Since the last update, if you use the addbackpack function to replace an existing backpack, the function create a clone of the old backpack and put it at the foot of the unit before replace it.
The problem with this method is that we lost the object variable reference to the real backpack object and a new one without reference was created.
sleep 10;
_pack = unitBackpack player;
// replace the backpack by a parachute
player addBackpack "B_Parachute";
// at this time a clone object of the old backpack was created at the foot of player, and real old backpack was destroyed
// just check where the pos of the old backpack
sleep 2;
hintc format["%1 %2", position _pack, position player];
an other pack was created at the foot of the unit without variable reference and _pack was destroyed.
ok, not sure if this is a bug anymore. This only creates a backpack at the players feet when the entity already has a backpack. If you remove the backpack prior to creating the parachute then it will not create the replica.
I would advise that you load the backpack type and contents into variables prior to switching it out. and maybe wait till the players height off the ground is 0 and give him his backpack back or something?
Let me shed some light on this ticket.
pack = unitBackpack player; get reference to players backpack
player addBackpack "B_Parachute"; drops old pack at player's feet
clearMagazineCargo pack; //clears magazines for a backpack at player's feet
hint str (pack distance player); //6185
however obtained position via modelToWorld is correct
hint str ((pack modelToWorld [0,0,0]) distance player); //0.38
As far as this ticket goes, there is no issue.
your analysis is Wrong.
It's not a position problem, it s an object reference problem. This bug happens 2 releases ago.
_pack = unitBackpack player; get reference to players backpack
player addBackpack "B_Parachute"; drops old pack at player's feet
_position = position player;
_pack setpos [((_position select 0) + 10), ((_position select 1) + 10)];
_distance = (_pack modelToWorld [0,0,0]) distance player;
hint format["bacpack is at %1 meter of player", _distance]; // 15 meters
But the new object suppose to be the old backpack still at foot of player (..)
Killzone i saw your trolls on any other tickets with wrong/stupid analysis.
As you don't have the skill to report or understand thoses kind of problems,you shouldn't ask to close them.
I guess you missed the part when I said "The position of the backpack is reported incorrectly mostly due to it is being inside a weaponholder."
_pack = unitBackpack player;
player addBackpack "B_Parachute";
_weaponholder = nearestObject [_pack, "GroundWeaponHolder"];
_position = position player;
_pack setpos [((_position select 0) + 10), ((_position select 1) + 10)];
_weaponholder setpos [((_position select 0) + 10), ((_position select 1) + 10)];
_distance = (_pack modelToWorld [0,0,0]) distance player;
hint format["bacpack is at %1 meter of player", _distance];
You're welcome.
and what ? You just proove what i said before. The reference to the old object is lost, and you retrieve the new bacpack reference with nearestobject command.
Try this code instead:
_pack = unitBackpack player;
player addBackpack "B_Parachute";
_weaponholder = nearestObject [_pack, "GroundWeaponHolder"];
_position = position player;
_weaponholder setpos [((_position select 0) + 10), ((_position select 1) + 10)];
_distance = (_pack modelToWorld [0,0,0]) distance player;
hint format["bacpack is at %1 meter of player", _distance];
The backpack will be move at 15 meters, and your _pack is at 0 meters (..)
Note: your nearestobject command is not a good way to fix this problem, it's just a workaround.
You are trying to treat backpack like any other object, but it is really a storage container. The reference to backpack object never changes
_pack = unitBackpack player;
_distance1 = player distance _pack;
player addBackpack "B_Parachute";
_distance2 = player distance _pack;
hint str [_distance1, _distance2];
As you can see here the backpack location before and after it is dropped is not much different. The reference to the backpack doesn't change, it is still the same backpack, only when you drop it it is inside groundweaponholder and if you want to move it visually you need to move weaponholder as well.
i want to go out of this maze doom. I spend more time to talk to explain things to unskilled guys than coding. (i open this poor ticket 2 months ago)
If BIS doesn't want to fix this kind of problem, at least they should share the source, i will fix it myself.
well i m sorry, i had a bad spirit yesterday. You are not unskilled, we are just not agree about how the things should go.
well the thing goes just like KillzoneKid described. When player drop its backpack, so that backpack will be placed into the ground via groundWeaponHolder(Entity) which means that engine will lost an information about dropped backpack as a standalone world entity and whole simulation and render behavior will be assigned to a created weaponHolder. So if you think you see a backpack in front of you - you see nothing but the one of dummy proxies(from weaponHolder.p3d) replaced by a backpack shape model.
You will be still able to add/remove items into backpack through assigned variable, but you definitely won't be able to work with them as a standalone entity(moving, deleting, etc..)
this behavior has been implemented as a part of further design document(section: interaction with a content placed on a ground and/or crate). In fact, before "last update(your word code34)" the behavior went against design document(backpack was placed on a ground directly as an entity) so I have just fixed the bug :-)
code34: JFI - I really don't like the way you're speaking to another community members. Let me be quite personal.. well I'm not so well informed about community peoples but from my point of view: peoples like KillzoneKid, Samatra, etc. have already done many nice things, workarounds and bug reports so I'm hardly sure that KillzoneKid is not unskilled noob or troll. For the other hand, the only thing I know about you is you are not so polite to others ;-) Just my two cents
but gets back to a real problems: this is not a bug, but the design decision. Every engines have theirs limitations and this is one of them
Maybe I can add some kind of scripting command like [GetEntityOwner()] which returns owner weaponHolder so you will not have to use any workarounds
Why this design choice ? I don't understand. Why we have to work with an invisible object the weaponholder instead the visible object ? what is the benefit ?
IT should be the inverse:
getweaponholderentity()
this behavior has been implemented as a part of further design document(section: interaction with a content placed on a ground and/or crate).
is it a private or public document ? Where we can fount it ?
For the other hand, the only thing I know about you is you are not so polite to others ;-) Just my two cents
Let me be quite profesionnal (..) it s perphaps because you don't read enough the BIS FORUM, and you don't see the coders who use the arma's functions (..)
It's not important but you can't talk to me about community when you are a worker from BIS and you receive a salaries for your work while i do this for FREE since 2007 (7/7)
I recieve so much requests from this community to enhance/fix the vanilla work, support coder through chat, forums or other, and organize events, that i know what i m talking about.
I don't want to be rude with you, but i think the minimun of BIS should be to/
Do you think i m happy to complain ? I just used a script that was developped by other developper, worked for several months, and don't work anymore after release.
For my think, the thing you are talking about broke the global design cause script only created before standalone object.
I lost half day on this stupid bug to find why the object cant move anymore, came here to open a tracker, and explain the case.
So yes i m a bit lazy of what happens here (..)