Probably best to have it at 3.6.2 branch where it's still in beta and we can test with a bunch of old games and see if it doesn't happen to break anything, and later it may be just a bugfix that isn't backported - I think if the current behavior was an issue in some old game, something would have cropped up from the ScummVm testers.
This sounds like it would work great. I think it would give the expected behavior as an adventure game even though it may not be as consistent when think purely as a programmer (that would expect the nested dialogs).
Quote from: Crimson Wizard on Sun 27/10/2024 18:32:18When Dialog.Start is called within a script, it's actually scheduled to run after script completes, similar to ChangeRoom, and few other things.
So, this "post-script" execution seems a convenient place to do this.
I found a possible trick: while processing this scheduled command, check if we are inside a dialog, and then not start a new dialog loop, but override the script's return value that is going to be passed back into the current running dialog loop. This return value contains a instruction of what to do (stop dialog, switch to another topic, etc).
In a way, Dialog.Start called within a dialog script will work more like a postponed "goto-dialog".
This sounds like it would work great. I think it would give the expected behavior as an adventure game even though it may not be as consistent when think purely as a programmer (that would expect the nested dialogs).