opusfmspol

{_x assignTeam "RED"} forEach (Crew this); and, {_x assignTeam "BLUE"} forEach (Crew this);

Maybe a Zeus module could be used. I've tinkered with it enough to limit radius and height but didn't go any further than that. Whether it could be limited enough to correctly imitate A2 COIN, I can't say.

. . . when you code using classnames without looking them up to verify, and no resulting errors. . . . when watching an Arma video, the person who did the recording opens their map, and you click the screen to try moving the map.

If not already, for debugging purposes, use -showScriptErrors in startup params and do not use -noLogs. - Using -showScriptErrors gives a black error box on screen when an error occurs. Let's you know when there is an error encountered which is quite helpful. - Not using -noLogs will catch errors in the .rpt log and lets you review the encountered error. But using -noLogs prevents the .rpt from logging errors. The problem is here . . . "Land_TentDome_F" is missing a string quote ( " ) at its end, and there is a comma ( , ) after last item of the array. One would think it should have errored on those. and here . . . createVehicle command needs a string classname to create. You made _objType an array. createVehicle can't do anything with it. One would think it should have given a "type array, expected string" error on that. An array could be used, but it really is simpler to create three objects in a row from string. A problem is that the sleep script shows "obj2" and "obj3" are variables already in use. You would need to decide what variables to use to reference the additional created objects, and how to position them when obj1 is setPos.

Wouldn't it be better to have placed triggers run a single script that spawns the modules at the location? What's the purpose of using BIS_fnc_locations? Do those modules even use it? I do know using "CityCenter" with BIS_fnc_Locations is rather disappointing.

Don't Call Compile "New Name", that will error. BIS_fnc_SpawnGroup returns the group created, not the unit, i.e: _group = [<< params >> ] call BIS_fnc_SpawnGroup; Use Units command to select the unit from the group, i.e.: _unit = (Units _group) select 0; If you want the unit available to other scripts, define it as a global variable rather than a local one, i.e.: NewUnit = (Units _group) select 0; If you want other machines to use the unit in scripts, broadcast it as a public variable, i.e.: PublicVariable "NewUnit"; Waypoints are a group function. Use the group, not the unit, i.e.: _wp1 = _group addWaypoint [getmarkerpos "owp2", 0]; Hope this helps.

Not correct, you can adjust local alpha on editor markers. To my understanding, all markers are local and the difference between createMarker and createMarkerLocal, and their other associated commands, is that the markerLocal commands won't propagate across the network, whereas the other command does propagate to all machines. I just tested this to verify: If you have two machines - - Place a Blufor and Opfor unit on map, player and playable. Name one unit bob and the other bill. - Place two flag markers on map, "flag1" and "flag2". - Place a Radio Alpha trigger, with OnActivation: if (player == bob) then {"flag1" setMarkerAlphaLocal 0;}; - Launch in multiplayer and join on both machines, go to map and view the markers. Markers appear on both machines. - Call the radio trigger. Flag1 marker disappears on Bob's machine but not on Bill's machine. Check your trigger OnActivation and onDeactivation codes. You probably want something like: if (!isDedicated && hasInterface) then {if (side player == West && getMarkerType "bluMZ_1" != "") then {"bluMZ_1" setMarkerAlphaLocal 1;};}; and, if (!isDedicated && hasInterface) then {if (side player == West && getMarkerType "bluMZ_1" != "") then {"bluMZ_1" setMarkerAlphaLocal 0;};};

Might check in directory Steam\Steamapps\common\ , and verify that the Arma 2 folder is named "Arma 2" (space included). The folder being renamed can cause that to happen. Also in Arma 2\addons folder should be a missions.pbo and missions_ew.pbo. Missions.pbo has the A2 campaign.

Variable = params call BIS_fnc_spawnGroup; Variable is the returned group. Use the variable in triggers and for waypoints.

Trigger Activation See Any Group Member

Store the action ID. You want it stored so the action can be checked and properly removed. Add action: if (_vehicle getVariable ["actionVarName",-1] < 0) then { Private _actionID = _vehicle addAction ["Action Name", {_actionCode}]; _vehicle setVariable ["actionVarName",_actionID]; }; . . . . . . . . Remove action: Private _actionID = _vehicle getVariable ["actionVarName",-1]; if (_actionId >= 0) then { _vehicle removeAction _actionID; _vehicle setVariable ["actionVarName",-1]; }; . . . . . . . . Storing actionID should be included in addAction and removeAction pages, imo. These type questions pop up frequently.

Don't know about "faceType" or "genericNames", but my understanding of "identityTypes" is that it holds tags used in randomization, so when units are placed they get random faces, glasses and voices, but within the confines of their given tags. cfgFaces has various faces tagged with identityTypes "Head_NATO"; cfgGlasses has various glasses tagged with identityTypes "G_NATO_default"; and cfgVoice has voices tagged with "LanguageENG_F". So if a placed unit inherits from B_Soldier_base_F and has no identityTypes array defined, it uses those inherited tags to randomly choose face, glasses and voice. When there are multiple tags of a kind, it broadens the randomization range. If a unit class has "identityTypes[]={};" it gets no randomization, it uses defined identity. That's my understanding. If I'm wrong, somebody please correct.

If using the Conversations system, you don't have to use separate files but it helps with organizing. You can pack everything for different conversations into single files, i.e. one .bikb for topic, one .fsm for AI., one handler .sqf for players, etc. Then you only have to add one kbtopic to all speakers at mission start. But as the mission expands with more and more conversations, the files become larger and difficult to search through. So I would say, small missions with maybe a few conversations, you could pack all into single files, but with larger missions having various conversations, you will want to consider breaking the conversations out into files named for their topics.

Since no response, One option is to go into the missions.pbo and review the SOM folders (SecOps Manager). It has a kb folder and fsms folder. Would also need to go into the languagemissions.pbo to find the stringtables used by SOM. Has everything but the gunship run stuff, the Gunship Run stuff is in missions_e.pbo and languagemissions_e.pbo. That's where I learned how the conversation system works, by doing customized SecOps and SecOps supports. While working on that, the posts by Jezuro, HateDread and EvilEcho helped much with understanding how the SOM kb system was set up and functioned. In the end I had dialogues of my own going on. But they're not set up any different than what SOM has, so I suggest looking there. Locality is important. kbTell needs to be done where the unit is local. kbWasSaid is also local, it fails when checking a remote unit, so sleep is used in that instance. SOM is run by server, which does HQ kbTells. It uses public variable event handler on variable "BIS_SOM_codeBurst" to have the players do their kbTells. The artillery support includes use of addaction kbTell calls. Hope it helps.

You should just have to condition the "not" apart from the "In". if !(don1 In v1) then {<code>}; if (alive don1 && {!(don1 In v1)}) then {<code>}; // Edit - sorry, jumped the gun without reading entirely. If a team do the units as pointed out above, but still condition the two apart like Pierremgi has.