Add support for dynamic predecessor mapgen #52208
Merged
Conversation
This file contains 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
jbytheway
force-pushed
the
mapgen_can_rely_on_predecessor
branch
from
d9f6f53 to
e9ed28d
Compare
BrettDong
added
Map / Mapgen
The idea is that some oter_ts are just a modification of the existing terrain, and we want to remember what that terrain was and generate it before proceeding with the mapgen for the current terrain. We implement this by adding a flag to the oter_type indicating that it needs to save predecessor information, and a fallback predecessor terrain to the mapgen. This serves two purposes: allowing it to opt in to this feature, which means it is no longer forced to define terrain for every location, and defining a fallback oter_t to use in the event none is stored in the overmap (which can happen, e.g. when the mapgen definition changes between overmap mapgen and tile mapgen for a particular OMT). Use the new feature for anthills, so that they blend better into their surrounding terrain. Expose predecessors in the debug overmap editor for debugging purposes.
jbytheway
force-pushed
the
mapgen_can_rely_on_predecessor
branch
from
e9ed28d to
8ac05a0
Compare
|
clang-tidy kindly reminded me that I must serialize the new overmap data. Fixed now. I also added debug visualization of predecessor terrains in the overmap editor. |
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.
Summary
Infrastructure "Add support for dynamic predecessor mapgen"
Purpose of change
The idea is that some
oter_ts are just a modification of the existing terrain, and we want to remember what that terrain was and generate it before proceeding with the mapgen for the current terrain.Describe the solution
We implement this by adding a flag to the
oter_typeindicating that it needs to save predecessor information, and a fallback predecessor terrain to the mapgen. This serves two purposes: allowing it to opt in to this feature, which means it is no longer forced to define terrain for every location, and defining a fallbackoter_tto use in the event none is stored in the overmap (which can happen, e.g. when the mapgen definition changes between overmap mapgen and tile mapgen for a particular OMT).Use this new feature for the anthill.
Describe alternatives you've considered
Could have switched these OMTs to use
update_mapgenrather than plain mapgen.Testing
Spawn some anthills; see below.
Additional context
Here are some pictures of anthills in various terrains:
Previously all anthills appeared in mostly grass with a few bushes.