Artificial Unintelligence
- Thread starter Delnar_Ersike
- Start date
So I can't use Whoward's DLL with this at the same time? He has Ninakoru's mod merged, but not yours?
Indeed you cannot, this mod was developed from the original, unmodded DLL, not WHoward's, because I wanted to start off on a clean slate. [...] That said, I am planning on merging this mod's DLL with the Community Patch's after v10 is released, and AFAIK, the Community Patch is based on WHoward's DLL.
Will that mean v11+ (if you are still developing it at that point) will be based on the CPP's DLL base, or will you still be using an AUI-only DLL for development?
By merger, I mean that all functionality afforded by the CPP's DLL will be made available in AuI's DLL [...] Once this has happened, AuI will still continue as its own separate mod, but it will allow people to toggle and mess with features implemented by the CPP's DLL through XML/SQL and Lua. [...]
Does all that [I understood little] mean you mod [awesome job, btw] will be compatible with Whoward's? Or that he'll be able to tweak his to be compatible with yours? Or did I get it all wrong?
Delnar_Ersike
Prince
It means that I'll essentially be copying over the code sections that are included in CPP's DLL (which is based off of WHoward's DLL, but has its own stuff as well) that aren't in the unmodded DLL. This would mean that once the effort is finished (which I am not planning to start until I release v10, mind you), it would be as if AuI's DLL were built using the CPP's DLL as its base instead of the unmodded game's. This means that should the CPP (and possibly WHoward) wish to port AuI's changes to their mod, I'll already have resolved most, if not all, merge conflicts, so they'll have to spend hours at most on porting instead of days or weeks.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,171
Dev line of Art Int from last night -
Workers are now occasionally running off into the distance. Like, scouting almost. I will need to check the unit movement, but it's odd. 2nd build order was a worker, and he just went off. My best guess looking at the logs is the worker was trying to get a goody hut?
Settlers are still controlled by homeland AI, and still walk right into barb capture because of it. Settlers need to not roam around the territory, and instead stay in the city or one tile away.
Workers are now occasionally running off into the distance. Like, scouting almost. I will need to check the unit movement, but it's odd. 2nd build order was a worker, and he just went off. My best guess looking at the logs is the worker was trying to get a goody hut?
Settlers are still controlled by homeland AI, and still walk right into barb capture because of it. Settlers need to not roam around the territory, and instead stay in the city or one tile away.
Delnar_Ersike
Prince
I'm currently making another pass at my DangerPlots changes in the dev branch so that it can properly used by TacticalAI for attacks so that the AI will try to lose as few units as possible during its attacks. I'm also going have another pass at ExecuteAttack() and am in the process of implementing separate functions for finishing off units and cities so that the AI will make proper use of units that have effects when defeating enemy units (capture chance, health gain, faith gain, etc.), try to maximize XP gain, attempt to position Great Generals before an attack to maximize combat bonuses (now that queued attacks are removed), and will try to finish off cities with the weakest unit they can that will still capture the city, especially if the city could be retaken the turn after by their opponent.
The downside is that 1) commits are not going to come until I've finished with the implementations, and 2) anything that uses DangerPlots (including automated workers) will move weirdly until I've sorted things out.
The downside is that 1) commits are not going to come until I've finished with the implementations, and 2) anything that uses DangerPlots (including automated workers) will move weirdly until I've sorted things out.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,171
You're likely already aware of this, but I've been crashing on the barbarian turn for the first turn with the experimental build. Occasionally I'll get to turn 2 before the crash. No idea how to analyze it, but assume you're just working on it.
ThunderLizard2
Prince
- Joined
- Oct 6, 2010
- Messages
- 301
Running v9 and it's VERY slow late game - over 5 minutes per turn. It's a pangea plus map normal size/epic speed. It takes a long time on City-States (there are 8) and on some civs which only have 1 city left. Not usable at this point give the speed.
Delnar_Ersike
Prince
Yeah, that was caused by a typo, I fixed it in a commit pushed a few minutes after the initial slew. I'm currently tracking down an infinite loop which may or may not be present with the latest commits.
For future reference, if you compile with a debug flag, it'll generate a .pgd (debug database). If you include the .pgd in the mod (with VFS) and attach the Civ5 process to VS, you'll be able to troubleshoot crashes and/or infinite loops: for the former, VS will direct you to the line that caused the crash as well as the call stack (useful for patching overlooked null pointer deference possibilities), while for the latter, you can just pause the Civ5 process whenever you think the game thread has entered an infinite loop (or force a minidump), at which point you can see which loop is causing the problem after you browse to the game thread (it'll either be the loop enclosing the currently executed line or a loop enclosing a function in the call stack).
If VS doesn't like your machine (neither 2008 nor 2013 like mine), you can also use the Windows Debugging Toolkit to look at minidumps; I prefer the debugging toolkit to VS because I have a lot more control over what source files and what debugging symbols I load up, whereas VS doesn't give me any control.
Do note that when you're running a version of the DLL with optimizations turned on, the currently executing line that VS or the debugger displays may not necessarily be correct; you'll notice this especially when the problematic code is located in an inlined function (the debugger will point to the inlined function's call instead of the problematic code within the inlined function). The only way to work around this is to compile a DLL with all optimizations turned off.
It's kind of unavoidable, unfortunately, and it might get worse in v10. The slowness is caused by the AI using the pathfinder (the bit of the game that calculates the best movement path from a tile to another tile) a lot more than it did in the unmodded game, and the pathfinder is kind of a mess code-wise: it works, but that's pretty much the only good thing I can say about it (bad things include: it's single-threaded, it has a lot of redundant checks and calls pre-v10, it has room for caching certain data values then doesn't cache those values pre-v10). Ironically, the feature that is most likely responsible for the unenjoyable slowdown is the one that is probably the biggest AI improvement in v9: move-and-shoot, accurate move-and-shoot as well (the one in Ninakoru's Smart AI might run a bit faster, but only because it's ignored for siege units and units with range 1). When AIs go to war, they need to calculate where all of the enemy ranged units can move-and-shoot (as well as their own), and each AI player runs their own calculations, including city-states: this means that if an AI player with 2 CS allies goes to war with another AI with 3 CS allies, 7 AI players end up performing move-and-shoot calculations from that single war alone. As the game progresses, the AI creates more and more (ranged) units, so more and more move-and-shoot calculations need to be run, causing those really slow turns.
The only way to really "fix" the issue in v9 is to play on smaller maps, on a lower difficulty, and/or with less AIs: smaller maps cut down on possible tiles to move-and-shoot from as well as on AI units, lower difficulties cut down on AI units and warlike AI behavior, and less AIs cut down on the amount of AI players that run almost-redundant move-and-shoot calculations (eg. if 3 AI players are warring the same fourth player, all 3 need to perform the same move-and-shoot calculations for every one of that fourth player's ranged units).
I'm introducing a lot of optimizations in v10 that should help issues surrounding move-and-shoot's slowdowns, so that's good. However, I'm also repurposing DangerPlots (the system that the AI uses to keep track of what tiles are dangerous to be in) from a vague, add-up-attacking-unit-strengths thing into a full-blown damage preview system (ie. the AI will know precisely how much damage a unit could take if it is kept in a tile): while this is definitely good for AI accuracy, especially where unit placement is concerned, replacing a single integer call with at least 200-odd, intricate calculations causes noticeable turn slowdowns even in the earlygame.
Once I get the system to work properly (it works about 99% of the time, and I want it to work 99.9999% of the time), I'll try to optimize it as much as possible to see if I can cut down on expensive function calls; right now, I don't even know which function calls are the more expensive ones.
HorseshoeHermit
20% accurate as usual, Morty
Are you committed to preventing the A.I. from cheat-spying?
The A.I. in this game is neither fair, nor well-architectured, nor really able to do anything even if it did make "mysteriously good" "guesses" about troop dispositions. If you calculated enemy anticipation once, each turn could get a leg up on inspecting the battlefield, and would only involve magically knowing , sometimes, that a mobile unit is nearby in the fog. Not to understate the changes involved.
The A.I. in this game is neither fair, nor well-architectured, nor really able to do anything even if it did make "mysteriously good" "guesses" about troop dispositions. If you calculated enemy anticipation once, each turn could get a leg up on inspecting the battlefield, and would only involve magically knowing , sometimes, that a mobile unit is nearby in the fog. Not to understate the changes involved.
Delnar_Ersike
Prince
Do you mean using knowledge/information cheats? I only have the AI use those if they really are marginal improvements and/or the alternative would run a lot slower: for example, the AI can see all air units regardless of fog because creating a sort of intuition/anticipation algorithm would consume a lot of resources, and having the AI know about all air units in the game isn't a big enough of an advantage to be worth replacing it with a much slower but fairer intuition/anticipation algorithm. In fact, the reason I fixed radaring in AuI is because the AI could use it as well, so patching it removed an unintentional knowledge/information cheat (as well as an exploit, since you're really not supposed to know about any units in fog).
The only time the AI will act on the presence of non-air units in fog is when it calculates its overall status during operations: it will add in half the strength of units in fog but adjacent to a visible tile to its overall strength calculation. Keep in mind though that the strength calculation is inaccurate to begin with (eg. three composite bows with 11 ranged strength each vs. two pikemen with 16 strength each), so having the AI see units in fog for this calculation doesn't actually convert to a tactical advantage.
In fact, having the AI see all units in fog doesn't make much of a difference pre-v10 because of how shoddy DangerPlots was: the game would just sum up the base strengths of all units that could attack a tile in the next turn and store that away. Not only could this not be properly used to simulate damage (eg. being attacked by two units with 11 strength is not equivalent to being attacked by one unit with 22 strength), but it also ignored a lot of simple modifiers that could make a huge difference (eg. attacking an embarked unit vs. attacking a regular unit, per-class modifiers like pikemen vs. horsemen). The fact that such a vital part of tactical combat (knowing how much damage a unit could take if they stayed at a tile) was almost non-functional for the AI is why I decided to overhaul DangerPlots in v10; there's still plenty of ways it could be improved, eg. the AI does not know when enemy units would not be able to reach a tile due to 1UPT in the current experimental build, but it has definitely resulted in the AI handling its troops a lot more carefully.
Peng Qi
Emperor
Downloaded. Can't wait to try it.
Delnar_Ersike
Prince
This is covered by "Active AI in MP", I believe? If so, I am planning on implementing it as an XML-enabled option for v10 (meaning you could toggle it on or off, because I imagine not everyone would like to be bombarded with AI deals in MP).
Tiramisu
Warlord
I think the AI would become much more dangerous if they use their fleet to conquer costal cities more often. Human players already know that e.g. frigates are very important in the game if there are enough costal cities. So the AI should learn this, too. 
One small question. Does the AI (after your changes) still put units in the water so they can be slaughtered? I am considering using this to test my scenarios. For instance, I am working on one about Guadalcanal and kind of need an AI that is better at using naval units. Especially, using fighters, dive bombers, and bombers, in carrier operations.
Delnar_Ersike
Prince
The AI sort of know how to do what you described. The AI uses "operations" when it is building up a force to attack something or someone, and it has access to naval attack operations just like it has access to land attack ones. The problem comes from how naval warfare actually works in Civ5: the AI is not actually programmed to handle any of the things that are so important in naval warfare (moving and attacking, retreating after moving, maximizing the use of units with special promotions like the Privateer, waiting to tech to a much stronger unit instead of producing a current, terrible one eg. Frigates and Cannons vs. Triremes and Catapults), which is the main reason it fails so much at naval combat.I think the AI would become much more dangerous if they use their fleet to conquer costal cities more often. Human players already know that e.g. frigates are very important in the game if there are enough costal cities. So the AI should learn this, too.
v9 does feature a few things that improve AI naval combat (eg. move-and-attack), but there's definitely more left to do for v10 and later versions.
I honestly do not know: from what I remember, the AI either completely avoided putting embarked units in dangerous waters in v9 or at least only did so rarely. The reason is that I've been working on v10's DangerPlots for so long that I've almost forgotten how any of my previous DangerPlots-related tweaks worked, from falling back to avoiding "dangerous" plots. Needless to say that v10's DangerPlots will definitely fix it completely if it's not fixed in v9, but I've still got a lot left to finish for v10.
One thing I can tell you is that the AI uses air units a lot better in v9 than in the default game. I mean, the AI couldn't even use Air Sweeps in the unmodded game. I had originally advertised that the AI knows how to use paratroopers in v9, but I later realized that my code had a few typos in it that stopped it from working; paradrops should work for v10, but they do not work properly for v9 (so the AI will build paratroopers but never actually paradrop with them).
Peng Qi
Emperor
In V9 the AI very rarely puts units in the water.
I have a suggestion if it's possible (which I'm not sure if it is).
It requires that the AI have any idea whatsoever that it's at a disadvantage. When it is, I think it should place a higher value on fortifying infantry units on difficult terrain tiles adjacent to its cities. This should significantly slow advances into an AI's territory and substantially help city states, which often have fewer units and can't afford to be making too many risky assaults.
Oh, and is it possible to tell the AI that if:
1. All religions have been founded and
2. It didn't found a religion that it
3. Should not attempt to build the Hagia Sophia?
I have a suggestion if it's possible (which I'm not sure if it is).
It requires that the AI have any idea whatsoever that it's at a disadvantage. When it is, I think it should place a higher value on fortifying infantry units on difficult terrain tiles adjacent to its cities. This should significantly slow advances into an AI's territory and substantially help city states, which often have fewer units and can't afford to be making too many risky assaults.
Oh, and is it possible to tell the AI that if:
1. All religions have been founded and
2. It didn't found a religion that it
3. Should not attempt to build the Hagia Sophia?
