-
Notifications
You must be signed in to change notification settings - Fork 465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: Room/Scene Timers #2478
Enhancement: Room/Scene Timers #2478
Conversation
Checklist for remaining items before this can be considered ready for review:
|
Opening for review to get more eyes/playtesting on this. |
SaveManager::Instance->LoadArray("timestamps", ARRAY_COUNT(gSaveContext.sohStats.timestamp), [](size_t i) { | ||
SaveManager::Instance->LoadData("", gSaveContext.sohStats.timestamp[i]); | ||
SaveManager::Instance->LoadArray("itemTimestamps", ARRAY_COUNT(gSaveContext.sohStats.itemTimestamp), [](size_t i) { | ||
SaveManager::Instance->LoadData("", gSaveContext.sohStats.itemTimestamp[i]); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this change means that old timestamps will not be loaded into the new struct properly. Normally when a json change happens, we have to introduce a new LoadBase vX function. However this is non-critical information that will not break in-game functionality.
Curious others thought about this. do we want to add another base func and support the old timestamps to be loaded, or are we fine with old timestamps getting lost.
My gut feeling is I'm fine with losing the old timestamps. I think this is also probably necessary since the old timestamps included more than just "item" timestamps, so they probably wouldn't be able to be brought over correctly anyways without some strange parsing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, losing timestamps if you load a save from an old build isn't a big enough problem to warrant building out migrations
@briaguya-ai sorry for the ping, just making sure this didn't fall off the radar re: review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall this is looking great! left a few comments, some that are small and can probably be addressed quite easily. some that feel out of scope for this PR but came to mind when i was looking through it.
shouldn't take long to address those and resolve merge conflicts, once that's done this should be good to go!
} | ||
|
||
const std::vector<std::string> sceneMappings = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this feels similar to sceneNames
in util.cpp
but it's different enough that i can understand having it here
would be nice to consolidate stuff like this at some point but this is far from the only example of duplicated strings throughout the codebase, definitely not something that should block merging this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly did not know that utils.cpp
existed, but I think sceneMappings
does have some more user-friendly names. Definitely not a bad idea to combine the two containers
gSaveContext.sohStats.sceneTimer++; | ||
gSaveContext.sohStats.roomTimer++; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could be cool to refactor to use hooks here, but since we're already using playTimer
without them that feels out of scope for this PR. probably worth making a new issue for refactoring stats tracking to use hooks.
u8 idx = gSaveContext.sohStats.tsIdx; | ||
gSaveContext.sohStats.sceneTimestamps[idx].scene = gSaveContext.sohStats.sceneNum; | ||
gSaveContext.sohStats.sceneTimestamps[idx].room = gSaveContext.sohStats.roomNum; | ||
gSaveContext.sohStats.sceneTimestamps[idx].roomTime = gSaveContext.sohStats.roomTimer / 2; | ||
gSaveContext.sohStats.sceneTimestamps[idx].isRoom = | ||
gPlayState->sceneNum == gSaveContext.sohStats.sceneTimestamps[idx].scene && | ||
gPlayState->roomCtx.curRoom.num != gSaveContext.sohStats.sceneTimestamps[idx].room; | ||
gSaveContext.sohStats.tsIdx++; | ||
gSaveContext.sohStats.roomNum = roomCtx->curRoom.num; | ||
gSaveContext.sohStats.roomTimer = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks pretty much identical to what's happening in z_play.c
, what's happening in this method that isn't being covered by the logic there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
z_play.c
specifically scene transitions, whereas this snippet handles specifically room transitions. z_play
has similar code to handle certain respawning states, such as warping from DMC to DMC or falling in the lava there (which causes a voidout); in some cases, voiding out of a scene will cause the room number to change but not the scene number, so that's for some edge cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this is good to go!
(Attempts to) resolve #2459.
Build Artifacts