Improve builtin extraction detection and QoL #2865
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to address a few bugs and quality of life improvements for the built in extraction flow:
There was a bug where if a rom was auto detected in the folder, but you select "Find rom", the current rom size is updated, but the file stream is not cleared, so nothing happens when reading the new rom data, and instead the old detected rom data is still stored. This will either lead to incorrect CRC errors, or the wrong XML set is used in ZAPD causing a crash.
To address this, the file stream is now being cleared and closed properly every time a rom is read.
Manual selection was also not converting the rom data to BigEndian, which would cause CRC errors. Now all rom data no matter which path your take is converted to BE.
The quality of life changes added now allow the ability to search for both game types, or specifically vanilla or MQ. This comes into play when generating OTRs back to back, so which ever you generate first, the next run through will filter for the opposite game type.
The new flow is now:
No OTRs on launch -> prompt to generate -> auto detect all roms -> detect which game type was generated first -> prompt for generating a second OTR -> restrict auto detection/manual selection to the opposite type
When the search mode is restrict, if the use goes the manual selection route and selects the wrong game type, a new prompt will appear indicating as such, and ask to select again.
Build Artifacts