Dialog.ShowTextParser: Why readonly? Also, StopDialog!!

[monkey0506]

Hi folks,

I was wondering, if anyone has the time, could you make sure I haven't overlooked any technical reasoning why Dialog.ShowTextParser is readonly at run-time? Specifically the reason I would want to change it would be so that I can create a Dialog.RunInteraction(int option) function that wouldn't break if the text parser was being used. The way I would accomplish that would be by storing the current user settings for the various options, turning off the text parser if it was in use, disabling the showing of a single dialog option, running the dialog, and then afterwards restoring the user settings. The text parser is currently the only thing in the way that would break this functionality, and then only if it was in use by the dialog in question.

Seeing as there's no branch in the SVN for the engine, I can't really check in any changes, and I don't see the point behind forking the engine any further for this particularly, but it's something I would be interested in changing (unless there's a specific reason why I shouldn't).

Edit: I've just been poking around, and there's a game.disable_dialog_parser that doesn't show up in the manual anywhere. Let's see if I can't use that then!

Edit: Ah, yes, I'd forgotten about this. There's no way to generically stop a dialog. The StopDialog function only works from within the dialog_request function. So I've got this RunInteraction function working great, except you have to put a random run-script call into every dialog option that you want it to work with. Or you could just make said options end the dialog at the end of their script. Neither is particularly friendly, but I guess either would be at least slightly more friendly than not being able to generically call into the dialog script...

[monkey0506]

I'm not sure that there's a technical reason behind it really, but the current behaviour in the engine is for a dialog with all of its options turned off, upon being started, to throw a hideous and unrecoverable error. I've done some testing with various things (probably going about a fair bit of it "the wrong way"), and I can't seem to see why the preferred behaviour wouldn't just be to have the dialog end if all the options are off.

I'm proposing that this, the latter scenario, be adopted. This would allow us to emulate a proper Dialog.Stop type of method, which is something that I feel is presently lacking. If we're going through all the trouble of making modifications to the engine, it might be worth making the existing StopDialog method simply work outside of dialog_request, but I was just poking around to see what various bits of the existing code were actually accomplishing.