mrcurry

Looks like copying between forum posts added a few "ghost" characters in my last edit, I've updated the code in the previous post so either remove those spaces or copy the code again.

A way you could get around this: Display the name of the player and the type of unit they occupied at the time e.g. "Johnny (Rifleman) - 69 kills" or "Johnny (Machinegunner) - 420 kills" or even "Johnny (T100 Varsuk)" if in a vehicle. To get this working you just need to change how the name is fetched in the MEH to one of these: // Retrieve the name of the unit and the unit type private _name = format [ "%1 (%2)", name _instigator, getText( configFile >> "CfgVehicles" >> typeOf _instigator >> "displayName") ]; // Retrieve the name of the unit and the unit type if unit is on foot or vehicle type if unit is in vehicle. private _name = format [ "%1 (%2)", name _instigator, getText( configFile >> "CfgVehicles" >> typeOf vehicle _instigator >> "displayName" ) ]; As for "elPresidente" you could just handle him in the original MEH as well like so: initServer.sqf - Note the extra global variable at the top. missionDebriefing.sqf: Yes, the variable is declared as a local variable and is only available within the same scope (curly brackets) it was declared, hence we have to move it out into a global variable like I did above.

Sort of, while AI are given a randomly generated names player controlled units are named after their controlling player's identity a.k.a. the profile name. If an AI controlled unit is taken over by a player the unit's identity shifts to the player's identity, so what you see is your unit's 'original' name. You could fake it by generating a random name if the _instigator is a player but I don't see why you would want to. Surely the point of displaying highest kills is for people to know who it is. A random name will just hide who scored highest and make it seem like an AI always does best. Often they are the same but in certain cases they differ. For example if the shooter is in a vehicle the instigator is the one who pulled the trigger while the _killer is usually the vehicle commander if I remember correctly. Generally _instigator is better at saying who should be awarded the kill (from a gaming perspective).

No, and just to rub it in we have debugLog which from the biki sounds like it could do it, if piped correctly, but it's ofc non-functional in the retail...

No worries, MP compatible code is seldom straightforward. Here's what should be a working example (don't have access to game right now so untested). If any questions then ask. In your initServer.sqf: In your missionDebriefing.sqf clear the chatGPT garbage and put this:

I'm not surprised, it's a mess... like it's probably the worst attempt from chatGPT I've seen so far on this forum, but I'm not here to dunk on language models. I'm deffo more of a "teach a man to fish" kinda guy so here's the gist of what would be my approach: 1. Use initServer.sqf to setup a hashmap to store kills by name and make sure it's accessible globally (in missionNamespace). The kills value should start at 0. 2. Use initServer.sqf to add a EntityKilled mission event handler (MEH). 3. In the MEH check if the killed entity is of side opfor (or w/e side you have as the enemy), then check if the instigator is of side blufor (see above link for example how to correctly get the instigator), if both are true then a. Fetch the instigating unit's name b. Get the kills to that name from the hashmap we created in step 1, remember to default to 0 if not found. c. Add 1 to kills and set the new value into the hashmap, remember to again use the name as key. 4. At mission end trigger a script that: a. Create an empty array for sorting b. Loop over each name in the hashmap and forEach name makes a pair of the kills value and the name with the number of kills being the first of the pair. The pair is then added to the sorting array. c. Sort the array in descending order. d. Select the first pair in the array. e. Format the pair into a string of text. f. Hint the text for all players by using remoteExec. I've marked relevant commands and terms for each step. You can search on the biki for more info if you feel like writing it yourself or, if you are feeling lazy or get stuck, I can write up an example for you.

It is definitely applicable, especially what Larrow wrote which in essence is: 1. Define endings in CfgDebriefing for outcome, end_win and end_lose. 2. The server monitors the game conditions and when the appropriate end occurs the server broadcast end_win to the winning side and end_lose to the losing side. A good place to start code this would be initServer.sqf The key is to use BIS_fnc_endMission in combination with remoteExec. Any questions just ask.

On their own scripts rarely cause "access violations", they run in the script engine which should catch errors without crashing the game. Of course this could be a weird edge case but your script has no loops and ends as soon as all code has executed, likely long before the unit dies. Are you sure the problem occurs only with this script enabled? If No: Keep testing more things in isolation, shut down systems in broad strokes and refine the search each time you test, it's a lot of work but a sure way forward. If Yes: Since the problem happens sometimes it is more likely to be one of the items or identities that are the root cause. It may be a bug in one of the mods you are using... The only code where you have any randomness involved seems to be the in the selection of identity. To find out which unit, items and identity are causing the problem you can try add event handlers for hits and kills to print out which are involved. This is of course assuming the death is actually the trigger. After adding them try forcing the crash and then check the log file, unless the crash happens the same frame the unit dies the last entry in .rpt before the crash message should contain your culprit, just check the timestamps to make sure. Put something like this at the end of your script to get the debug printouts, just remember to remove them before release 🙂 As a side note: You also seem to have some rogue Unicode Characters (U+FEFF) on line 195 and 197. Could be an artefact of the forum formatting and probably not relevant but worth cleaning out anyway if you have them on your end.

You say you verified so I assume it's the steam version you are running. It seems unlikely but just on the off chance... you haven't tampered (hacked/cracked) with the game files have you? 🙂 Same for the server? Arma DRM was notorious back in the day 'cause it could shut down random features if it thinks it's been hacked, not sure if that's still a thing but you never know... A more likely reason: are you running any editor addons? That could be inserting stuff into unit init's and would explain why Zeus stuff works but editor placed doesn't.

A couple of clarifications: How does the mission end, what does it look like, what happens and in what order? How and under what circumstances do you end the mission? Describe (technically) all possible endings When you say it works in singleplayer do you mean the editor or as a singleplayer mission launched from the menu? If you can upload the raw mission with a required dlc/mod list so we can help troubleshoot.

Well what @pierremgi posted is an event handler, it only runs whenever a Entity is created. Spawning units is relatively resource intensive, so is deleting them. Hence why this hack isn't the best solution. When you mention the specific numbers of 244/255 units though the limitation is likely not the number of units but rather the number of groups, which is hard-capped by the engine at 288 per side. Maybe there is some groups not being deleted when empty? Here's the thing: If you want each unit to act completely independently then you need 1 group per unit but if you want more units you need to squeeze more units into each group. The trade-off is that they will act as a group. For an RTS style mission/mod this is a challenge to deal with. Limiting resources or scope can help but at the end of the day Arma 3 was not built for that amount of active units with such a high level of detail. You got to remember modern RTS games have very simple models or other geometry and use fancy shaders and other tricks to make things look good and run smooth with a metric f*-ton of units on screen.

Are you referring to where you put finished missions you downloaded OR are you looking for the editor's scenario folder (where missions you are working on are stored)? Not very familiar with mac so no idea on the former (nor is this the right subforum to ask) but the later should in theory be accessible through the editor > top-left menu > Open scenario folder.

There is, { !isPlayer _x } count allUnits. You cannot prohibit spawning globally no, possible hack is to delete them after spawn but this can turn quite bad for performance. On top of that the script that spawned the unit may rely on the assumption that the unit exists and deleting it early can be another whole can of worms... If you can't figure out the spawn code yourself your best bet to stop the unnecessary spawning is to contact the original author(s).

With the amount of information you have provided we can only give you rough ideas. Why delete after spawn, that's incredibly wasteful. Just prevent spawning when the.number of AI gets too high. This can be done by storing each spawned unit after they are created and then before spawning new units count the number of living left and compare with your limit. If you absolutely have to delete after spawn well, the idea is the same, you count the living and check if the newly created unit should be removed... but again this is not a boon to performance. If you want more help you'll have to provide more details on how your units are spawned.

Also read the notes at the top of https://community.bistudio.com/wiki/setAccTime

Just off the top of my head: If you're working off an existing script (that you don't want to change) and a combined list is all you have access to. If you using something like nearObjects to fetch and want to do different operations on triggers and other objects. If all you are doing is both combining and filtering then maybe rethinking the design could be beneficial to save on perf, but sometimes you just gotta work with what you got.

Editor placed triggers inherit from EmptyDetector. Ofc this assumes _trigger is an object, passing something else will throw an error Use isKindOf: if ( _trigger isKindOf "EmptyDetector" ) then { //trigger-Stuff } else { // not-trigger-Stuff }

What module would that be? Is the plane created by the module and if so, is it an actual flying AI controlled plane?

I assume you checked that your input _this is the plane and not something else. While you wait for 2.14 try using both and the ASL variant like so: aircraft flyInHeight 500; aircraft flyInHeightASL [500, 500, 500]; If that still doesn't work just try with a vanilla jet to be sure.

Last I checked I had working scripted artillery in PF, both fired and spawned, so it should be possible. Since the classes you said are working are magazines check the PF classes are too, just so you aren't accidentally using ammo classes. With PF loaded they should be found in configs CfgMagazines and CfgAmmo respectively. Need to see code on how you "fire" the projectile to be more helpful. If certain sounds happen while tabbed out the game can queue them to be played when you give the game focus again. Not sure but I don't think there is much we can do about that other than lowering your sound fx settings in game. EDIT: Check if you have the startup parameter -nopause enabled in the launcher, could be a possible culprit. However it is not normal behaviour for a warning or error to be played often enough for this to be a mayor problem. There is obviously some kind of error generated multiple times while you are tabbed out, fix the error (if possible) and your issue should go away. Do your hear a similar but quiet sound while working in the editor? Try figure out why and if that could be the cause. If you can't catch the error in-game they are usually printed to the log files as well. Best of luck!

A slight but important correction: round does not round up, it rounds to nearest whole integer. Using round X where 0 <= decimal (X) < 0.5 will cause it to behave like floor. ceil always rounds up. Yes, you no longer have uniform chances for each possible value and the possible max value increases by 1 floor random 10 has a possible and uniform range of 0-9 (10 possible integers). All with equal chance of getting picked. round random 10 has a possible range 0-10 (11 possible outcomes) and the extreme values 0 and 10 are less likely to occur. My gut says about half as likely as all other outcomes but I may be wrong, probability is hard. It's essentially the same as using floor and no -1 but with a non-uniform distribution, as I explained above. Basically if your working with indicies for arrays and you want an even spread always use floor. If you do want an uneven spread and proper control either use the alternative syntax: random [min, mid, max] or work with weighted randoms instead. See selectRandomWeighted for more info on that.

Well you haven't described the symptoms yet, just your setup... But yes. 🙂 If it works in SP/Host but not in MP/clients the most likely culprit is locality. There are good pages on the biki for that but the TL;DR is this: As a general rule in MP the game doesn't want to send all commands over the network unless it has to. In some cases it doesn't make sense to do so (example UI elements) in other cases it just simply better performance not to. So SQF commands are designed to have their effects happen either: - locally: only on the PC that executed them - globally: on all PCs connected to the server (there are other variations but not important here) When writing script for a MP environment you need to consider where (which machine) the execution starts on and who will receive the effects. addAction has local effect, you get that info from the EL icon at the top of its BIKI page. Makes sense since it's a UI feature. That means the action gets added ONLY on the PC that executed it AND the same goes for the attached script when the action is activated. Hope that helps!

Bit late to the party but to give you a jumping off point, if you wanted to write it all yourself, the code in the spoiler should have all the required pieces just not in the right order. 😉 Have fun!

Curious which one would be cheaper... Not that that's a major concern at default trigger intervals.

Multiple ways to do this but my favourite "good enough" method uses the titleText command. 1. Create a file called "initPlayerLocal" in your mission root folder, make it a .sqf file 2. In it put the following code: private _titleString = "YourTextHere"; titleText [_titleString, "BLACK OUT", 0.01]; _titleString spawn { sleep 1; // Change this number to however long you wish the effect to stay before starting to fade out, recommend atleast 0.1 s titleText [_this, "BLACK IN", 1]; //Change the 1 here to however long you wish the fade in to take }; Since v1.74 titleText also supports StructuredText (color, alignment, images and other fancy stuff). If you wish to use those edit the text above by adding 2 true entries to the array of arguments for both titleText entries like so: // First one titleText [_titleString, "BLACK OUT", 0.01, true, true]; // Second one titleText [_this, "BLACK IN", 1, true, true];