Attachment 1: Heres a new game with 1.26b and China expanded early onto a spot with 6 base plots of jungle, maybe this needs to be fixed?
Attachment 2: Turfan built on gold, good idea for them to do that or not?
Turfan looks like it's in a good spot to me. It's a desert gold, so it's not a great tile to work, and it gives him a 2 commerce city-plot, on a hill for extra defence, it meshes well with his other cities; and it gets the cow... So I reckon Turfan is fine.
That jungle city is also in a decent spot, but it's probably not a good choice for the first expansion, because it can't do much until iron working. Still, his options for expansions were actually pretty limited - so I think it's ok.
huh,
so i can add xml tags into the dll files with no worries?
does oos errors mostly cause from python files?
thanks.
I see. Previously you mentioned new civics, and buildings, and units; so I thought maybe you just meant xml changes only. But now I see that you mean adding dll code to support new types of xml tags. It's hard to say whether or not this will cause OOS errors, because it really depends on the specifics of the implementation of the new fields. But it's probably pretty safe. In general, OOS errors are created when there are things in the user-interface which can affect the state of the game. To avoid OOS you just have make sure that the only way the player can affect the state of the game is by issuing commands. eg. build such-and-such, move this unit here, and so on. If simply pointing to a leader's name can change something, then that could be the cause of an OOS error.
For example, pointing to a leader's name may cause the game to recalculate the leader's attitude rating, which may cause it to reassign its worst-enemy, or something like that, and thus change the outcome of future AI decisions. The most recent OOS problem I fixed was a bit like this. If OOS errors are to be avoided, then the key is to make sure that anything which can change the state of the game will happen simultaneously for all players. Most changes are pretty safe. The dangerous places are in the AI, random events, python controls which change the way the game works, and anything related to cache in the dll...
Probably a minor bug...
Took a city and about 4 or 5 turns later, ai poisons its water supply...but its still "in revolt" for another 4 or 5 turns, so its not losing population.
Well, many versions ago I told the AI to take the revolt time into account when evaluating poison / foment-unhappiness. Maybe the poison was still a bad idea, but I don't think it's a bug. I'm sure they had their reasons...
Im also seeing alot of ais, by pass rifling, and go for railroad, scientific method, and even biology...and they are paying the price in almost every case.
Edit2: I took the mongol capital 3 times (different cities) as I was taking over all his cities and he would never vassal me, even up until his last city. Werid. Maybe its because he had 2 vassals?
I agree that the AI undervalues rifling a bit. The thing that confuses the AI about rifling is that riflemen very
general purpose, which is unlikely pretty much every other unit in the game. Riflemen in their prime are the best city defenders, and the best city attackers, and the best general fighting unit; whereas most other powerful units do not have such a broad appeal. Anyway, the AI currently doesn't really take that broad appeal properly into account - and so riflemen are somewhat undervalued in some games. (What tends to happen though is that if a strong civ gets cavalry, then every other civ will suddenly realise it's a good idea to start getting rifling...)
As for when civs will vassalate. I haven't looked at that much. It's still the original AI. (or maybe the BBAI AI, I'm not sure). Anyway, I haven't changed it yet. But I can tell you that it's quite an arbitrary calculation.. it depends on the number of units killed and the position on the scoreboard and stuff like that. Generally, units with vassals will be difficult to vassalate because their vassals are always below them on the scoreboard.
