Extradata definition thread

Post by **Graf Zahl** » Thu Oct 27, 2005 11:08

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

Post by **Graf Zahl** » Thu Oct 27, 2005 11:17

To all non-source port programmers: Please do not post in this thread unless you have something to contriubute. This is supposed do be used for collecting information for an extended map format, not for discussion! Any posts disregarding this will be deleted without warning!

DarkKnightXC · Post by **DarkKnightXC** » Thu Oct 27, 2005 11:55

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

Post by **Graf Zahl** » Thu Oct 27, 2005 12:10

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.

DarkKnightXC · Post by **DarkKnightXC** » Thu Oct 27, 2005 14:55

Understood.

SlayeR · Post by **SlayeR** » Thu Oct 27, 2005 15:52

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

Post by **Graf Zahl** » Thu Oct 27, 2005 16:06

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.

Post by **Graf Zahl** » Thu Oct 27, 2005 16:10

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?

SlayeR · Post by **SlayeR** » Thu Oct 27, 2005 16:11

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...

Post by **Graf Zahl** » Thu Oct 27, 2005 16:18

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.)

Post by **Graf Zahl** » Thu Oct 27, 2005 18:40

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.

Ajapted · Post by **Ajapted** » Fri Oct 28, 2005 1:07

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.

Post by **Graf Zahl** » Fri Oct 28, 2005 1:14

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.

Ajapted · Post by **Ajapted** » Fri Oct 28, 2005 9:41

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.