Investigate leftover entity when deleting containers

[dedmen]

When a container is deleted it leaves a entity only accessible via netID. Find out what kind of object that is and where it comes from.

repro

0 spawn {
    systemChat "begin";
    logEntities;
    sleep 1;
    private _box = "IG_supplyCrate_F" createVehicle getPos player;
    sleep 1;
    logEntities;
    sleep 1;
    deleteVehicle _box;
    sleep 1; // deleteVehicle applied next frame
    logEntities;
    systemChat "done";
};

logEntities:

> Loc:1, ForDel:0, Dstr:0, DmgDstr:0, DmgDead:0, Sim:1, Inv: 0, AnyPl:0, Out: 0, NetID:2:193, Pos: [0.000000][0.000000][0.000000], N:Supply140
> Loc:1, ForDel:0, Dstr:0, DmgDstr:0, DmgDead:0, Sim:1, Inv: 0, AnyPl:0, Out: 0, NetID:2:198, Pos: [0.000000][0.000000][0.000000], N:Supply100

[dedmen]

12:44:13 Server: Object 3:1310 not found (message Type_121) 12:44:13 Server: Object 3:1309 not found (message Type_455) 12:44:13 Server: Object 3:1308 not found (message Type_455) 12:44:13 Error: Object(3 : 1309) not found

[dedmen]

Log all vehicle creates and check if creating a ammo box creates more than one. Apparently it does. Error object is one past actual object. Just breakpoint and see from where and what happens to it on delete. possible classes InvisibleVehicle Thing

Maybe replace simulation from ThingX to Thing? Should make it a little simpler to debug atleast.

[dedmen]

WeaponsState::TakeBackpack -> MoveOut -> Entity::MoveOut Getting lost on that path? And never actually getting deleted? Does the ammobox have a parent? if so it's invisible parent might not get deleted.

[IrLED]

The case with IG_supplyCrate_F is that it, by default, is filled with 2 backpacks (no problems with them), 4 x Tactical Vest (Black) and 4x Chest Rig (Olive). Those vests are backed by 4xSupply100 and 4xSupply140 accordingly. But during crate initialization two additional vests (1 of each type with respective SupplyXX) were created and somehow those SupplyXX became rouge (orphaned). Tactical Vest (Black) - Supply100 Chest Rig (Olive) - Supply140

Also it's reproducible with other crates, e.g. "Box_Syndicate_Wps_F".

https://community.bistudio.com/wiki/objectParent

[infiSTAR]

if(!isNil'supplythread_ID')then{terminate supplythread_ID;};
supplythread_ID = [] spawn {
    _supplyCount = 0;
    _nullParents = 0;
    for '_i' from 0 to 35000 do {
        _objectFromNetId = objectFromNetId format['2:%1',_i];
        if(!isNull _objectFromNetId)then {
            _type = typeOf _objectFromNetId;
            if(_type select [0,6] isEqualTo 'Supply')then {
                _supplyCount = _supplyCount + 1;
                if(isNull objectParent _objectFromNetId)then {
                    _nullParents = _nullParents + 1;
                };
            };
        };
    };
    diag_log format['supplies: %1 - nullParents: %2',_supplyCount,_nullParents];
};

All Supplies lost their parents :-(

Ran it like that on an Exile server which ~25 people live. So most objects on the server were created by the server (with netId starting with 2:) which is why I only have it look for supplies starting with 2: (objects created by the server)

When I ran it like that on the said Exile server which was live for around 1 hour, I found 1369 Supplies that had no objectparent.