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 pre-alpha content, maybe somebody could shed more 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.

Didn't check what exactly changed yet (is group deleted or has delete when empty flag set?) but I noticed that you can't get that empty group when vehicle is dissembled unless you put it into a variable. Lets expand Disassembled event handler to also include reference to the group that deleted units had?

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

In summary, I'm against changing existing commands to also handle one specific case of being run on backpacks. Its already possible to do everything you want with packed static\drone, just requires some tricks, this command should have made it clear and easy to do that.

In T171260#2424804, @BIS_fnc_KK wrote:

the vehicle is removed from world when it is packed I dont want to make a specific getter for asset that is not supposed to be exposed with api. The fact that it is available via variable reference was overlooked but due to back compatibility would now remain. I am actually trying to make it usable by wider user base, set/getVehicleAmmo is a good example. I can add that and god knows when I will be around that part of the code again, so if you give the list I can do it in one go

I don't get this argument what so ever, even if out vehicles aren't simulated or shouldn't be operated with some scripting commands, so what? And its not like this is arbitrary code execution level security issue, just a matter of entity being limited while hidden. Lets forbid allObjects from returning out vehicles too then, what if user deletes a vehicle from there and ends up getting an RPT error? There are already myriad of ways to break\lag\freeze\crash the game with scripting already, by the nature of modding.

Did tests for all possible combination, works properly. Shitty test code:

	if(!isNil"markers") then {{deleteMarker _x} forEach markers;}; markers = [];
	if(!isNil"objects") then {{deleteVehicle _x} forEach objects}; objects = [];
	if(!isNil"locations") then {{deleteLocation _x} forEach locations}; locations = [];
	positions = [];
	if(isNil"testgroups") then {{{deleteVehicle _x} forEach units _x; deleteGroup _x} forEach testgroups};
	testgroups = [];

You can do a lots of things with a packed drone\static - repair, refuel, change weapons and magazines, get\set variables, altering a single command to have special handling case for backpacks is not the way. Returning object off backpack can also tell you if backpack was assembled before.