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.

Edit: After sleeping on it and reading your post again I realize you may not have loadout-restoration in place. If so Solution 1 won't work! I've added solutions for a client-side and a server-side variant. These are all mutually exclusive with each other. Solution 1: (Original post) Vanilla diving gear is placed in the goggles slot ( the stuff that makes you able to see and breathe under water anyway ). So as long as the your equipment uses the same technique you can check what the player has equipped to figure out which state the variable should be in. Here's a version pf your initPlayerLocal.sqf that supports multiple types of diving gear, you just have to fill the _goggles with the correct classnames. private _goggles = ["G_Diving"]; private _equipped = goggles player; private _index = _goggles findIf { _x ==_equipped }; scubaEquipped = _index >= 0; If you use a mod that defines diving gear differently you might need to use a different command to get the value for _equipped. Solution 2: Client-side saving initPlayerLocal.sqf scubagear.sqf loadoutgear.sqf Solution 3: Server-side The drawback with doing it client-side is saving cannot be reactive that if a player leaves before the mission ends and rejoins as JIP after the mission has ended and been restarted, there's no way to for the client alone to tell the difference between the sessions. As Mando would say; This is the way. ... more coming soon ...

Correct

All publicVariable does is broadcast the current value of the provided variable. So what's currently happening is: 1. ShowGlobalAction starts as undefined (nil) 2. publicVariable sends the nil value to/from the server. 3. Line 2 assigns ShowGlobalAction to false which hides the action 4. The network update to/from the server arrives and overrides ShowGlobalAction to nil again, revealing the action once more. So reverse the order and call publicVariable after the assignment is done. Edit: To be more efficient the trigger should be set to server only.

Yes, assuming you mean using remoteExec with the JIP parameter set to true. Not sure what you mean here tbh but remoteExec with JIP-param set to false will only ever execute on clients that are connected to the server at the time of execution. The task framework (which BIS_fnc_setTaskState is a part of) is built by BIS to be fully MP compatible. So as long as you set it up right it should sync automatically for you. Not sure if the task modules use that framework but would make sense that they do. Again assuming we're talking about the remoteExec command: JIP = false - use when something only needs to happen for everyone that are present right now. Probably the most common usage (hence it being default). JIP = true - avoid if possible but use when something needs to happen for everyone present and also for any late arrivals. Remember to save the JIP ID and remove from the JIP queue when no longer needed. See wiki for how. JIP = Object, Group or netId - use when something needs to happen for everyone present and any late arrivals but only as long as the given object, group or netId exists/is valid. This is perfect for clientside things like adding interactions to spawned objects; deleting the object will automatically remove the entry from the JIP queue. JIP just means join in progress. As such there is very little difference between a JIP client and a "regular" MP client. Once the JIP-client is fully initiated you rarely treat them any different, if at all. So something like BIS_fnc_endMission which has local and immediate effect you just remoteExec with JIP false. I recommend you check out the wiki on MP locality if you haven't already.

Maybe you already found this but take a look in this thread and see if it helps: 231504-performance-warning-simpleserialization

My bad, broken link - updated to a working one in the previous post and added some comments to the mission. Take a look in there and it should make more sense. On editor variable names Larrow recently explained this perfectly in another thread: For us the important bit is the 2nd part. The object in our case is the area trigger, give it a variable name, e.g. trigger1, which you can then use to access that particular trigger from anywhere in the mission. In the execution example you replace myTrigger with the name you have selected e.g. trigger1: // Replace myTrigger [this, myTrigger, -1] execVM "cleanup_script.sqf"; // with your name, here I also changed the mode. [this, trigger1, -1] execVM "cleanup_script.sqf"; It's good practice (for your own sanity) to use verbose names such as 'cleanupTrigger1' but not required. For full rules and recommendations see this link, variable names given in the editor are considered global variables.

Alright I've got something that should* suit your needs. Since it might be useful for others I've added some options for automatic cleanup and admin control, explore them if you wish. Setup: Save the script into a sqf-file or copy the cleanup_script.sqf from the example mission into your scenario folder. Then open the editor and: Add a trigger covering the area, give it a unique variable name. Add an appropriate 'collector' object to act as the interaction point (or as data holder if using automatic mode). Copy one of the execution examples (see the script header) to the init of your 'collector' and change the parameters to your needs. If you need multiple areas repeat the above steps as many times as you want. Though I haven't fully tested in an MP environment I've done this enough to say that SP/MP compatibility shouldn't** be a problem if you set it up as described. See the full description below for more details: The full source code is here: And an example mission can be found here: Dropbox link * - I am human and I make mistakes. ** - See *.

There probably are scripts out there that do this but what the heck, it's a fun little thing to write up. Now I haven't played Mike Force in a while so just clarify for me a few things (There's also a chance here of changing the behavior to fit your vision) : Do you want it to require manual input or would you prefer automatic cleanup? Do you care about the dropped gear or should it just be completely removed from the game? If user input is required, should it be locked behind admin access or available for all players? Remember to Quote me or mention @mrcurry in your response so I get the notification, otherwise I might take a while to respond 🙂

Do you have something already that doesn't quite work? Where and how are you executing said code? What's the purpose? Context matters.

Use Photoshop... Jokes aside, if there is no road segment you can't add one. Period. Only the terrain tools can do that, so for a proper fix you need to let the author know about the missing road. However since the road surface is visible, could it be that the road is there and just not displayed on the map? My terrain-making-fu is too bad to know for sure. You can check if the road segment exists by: Get in a vehicle Execute this little script in the debug console [] spawn { while { vehicle player != player } do { hintSilent format ["isOnRoad: %1", isOnRoad vehicle player]; }; hintSilent ""; }; Drive around on the road in trouble area. If there is an actual road segment underneath the vehicle you should see "isOnRoad: true". If so it could instead be that nearby objects (buildings, canal walls etc.) are interfering with the driver's pathfinding. Your best bet in either case is to contact the author of the map and detailing the issue. While waiting for a fix, if you really need to get a vehicle through there, here are some possible workarounds: Use waypoints closely spaced together (5-25 m) and limited speed. If you do it right and thread the needle it could possibly get them through but it likely won't look good if that's important. You could also use setDriveOnPath to guide the vehicle through the troublesome sections. If you are looking for something more cinematic you could use unit capture / play. P.s. while you're at it tell 'em to fix the textures on them buildings. I'd go blind driving around in there. 😛