Don't hire a hero in a town where another hero is currently defending against a threat. This would mean one of them has to stay outside and be exposed.
Removed the restrictions of the greedy-playstyle.
Only count forts as gold-producing prerequisites when no same- or higher-level fort exists somewhere else in the empire.
When not threatened by nearby enemies the AI adds missing gold-income-buildings towards gold-pressure. This impacts the build-order in a way that they try to rush these more and get up a good economy more quickly.
Fixed an issue where the part of a 2-tile-unit that is outside of the map was considered a target and caused an endless-loop in the pathfinding being unable to get there.
- Replaced BattleSide namespace-enum with enum class
- Merged two different BattleSide enum's into one
- Merged BattlePerspective enum into BattleSide enum
- Changed all places that use integers to represent battle side to use
BattleSide enum
- Added BattleSideArray convenience wrapper for std::array that is
always 2-elements in size and allows access to its elements using
BattleSide enum
Deliberately defending towns in danger will now only be performed when the town has at least a citatel.
The AI will now count the buildings per town-type and add a score-bonus to dwellings of towns it already has a lot of buildings of. This shall help with getting a stronger army with less morale-issues.
Scoring for mage-guild now increased the bigger the existing armies are.
AI is less afraid of enemy-heros than previously.
When evaluating their fighting-chance against towns with a garrisoned hero the AI didn't consider the attribute-boosts of the defending hero.
Now it does.
A town will no longer communitcate that it doesn't need defenses, when it currently has a garrisioned hero. Because otherwise the garrisoned hero would just leave and let the town undefended.
Fixed a bug that caused tasks that are generated with an initial priority not being executed.
Fixed an error-message wrongfully claiming a hero was locked by STARTUP, when infact the hero was locked by something else (usually a hero-chain).
Recruiting-heros is now handled alongside buying army and buildings.
Delivering troops to mains is now considered a priority 0 task that should immediately be fulfilled.
Defending nearby towns against nearby enemies is now also considered a priority 0 task.
Priority 0 tasks are now exclusively scored by distance and armyloss has only a cut-off-point instead of lowering the score.
Building-cost now has more impact on their score.
Reworked recruit-behavior to be a bit more conservative and avoid recruiting-sprees. Stuff like buying several heros in a row because the next one is always slightly better than the last but using up the whole starting-bank for that.
All text processing code is now located in lib/texts.
No changes other than code being moved around and adjustment of includes
Moved without changes:
Languages.h -> texts/Languages.h
MetaString.* -> texts/MetaString.*
TextOperations.* -> texts/TextOperations.*
Split into parts:
CGeneralTextHandler.* -> texts/CGeneralTextHandler.*
-> texts/CLegacyConfigParser.*
-> texts/TextLocalizationContainer.*
-> texts/TextIdentifier.h
Added building-cost including all resoruces as evaluation-context for more sophisticated building-selection and also as a countermeasure to softlocking a build-order by having no ways to obtain certain resources.
For example, if the AI would drop below 5 wood, while having no market-place and no wood-income it will avoid building any buildings that neither allow trading nor produce wood.
Added trading-logic to Nullkiller-AI.
The AI can now identify which resources it is lacking the most and buy them to fix softlocks in their build-order. It can also sell excess resources that it doesn't have a need for.
Before marketplaces could only be built as part of a requirement for other buildings but not on their own when that other building already existed like it is the case in certain campaign-missions.
There's 3 new evaluation-contexts that are now taken into account:
Whether an action is building, whether an action involves sailing and the newly introduced threat.
The value-evaluation of creatures now also takes special resources into account.
No longer treating other AIs differently than players when it comes to how afraid we shall be of them.
The cost of buildings for decision-making now determines missing resources. Available resources are ignored when it comes to how they impact the cost. But missing-resources will heftily impact the assumed price by calculating their market-value. This shall encourage the AI to rather build what it currently can build instead of saving up for something that it lacking the special resources for.
AI is no longer willing to sacrifice more than 25% of their army for any attack except when it has no towns left.
Revamped the priority-tiers of AI decision-making.
Higest priority is conquering enemy towns and killing enemy heroes. However, the AI will no longer try to do so when the target is more than one turn away and protected by a nearby enemy-hero that could kill the one tasked with dealing with the target. Except when they have no towns left. Then they get desperate and try everything.
As a general rule of thumb one could say the AI will prioritize conquest over collecting freebies over investing army to get something that isn't a city. It's a bit more complex than that but this is roughly what can be expected. It will also highly value their own heroes safety during all this.
Startup-behavior was messing with my intended logic. Mostly by getting excess heroes for no real purpose other than that it could.
This wasted a lot of money that could be better invested on subsequent turns.
I removed it and playing-strength actually went up.
The magic-strength of a hero now checks if the hero has a spellbook and at least one combat-spell.
The impact of knowledge and spellpower to the hero's magic-strength is now also depending on it's current and max mana-pool-size as an empty mana-pool does not exactly contribute well to fights.
Replaced every call of getFightingStrength() with getHeroStrength() which uses both the fightingStrength and the (reworked) magicStrength to guess how much stronger a hero-lead army is.
Fixed that army loss was taken into account both for the path and the target-object. In certain cases, like a hero defending a town, this could lead to armyloss being twice as high as it should be.
Heroes with conquest-tasks will only endanger themselves to be killed when they can execute a conquest in the same turn.
Heroes with other tasks will dismiss any tasks except of defending when they'd be within one turn of an enemy hero that could kill them.
Tasks are now in different priority-tiers. For now there's 2 tiers. One for regular tasks and one for tasks of the new "conquest"-type. Regular tasks will only be considered when no possible conquest-type tasks were found.
Slightly reworked scoring heuristics.
Openmap is no longer tied to difficulty-level due to being configurable anyways.
Tasks are now in different priority-tiers. For now there's 2 tiers. One for regular tasks and one for tasks of the new "conquest"-type. Regular tasks will only be considered when no possible conquest-type tasks were found.
Recruit-hero-behavior is now evaluated before movement to make it more likely a new hero can exchange their stuff with others.
No longer excluding paths for exposing a hero to an enemy in the behaviors. There definitely are reasons for doing something anyways, even if threatened. The logic for that should be done in the PriorityEvaluator.
Supressing hiring army on turn one seems just bad. Starting the main-hero as strong as possible seems like a good idea to me and hiring the available troops outright will help achieve that goal.
However, if there's a hero for hire, who has army with him that is a better deal, we hire that one first.
When we have no hero, we will definitely want to hire one.
We will also want to hire heroes who already pay for more than themselves by coming with an army that has more value than the hero costs.
Fixed a bug that prevented the AI from using spells when attacking an enemy settlement that has towers.
The bug was caused by noticing how greatly effective spells would be against towers but not being able to actually target them.
By skipping invalid targets, this no longer is an issue.
Allowed the AI to cast spells that are aimed at a location instead of a unit. For example meteor shower.
Fixed an issue that caused the AI to not kill unit-stacks with spells due to only considering stacks where at least one unit survives in it's score-calculations.
Fixed a bug that prevented the AI from using spells when attacking an enemy settlement that has towers.
The bug was caused by noticing how greatly effective spells would be against towers but not being able to actually target them.
By skipping invalid targets, this no longer is an issue.
Due to morale-considerations the AI sometimes calculated that their strongest army after doing an exchange had slightly lower total value than the army they used before.
But by using unsigned "slightly lower" became near infinite.
So they constantly wanted to upgrade their army because they considered it more useful than anything else.
Changing the unsigned into signed fixes this.
It is now possible to switch to an AI-variant that uses hand-written heuristics for decision-making rather than the FuzzyLite-engine. This is configurable in nkai-settings.json via the new parameter "useFuzzy".
The information of whether objects like a redwood-observatory or subterranian gates have been interacted with by the AI will now be retrieved from the game-state instead of using an AI-internal memory that won't survive loading a save-game.
Nullkiller suggested that this change would help to further fix inconsistent behavior by the AI. I tested it and it did indeed fix different orders of how AI does things.
"Important to make count 1 to not relay on object addresses
They are source of random" - Nullkiller
Currently closing game while network thread is waiting for something is
very bug-prone, since network thread may resume during shutdown and
access partially destroyed client state.
Now if exit has been requested, the very first step would be semi-
graceful shutdown of network thread (via exception throwing). This may
in theory skip some cleanup in non-RAII code, but since game is shutting
down this does not matters much.
This logic applies to:
- shutting down while network thread is waiting for dialogs
- shuttind down while network thread waiting for animations in combat
