Dialogue GUI/System

[gus]

If you think it's still OK, I will follow the design you proposed in this thread Zini: http://openmw.com/forum/viewtopic.php?f ... 7&start=10

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.

But I don't know what "keyword" exactly refers too. Is it the topic list?

Edit: i had a look at what's already done, and the good new is that it looks like the GUI part is nearly finished. What's need to be done now is mainly to weir it to the dialogue Manager.
And also, I should be able to reuse some part of the code done by Pepe for the journal task


Edit2: I'm also not sure of the startDialogue() and stopDialogue() function. Do they open the dialogue window? Or do they simply pass parameters like NPC names just after the dialogue window open up? (and if it's like this, what's the use of stopDialogue?)

[Zini]

keyword really should be named topic instead. Sorry.

Yes, the GUI is already pretty advanced. From what I remember we need to display the real dialogue text (instead of the dummy stuff) and add interactivity.

startDialogue should start the dialogue on the GUI side. This can be caused by the player activating an NPC or by a script instruction.

stopDialogue should end the dialogue on the GUI side. This can be caused by a script instruction or by the player clicking on the Goodbye button. the button should not immediately end the dialogue. Instead it should call a respective function in the dialogue manager (we still need to add it to MWDialogue::DialogueManager). This function will then in turn call stopDialogue on the GUI side. This will allow us later to control the way the player can leave a dialogue.

Ah, right. The function was already listed in the text you quoted. goodbyeSelected.

[gus]

The thing is that bringing up a GUI window is managed by the window_manager class, not by the GUI dialogue class.
So to be coherent with the design of the GUI, the dialogue GUI class should not be able to open itself.

So the dialogue system should ask first the window_manager to change the GUI mode to dialogue (which open up the window dialogue) and then pass parameters to the dialogue class.
And to switch off the dialogue GUI, that's the same, the dialogue system should ask the window_manager.

keyword really should be named topic instead. Sorry.

And I believe the clickable keyword are the same than those on the topic list?

[Zini]

The thing is that bringing up a GUI window is managed by the window_manager class, not by the GUI dialogue class.
So to be coherent with the design of the GUI, the dialogue GUI class should not be able to open itself.

So the dialogue system should ask first the window_manager to change the GUI mode to dialogue (which open up the window dialogue) and then pass parameters to the dialogue class.
And to switch off the dialogue GUI, that's the same, the dialogue system should ask the window_manager.

(Nearly) each MW-subsystem has one facade class, that is used to access the subsystem from the outside and that exposes as little internals as possible. Therefore routing all the GUI interaction in model -> view direction through the WindowManager class certainly makes sense. Should require very little modifications though. Minor function signature changes and one additional indirection.

And I believe the clickable keyword are the same than those on the topic list?

Correct.

[gus]

Another question: IRC, when talking about some topics with an NPC, new keywords can appear in the list right? If so, the dialogue Manager would have to be told each time a new topic is selected, to be able to update keywords.

[Zini]

Another question: IRC, when talking about some topics with an NPC, new keywords can appear in the list right

And old ones can also disappear.

If so, the dialogue Manager would have to be told each time a new topic is selected, to be able to update keywords.

I guess the easiest method would be to rebuild the topic/keyword list after every user interaction.

[gus]

How can the dialogue window class have access to the dialogue manager class?

[Zini]

The WindowManager gets a reference to the Environment instance, which it should pass on to the dialogue window class in the constructor. The environment class has a pointer to all top level facades, including the dialogue manager.

[gus]

Thanks!

Ps: do you want me to have a look at the render system?

[Zini]

No thanks. I know how to fix it. The thing I really need help with is the crash in the physics system (even if it is not a bug in the physics system itself, the reason why it crashes might tell us about the nature of the bug).