---

esselfortium said:
giant skulltag forums smiley

---

---

Quasar said:
http://eternity.mancubus.net/text/udmf.txt

There are some unsolved technical issues:

* Conflict between BOOM and Hexen flags for mapthing gamemode presence. I have currently preferred BOOM's not* flags over Hexen's because they can be set on what few objects are typically not in various gamemodes, whereas Hexen's flags require setting on every object in the map in order to appear in a given gamemode. Other than this, neither has serious technical merit over the other.

---

---

* All possible SPAC flag combinations have not been documented.

---

---

* Reasonable default value for sector light level not clear.

---

---

* Semantics for Hexen player class flags possibly problematic for DOOM/Heretic/Strife games. Flags which must be set on every object really should be discouraged in the new format IMO. They are currently specified as class0-2 fields in the thing record.

---

---

Graf Zahl said:
- This was discussed before: Vertex coordinates should be float or fixed point. I have been in a situation where the lack of precision became a problem with a map because intersecting diagonal lines had their intersection on a non-integer coordinate so the end result didn't look correct.

---

---

Quasar said:
http://eternity.mancubus.net/text/udmf.txt
* Reasonable default value for sector light level not clear.

---

---

DoomKn1ght said:
I still don't understand anything to this. Will this allow new
features like 3D floors in software.

And will it implies console doom port map spécifications:
http://www.doomworld.com/vb/wads-mo...-console-specs/

like doom 64 lighting system for example

Sector_0:
Floor Color: 44
CeilingColor: 15
SpriteColor: 16
CeilingShade: 15
FloorShade: 43
Sector_1:
Floor Color: 98
CeilingColor: 97
SpriteColor: 99
CeilingShade: 100
FloorShade: 101
Sector_2:
Floor Color: 93
CeilingColor: 92
SpriteColor: 94
CeilingShade: 95
FloorShade: 96

This just a question

---

---

Ralphis said:
udmf on top

---

---

CodeImp said:
A) This format doesn't have to be compatible with older games. It cannot be, because older games are not going to be able to read this anyway. So I don't see your problem with the flag names and such. Just say "these are the flags we use in UDMF, period".

B) In the 'sector' structure, change the 'floorpic' and 'ceilingpic' to 'texturefloor' and 'textureceiling'. Also change 'floorheight' and 'ceilingheight' to 'heightfloor' and 'heightceiling'. You did this right for the sidedef (see 'texture*') I think you should document these naming conventions.

---

---

Graf Zahl said:
- This was discussed before: Vertex coordinates should be float or fixed point. I have been in a situation where the lack of precision became a problem with a map because intersecting diagonal lines had their intersection on a non-integer coordinate so the end result didn't look correct.

- The Boom sector type bit masks should be taken out of the special field. This would make handling (especially editing them) a lot easier.

- Limitations imposed by the Doom map format should not be kept for convenience. This includes the merging of skill flags for the easy and hard skills (with a new map format each skill can easily have its own flag with little additional work in the port.) or the line tag with the line ID. The line tag as originally used by Doom is just an argument to the special and should be treated as such. Again, this shouldn't be too hard to implement (ZDoom already has it separated so for me this is just an artificial limitation without any purpose.)

---

---

Quasar said:

The primary guiding principle I used when designing the fields supported by v0.99 was to stick to what will be necessary to represent any translated Doom and Hexen maps. This is why there are no fancy port features in there, even ones that we might agree upon immediately. I wanted the spec to be as broad and unrestrictive to implementation as possible.

---

---

- The Boom sector type bit masks should be taken out of the special field. This would make handling (especially editing them) a lot easier.

---

---

Quasar said:
Most of the field names were taken directly from the structures in the Doom source code, including all of the ones you have singled out - flats, sector heights, and sidedef texture names. Check doomdata.h in the Doom source code if you don't believe me ;) Of course there is no reason we HAVE to follow that.

---

---

Quasar said:
1. Don't know that Doom Builder can handle a real-number grid rather than an integer one. CodeImp is going to have to give feedback on this before I can add it to the specification. It would already be possible to provide xf/yf vertex members for vertices created by the BSP, whether or not CodeImp can support them in his editor.

---

---

Quasar said:
3. Again, implementation specific concern. If ZDoom wants to support separate skill level flags for all skills, why not add them as a port-specific feature. And then, if support becomes widespread, they could be standardized in a later v2.0 draft. If the specification is used to dictate new features that have to be supported, then support for it will dwindle.

The primary guiding principle I used when designing the fields supported by v0.99 was to stick to what will be necessary to represent any translated Doom and Hexen maps. This is why there are no fancy port features in there, even ones that we might agree upon immediately. I wanted the spec to be as broad and unrestrictive to implementation as possible.

---

---

CodeImp said:

Doom Builder is not a nodebuilder and I don't intend to write one. This map format could be extended to include nodes information, but I don't see the need for that (sourceports today can build nodes automatically). The only real reason I see for floating point vertices are for nodebuilder output, not for mappers, because such a level of detail is not needed IMO.

---

---

CodeImp said:

Agreed, but please don't be afraid to document extensions. The sooner you document them, the better other sourceports can support the same field names for the same purpose!

---

---

CodeImp said:
Very well, then floating point vertices it is. I will make Doom Builder 2 capable of working with this.

---

---

Quasar said:
1. For sector specials, it would not be appropriate to *forbid* the use of the value in this field as a BOOM extended sector special by implementing ports, but it would nevertheless be prudent to provide access to BOOM's sector bits as separate fields, and such representation should be preferred for obvious reasons.

---

---

esselfortium said:

Alternately, how about a compromise where you have a few specials (or I suppose you could even do just one) for the boom extended specials, and a boom-special field that would have the full Boom special number? I guess that could be kind of weird, but it'd keep the 8 billion numbers out of the main specials field while allowing ports to read it without having to support args. Actually, forget that. Probably a dumb idea. :p

---

---

Quasar said:
We were talking about *sector* specials, not line specials. There's no problem with the BOOM line specials because they use outrageously high and difficult to remember numbers that will never be needed anyway. The problem with sectors, on the other hand, was BOOM team's decision to make them kick in starting at 32. This leaves scant few free specials below that number. Hexen already uses some that are not compatible due to being numbered higher than that.

---

---

CodeImp said:
Very well, then floating point vertices it is. I will make Doom Builder 2 capable of working with this.

---