Get all civwide unit discount uniques once, and then filter them by-conditional only when checking each specific unit.
This saves a LOT of memory allocation and time.
A result of the investigation at #5919.
* Update Spanish.properties (#6082)
* Update Spanish.properties
the only thing i didn't translate were the names of the cities if you have any problem contact me on discord like: lostxxxxx
* Update Spanish.properties
problem solved
* Update Japanese translation (#6075)
* Update Japanese.properties
* Update Japanese.properties
* Update Italian.properties (#6074)
Co-authored-by: Hello200000 <98656089+Hello200000@users.noreply.github.com>
Co-authored-by: yuracla <89312848+yuracla@users.noreply.github.com>
Co-authored-by: Giuseppe D'Addio <41149920+Smashfanful@users.noreply.github.com>
* Since we have the old unique typed, and the new replacement unique typed, we can show modders EXACTLY the new unique they'll need to have!
The final step of this process is having a 'replace old uniques' button which will automagically replace old uniques in a mod with the new versions. This will of course require some manual intervention since it's possible we added some parameters that didn't exist in the old one, but should work well for 95%+ of uniques.
* Also allow "[-amount]" replacements
Better replacements - "[+amount]" etc - where relevant
* Fixed misadded + in unique
* Caught more mod failure conditions, removed certain assumptions from map creation
* Military unit in Era can be "Era Specific Unit"
* Resolved#6078 - even more ruleset assumptions removed :)
* We now catch missing military units from the difficulties as well, as well as missing settler and worker units from eras
* Possibly fixed a crash accessing gameInfo before it is initialized
* Inlined an otherwise unused variable
* Alternative version using an extra constructor instead of weird getters/setters
* Gradle build tools upgrade
Apparently the magic is rewriting a specific line in the Android build file and downloading Android SDK 30.0.3
* Added wiki change, isn't that nice :)
Upgrading to 7.1 gives us the fun java.lang.NoSuchMethodError: 'void org.apache.commons.compress.archivers.zip.ZipFile.<init>(java.nio.channels.SeekableByteChannel) error so let's not
* Current map generation is extremely dependant on specific terrains existing in the ruleset.
This attempts to eliminate those dependencies.
All changes indicate areas where a crash occured before the change.
I still encounter problems in generateRegions when trying to generate a map with no water tiles - @SimorCedar I think the splitRegion doesn't like the fact that there are land tiles on edges of the map?
* Split 'equal fertility' regions as close to the center as possible
Also, don't crash if no luxury resources are defined
The cost of casting getEra() constantly is definitely non-trivial, and why do we even generate the era every time? It only changes when we add a new tech! So we can save it as a transient in the civInfo.tech and be done with it!
* 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!
