WIP: fix: avoid pushing to quest progress in updateQuestStage #2847

Closed

Sainan wants to merge 7 commits from quest-fix into main

pull from: quest-fix

merge into: OpenWF:main

Conversation 1 Commits 7 Files Changed 4 +40 -30

Sainan commented 2025-10-05 08:58:15 -07:00

Owner

Copy Link

Fixes #2846. The problem in that case was that ordis' message caused the logic in updateQuestStage to increment the quest stage because of an off-by-one (it wasn't accounting for the client's 1-indexing), so the quest was basically finished at that point, which the client then realised upon resyncing the inventory.

Fixes #2846. The problem in that case was that ordis' message caused the logic in `updateQuestStage` to increment the quest stage because of an off-by-one (it wasn't accounting for the client's 1-indexing), so the quest was basically finished at that point, which the client then realised upon resyncing the inventory.

Sainan added 4 commits 2025-10-05 08:58:16 -07:00

fix: avoid pushing to quest progress in updateQuestStage 90da0e5326

fix indexing in giveKeyChainItem a75e2b4c69

avoid resending key chain message f097b28e68

Revert c6a3e86d2b0cb9745c07e8955881e9c4037b0f7a 42552d0ed1

Sainan added 1 commit 2025-10-05 09:09:39 -07:00

fix completeKey 06156bacf0

Sainan added 2 commits 2025-10-05 09:23:07 -07:00

let webui know when client called updateQuest ef1922146a

handle giveKeyChainTriggeredMessage with ChainStage = -1 ... a539b07502

e.g. for railjack build quest, the initial inbox message is sent like this. no 'm' needs to be set to true for it.

Sainan force-pushed quest-fix from a539b07502 to 827e224c3b 2025-10-05 09:23:44 -07:00 Compare

Sainan force-pushed quest-fix from 827e224c3b to 37c2da0f8e 2025-10-05 09:26:31 -07:00 Compare

Sainan commented 2025-10-05 09:47:23 -07:00

Author

Owner

Copy Link

This logic definitely seems a lot more solid now. At least triggering a message doesn't advance the quest unexpectedly but I do see that now the 'm' fields in Progress are kinda off-by-once compared to live which doesn't make a whole lot of sense.

It's possible that the 'm' and 'i' fields for the currently active stage are tracked in some way that's not apparent to the client and then discharged to Progress once that stage has been completed.

This logic definitely seems a lot more solid now. At least triggering a message doesn't advance the quest unexpectedly but I do see that now the 'm' fields in Progress are kinda off-by-once compared to live which doesn't make a whole lot of sense. It's possible that the 'm' and 'i' fields for the currently active stage are tracked in some way that's not apparent to the client and then discharged to `Progress` once that stage has been completed.

Sainan changed title from fix: avoid pushing to quest progress in updateQuestStage to WIP: fix: avoid pushing to quest progress in updateQuestStage 2025-10-05 09:47:56 -07:00

Sainan closed this pull request 2025-10-05 09:58:02 -07:00

Sainan deleted branch quest-fix 2025-10-05 09:58:07 -07:00

All checks were successful

Hide all checks

Build / build (pull_request) Successful in 1m37s

Details

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

bug

An existing implemention is incorrect

dependencies

Pull requests that update a dependency file

documentation

Improvements or additions to documentation

enhancement

New feature or request specific to the emulator

help wanted

Extra attention is needed

improvement

missing data

part of more major rehaul

Can't be worked on right now without merge conflicts later

pr'd for

Soon™

question

Further information is requested

unimplemented

you can do this

Considered easy enough for someone's first PR.

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: OpenWF/SpaceNinjaServer#2847

No description provided.