Inconsistency with 3-d floors

[Nash]

http://nash.wanzafran.com/doomstuff/floorchecker.zip

The normal behaviour with Spawn() is that it'll fail to spawn anything if the spawned object does not have enough space to spawn.

However, with 3-d floors, the object will still get spawned, then it will be raised to the floor's surface.

In the example WAD, it is trying to detect whether the player is on ground or not. GetActorFloorZ can't be used because it will always return the distance from the real sector's floor, not the 3-d floor.

So a hack was made to solve this problem, by constantly spawning a 1-unit tall object underneat the player. If it is spawned, then the player is not on the ground. If it can't be spawned successfully, it means the player is on the ground.

If anything, this is just an inconsistency with the behaviour of spawned objects. Shouldn't it be destroyed if it can't spawn, just like real sector floors?

[Graf Zahl]

There's a lot of issues with 3D-floors because Doom's movement clipping code is 2D only with the z-axis handled by awful hacks. The problem causing this is that when an object is being spawned the engine doesn't calculate its proper floor and ceiling height values. Unfortunately that can't be added because it'd create all kinds of compatibility issues so I'll leave it as it is.

[Nash]

Oh, that's too bad.

Anyway, I came up with a workaround... I'll just fill the 3-d floors with invisible bridges. It's a little tedious but it works.

[Graf Zahl]

My question is, why does GetActorFloorZ not work? Normally it should.

[Nash]

That's really odd. Now it does. I was pulling my hair the last two days but it just didn't work. Looks like I really fail at scripting.