Closing due to lack of activity for over 5 months. If this issue/request is still valid in the latest dev build, please create a new ticket or ask for this one to be re-opened.

In T63050#2307214, @BIS_fnc_KK wrote:

Should be fixed in 149354

Thanks, can I really wait for this moment, after 9 years!

Hallelujah!

In T63050#2307214, @BIS_fnc_KK wrote:

Should be fixed in 149354

My God, miracles do happen at this time and age. Well done!

Who knows maybe you end up fixing the vehicle physics somehow... or the Ai going through walls.

Ok lets stop day dreaming, one revolution at a time.

In T63050#2307214, @BIS_fnc_KK wrote:

Should be fixed in 149354

@BIS_fnc_KK

I hope not only the dead bodies will be fixed!
Since any object (furniture, boxes of ammunition, etc.) that were placed above the first floor also remained hanging in the air after the destruction of the building.

Some static objects, such as sandbag walls, don't have physics simulation at all - they're always fixed in place. You could place one in midair to begin with and it would stay there. The only possible solution for these objects would be to delete them when the building is destroyed, and it wouldn't be safe for the engine to do that automatically (it could accidentally delete something the missionmaker doesn't want it to). The best way to handle those is for the missionmaker to use an event handler or trigger to delete them when the building is destroyed.

In T63050#2322623, @NikkoJT wrote:

Some static objects, such as sandbag walls, don't have physics simulation at all - they're always fixed in place. You could place one in midair to begin with and it would stay there. The only possible solution for these objects would be to delete them when the building is destroyed, and it wouldn't be safe for the engine to do that automatically (it could accidentally delete something the missionmaker doesn't want it to). The best way to handle those is for the missionmaker to use an event handler or trigger to delete them when the building is destroyed.

Thanks for your advice, but making every event handler, or make every trigger, for every object in every house in tha map is very tedious action for a this realistic effect.

The best solution would be if game will automatically delete every static object that is in the rectangular trigger of the destroyed structure. Whereas a mission creator not wanting to delete a specific object could enable the CheckBox (don't delete after crash) in the object's properties.
It would seem more logical.

If such a system were to be implemented it would make more sense for the object deletion flag to be opt-in, rather than opt-out. This would avoid issues with backwards compatibility.

However, the idea of such a system is still flawed. What if multiple buildings overlap? What if the detection area is inaccurate? Doing a physics wake on ragdolls is non-destructive, so it doesn't really matter if a collapsing building wakes bodies it doesn't need to. But what if a collapsing building accidentally deletes an object in a neighbouring building because the detection area overlaps? That could be pretty bad. And, of course, sometimes buildings collapse in ways that don't look like they should wipe out everything inside. It would be unfortunate to delete objects in an area of the building that ends up being largely undamaged - especially if there were survivors present to see it happen. There are too many edge cases to do it automatically, especially in a way that affects existing missions.

Sorry, no deletion planned, too risky and could be undesirable. You will just have to add it by script in BuildingChanged event handler

In T63050#2322629, @NikkoJT wrote:

However, the idea of such a system is still flawed.

There is not a single flaw. The disappearance of any object means its destruction in an explosion or building collapse!
If any object disappears even near the building, it is logical. It was simply destroyed by an explosion wave or heavy rocks falling. It's all! This is much better than flying objects that will ruin the rest of the game, because they will remain forever in the air.

What if multiple buildings overlap?

What does buildings overlap mean? I have not seen a single building that would intersect! If you intentionally cross buildings in the Eden editor, then you will get the disappearance of objects. If you don't want to disappear, just check the checkbox in the object's properties (do not remove from the map)

If such a system were to be implemented it would make more sense for the object deletion flag to be opt-in, rather than opt-out. This would avoid issues with backwards compatibility.

I disagree. But in any case, adding such a checkbox would satisfy everyone.

What if the detection area is inaccurate?

What precision do you expect? Do you need millimeters? Who will check it?
Disappearance will look adequate, because this elementary means it was destroyed by the blast wave (which destroyed bulding) or it was destroyed by the falling stones.

if a collapsing building accidentally deletes an object in a neighbouring building because the detection area overlaps?

Are you saying that flying objects that will never disappear look better? - Here is main question.
Once again If the near object disappears next to the destroyed building, it means that it was destroyed by the blast wave that destroyed this building or it was buried under the rubble. To avoid confusion, need to create an object status "inside" the building, so that it does not have an impact on other objects, especially inside other buildings. Something like an attached trigger that follows the outlines of buildings

And, of course, sometimes buildings collapse in ways that don't look like they should wipe out everything inside. It would be unfortunate to delete objects in an area of the building that ends up being largely undamaged

Note! Any partial damages of any building will not remove its second/third floors, only the walls are destroyed!
It is necessary to delete all objects only when all parts of the building are destroyed, i.e. 100% destruction

There are too many edge cases to do it automatically, especially in a way that affects existing missions.

There's nothing worse than hovering objects that stay in the air FOREVER! It looks like a game shame. The player cannot create an event handler for every building on the map. The game itself should take care of that.

In T63050#2322690, @BIS_fnc_KK wrote:

Sorry, no deletion planned, too risky and could be undesirable. You will just have to add it by script in BuildingChanged event handler

I'm reading the developers thread on the BIS site:

Posted May 18
18-05-2022
EXE rev. 149361 (game)
EXE rev. 149361 (Launcher)
Size: ~82 MB

Written like this:

Fixed: Floating dead characters and PhysX objects after a building collapse - FT-T63050

My question is why then except for corpses the other objects are mentioned?

I know that some other objects have physics. I saw how the chairs inside the building reacted to the grenade explosion. Or not all objects have PhysX ?

Please explain what objects are talking about

Physx objects and corpses are not deleted, they are unfrozen so they fall down with building rubble. non physx objects don’t fall down and there is no good default solution so mission makers could script one for themselves

@BIS_fnc_KK

thank you for for clarification

Weaponholders should fall down since 149572

In T63050#2322819, @BIS_fnc_KK wrote:

Physx objects and corpses are not deleted, they are unfrozen so they fall down with building rubble. non physx objects don’t fall down and there is no good default solution so mission makers could script one for themselves

What about a line intersection solution?
First do a vertical line intersection, and test if the object was touching the destroyed object's roadway LOD.
If it was, simply teleport the object on the next roadway LOD, maybe even one that belongs to the building rubble.
During normal gameplay, there will be too much smoke and dust to notice the teleport.

in SQF that would be:

_objPos = getPosASL _obj;
_begPos = _objPos vectorAdd [0,0,0.5];
_endPos = +_objPos;
_endPos set [2, getTerrainHeightASL _objPos - 1];

_touchesBuilding = false;
_touchOffset = 0;
{
	if (_x#3 == _building) then {
		_touchOffset = _objPos#2 - _x#0#2;
		_touchesBuilding = true;
	} else {
		if (_touchesBuilding) then {
			_obj setPosASL (_x#0 vectorAdd [0,0,_touchOffset]); break;
		}
	}
} forEach lineIntersectsSurfaces [_begPos, _endPos, _obj, objNull, true, -1, "ROADWAY", "NONE"]

As you can see, it will preserve the "touch offset".

Sample script (needs a bit of polish, such as proper bounding box check, making sure object is not physx, etc.):

addMissionEventHandler ["BuildingChanged", {
	params ["_building"];
	{
		_obj = _x;
		_objPos = getPosASL _obj;
		_begPos = _objPos vectorAdd [0,0,0.5];
		_endPos = +_objPos;
		_endPos set [2, getTerrainHeightASL _objPos - 1];
		
		_touchesBuilding = false;
		_touchOffset = 0;
		{
			if (_x#3 == _building) then {
				_touchOffset = _objPos#2 - _x#0#2;
				_touchesBuilding = true;
			} else {
				if (_touchesBuilding) then {
					_obj setPosASL (_x#0 vectorAdd [0,0,_touchOffset]);
                                        _obj setVectorUp _x#1;
                                        break;
				}
			}
		} forEach lineIntersectsSurfaces [_begPos, _endPos, _obj, objNull, true, -1, "ROADWAY", "GEOM"];
	} forEach nearestObjects [getPosWorld _building, [], boundingBoxReal _building # 2, true]
}];

Before:

After:

Great post it on wiki

In T63050#2328983, @BIS_fnc_KK wrote:

Great post it on wiki

I was kinda hoping it could be added as an in-engine solution, but ok! 😅

it cannot be. some objects may not be intended to fall by mission designer (weapon holders excluded as this is game generated every time someone drops stuff in houses) Sandbags are not game generated, you are free to take care of clean up too

In T63050#2328999, @Leopard20 wrote:

In T63050#2328983, @BIS_fnc_KK wrote:

Great post it on wiki

I was kinda hoping it could be added as an in-engine solution, but ok! 😅

Me too. I don't think any mission maker would want its "objects" floating by "design". That is just immersion breaking.

Your solution is a good workaround thou! PS: Can you make a stream lined version that just deletes any object placed on the roof instead of moving them to the floor? It makes sense that the objects that fall are also destroyed and will be far more performance friendly too ;)

If an object was placed floating, I'd rather it was kept floating. Admins/mission makers can script the rest, deleting stuff is undesired.

In T63050#2330713, @Cyruz wrote:

If an object was placed floating, I'd rather it was kept floating. Admins/mission makers can script the rest, deleting stuff is undesired.

What nonsense!
Why does the game need floating objects in the air?
Isn't this what users have been struggling with for 8.5 years!?
All of them must fall to the ground or be removed. Ideally, after a building collapse, no one object should be left flying in the air! If the object was removed, it means that it was buried under the rubble. This is exactly what would happen in reality...

I personally have a scripted solution that fixes floating bits after building destruction so it doesn't impact me, however just because your usecase wants this by default, others might not. As KZK said, it's not getting implemented so it's a mute point.

@Cyruz I suggested a good solution above. By default, this disappears, just like it would in real life. But in the properties of the object there should be a checkbox - "do not delete in case of destruction of buildings".
Or do you think that each user will have the skills of scripting knowledge?

The fix as described by KK appears to be working in the release version of 2.10.