Magirot

If you want a relatively simple command, CfgPostprocessTemplates should be viewable from the editor's config viewer and contain a template class for black & white. Then you can set it with BIS_fnc_setPPeffectTemplate: ["templatename", 0, TRUE] call BIS_fnc_setPPeffectTemplate; 0 is the commit time, TRUE means that the effect will be executed globally for every player. Edit: Oh, scratch that, most of the templates are only added in the development build for Zeus. Well, that effect is applied with: "colorCorrections" ppEffectAdjust [1, 1, 0, [1, 1, 1, 0], [1, 1, 1, 0], [0.75, 0.25, 0, 1.0]]; "colorCorrections" ppEffectCommit 1; "colorCorrections" ppEffectEnable TRUE; "filmGrain" ppEffectAdjust [0.04, 1, 1, 0, 1]; "filmGrain" ppEffectCommit 1; "filmGrain" ppEffectEnable TRUE;

Doesn't BIS_noCoreConversations only remove the generic conversations that Arma 2 had? Like the ones where you could ask for seen units, nearest settlement, or weather. Arma 3 doesn't have them to begin with.

Thank you, I'll keep that in mind :) It's mostly due to overreaching (too many features), poor planning (giant mess), and an effort drain from making a separate program for dialogue editing, which I had no previous experience of. I'll just have to start simplifying it at some point.

I'll try to clarify, please correct any mistakes: There's no easy, elegant solution The unit type isn't really relevant in this case, but if it's a civilian, it's better to change the side of the unit to blufor with the aforementioned invisible group leader or some other trick. This is done because sides other than civilian get an easy command for switching them to civilians temporarily (setCaptive). With it, you can set them to be treated as civilians initially, and switch them back to their original side (that is, their group's side) when opfor is alerted. But it's not simple or straightforward, since you need to keep track of player actions with scripting to figure when they shouldn't be civilians anymore. (The unit also doesn't register as a member of its side while setCaptive is on, which is why I earlier talked about grouping triggers to the group instead) The point of the last few messages was: The system with setCaptive is complicated to set up and manage. You can use "this addRating -20000"* instead, to make everyone hostile to the unit without affecting its side. However, that makes everyone hostile, including any allies that the mission setup would have the players have. In this case it will also still warrant following player actions to determine when to run it. Given that you want friendly blufor units in the mission, setCaptive is probably more to the purpose. * Rating is a system that's used by the game for, among other things, following friendly fire. If the rating gets too low, the unit gets tagged as a renegade that everyone is hostile towards. As for the rest, I already explained the solutions and problems I know of in posts 3 and 5. I don't know a thing about ALiVE, but it might work if you modify the spawning to add the required event handlers to newly spawned units as well. You can test it with units that already exist in the mission by adding something like this to init.sqf: // Only set the EH's if it's the server if (isServer) then { // Declare functions OpforAnnoy_KilledEH = { // declare private variable private "_killer"; // causedBy is the 2nd variable passed by the EH _killer = _this select 1; // if still captive, remove setCaptive if (captive _killer) then { _killer setCaptive FALSE; }; }; OpforAnnoy_HitEH = { // declare the private variable private "_damager"; // causedBy is the 2nd variable passed by the EH _damager = _this select 1; // if still captive, remove setCaptive if (captive _damager) then { _damager setCaptive FALSE; }; }; // 'forEach allUnits' block start { // Only add if the unit is OPFOR if (side _x == opfor) then { // add EH's _x addEventHandler ["Killed", OpforAnnoy_KilledEH]; _x addEventHandler ["Hit", OpforAnnoy_HitEH]; }; } forEach allUnits; // cycle through all existing units }; So to reiterate this whole mess, in case you want to try the setCaptive path: Group the civilian player units under a blufor commander that has probability of presence slider set to zero. Add this setCaptive TRUE; to the init of all player units. Add that block of code above to init.sqf; it will make all opfor units that have been placed in the editor react to players shooting them. (Or rather, react to players hitting and killing them; in case of players firing madly near them or missing their shots, they'll at most go prone. This is why it always feels a bit lacking, and you'd need to add even more EH's to simulate it better.) To reset captivity on respawn, create onPlayerRespawn.sqf in the mission directory with the snippet in post 5 in it. Add the trigger from post 5 to the military base(s) to make them react to intruders.

Doesn't seem to be stuff that can be set with scripts, it's done by emptying all lines from class RadioProtocol*. Does enableRadio FALSE also disable group/side/globalChat messages created by scripts, by the way?

sideEnemy has its own issues you should keep in mind, though. One is that the noticed player gets thrown out of the group, which can be annoying in MP, other is that all units of all sides start attacking the player, including any blufor that the player should be working for. But if there are no armed units that are supposed to stay friendly to the players, that can indeed be the best method. Edit: Then again, in case all you need is armed friendly units for flavour's sake, you could just init them with { this disableAI _x } forEach ["TARGET", "AUTOTARGET"]; this allowFleeing 0; this setBehaviour "CARELESS"; and they shouldn't fire or react to anyone, including an enemy player.

In your own mission? enableSentences FALSE silences everything, but you could apply a different speaker to Nato units with setSpeaker. Or add something like this to init.sqf: _voices = [ "Male01ENGB", "Male02ENGB", "Male03ENGB", "Male04ENGB", "Male05ENGB", // British "Male01GRE", "Male02GRE", "Male03GRE", "Male04GRE", "Male05GRE", "Male06GRE", // Altian "Male01PER", "Male02PER", "Male03PER" // Farsi ]; { if (side _x == blufor) then { _x setSpeaker _voices call BIS_fnc_selectRandom; } } forEach allUnits; Edit: I wonder if this Male00 that appears in the configs is a silent speaker or something?

You probably meant Description.ext, not init.sqf?

The grouping setup should work, since respawning doesn't change the group. As for setCaptive, you just apply it again after respawn. Create a file called onPlayerRespawn.sqf in your mission directory and add this in it: _unit = _this select 0; _unit setCaptive TRUE; You can also modify the loadout at that point with stuff like "removeAllWeapons _unit;", just remember that remove/addUniform is very problematic and should be avoided, since the latter is a command with a local effect and onPlayerRespawn fires only locally. List of possible Event Scripts like onPlayerRespawn if someone is interested. Anyway, since it's a multiplayer mission, the "no civilians allowed" base's trigger needs to be different. Maybe rely on the locality of player command. Create a trigger, group it with the player group, and try these settings: - Size: the size of the base - Activator: any member of group - Detected by opfor - Condition: player in thisList - On Act.: player setCaptive FALSE;

I'd go with this usual setup: 1) Add "this setCaptive TRUE;" to the player unit's init 2) Create a new blufor unit 3) Set that unit's "probability of presence" slider to zero 4) Group the player under him This way the player is actually a blufor unit that's just treated like a civilian by other sides. Then whenever you want to remove this status you can use "playername setCaptive FALSE;" The approach isn't without problems though, since enemies won't instantly react after setCaptive has been set to false. And the harder part is usually following the player's actions in such a way that the enemy's reactions seem logical. In case of the military base you'll probably just want to create a trigger that takes setCaptive away if opfor notices the player - don't use "blufor noticed by opfor", though, since a captive isn't treated as his regular side. Rather group the trigger to the player unit. For reacting to firing I'd use Killed and Hit event handlers applied to all units, but that's the part that isn't compatible with ALiVE. I don't know if there are features in it that allow for applying EH's to all spawned units.

Nice! Completely missed dwringer's system as well. I was working on a similar, more complicated system, but I doubt I'll ever get it done with my skills.

In case you're running it from the object init, isn't it the same to use setObjectTexture, though? Not really related to Sylensis' question anymore, just curious.

If you want to do it from the vehicle init, you can use spawn which allows delaying the command. _null = this spawn {sleep 0.1; _this setObjectTexture [0, "\A3\Soft_F_Gamma\SUV_01\Data\SUV_01_ext_02_CO.paa"];}; from this post of Kylania's. I added sleep 0.1 because in my experience spawn alone doesn't always delay it enough to avoid the randomiser, though in 95% of the cases it does. Also, forum search or google with site:forums.bistudio.com is usually helpful with problems such as this.

That is probably the case. http://feedback.arma3.com/view.php?id=14701

I don't think it's related to length, since at least with me the audio always desyncs in the first few seconds regardless of how long it is. I've tried clips ranging from 4 seconds to ~5 minutes. Still there must be a working encoding setup, since BI's own intro works fine if you call it in your own mission, and apparently you've gotten shorter videos to work as well? I played around with Kydoimos' file in ffmpeg2theora (since that's what BI used), and I actually got the sync to be better than what it usually is for me, but there's still an annoying sound failure in the beginning, and it's clearly not as good as with a regular media player. On another note, if there are other people like me who hadn't checked BI's own scripts before, here's initIntro.sqf from Survive with the subtitles removed. Makes the mission intro consist of only the video in an apparently performance friendly manner and then ends the intro section. 0 fadeSound 0; titleCut ["", "BLACK FADED", 10e10]; [] spawn { waitUntil {time > 0}; enableEnvironment false; }; // Limit view distance setViewDistance 500; // Create upwards-facing camera private ["_camera"]; _camera = "Camera" camCreate [10,10,10]; _camera cameraEffect ["INTERNAL", "BACK"]; _camera camPreparePos [10,10,10]; _camera camPrepareTarget [10,10,1000]; _camera camPrepareFOV 0.7; _camera camCommitPrepared 0; sleep 1; private ["_video"]; _video = ["A3\Missions_F_EPA\video\A_in_intro.ogv"] spawn BIS_fnc_playVideo; waitUntil {scriptDone _video}; sleep 1; _camera cameraEffect ["TERMINATE", "BACK"]; camDestroy _camera; // Terminate intro endMission "END1";

I've not seen anyone say they don't work in threads concerning them. On the contrary, often it's about people thinking the default values remove corpses too early.

addons\ characters_f.pbo, characters_f_beta.pbo, soft_f.pbo, soft_f_beta.pbo with a software like PBO Manager. If you just need the filenames, you can also dig them up from the config editor in the mission editor.

What about the setup mentioned here, does it only work for items?

Have you used them in-game? I don't have any trouble with sound while playing them with regular media players either, but in Arma 3 there's always the desync.

I did try to convert a raw video with both VLC and ffmpeg2theora. With the latter I also tested different setups I could dig up with google, all had either the same old desync or even worse problems. Has someone actually got it working correctly? None of the older threads I find on the subject mention this stuff.

I seem to remember from the thread that executing addUniform had problems even with BIS_fnc_MP. Only solution I've found is making sure that removeUniform is not run after the initial initialisations, and executing loadouts through functions. Here's one of my loadout scripts, though I wouldn't rush changing yours yet, since no-one more adept at scripting than me has taken a look at it yet. I can't take a proper look at the mission now, but you should at least get the briefing show up if you just call it from the beginning of init.sqf with [] execVM "briefing.sqf"; and add if (!isDedicated && (player != player)) then { waitUntil {player == player}; waitUntil {time > 10}; }; to the beginning of briefing.sqf. If that file is your only setup for it? In case you use modules, they're quite broken in MP, though the task ones work except for some flicker for Join-In-Progress players.

F2k Sel probably confused it with using local variables in the actual condition text. You can pass _text and _conditionCode, but you couldn't for example use _fixAllowed = true; _action = _veh addAction [_text, "vla\actions\DO_ACTION.sqf", [], -1, false, true, "", [b]"_fixAllowed"[/b]]; since the scope is different.

Sorry if I'm making it worse by not getting it, but just to be sure: so you do want to call the script automatically at missionLoad, and have preInit = 1 in there for a reason, then? Because it's confusing that you talk like it shouldn't do that when it's set to 1. And clarifying further, if you don't want to have the Functions Library automatically call the script when the mission is loaded, then leave preInit = 1 out. All you need for a function is the file path. The invalid type it complains about might be the preInit variable that preInit passes to the function. From the comment of what you pasted: 'Passed arguments are ["preInit"]'

This turned up in the search: http://feedback.arma3.com/view.php?id=18026

You are missing one }; at least, but that was probably just left out from the paste. I might be misunderstanding something (sorry if I did), but if you put preInit = 1 as an attribute to a function, it'll be automatically called pre-initialisation. Like it says in the comment of what you pasted: "1 to call the function upon mission start, before objects are initialized". If you just want to compile functions for later use, leave preInit (and postInit) out altogether. As another note, you don't need to specify ext if you have the file path.