DRD Team

This is a list of properties suggested for extended map data.


THINGS

• z: integer - specifies the z-coordinate of a thing according to the same logic as in Hexen's map format. If used in a Hexen-format map it overrides the regular z-coordinate.
  Source port support: mandatory
• tid: integer - specifies the object's thing ID. If used in a Hexen-format map it overrides the regular tid.
  Source port support: mandatory

SECTORS




LINEDEFS




SIDEDEFS

I think we've discussed having script references (like thing's TID) as a string.

Sure, that can be done as a second stage. It would require reprogramming of a lot of code to achieve that and I really don't want this in the first draft. That is something we can add when we have something that is working. It would require a different approach anyway and I would use a different property name anyway.

Right now the definition of z and tid are only meant to expose Hexen-format functionality to Doom-format maps.

But rest assured, it has not been forgotten.

Understood.

Heh, didn't notice this

From the DW thread: How about some way to specify more than 5 args for things/specials?

Also technically with this we could specify action specials for vertices. This could allow a feature I'd like to see, something like Vavoom's 'vertex heights'. Makes creating landscape-style slopes much easier (as long as you keep the sectors triangular).

Anyway more stuff:

SECTORS:
To specify floor/ceiling slope planes:

• f_plane_a, f_plane_b, f_plane_c, f_plane_d: float
• c_plane_a, c_plane_b, c_plane_c, c_plane_d: float

To specify floor/ceiling texture rotation/scaling, could apply to sides too (per-texture: upper/middle/lower)

• ftex_rot: float
• ctex_rot: float
• ftex_scale: float
• ctex_scale: float

To specify floor/ceiling light/colour/fog (not sure about the fog part but should be possible, also could apply to sides)

• floor_light: int
• ceiling_light: int
• floor_col_r, floor_col_g, floor_col_b: float
• floor_fog_r, floor_fog_g, floor_fog_b: float

SlayeR wrote: Also technically with this we could specify action specials for vertices. A feature I'd like to see is something like Vavoom's 'vertex heights'. Makes creating landscape-style slopes much easier (as long as you keep the sectors triangular).

You mean, giving each vertex a floor and ceiling height so that the engine can create the slope formula from them? Sounds interesting.

Heh, crosspost.

SlayeR wrote:
Anyway more stuff:

SECTORS:
To specify floor/ceiling slope planes:

• f_plane_a, f_plane_b, f_plane_c, f_plane_d: float
• c_plane_a, c_plane_b, c_plane_c, c_plane_d: float

I'm sure they can be interesting when created by some tool. With proper editor support they can be very useful but as a generic property they aren't intuitive enough. I'd add them anyway just to give developers a chance to add proper support. Worst case scenario is that they aren't used.

To specify floor/ceiling texture rotation/scaling, could apply to sides too (per-texture: upper/middle/lower)

• ftex_rot: float
• ctex_rot: float
• ftex_scale: float
• ctex_scale: float

To specify floor/ceiling light/colour/fog (not sure about the fog part but should be possible, also could apply to sides)

• floor_light: int
• ceiling_light: int
• floor_col_r, floor_col_g, floor_col_b: float
• floor_fog_r, floor_fog_g, floor_fog_b: float

[/quote]

Most of these are already at the top of my list and belong to the first batch added to the spec. But separate fog for floor and ceiling? Are you sure that looks good?

Probably not, but I'm sure someone could find a use

More sector stuff:

Floor/ceiling glow (ala jDoom, GZDoom, old ZDoomGL etc)

• f_glow_r, f_glow_g, f_glow_b: float
• f_glow_height: integer
• c_glow_r, c_glow_g, c_glow_b: float
• c_glow_height: integer

Hmm, it'd be cool to be able to specify 'decals' somehow in the linedef extra data, something like:

• n_decals: integer
• decal1_tex: string
• decal1_x: integer
• decal1_y: integer
• decal2...

Also don't forget colors and light levels for walls. It's also something that can be very useful and currently forces mappers to do crude hacks.

Another (software renderer only) feature would be an option to clip mid textures to floor and ceiling. (In hardware it is done automatically.)

SlayeR wrote:Probably not, but I'm sure someone could find a use

More sector stuff:

Floor/ceiling glow (ala jDoom, GZDoom, old ZDoomGL etc)

• f_glow_r, f_glow_g, f_glow_b: float
• f_glow_height: integer
• c_glow_r, c_glow_g, c_glow_b: float
• c_glow_height: integer

Definitely.

Hmm, it'd be cool to be able to specify 'decals' somehow in the linedef extra data, something like:

• n_decals: integer
• decal1_tex: string
• decal1_x: integer
• decal1_y: integer
• decal2...

I think the current method with the decal thing is good enough so most likely not. It would create some issues regarding limits as well.

Some naming conventions are already apparent, and may as well standardise them. E.g.:

f_ prefix for floors
c_ prefix for ceilings
u_ prefix for uppers
m_ prefix for middles
l_ prefix for lowers

The lowercase L is not nice, can look like number '1' or capital 'i'. Maybe uppercase is better.

Personally I would have preferred these to be unified into a single Surface structure. But that doesn't really fit with the extra-data system.

Ajapted wrote: Personally I would have preferred these to be unified into a single Surface structure. But that doesn't really fit with the extra-data system.

It doesn't really fit with Doom's engine. Most ports wouldn't be able to handle a system that tries to make all surfaces equal.

Graf Zahl wrote:Most ports wouldn't be able to handle a system that tries to make all surfaces equal.

Probably not. Shame though.

With regard to the spec, I can see there'll be quite a lot of duplication, e.g. upper_light, middle_light, lower_light, floor_light, ceil_light. Something better than what I suggested before would be a very simple "namespace" capability: allow a dot ('.') in field names. Then have fields like: upper.light etc.. Do not allow whitespace, so an editor or port can still treat them as a single keyword, but other ports can decompose it.