Greyed out dialogue options

[wareya]

The engine could run the dialogue command in a sandbox and compare it to the previously-seen versions of it. Also, if it contains unique hyperlinks like joining a guild, or it contains inventory changes like taking or giving items, or anything funny like that, it wouldn't be grayed out, even if it's already there.

That would get really complicated fast, though

I would prefer only having graying for "simple" dialogue commands.

[Greendogo]

We could consider more in depth possibilities, such as greying out for simple repeats, but only half greying out more complex options.

Also, I think grey here should just mean a darker tone of the normal color and half greyed somewhere between.

[Jyby]

I would like to be able to toggle this on and off ingame.
Menu option. And I'd like to see a key stroke assigned to this as well.

Here is a compiled list of case, feel free to add:

• Dialogue options with choices that players can make should never be greyed.
  Dialogue options that have been read once should be reevaluated for randomness (e.g. sandbox the response and string compare).
  Dialogue options that have hyper links to dialogue options that have not been read or have not appeared to the player should not be greyed

We also need to also think about how we store and represent the data in the engine.

We can't simply store the dialogue topics with the player by themselves, we'd also need reference to the NPC, since those topics can be slightly different npc to npc (if I recall). But that has problems since referencing a NPC that can disappear from the game entirely is a good way to break someones saved game (we could just easily drop it if it comes to that).

Another way we could store this information is along with the NPC records. They already know how many topics they have and we can index them (unless there's scripts that add topics, then we dont know how many they have). Either way we would need to store reference to the topic and track its grey state. Which also has the potential to break someones saved game if a topic suddenly disappears.

Both ways require us to recalculate the greyness (which could live in the dialogue display code sections). Both ways need to be stored and tracked with references to NPC & topics or just topics in general.

I would like to see this implementation have a failsafe to prevent a game from breaking if a topic reference is lost.

[Jyby]

Sounds neat. Might accept this even before 1.0, if someone really wants to do it.

Zini do I have your permission to do this pre 1.0?

[Zini]

The most basic implementation with greying out based on being clicked at least once for the respective NPC, controlled by a user setting without a GUI I would greenlight immediately.

Topic lists would have to be stored in the CustomData of the respective NPC/Creature instance. Everything else is just too brittle.

Anything beyond that needs further discussion (feel free to open a thread in the development forum). I am particularly not fond of the idea of adding more user settings to the GUI. We can't do that cleanly at this point (no proper localization and such).

We also need an issue on the tracker for this feature.

Also the impact on saved game files need to be considered. We don't want to blow them up unnecessary. I guess storing a list of used topics should be fine. Compatibility with existing save files is also an important point since apparently plenty of people are already playing on OpenMW. Loading an old saved game should result in all topics flagged as unread.

[scrawl]

You don't need to store anything. The list of seen responses is stored in the journal already.

We also need an issue on the tracker for this feature.

There is one already.

[Zini]

It seems we are storing the actor name, which is actually a bit problematic, because we could easily have two completely different actors with the same name.
This also does not cover the case of several NPC instances of the same NPC object. Even if each instance acts the same that would feel kinda odd, e.g. Having topic x greyed out for Guard B after speaking about it with Guard A. And it will fall fully apart when we have different instances of the same object acting differently (because of different state).

[scrawl]

Why would you handle it per actor? If an actor gives you a response to a topic, and you've already heard the same response from another actor, then that topic should be greyed out, right? The idea is to grey out topics that aren't "interesting" to the player, and the various lore that Morrowind attaches to pretty much every actor in the game sure does not qualify as interesting if you've already heard it.

And it will fall fully apart when we have different instances of the same object acting differently (because of different state).

Not sure if I follow. If the actor's different state causes a different response to a topic, then the topic list would search for that particular response in the journal to determine the greying out state. Works as expected?

[Zini]

Why would you handle it per actor? If an actor gives you a response to a topic, and you've already heard the same response from another actor, then that topic should be greyed out, right?

The actors may not give the same response. Also we can have side-effects from a script that work on a per-actor basis.

The idea is to grey out topics that aren't "interesting" to the player, and the various lore that Morrowind attaches to pretty much every actor in the game sure does not qualify as interesting if you've already heard it.

I think the idea was more to flag topics that aren't relevant anymore, because they would do nothing but present the same text again that the player already read. That is not quite the same.

Not sure if I follow. If the actor's different state causes a different response to a topic, then the topic list would search for that particular response in the journal to determine the greying out state. Works as expected?

So you would not only check for the topic, but also for the response text? That's at least how I understand this statement. Didn't think of that. Makes kinda sense, but does not cover the possibility of side effects from the scripts.

Actually, I am okay with this approach. At least as a first iteration of this feature, because it would not introduce any new saved game data and it would allow us to refine it later without worrying about compatibility with existing data.

[scrawl]

I think the idea was more to flag topics that aren't relevant anymore, because they would do nothing but present the same text again that the player already read.

That is exactly what I meant:

sure does not qualify as interesting if you've already heard it.

"already heard it", as in, the player has been given this same response before.

So you would not only check for the topic, but also for the response text? That's at least how I understand this statement

I thought that was implied from the beginning. Chris wrote on page 1:

The engine should be able to figure out which dialog entry a given link will lead to ahead of time. So rather than flagging the topic as heard/unheard, flag the target dialog entry. It should then only gray out if the player has read the actual response before.

The actors may not give the same response

You mean generic responses like "I am %name, %class." that get formatted with the actor's name and class? Well, given that generic replies can't be quest-relevant (or particularly informative, for that matter), I imagine it's not a big loss.

As an aside, there may be issues with the "clearInfoActor" command, which is often used on these generic replies to prevent them from displaying in the journal. When clearInfoActor is called, the response most recently added to the journal gets removed. That means certain topics would never be flagged "read". We could work around that though by making clearInfoActor flag the journal entry as hidden instead of deleting it.

Given all the possible complications summed up in this thread I suggest to add the feature post-1.0.