Exult Forum

Are there any docs anywhere on how the branching conversation tree in U7/SI is implemented? Without having to go and read a load of usecode, that is

What in particular do you want to know?

Which opcodes are used in it? (exult/usecode/ucxt/opcodes.txt from the cvs, has some information, the other way is to actually look at how it's handled in exult's code.)

How it's structed at a high level? (Sort of like a switch statment in C/C++.)

Something else?

There's no _specific_ piece of documentation to reference at the moment about this.

We just have the compiled Usecode, which is assembler that looks like it comes from a typical procedural language (like 'C'). It's possible that they had a higher-level tool for creating conversations, but we have no way of knowing what it is.

Yeah, in particular I want to know the higher level details. I'm not interested in Usecode (although I will take a look at it if that's the only way). I am just wondering how it decides to reveal certain parts of the conversation, such as whether it uses a flag before each bit of text... how it knows to chain several sentences in a row that you have to click through, and so on.

As DrCode implies, I expect there is/was some higher-level format to conversations than explicitly coding every branch and flag in usecode. If so, I'd think it would be possible to take a guess at this just from looking at the usecode if you were familiar with compiling and parsing. So I wondered if anyone knew this off-hand

It basically looks something likes this (on a C-ish level):

Clear_answers();
Add_answers("name", "job", "bye");

while (true) {
Converse();
if (answer == "name") {
Say("I'm wjp");
Remove_answers("name");
} else if (answer == "job") {
Say("I'm a programmer on Exult");
Remove_answers("job");
Add_answers("Exult");
} else if (answer == "bye") {
Say("bye!");
break;
} else if (answer == "Exult") {
Say("You should know what Exult is by now!");
Remove_answers("Exult");
}
}


Like in this small example, most of the conversation doesn't use flags for option tracking, but options simply add and remove other options to/from the current list of answers. There doesn't seem to be any obvious higher level logic in there, from what I can tell.

wjp

maybe the type of action like adding a piece of equipment (or buying food, or selling items....) or marking the character's "already met" flag as "on" or even choosing certain phrases to say based on flags (like the wolf's captain when he refuses to talk to you unless you are a knight).

Also, I wouldn't be surprised to see lots of occasions where conversing sets more flags than just "already met"...

Artaxerxes

Yes, for things that have to be remembered across conversations flags have to be (and are) used.

The whole conversation engine is written in usecode.
In fact, I started usecode reverse engineering with conversations - Finnegan and Spark.

The decision of what text and what answers to show is made by usecode, using any means provided to it - sometimes it is just game flag, sometimes - more complex things like having a particular item in the party, sometimes - a combination of this.

The C-written engine just draws the text and faces on the screen.

So, you cannot understand conversations without understanding usecode.

If you want to see a real example of conversation in Usecode, download the 'patch' from our 'Files' page. I'm pretty sure I included the Usecode source.

Max - I know what you're saying, but any procedural programming language can be described in terms of another, which is what I was asking for. I don't need to know exactly how U7 does it, just a general idea to compare to my own plans.

wjp - Thanks for that, much appreciated. So the tree structure is implicit, by having one part of the conversation add the successive parts? And I assume that the Add_answers part at the start will, given the character you're talking to, also check any necessary flags/conditions in case any extra keywords need to be added?

-----
And I assume that the Add_answers part at the start will, given the character you're talking to, also check any necessary flags/conditions in case any extra keywords need to be added?
-----

Yeah, you're right. Like Max said, these extra conditions can be flags, presence of NPCs, possession of items, and basically every game condition you can think of

-Willem Jan