prevent teammates from syncing QuestStop events for incomplete quests

[otsffs]

For example, in the Companions’ radiant quest “Trouble in Whiterun”—where the player is sent to break up a brawl in the streets—team members often misinterpret the fight’s outcome. Even when the Leader has successfully resolved the encounter (e.g., by making the aggressor yield), some teammates may incorrectly register the quest as failed on their end. As a result, they unintentionally synchronize a “stop quest” command back to the Leader, forcibly halting the Leader’s active quest and corrupting their progress.

[rfortier]

It's more complicated than this, isn't it?

~~As written, if Player is Member and the quest isn't started, it means the Member can't start quests. The whole point of your Member progression PR #769 was to let them do that. ~~ Oops, this is delivery of event, not a request. Read too quickly. If a regular request is completed by a party member, the completion is ignored is the actual bug. Most quests we want members to be able to turn in.

Isn't there a bigger ordering problem also? Let's say the quest is running and N>0 Members are the first to notice the brawl is ended and they stop the quest. They are making these decisions independently, so in theory they could ALL successfully stop the quest in their individual BSTEventResult QuestService::OnEvent() routines, and all notify the server. The leader's decision may be generated before or after all of those, and separately may be processed on the server before or after.

This used to be OK cuz only the leader could advance the quest state, and when they did they broadcast the state to the Members of the party. There was supposed to be code to prevent the Member from reflecting changes back to the server, but it doesn't work (engine quest events are on a different thread than the one OnUpdate() comes in on, so the ScopedQuestOverride doesn't actually work).

The stuff I'm working on to stop reflections makes things a bit simpler but does not address what this PR does. Conceptually, distributed consensus with the decisions distributed in time (but bounded). That's too hard, would normally be solved by having a "decider."

How many examples like this are there? It may be a patch to the script for this one quest to say only the person actually brawling is the decider. If there are lots of examples we need to survey a few of them to find a pattern we can lock onto.