Personally the most needed command for me is to check is fuseDistance condition was satisfied. I'd be fine with a BOOL check but perhaps somebody else could use distance traveled NUMBER. PLZ ADD.

In T176047#2510681, @BIS_fnc_KK wrote:

When do you need the muzzle param?

Not sure about real use case, but can't you have 2 different muzzles that take same 1 grenade magazine somehow? I guess we might ignore this hypothetical scenario and just select by magazine.

In T176022#2509767, @Leopard20 wrote:

I see what you mean now. I thought you're talking about the EH.
You should've mentioned that in the issue description

In T176022#2509736, @Leopard20 wrote:

Cannot reproduce. Do you mean the HitExplosion EHs? Also which branch are you testing on? It should be Dev
In fact it's the opposite for me. Sometimes HitExplosion doesn't trigger?

Shot HitExplosion doesn't seem to trigger for tree hits like this at all, only shot HitPart does. If you'll place a quad under a tree it will also trigger entity HitPart but without any damage. Either way, EHs are not the issue, the issue is that tank shell explodes in (visually) full strength each time it passed through a bush or a tree. Its a latest dev build but this issue existed for years (tested in 1.10 recently, same picture there)

Yeah, looks like ammo count is engine-hardcoded. Perhaps there could be a scripting command to return it by ListBox index. Maybe let us draw similar bar on any ListBox and ListNBox too?
NUMBER = CONTROL lbBar INDEX
CONTROL lbSetBar [INDEX, NUMBER]
with values ranging from 0 to 1

I think this command is obsolete in A3. You can get gear info with lbData and lbValue from A3's inventory lists. Check RscDisplayInventory config for inventory IDCs of lists.

Speaking of model type property, is there a way to get it through scripting command at all? Maybe add it into getModelInfo too?

Aren't vehicle tire marks local and disappear as soon as camera goes away? Unless its different scripted tire marks.

Looks good so far! I work with HitPart right now and report if issues are found.

Found the issue, BIS_fnc_fire has to be RE-allowed. I expected it to be engine-driven.

Looks like T-100X doesn't work in MP at all anymore. No matter what I do, just doesn't shoot. Server-created vehicle, client-created, locality combos, AIs on other seat, never shoots.

Perhaps a scripting command to pull burst counter out of the soldier\weapon\mag instead?

This is just how the game works under the hood. When you disassemble a drone into a backpack, it gets hidden (moves out) so vehicle retains all of its properties - weapons, ammo, fuel, damage, variable space, variables keep pointing to it, etc.

This wreck has been in the game since beta and I remember people asking to bring this van back a lot of times. I guess it was just not up to A3 quality and wasn't included in the final game. Now that T-100X was dug out of pre-alpha content stash, maybe somebody could shed some light on this van too.

Still need this feature.

Still very much needed.

Still an issue.

Looks like everything is fixed, can be closed as resolved.

Fixed, can be closed as resolved.

Tested, works good. Can be closed as resolved.

Tested, works good. Can be closed as resolved.

This still needs attention. Make flares bright again!

Can be closed as resolved.

Can be closed as resolved.

From the discussion in feedback tracker channel this seems to happen due to lack of get in\get out animations.

Could use other attachTo arguments in the EH as well.

Thanks, this will suffice.

This ticket needs a revival, flares sucked for almost 10 years now!

Probably should be called worldToModelWorld instead

Compared to Ghost Hawk turret, static M2 has optics = 1;, maybe its the cause? Couldn't find this parameter description in https://community.bistudio.com/wiki/Turret_Config_Reference

In T171754#2438892, @dedmen wrote:

Ok didn't realize this change didn't go to dev-branch yet so you cannot have tested this.
I just checked

will now return "<NULL-config>" instead of empty string. I suggest to revert it.

No that's wrong, I don't see how you got to that as there was no mention about changing configName
We changed the string representation of configNull, we did not change what configName returns.
str config and configName config are very different things.

Just realized that we shouldn't make str configNull return anything but empty string for backwards compatibility reasons. Personally I use configName CONFIG as a way to check if class exists AND return its config letter casing. Pretty sure I'm not the only one. Since

(configFile >> "CfgWeapons" >> "asd") isEqualTo configNull

is true,

configName (configFile >> "CfgWeapons" >> "asd")

will now return "<NULL-config>" instead of empty string. I suggest to revert it.

In T171609#2438269, @dedmen wrote:

For performance reasons also, unsimulated objects probably shouldn't animate

Adding showNVGTurrets could be useful too, there is only showNVGGunner right now.

In T171966#2438098, @dedmen wrote:

Due to the way of how this works, this is VERY unlikely.
The color is usually stored in the texture, pre-calculated when it is converted to PAA.
For UIToTexture the CPU doesn't even have access to texture, so we would have to calculate the average color on the GPU.
I'm quite sure this won't happen

You probably can mitigate the effect with setAnimSpeedCoef but its a hack fix rather than controlling engine behaviour.

In T171953#2436725, @Leopard20 wrote:

Getter2 is not needed. You only need to know which ladder.
All of them can be combined in one command:

getLadder player

returns:

[object, "ladderCfgName", progress]

Since ladders are just an array inside CfgVehicles definition, it should a Number instead instead of config name. But overall I guess that having all in one command should be fine.
[ENTITY, INDEX, POSITION] = getLadder UNIT;
Alternative names: getUnitLadder, getLadderState, getUnitLadderState

In T170425#2433944, @BIS_fnc_KK wrote:

not units controlling UAVs

UAV AI is the one controlling UAV, what you asked in the first place was inconsistent with the command name but useful for a quick check, otherwise you could have done all this via config look up.

Using this moment to put attention at the lack of a proper getters for remote control: T171357, T171207, as getControlledUAVUnit doesn't cover remote control done with remoteControl commands, only through terminals. Fixing remoteControl command is one thing, but at least having proper getters would be a great help.

What was the reason to have player\unit controlling the UAV return true with this command btw? Just to make command more broad? You can already do that with !isNull getConnectedUAVUnit player, while command name itself suggests that player\unit is UAV while they're just contolling a UAV. If you ask me, I'd revert that to only return true for vehicles and UAV units, not units controlling UAVs, for a better consistency.

Turns out, getModelInfo has "Placing point" now. This ticket can be closed.

I'd prefer position to be ASL\World and not AGL btw.

New command is great, but I'd also like to request tweaks to existing commands, here are the tickets:
T171744 - Have inAreaArray and inAreaArrayIndexes take ENTITY as argument like inArea does
T171699 - Have inPolygon take ENTITY as argument
T171524 - inAreaArray variant that takes both list of areas and list of positions to check

In T171323#2431161, @POLPOX wrote:

In T171323#2425423, @SaMatra wrote:

I wonder if its possible to fix this through config without changing the model?

Apparently is possible with just config, I've done it before. This issue going to have no official fix anymore I suppose, though.

Great stuff, now I wish this was added officially, this asset is very much underused because its not flexible with the pylons

Oh, I see it now, indeed it uses wrong axis

Are you sure you're playing unmodded game? I just tested it and it seemed fine.

Had a look at it, looks like this blur is engine-driven, not scripted, once applied and unit dies, it never resets. Could be an easy fix - clean up effects on death.

Once again I had a need for this command, trying to make a hack fix to fix broken remote control (if somebody disassembles drone you're controlling, your player always remains in vehicle for everyone except you) I need to find a vehicle that backpack assembles to on "WeaponDisassembled" event handler, so I can broadcast it to players that used to control this drone, to do a hack to fix their broken state. Turns out in some locality combinations none of allObjects combinations work if you do _backpack == objectParent _x check on each. Yes I shouldn't be doing this hack fix in a first place but I can't wait months for something to get fixed and be available on stable. Though same could be said about this command too.

PLZ FIX

Thought that having a getter to return JIP queue attached to an entity will be useful too:
ARRAY = getRemoteExecutedJIP ENTITY which will return array of JIP handles that match this vehicle

I have a need for such command too, comparing unit and even units against list of areas is what I constantly do in my mission.

I feel that removing one by one is fine if EH exists. Its not like such removal happens each frame on a 100 units in scripts or in the engine itself, performance difference would be super tiny. Since the engine wasn't designed for such event handlers, this feels like a good solution.

A small correction to the request. It would be useful to also get container where new item was taken from (to remove event handlers off it or delete its items or something).

Tested, looks fine. Won't bother with extending Disassembled event handler, not critical at all.

Also I'd ditch this entire hardcoded UAV Terminal system and written my own with remoteControl but the command is absolutely terrible, my ticket T171207 has an example how player can be put into remote control without a proper way to revert it. And there are no getters for remote control either. Fixing remoteControl will also be appreciated.

In T171357#2426221, @BIS_fnc_KK wrote:

have you looked at UAV actions via action command?

I think its better to bite the bullet and fix this, make drawRectangle/drawEllipse/drawIcon treat angle as world angle rather than UI angle, same as markers currently do.

Example of repro results, in this case 4 out of 100 drones teleported back to their original spot after assembly.

In T171344#2425784, @BIS_fnc_KK wrote:

if set velocity is part of vehicle update packet (probably is) then it will update when it updates which could be after ownership change which is immediate. Not sure what would be a good solution

This doesn't happen only with such quick scripted assembles, I was working with backpack drones recently and had them disappear twice on me during normal testing gameplay (Using Assemble from mouse wheel menu). What I've seen as client: drone appears before me for a few frames and then vanishes. When I checked its position it was very far and high away (out position probably) and falling down back to earth.

Updated repro, now properly shows bugged vehicles in the chat and puts them into fucked array.