---

The id should be used to identify this line, and arg0 should be used to
identify the line or sector that this line is to affect or otherwise
reference, if the implementing port is capable of making such a semantic
distinction.

---

---

Unlike traditional Doom maps UDMF makes a clear distinction between a line's ID and the parameter which identifies the object the line's special is supposed to affect.

The id will be used to identify this line, and arg0 will be used to identify the line or sector that this line is to affect or otherwise reference, i.e. it is effectively a parameter to the line's special.

Boom used the linedef's tag for both due to lack of other options so in order to ensure compatibility any map converter converting maps for the Doom/Heretic/Strife namespaces must store the linedef's tag field as both the id and as arg0 in each line. The default value of the id field under these namespaces is defined as 0 rather than -1.

---

---

Quasar said:
I can change it, but I still cannot force ports with no Hexen support to support the id/arg0 differing from each other. Feature dictation is outside the scope of the standard. In that case it isn't totally clear what they should do, since in those standard namespaces, the numbers really should not ever differ (making it accordingly irrelevant, in those namespaces, which is used as what's going into that port's line->tag field at map init).

---

---

esselfortium said:
Isn't Hexen support kind of required for ports that want to support UDMF, though, since it's a part of the base spec? o_O

---

---

Quasar said:
Alright then, as long as it is understood that this isn't establishing a precedent for the future in requiring larger restructuring of port internals to support UDMF.

---

---

Requiring a change this minor, which has no compatibility ramifications, is tolerable.

---

---

Creaphis said:
Graf, you need to get a job that involves something other than cell phone java.

---

---

Quasar said:
I can change it, but I still cannot force ports with no Hexen support to support the id/arg0 differing from each other.

---

---

Ajapted said:

YES YOU CAN!

Don't muck up the spec by making the Doom namespace work differently.

---

---

Graf Zahl said:

...
Honestly, this precise situation is what I absolutely want to forbid by precise unambiguous wording - because this is exactly what will break the spec.

---

---

Ajapted said:
Of course that won't work for linedefs which have both a special and are referenced by another line (for translucency or whatever). However in practice such a situation will be rare, so this solution would be good enough for me.

---

---

CodeImp said:

Yea but you cannot actually force anyone to implement UDMF properly.

---

---

You DID gave an unambiguous wording for the implementation, so if the implementor fails to properly implement UDMF, it simply is NOT a UDMF-compliant sourceport, regardless of what the implementor claims it to be.

---

---

CodeImp said:
I don't see why you would need such a lazy hack Ajapted. Graf Zahl already showed is is very easy to make it work properly. Do you really want broken UDMF support, just to save yourself a few more minutes from coding?

---

• Parse the lump twice (once for counting, twice to do the actual work)
  
• Keep calling realloc on an array
  
• Store parsed objects in a linked list and make an array of pointers when you're done (for random access)
  
• Something else :)

---

RjY said:
I guess it would be nice if the format could give you a hint of how many objects to pre-allocate. Like say "numlinedefs = 673;" after the namespace definition but before any object definitions.

---

---

RjY said:
There's no way to tell ahead of time how many objects a map has in it. How are you guys going about loading textmaps?

• Parse the lump twice (once for counting, twice to do the actual work)
  
• Keep calling realloc on an array
  
• Store parsed objects in a linked list and make an array of pointers when you're done (for random access)
  
• Something else :)

I guess it would be nice if the format could give you a hint of how many objects to pre-allocate. Like say "numlinedefs = 673;" after the namespace definition but before any object definitions.

---