Grey out read dialogue topics

Everything about development and the OpenMW source code.
User avatar
Jyby
Posts: 408
Joined: 10 Dec 2013, 04:16

Grey out read dialogue topics

Post by Jyby » 15 May 2015, 18:21

Idea: Read dialogue topics are greyed out (i.e. the topic text in the selection column of the dialogue gui is slightly greyed out).

Things to consider:
  • Do we have to refer to individual NPCs or a global journal?
    How do we record read topics (parse player journal? save CustomData?)
    How do we recover from lost topics? (e.g. mod removal)
    How do we limit the impact on our existing saved games?
    Do we need to follow topic hyper links in order to determine if the topic is greyed?
    Do we need to generate a sandboxed response to look for randomness?
There is a lot here that needs to be considered. If we can greenlight a simpler version we should definitely figure out how to make it extensible.
Macbook Air 2013 - 1.7GHz Intel i7 - 8 GB - 512 GB SSD - Intel HD 5000
Windows 10 PC - 4GHz Intel i7 - 16 GB - 512 GB SSD - EVGA GTX 1060 SSC

User avatar
Zini
Posts: 5536
Joined: 06 Aug 2011, 15:16

Re: Grey out read dialogue topics

Post by Zini » 15 May 2015, 19:31

As explained in the original feature request thread this is called off for now. Sorry for everyone who got their hopes up. I still think that this is an important feature to have.

User avatar
Zini
Posts: 5536
Joined: 06 Aug 2011, 15:16

Re: Grey out read dialogue topics

Post by Zini » 16 May 2015, 07:30


Golken
Posts: 27
Joined: 04 May 2015, 05:03

Re: Grey out read dialogue topics

Post by Golken » 22 May 2015, 00:11

I don't think it will be problematic if you flag by individual dialog responses, and add some special but simple exceptions that make a response never be flagged:

- The response contains a script or global var (I think this is possible to do?). Even though this probably almost never happens. No need to check for generic stuff that won't ever change like %PCRace, etc. You may or may not want to treat the NPC's attributes (class, race? name?) as an exception, which will effect whether topics like Background can become grayed out.
-The response contains a script or global var or certain functions in the result, such as: Choice, AddItem, RemoveItem, Add/RemoveSpell, StartScript, StopScript, AI functions, rank modifying functions, journal modifying function...
I guess you could even blanket if you want by checking for any function at all in the result, or even a non-empty result (after all, even that drastic filtering should catch all the generic lore responses anyway).

That thread mentioned simulating and comparing the text of the response to previously-heard ones. I imagine this could be done easily by adding a list of CRCs of every heard dialog text to the save, or something to that extent, though I can't imagine right now how this would be better than the aforementioned behavior, maybe I'm missing something. At any case, I'm not sure why you'd need to store info with the NPCs/creatures themselves at all.

Lastly, even though I think I covered dynamic, remember, even if a topic is somehow grayed out accidentally, it doesn't mean it's removed, and it isn't the end of the world. Also, and it would seem to be true of others as well, when I say "grayed out" it doesn't mean literally gray and looking disabled-ish, like a button in Windows; we use "grayed out" as a shorthand here for a different color shade (think of a visited hyperlink).
I don't feel the scare of making this a post-1.0 feature, since it'd be turned off by default and only enable-able through config editing, anyway.

Chris
Posts: 1559
Joined: 04 Sep 2011, 08:33

Re: Grey out read dialogue topics

Post by Chris » 22 May 2015, 01:43

Golken wrote:- The response contains a script or global var (I think this is possible to do?). Even though this probably almost never happens. No need to check for generic stuff that won't ever change like %PCRace, etc. You may or may not want to treat the NPC's attributes (class, race? name?) as an exception, which will effect whether topics like Background can become grayed out.
-The response contains a script or global var or certain functions in the result, such as: Choice, AddItem, RemoveItem, Add/RemoveSpell, StartScript, StopScript, AI functions, rank modifying functions, journal modifying function...
I guess you could even blanket if you want by checking for any function at all in the result, or even a non-empty result (after all, even that drastic filtering should catch all the generic lore responses anyway).
Like I said in the other thread, I'm not sure how much of a problem this will even be (for a single dialog response to give different script/function results on different invocations). I think it would be silly to make such responses never gray out just because they contain a script or global var, when the odds of a repeat response having a different effect is (next to) nil.

The only responses that I can see not being grayed out are the ones that are part of a randomized group. But even that could be (eventually) fixed by pre-calculating which random entry will be selected.

User avatar
Zini
Posts: 5536
Joined: 06 Aug 2011, 15:16

Re: Grey out read dialogue topics

Post by Zini » 23 May 2015, 10:23

I have a problem with basing our design decisions on this assumption:
when the odds of a repeat response having a different effect is (next to) nil.
That may be true for Morrowind.esm. But we can't know for sure if there isn't an unreleased work-in-progress TC out there that makes heavy use of such a feature.

Chris
Posts: 1559
Joined: 04 Sep 2011, 08:33

Re: Grey out read dialogue topics

Post by Chris » 23 May 2015, 12:26

Zini wrote:I have a problem with basing our design decisions on this assumption:
when the odds of a repeat response having a different effect is (next to) nil.
That may be true for Morrowind.esm. But we can't know for sure if there isn't an unreleased work-in-progress TC out there that makes heavy use of such a feature.
I'm not really sure I'd consider it a feature. I think if you're going to have a dialog response do something different, it should be a different dialog response. If you need it to have the same dialog text, and it's too much to keep synchronized, we could think of ways to efficiently share text between responses*. But if it acts differently, it's logically a different response, IMO.

* Externalizing the text into separate language-specific resources may be a good idea anyway, when localization is considered. Don't want to fall into the same trap vanilla did with needing entirely different esms for different languages.

User avatar
Zini
Posts: 5536
Joined: 06 Aug 2011, 15:16

Re: Grey out read dialogue topics

Post by Zini » 23 May 2015, 15:22

Well, if you like it or not, people will eventually going to use it. And considering the amount of modding that has happened with MW so far, they probably have already.

Anyway, different responses aren't even the point here. As mentioned before replies can have side-effects via scripts. These might be useful/desirable multiple times in which case it might very much make sense to never grey out the topic.

Maybe we could go for reasonable defaults and later add script instructions that allow greying/un-greying a topic.
Externalizing the text into separate language-specific resources may be a good idea anyway, when localization is considered. Don't want to fall into the same trap vanilla did with needing entirely different esms for different languages.
Agreed. That's already part of the plan for improved localisation that I am going to put forward once we reach 1.0.

Chris
Posts: 1559
Joined: 04 Sep 2011, 08:33

Re: Grey out read dialogue topics

Post by Chris » 23 May 2015, 16:20

Zini wrote:Well, if you like it or not, people will eventually going to use it. And considering the amount of modding that has happened with MW so far, they probably have already.
OpenMW already requires adherence to certain non-vanilla scripting rules, which knowingly causes some mods to break; all the things vanilla's script compiler allows, which OpenMW willfully doesn't. This, on the other hand, is just a simple visual cue that in no way impacts the functionality of anything (a topic being grayed out would not prevent it from being selected if it needs to be), and as such it cannot break anything. At most, a few mods that may do a dialog script 'faux pas' will have some unexpectedly colored topic links. Compared to some other things OpenMW does, which results in some mods never being able to work, I can't see this as worth worrying about.
Maybe we could go for reasonable defaults and later add script instructions that allow greying/un-greying a topic.
It would make sense to add script functions to switch a dialog entry to/from being grayed out, yes. Having that in conjunction with the aforementioned behavior (of topics being grayed out when they lead to a dialog entry that's already been read before) should give everything modders need to handle whatever cases they may run into.

User avatar
Zini
Posts: 5536
Joined: 06 Aug 2011, 15:16

Re: Grey out read dialogue topics

Post by Zini » 24 May 2015, 09:43

OpenMW already requires adherence to certain non-vanilla scripting rules, which knowingly causes some mods to break; all the things vanilla's script compiler allows, which OpenMW willfully doesn't. This, on the other hand, is just a simple visual cue that in no way impacts the functionality of anything (a topic being grayed out would not prevent it from being selected if it needs to be), and as such it cannot break anything. At most, a few mods that may do a dialog script 'faux pas' will have some unexpectedly colored topic links. Compared to some other things OpenMW does, which results in some mods never being able to work, I can't see this as worth worrying about.
I think we have a misunderstanding here. I was not arguing that imperfect greying out behaviour would be a substantial issue. I was merely pointing out that for considering what is a substantial imperfection and what is not the assumption you made was problematic.

Personally I don't think having some imperfections here is a big issue as long as the feature can be disabled and assuming we later deliver additional tools like the mentioned script instructions that allow modders to fix these imperfections.

Post Reply