Rework of party member quest progression PR #769

[rfortier]

• Definitely is not compatible with 1.8.0 servers.
• PR Several dialog & subtitle improvements in the way Scenes / Cutscenes … #854 is a prerequisite and should be merged first. After it is merged this should be rebased and might need a tweak.
• PR IsSlowTime fix caster, not target #858 is not a hard prerequisite, but fixes a cosmetic issue.
• Large credit to @miredirex for RE:: logic and insight, and @powerof3 CommonLibSSE for having already figured out some things we needed to know.

The community loves Members being able to advance quests (instead of only Party Leader), but it introduced a bunch of problems with duplicate quest triggers. This rework deals with it (hopefully).

A large credit goes to co-author @miredirex for reverse engineering a couple more methods to make this work, especially having more awareness of when a Player is in a scene (BGSScene) or not. That's one key to making cutscenes sync, or at least sync much, much better. That, and deduplicating the storm of duplicate attempts to advance the quest stage that was introduced with Member-can-progress-quests PR #769. That introduced several bugs that are fixed here.

A lot of the effort in this PR was figuring out the real-world situations in which quests can and cannot rewind, and making sure the fix supported that. You can find the information in ck.uesp.net starting with SetStage(), but it isn't all consolidated in one place. Find comments in the code, it's too long and complicated to re-explain here (likely introducing errors)

The most fundamental problem found in the old code is that ScopedQuestOverride() doesn't work, because in many cases quest progress is executed on a different thread; the ScopedQuestOverride() is destructed before the quest OnEvent...() routines are invoked. So all the Members send their updates to the server even when told not to. The server just ignored them all before, but now with Member quest progression enabled, it ends up causing replicated quest updates. Some quests ignore it, many break.

The engine is in control of the content of events passed to the OnEvent routines. I could not find a reliable way to pass any context to the OnEvent routines through that barrier (it runs async, so matching up was nigh-on impossible). So ended up implementing a dedup history server-side, where there is enough context to figure this out.

The worst-case flow (when a Member triggers progress), is:

1. Member sends update.
2. Update is forwarded to Leader, only.
3. Leader OnEvent hooks send the Leader update to the server.
4. Leader SendsToParty
5. Party members reflect their updates to the Server, but are dropped by the dedup history because the Leader has already sent it.
6. Entries in the dedup history time out in seconds (needs some tuning), so quests can rewind and stages can be triggered multiple times to evaluate.

There's also logic to keep track of the SceneMaster, the player that initiated the scene. This has proven to be less useful than hope, it was to be used to sync everyone's Scene state to the SceneMaster. But the scene start/stop routines have so many side-effects, the logic made things worse more often than better. So now, state is tracked in case we find more use for it, but largely doesn't do anything.

The one exception: players can get stuck in dialogues that have been answered by the SceneMaster. Most times, they are fixed by a quest stage transition, but I have seen scenes that don't end with a quest stage change. So Scene End triggers a forced quest stage change. It's ignored by the client if they've already done it, so this one helps more than it hurts.

Partial support for Remote actors to run AI packages when in-Scene That comment in the commit is obsolete, the support was yanked as too incomplete.

[rfortier]

Substantial logic change. Remote updates received while playing a scene are ignored. Unless they include a SceneEnd flag. Those updates are sent when a scene ends and forces everyone to accept the update to catch up.

Many variations of scene support have been tried, this seems to be the best compromise.
When in a Scene, ignore updates from other players. Each player runs the scene and generates their own progression.
This mostly works for scenes that are "movies," but if the scene requires player interaction, one player makes the choice (usually, the one who started the scene, but if the party stands together they might all get the dialog prompts, for example). The scene progresses for that player, everyone else is "stuck" there.

Unless multiple players click the option to continue. That's often going to do something unpredictable, don't do that.

To unstick players, at Scene End, send a "poke" quest stage update that is not deduped, to catch everyone up.

A future improvement may send such a poke every time player interaction causes a quest stage change, but have to figure out how to detect that.

[rfortier]

Did a submission cleanup pass. Deleted all the dead (#if 0) code that didn't work or didn't help. Kept as a separate commit so you can see that code and the notes on why it didn't work if anyone works on this in the future.

Turned down all the logging to a more modest amount. There are a couple of [critical] logs that aren't exactly errors, they are still experimental code paths that haven't been fully tested because they have not yet been seen in the wild. I might know where one is hiding, though.

It's ready for review. I've gotten the critique already that it is "too big," but most of that is logging. It's a repeating pattern of setting up a bunch of state / status variables so they can be used in log messages, and then a lot of logs, what it took to figure out what was happening or broken, and then proving the fix in a rapid-fire distributed state machine.

Could delete the logging now that it works, but I don't recommend it. I think there are still more edge cases we will find, and we'll need the same logs to fix the AI Package support, which will fix several more cases where the party Leader must be the one to advance the quest.

The heart of the change is in the two QuestService.cpp files. Most of the rest is RE:: support and an easy read.