-
Notifications
You must be signed in to change notification settings - Fork 632
Rando Definition Deduplication #3284
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
Merged
garrettjoecox
merged 142 commits into
HarbourMasters:develop-rando
from
leggettc18:rando-refactor-dedup
Oct 19, 2023
Merged
Rando Definition Deduplication #3284
garrettjoecox
merged 142 commits into
HarbourMasters:develop-rando
from
leggettc18:rando-refactor-dedup
Oct 19, 2023
Conversation
This file contains hidden or 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
The parameters were rearranged for easy copy-paste from the GET_ITEM macro calls later on.
Array is all that is needed, since the item list will be contiguous and indexed by the RandomizerGet Enum values.
Up through bottles, many more items still to go.
Also added constructors that put the GET_ITEM_NONE data in for these items, since there is no corresponding GetItemEntry for them.
These are present for GetItemEntry purposes, and aren't really meant to be used in seed generation (unless we find a need for it later on.)
It's now a pointer to memory instantiated on the heap in the constructor. These are shared pointers so the memory is freed if any of the item instances get deconstructed (which they shouldn't but just in case.)
Also replaces calls to the ItemTable method with StaticData::RetrieveItem
This allows importing them without causing weird conflicts in cpp files when importing the z64scene.h and z64actor.h files directly. Now you can just import z64scene_enum.h and z64actor_enum.h instead. The two old files also import these new files so that existing setups still work as expected.
garrettjoecox
approved these changes
Oct 15, 2023
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.
A large chunk of an ongoing effort to bridge the gap between our runtime rando code and 3drando seed generation code. As of this PR, Items (RandomizerGet) and Locations (RandomizerCheck) now use tables located in
randomizer/item_list.cppandrandomizer/location_list.cpp, which contain data that was previously split between tables on our end and tables in the 3drando folder. There is also a separate item_location table that stores data that changes during runtime.This can and will be taken farther, for instance right now the item_location table does not get used in-game, only during seed generation. This should be a fairly easy gap to bridge, just haven't gotten to it yet. Should just need to load save data into this table instead of the current tables. Related to that, ithe item_location table should probably just be used as is directly after seed generation, rather than needing to parse a spoiler file and use the current separate tables in-game.
PR-ing this as is because it is already massive, and is, as far as I have tested, functionally equivalent to the current system as far as the end result goes. This should DEFINITELY be playtested pretty heavily before merging.
Build Artifacts