3 ms·
If you look at the code linked to for the OoT decomplication, it's centralized in a single file everyone would be committing to https://github.com/zeldaret/oot
by hbn 1y ago
If you look at the code linked to for the OoT decomplication, it's centralized in a single file everyone would be committing to
https://github.com/zeldaret/oot/blob/4d2bc68bacdff06261f7a89a24b63bf4eec97487/include/save.h#L524-L552 https://github.com/zeldaret/oot/blob/4d2bc68bacdff06261f7a89...
- AshamedCaptain 1y agoThat is not at all representative of how the original code would have looked like. At all. I am tired of people assigning pseudo-magical properties to "decompilations" while at the same doublethinking them as a way to launder copyrighted works.
- sandinmyjoints 1y agoYeah looking at that is what prompted this question. Are the events in order? If so: the index for an event in the bitmap is constant, so if you realize you need to save an event that wasn't previously being saved, how do you insert it to keep order? Do you break all previously saved data by changing all the following indexes? Or are the events not in order, which could make it harder to find if an event is already in it (and just generally be confusing)? Managing a long list of events like this given that it is used for persistent state seems like an interesting process challenge.