Add objets on 3d floors

Hi,

With 3d floor technic, I can do that :
http://steamcyberpunk.net/gallerie-photos/?locale=fr_FR&wppa-album=5&wppa-photo=23&wppa-cover=0&wppa-occur=1
I would to know how to add "Objects.Things" in 3d floor ?

I used Remood as Doom engine.

Thx!

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.

Thx DooMAD for your tip !

For information, this is my script :

[level info]
levelname = MechaSpiderDrone
creator = Samglux

[scripts]
// http://mancubus.net/.svn/wsvn/zdoom/zdoom/trunk/wadsrc/static/things.h.txt?rev=3124
include("things.h");

script 0
{
message("MechaSpiderDrone");
}

startscript(0);


script 1
{
while(1)
{
tip(objx(playerobj(0)), ":" , objy(playerobj(0)));
wait(5);
}
}

//startscript(1);

script 2
{
spawn(BLUEARMOR , 192, 0, 410, 300);
spawn(GREENARMOR , 224, 0, 410, 300);
spawn(BLUEARMOR , 240, 0, 410, 300);
}

startscript(2);

If this issue is resolved, I would like to use this topic for a little problem I have.

I use 3D floors all throughout my map, but alot of them show up transparent, and all the alpha settings and flags are fine. What am I doing wrong?

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.

Nomad said:

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.

It is a map format issue, the DOOM format in the THINGS lump lacks any Z-height value.

I think some Legacy mods used Fragglescript for this. EDGE projects use RTS scripting for it.

Agentbromsnor said:

If this issue is resolved, I would like to use this topic for a little problem I have.

I use 3D floors all throughout my map, but alot of them show up transparent, and all the alpha settings and flags are fine. What am I doing wrong?

Can somebody reply please?

Agentbromsnor said:

Can somebody reply please?

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

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.

Agentbromsnor said:

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

Try 255. I never imagined 5 units would be noticeable, but that's the only explanation I can think of.

Agentbromsnor said:

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

'Solid' has nothing to do with rendering. That's a physics related property. Also, as DooMAD said above, you need to set alpha to 255 to make the 3Dfloor opaque.

Edward850 said:

'Solid' has nothing to do with rendering. That's a physics related property. Also, as DooMAD said above, you need to set alpha to 255 to make the 3Dfloor opaque.

Haven't tried it out yet, but I'm thinking that should solve the problem.

Excuse me while I go slap myself...

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.

kb1 said:

(Has anyone made any progress in this area?)

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.

ReMood and DoomLegacy 3D floors.

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.

Format: #aaaF
where aaa is in range 0..255
where F is A..G which selects a fog effect
Applies the User Option selected default for the special linedef when not specified.
These selections are not present in ReMood.
A: clear (old water)
B: floor cast (TBD)
C: colormap only
D: inside visibility (old fog)
E: fog lite
F: fog without distance effects, outside visibility, with face fog
G: fog with distance effects, outside visibility, with face fog
H: water fog, with face fog


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.

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

There is also an opaque 3d floor.

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.

GL nodes has nothing to do with OpenGL. It gives you well-formed convex subsectors. EDGE used them in its software renderer to solve the sprite issues.

Read the specs at http://glbsp.sourceforge.net/

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.