Sorry for not replying earlier, it's been a busy week at university. Gotta love statistical thermodynamics. I'm writing this with a significant sleep debt, so my apologies for typos and if I seem a bit flippant or have missed something.
This would be an improvement in so many cases. For example, the Civ that's building wonders that is attacked, yet can't build anything new in any of it's cities for 20 turns.
Wonders are the only thing the AI is allowed to interrupt, but it only does so if an operation has been requesting units from the city for the past (AI_CITY_SPECIALIZATION_REEVALUATION_INTERVAL) turns.
The AI loses it's settlers waiting for an escort more often than if they were to go out on their own. If the Settler stayed in the City, this would be an improvement.
[...]
1. Settlers and Workers have to be protected. They are walking towards barbarians they've seen before. The ideal solution would be to have them consider that area extremely dangerous, and then send out a barbarian squad to deal with them.
Today, they walk directly into obvious trouble. I'd take the AI knowing everything about Barbs over this situation. A simple AI always takes into account Barbs as if they knew where they were is a significant improvement, and is fairly close to human perspective.
I just think it's closer to right than current code.
This was one of the main reasons I started rewriting the DangerPlots code from scratch in mid-January; in the unmodded game, each tile keeps track of the sum of the combat strengths of all visible, enemy units that could attack onto the tile within 2 or 3 turns. It currently works exceptionally in my v10 dev build in most cases (the AI not only distinguishes between units that can move onto a tile and those that can only ranged attack onto a tile, but it also knows precisely how much damage any unit could suffer on a tile, leading to more accurate healing and retreat code), but there are still plenty of rough edges to smooth out. For example, the AI cannot properly recognize enemy units that can attack from fog, leading to some hilarious situations where an AI will sit its crossbowmen within range of enemy longbowmen and just leave them to die; this was still the case in the unmodded game, it's just amplified tenfold by the new DangerPlots due to how much other systems rely on DangerPlots' new accuracy.
My solution at the moment is to keep the minimum number of units defending the homeland much lower, and have all unit types as optional escorts for the Settler. I would post the full solution if I felt it was fantastic, but there are still issues with it, and I don't feel it is "ready" yet.
I'm not sure how you got all unit types to act as optional settler escorts: operations only support one primary and one secondary unit type (adding multiple secondaries should not work), and single-hex operations (which include both the regular settle city and the settle-city-on-another-continent operations) are not programmed to be able to account for more than one land unit escort (sea escorts are fine), the same way they're not programmed to account for multiple civilians or sea-based civilians (eg. admirals).
That's great. The issue I have is that the first unit starts as explore, and remains as explore no matter what. This is odd when a unit upgrades from a goody hut, and remains an explorer when he could be used to 1. escort a settler, 2. defend the homeland, 3. be a part of an attack. (clearing barbs, or whatever)
I'll be honest, the way non-scouts are automatically allocated and unallocated to and from scouting is still a bit mysterious to me. Yes, I've read over the algorithms a bunch of times and even made a few modifications to fix some bugs (eg. if an unmodded AI accepts the embassy of a player on another continent, it will start allocating a large portion of its land army to scouting and then send them out to attempt to scout the fog surrounding the other player's capitol, even if they'd need to cross an ocean and don't have ocean embarkation yet), but the whole thing still doesn't *click* for me the way, say, operations have.
Hmm, and now that you mention upgraded scouts from ruins, I also haven't checked to make sure there aren't any problems with scouts upgrading to units that do not have a UnitAI_Explore flag.
There is also a large problem in my opinion that a Settler determines where it will settle, and then starts to move there. The position they would settle is only reevaluated when they arrive. This causes settlers to move many turns to a location, only to turn around and move many turns to a new location.
I'd prefer a settler reevaluating after every step, it's that important of a decision.
That's definitely doable, especially since I swapped out settler evaluation to use the pathfinder instead of distance. I know that the Community Patch has implemented something similar, though AFAIK, theirs only reevaluates on arrival to the original target. I'll see what I can do after I figure out why Great Generals just sit around in cities all the time in v10. It's probably a mistake in the new DangerPlots. It has always been a mistake in the new DangerPlots. *sigh*
All of my work is done on Prince. I am trying to make competitive AI on prince. When I run a Deity test of the work I've done, it's absurdly unstoppable.
[...]
I don't disagree there are a challenges, but I don't think it's as difficult as you're expressing. There is so much in the default setup that is completely unoptimized.
Running a game of your mod, vs. a game of my edits + your DLL is a completely different experience. My AI is leagues harder due to simple changes.
I.E. I agree it won't be perfect, but we're not even past bad, and I think we can reach good.
Hmm, I may be underestimating the power of flavors then. It's still not something I'd prefer to rely on, but if the unmodded flavors are truly this unoptimal, I guess a few tech flavor changes won't hurt.
I've been eying some of WHoward's Lua script system insertions and wondering whether I can create something for flavor modifiers, ie. allow mods to modify the flavors of items based on Lua scripts. The main advantage would be for mods that add items with very specific effects: for example, a Petra-like wonder would be able to modify the wonder's food and production flavors based on the amount of eligible tiles within working range using a Lua script, rather than forcing the modder to either deal with static flavors or have to rely on C++ code. It would certainly have its limits (Terracotta, for example, since it not only needs to check for nearby units when selecting the wonder, but also make sure enough units stay in range when it completes), but it should do for most cases.
The main problem here is a bit complicated to explain as I see it, but I've essentially corrected it for my usage.
Instead of going from small numbers, to larger numbers in the flavors, I've flipped it. With higher numbers earlier in the tree.
This allows me to force the AIs hand in directions. The problem with flavors currently is the numbers are so high deeper in the tree, that the AI will start beelining for a Tech without getting important techs before it.
Looking at the actual flavor values, it seems like Firaxis just filled them out on a whim with very little thought into how much a flavor value of, say, 20 or 50 actually means. Based on AI log files, it seems that techs' flavor propagation doesn't work as consistently as I thought it would. I also just realized another problem stemming from the way lategame techs' flavors propagate downwards: since the AI always compares total flavor values for techs, useful lategame techs will always have less total flavor values than less useful earlygame ones simply because there are less future techs whose flavors will propagate downward. I'm sure there's a way to solve both problems at once by altering the way flavors propagate in the tech tree, I just haven't figured out how... not yet, anyway.
When I implemented this in Civ 4, I used Python and if thens to get what I needed. I don't see how to do that with Civ 5, so I am using the Flavors to do a version of this same concept. It's working, but it's annoying to debug. You literally have to test it repeatedly, and I don't see logging to indicate to me which Civs are running which flavors. More logging info would save me tons of wasted time, if you are aware of how to get explicit AI details.
If you
enable logging and AI logging (via setting AILog = 1) in the Civ5's config.ini, the game will print detailed .csv logs into My Games\Sid Meier's Civilization 5\Logs about almost every AI-related decision. One of those logs, TechAILog, displays all information related to what techs the AI chooses: whenever the AI must choose a tech, all available techs' flavor values are logged as well as what tech the AI chose (it'll be the one with the highest flavor).
If you want to have separate logs for each civilization, make sure to set PlayerAndCityAILogSplit = 1 in config.ini. Also, make sure you clear the log folder after each game (you'll need to quit Civ5 to do so), or else subsequent games' logs will be appended to existing logs; this a minor nuisance at worst if you don't split logs for each civilization (since everything's just appended to one log file), but it can be quite a pain if you split logs.
I'd say it doesn't work, or I'd have seen it given how many tests I'm doing.
It's a very situational thing: the code will only fire for units that can attack after moving after they've attacked a target that has not died from the units attacking it that turn. The unit must be able move to a safer spot from which it can move and attack the target next turn. Due to these conditions, it's highly unlikely to trigger for melee units, and since I still haven't gotten around to having the AI make sure it keeps units with a lot of promotions alive, Keshiks are really the only case where the code will probably fire.
One thing that consistently drives me nuts is the AI doesn't select a build order when they build a city, or complete a new build order at times.
You can see it easily whenever the AI settles. They don't select a build order until the next turn. This slows down their ability to rush items, and all sorts of other things.
I haven't done testing to see if they are actually losing hammers because of this, if they are actually slower than a human player. Can you look into this? This seems like it would be a big help, but perhaps I'm misguided here.
Unless I'm wrong, the AI will choose a city's production right before production is tallied up and spent, so no turns or hammers are actually being lost. If anyone wants to double check, cities' production is tallied and spent in CvCity::doProduction(), which fires off an AI_chooseProduction(false /*bInterruptWonders*/) right at the beginning for AI/automated cities that are not producing anything or are working on a process (Wealth, Science, World Congress Project).
2. The AI goes directly for Guilds because of the weight of the Guild buildings. It rushes the wrong part of the tech tree to be competitive.
It has to go Philosophy no matter what.
My idea is to just increase everyone's science flavors, and make the science flavors match the ways to get Science.
There is no good strategy that involves ignoring Science.
You have to build Libraries, the National College, Universities, and Public Schools. The faster you do it, the better military you'll have.
Rushing Currency just kills your competitiveness.
... Guilds' 20 Gold flavor is just ridiculous, especially since things like having negative income boost gold flavor as well. Outside of AuI's special, multiplicative science flavor boost (all building, policy, and tech science flavors are multiplied by 8, 4, or 2 if the AI is in at least Classical Era and missing techs marked as "crucial" to their prominent Grand Strategies: Archaeology and The Internet for Culture, Globalization for Diplomacy, etc.), there are no real ways any of Philosophy's three flavor types (culture, science, religion) get boosted throughout the game; Culture and Spaceship Grand Strategies boost them a little, but it's not nearly as much as all the flavor modifications of Gold, Growth, Expansion, Production, Offense, and others from city strategies, economic strategies, and military strategies. Tech flavors were assigned with no regard to what they unlock: even though Philosophy unlocks one of the most important science buildings in the game, it actually has less science flavor (3) than Optics (5).
3. UPDATE Defines SET Value = '12' WHERE Name = 'AI_OPERATIONAL_BARBARIAN_CAMP_DEPLOY_RANGE'; -- Default 2
The AI will completely allow Barb Camps to spawn and won't defend themselves. Just take out the threat.
I don't think altering that value has the effect you think it does. The deploy range is the maximum allowed distance between an operation's true target and deploy target. The true target is the operation's actual target (enemy city, barbarian camp, etc.), while the deploy target is the tile to which the operation's army moves; when the army reaches the deploy target, its movement code is handed over to the tactical AI, the AI class that handles all non-passive, non-scouting, and non-worker moves (those are handled by the homeland AI). If you increase the value to 12 from 2, what you're doing is allowing destroy barbarian camp operations to deploy 12 tiles from the target camp instead of 2, possibly leading to unintended side-effects of units wandering off away from the camp instead of attacking it, or units with more movement speed than other units in the army rushing ahead to engage the camp alone before the others can catch up (the operation AI performs "move-as-a-group" corrections, but the tactical AI does not).
I have been playing around with having city states do this too. They might as well get some experience.
It's pointless, city-states don't have an operation AI from what I can tell, so they will never create or run a destroy barbarian camps operation, among others.
Also, the AI doesn't have any clue when it's civilians get taken. You'd expect a squad of the guys they have to go fix it, but they do nothing. They could have their entire territory filled with units ready to war, and not go get the 3 settlers they lost.
This is a problem inherent to the model of operations controlling groups of units; if you wanted to stay within the operation model, you would have to create a new operation specifically for stealing back civilians from barbarians, then make sure that operation can accept every military unit type (which would either require rewriting the formation recruitment code or creating four clones of the same operation to cover every unit type), then make sure there are no conflicts with other operations (a much harder task, since you might get overlap between this operation and the destroy barbarian camp operation, which gets increased priority if the camp contains a captured civilian that originally belonged to the current AI player).
Instead, I may start experimenting with "hunting" algorithms in the far future. Even if I let the AI cheat and always know where its captured civilians are, it would still need to know what unit(s) to send. The primary purpose would be to farm barbarians for XP in peacetime, since this is probably the easiest to test and debug, but they could be used for a bunch of other stuff, including hunting down captured civilians.
Plus it'd be nice to say that the mod has a
hunter-seeker algorithm.
Part of the Settler problem is they are patrolling.
Settler (32770) patrolling to, X: 30, Y: 25, Current X: 30, Current Y: 26
It would be better to just leave them in the capital until a unit is available. Patrolling puts them in harms way without an escort.
Patrolling is just simply what the homeland AI does when it can't do anything else with a unit. I don't exactly know off the top of my head how and when the homeland AI gains control of settlers (since it should be just the operation AI and tactical AI handling them), but patrolling shouldn't normally be an issue in AuI (civilians would patrol to dangerous tiles in the unmodded game, this was supposedly fixed in AuI v8) so long as its DangerPlots are accurate... which brings us back to the dysfunctional DangerPlots system pre-v10...