Skip to content

Conversation

@leggettc18
Copy link
Contributor

@leggettc18 leggettc18 commented Oct 13, 2023

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.cpp and randomizer/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

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 garrettjoecox merged commit 92028aa into HarbourMasters:develop-rando Oct 19, 2023
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.

2 participants