I've started a branch for v0.97b – not much in it yet except the changes for
@Cruiser76; I'll add more (as more issues are discovered) before making a proper release.
- Better handling of per-instance (unit production cost) modifiers and impassable terrain and feature types
- Addresses minor issues with the 2nd AI settler having to wait for an escort sometimes
- Some minor tweaks to the evaluation of potential starting sites
- Tiles with goody huts are no longer off limits as starting sites; the hut gets removed if its tile gets chosen as a starting site.
- Fixes a rare bug that had caused Barbarian Galleys to get "stuck in a loop" – probably inconsequential, but had triggered an assertion. Also disables an assertion about AI civs on strike during anarchy.
DLL:
final-release build |
assert build
Took a while to work out how "impassables" should affect AI group formation. Not sure if I really got it right either. The basic approach is now that no unit in a group must have more restrictive movement rules than the unit that leads the group. That group leader controls the behavior of the whole group and is determined, as before, mainly based on UNITAI type (function AI_groupFirstValue). For example, UNITAI_SETTLE has the highest priority for group leadership. So, if a Settler can enter, let's say, all terrain/features and a Warrior can't enter Desert, then the Warrior can't join the group and thus can't escort the Settler – because the Settler would remain the group leader. If a Settler - different example - cannot enter Jungle and Snow, while an Infantry can go everywhere except Jungle, then the Infantry is allowed to join the Settler. If the newcomer and group leader have the same AI_groupFirstValue – perhaps both are non-siege city attackers –, then joining is only allowed if they have the exact same impassables (not just the same number impassables). As I type it down now, it seems pretty clear that a suitable
number of impassables should never be sufficient for joining a group; set inclusion needs to be checked really. As it is, Infantry that can't enter Desert could still join a Settler that cannot enter Snow and Jungle (but can enter Desert). Not sure if that would really be a problem, but it's at least inconsistent.
[...] The game was acting very buggy and crashing when I would leave the game window.
I've noticed a bug in my old code (now replaced) for handling InstanceCostModifiers. It had treated unit type ids as unit class type ids; that could've crashed the game erratically through out-of-bounds array accesses.
Potential bug: I was at war with a particular AI and we made peace. A few turns after the mandatory no war period expired, this AI offered me a peace treaty in exchange for two cities. We were not at war.
If it was just one city, then I'd assume that this was actually a gift or tribute dialog. Those show the implied peace treaty as a trade item now. But I don't see how the AI could ask for two cities at once that way. From looking at the code, I also don't see the AI could enter peace negotiations while at war or get confused about being at war. The code for that is pretty straightforward.
Edit: AI is routinely including peace treaties with normal trade offerings.
That's OK if they're help requests or tribute demands, i.e. if there's only the peace treaty on your side of the table. If they're actual trade offers, then something is wrong.
From Classic to Future:
10 - 20 - 30 - 30 - 20 - 10
Thanks; nice that this does the job – doesn't sound too drastic.
) the AI is a huge improvement over unmodded BtS.
