Freghar

Could you please change the groupID Eden attribute (when setting group callsign) to insert setGroupIdGlobal instead of setGroupId into expression, to make it MP-compatible? It would be awesome if the lobby screen could read this attribute's value as well, but that could take more work. Thanks!

Hello, I use a simple loadout modification logic performed on any unit (editor-placed or spawned mid-mission) using the init EventHandler. When I however removeBackpack _this; _this addBackpack "I_UAV_01_backpack_F"; (or any backpack for that matter) from init EH, I find this backpack on the ground below the unit when the game starts, with the unit wearing the default backpack.This can be likely attributed to something calling addBackpack after my init EH, but as this is reproducible even on vanilla game with a very simple mission, I can't think of what that would be. Happens in SP (editor preview) as well.Obviously, can be reproduced only with units which have backpack by default, ie. B_soldier_AAR_F. Doing the code above in a scheduled environment works, but is obviously bad as it breaks MP setups - the init EH seems to run on the server and if I was to defer the loadout modification using spawn, the unit could change locality to its player client mid-execution. I use CBA's "init" EH, but this seems to be reproducible with Mod-based config.cpp init EH as well, without any other mods. Any ideas, please?

Probably - I always try to distill the issue itself to what's important, so that people don't have to go reading thousands of code lines to understand the big picture, though sometimes this oversimplified example gets misunderstood as my actual use case. :( Using remoteExec would indeed work, it's just that doing locality check or remoteExec of each individual command is kind of annoying when the idea was to use essentially exported arsenal loadouts. I might just go with the spawn approach and specify that it's dangerous for playableUnits, but still generally useful for the rest (ie. AI units). I've spent about quite a few weeks on this particular part so yes, I've tried many different approaches and this one seemed nicely non-intrusive, efficient and usable at time == 0. Well, until I found this. I'm used to solving hard programming problems, it's just that usually I can see the source and send patches back, except ... well, I obviously can't do that with the Arma engine. Anyway, thanks for the help. Yes, I know it makes sense if you oversimplify it like that. Please let me use an analogy to better explain; Imagine that the NT kernel (Windows) crashes when it receives any multimedia key press. Let's say Windows refuses the fix the issue, because a "keyboard" is something out of its scope as an OS and it works fine with all the standard 1990s keyboards they have. However XYZ media player developers really want users to be able to use multimedia keys found on some keyboards, yet they get a reply that that's something not possible with stock Windows and if they really need it, they should mod the NT kernel. All this discussion however hides the real fact that multimedia keys are really just regular keycodes and there's no reason for the kernel to crash on them, so there's actually a real bug (or "undocumented feature") that's being refuted because the original use case is outside the bounds of what Windows supports. I realize it's impossible to support / add features for whatever crazy schemes others come up with, but am I wrong for viewing Arma as a "library" to base development on? Shouldn't this library be then consistent with its workings or at least document the weird cases which cannot be easily fixed, even if the workings are mainly used by foreign content? You can either load the loadout before the init EH (great for me) or after the init EH (destroying my use case), I'd be fine with either as there was no guarantee of order to start with, but splitting gear load across the init EH really seems like an inconsistency worth fixing (if it can reasonably be done). Or declaring that it cannot be done because it's an ABI set in stone.

Thanks for the effort, but that unfortunately has the same problem I mentioned before - when a player joins in progress, the code (removeBackpack + addBackpackGlobal or whatever other code) races with the locality change of the new unit (if a new unit was spawned for the joining player).This wouldn't be an issue if all the commands used were AG+EG (as they would just continue running, regardless of locality), but commands like addPrimaryWeaponItem (and others I need to run with the backpack code) don't have an AG variant. So the script needs to run completely on either the server or the JIP'ed client. This conflicts with the "spawn" as spawned script can run alongside the server->client unit transfer and the locality can change in the middle of the script. That's where unscheduled environment comes in as I can just load the loadout (incl. backpacks) fully in the init EH on the server and the unit won't be transferred until all the code has run. This works perfectly in theory, .. except for this backpack "bug" as something is trying to add a backpack after I'm done with the loadout from the init EH (unscheduled).

But the point wasn't in the actual full complete code or how I use it, the point behind this thread was that there's an inconsistency between backpacks and the rest of the unit gear w.r.t. init EH and this can be reproduced using a vanilla game. The /fix/ would be to either modify the loadout (engine-side) before or after the init EH, not split across it in this way.

Because I would need to to pick an arbitrary number and state "I think that this should be enough", it may work most of the time, but is not a reliable way of doing things. Essentially it's a band-aid on race conditions.(Exceptions exist, to cases that are outside one's control, like waiting ~2 seconds for BIS_fnc_showNotification.) It wouldn't really help much in my case anyway - for playable units, the init EH still triggers on a different client than the script would need to run, even if I put sleeps everywhere.The "useful sleeps" would be just deciding how long can there potentially be between an init EH and a Local EH before the script considers the the unit being spawned ingame (and not as a result of a JIP player) and restore my backpack. As mentioned, I'm using CBA_fnc_addClassEventHandler because this all is a mission (framework), not a mod, unfortunately, and there's currently no way of doing this in vanilla game (no EntityInit mission EH, in contrast to existing EntityRespawned / EntityKilled).(The full thing is at https://github.com/CntoDev/template/tree/0964053642d/features/Custom_Factions, essentially a system to define loadouts for unit classes, enabling one to define player and AI loadouts, per-mission. The backpack config bit was a simplified example as this "bug" happens only with backpacks.)

Thinking about it a bit more - there's actually no clean (sleep-less) workaround possible if one wants to support join-in-progress. Because even if the EH is added in postInit and the logic is called separately for allUnits, after all units are on their respective clients, the original problem persists for JIP; init EH still fires on the server, followed by (few ms) transfer to the client. This could potentially be caught be the Local EH, but not really as both init EH and local EH can be (and are) used independently: init EH can trigger for units that won't be transferred and there's no defined point in time of a running game where we could detect it, we would have to blindly sleep local EH can fire for a simple headless client locality change mid-mission, no units created if we set some state variable in init EH and expect it in local EH (or register local EH from init EH), it can trigger false positives - AI unit spawned on the server, moved to a headless client few minutes after And since there's no "unit spawned for a JIPed player" flag passed to init EH, it cannot possibly know what the unit is used for. Similarly for local EH. Even if we would use the arguments passed to local EH and check if the client JIPed, it has no indication of whether the client just entered the game - the local EH might have fired minutes after a headless (or any other) client JIPed into the game. Fixing the backpack on the engine / BIS side is the only solution I can think of.

Sure, thanks, as mentioned - I use CBA_fnc_addClassEventHandler in the real code, this was just a quick-n-dirty reproducer.

Simple reproducer (for anyone interested); create a mod with class CfgPatches { class TEST_init_eh { units[] = {}; weapons[] = {}; requiredAddons[] = {"A3_Modules_F"}; }; }; class CfgVehicles { class B_Soldier_base_F; class B_Soldier_AAR_F: B_Soldier_base_F { class EventHandlers { init = "_this = _this select 0; systemchat str _this; removeBackpack _this; _this addBackpack ""I_UAV_01_backpack_F"""; }; }; }; and start the game with it, go into editor, place down Assist. Autorifleman, hit preview. You should see the added UAV backpack on the ground, with default backpack on the back.Modifications of the rest of the loadout work fine, it's just the backpack. :(

Yes, that's the whole point - execute the EH before the simulation (mission) starts, so there's no additional ingame overhead. Doing any extra work via init lines is also exactly something I wanted to avoid as it would be very tedious for >100 units and multiple missions. My current workaround is to defer loading for time == 0 to a postInit function - doesn't work for JIP save loadout via setVariable onto the unit after I changed it hook the Local EH (as the last place on the server) and restore the loadout there, assuming Local EHs get to run before the actual transfer spawn waitUntil in case the unit isn't transferred away, restoring the loadout "some time" after (possibly when time > 0), or iterating over all units in a postInit function, looking for saved loadouts, restoring them This is kind of very ugly to do, but is the only reliable way I can think of (no race conditions). Would be really great to find what's causing it though, it's not anything in functions_f*.pbo, so is it an engine thing? Maybe backpack loading was accidentally added after init EH, contrary to other gear?

Good idea - no, it happens only on mission init, createVehicle / Curator-spawned load correctly my backpack with nothing on the ground.

Any documentation on how to use it would be awesome, so we don't have to reverse-engineer it and create urban myths in the process. Does it use the server profile for preset definitions? Not saying it has to be done NOW, just eventually is fine. :) Thanks for adding that.

That could actually be possible even without rewriting the memory management to 64bit, there's this thing called AWE, which essentially allows a 32bit process to address many "ranges", mapped onto some part of the 32bit space on demand. It is kind of similar to the (presumably) current file mapping system, except that you don't read mapped files, but reserved memory, which cannot be paged out. The former can be theoretically cached in RAM and that's what Linux does (on a LRU basis), but my benchmarks showed that Windows is much more .. conservative .. and doesn't make use of free RAM as a page cache (to the extent Linux does). So yes, if you don't own a super fast SSD and assuming the texture loading code would be optimized for it, using AWE could bring its benefits. Actual tests needed, though. The main drawback, however, is that Arma could then indeed use huge amounts of memory (which is currently not the case, contrary to what some people claim), even on systems which don't have it (ie. 2GB RAM total) and thus crashing. The rest would probably benefit.

Exactly, but that's also a feature I would very much appreciate - it would allow others to easily edit my mission (re-using the compositions) without me having to provide compositions separately, with instructions where to extract them (user profile). I know there's a planned steam workshop support for hosting compositions, but steam workshop is not the only way to distribute missions. :(

That doesn't really work - player is always going to be in playableUnits. Thanks, I did consider that, but it seemed like a heavy solution to a simple problem. Still better to copy a state variable between two sides than export a publicVariable to everyone, I guess.

Hello, is there any way to determine if a player Joined In Progress into a slot which had "AI Enabled", therefore joining as an existing (AI) unit, not spawning a new one? I know I could use the missionConfigFile command to get global disabledAI value, but I don't know how to do that per-slot when disabledAI=0. One way would be to set some variable for each existing playable unit at a mission start, however that wouldn't persist through respawns of that unit + would need to be a publicVariable (which is what I'm trying to avoid). Is there something simple like didJIP for checking if a new unit was spawned on JIP? Thanks.

Note that there are some issues with respawning players, the first one being related to the ACE3 compatibility feature - the action menu item is added after respawn. This seems to be because the code doesn't check for ACE on respawn (when removing action from the old body & adding it to the new one), the following fixes it: http://pastebin.com/yBq6fG9a The second is trying to set view distances when TAW is supposed to be disabled (tawvd_addon_disable = true;), causing script errors on undefined variables. The following is really a hack as it should be solved using the state machine, I just didn't want to install the FSM editor, so I hacked it up in a notepad: http://pastebin.com/s5bZa3rf (Using pastebin instead of code tags here as these forums don't support syntax highlight for diffs.)

Neat tip: To easily make mutexes / semaphores in a scheduled (can sleep) environment, use the pushBackUnique command, which is an easy alternative to the more common compare-and-exchange instruction you'd find in many CPUs or interpreters. The key here is that pushBackUnique is a single scripting command (seems to be an atomic unit for the engine) and returns -1 if the element is already there or its new index if not. So given an empty array as a starting lock, if you try to add a single member (ie. a digit 1), you can get 0 (index, you got the lock) or -1 (somebody else was faster). _acquire_lock = { waitUntil { (_this pushBackUnique 123) == 0 }; }; _release_lock = { _this deleteAt 0; }; _lock = []; ... _lock call _acquire_lock; ... do work ... _lock call _release_lock; The code above could be easily enhanced with canSuspend to work in unscheduled environment (cannot sleep) as well, returning ie. 'false' if the lock couldn't be acquired.This could in theory work reliably with publicVariables, but I haven't really stress-tested it to see how the uniqueness check works across network. Note that while the engine doesn't currently execute more than one script at a time, it can cut off a script in a scheduled environment at any single scripting command, raising the need for proper mutexes if multiple scripts perform conflicting actions.

That's why I do use "doWatch", the "commandWatch" was from a quoted post. I kind of figured it was something similar as it seems to happen only to units which have already "acquired" a target and cannot get rid of it even through doWatch. If I don't disableAI, they just keep shooting, ignoring any movement orders (despite being in AWARE/SAFE/CARELESS/..), so having an ability to flush the target list could help immensely. I was wondering a bit why there's no "forget" command in addition to "reveal".

I can confirm the desync on setGroupOwner as well, although it seems to produce only a very slight lag for a second. It's the "red chains" that remain for up to 30 seconds. Again, stable branch since at least 1.50, when moving curator-spawned units from player to server. Doesn't seem to happen on player disconnect though, so it may be tied to the command itself.

Thanks for the sequence, it seems to work better than what I did: private _grp = group _this; { _x disableAI "AUTOCOMBAT"; _x disableAI "AUTOTARGET"; _x disableAI "TARGET"; _x disableAI "COVER"; _x disableAI "SUPPRESSION"; _x disableAI "FSM"; _x setUnitPos "UP"; _x doWatch objNull; } forEach units _grp; [_grp, currentWaypoint _grp] setWaypointForceBehaviour true; with the waypoint set to AWARE / FULL. This code is actually an "updated" version of an older one, which set behavior properties manually on the unit.The problem is that both of these code blocks seem to work well only on units which haven't entered combat. If you try activating them on suppressed units in COMBAT, ie. with an existing waypoint active, some (almost all) of the units get stuck. They just stand in place as if AI was completely disabled (allowDamage false) - http://i.imgur.com/JtHvTcE.jpg . This was mentioned in multiple old threads, but nobody found a good solution to it and neither did I - it seems to happen for any disableAI command, but semi-randomly. With the first code block, the unit(s) eventually get unstuck, within 60-300 seconds, but by this time they would be long dead. I tried just about everything to make them unstuck, but nothing seems to work - even doMove just makes them raise/lower the weapon. switchMove "" does nothing. The units aren't stuck in an animation or physics simulation, it's the AI that seems to be temporarily stuck as if MOVE was disabled (enabling it does nothing). Doing enableAI on all supported types also doesn't help. To reproduce: place a NATO squad and a CSAT squad, about 100m away, name them, make all units immortal configure game master, so you can see what's going on use init.sqf or game logic init line to assign all units under that game master start the game, watch groups fire at each other, give it a few seconds make a waypoint (via curator) for one of the groups, watch nothing happening, both units in COMBAT configure the waypoint for AWARE / FULL via curator execute my (second) code block on the chosen group, by variable name watch as all units stand up and do nothing (executing the first code block makes all but 2 units freeze, the 2 units behave as they should - fleeing, after some time, another 2 units unfreeze, etc.)There are other ways of making groups flee (allowFleeing, setting courage to 0, etc.), but none of them are really effective for making units aggressively retreat under fire.

Which basically means it's the same. :) (See original post.) Strictly speaking it's not the same, BIS_fnc_*Inventory doesn't store the loadout as the variable itself, it uses a hardcoded "bis_fnc_saveInventory_data" variable, which (IIRC) is an array of [name, loadout, name, loadout, ...] where "name" is the loadout name given to the function. This confused me a lot when I was checking for isNil on the "name" and it always matched. :)The new approach via scripting commands is infinitely better. With the new (today) option of taking a class name, it's nearing feature parity with the BIS functions. In some limited form, yes, it seems to be working well for me. I saw it first here - https://forums.bistudio.com/topic/151099-scripting-discussion-dev-branch/page-43#entry2990022, though note the comments below it.

Yes, except it actually works now (for weapon attachments). :) Even on stable, just undocumented. I have a feeling that it "modifies" just differences, not remove all + add saved as the other solutions - based on my observations of inventory item ordering. This could be an issue for mods that rely on a specific item order (ie. ACRE2 and multiple radios), but otherwise seems fine.

+1 for frag/smoke separation - again something done by ACE3 (and was AGM, I believe), incredibly useful thing. I might even give up on Spacebar being weapon switching for me (has been since OPFL). :D

I can definitely confirm the dismount thing, although it seems to happen only after some mission runtime, it's not 100% reproducible. :( Also, there seem to be multiple "levels" of /break-ness/ here - at the first level, moving (dragging) the unit back to the vehicle works, but after some time, the unit keeps getting out. Around that time, the Curator is unable to Directly Control units - it can see "through" the eyes of the soldier, just the movement/actions are AI-controlled. Also, dragging any air units via alt-drag doesn't make their engines start immediately, causing them to fall and crash. Again, these cannot be immediately reproduced, but if you hook the CuratorPlaced EH and transfer any newly placed units (setGroupOwner) to ie. ID 2 (server) and give it enough playtime (30-60min), these issues pop up. That is, in addition to the usual easy-to-reproduce limitations like the Curator not being able to change formation or group properties if the group isn't local to it. Reproduced on Stable (1.56).