USDF branch question
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
-
- Posts: 456
- Joined: Sun Dec 28, 2003 7:40 pm
- Location: Netherlands
Re: USDF branch question
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.
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.
Last edited by CodeImp on Mon Aug 23, 2010 5:30 am, edited 1 time in total.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: USDF branch question
Not all actors you may want to have chatting have an editor number, since they can also be spawned through other means...CodeImp wrote:and use the DoomEdNums on actors
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.
-
- Posts: 456
- Joined: Sun Dec 28, 2003 7:40 pm
- Location: Netherlands
Re: USDF branch question
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 wrote:Not all actors you may want to have chatting have an editor number, since they can also be spawned through other means.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: USDF branch question
It's not up to me.CodeImp wrote:And do you think adding this feature is worth breaking compatibility up to the point that it is no longer editable as USDF?
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: USDF branch question
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.
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.
-
-
- Posts: 3178
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: USDF branch question
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.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: USDF branch question
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.
Heck, if you really want numbers, allow the use of defined constants.
-
- Posts: 456
- Joined: Sun Dec 28, 2003 7:40 pm
- Location: Netherlands
Re: USDF branch question
No modder needs to when you have an editor for it. And I don't mean notepadGez wrote:None of the modders so far want to use numbers.
-
-
- Posts: 3178
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: USDF branch question
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 wrote:Heck, if you really want numbers, allow the use of defined constants.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: USDF branch question
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.
#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.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: USDF branch question
CodeImp wrote:No modder needs to when you have an editor for it. And I don't mean notepadGez wrote:None of the modders so far want to use numbers.
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.
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.Blzut3 wrote:You could argue named constants would be useful for UDMF's line actions as well.
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.
-
- Posts: 456
- Joined: Sun Dec 28, 2003 7:40 pm
- Location: Netherlands
Re: USDF branch question
Strife had IDs for items so it should be possible. What did ZDoom do here that makes it impossible now?Graf Zahl wrote: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.
Ok, they can do that then. Now they definitely need class names.Graf Zahl wrote: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.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: USDF branch question
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.CodeImp wrote:Strife had IDs for items so it should be possible.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: USDF branch question
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.Gez wrote: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 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.
-
- Posts: 456
- Joined: Sun Dec 28, 2003 7:40 pm
- Location: Netherlands
Re: USDF branch question
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.Gez wrote:ZDoom did away entirely with those.