---

Graf Zahl said:
Ok, so far, so good. Is there any reason why you didn't add my other clarifications? I think they are necessary to avoid problems.

The Strife flags are unlikely to be supported by most Doom ports, I'd think, so they should be excluded from non-Strife games - at least in the default namespaces.

And the thing special remark is necessary because there are absolutely no semantics defined how thing specials are to be used with Doom format specials.
The spec contains nothing about this which I consider a serious problem that may easily cause incompatibilities.

---

---

Quasar said:
If you can boil it down to a single point, I'll add a blurb. Otherwise it just seems to be restating the obvious.

---

---

Quasar said:
Except we seem to be confusing issues relating to the compatibility namespaces with issues relating to individual ports' private namespaces.

---

---

Doom namespace should never have specials on things, because there's no mapthing_t::special field to convert to it in the first place.

---

---

As far as the base UDMF standard is concerned, the only unified semantics are with respect to the standardized namespaces. I think maybe you're seeking, with this suggestion, to do something with the standard that it is not meant to do.

---

---

Graf Zahl said:
Regarding custom namespaces, I will support everything, including thing specials in ZDoom's Doom format namespace because the engine can do it so it should be obvious that nothing of this is of any concern to me regarding ZDoom extensions. I just don't want to see someone messing up the base namespace by accident.

---

---

esselfortium said:

Wait, what? Let me get this straight: You want to completely ignore the fact that the base namespaces are intended to be the same on all ports (the basic stuff only, with no sourceport-specific additions), for no benefit other than confusing other ports that try to read those maps (which, for all intents and purposes, have no reason not to just use the ZDoom namespace).....and then you say you don't want someone else "messing up the base namespace"? Unless I'm misunderstanding something here, it sounds like you want to ignore part of the spec and then tell everyone else to follow it?

---

---

Graf Zahl said:

Regarding custom namespaces, I will support everything, including thing specials in ZDoom's Doom format namespace because the engine can do it so it should be obvious that nothing of this is of any concern to me regarding ZDoom extensions. I just don't want to see someone messing up the base namespace by accident.

---

---

Quasar said:
UDMF->binary map converter

---

---

Quasar said:
Looks like EE may have to increase the default heap size a bit (by around 300%) if we are to support maps of that size.

---

---

Quasar said:
[B]So far there's no reason why UDMF maps in the standard namespaces could not be converted back to the binary map format. There is a one-to-one correspondence between all the data. I'm not saying that there will be high demand for a UDMF -> binary conversion tool, just that it is technically possible.

[quote]
Graf: *gulp* 8 MB? Before nodes? EE would require +16 MB of RAM to process this map, since libConfuse caches the file, then copies data out of the file, and has overhead for each structure holding the copied-out data. 16 MB is not a big deal in modern memory terms, but it's a bit alarming since currently the entire game can run on a 16 MB heap O_O

---

---

Quasar said:
No, you cannot. Not in Hexen namespace. It is not allowed. A binary Hexen map cannot represent two specials for a line. If you edit the map, you must put it under some other namespace if you set another special on the line. This was the whole point of the compatibility namespaces.

If the purpose of eliminating Line_SetIdentification in the Hexen namespace was to try to allow effectively two line specials on one line, then I am going to decline to implement that change to the spec.

---

---

Quasar said:
No, you cannot. Not in Hexen namespace. It is not allowed. A binary Hexen map cannot represent two specials for a line. If you edit the map, you must put it under some other namespace if you set another special on the line. This was the whole point of the compatibility namespaces.

---