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

Universal Strife Dialog Format

Recommended Posts

Over a year ago I wrote a WYSIWYG Strife Dialog Editor. Recently I've started work on a new lump editor entitled Simple Doom Editor and this project is nearing the point where I can start to write some of the internal editors for it. One of the first things I want to do is rewrite that Strife Dialog Editor in C++, but before I write it I want to know if there is interest on the part of port authors, that may support Strife, to create a textual format for the dialogs? (I know KSSC scripts could be used but the format does not allow for expansion.)

Edit:
Universal Strife Dialog Format Version 1.2: http://maniacsvault.net/usdf/usdf12.txt

Share this post


Link to post

If it is well designed and easily parsed into ZDoom's structures, it will sure be added and if ZDoom leads Vavoom will certainly follow - as it does with almost everything.

Share this post


Link to post

I think so. For ZDoom I'd add the option to specify items by class name though. Of course that'd not work for SVStrife so it's probably not the best thing to have in the base spec unless we'd define a list of default name->integer mappings.

Share this post


Link to post

Though this brings up the question, does the base spec have to work on conversationIDs or could those be thrown out completely and use DoomEdNums instead?

Edit: Also should the base spec allow for removing the default response? I seem to recall suggestions for the ability to do this in the past.

Share this post


Link to post
Blzut3 said:

Though this brings up the question, does the base spec have to work on conversationIDs or could those be thrown out completely and use DoomEdNums instead?


No. They need to stay. Not every type has a doomednum. I personally would prefer class names but that'd limit the whole thing to ZDoom compatible engines.

Share this post


Link to post

Specifying items by DoomEd numbers would require a way to disambiguate whether the given int is a conversation ID or a doomed number... Then there's also the SpawnID, which is a third way of identifying actors by numbers. None of the three are universal, though, since an actor may very well have no DoomEd number, no conversation ID and no spawn ID.

On your format so far, a comment:

            close_dialog   = <bool>;    // Should the dialog be closed upon
                                        // selecting this choice? Default: true
I think default should be false. To me it makes more sense to add "close_dialog = true" when you want to close the dialog than "close_dialog = false" when you don't want it. I just find it counter-intuitive to add "close dialog" lines to choices that do not close the dialog, that's why.

Share this post


Link to post
Gez said:

I think default should be false. To me it makes more sense to add "close_dialog = true" when you want to close the dialog than "close_dialog = false" when you don't want it. I just find it counter-intuitive to add "close dialog" lines to choices that do not close the dialog, that's why.

Good point, I've changed this and uploaded a new version of the spec.

Share this post


Link to post

If this turns out good, EE will eventually support it as well :) EE Strife support is a bit premature to talk about though. Right now all we can do is load the texture lump, but hey, you gotta start somewhere ;)

Share this post


Link to post

I thought about the spec for awhile and was wondering if there was a better way I could go about these parts:

        // if_item item, min_amount = page;
        // jumps to the specified page if the chater has the specified amount 
        // or more of item in their inventory.  This can be repeated as many
        // times as the author wants, but only the first one to evaluate as
        // true takes effect.
        if_item <integer>, <integer> = <integer>;
Perhaps something more array like? "if_item[<integer>] = <integer>;" and "if_item_min[<integer>] = <integer>;".

The use of parameter arguments also happens on the cost parameter.
            cost <integer> = <integer>; // cost <item> = <amount>;  Can be
                                        // repeated, but only the first will be
                                        // displayed.
Which could also be done as "cost[<integer>] = <integer>;"

Share this post


Link to post
Quasar said:

If this turns out good, EE will eventually support it as well :) EE Strife support is a bit premature to talk about though. Right now all we can do is load the texture lump, but hey, you gotta start somewhere ;)


Presumably you would include it so that it could be used in any supported game though, not just Strife?

Share this post


Link to post

How do we tell which map those dialogs are for? Strife's original dialog system only works for MAPXX lump names (MAPXX loads SCRIPT00 and SCRIPTXX), but ports would probably want it to be able to work for any map, regardless of its lump name (for example, E1M1).

Quasar said:

If this turns out good, EE will eventually support it as well :) EE Strife support is a bit premature to talk about though. Right now all we can do is load the texture lump, but hey, you gotta start somewhere ;)


That's already more Strife support than SLumpEd has!

Share this post


Link to post
Gez said:

How do we tell which map those dialogs are for? Strife's original dialog system only works for MAPXX lump names (MAPXX loads SCRIPT00 and SCRIPTXX), but ports would probably want it to be able to work for any map, regardless of its lump name (for example, E1M1).


With UDMF it wouldn't be an issue but for the old format - no idea... :(

Share this post


Link to post
Gez said:

How do we tell which map those dialogs are for?

One of the things with UDMF is more related lumps can be grouped in with the map. In this case its a matter of adding a DIALOG lump (if that's what the decided name is) to the list like so:

E1M1
TEXTMAP
DIALOG
ENDMAP

Edit: beat by Graf.

Share this post


Link to post

From someone who doesn't know this stuff.
How about an map to script linking lump?
00 == E1M1
01 == E1M2

And you just replace E1M1 with whatever you choose for map name.

Share this post


Link to post

At the moment any port that would allow you to use map names like E1M1 and Strife dialogs also supports UDMF. So the question is why should we support the old lump names any further?

Share this post


Link to post

Those were rejected in the UDMF process for various reasons, the least not being that it's always a pain to have to look for and open the proper index lump - not inside source ports, but for tools like editors.

However they certainly would work. There's never been any other objection to them. I'd just be surprised if that approach is accepted here. I myself have no opinion on the matter. I can program any number of ways to find the appropriate lump for a given map.

Share this post


Link to post

Possible methods:

- A "DIALOGUE" lump that is, like the ACS "SCRIPTS" lump, optional and inserted at the end of a map's dependent lumps. Those are automatically loaded for the map. Problem: map editors would have to keep it in that place.

- An addendum to MAPINFO, as suggested by Kristus. Problem: not all ports have MAPINFO support, so, for example, Eternity would have its own implementation as an addendum to EMAPINFO, and so on. We're veering away from the "Universal" standard if we go down that road.

- A single "DIALOGUE" lump which associates each map name with each dialog lump name. Problem: basically a duplication of MAPINFO.

- A FraggleScript-like approach with a line in the level header telling to load an USDF lump. For compatibility with FS, it would be something like this:

//{{USDF:Include "lumpname"}}
So a port with an FS parser would ignore it as a comment.

- Making the DIALOGUE lump valid for all maps and containing all scripts (can be fragmented anyway using #include), but encapsulating everything by map. Basically, we'd have:
map_name <string> // Name of the map's header lump 
                  // for the following dialogue
{
   conversation <integer>
   {
      page <integer>
      {
         choice
         {
            <blah>
         }
      }
   }
}
With the possibility to use #include anywhere, so that it could look like this:
map_name "TESTMAP"
{
#include "TESTDIAL"
}

map_name "MAP12"
{
#include "DIAL12"
}

map_name "E8M3"
{
#include "DIALE8M3"
}

map_name "RANDOM"
{
#include "LOLDALEK"
}
With that last approach, in addition to map_name we could also have a hub_name {} and world {} to have dialogues valid throughout a whole hub rather than just one map, or throughout all maps without exception, respectively.

Just throwing ideas around.

Share this post


Link to post

Way, way, way too complicated. The MAPINFO idea seems like the most sensible. It's easy to implement and causes by far the least overhead.

Share this post


Link to post

Uploaded revision 3 of the base spec with the following changes:

  • Removed underscores from property names in order to keep syntax more similar to UDMF.
  • Made ifitem a function.
  • Made cost an array.

Share this post


Link to post

It appears as if there are no objections to the proposed format. Should I go ahead and name it version 1.0 or should I wait a bit longer?

Share this post


Link to post

I have one objection. Is it really necessary to use a # on the include function? My parser library cannot support that because it uses # as an alternate form of single-line comment (a decision I regret, but cannot rescind at this point).

In the absence of an actual preprocessor phase, the hash is doing nothing and is just unnecessary syntactic noise. This would work equally well:

include("filename");

My parser DOES support this undecorated function call syntax, which is used extensively in EDF.

Share this post


Link to post

I have no problem with that. I made the change and uploaded revision 4. Anyone have any other objections? Revision 4 will go final if I do not hear anything by Sunday the 25th.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×