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.
PR is to move capitalCityIndicator, as it
previouslydoesn't make sense in the city code. Starting as a draft because there are many, many, many questions. I wish I PR'ed this a while ago before "uniqueTo" became something you can filter from as many aspects made more sense before thenIndicatesCapital
unique does not use conditionals.City.isCapital
uses getUniqiues instead of getMatchingUniques, which inherently ignores condtionals.CityConquestFunctions.destroyBuildingsOnCapture
uses hasUnique, but this is not given a state, so it usesEmptyState
instead ofIgnoreConditionals
, auto-failing any civ/city check. previously, this function also used hasUnique without a state, thus having the same problem. This PR changes it to specifically use IgnoreConditionals for consistency withisCapital
and uniqueTo can multiFilter, there is a question of which state this should use. I would assume IgnoreConditionals here as well, not the civ's state or the city's state like I erroneously used prior. This PR as of writing this keeps the incorrect behavior of the previous PR, but I can easily change it backuniqueBulidings
cache. This isn't a particularly complicated bit, but it does force the question of when we want to check the filter as what to cache changes based on when we want to check for filtersSide note, regardless of those points, the changes to
Civ.moveCapitalTo
to keep the code functioning as it did prior. kotlin's smart casting isn't recognizing thatcity
can't be null if the indicator isn't null