opusfmspol

Multiplayer Custom Sounds Tutorial

Hi QuiGon, Not known when I made that post (2017), is that a waypoint's condition only gets checked by the Group Owner machine. The waypoint's OnAct code will get run on all machines, but only the group owner machine will check whether a waypoint's condition is completed: (Waypoints wiki page) And I believe that's what leads to the locality issue, in that my testing back then showed the synced LOAD and GETIN waypoints seem to rely on unitReady commands in their handlers to detect when the units to board have all mounted. But unitReady only gives an accurate return when the unit being checked is local. A machine that checks unitReady on a remote unit will always receive a return true (unit is ready) even when the unit is not ready. The waypoints work in SP and for MP Host-Only because the transport group and the boarding group are all local to the server, the waypoint unitReady checks give them an accurate return. But In multiplayer client and dedicated server it fails, because the transport and boarding groups are each local to different machines. The transport hits the LOAD waypoint, and checks status of the remote group boarding. Being remote, it receives unitready true from all the units to board (even though they haven't yet boarded), so it continues on to next waypoint. That's what I believe occurs. The post from 2017 was an attempt at working around the locality issue, while not understanding that only group owner would check on waypoint condition. It worked, but is a burdensome work-around. Instead, try using waypoint conditions to check that the units have actually boarded before the waypoints can complete. Keep in mind that for your mission, server checks waypoint condition for the transport, client checks waypoint condition for the boarding team.

The .rpt log is spamming because you have no sleep in the waitUntil. Undefined variable gets logged for each cycle while it remains undefined. Seems your camp script is running before the common init completes, and commonInitComplete was not predefined. You could predefine it, which is often the best way: commonInitComplete = false; // stuff happens // camp script runs // common init finishes commonInitComplete = true; Or you could handle it as a flag variable which could be nil, true or false: waitUntil {sleep 0.1; [false,commonInitComplete] select !(isNil "commonInitComplete")}; Return is false when commonInitComplete is not yet defined; or, Return is commonInitComplete value when it is defined.

showCommandingMenu "";

SaveVar command BIS_evidenceGathered = 0; saveVar "BIS_evidenceGathered"; //GLOBAL: VALUE OF EVIDENCE GATHERED SO FAR IN THE CAMPAIGN

For unlimited ammo, @avibird 1 posted this release at the beginning of January. And it can still work in A2 if the private variables, params and remote execution get reverted back to the A2 old school methods. For instance, where A3 uses remoteExec, A2 uses the RE function, as in "Call RE" or "Spawn RE", with its associated rCommands.

Maybe this post from 2016 could be relevant. isTouchingGround also has a note from Gippo dated April 2017 saying: Which in my mind would conflict with its Global Argument indicator; usually a command that needs to be run on the machine where object is local would have a Local Argument indicator. I concur with the @Larrow and @pierremgi, if the command is being problematic, rely on the object's z-coordinate instead.

@Gunter Severloh, I suppose it's not the word "time" that's the issue, it's the word "waste". What is waste? In refining, it's the slag. Raw ore goes in and the product is run off; but whatever's left over is the slag, cast off and disregarded. The product is the tin, the iron, the copper, the silver, the gold. All things precious. ("Precious": because of Tolkein and the brainwashing black boxes we live with, it invokes the word "Gollum" to mind, but is that what I'm speaking of here? I mean what's actually near and dear in each of our hearts. The things we treasure in our hearts and our minds, the things we appreciate. Should a parent look at their child and go, "Gollum"; or should we break the brainwashing and cast that aside?) We're all individuals. We all have things precious to us. All things precious to me may not be precious to you, and all things precious to you may not be precious to me. Those things precious to you clearly are not all precious to whoever criticized. But it seems they have their things precious too, which it seems you don't appreciate as they do. They look upon your time in Arma as a heap of slag, and they seek gold. Yet in your own eyes, what they see as slag is golden. Is that a paradox? No. It's human, it's humanity, it's who we are. We all have different values, and we all value the same things differently. I'm in the U.S., and here in the early 1800's there was a card game called Faro that was more popular than poker or blackjack and played in all the saloons whether for money or for fun. How do you suppose the people in the saloons would have reacted had someone come in and told the Faro players, "You're wasting time, those cards aren't real; the real world lies outside those cards!" I figure first you'd hear, "These cards are real", and they'd be right. Then you'd hear, "If I'm wasting time, whose time is it I'm wasting?" Anyone who might say it's a waste of your time would be more truthful to say "It's a waste of time to me." They're projecting if saying it's a waste of your time. We all live from point A to point B (whether we go on to point C, you decide). Simple fact is, from the moment we're conceived, we're doomed to die and we get a dash between two numbers. So what do we do with that time that we have? We live, we work, we rest. Some have more and harder work than others, some have more and greater rest than others. Some have more and better life than others. Make the best with what time we've got. Family; don't neglect family. But sing it brother, there's a song in there. And if a preacher can't preach about that, he's got no Spirit in him. Reality is that Arma, for most of us (because for some it is a job, putting bread and butter on the table), it's entertainment, it's amusement. We all seek entertainment, we crave it, because in life we have stresses and distresses all around us; and like a field laborer longing for the shade, we seek relief. And when we get it, relief itself is short-lived, it's not enough, we want amusement. I've heard it said that "amusement" comes from the Greek word "muse", which means to have in mind, to think. To a-muse is the antithesis, the opposite, to put out of mind, not to think. Think of what? The labor, the stresses and distresses we have to deal with. If we rest without entertainment, we think about those things. We don't want to muse on them, we want to be amused. And some people take their amusement seriously, like you do, and admittedly, so do I. What you're doing is taking your bit of shade that you found seriously; constructing a lean-to, making a mattress, adding a pillow. And others who share the shade with you appreciate that, because you share your stuff with them. The laborer expects his wage; to you and those around you, it's silver and gold. Those looking on from afar say, a trash heap; what a bunch of waste. It's not a waste. It's what you choose to do with your time in the shade. All I would suggest is, don't ever let the time resting in the shade detract from the work, or the life (i.e., family as well as friend time).

If a script is run repetitively, over and over again, you want to compile and run it as a function. Whether done using CfgFunctions in a Description.ext, or by using: THY_fnc_mainBasesProtection = Compile PreprocessFileLineNumbers "FolderName\mainBasesProtection.sqf"; . . . the file will only be compiled once, and the function can be called or spawned over and over again without it being recompiled. execVM compiles the script every time it gets used, and that takes away processer time that could be used elsewhere. So you would use ExecVM for scripts that are only run once, or remain persistent (like looping updates, which the base protection script sounds like), or scripts that are needed, but rarely get run. This is good strong advice (IMHO), because your mission might not use a CfgRemoteExec in the Description.ext, but you won't always know whether an addon that will be used has within its config a RemoteExec restriction against clients running the ExecVM command. On dedicated server, Player is objNull. If it has to be run by server, you may need to cycle through allPlayers array and determine who is inside the base limits. But on client, Player command will always return the object which is the client player's unit. It's different on every machine. So if the script is only applying immortality to a player, and nothing else, it should likely be run from initPlayerLocal.sqf

With that many tasks I would resort to a mission flow FSM to handle them the way BIS tends to do, but you may be unfamiliar with FSM's so.... - You spawn or execvm a loop that handles setting the task states. This way you have a single go-to script for testing whenever tasks get added in or modified. - At the start, before the loop begins, you declare flag variables. These flags prevent their specific task blocks from running more than once. - Inside the loop, each task gets checked to see if its condition is met. If so, the task state gets handled and the flag gets set. - Each task has its own condition to satisfy, but it also checks the flag variable, in order to disregard after the task has already been handled. Very basic and simplified: And if one task is dependent on another being completed, that too can be added into the condition using its flag variable: if (<task04 condition is true> && _task_02 && !_task_04) then {_task_04 = true; <set task state completed>};

That would be correct, player object changes to a different object on respawn. No need to copy it over, the loop continues until player disconnects. Just use Player command (or update the player object "_rc" each loop), and use condition that player is Alive for the info to update. While {true} do { if (Alive Player) then { hint . . . . }; Sleep 1; };

Why not have initPlayerLocal execVM the script? The remotExec and BIS_fnc_ExecVM seem unnecessary, and the remotExec 0 seems like it would be the issue.

Says it's "RemoteExec Restriction", is CfgRemoteExec being used with mode restrictions applied? I wouldn't know the answer myself, haven't as yet ever used a CfgRemoteExec in a mission.

I would suggest: 1) End the onMapSingleClick code with true or false, to tell the engine whether to include default engine handling. An example of default handling is, when player is the commander of a vehicle, clicking on map tells the driver where to move. Would you want that sort of engine click behavior included with the map click? - Ending onMapSingleClick with true tells the engine the code completes the click action, do not include the default engine handling. - Ending onMapSingleClick with false tells the engine the code does not complete the click action, also include the default engine handling. 2) Only use onMapSingleClick to get the pos. After that, have the addAction code do the work, but also handle interruption, i.e. the player chooses to close the map without selecting a position. At the end of addAction, clear the map click (onMapSingleClick ""). A very basic example: openMap true; hint "information"; PosClicked = false; _target onMapSingleClick {ClickPosition = _pos; PosClicked = true; true}; WaitUntil {Sleep 0.1; (PosClicked || !visibleMap}; PosClicked = false; if (visibleMap) then { // do the marker and waypoint stuff openMap false; }; onMapSingleClick ""; hintSilent "";

Assuming _targetMarker is a marker, it should be: if (_x distance (getMarkerPos _targetMarker) <= 30) then Is this the idea? (expanding from what @ZaellixA has above) Private ["_cars","_maxDist","_minDist","_nearest","_unit"]; _cars = [car01,car02,car03]; _nearest = objNull; _maxDist = 100000; _minDist = 30; ScopeName "DangerClose"; { _unit = _x; if (isPlayer _unit && Alive _unit) then { { if (_unit Distance _x < _maxDist) then { _maxDist = _unit Distance _x; _nearest = _unit; if (_maxDist < _minDist) then {BreakTo "DangerClose";}; }; } forEach _cars; }; } forEach playableUnits; // Something now happens.