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.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).
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.when the odds of a repeat response having a different effect is (next to) nil.
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.Zini wrote:I have a problem with basing our design decisions on this assumption:
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.when the odds of a repeat response having a different effect is (next to) nil.
Agreed. That's already part of the plan for improved localisation that I am going to put forward once we reach 1.0.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.
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.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.
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.Maybe we could go for reasonable defaults and later add script instructions that allow greying/un-greying a topic.
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.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.
