Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Blzut3

USDF Changes

Recommended Posts

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).

Share this post


Link to post

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.

    Share this post


    Link to post
    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

    Share this post


    Link to post

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

    Share this post


    Link to post

    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.)

    Share this post


    Link to post
    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.

    Share this post


    Link to post

    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.

    Share this post


    Link to post

    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.

    Share this post


    Link to post

    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 ;)

    Share this post


    Link to post

    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.

    Share this post


    Link to post

    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?

    Share this post


    Link to post
    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();
    }

    Share this post


    Link to post
    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.

    Share this post


    Link to post

    Please sign in to comment

    You will be able to leave a comment after signing in



    Sign In Now
    ×