george112n
commented
1 year ago It appears that the issue was being caused by the fact that every stage was always started at the step defined in the Lesson object, which never changes. When not resuming a lesson, this is simply always 1 so stages are always started at the first step. When resuming a lesson, this is set to whatever step they are at when they resume, and never changes.
One solution to this is to change the iStep in lesson to be iResumeStep to clarify that this is the step to resume a lesson at, not the current step and to then change nextStage() to not use iStep if it is not resuming a stage. Either by creating a resumeStage() method which DOES use iStep or having nextStage() take a boolean input of bResumingStageAtStep or having nextStage() take in an int always.
The firstly mentioned option costs space and all the processing power it saves by avoiding an if branch as appears is option 2 is completely negligible. The lastly mentioned option is more sustainable because it allows for future use of specifying the starting step of a stage. The adding passing of integers is negligible. Thus option 3 shall be used. It also encourages step to be specified whenever using nextStage() which should prevent further such issues whenever this method is used.
Sometimes, when saving the position of a player in a tutorial, when they rejoin, they will end up having skipped a step.
When resuming on Stage 1, Step 2, once completing this, it will remove straight to Step 2 of Stage 2 and skip Step 1 of Stage 2.
There doesn't appear to be any other combination of stages and steps which causes this, although I suspect if there was a Stage 3 then the same issue would occur when resuming the last step of stage 2.