* 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.
