Rename fd_reality_tear back to fd_fatigue (fix tilesets, migration) #73958
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.
Summary
None
Purpose of change
fd_fatigue was renamed to fd_reality_tear in #72708, but we do not have any migration handling for fields. This causes existing instances of the field to throw errors on load and disappear (as a valid field cannot be found for them).
Additionally, because the ID has changed the tilesets no longer have an entry for them. This causes them to revert to their
looks_like
of smoke. The actual graphics are pretty cool, so I'd like to keep them.Describe the solution
Revert this naming change.
Describe alternatives you've considered
Implement migration handling and figure out the tileset incantations to move its sprites around?
Testing
Load this save without the patch, notice field errors and no tears in reality exist on load:
FIELDS NAME-trimmed.tar.gz
(Without saving) Load after patch, notice fields exist and look like they should on all tiles builds with in-repo tilesets
Additional context
This causes the reverse problem for builds created between April 4th and the merging of this PR, in that fd_reality_tear generated in saves between them will disappear. This is not ideal, but the issue will not occur for anyone moving from 0.H--->a hypothetical future 0.I, which is desirable.