USDF branch question

[CodeImp]

I was having this discussion in the dev forum and Graf said he wanted to use class names for everything instead of IDs. Because it does not adhere to the framework set by Blzut3, this means that I can't easily write an editor that edits both Blzut3's USDF and Graf's USDF (so since ZDoom is the only sourceport currently implementing this, I will have to make an editor for that)

I am still not convinced this is the best thing to do, because it breaks compatibility and gains very little as far as I can see. Class names are easier to remember than numbers, but a visual conversation editor can just read DECORATE and use the DoomEdNums on actors to show the real actor names (so you don't have to deal with the DoomEdNums). Just like placing a Thing in DB lets you select one from a list instead of asking you for a number.

Either way, it's Graf's call and I guess he already made up his mind about this.

[Gez]

and use the DoomEdNums on actors

Not all actors you may want to have chatting have an editor number, since they can also be spawned through other means...

If this were Eternity, one could use the dehacked number, since this is essentially what the conversation ID is in Strife -- the index in the mobj table. But even in Eternity, specifying a dehacked number for custom mobjs is no longer mandatory.

[CodeImp]

Not all actors you may want to have chatting have an editor number, since they can also be spawned through other means.

And do you think adding this feature is worth breaking compatibility up to the point that it is no longer editable as USDF? Remember that you can also set "ConversationID" on the Actor in DECORATE to get the same result. Or just give it a DoomEdNum.

[Gez]

And do you think adding this feature is worth breaking compatibility up to the point that it is no longer editable as USDF?

It's not up to me.

[Graf Zahl]

If I had had the choice to implement USDF with IDs only or an alternative format with names I would have chosen the alternative.

Unlike original Strife the common use in ZDoom would be seriously hampered if inventory items had to be accessed by an ID that's not being set for any of Doom's default items.

[Blzut3]

Honestly since CodeImp isn't going to support the ZDoom namespace in DB2, you really ought to think of a new way to go about the id issue. Might I suggest using DoomEdNums as a fallback for undefined conversationids? I think between those and the ability to reassign conversations in UDMF/ACS will cover most of the advantages to using class names.

[Gez]

The fallback to me would be to use a different name for the actor property so that it can be used instead of the actor property. None of the modders so far want to use numbers.

Heck, if you really want numbers, allow the use of defined constants.

[CodeImp]

None of the modders so far want to use numbers.

No modder needs to when you have an editor for it. And I don't mean notepad

[Blzut3]

Heck, if you really want numbers, allow the use of defined constants.

As I've said elsewhere, USDF is like UDMF in that it's also intended to be written by editors. The only thing that makes it considerably more user-friendly to do by hand is that the scripts are significantly smaller. You could argue named constants would be useful for UDMF's line actions as well.

[Gez]

Even then, the needs of USDF and the needs of UDMF are very different on two critical points:

#1: UDMF was about offering the basic features of binary map formats in an extensible way. (You can bet a ZDoom-only endeavour would have used names for things and specials.)

#2: Editor numbers have always been a requirement for being put in a map. Conversation IDs, not so much -- because they're basically nothing more than the SeHackEd index. In Strife, all actors have a conversation ID. Not all actors have an editor number. Using editor numbers instead of something that is as universally-available as the declaration order in a hardcoded engine like vanilla Strife, or the class name in a more dynamic engine like ZDoom, makes it less powerful than the binary format.

Alternative: you want a number, fine. Compute a hash value from the actor's name.

[Graf Zahl]

None of the modders so far want to use numbers.

No modder needs to when you have an editor for it. And I don't mean notepad

No modder will use an editor that will force him to jump through hoops on the engine side because they cannot use the standard items.

In this case I won't change my position: For ZDoom plain USDF is sub-optimal due to the actor referencing issue. In technical terms that format is only marginally better than the binary version Strife has. The only real advantage it offers is to call an action special instead of giving an item when completing a node. And I'm sorry to say but that would not have been worth the work I invested in it. The only reason I did it was to have an option to get rid of the conversation IDs, too.

You could argue named constants would be useful for UDMF's line actions as well.

The UMDF spec has one big flaw. Back when it was discussed Eternity was still unsure where to go with this. Otherwise we would have made it Hexen format only. And then making the specials named wouldn't have been a problem.

But in the end the major difference between UDMF and USDF is data size and internal referencing. An average map is several 100000 bytes, an average dialogue a few 1000. The data inside a map references each other by index so the file format is inherently non-manageable by humans. USDF is completely different due to the nested approach which eliminates the biggest issues. The format is very easy to create and handle in a text editor and I'm quite sure that many people will use it this way.

[CodeImp]

No modder will use an editor that will force him to jump through hoops on the engine side because they cannot use the standard items.

Strife had IDs for items so it should be possible. What did ZDoom do here that makes it impossible now?

The format is very easy to create and handle in a text editor and I'm quite sure that many people will use it this way.

Ok, they can do that then. Now they definitely need class names.

[Gez]

Strife had IDs for items so it should be possible.

No, it had a Doom-style mobj table and used the indices to that table; just like DeHackEd patches did. ZDoom did away entirely with those. Conversation ID as a property is a hack to support Strife, which is about exactly the same thing as if ZDoom has had a DeHackEdNum property to support custom DeHackEd patches.

But ZDoom chose not to allow to extend DeHackEd, and the ConversationID thing was around only because there was no alternative. If a USDF-like system had been around back in the days when Strife support was being added to ZDoom, I'm sure the conversation IDs would have been only a listing in a DEHSUPP-like text lump in zdoom.pk3, and the actors themselves would not have had it in their properties.

More importantly, all the standard Doom, Heretic, Hexen, Chex Quest, Urban Brawl, etc. actors do not have conversation ID.

[Graf Zahl]

If a USDF-like system had been around back in the days when Strife support was being added to ZDoom, I'm sure the conversation IDs would have been only a listing in a DEHSUPP-like text lump in zdoom.pk3, and the actors themselves would not have had it in their properties.

In retrospect handling the conversation IDs like they are now was a bad idea. I'd do it differently right now. And to be clear: Had I had the time to cook up my own text based format before my response to USDF would have a clear 'Does not meet ZDoom's requirement.' and I wouldn't have bothered implementing it. It was clear from the start that it's either class name support or not doing it at all.

In any case, the only other port which I can ever see supporting USDF is Vavoom - which can implement the ZDoom namespace because it shares the same actor names.

[CodeImp]

ZDoom did away entirely with those.

I suspected that yea. Oh well, class names it is then. I don't dislike the use of class names really, but I hate the fact that we can't have one standard that works for both ZDoom and any other sourceport that might want to use this format.