Dialogues

Everything about development and the OpenMW source code.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Dialogues

Post by lgromanowski »

Zini wrote: I started working on the dialogue system. The missing code for loading info records is in place now (branch dialogue). It slows down loading a bit (on my box about two seconds). But that was to be expected, since we were skipping info entries previously. There is still some room for optimisation, but I will leave the code as it is, until it is proven that it needs to be faster.

Right now I can't do much more without a GUI. If anyone would be willing to implement the dialogue window, that would be a huge help (we can leave out some of the more complicated features for now).
Zini wrote: I added NPC and creature activation in my master branch. If you focus a creature or an NPC and press space, OpenMW will try to bring up the dialogue window. It will make OpenMW partially lock up, because there is no dialogue window.

Please note, that some NPCs are scripted to not have dialogues (this feature is fully implemented).
Zini wrote: My dialogue branch can now almost correctly handle the initial greeting message (script execution and some conditions are still missing). I am not going to merge it into master for a while, because that would make testing the (hopefully) upcoming dialogue window implementation a lot harder.
nicolay wrote: Great. I've put up the dialog window and other gui windows on the roadmap for the next milestone (not the current one.) I think that + the terrain stuff will be more than enough for one release.
Zini wrote: I finally integrated the dialogue branch into the master branch. For now I can't do much more dialogue work without a window. Ready to be pulled.

Note, that if a matching info record is found, the engine tries to open the dialogue window. But since there is no dialogue window, it is partially locking up. You can break out of the lock by pressing F1 twice. This opens and closes the console and as a side-effect resets the GUI mode.
nicolay wrote: Done, looks good! (I get all the dialog items in stdout)

That branch tree is starting to look complicated. I'm so glad we didn't have to do all this through SVN :)
Zini wrote:
(I get all the dialog items in stdout)
Actually, that is a bug. You should get only one. Fixed now.
ap0 wrote:
I'm so glad we didn't have to do all this through SVN :)
Troll spotted :D !
Star-Demon wrote:
ap0 wrote:
I'm so glad we didn't have to do all this through SVN :)
Troll spotted :D !

While we're on that - what was the major reasons to pick Git over Subversion? From what I read way long ago, they handle copying and updating differently, right?
nicolay wrote:
Star-Demon wrote:While we're on that - what was the major reasons to pick Git over Subversion? From what I read way long ago, they handle copying and updating differently, right?
The choice is mainly one of personal preference, I (re)discovered git about a year ago and fell in love with it once I understood how it worked.

Despite being very similar on the surface, SVN and Git are very different. Most has to do with Git being a distributed VCS, which means that there is no central repository. Everybody has their own repository, even the copy on my hard drive is a separate repository from my repository on github. My github repos is the "main" repos only by convention, not by any technical standard.

This means that you can make commits without needing anyone's permission, you can have private branches that you share only when you want to, and you can decide if and when you want to implement the changes that others have publicized in their repositories. It also means that anyone at any time can decide to take the project in their own direction (a true fork), or continue the project if the my repos dies for some reason, without a lot of extra setup and without precluding the possibilities of the two projects merging back together at a later point.

Anyway, this is getting off-topic. I suggest that anyone who wants to discuss this further start a new thread for it.
Peppe wrote: I've started to build a dialogue window.
Current state is that it shows up with dummy options and history.
I've made a subclass of MyGUI::Edit to be able to detect clicks on colored text in the history.

It's not all that pretty, but it is a start.
<!-- ia0 -->screenshot000.jpg<!-- ia0 -->
The next step will be some cleanup and having a look at the connection to the the dialogue manager to get an idea of what the actual data it will need to handle looks like.
Zini wrote: That's a good start. I don't see any of your code on github though.

Regarding the dialogue manager: There is no interface for the GUI yet.

I think on the GUI side we need the following functions:

- startDialogue
- stopDialogue
- addKeyword
- removeKeyword
- addText
- askQuestion (for the multiple choice function)

The dialogue manager would need the following callbacks:

- keywordSelected
- goodbyeSelected
- questionAnswered (for askQuestions)

Note, that this is only a first draft. Its been a while since I have looked at the dialogue system. But I think it is mostly accurate.
Star-Demon wrote: Frame looks good - just need a decent font. :) Good work!
Xan wrote: I like the way it's turning out so far. As stated it does need some work. I am still so pumped for this project, keep it going. An again good job. :D
Peppe wrote:
Zini wrote:I think on the GUI side we need the following functions:

- startDialogue
- stopDialogue
- addKeyword
- removeKeyword
- addText
- askQuestion (for the multiple choice function)

The dialogue manager would need the following callbacks:

- keywordSelected
- goodbyeSelected
- questionAnswered (for askQuestions)

Note, that this is only a first draft. Its been a while since I have looked at the dialogue system. But I think it is mostly accurate.
In the design I'm considering the dialogue manager will have the following functions:
  • getTopics
  • getHistory
  • selectTopic
  • selectAnswer
getTopics will probably return just a list of strings.
getHistory will return a list of history elements some kind.
I believe a history element will contain a heading, a body and list of possible choices, all of which are optional but at least one must be present.

Illustrating this with a screen shot
Image
In this case we would have a history list of five elements. The first one containing just a body, the second header and body, third and fourth just a heading, fifth no heading or body but two options.

The dialogue window will subscribe to the dialogue manager to get notified of updates.

The general flow will be:
  1. Dialogue is started.
  2. The window is opened and subscribes to the manager.
  3. The window will query the manger for topics
  4. The window will query the manger for history
  5. The window will be updated using the result of the two queries.
  6. The user performs and action, selecting a topic or answering a question. The appropriate function in the manager is called.
  7. The manager acts on the action, updates available topics, history etc.
  8. The manger sends a notification to it's observers
  9. The window gets the notification and we start over at step 3
What I'm trying to accomplish is to make the GUI just a (somewhat) dumb front end for the manager. It is to show the state and initiate changes, but all actual logic should be in the manager.
Zini wrote: I mostly agree with your design. But I see two issues:

1. There is no need for a history. The text in the dialogue window does not persist once the window is closed. There is no need for the dialogue manager to bother with it. I think the dialogue window should more or less act as a std::cout like data-sink (and with that I don't mean you should copy the stream interface).

2. Why is the dialogue window querying the dialogue manager? When the dialogue window is opened by the dialogue manager, the manager can configure the window with topics.
Peppe wrote:
Zini wrote:1. There is no need for a history. The text in the dialogue window does not persist once the window is closed. There is no need for the dialogue manager to bother with it. I think the dialogue window should more or less act as a std::cout like data-sink (and with that I don't mean you should copy the stream interface).
I don't believe just text will be flexible enough.
For example once the user have choose one answer to a question we no longer want the user to be able to choose an answer, unless we ask a new question.
I can't run Morrowing though wine on this box (Intel drivers agen't good enough) so I can't try, but do we even want to show the other options after an answer have been chosen?
I also don't believe we want to make part of options or headings links to topics. So we need to distinguish them.
Zini wrote:2. Why is the dialogue window querying the dialogue manager? When the dialogue window is opened by the dialogue manager, the manager can configure the window with topics.
Due to dependencies, it is my belief that a front end should depend on the back end, not the other way around. There is currently no direct connection between the dialogue manager and the window, the dialogue manager only knows about setGuiMode in the input manager.
Zini wrote: 1. I guess I could have described that more clearly. I didn't mean a flat text interface. The dialogue manager produces either a key phrase (the heading) plus a text or a list of options. These are sent to the dialogue window. The dialogue manager should not be required to keep track of the text (since it has no use for it).

2.I can understand your argument. But this design would make the dialogue manager a lot more complex, because it would need to keep track of various dialogue results, that otherwise could be pushed to the dialogue window and be forgotten.
Peppe wrote:
Zini wrote:1. I guess I could have described that more clearly. I didn't mean a flat text interface. The dialogue manager produces either a key phrase (the heading) plus a text or a list of options.
So I guess we agree on this part, some kind of container is required.
I believe the history element I described earlier fill this requirement.
Zini wrote:These are sent to the dialogue window. The dialogue manager should not be required to keep track of the text (since it has no use for it).
Well, in my proposal the dialogue manager do have a use for it.
It is to provide it to the front end and modify it when required.
For example to mark a question as answered to make the front end no longer allow the user to answer (and possible hide the other options?).

Basically it is about dependencies and responsibilities.
As stated I believe the back end should not depend on the front end.
Which means the back end can't modify the front end directly. You could define a more complex interface so that the the front end could subscribe to the back end and push data that way, but I really don't see any advantage with that.

Responsibilities, the front end should not make any changes to the state, that is the responsibility of the back end. So in the case of a question, if we have the history element we can change it and notify the front end that something changed. If we don't have the data we need a more complex interface towards the front end in order to inform it about the change.
Zini wrote:2.I can understand your argument. But this design would make the dialogue manager a lot more complex, because it would need to keep track of various dialogue results, that otherwise could be pushed to the dialogue window and be forgotten.
No, I can't see it making any significant difference on the complexity of the dialogue manager. What we are talking about here is basically keeping a list of history elements for the duration of the conversation. Some push and pop, shouldn't be anything advanced.
Zini wrote: Looks like we are not finding an agreement here. Maybe because we have different idea about the dialogue manager? It seems you consider the whole thing a model-view pattern, where the manager (model) holds the whole state and the window (view) displays it.

That is not my position, because except for the multiple choice case the Morrowind dialogue system is mostly state-less. And the multiple choice function should be seen more as a modal dialogue box, that interrupts the regular GUI, asks the user a question and then returns to the regular GUI.
Zini wrote: Anyway, I won't try to insist on you using my design instead of yours. However please note, that the actual dialogue manager implementation is still on my to-do list (I started with the groundwork a while ago) and I am not comfortable with your design. So we have three options:

1. We use my design concept.

2. We use your design concept, but you implement the model part too. Maybe even as a separate class: DialogueModel? Or even simply Dialogue? The dialogue manager will be complicated enough. The actual dialogues should not be integrated into it.

3. You take over the rest of the dialogue implementation from me and do the whole thing by yourself.
Star-Demon wrote: I would say "disagree and commit" but my place here and the situation here is a little more complex than that.

We're discussing things for a good reason - we want to be involved. We are (or would like to) work together, and unfortunately things need to be discussed and disagreements will come up and need to be resolved.

Without having to make this a private conversation - I don't believe your points, as clearly decisive of the situation in front of us as they are, really resolve the conflict we're looking at.

Wait...this isn't the music player thread...I have to read this all over...oh crap!
Peppe wrote: No, it really isn't all that complicated, at least from my point of view, the discussion is about the design solution not about what to do with something already implemented.

The point of having this discussion before implementation is to find a good solution. If I did not want a discussion I would have avoided starting one :)

Obviously I will argue for the solution I have proposed, but that does not mean I can not be convinced that it is not the way to go.
Zini wrote: Well, I can sum up my position once more:

I see the merit in strictly controlling the dependencies in a model-view-pattern. But I also see the model-view-pattern as overkill here, because of the extreme simplicity of the model (only operations on it are adding data at the end, the modal-like choices function and topic list updates). However that is not the real problem here.

What I don't like about your design is that you are trying to mix dialogue functionality into the dialogue manager. The dialogue manager is not a dialogue.

My original understanding was, that the dialogue window is the dialogue. This can be internally implemented as two classes (model and view), if you insist on it, but it should be kept out of the dialogue manager.
Locked