Skip to content
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

Merged
merged 18 commits into from
Apr 3, 2023

Conversation

stratomaster64
Copy link
Contributor

@stratomaster64 stratomaster64 commented Feb 15, 2023

@stratomaster64
Copy link
Contributor Author

stratomaster64 commented Feb 17, 2023

Checklist for remaining items before this can be considered ready for review:

  • Allowing the scene/room timers to run when paused? - current behavior is that both timers stop, same as playTimer, when the game is paused. Would require being aware of the amount of time being paused while in the scene, which uses a different framerate divisor than during gameplay.
  • Allowing the user to have less granular timestamps shown - current behavior creates a timestamp everytime a new room is entered (which includes loading a new scene as well)
  • Pausing timers when entering a scene only to play a cutscene - for example, when starting a vanilla game, timestamps are created for Link's House > Hyrule Field > Kokiri Forest > Link's House before gaining control.
  • Mapping of scenes to names - current behavior is exposing the scene number to the user, as opposed to the familiar name (Scene 80 instead of Hyrule Field).
  • Cleanup - Not actually required.

@stratomaster64
Copy link
Contributor Author

Opening for review to get more eyes/playtesting on this.

@stratomaster64 stratomaster64 marked this pull request as ready for review February 28, 2023 05:13
Comment on lines -1285 to 1295
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]);
});
Copy link
Contributor

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.

Copy link
Contributor

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

@stratomaster64
Copy link
Contributor Author

@briaguya-ai sorry for the ping, just making sure this didn't fall off the radar re: review

@stratomaster64 stratomaster64 requested review from Archez and briaguya-ai and removed request for Archez March 16, 2023 01:25
@briaguya-ai briaguya-ai added the merge conflicts PR has conflicts that need to be resolved before it can be merged label Apr 2, 2023
Copy link
Contributor

@briaguya-ai briaguya-ai left a 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 = {
Copy link
Contributor

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

Copy link
Contributor Author

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

soh/soh/Enhancements/gameplaystats.cpp Outdated Show resolved Hide resolved
soh/soh/Enhancements/gameplaystats.cpp Outdated Show resolved Hide resolved
soh/soh/Enhancements/gameplaystats.cpp Outdated Show resolved Hide resolved
soh/soh/Enhancements/gameplaystats.cpp Outdated Show resolved Hide resolved
soh/soh/Enhancements/gameplaystats.cpp Outdated Show resolved Hide resolved
soh/soh/Enhancements/gameplaystats.cpp Outdated Show resolved Hide resolved
Comment on lines +1122 to +1123
gSaveContext.sohStats.sceneTimer++;
gSaveContext.sohStats.roomTimer++;
Copy link
Contributor

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.

Comment on lines +651 to +660
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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@briaguya-ai briaguya-ai removed the merge conflicts PR has conflicts that need to be resolved before it can be merged label Apr 3, 2023
Copy link
Contributor

@briaguya-ai briaguya-ai left a 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! :shipit:

@briaguya-ai briaguya-ai merged commit ff1d8a9 into HarbourMasters:develop Apr 3, 2023
@stratomaster64 stratomaster64 deleted the even-more-stats branch April 3, 2023 23:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

gameplay time breakdown
3 participants