* Step 1 - converted stat bonus list to tree.
No visual difference yet, since the stat bonus list is still generated in the same way.
* Step 2 - updateStatPercentBonusList converted to tree form
* Step 3 - buildings converted to tree form - now user visible!
* Step 4 - Bonuses from uniques are now drilldownable
* Removed unneeded todo
* Welp, turns out I forgot to apply conditionals
Due to changes since that was written, the cityInfo.getMatchingUniques has a default parameter of 'local uniques that are of the unique type', so not only was it making a mess, it was also inefficient!
* Added a json file for unhappiness effects
* Change existing code to handle these effects
* Made a weird and unexpendable way to add unhappiness effects to the civilopedia
* Add the default unhappinesseffects to mods without the json
* Added revolts when at very low happiness
* Renamed a few often-used functions
* Added a file for uniques that are always active
* Fixed tests
* Nullifies [Food] -> Nullifies Growth
* Initial attempt
* Allow Ranged to move into unguarded Civilian Unit
* Comment for clarity
* Fix unit test so that it doesn't segfault and checks you can't move into military units
* Unify that all units can move on to (and through) unguarded civilians that you are at war with
Add TileInfo.getUnguardedCivilian() to quickly respond if there is an unguarded Civilian on the tile
Something is bugged in movement code
* Fix MapUnit.moveThroughTile() so that it doesn't segfault by fixing getUnguardedCivilian()
* captureCivilianUnit() call is now redundant in postBattleMoveToAttackedTile() since canMoveTo() will now return true and capture will happen during the moveToTile() call
Co-authored-by: temurakami <spellman23@gmail.com>
* Converted stat list to stat tree - current changes do not affect UI at all, since we're still going by the shallow mapping that existed beforehand
* Display details of both buildings and uniques
* Unique stats now add correctly to building base stats, good thing we have tests :)
* Stat details are now click-to-expand, and calculate correctly :)
* Added small +/- button to show it's expandable
* Typed some uniques, etc.
* Missed a few square braces
* Missed a parameter
* Missed another parameter
* Made a conditional, spelling, added check to `isStatRelated`
Co-authored-by: Yair Morgenstern <yairm210@hotmail.com>
This also means we don't need a special coastal check, since it's caught by the regular check
IIRC there are nations in Original Civ that have 'mountain' start bias - if so this will also enable that :)
* Remove unused Constants.
* Remove outdated comments.
* Typified "Will not be displayed in Civilopedia" Unique.
* Fix pre-existing inconsistency that would display religious UBs with broken links in the Civilopedia when religion was disabled.
* Use Sequences, and fewer function params, in Nations' Civilopedia texts.
* Accidentally hid a Unique that should be visible.
* Oops… Missed a negation.
* Unhide limitations on Religious Ruin rewards— But I'm not sure they'll be displayed anywhere even so.
* Typified some building uniques
I noticed that the code allows "[stats] from every [buildingFilter]" but the UniqueType was limited to "[stats] from every [buildingName]", so now that that's available we don't actually need the "[stats] from every Wonder" unique :)
* buildings-only unique moved to buildings section
* Make unknown nation placeholder translatable.
* Make MultiplayerScreen help button clearer and translatable.
* Use `Constants.spectator` more.
* Make random/unknown nation icon translatable.
I tested this out with RekMOD, 150 simulated turns, to see if this was working.
Not only did I discover that workers were squatting on Antiquity Sites since they had resource improvements that they couldn't build, I also discovered something much worse.
Even after fixing that, most cities were woefully underimproved.
Turns out, the construction automation would limit worker construction to a measly *3 workers* even for a *10 city* civ!
After removing this limitation and making civs aim for a 1:1 ratio between cities and workers, everything started looking much, much better.
I'm not sure what the exact effect on the AI will be but I'm _sure_ that this leads to a major improvement. More improved tiles means more stats means more everything.
I came to the mod management screen to add a functionality to download the latest version of an installed mod by adding a 'download latest version' button to its action menu.
I did not expect the code to be this intractable. I've been reading and writing Kotlin daily for the past 5 years now, and even I struggle to understand what's going on here.
(also instead of adding button and counting duplicate entries just to remove them from both UI and count, just - don't add them to begin with)
The same change we made in the move to getStatsFromUniquesBySource()
This should be faster, more generic, more accurate (buildings vs wonders), and catch all usecases (i.e. stat bonuses from uniques attached to *techs* or who knows what else
* Worker AI for mods, step 2
Support for removing terrain features, both when we need to get rid of them for a resource, and when they plain reduce the yield of a tile
Note that the "Remove <improvement>" was implemented WAY before templating and uniques were a thing - the correct solution in these enlightened times would be to separate the improvement *name* from the *effect*, so we could have e.g. a "Deforestation" improvement which would contain botth ["Removes [Jungle]", "Removes [Forest]"] or whatnot.
For now I Constant'D the "Remove " so we can at least follow where it's used.
* Reverted some of the auto-formatting so the PR is cleaner
* Caught 'nullify yields' unique for terrain removal
* Use toTextButton for WorldScreenTopbar "Overview".
* Use toTextButton for AddMultiplayerGameScreen "Paste gameID from clipboard".
* Use toTextButton in MultiplayerScreen.
* Use toTextButton for CityOverviewTable city.name.
Current worker automation assumes A LOT about the current ruleset.
This is only step 1, which allows skipping irrelevant improvements to reach actually useful improvements.
Comments welcome.
The NewGameScreen was written by a past version of myself that had no idea how to handle threading, and thus was extremely strange. Checking an object _on render_ and if it's set then activate? Totally clueless.
