Background
src/Engine/Core/CoreParser.aslx stores two pieces of per-turn parser state on the shared game object instead of game.pov, even though the closely related state around them (currentcommand*, currentcommandresolved*) is already correctly scoped to game.pov:
game.lastobjects (CoreParser.aslx:355, read at :529-535) - the objects resolved by the previous command, used so a following command can refer to them by pronoun/article/gender ("look at it", "take it").
game.unresolvedcommand, game.unresolvedcommandvarlist, game.unresolvedcommandkey (set in UnresolvedCommand, CoreParser.aslx:726-739; read in CoreCommands.aslx:861-871) - the pending state for a disambiguation-style "what do you want to X?" follow-up prompt.
This engine doesn't support concurrent multiplayer - game.pov is a single, switchable "currently controlled character" pointer (see the ChangePOV function and the changedpov script hook in CoreTypes.aslx:81-83). Because these two pieces of state live on game rather than game.pov, they aren't reset or re-scoped when ChangePOV runs. Concretely:
- If a script calls
ChangePOV while an unresolved/ambiguous command is still pending an answer, the next typed input can be misapplied as the answer to a question that was actually asked of the previous POV character.
- After switching POV, "it"/pronoun resolution via
game.lastobjects will still refer to whatever the previous character last looked at/took, not correctly reset for the new one.
The ask
Move game.lastobjects and game.unresolvedcommand/game.unresolvedcommandvarlist/game.unresolvedcommandkey onto game.pov, consistent with the rest of the per-command resolution state, so this state is naturally scoped per-POV instead of leaking across a ChangePOV call.
Background
src/Engine/Core/CoreParser.aslxstores two pieces of per-turn parser state on the sharedgameobject instead ofgame.pov, even though the closely related state around them (currentcommand*,currentcommandresolved*) is already correctly scoped togame.pov:game.lastobjects(CoreParser.aslx:355, read at:529-535) - the objects resolved by the previous command, used so a following command can refer to them by pronoun/article/gender ("look at it", "take it").game.unresolvedcommand,game.unresolvedcommandvarlist,game.unresolvedcommandkey(set inUnresolvedCommand,CoreParser.aslx:726-739; read inCoreCommands.aslx:861-871) - the pending state for a disambiguation-style "what do you want to X?" follow-up prompt.This engine doesn't support concurrent multiplayer -
game.povis a single, switchable "currently controlled character" pointer (see theChangePOVfunction and thechangedpovscript hook inCoreTypes.aslx:81-83). Because these two pieces of state live ongamerather thangame.pov, they aren't reset or re-scoped whenChangePOVruns. Concretely:ChangePOVwhile an unresolved/ambiguous command is still pending an answer, the next typed input can be misapplied as the answer to a question that was actually asked of the previous POV character.game.lastobjectswill still refer to whatever the previous character last looked at/took, not correctly reset for the new one.The ask
Move
game.lastobjectsandgame.unresolvedcommand/game.unresolvedcommandvarlist/game.unresolvedcommandkeyontogame.pov, consistent with the rest of the per-command resolution state, so this state is naturally scoped per-POV instead of leaking across aChangePOVcall.