USDF Changes

For those who don't remember, USDF is the agreed upon standard format for Strife dialog lumps and is based on the UDMF spec. The current spec for USDF can be found on my website. Graf has noticed a few problems with the spec and I feel obligated to discuss them here.

• displaycost defaults to true. IIRC this is because the binary dialog format worked in a similar way (a positive value indicated the cost should be displayed). Graf suggests that this should be changed to false to avoid problems.
  
• What is a valid conversation id? The dialogs within Strife seem to use -1 as an invalid id however in some cases 0 is used as well. Should valid ids only be numbers greater than or equal to 1?
  
• In regards to displaycost should a note be added that says that if no costs blocks are defined that this property should be ignored?
  
• Finally, should the spec preserve Strife's use of "_" as an alias for "" or should I simply make my decompiler aware of this (I'm guessing the latter).
  

Let's make this quick because I'm mostly done with the internal USDF parser:

Blzut3 said:

For those who don't remember, USDF is the agreed upon standard format for Strife dialog lumps and is based on the UDMF spec. The current spec for USDF can be found on my website. Graf has noticed a few problems with the spec and I feel obligated to discuss them here.

displaycost defaults to true. IIRC this is because the binary dialog format worked in a similar way (a positive value indicated the cost should be displayed). Graf suggests that this should be changed to false to avoid problems.

There's a few options:

1. Default to false (easiest)
2. Default to true only if the first item is valid and has a positive count (may be a bit non-intuitive)
3. Define a currency object per conversation and only default to true if it is referenced in the dialogue (too messy in my opinion)

So I'm for defaulting it to false and the most serious issues are gone.

What is a valid conversation id? The dialogs within Strife seem to use -1 as an invalid id however in some cases 0 is used as well. Should valid ids only be numbers greater than or equal to 1?

any positive value. 0 in Strife is the ForcefieldGuard item, according to ZDoom source and that's neither an inventory item nor something that can be talked to so in the end it's irrelevant.

In regards to displaycost should a note be added that says that if no costs blocks are defined that this property should be ignored?

Yes, it only makes sense if some item is set to be required.

Finally, should the spec preserve Strife's use of "_" as an alias for "" or should I simply make my decompiler aware of this (I'm guessing the latter).
[/list]

Does it really matter? I'd add a handler to the decompiler but I'd also add a handler to the parser so I really don't care.

So as soon as the displaycost issue is resolved I merge the branch back into the trunk. We can think about enhancement features later, I think.

Graf Zahl said:

Does it really matter? I'd add a handler to the decompiler but I'd also add a handler to the parser so I really don't care.

I'd prefer it to be only handled by the decompiler unless there's a reason not to.

Anyhow here's the 1.3 draft. I'll consider it final in a few days unless someone has an objection. http://maniacsvault.net/usdf/usdf13_draft.txt

Ok, sounds good to me. I'll remove the '_' handling and change displaycost's default and we should be good to go.

I've made some updates in the draft in order to be consistent with the binary dialog format. Namely all cost and ifitem must be satisfied for their respective effects to occur.

This leaves one problem though on how to handle the ifitem jumps. Should I move the page property out of the ifitem block and into the page block as "link" like Strife does it? Or should it be some kind of hybrid behavior? Something like jump to the page of the last condition to pass:

ifitem
{
    item = 1;
    amount = 2;
}
ifitem
{
    item = 2;
    amount = 2;
    page = 2;
}

This would require both conditions to be true in order to jump to page #2.

ifitem
{
    item = 1;
    amount = 2;
    page = 3;
}
ifitem
{
    item = 2;
    amount = 2;
    page = 2;
}

In this case it will jump to page 3 if the only the first condition passes. If there were 3 conditions and the first and last pass then it would still execute the first jump. (A default of -1 would be used to signify no jump.)

Blzut3 said:

I've made some updates in the draft in order to be consistent with the binary dialog format. Namely all cost and ifitem must be satisfied for their respective effects to occur.

This leaves one problem though on how to handle the ifitem jumps. Should I move the page property out of the ifitem block and into the page block as "link" like Strife does it? Or should it be some kind of hybrid behavior? Something like jump to the page of the last condition to pass:

Let's keep it as simple as possible: Move the page property out of the 'ifitem' block and keep the current behavior.

Yes, this can be improved but for the base spec it only complicates matters for potential implementors and ZDoom does not need it because I already added a feature to assign arbitrary dialogues to NPCs so all this needs is to implement what the original binary format does.

I asked Quasar about it and he says I should go for whatever gives the most flexibility. Do you see my more flexible option as posing problems in the future? I lean a little more towards it since it would remain compatible with existing USDF scripts.

To be honest, in this particular regard flexibility will only become a hassle.

In a fully scriptable engine there is no need to have a dialogue decide where to go based on the presence of inventory items beyond the simple means the binary original has.

For that real scripts are better suited to evaluate all the conditions and change dialogues based on that.

And for others it adds a layer of complexity to the decision making that's currently not there in a simple binary-based dialogue engine.

I think under these circumstances, USDF base spec should not go beyond the original feature set more than absolutely necessary.
Anything that requires more than trivial changes to the existing code is not a good idea as it might keep implementors of other engines - in particular more basic ones - from using USDF.

A small issue that I'm sure you can easily fix; In the USDF specs it says the map lump for UDMF is named "DIALOG", but in the ZDoom UDMF specs it says the lump is named "DIALOGUE". That's not going to work. I don't mind which of the two it will be, but they have to be the same. You fight over it ;)

Even though I'm not involved with it, I have to agree with Graf about this being better suited as logic in a user written script. Its just easier for everyone really so long as the format can be recognised.

All right, I've updated the spec to include the link property. Also changed the spec version number to 2.0 to indicate the broken compatibility. (The link hasn't changed yet.)

CodeImp said:

A small issue that I'm sure you can easily fix; In the USDF specs it says the map lump for UDMF is named "DIALOG", but in the ZDoom UDMF specs it says the lump is named "DIALOGUE". That's not going to work. I don't mind which of the two it will be, but they have to be the same. You fight over it ;)

Thanks for pointing that out. I've changed my specs to DIALOGUE since there's a probability it has already been used. Come to think of it, as long as we're already breaking compatibility with previous scripts should I change the properties which use "dialog" in their name to "dialogue" as well for consistency?

This one looks good. I don't think we need any more changes to it.

Blzut3 said:

Come to think of it, as long as we're already breaking compatibility with previous scripts should I change the properties which use "dialog" in their name to "dialogue" as well for consistency?

Would it hurt anything if both are accepted and equivalent? I imagine on the code side of things it'd simply look like this:

switch (token)
{
  case Token_Dialog:
  case Token_Dialogue:
     DoSomethingRelatedToTokenDialog(ue);
     break;
  case SomethingElse:
     DoSomethingElse();
     break;
  case etc:
     AndSoOn();
}

Gez said:

Would it hurt anything if both are accepted and equivalent? I imagine on the code side of things it'd simply look like this:

switch (token)
{
  case Token_Dialog:
  case Token_Dialogue:
     DoSomethingRelatedToTokenDialog(ue);
     break;
  case SomethingElse:
     DoSomethingElse();
     break;
  case etc:
     AndSoOn();
}

Why complicate matters? It's not that anyone has finished a working USDF implementation yet.

Since no one seems to have further comments. I went ahead and closed the spec.

Edit: And my USDF to binary format (de)compiler has also been updated.