If you're not using a Hexen-based engine (from what I recall Remood doesn't, but it's been a while) then the only way to do it is to spawn the objects in with scripting, which is somewhat tedious. Hexen-based map formats have a Z height for Things, so it's far easier to do.

DooMAD said:
If you're not using a Hexen-based engine (from what I recall Remood doesn't, but it's been a while) then the only way to do it is to spawn the objects in with scripting, which is somewhat tedious. Hexen-based map formats have a Z height for Things, so it's far easier to do.

If I'm not mistaken, Isn't Remood a Legacy fork? It's been a loooooong time, but I'm pretty sure I remember legacy having z-height for things.

DooMAD said:
More details needed. Without that, or better yet actually seeing the map itself, it's going to be pretty hard to guess.

When I'm getting up close to any 3D floor in GZDoom (with my nose against it, so to speak) you can faintly look through it. Its not that big a deal, but I did notice it and I would rather have solid 3D floors.

And again, before you reply: I set the 'solid' flag on those 3D floors, and the alpha is 250.

I dabbled with this exact issue in my home port. I added a modification of the Legacy 3D floor stuff into the port. It works pretty good, and is certainly impressive (good job SoM!), but I've always wondered how to correct some of the rendering problems (like sprites occasionally being clipped incorrectly.) One day, I'll take the time to understand exactly what's happening, and see if I can correct some of the issues. (Has anyone made any progress in this area?)

Anyway, I decided to try them out in a new map, and immediately realized that, as stated above, it was not possible to add things on top of the 3D floor, in a Doom format map, which lacks the Z-coordinate in it's thing definition.

So, I came up with this hack, which is ugly, but works pretty well. Basically, I "overload" the angle field with the Z-coordinate. The angle field is 16-bits wide, but only 3 are needed to set a thing's angle to 1 of 8 possible angles.

My port looks for a map definition lump (some ports use MAPINFO, MAPDATA, MAPSETUP, etc). If I find my map definition lump, I parse it, and look for a flag "Z_IN_ANGLE_FIELD". If set to True, my map load code expects the angle field to contain both the thing's angle, and the thing's Z-coordinate divided by 8.

In other words, the lower 3 bits of the angle field specify the angle, and the upper 13 bits get multiplied by 8, and used as a Z-coordinate.

This hack, of course requires map editor support to be useful. However, as more ports support 3D floors, maybe this method can become standard. Of course, moving to Hexen format is the cleanest approach.

You can take a look at ZDoom's 3D floor branches. They correspond to three different approaches to the problem, which I believe are all different from what SoM used in Legacy. The first branch was abandoned, the second is what's currently used, and the third is unfinished but might, if completed, be the key to sloped 3D floors.

You either need to spawn the monster using a script. Or use a dehacked mod that makes the monster spawn at the ceiling and then fall down on the 3d floor. Another wayu is to make nooks and crannies that the monsters can spawn in and then walk out on the 3d floors from.

kb1 said:
So, I came up with this hack, which is ugly, but works pretty well. Basically, I "overload" the angle field with the Z-coordinate. The angle field is 16-bits wide, but only 3 are needed to set a thing's angle to 1 of 8 possible angles.

I suggested a very similar hack a few years ago (on the NewDoom forums), except with a new thing option flag like MTF_ANGLE_HAS_Z_HEIGHT.

I would like to add something like this to Eureka DOOM Editor, but it would need wider port support first.

Method 1.
If you already are using fragglescript.
Place the object using a fragglescript function.

Method 2.
No fragglescript.
Make a post to hold each object at the floor level desired.
Many of the posts can share the same sector.
Tag all the posts with the same number.
Place walkover triggers around ALL the player start positions,
that lower the tagged posts to lowest floor.
The objects will not pass through the 3d floors.

DoomLegacy sets the alpha of translucent floors in the upper texture
of the special linedef side1.
This has been expanded in DoomLegacy 1.44 alpha4 to include a fog effect, and the alpha range has been expanded to 0..255 in all draw modes. Alpha4 svn999 is just getting released today.

Please see DoomLegacy editing docs for a better and most correct description. From my memory, this is approximate.
This now applies to fog, water, opaque water (inside only), and
partially to transparent floors.

wesleyjohnson said:
DoomLegacy: The 3d floor sprite clipping is a stubborn problem that I have yet to solve. It will require extensive changes to the entire sprite drawing code.

The most reliable way to solve this is to:
(1) use GL nodes (to get convex well-formed subsectors)
(2) split sprites which cross subsector boundaries, so that all final pieces belong to a single subsector

Splitting the sprites is unavoidable. I have started code to split the sprites. The hangup came from considering the different directions (horz, vert, diag.) I might have to split the sprites and which could be eliminated.

GL nodes is part of OpenGL ??.
Being that we have many non-OpenGL drawing modes I cannot rely upon OpenGL being present.
The problem is the inability to sort floors by distance easily, because floors have so much extent and shape issues. Restricting sector shapes does not help much. Even a convex polygon can cut a sprite several times at odd angles, and it still does not have one distance number.

Putting a sprite on a 3d floor:
* Fragglescript solution does not require any more support.
* Hexen format does not require any new wad format.
* Sprite angle extension. Not quite adequate, requires support from the editor and the ports. Could be supported as a fall back.
Z height is too short to handle all cases, and has different scale than floors.
* Code which floor (0..3) to put the sprite on and let the code find the z level. When object is on-ceiling, the code finds which ceiling. This could be put coded in angle or somewhere else ??
It would handle floors that are positive or negative height. The only limitation is how many stacked floors it can handle.

Once you split sprites into subsectors, then your drawing order simply follows the traversal of the BSP, draw each subsector (wall parts, floor, ceiling, extrafloors and sprite parts) from furthest to closest.