Freghar

Thanks, this very nicely illustrates why I have a problem with people needing to repeat that "AI doesn't see you through grass" - they may not see you initially, but once they start shooting, any tiny opening in the grass completely reveals your position, making the grass seem worthless. I wonder how this works when the AI is simulated by another client/server which doesn't render the grass at that location. This isn't limited to grass or obstacles though, use setUnitTrait to reduce your visibility to virtually nothing, same for audibility, make it night, put an AI soldier under a lamp and walk up until they become aware and start tracking (but not shooting) you. After that, you can go back as far as you want into the darkness, but the AI will keep tracking you with 100% accuracy and if you try to fire your weapon, they will headshot you immediately (seems to be within the same frame). This might be fixed on the devbranch, we'll see soon, I guess. :) For me personally, the biggest AI issue is (nearly?) no penalty for getting hit - unloading half a magazine of 9mm rounds into an AI isn't enough to stop it from turning 120deg and insta-killing you. All subskills at 0.5, default interp. curves, 2m distance, indoors. Even skilled players are easier to kill in CQB sometimes.

Managed to find reliable reproducers for recently introduced movement bugs: when crouching from a standing stance with lowered weapon, the weapon is automatically raised when crouching from a standing stance with raised weapon while turning around (using mouse), the weapon is lowered The latter is especially annoying when you suddenly realize the enemy is behind you, so you crouch and turn, only to lower the weapon and get killed. Neither happens during movement, only when stationary, and occurs only when holding a main weapon.

There are more ways - https://forums.bistudio.com/topic/183993-scripting-introduction-for-new-scripters/?p=3016726 (spinlock essentially). Since that post, I came to an observation that the atomic execution unit of the interpreter is an expression, not a single command, so it likely could be even more simplified.

If it's of any consolidation, the official PBO tools never worked well for me either. They seem to require some P: drive set up just to pack folder contents into a PBO. They *seem* to be working, but if you open/extract the created PBO, there's only the config.bin stub (if packing a mod). I can very much recommend https://github.com/KoffeinFlummi/armake- if only I had known about this sooner, I wouldn't have written my own C-based PBO packer. :)

I obviously use the correct order, otherwise the behavior wouldn't be 100% reproducible. I'm not looking for a particular answer to a particular problem, I'm trying to understand the syntactic and semantic nature of the configuration language, which (to me) doesn't feel very consistent regarding overwriting, hence the first post.

It seems that the number of items you carry significantly affects FPS, which I haven't observed earlier. With 86x 9mm pistol magazines, the FPS as measured by BIS_fnc_fps drops by ~4 (on the VR map) compared to no gear. If you add ie. 10000 SmokeShells via setUnitLoadout, the FPS drops by ~30. Don't know if this is expected (something calculating weight for all items every frame), but it's much more pronounced with some modded items (like ACE3 medical) in much smaller quantities (~400 total = ~50 FPS drop). As far as I can tell, this seems to be on 1.60 as well, was this always the case?

+1 It's a PC game, you don't need minimalistic menus, just let me go straight to Virtual Arsenal with a single click. Or Editor. Or video options. :)

That turns out to be incorrect, SizeA / SizeB does nothing to the default area, despite presumably working for triggers. Using "size3[]" works though. Not really, just my bad code. There indeed is a magical variable named "objectArea" set by god knows what which seems to have the the same format as triggerArea (scripting command).So getting this to work with just elipsoids is pretty simple - set "canSetArea" to 1, optionally set defaults in "size3[]" and check in expression for the "objectArea" variable. class CfgVehicles { class Logic; class testlogic : Logic { scope = 2; displayName = "Test Logic"; canSetArea = 1; class AttributeValues { size3[] = {12, 34, -1}; }; }; }; While the trigger code never needed to specify a default, I apparently had to and with it, this "works" (doesn't throw an error). "ShapeTrigger" is a custom control defined in 3den.pbo, UI/Attributes/ShapeTrigger.hpp, and expects a number, so class CfgVehicles { class Logic; class testlogic : Logic { scope = 2; displayName = "Test Logic"; canSetArea = 1; class AttributeValues { size3[] = {12, 34, -1}; //IsRectangle = 0; }; class Attributes { class Shape { //data = "IsRectangle"; property = "IsRectangle"; control = "ShapeTrigger"; displayName = "Shape"; condition = "logicModule"; tooltip = "something"; typeName = "NUMBER"; defaultValue = "0"; }; }; }; }; The weird thing is that some of the BIS code defines "data" where "property" should presumably be, and "value" (instead of defaultValue?), in 3den.pbo, cfg3DEN_Trigger.hpp. If I use "data", the attribute doesn't show up in the UI.Regardless, this doesn't work - even if I set3DENAttribute ["IsRectangle", true] manually from the debug console, it (get3DENAttribute) still retuns false, so the attribute seems read-only (?). When set in the config (in AttributeValues), it works correctly, but again cannot be overwritten.

Hello, I'm making a logic unit / editor module which performs some action (disabling street lights, etc.) in a user-configurable radius and would like to visualize the radius in with a trigger-like cylinder / circle on a map. There are modules which do something similar, ie. ModuleCuratorAddCameraArea_F (Zeus -> Add Camera Area) and they seem to do it using some combination of (undocumented?): class ModuleCuratorAddCameraArea_F : Module_F { ... canSetArea = 1; class AttributeValues { size3[] = {250, 250, -1}; }; class ModuleDescription : ModuleDescription { ... class LocationArea_F { description = ""; duplicate = 1; sync[] = {"TriggerArea"}; }; class TriggerArea : EmptyDetector { position = 1; area = 1; description = "$STR_A3_CfgVehicles_ModuleCuratorAddCameraArea_F_ModuleDescription_TriggerArea"; }; }; }; However even if I managed to get it working using this method and if "size3[]" is indeed the cylinder size, I have no idea how to change it during "runtime" (outside config, in Eden workspace).I've also looked into triggers, but they are not CfgVehicles (and CfgDetectors defines only one), so I assume the drawing functionality for them is done internally by the engine. Any ideas how to achieve the visualization? Thanks!

Alright, it seems that "size3[]" is an alias (?) for sizeA, sizeB and (?) sizeC in AttributeValues. It also seems there was "size2[]", from CfgNonAIVehicles: class EmptyDetectorAreaR50: EmptyDetector { displayName = $STR_3DEN_CfgVehicles_EmptyDetectorAreaR50; class AttributeValues { size2[] = {50,50}; //--- Obsolete, remove size3[] = {50,50,-1}; }; }; Triggers also seem to be defined in the in Cfg3DEN and the visual magic is presumably done via "class Draw" for both 2D and 3D (cfg3DEN_Trigger.hpp). They also use (undocumented) "ShapeTrigger" control which, when used on a custom CfgVehicle object, after adjusting condition, throws: 22:23:33 Error in expression <(_this controlsGroupCtrl 100) lbsetcursel _value;> 22:23:33 Error position: <lbsetcursel _value;> 22:23:33 Error lbsetcursel: Type Bool, expected Number when the attributes window is opened for that vehicle, probably from some other 3DEN-related code.As mentioned in first post, it's really just the "canSetArea" setting, which automatically adds the 2D area dimensions to the position attributes (kinda like "EditAB" control). Retrieving this value from an executed function seems a bit tricky, all the BIS functions use essentially _logicArea = _logic getvariable "objectArea"; but there's no place setting it. Trying "canSetArea" on my custom vehicle, naming it in the editor, and trying getVariable on it ingame returns nil, so it doesn't seem like some automatic variable, even though no game sqf code seems to set it explicitly.

That's because I recreate the backpack on the chest as a Simple Object - if I did create a full "vehicle", its inventory would still be accessible (and incorrect/reset). I guess it could be perhaps possible to getObjectTextures from the original backpack and setObjectTextureGlobal on the new object, haven't tried it yet, no idea how it could "break the script". Alternatively, somehow disabling inventory interaction with a newly spawned vehicle could also work.

Hello, are there any plans to add periodic remote repo checking / automatic update in addition to the startup-time check? Or alternatively a check before game start? Would be very useful to ensure people are starting the game / joining a server with the latest mod versions. I know there are other launchers that can do it, but they either lack the feature set of a3s or require completely custom metadata and repo duplication. Thanks!

May I ask how does this work now? Is ie. assignTeamGlobal planned? Or does just assignTeam now have a global effect? Do the usual limitations (non-null "player", target unit must be in player's group, ..) still apply? Thanks.

Remove the forceWalk commands in fn_setChestpack.sqf and fn_removeChestpack.sqf.

Well, it's a velocity multiplier, so 1.0 would mean zero slowdown (the default is 0.8) due to the multiplier itself, gravity/drag/.. would eventually slow it down anyway.

As the link above covers most of it, I'll reply just regarding apparent CPU utilization - the vast majority of people measure good multi-thread-ness by looking how evenly is the load distributed across cores. Even many big youtubers reiterate this, but it's a complete bollocks. I can easily make a horribly optimized program that uses 8 cores @ 12.5% and one that performs better with 1 core @ 100%.The reason is that multithreading doesn't equal more peformance, you need to have the program designed to make use of it and in some cases, doing the work on a single core will be faster because of more aggressive register usage and L1 cache hits. To give you an idea (with a very artificial example, I know) of register vs L1 cache ("memory") access, consider the int i; for (i = 0; i < INT_MAX; i++); loop written in C. It iterates over 2^31 values, using a variable to store the current value.The (unoptimized) x86 assembly looks like 400710: bb 00 00 00 00 mov $0x0,%ebx 400715: eb 03 jmp 40071a 400717: 83 c3 01 add $0x1,%ebx 40071a: 81 fb ff ff ff 7f cmp $0x7fffffff,%ebx 400720: 75 f5 jne 400717 You write the 0, then jump into loop of checking whether it's 2^31, if not, jump to the 'add 1' and check again.This program takes about 0.58 seconds to complete on my CPU. Now if I force it to read/write to memory (using "volatile" in C), it produces something like 8048563: c7 44 24 3c 00 00 00 movl $0x0,0x3c(%esp) 804856a: 00 804856b: 8b 44 24 3c mov 0x3c(%esp),%eax 804856f: 83 c4 10 add $0x10,%esp 8048572: 3d ff ff ff 7f cmp $0x7fffffff,%eax 8048577: 74 14 je 804858d 8048579: 8b 44 24 2c mov 0x2c(%esp),%eax 804857d: 40 inc %eax 804857e: 89 44 24 2c mov %eax,0x2c(%esp) 8048582: 8b 44 24 2c mov 0x2c(%esp),%eax 8048586: 3d ff ff ff 7f cmp $0x7fffffff,%eax 804858b: 75 ec jne 8048579 So it writes 0 to memory, then it reads back to a register, compares it to 2^31 (like before) and if it's (obviously) not equal, it enters the loop which, on every iteration, increases the counter, writes it to memory, then reads it back and uses it for comparison, just for demonstration purposes. Instruction wise, it's about the same size (for the loop itself).The program takes about 3.52 seconds to complete, much slower than the 0.58 seconds before. The point is that if you allow the thread to keep executing on one core, it has better instruction and data "locality" and runs more optimally. Doing the same amount of work in a single queue, aritificially switching between cores, produces worse performance, not better. In reality, this won't be so extreme as you'll likely hit L1 cache much more often even in a single thread and L2/L3 in a multicore scenario (shared across CPU cores nowadays), but the point still stands - don't multithread just because it looks nicer in CPU usage meters. You need to have data structures that take advantage of multiple cores. In analogy, it's like having 8 pizza delivery cars, but only using 1 at a time - using the same car is more efficient than using a different one on each trip because the engine is already warm and has more optimal fuel consumption. You can pretend to be a multithreading game by using a different car on each run (and people will applaud it), but you're just performing worse. Obviously, the better solution is to hire more drivers. PS: Sorry for the not-so-relevant examples, I would have provided some actual one-core vs multi-core examples, but they aren't as straightforward in asm to explain as you need to work around the OS CPU scheduler to demonstrate it. PPS: (To answer the actual question :)) no, overall (averaged) CPU usage is not a good metric as it hides over-saturated cores. Looking at individual cores is better, but - for reasons mentioned above - doesn't tell you much about how "well" the game uses multithreading.

It would be doable, but with the same limitation - you cannot (via script) place a pre-configured weapon into any container (or on ground). On the player side, one could use either get/setUnitLoadout (like I did) or primaryWeaponItems/addPrimaryWeaponItem to the same effect. The main problem is visually attaching anything to the player as you would need to constantly rotate/tilt it according to the stance which I don't think can be done efficiently as there's no "stance changed" EH, at least AFAIK, AnimStateChanged could potentially work, but even if it does, it's a LOT of animation states to create the alignment for.. An easier solution (I imagine) would be to make weapons fit the launcher slot, https://forums.bistudio.com/topic/158768-rifle-in-launcher-slot-possible/ . Not to my knowledge, no. Unless the attachments are part of the base weapon class or the weapon was dropped manually by the player. (Or unless using the launcher slot.)

There's currently no nice function for that, so you'd have to do what the ACE action does, if (isServer) then { [this, (this call Chestpack_fnc_removeBackpack)] call Chestpack_fnc_setChestpack } (assuming it even works from an init line // untested).

It would need quite some work to get it into that state + it's likely not worth yet another .pbo for its rather limited use case.

That was my initial guess too, it's why I wrote "on/inside ACE_Equipment", but it didn't seem to work. At that point, I saw no ACE code setting any attributes on ACE_Equipment, so I just assumed (still testing without requiredAddons[] as it seemed unnecessary) that I can just set (`=`) the exceptions[] for ACE_Equipment, but it didn't work and the next logical (debugging) step would be to depend on all ACE modules that define ACE_Equipment (to override it), which was too many. However I missed interaction/CfgVehicles.hpp and the fact that there are attributes being set in ACE code, which explains the whole thing. Thanks for pointing it out, along with the `+=` tip, I didn't know Arma config classes supported that.

Yes, as long as the AI runs on the server (or elsewhere), I get about +15FPS on some busy benchmarks of armored vehicles engaging each other (~20FPS -> ~35FPS). Too bad setGroupOwner has been having some issues lately, so Zeus-based scenarios cannot really take advantage of this (without glitches).

"this"/player has nothing to do with locality. :)If you look at https://community.bistudio.com/wiki/Event_Scripts, you'll see that onPlayerRespawn.sqf gets passed "[<newUnit>, <oldUnit>, <respawn>, <respawnDelay>]" as arguments. So if you want to add the EH to the newly respawned unit, you would use the first (0th) argument, (_this select 0) addEventHandler ["HandleDamage", { ... your code ... }]; where "your code" gets passed HandleDamage-specific arguments (see https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#HandleDamage, 3rd column), which you can use in a similar way, ie. (_this select 0) addEventHandler ["HandleDamage", { params ["_unit", "_selectionName", "_damage", "_source", "_projectile", "_hitPartIndex"]; hint format ["%1 was damaged by %2", _unit, _source]; }]; You don't need to worry about locality because onPlayerRespawn.sqf always runs only for the local player unit, so you can safely add the HandleDamage EH and it will trigger as long as the player unit remains local (which it will unless you TeamSwitch or something).PS: You can also use description.ext respawnOnStart to make the EH register on player spawn in addition to respawn.

Hello, I would like to do, in short, _unit action ["DropBag", _my_created_container, typeOf unitBackpack _unit]; but without the limitations of an Action (does animation, cannot be performed by a corpse, doesn't work inside vehicles when a non-vehicle container is used, etc.).So far, my approach has been to save/restore the cargo contents, which is a pretty challenging job, but items are easy as they don't seem to have any extra metadata magazines can use magazinesAmmoCargo / addMagazineAmmoCargo, preserving ammo count weapons can use weaponsItems (since v1.21 on Cargo, if wiki is correct), but I found no way to "restore" these to another Cargo space All the commands that work with Cargo seem to be able to add only weapons given their class name - if there's one that takes weaponsItems output, please point me to it.Alternatively, it should be somehow possible to getUnitLoadout from the soldier, filter out only backpack, create some proxy (logic?) unit that would do the DropBag action after setUnitLoadout, though it would be very slow (as the animation needs to finish). Any better solutions? Thank you.

Probably best start again, looking always at the big picture. :) You want to sync a countdown between multiple players, some of which might have (possibly) joined in progress, some of which will have slower computers (delaying the scheduled "sleep" more than others), .. and if not, the clock will drift slowly anyway. So the easiest thing is to just run the countdown on the server and simply send notifications to clients. Though first, we have the satphone with an Action, which you'd presumably want to hide if anyone calls in reinforcements. This can be done with by specifying a "condition" to addAction like isNil "satphone_used" The _scriptToCall would then simply tell the server to execute the countdown script and would set this used variable for everyone else, so the satphone couldn't be used again. { null = execVM "startCountDown.sqf" } remoteExec ["call", 2]; satphone_used = true; publicVariable "satphone_used"; So together, it could look like (on the satphone init line) this addAction ["Call Reinforcements", { { null = execVM "startCountDown.sqf" } remoteExec ["call", 2]; satphone_used = true; publicVariable "satphone_used"; }, nil, 1.5, true, true, "", "isNil ""satphone_used""" ]; The actual startCountdown.sqf would then cycle the sleeps (or diag_ticktime if you want to be super precise) and display notifications for all players, something like for [{_x = 300}, {_x > 0}, {_x = _x - 1}] do { if (_x % 10 == 0) then { (format ["Reinforcements: %1 secs left", _x]) remoteExec ["hintSilent", -2]; }; sleep 1; }; "Reinforcements are here!" remoteExec ["hintSilent", -2]; ... your server-only reinforcements code here (or execVM with its script) ... This isn't very much optimized, but the regular "for .. from x to y" loop cannot count downwards.Sorry I can't test all of the above right now (might have some syntax errors), but it hopefully should help. It's not the most efficient way of doing things (that would be using serverTime, working around its "features", checking satphone_used on JIP, etc.), but it should work reliably.

Respawn EH (on a unit) can be added only where the unit is local. This thus doesn't work on editor init lines for players (playable units) as the init line is run on the server (registering the EH), but immediately after, the unit is "moved" (changes locality) to the player client. At that point, the respawn EH is lost. The respawn EH itself persists through respawn just fine (again, as long as the unit doesn't change locality). You can use event scripts/files (suggested above) or just register the EH in init.sqf, which runs after the initial locality change. Maybe a better description of your use case would help.