Since backpacks contain links to vehicles they've been assembled to (drones and static weapons), it would be useful to have a scripting command that returns that link. You can already check if vehicle is packed into backpack with objectParent, so its only natural to have command that works
Suggested syntax:
getBackpackVehicle ENTITY, takes backpack entity, returns the vehicle it assembles to or null of it wasn't assembled once yet or invalid\can't assemble
If command existed, you could do this:
Additional command name ideas:
getBackpackEntity, getBackpackObject, getBackpackAssembledTo, getAssembledVehicle, getAssembledObject, getBackpackChild (by analogy with objectParent)
Fixed typo on step 4, meant to say you have to disassemble it and wear the backpack again, then command should return assembled but hidden drone.
When you dissemble the drone or static weapon, it doesn't get deleted but gets hidden and link to that entity is stored in the backpack, the command should return that link. When you spawn assemblable backpack it doesn't spawn associated drone\static right away but only when you assemble it the first time.
Simplest application example - rearming static weapons\drones when they're in backpack form:
getBackpackVehicle unitBackpack player setVehicleAmmo 1;
Sure I can. Would this be enough? any other commands you want to use on assembled vehicle apart from setVehicleAmmo?
I thought you meant you can rearm it already with current unitBackpack command implementation. Do you suggest having unitBackpack return assembled vehicle instead of backpack entity? That's a bad idea because unitBackpack command should return the backpack, not the vehicle "inside" the backpack. Plus backpacks can be elsewhere - on the ground or in vehicles. Yes you can already jump through hoops to find the vehicle your backpack assembles to, like iterating through each 8 allObjects 4 and running objectParent on each, or storing it in a variable somewhere on WeaponAssembled event handler. Personally I can do without this command, I can access the vehicle through other means but this ticket is exactly about benefit to wider audience - a proper command that returns the link that's already in the engine, using existing engine mechanic, letting scripters operate assemblable vehicles without having to resort to hacks and workarounds.
Do you suggest having unitBackpack return assembled vehicle instead of backpack entity?
Only when you use it in context that makes sense like with setVehicleAmmo. If you just unitBackpack you get backpack reference
In fact it doesnt matter if it is unitBackpack or backpackcontainer or a variable with reference to backpack, it matters what you gonna use it for, like I said for setVehicleAmmo I can make it to look for the vehicle and rearm it. So my question stands, what other commands you want to use on backpack vehicle
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.
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.
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.
allObject is just that all objects would be strange to call it all objects and remove some objects the engine collections already include. But what you ask is for the getter to SPECIFICALLY return out of world objects and ONLY out of world objects. I won’t add that. Using other vehicle commands on backpack you know is a vehicle makes sense, but ok, you can still do it via storing a variable on backpack.
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.
Speaking of getters for out of world objects, this is exactly what uniformContainer and vestContainer do too, I remember asking for these commands back in like beta and dev told me they can't make them available, yet they did add the commands some time later, probably because they needed them themselves. I still think its totally fine to let us get and operate (though limited) out of world objects.