Refactor list structures, change list base class to a generic observable list #2072
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
|
Download the artifacts for this pull request here: GUI:
CLI: |
Miepee
reviewed
Mar 28, 2025
Miepee
approved these changes
Mar 28, 2025
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.
Description
Refactors all of the list classes inheriting from
UndertaleListBase<T>, which itself is no longer an abstract class, and has been renamed toUndertaleObservableList<T>. This allows data models to take advantage of observable collections for lists that need to unserialize usingInternalAdd()(for performance purposes), when those lists have an irregular format in the WAD that the other lists can't handle. This functionality is currently unused in this PR, but will be taken advantage of in at leastUndertaleGameObjectin a future project system PR, for the list of physics vertices.In general, I took to cleaning up and commenting all of the list code, as well as moving try/catch statements outside of loops to reduce their overhead. I have no idea if this has any noticeable impact on performance, but if it does, it's probably marginally faster now.
Caveats
There's probably an extremely small chance something has been broken with these changes, but I ran through my whole game test suite and everything saved/loaded identically byte-for-byte, as usual (and the tool operates as normal).
Notes
It's a little bit hacky how the base observable list has to use reflection to get and modify an internal member of
Collection<T>, but it was already that way previously, and I'm not sure if we have any better alternatives. Perhaps a future PR could address that, if there is another way.