UDMF? Is the new map format finally happening?

[SoM]

It's the confusion about the tag/line id issue. You may have gathered from the Doomworld thread that I still haven't fully understood what you did there that makes this such a big deal. (hence weird. )

EE has historically (through fraggle script, anyway) used tags the same as doom, but also needed to reference specific lines as well (for changing attributes, whatever) fragglescript had to do this through linedef number which was a nightmare. I'm pretty sure Quasar` would only want to add a line id field to identify specific lines for referencing via scripting, which is why I don't see what the big freak out is for. Although, Quasar may have some other intention for the line id, but that's what my understanding of it's use. Same with sector id, and thing id, they would be simply unique numbers used for identifying specific lines, sectors, things, without having to use array indexes which are not constant numbers.

I say this but I haven't been able to talk to Quasar about it for clarification, so take this all with a grain of salt.

[Graf Zahl]

It's the confusion about the tag/line id issue. You may have gathered from the Doomworld thread that I still haven't fully understood what you did there that makes this such a big deal. (hence weird. )

EE has historically (through fraggle script, anyway) used tags the same as doom, but also needed to reference specific lines as well (for changing attributes, whatever) fragglescript had to do this through linedef number which was a nightmare.
I'm pretty sure Quasar` would only want to add a line id field to identify specific lines for referencing via scripting, which is why I don't see what the big freak out is for. Although, Quasar may have some other intention for the line id, but that's what my understanding of it's use. Same with sector id, and thing id, they would be simply unique numbers used for identifying specific lines, sectors, things, without having to use array indexes which are not constant numbers.

The confusion is about the Boom specials referencing lines by tag. If the tag is used for both in addition to a separate ID - yes, I'd consider this messy because you not only have a line ID, you also have a second value doing the same but additionally having another function as well. It's not surprising that this causes headaches.
Of course ZDoom also has line IDs and due to lack of options it has to use the tag in Doom format maps. However, internally the value never doubles for both identifier and special parameter. All Boom specials that require the tag to be used as both have two line id parameters in their Hexen format incarnation so that they can be defined properly without having to bother with this issue (see [wiki]Teleport_Line[/wiki].)

And BTW, FS never addressed lines by map index. It did this with the tag (in GZDoom when using Hexen format of course with the line ID.) Only things were ever referenced by map index because they never had another identifying value.

[HotWax]

[quote="Juan "JacKThERiPPeR"]So... is there a future feature list for this UDMF thing?[/quote]
It's probably too early to be discussing what features it will support out-of-the-box. However, here are the applicable changelog entries by Graf for ZDoom:

R954:

* Separated the linedef activation types into a bit mask that allows combination of all types on the same linedef. Also added a 'first side only' flag. This is not usable from Hexen or Doom format maps though but in preparation of the UDMF format discussed here: http://www.doomworld.com/vb/source-port ... a-textmap/
* Changed linedef's alpha property from a byte to fixed point after seeing that 255 wasn't handled to be fully opaque.

R956:

* Changed all thing coordinates that were stored as shorts into fixed_t.
* Separated mapthing2_t into mapthinghexen_t and the internal FMapThing so that it is easier to add new features in the UDMF map format.
* Added some initial code to read UDMF maps.

R964:

* Added UDMF line trigger types MonsterUse and MonsterPush.
* Separated skill and class filter bits from FMapThing::flags so that UDMF can define up to 16 of each. Also separated easy/baby and hard/nightmare and changed default MAPINFO definitions.

R966:

* Added base translation tables for UDMF compatibility maps which only should handle the native line and sector types of each game.

The most interesting things to me are the line activation changes in R954 and R964. From what I gather, these will allow multiple activation types (i.e. Player Crosses OR Player Presses Use), a flag to say that the line can only be activated from the front side, and additional flags that allow monsters to activate lines by "using" them or pushing against them. There's also the skill and class change that allows the map to filter item placement by up to 16 skill levels and 16 classes. Not bad.

[SoM]

The confusion is about the Boom specials referencing lines by tag. If the tag is used for both in addition to a separate ID - yes, I'd consider this messy because you not only have a line ID, you also have a second value doing the same but additionally having another function as well. It's not surprising that this causes headaches.
Of course ZDoom also has line IDs and due to lack of options it has to use the tag in Doom format maps. However, internally the value never doubles for both identifier and special parameter. All Boom specials that require the tag to be used as both have two line id parameters in their Hexen format incarnation so that they can be defined properly without having to bother with this issue (see [wiki]Teleport_Line[/wiki].)

And BTW, FS never addressed lines by map index. It did this with the tag (in GZDoom when using Hexen format of course with the line ID.) Only things were ever referenced by map index because they never had another identifying value.

I could have sworn there were some FS functions that used line index as well (for things like changing linedef flags).. oh wait.. that was a legacy extension. Who the hell wrote that... *hides*

hehe at any rate, so you get around using linedef tags for boom effects internally... by using hexen parameters to simulate basically the same thing? Also, I thought lines in hexen maps were supposed to have unique ids(?) but the Teleport_Line function seems to be able to reference two different lines from the same id. So you want the line ID to basically become a tag for lines to act upon each other, where as the line "tag" would be for acting on sectors.. correct?

[Graf Zahl]

I could have sworn there were some FS functions that used line index as well (for things like changing linedef flags).. oh wait.. that was a legacy extension. Who the hell wrote that... *hides*

I actually never noticed that function. Well, it's the only one that's broken and I've never seen a WAD using it.

hehe at any rate, so you get around using linedef tags for boom effects internally... by using hexen parameters to simulate basically the same thing?

Internally ZDoom translates everything to Hexen format specials so all the Boom types have an equivalent. And all of these which manipulate lines reference them by line ID.
So obviously, to make this work with Doom format maps the tag has to be used as both line ID and special arg but when using Hexen format natively you will have to set the line ID with Line_SetIdentification or some other special doing the same.

Also, I thought lines in hexen maps were supposed to have unique ids(?) but the Teleport_Line function seems to be able to reference two different lines from the same id. So you want the line ID to basically become a tag for lines to act upon each other, where as the line "tag" would be for acting on sectors.. correct?

There's no need for unique IDs and normally any special using line IDs will affect all lines with the same ID.

It's just that the Teleport_Line function is special because it has to do some weird stuff to match Boom's behavior.

Any Boom type will be translated to Teleport_Line(tag, tag). This will work the same as in Boom (i.e. the next line after the current one with the same ID will be the destination.)
However, with Hexen format maps the destination line id can be different from the source id so that you can match Teleport_Line(3,4) with a corresponding Teleport_Line(4,3). This is actually the preferred method of using it in Hexen format maps.
The dual IDs are needed because obviously you can't use Line_SetIdentification on this line so its functionality had to be integrated into Teleport_Line. The curse of Raven's laziness not to add an ID field to the line_t structure...

[Michi]

At first I wasn't understanding why this is such a big issue for Eternity but now that I have taken a look at its source things have become a lot clearer.

All I can say that this is due punishment for not having a solid foundation on which to build and I believe the reason for this is the overriding need to keep demo compatibility.

Admittedly I'm nowhere near a good programmer as Graf or Randy but even to me it is clear that you can't just do a wild mix of different features from different sources without basing them on some common ground. Instead, all I see in Eternity is that these are all implemented in parallel. Doom line types next to Hexen line types, Tags next to IDs and maybe more. I'm amazed that it works at all but it is totally confusing with a shitload of redundancy and will most likely be too much to handle for most developers. It is by far the most convoluted scheme any source port has invented yet - and that's not a good thing.

And some of the same design approach can be found elsewhere as well. The way how things are referenced by Eternity (E_SafeThingType(MT_???)) just makes my head hurt. So what does identify a thing type? Obviously not the MT_ constants. Also obviously not a readily accessible name. Ugh. It just shows how good ZDoom's approach is which nicely and seamlessly exports to DECORATE in a way that inheriting from internal classes is a non-issue. Oh, wait - C can't do it. Shit...!

Why? The only answer I can come up is that Eternity's developers are so preoccupied with demo compatibility that they are scared to do a proper implementation of features because it might break this most sacred of things.

Need I to go on?

Sorry for the bashing but I felt it had to be said at least once.

[Graf Zahl]

And some of the same design approach can be found elsewhere as well. The way how things are referenced by Eternity (E_SafeThingType(MT_???)) just makes my head hurt. So what does identify a thing type? Obviously not the MT_ constants. Also obviously not a readily accessible name. Ugh.

And in what way is that different from PClass::FindClass("Name")? Granted, I would have gotten rid of the MT_ constants but this is hardly a big deal.

[Onslaught Six]

[quote="HotWax]From what I gather, these will allow multiple activation types (i.e. Player Crosses OR Player Presses Use), a flag to say that the line can only be activated from the front side, and additional flags that allow monsters to activate lines by "using" them or pushing against them.[/quote]

Would this mean that monsters could activate, say, polyobject doors?

EDIT: Fixed quote.

[HotWax]

Would this mean that monsters could activate, say, polyobject doors?

If I had to venture a guess, I would say that this is one of the major reasons for the change...

[esselfortium]

If I'm not mistaken, it's already possible to make line types monster-triggerable (I know the generalized Boom triggers can, at least). I think the problem with monsters and polyobjects is more with the fact that they're solid 1-sided lines, so even if they were able to activate the line, they'd still treat them as solid walls when they're closed.

[Onslaught Six]

Would this mean that monsters could activate, say, polyobject doors?

If I had to venture a guess, I would say that this is one of the major reasons for the change...

Awesome.

What does this mean for, say, my existing Hexen format maps, though? Will I be able to open them in UDMF format and instantly be able to use the new features, or will I have to run them through a conversion program first? (I realize only Graf would know this, of course.)

If I'm not mistaken, it's already possible to make line types monster-triggerable (I know the generalized Boom triggers can, at least). I think the problem with monsters and polyobjects is more with the fact that they're solid 1-sided lines, so even if they were able to activate the line, they'd still treat them as solid walls when they're closed.

Hrmm. You're right, if I recall. But HotWax seemed to imply that monsters could now "use" doors/walls simply by bumping into them as opposed to (I'm guessing) the existing Monster-uses-wall trigger.

Either way, though, I'm excited for this. More options is always good.

[esselfortium]

Yes, you'll have to convert your maps into the new format to take advantage of it.

[HotWax]

Yes, you'll have to convert your maps into the new format to take advantage of it.

Once a proper editor is made, this shouldn't be that difficult.

[esselfortium]

CodeImp has said that Doom Builder 2 will not be responsible for conversion, but Quasar was planning to write a Doom->UDMF converter and I think Graf may have already done one, or at least enough of one for him to convert Doom2 map01 with it. (As I'm assuming he didn't convert the map by hand, heh)

[Graf Zahl]

I have hacked one together in quick'n dirty style so that I could create some maps to test. Once the spec is finalized I may clean it up for public release but I give no guarantees.