Page MenuHomeFeedback Tracker

attachedObjects command returns null objects if attached objects are not detached before deletion
New, NormalPublic

Description

The array returned by the attachedObjects command contains null objects (objNull) if attached objects were deleted before being detached using the detach command. This is not the behaviour one would expect from this command - the command should not return any null objects.

Details

Severity
Minor
Resolution
Open
Reproducibility
Always
Operating System
Windows 10 x64
Category
Scripting
Steps To Reproduce
  1. Create a new mission in VR world
  2. Place a player unit
  3. Play the mission in SP
  4. Open debug console and execute the following code:
a = createVehicle ["B_Truck_01_mover_F", [0, 0, 0], [], 0, "NONE"];
b = createVehicle ["B_Truck_01_mover_F", [0, 100, 0], [], 0, "NONE"];

systemChat format ["Before Attach: %1", attachedObjects a];

b attachTo [a];

systemChat format ["After Attach: %1", attachedObjects a];

0 spawn {
sleep 0.1;
deleteVehicle b;
sleep 0.1;
systemChat format ["After Delete: %1", attachedObjects a];
};
  1. Observe the chat to see the unexpected behaviour.

Chat Output:

Before Attach: []
After Attach: [<not-null object>]
After Delete: [<NULL-object>]
Additional Information

To see the correct behaviour, execute the following code (difference from above is that this contains a detach before the deletion):

a = createVehicle ["B_Truck_01_mover_F", [0, 0, 0], [], 0, "NONE"];
b = createVehicle ["B_Truck_01_mover_F", [0, 100, 0], [], 0, "NONE"];

systemChat format ["Before Attach: %1", attachedObjects a];

b attachTo [a];

systemChat format ["After Attach: %1", attachedObjects a];

0 spawn {
sleep 0.1;
detach b;
deleteVehicle b;
sleep 0.1;
systemChat format ["After Delete: %1", attachedObjects a];
};

Event Timeline

Why is this unexpected? When you delete object the reference to it becomes objNull.

That is true, however, to me the name attachedObjects implies "return a list of currently attached objects to the given object". An object that doesn't "exist" anymore, can't be attached to the object (or anything).

BIS_fnc_KK added a comment.EditedDec 27 2019, 12:25 PM

By your logic the variable that contained object should become nil and not objNull when object is deleted. This is not how it works. You havent detached object so it is considered attached and returned in the array. detach object before you delete it, you are the designer

BIS_fnc_KK changed Resolution from Open to Won't Fix.Dec 27 2019, 12:27 PM
mharis001 added a comment.EditedDec 27 2019, 1:32 PM

I fail to see how my comment implies that variables referencing the deleted object should become nil.

I understand your side of the discussion, that because the object was not explicitly detached, it is still considered attached. However, consider this similar situation for Vehicle in Vehicle Transport:

a = createVehicle ["B_Truck_01_flatbed_F", [0, 0, 0], [], 0, "NONE"];
b = createVehicle ["B_MRAP_01_F", [0, 100, 0], [], 0, "NONE"];

systemChat format ["Before setting as cargo: %1", getVehicleCargo a];

a setVehicleCargo b;

systemChat format ["After setting as cargo: %1", getVehicleCargo a];

0 spawn {
    sleep 0.1;
    deleteVehicle b;
    sleep 0.1;
    systemChat format ["After deleting: %1", getVehicleCargo a];
};

The above code prints out the following in the chat:

Before setting as cargo: []
After setting as cargo: [<not-null object b>]
After deleting: []

The above code does not explicitly set the cargo object as not cargo before deletion using objNull setVehicleCargo b, however, it is not considered to be still set as cargo after deletion. I believe that these situations are very similar and for consistency, one should be changed.

I do not see any reasonable purpose for the array returned by attachedObjects to contain objNulls.

Also, it this behaviour is not changed, BIS_fnc_arsenal should be fixed then because every usage of Virtual Arsenal adds a objNull to the array returned by attachedObjects for the unit.

Ok makes sense, ropeAttachedObjects also removes null objects, lets see what we can do

BIS_fnc_KK changed Resolution from Won't Fix to Open.

Thank you. This change will also resolve T84595.