USDF branch question

[Nash]

Well, class name it is, then. It's much more readable for modders who plan to write conversations in Notepad or whatever.

[Ceeb]

So wait, I'm confused. Does this mean conversation IDs and the conversation UDMF property are totally useless to ZSDF, and so I -do- need multiple copies of my conversible actors defined because of the way ZSDF takes an actor name instead of an integer?

[Nash]

Conversation IDs don't need to be defined in your actor if you're using the ZDoom namespace. Simply putting the actor's name in the USDF script will correctly attach your conversation to said actor.

If you want to use the conversation field in the thing's UDMF, then yeah, you need to define a conversation ID.

BTW, my attachment on page 2 finally works. I'm loving USDF!

[Ceeb]

But what I mean is, let's say I have an actor named Scientist. But there's more than one scientist in this map, and the first scientist you talk to needs to say something else after a certain point in the map... I told my first dialogue script to use actor = 1; and I set the scientist's conversation to 1. But GZDoom tells me it expected a string and aborts the script.

[Nash]

Maybe Thing_SetConversation should have another version that accepts a class name instead of mobj id? Currently it appears to only be the latter.

[Graf Zahl]

The conversation ID's in Strife were essentially the class 'names'. The only way to reference a class was by its index in the class table.

For 'ZSDF' the ID parameter in the conversation serves a different purpose: It is used as a dialogue identifier to be used in UDMF things or with Thing_SetConversation (after all you need something to reference the dialogue by.) so it's more comparable to a tid, tag or line ID.

Essentially there's 2 ways to attach a dialogue to an actor:
1) the old fashioned way to define an actor type in the dialogue. With this all actors of the same type will run the same dialogue.
2) Give the dialogue an ID and use that to attach it to any thing on the map you like (or use a script to change it during the run of the level) With this you can give different actors of the same class different dialogues but you also can give actors of different classes the same dialogue.

Maybe Thing_SetConversation should have another version that accepts a class name instead of mobj id? Currently it appears to only be the latter.

The parameter is a tid. Which is the basic way to reference actors from ACS. No need to do an exception here.

[Ceeb]

Think I have it figured out then. Just one little bitty tiny problem. How do I add Thing_SetConversation to ACC?

[Nash]

Get the latest headers. http://mancubus.net/svn/zdoom/acc/trunk ... 49f44eadd6

[Blzut3]

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.

I know Quasar has expressed interest in supporting USDF in Eternity once they get Strife support.

In any case you didn't answer my question about using DoomEdNums as a fallback if a conversationID is undefined. Gez touched on it, but he seemed to assume I meant use DoomEdNums exclusively. What I'm thinking is if(ConverstationIDLookup == NULL) DoDoomEdNumLookup. May not seem perfectly user-friendly however I imagine Doom Builder and other editors could safely handle this.

[Ceeb]

Huh. Having a problem with my script. Here it is (sans storyline dialogue ) and the error is supposed to be on line 90, but nothing is there except a closing bracket. >_>

Script error "MAP02"
No valid actor type defined in conversation

---

Code: Select all • Expand view

namespace = "ZDoom";

conversation
{
   id = 1;

   page //1
   {
   name = "Dealer";
   dialog = "Buy drugs from me";
   drop = "Drugs";
      choice
      {
         text = "Drugs you say???";
         nextpage = 2;
      }
   }
   page //2
   {
   name = "Dealer";
   dialog = "Yes drugs!";
   drop = "Drugs";
      choice
      {
         text = "Wow drugs!";
         nextpage = 3;
      }
   }
   page //3
   {
   name = "Dealer";
   dialog = "Many drugs! All drugs! Banana made of drunks, monkey made of drugs!";
   drop = "Drugs";
      choice
      {
         text = "I see.";
         nextpage = 4;
      }
   }
   page //4
   {
   name = "Dealer";
   dialog = "DRUGS!";
   drop = "Drugs";
      choice
      {
         text = "TREES";
         nextpage = 5;
      }
   }
   page //5
   {
   name = "Dealer";
   dialog = "Tree made of drugs!";
   drop = "Drugs";
      choice
      {
         text = "Drugs!?";
         nextpage = 6;
      }
   }
   page //6
   {
   name = "Dealer";
   dialog = "Always drugs!";
   drop = "Drugs";
      choice
      {
         text = "Thank you.";
         special = 80;
         arg0 = 24;
         arg1 = 0;
         arg2 = 0;
         arg3 = 0;
         arg4 = 0;
         nextpage = 7;
      }
   }
   page //7
   {
   name = "Dealer";
   dialog = "I am out of drugs!";
   drop = "Drugs";
      choice
      {
         text = "I understand.";
         closedialog = true;
      }
   }
}

conversation
{
   id = 2;

   page //1
   {
   name = "Dealer";
   dialog = "I have more drugs!.";
      choice
      {
         text = "Thanks.";
         giveitem = "Drugs";
         nextpage = 2;
      }
   }
   page //2
   {
   name = "Dealer";
   dialog = "Fresh out!";
   }
}

[Nash]

This seems to be a bug. Setting the conversation field in a map thing doesn't seem to successfully attach the conversation to said thing. I ran into the same problem five minutes ago. Going to post a bug report.

[Graf Zahl]

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.

I know Quasar has expressed interest in supporting USDF in Eternity once they get Strife support.

In any case you didn't answer my question about using DoomEdNums as a fallback if a conversationID is undefined. Gez touched on it, but he seemed to assume I meant use DoomEdNums exclusively. What I'm thinking is if(ConverstationIDLookup == NULL) DoDoomEdNumLookup. May not seem perfectly user-friendly however I imagine Doom Builder and other editors could safely handle this.

One word:


Ugh...

[Nash]

BTW, Ceeb, I'd just like to point out that you can use the "tag" property on your drug dealer's DECORATE to properly name him; effectively bypassing the need to explicitly define a name in each and every of your conversation's pages (which can be prone to typos and is just redundant IMO).

Code: Select all • Expand view

actor DrugDealer
{
tag "Dealer"
// ... etc
}


[Ceeb]

Good to know, although since I use one scientist, I need to give them different names.

[DavidPH]

Maybe I'm missing something, but why can't ZDoom support int or string for the relevant fields (when in "ZDoom" namespace, of course)? As far as I can tell, the USDF syntax is strict enough that it should be possible to reliably detect which type of constant is being provided. And if ZDoom supports the "Strife" namespace anyways, it sounds like all of the requisite internal handling is in place.

Other than that, I don't see how conversation id is all that different from doomed number, and nobody blinks at the latter. Yes, non-Strife actors don't have the former by default, but the same could be said of Hexen's spawn numbers. (Sure, ZDoom defines those for non-Hexen actors, but that's just a ZDoom extension.) Personally, I see USDF as being just as much a storage format as UDMF along with all the same caveats. If editing raw USDF is too difficult, one should seek out an editor of some sort, just like with UDMF.