mrcurry

this should be doing nothing at best or throw an error at worst. Have you enabled -showScriptErrors on your A3 launcher / startup parameters?

@scottb613https://community.bistudio.com/wiki/forgetTarget

This depends entirely on the use case. If a uniform distribution is required, meaning all outcomes have equal chance to occur, you need a different approach. For a proper uniform random range use: _rand = _min + floor random (_max - _min); Above _max is exclusive and won't be included, if you need inclusive _max use: _rand = _min + floor random (_max - _min + 1); These are both guaranteed to never generate value below _min. It's ofc ok to precompute the brackets into a variable and use that as input to the random call.

If this fixed the issue one of the logic tests in the previous conditions obviously failed. To know for sure you'd have test them individually and see which one returns false. I'd do that before attempting a further fix.

I can think of two ways. Method 1: For each group of detecting side, command: groups playerSide Call command targets on the current group Use the result to create your marker Method 2: For each group of the detecting side Add an "EnemyDetected" event handler In the event handler add your marker If you need information on the enemy you can use _groupLeader targetKnowledge _target These methods doesn't include how you track markers, check if an object has a marker or delete markers that are no longer relevant. If you want it, here's how I'd solve that: Edit: Oops, just realized you wanted groups, but the logic should be easy to extend to manage detected groups instead of individual units. The key is to remember that AI doesn't see groups, they see units. Groups are just an abstract composition, so you have decide what it means to "create a marker on the group". Do you mark the group leader's position or the average position of all units in the group? Do you include units that aren't detected yet? Do you interpret clusters of units as s group or rely on the game's predetermined groups.

My 2 cents: Tell the story you want to tell. Make the mission you want to play. If your goal is a specific narrative then a given character makes more sense. The vanilla and Laws of War campaigns are good examples of this. This requires some solid writing though and I would recommend running any script or story by a trusted friend or partner for feedback.

I've been doing SQF since Arma 2... Hundreds if not thousands of hours spent looking on the BIKI... and today I learned the BIKI has dark themes... F M L Edit: Right maybe I should contribute something useful... Only thing I see is that _unit isn't defined in what you posted.Something like: params["_unit"]; at the start of EliteOrNot.sqf should do the trick.

I'm fairly sure that lobby slots are derived from the mission sqm, so No... but I also haven't tried. If someone has succeeded please do tell. In the meantime your best bet is to place playable units and move them into the correct seat as the player loads in (initPlayerLocal). You can hide it behind a loading screen if you wish, the player won't know the difference if you do it right.

Have you set your player units to playable? If yes try removing them and placing them again and export to multiplayer again. You say: Does this mean it works hosted from your a player's PC?

This is because the code you pass to the BIS_fnc_loop doesn't run inside LFT_startCarLoops's scope and therefore knows nothing of the variables declared there. Reading the BIKI for BIS_fnc_loop we can see that it doesn't allow passing of arguments to the code. A quick and dirty fix is to rely on global vars instead, which should be ok as long as it's only used once... For a more reusable approach I'd recommend scrapping the use of BIS_fnc_loop and switch to a regular while loop instead. Combine with spawn and sleep you can achieve a similar effect with the added bonus of a lot more flexibility. If you need code examples let us know.

Logically the only thing that differs is your position input right? My vector math is a bit rusty so take this with a grain of salt but a couple of observations: 1. I don't know what _position_x, _position_y and _position_z contains since you don't show them being computed but here you using the order XZY, are you sure this is the correct representation? In most cases A3 uses XYZ but sometimes it doesn't. Just worth double-checking. Edit: checked the docs, XZY is correct. 2. The angle between the screw driver and the horizontal axis seem very similiar to the angle between same axis and the desired vector... I'm gonna hazard a guess the resulting vector is incorrectly reflected around the horizontal. If that's the case you probably need to invert the input corresponding to the vertical axis, once you figure out whichever that is. Edit: Nvm, was an illusion on a smaller screen. As a debugging tool you can add the ability to move the screwdriver in a circle around the desired target so you can get a better feel for the problem. Otherwise I'd say start printing out the variables and see where the numbers stop making sense. Hope that helps!

Your code seems fine at a glance. player should be fine, it just needs to be executed on the correct PC. If your trigger is doing nothing the code is either not executing or executing on the server only (where player = host player or null-object) or on another player's machine (that would be strange). What is the trigger settings and condition? Is it server only? The following trigger config should at least execute your code locally for each player as that player enters the trigger: Setting: Any player present Condition: player in thisList Server only: Off With this I recommend changing the removeX commands so they execute only on player i.e. change: {removeVest _x} forEach thisList;  to removeVest player; To help with troubleshooting you can verify that your code is running by putting a systemChat "Loadout X"; as the first line. If you see the text the problem is in your code, else it's in your trigger. You can also have -showScriptErrors enabled in the A3 launcher. This will show you on screen if your code has errors.

Is not the same as This: Turns into this: player addAction ["End Mission", { ["end1", true , 3, true, true, true] remoteExec ["VN_fnc_endMission", 0]; }, nil, 7, false, true, "", ""]; That being said I don't think it is a great idea to allow any old player to end the mission at their own whims. Either let the host/admin decide or go for some kind of voting system, only if a majority says "End it!" then you do so. Also since ending the mission is an irreversible action consider that actions added to the player will be available at all times. You don't want a player to accidentally bring the session to a close prematurely, just cause they are in a high-stress situation and clicks the wrong action. Oh boy, the number of times I've seen people blow themselves up with charges or eject themselves... the action menu is really prone to mistakes like that. I'd do either of these: gate the action behind some "objectives complete" condition add some kind of confirmation step use another approach that requires deliberate user input (like using chat messages as input)

After a solid 2,5 hours of testing I'm pretty sure this is a very niche bug with setUnitLoadout that we've stumbled across... From my tests it only happens under these circumstances: The player is in a vehicle setUnitLoadout is applied to the player The player disconnects before leaving the vehicle, switching seats does not avoid the issue. The server and mission is configured so AI takes over the player unit (disabledAI = 0;) The symptom seems to always to be that the uniform and vest disappears. It'd be interesting to see what other players see... when exactly does the uniform and vest actually disappear? I've disabled everything else custom in the mission, including your script Pierre and it still happens. So yeah I wouldn't bet my life on it but it looks like super niche issue that just happens to line up perfectly with your script Pierre and @FoxClubNiner's requirements... Well done! 😄 It should be posted to the bug tracker if it isn't already... but I wouldn't hold my breath for a fix anytime soon.

You hit the nail about the game not knowing about your previous loadout when you reconnect, and it hints at the core problem MP code has to solve: state syncing 🙂 I double-checked what I posted and it seems syntacticly correct, also line 2 in scubagear.sqf is unchanged from the OP. My guess is some sort of invisible formatting characters snuck in with the copy to/from the forums. I've seen it before when I combine code and spoilers like that. A quickfix can be to check for hidden characters using a competent code editor like notepad++ or vscode. The hidden usually look like weird symbols or question marks. Or just brute force it by rewriting the offending line (including comments) manually. I'll upload a clean copy "soon", hopefully together with a working server-side version.