mrcurry

I believe this is the crux right there, Resume essentially loads a save, so I imagine you can try to use the Loaded eventhandler to reapply the time of day.

How to turn any array into a shuffled deck in 1 line. Nice. The brackets shouldn't even be necessary since floor random and count are all unary commands.

Yeah that fits the bill with the other issue I mentioned but as long as the object structure is static it should be trivial to deconstruct/reconstruct the references manually. P.s. out of curiosity what possessed you to do pointclouds in sqf? 😛

The key in this case is a string, "a" or "b" are very hashable. The stored value is the reference to the first HashMap. Nesting HashMaps like this is very useful for quick lookups of complex nature. Example: You have some thing that doesn't support setVariable, you can use nested hashmaps to replicate similar functionality where the lower level contains "variables" and their values while the upper level acts as a registry for each "thing". The lower level keys can be shared across multiple things which means easy to use and value lookup is fast even with massive amounts of objects with a lot of variables. And to clarify: This works fine during runtime. This is only a problem during save/load of a mission. A bug report is also a way to get verification if it is or isn't a bug. 🙂

Honestly seems like a bug. Good find if so, I wonder does it only happen when 'm' is empty? Or if it's not a missionNamespace variable? Last I checked loaded HashMaps doesn't retain group or object references either, unlike arrays. My guess is the serializer doesn't know how to handle them properly. You should post it to the Feedback Tracker but I wouldn't hold my breath for a fix expect a fix. It's quite a niche issue and you can work around it by converting HashMaps to arrays on save, then use the Loaded eventhandler and createHashMapFromArray to rebuild.

setVehicleCargo only works with certain combinations of vehicles and cargo. As an FYI, for the command to work the following must be true: The vehicle needs to have a defined capacity ( mass and volume ) The cargo needs to be defined with appropriate values for the same. The cargo must no exceed the capacity of the vehicle. You can read more details here but to summarise that's all defined on the config side so as a mission creator at best you can test the combination using: vehicle canVehicleCargo cargo Note that the returned value is not true/false but rather an array of Booleans: [ willFitIntoCurrentVehicle, willFitIntoEmptyVehicle ]

From HandleDamage wiki: From the explanation thread linked on the same page: With your current setup you are setting the damage for the selection to 25% of the resulting damage level, hence the healing effect. AFAIK the event handler executes before the damage is applied, if true you need to subtract the current damage (getHit) from the damage parameter to get the delta (incoming damage). Multiply that by 0.25 to get the reduction and add the current damage back to get the modified resulting damage level.

When you switch it's side also use: unit setCaptive true; Then when you want it to be shot at do: unit setCaptive false;

Don't remember how Mike Force does it exactly but I'm pretty sure it involves the interaction wheel-feature. Here are steps to reproduce a similar functionality using actions instead: Identify when a recoverable vehicle is destroyed, see addEventHandler and EH Killed. Add an action to the wreck to do the following steps, see addAction Get the type, position and direction of the vehicle, see typeof, getPos, getDir Delete the wreck and replace it with a container, see deleteVehicle and createVehicle Store the type of the wreck in the container, see setVariable (Optional) Add an action to see what kind of wreck it is, see addAction. That's it for the packing. For recovery: At your recovery point add a trigger to continuously check for containers which contain a vehicle, trigger should detect Anything Present and it's condition need to filter for only wreck containers, see triggers and getVariable, thisList When the trigger activates get the type of the first container, see getVariable, thisList Delete the container and replace it with a new copy of the wreck, see deleteVehicle and createVehicle Reapply the event handler from step 1 of the packing process to the newly created vehicle If you got any further questions or need some code examples just ask.

Animals are agents (simpler version of units) and cannot be the target of an action. Best bet is to put the action on the player and in the condition check cursorObject is the required thing.

So shortcut it is. All the launcher does to launch the game with mods is to set the -mod startup param. We can do the same in many ways, but the easiest is probably using shortcuts. That's the way it used to be done, way back before fancy launchers and workshop-support. 😛 Browse to your game's install location. From steam: Open steam library -> Right-click the game -> Manage -> Browse local files. Locate the mod's installation folder and its relative path compared to your arma3.exe. If it's a workshop mod it's located in the hidden !Workshop folder, if you can't find your mod in there the launcher probably hasn't finished installing it yet so just let it do that first. If it's non-workshop then only you know where you installed it but inside your game's root folder starting with an @ is the recommended approach. Create a shortcut to the arma3.exe. Right-click the Shortcut -> Properties -> Shortcut-tab At the very end of the "Target" field add: "-mod=<your mod path>" For example: If you want to launch with multiple mods you can chain them together like so: "-mod=<mod path 1>;<mod 2>;<mod3>" Here I'm launching with Prairie Fire (vn) and 3den Enhanced: Launch the game by using the shortcut and verify the mod has been activated by looking in the lower left corner of the main menu. Using this method you can definitively launch as many instances of Arma 3, the only limit is how much hellfire you want to create on/underneath/near your desk.

Something like this: TAG_react_condition = { !(_this in [group unit_name_1, group unit_name_2]) }; Edit @RS30002 A better way is to do this: TAG_react_condition = { _this getVariable ["react_to_explosions", true] // Check the group's setting, by default all groups react }; and in group's init (Attributes for the group/collection): this setVariable ["react_to_explosions", false]; // Disables reaction // or this setVariable ["react_to_explosions", true]; // Enables reaction This way you do not have to list every group that should ignore it, instead you can control everything in the editor without having to do additional changes to code every time you add a new group that shouldn't react. This also allows you to turn it on and off at will, for example when the group reaches a certain waypoint. You could also add interesting behaviours by checking against the skill of the unit, make more "disciplined" units stick to their post maybe... TAG_react_condition = { _this getVariable ["react_to_explosions", true] && leader _this skillFinal "commanding" < 0.5 // only groups with poor leadership will react };

That's my bad, I missed to reset the "is reacting" flag when they were done with the investigation. They should react as soon as the investigation is complete now, even if they are on their way back to the original position. Also refactored the code a little bit to not run unnecessarily for soldier's who aren't group leaders. I've updated the code in this post. Tested and works. A better approach would be to queue up explosions and have the groups react in a prioritized fashion based on the closest one and spread the jobs about among several reacting groups... but I think the current setup is good enough.

Huh, I was gonna describe the good ol' technique of shortcuts... but that's way simpler yeah 😛 Just remember to set your Launcher options to not close after launching the game like I had...

Not really a mission editing or scripting question but I'd say the same way it's always been done (which the launcher also uses): -mod startup parameter

In short: don't. LLM's doesn't understand the code they write. At best this means they are unable to fix it unless you explicitly state what's wrong. At worst they introduce hard to spot bugs and/or security issues. On top of that you have implicit ownership of, and responsibility for, things you create. No matter which tools you use. If your shit hits the fan it's your responsibility to clean up the mess so you must either understand it or have access to someone who does. If you wish to learn code I'd happily help. There are plenty of resources online, read existing code examples and ask on these forums. If you want something coding related done either do it yourself or ask someone competent like over on the scripting request subforum. LLMs probably have their place in programming but that place is not (yet) helping non-programmers, that's like the blind leading the deaf.

You could just spawn the equivalent CfgAmmo class nearby and send it into the ground using setVelocity or detonate it in the air using setDamage. To find the class you have to do some digging in the configs.

Yes, the tricky part is actually the UI part. You need 5 image UI elements on top of each other and you need to make sure the image resolution matches. Then you just enable/disable the relevant UI elements as you need. Check out docs on the gui editor to get started. For detecting this approach should work: _near = nearEntities [ ... ], filter on base classes like "Man" or "CAManBase" _enemies = _near select {side _x == opfor }, replace "opfor" with your enemy side Loop over all _enemies, for each enemy _x get direction from player: _dir = player getDir _x Check _dir against predetermined sectors, 45 to 135 = east, 135 to 225 = south etc. Just remember to account for north wrapping around zero (left bound = 315, right bound = 45) Enable appropriate UI elements depending on the checks The code could run from the onLoad event handler of the ui or you could build the ui from code too. Let me know if you got any questions.

I double-checked the code and there's no syntax errors on my end. The possible causes I can see are: A - You didn't the copy the entire code B - When you copied it some extra web characters came along for the ride C - You did some changes in the code after copying Considering the error message "Invalid number in expression" and it's position B seems most likely. Finding the solution: Make sure you copied the entire initServer.sqf code. When copying code from the forum make sure you copy only from a code section and only from one code section at the time. If the selection goes outside the code tags it can introduce errors. See the spoiler below for an example. If the problem persists open your initServer.sqf in a competent text editor like Notepad++ or VSCode and look for (and remove) these naughty little buggers:

To expand on Necropaulo's answer: This is specifically a problem when using commands with global effect ( all clients see the effect automatically ) inside trigger code which runs locally on each machine. Every client executes the code which essentially multiplies the effect by # of players. You want a car? Everybody gets a car! If all code the trigger runs has global effect set it to "Server only", there should be a tickbox in the trigger's attributes editor. If you are mixing global and local you need to wrap local effects inside: if( iSserver ) then { ... };

It's been awhile since I worked with displays so maybe double check in your testing but as far as I can remember: Yes, closing the display = destroying it. All event handlers are destroyed also. Using Set is not recommended, it's a leftover from the old days of UI scripting. See the Biki page for more info. It definitely has nothing to do with the lifetime of the event handlers though.

Yes. In On Act. the 'magic'-variable thisList contains the units which activated the trigger.

You're not that far off. 🙂 Firstly you have a misplaced semicolon inside the parentheses. The grammar is: Semicolon ends the statement and all round brackets (i.e. parentheses) needs to be "closed" before the end of the statement. Just don't mistake round brackets () with curly brackets {}. Secondly uniformMagazines et. al. return an array of strings so your _x select 2 just gets the 3rd (yes 3rd, 0 is the 1st) character in what happens to be the mag's name. No Bueno! To fix this without string-magic you can just use: magazinesAmmo player This command gets the data in the format you expect with the added bonus of getting uniform, vest and backpack in one go while ignoring loaded mags. If you needed more nudges just ask. Edit: Dammit @Harzach! 😛

'player' script command returns the player object on the machine where it is executed. This quirk means if we're both connected to the same dedicated server the following would be true: - On my PC: name player == "mrcurry" - On your PC: name player == "trollzor45" - On the server: name player == "Error: No unit" (or "", I don't remember exactly ) Depends on the activation and condition of the trigger. Triggers are evaluated on every machine individually and the trigger's state (activated/not activated) is not synchronized. If you want something to happen at the same time for all machines you have to make sure the conditions in which they activate will occur at the same time across all machines. This will result in a synchronized activation: Trigger activation: Any player Condition: this This also (assuming a player-unit is named 'someDude' in editor): Trigger activation: Any player Condition: someDude in thisList This will not (see aforementioned quirk regarding 'player' above): Trigger activation: Any player Condition: player in thisList Hope that clears things up a bit, if not just ask away.

Huh, wasn't aware of this caveat of the guard waypoint. Pretty neat and simple to setup. However I did some testing and it does seem a bit hit & miss. They'll take a full 2 minutes to react to an explosion 500 m away when there's only the explosion and no known enemy targets. While it's probably realistic, as a player sitting and waiting for them to move, that's tad long since there are no visual or audible cues from their decision making... They also won't move to where the explosion happens but rather stop nearby, and there's seem to be no search when they do arrive like with a S&D waypoint. Since I was already writing up something that acts closer to how I imagined it I'll just post that below. ----------------------------------------------------- It'd be nice if we had a mission event handler for explosions for this but as of today no such luck. So we have to jump through some hoops. Note that from the game's perspective those are 2 very different actions to monitor. That means you have to attack this from two directions. Handle vehicles exploding Handle player detonating an explosive Handle vehicles exploding Add event handlers to all vehicles (including spawned vehicles) Create initServer.sqf in your mission root and fill it with: Handle player detonating an explosive Add event handlers for when a player placed explosive explodes. Create initPlayerLocal.sqf in your mission root and fill it with: