opusfmspol

The High Command module doesn't monitor for changes in synchronizations. Some modules do I suspect, but it's one that doesn't. You could reinitialize by running its "hc.sqf" script again, but then it creates a new instance of the "hc_local.sqf" running on each connected machine. Each would end up with multiple instances of the same script running. You'd want to terminate each one's old instance for the new instance, or better yet not have a new instance run if their old instance still works proper following HC reinit. The HC module initializes by an eventhandler rather than function. The eventhandler execVM's the HC script. What I've done in the past (A2) was copied the HC module scripts to mission folder, and changed the scripts in mission folder to suit the need. Then placed a regular Game Logic on map and have it run revised HC eventhandler code, running the mission scripts instead of the core scripts. Basically the game logic acts as a surrogate HC, to run the scripts from mission folder instead of core. In that way I could get HC's Radio Waypoints and F5 "assign missions" menu to work in Warfare. Just tested, and this method does still work with A3, syncing HC Subordinate modules to the Game Logic. If you should choose that route, look for where the BIS_fnc_MP call is made to execVM hc_local.sqf on each machine. - Not running a new instance on clients: You'd want to control the call, only having it occur on first initialization, not on subsequent ones. - Or, running a new instance on clients: You'd have to work out a way to terminate the old instance on clients. Somehow find a way to capture and store each script handle, and issue them a terminate command when the new instance is going to run. But running a game logic as surrogate with mission scripts, you'll have much freedom to make the different HC scripts work as you intend.

Yes, but since isPlayer could occasionally give a bad false return, (_x In allPlayers) might be better.

"BIS_fnc_Init" is still true in A3 after functions compile, so yeah should work, but classnames would have to be changed to whatever the A3 proxies are.

Agreed. The OFP and Arma labels were apparently intended to help clarify, but in fact make it have to be somewhat deciphered: ModeClass: class Mode. Must be declared (or inherited) for each class. MuzzleClass: class Muzzle. Must be declared (or inherited) for each class. OFPModeClass: class Mode. Must be declared (or inherited) for each class. Generally moved to Arma's cfgMagazines Class and often renamed, else simply renamed. ArmaModeClass: class Mode. Must be declared (or inherited) for each class. Introduced from OFP:E and beyond.

Yes. And 0 is returned if setVariable hasn't been done.

thisTrigger is refence to the trigger itself in triggerStatements. No need to give the trigger a name unless needed for reference elsewhere. If you want the set variable unique to one trigger, give one trigger a name and there use thisTrigger setVariable [ ] and thisTrigger getVariable [ ]. In all the other triggers put <trigger name> getVariable [ ], using reference to that one trigger's name. Or, if you need the set variable unique to each trigger individually, no need to name the triggers. in each trigger use thisTrigger setVariable [ ] and thisTrigger getVariable [ ].

Have encountered the same before. The colon : causes the issue (insert puns here). Using setVehicleVarName resolved it for me. With colon : , preprocessor mad, but with vehicleVarName, preprocessor happy.

6thSense.eu - Locality Helped me much with understanding locality, but it was just a start. There's so much more, and I can't hit it all, others might chime in to help. But here's my experience. When scripting for MP you must always, with every script, keep in mind which machines will be running that particular script. Server? Client? Both? or maybe even a Headless Client? You have to keep your head wrapped around that. Argument local: When reviewing script commands and you find the argument is an object, and the command is "Argument Local" (e.g. setFuel), it means is that the object (in this case a vehicle) has to be local to the machine issuing the command, whether server or client. With AI, they might be local to the server or not. AI are usually local to the server, right?... one might think. But with a driver who is AI subordinate to a player leader, the vehicle is local to the player leader machine. This is where one would use local command: "if (local vehicle1) then {vehicle1 setFuel fuelAmount};" Effect Local: The local command is "argument global", and what that means is the object must exist on all machines. There is a command createVehicleLocal which has only local effect, i.e the vehicle would exist only on the machine that runs the command. Hint and addAction are also local effect. It means the hint only occurs on, or the action only exists on, the machine running the command. If you want it to occur on all player machines, the command has to be run on those machines. That would mean the script is spawned, called or execVM'd by the target machines, or Public Variable Event Handler is used, or remoteExec (allows suspension) or remoteExecCall (does not allow suspension) are used to target them. Headless and Dedicated: But AI can also belong to a headless client, which is a player and yet not a player. It's a machine run to offload AI functions, so the server can run faster doing basic processes while the headless handles its AI functions. In essence it's like having another proxy server, yet the headless client AI leader is registered as a player and it's AI subordinates are local to the headless client machine. Headless client has no user interface (UI), neither does a dedicated server. So to exclude those two and only target real player client machines, one can use "if (hasInterface) then { . . . };" Dedicated server has no player. Player is objNull on a dedicated server. This is why when scripting for MP you should avoid using player command in any server or common scripts. Using it in client or headless scripts is fine. But if a dedicated server runs a server or common script which issues a player command expecting a return, it could error and maybe even terminate the script. Effect Global and Editor Triggers/Waypoints: When you see a command that has "effect global" (e.g. createVehicle), it means you will usually only want that command to run on only one machine. Because the result will propagate over to all machines. This is important to keep in mind with Editor triggers and waypoints. They will exist on all machines that load the mission. Many times people post "Why am I getting (_x number of vehicles) created when a (trigger/waypoint) goes off?" First response: "Is it an editor (trigger/waypoint)?" - - "yes." (been there, done that). Usual fix is to localize the condition so only the server runs the global effect command, or a specific client machine if that's what is better for the mission. Instead of just "this", condition would be "this && isServer", or "this && local TeamLeader1". In MP you'll have problems with synced LOAD and GETIN waypoints when the vehicle and troops are not local to the same machines. I suspect (not confirmed) it might be that the two waypoints use the unitReady command on each other. My tests with unitReady command have shown that the command is "local argument". It only returns a correct true/false on the machine where the unit is local. On any other machine, where the unit is not local, it always returns "true". And that causes unexpected results when a mission event, like deployment or extraction, relies on it. Finally, with waypoints, I had an MP problem and ran a test one time, which found that only the machine where the group leader was local did the condition check, but the waypoint expression was run on all machines when the condition returned true. It had the standard placement condition. However I can't say whether that was a local mission issue or not, I don't believe it was. I've kept that in mind ever since. I would invite others to test whether it's true or not. So this final observation, take with a grain of salt. --- Edit: Reviewed that particular mission again, and recalled the waypoint had not used standard placement condition as first thought. Extraneous code was run in a waypoint condition field ahead of the returned waypoint condition "true". But the extraneous code only occurred on one machine, where it was expected to occur on all. To find out why not, diag_log's were added. The WP condition diag_log only logged on the machine where the leader was local. The WP expression diag_log was logged on all. That's when I figured that waypoint conditions are only checked on the machine where the group leader is local.

Thanks very much Larrow, I've been unaware of that. Got some uses for it too, now that I know.

I just remembered, with addAction the passed in params are (_this select 3). (_this select 3) params ["_marker","_foodCost"]; bas_num = (_this select 3) select 2;

No, it broadcasts the global variable so others get synched as to its value. But you have to broadcast it as a string: GLOBALFOOD = _foodRemaining; publicVariable "GLOBALFOOD";

Check the flagpole addaction, make sure base_4 is string "base_4".

Error >: Type Object, expected Number,Not a Number _globalFood is defined from GLOBALFOOD, so the error indicates that somewhere GLOBALFOOD is somehow being redefined as an object.

Incorrect structure of the params: params [ ["_marker","_foodCost"] ]; Test with this: params ["_marker","_foodCost"]; If unaware, this page lists all the commands as links to instructions on how each command can be structured and used.