USDF branch question

[Ceeb]

That code looks just fine to me. I think G/ZDoom may still require compilation... Either way, if we're this close to full USDF support, sweet. Thankfully my one USDF-heavy project isn't far along in that sense.

[Nash]

http://zdoom.org/svnview/2561/zdoom/tru ... p_usdf.cpp

This appears to be the UDSF parser. I'm seeing some "to do" comments here and there so I take it the parser isn't really ready yet?

[Ceeb]

Have you seen "USDF parser added" in the changelogs?

[Gez]

Yeah, you're not supposed to compile USDF lumps that are in the ZDoom namespace. In fact, you couldn't if you tried. (For the Strife namespace, you may compile them or not, as you wish.)

And the USDF parser IS in. If you want to see that in changelog form, look at all the [usdf branch] one, and then look at the one that says the USDF branch has been merged in the trunk.

[Nash]

I've setup my USDF lump to be in the ZDoom namespace, created a lump named DIALOGUE and put it just before ENDMAP for MAP01. I wonder what have I done wrong?

(Attachment is in Page 1) new attachment added on page 2

[Shadelight]

I think I'm going to make a plugin for DB to support this as soon as ZDoom has this. Maybe even sooner

That would be really awesome.

[Blzut3]

I think in the ZDoom namespace it's supposed to read: actor = "RandomZombieDude";
Edit:

(For the Strife namespace, you may compile them or not, as you wish.)

Even the Strife namespace is more feature filled than the binary format. USDC only compiles them to the best of it's ability (so there are missing properties and additional limits). If you are using Strife dialogs in a mod for ZDoom r2561 or later, you should always used the uncompiled form.

[Graf Zahl]

Yes. However, since the naming of actors is the only difference at the moment, it's entirely up to the modder which one to prefer. The feature set of both namespaces is identical.

[CodeImp]

Eh wow, thats a big violation of the USDF specs! That is not USDF then. Now that I carefully read the ZDoom extension, I see what it is doing and I wouldn't dare to call that an extension, that's just a different format, because it changes the 'actor' field from integer to string and also changes it's purpose. It would be better to just add a new field 'actorclass' for this purpose instead. Now I can't make a proper USDF plugin that writes proper USDF, but have to make a specialized one for ZDoom. So much for standards

[Nash]

I changed the actor to a string in the ZDoom namespace conversation but it still isn't working! :( Now what?

It says

Script Error, MAP01, Line 1:
Map does not define a namespace.

EDIT: Am I right in saying that for ZDoom namespace conversations, the ConversationID actor property isn't really needed and it's okay for me to leave it out when defining my actor?

[Nash]

If there are no responses, I take it that this feature is not working or is a bug?

[Graf Zahl]

Not checked yet. When I tested it it was working.

[Graf Zahl]

Ok, small oversight that was only triggered with UDMF maps that embedded a dialogue. Fix committed.

BTW, the most recent revisions allow assigning dialogues per actor in the UDMF map data in addition to class-based dialogues as was the only option until now.

[Nash]

Good to know. I was going crazy as to why it wasn't working when I clearly followed all instructions.

Things that I still need clarification on:

1) Am I right in saying that for ZDoom namespace conversations, the ConversationID actor property isn't really needed and it's okay for me to leave it out when defining my actor?

2) graf * r2567 /zdoom/trunk/ (5 files in 2 dirs): - added UMDF property to assign conversation dialogues to mapthings. - does this mean the actor field in a USDF conversation can be totally left out and optionally set in the map editor instead?

[Graf Zahl]

Good to know. I was going crazy as to why it wasn't working when I clearly followed all instructions.

Things that I still need clarification on:

1) Am I right in saying that for ZDoom namespace conversations, the ConversationID actor property isn't really needed and it's okay for me to leave it out when defining my actor?

Yes. The actor's conversation ID is not needed for this anymore.

2) graf * r2567 /zdoom/trunk/ (5 files in 2 dirs): - added UMDF property to assign conversation dialogues to mapthings. - does this mean the actor field in a USDF conversation can be totally left out and optionally set in the map editor instead?

The dialogue would need an ID for that, of course, but yes.