Artificial Unintelligence
- Thread starter Delnar_Ersike
- Start date
ThorHammerz
zzz
- Joined
- Jul 31, 2014
- Messages
- 836
Are you referring to AUI, or to the base version of the game?
AUI already has this feature enabled, although several conditionals/thresholds may need tweaking.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,185
AUI, Beta line as of yesterday.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,185
Test game - Poland created a Great Engineer... spent him to hurry production on the Wonder it was building - Gained no turns improved in building the Wonder.
That was really odd. I see the Engineer spent. I was watching the wonder being built, but nothing happened when the AI rushed with him.
---Next Test - I watched Petra get rushed, and it was rushed. So it must be some odd scenario where it doesn't work. Those are the worst to track down.
That was really odd. I see the Engineer spent. I was watching the wonder being built, but nothing happened when the AI rushed with him.
---Next Test - I watched Petra get rushed, and it was rushed. So it must be some odd scenario where it doesn't work. Those are the worst to track down.
Delnar_Ersike
Prince
I've committed a fix for DangerPlots considerations for healing and withdrawing moves; the commit also contains some extra bit of code that lets the AI know when an attacking unit can survive until next turn if it does not attack the target, whereas before it could only identify when the attacking unit would die from attacking the target (so the AI will now suicide low health units into cities that would have been killed next turn anyway).
I've yet to come up with a way for the AI to not count enemy units twice for DangerPlots (ie. it should not add in an enemy unit's possible combat damage to a given tile's danger if it thinks that the unit will attack a different tile), as well as a way for the AI to not ignore units that have attacked out of fog onto a visible tile (eg. non-air units with range 3 or greater).
Though I'm not as busy with university stuff at the moment, Visual Studio has decided to really start acting up, once again slowing me down. I have no idea how its RAM+commit usage jumps from about 700 MB to more than 4.2 GB over the course of an hour, but it's not something my outdated rig takes well.
The functionality is definitely there, and the fact that units are purchased all the time proves that it works (since the DoHurry() function does not discriminate between units and buildings). It's more likely that either the parameter values or the algorithm itself leads to the AI always favoring units over buildings when purchasing production.
Whenever the AI uses the DoHurry() function, which is the only way it can hurry buildings, all possible options as well as the amount of turns each option saves are printed in the Homeland AI log; the selected option is simply the one with the greatest amount of turns saved.
I've yet to come up with a way for the AI to not count enemy units twice for DangerPlots (ie. it should not add in an enemy unit's possible combat damage to a given tile's danger if it thinks that the unit will attack a different tile), as well as a way for the AI to not ignore units that have attacked out of fog onto a visible tile (eg. non-air units with range 3 or greater).
Though I'm not as busy with university stuff at the moment, Visual Studio has decided to really start acting up, once again slowing me down. I have no idea how its RAM+commit usage jumps from about 700 MB to more than 4.2 GB over the course of an hour, but it's not something my outdated rig takes well.
The functionality is definitely there, and the fact that units are purchased all the time proves that it works (since the DoHurry() function does not discriminate between units and buildings). It's more likely that either the parameter values or the algorithm itself leads to the AI always favoring units over buildings when purchasing production.
Whenever the AI uses the DoHurry() function, which is the only way it can hurry buildings, all possible options as well as the amount of turns each option saves are printed in the Homeland AI log; the selected option is simply the one with the greatest amount of turns saved.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,185
I don't see that in the Homeland AI log, I'll run a Deity game where there will be a ton of money and check it again.
I use the Expenditure log, and it's all units... even while the AI has thousands and thousands of gold.
Edit - I see purchases in the Expenditure log, not the homeland AI log.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,185
A city scores the target with your code here
Which is an improvement on the old code, but still fails to make sure the AI targets the city at the edge of their borders. It causes the AI to still choose targets past the front, and they walk through a city and get decimated by bombardment, or call the attack off because they can't get in position.
Spoiler :
Which is an improvement on the old code, but still fails to make sure the AI targets the city at the edge of their borders. It causes the AI to still choose targets past the front, and they walk through a city and get decimated by bombardment, or call the attack off because they can't get in position.
Delnar_Ersike
Prince
I think the problem is that I'm still sort of relying on Ninakoru's original logic for DoHurry(), which not only causes the AI to favor really expensive buildings (that may not be worth it gold-wise) over cheaper stuff, but also only triggers if the AI's treasury is past a certain threshold; the reason it's not triggering is because the threshold is too high, but if I'm going to change that, I might as well address the other problem (AI only considering turns saved, ignoring actual gold cost so long as they can afford it) simultaneously.
That was a bit of a bandage fix applied when I was trying to replace all finite-state scoring systems with continuum systems in MilitaryAI. I'd probably get the most accurate measurements if I use the pathfinder, even if it means replacing one more instance of a fast distance check with a slower pathfinder check. The basic idea would be to make sure that any paths going from possible mustering cities to target cities do not cross through dangerous territory; it's possible that a check for neutral tiles around the target city can achieve the same thing, but it's too late at night for me to come up with something. Should mass paratrooper/XCOM attacks be implemented in the future, the system would also need to be adjusted for them.
Delnar_Ersike
Prince
Committed another update to remade DangerPlots. Healing rates are now properly calculated via DangerPlots, including possible healing from killing a unit; however, I have not accounted for possible healing from pillage actions, so I still need to shoehorn that in somehow. The AI also will include all units that attacked onto visible tiles last turn into its DangerPlots calculations regardless of unit visibility. This is a fairly good approximation for human "intuition", though the AI does still have a fairly short-term (1 turn) memory; implementing long-term memory that doesn't cheat would be a gigantic pain (you'd theoretically need the AI to keep track of all non-visible enemy units and try to guess whether they are still alive and where they might be), so I don't think I'll try.
I also fixed an issue I found with my move-and-shoot code: it turns out that A* nodes' Data1 (move) values are multiplied by the move denominator (60), so my check for whether a tile's Data1 > (Set up count) resulted in incorrect decisions for all artillery units (catapult, trebuchet, cannon, artillery, and any corresponding UU's).
Welp, I just uploaded a semi-fix for the DoHurry() stuff with my latest batch of commits, since I wasn't seeing DoHurry() messages in my homeland logs, either. Unit purchases for operations don't actually go through DoHurry(), BTW, they go through a different set of algorithms. The newly tweaked DoHurry() functions assemble a "rush list" each time they are run, then attempt to buy the choice that will give them the lowest amount of yield spent per turns of production. Even if the previous DoHurry() functions worked correctly, the lists they used were still only updated every time the previous production order was finished, whereas now they're updated every turn (for better or for worse).
I haven't tested the newly tweaked DoHurry() functions because Visual Studio is acting up again and refusing to build. I have a sneaking suspicion that the faith-based DoHurry() function is going to work horribly, since faith-based religious buildings don't have a production cost...
As for debugging algorithms that don't seem to fire, I generally set up a couple of breakpoints in Visual Studio, attach its debugger to Civ5 running AuI, and then check to see which breakpoints are reached and which ones aren't.
PS. LoneGazebo, I see you've been adding elements of my remade DangerPlots to the Community Patch. I really wouldn't recommend it, that stuff is still very unstable (eg. I've often been getting crashes due to corrupted function calls that all originate from remade bits of DangerPlots), and I've yet to mitigate double counting (the fact that the system assumes that a unit will attack every enemy unit in its attack range instead of just one). The new Great Works swapping code seems to be fine and self contained, though my juggling of pointers to vectors of pointers in ThemeBuilding() will probably make your eyes bleed (I also haven't tested its performance, it's entirely possible that my seemingly clever solution actually runs worse than Firaxis' braindead one).
I also fixed an issue I found with my move-and-shoot code: it turns out that A* nodes' Data1 (move) values are multiplied by the move denominator (60), so my check for whether a tile's Data1 > (Set up count) resulted in incorrect decisions for all artillery units (catapult, trebuchet, cannon, artillery, and any corresponding UU's).
Welp, I just uploaded a semi-fix for the DoHurry() stuff with my latest batch of commits, since I wasn't seeing DoHurry() messages in my homeland logs, either. Unit purchases for operations don't actually go through DoHurry(), BTW, they go through a different set of algorithms. The newly tweaked DoHurry() functions assemble a "rush list" each time they are run, then attempt to buy the choice that will give them the lowest amount of yield spent per turns of production. Even if the previous DoHurry() functions worked correctly, the lists they used were still only updated every time the previous production order was finished, whereas now they're updated every turn (for better or for worse).
I haven't tested the newly tweaked DoHurry() functions because Visual Studio is acting up again and refusing to build. I have a sneaking suspicion that the faith-based DoHurry() function is going to work horribly, since faith-based religious buildings don't have a production cost...
As for debugging algorithms that don't seem to fire, I generally set up a couple of breakpoints in Visual Studio, attach its debugger to Civ5 running AuI, and then check to see which breakpoints are reached and which ones aren't.
PS. LoneGazebo, I see you've been adding elements of my remade DangerPlots to the Community Patch. I really wouldn't recommend it, that stuff is still very unstable (eg. I've often been getting crashes due to corrupted function calls that all originate from remade bits of DangerPlots), and I've yet to mitigate double counting (the fact that the system assumes that a unit will attack every enemy unit in its attack range instead of just one). The new Great Works swapping code seems to be fine and self contained, though my juggling of pointers to vectors of pointers in ThemeBuilding() will probably make your eyes bleed (I also haven't tested its performance, it's entirely possible that my seemingly clever solution actually runs worse than Firaxis' braindead one).
ComradeKristov
Warlord
I've had soo much fun with this mod. I'm playing with the non-ddl version and the superpower mod. I've never had a coup happen before, where I was starting to get ahead of the rest of the civs and everyone DOW'd me. My economy was in shambles for 10 turns with no access to trade routes. Even though I had luxuries being traded with almost every civ they seemed to know I was a threat and attacked me. Luckily Russia was my ally. We are the top two civs on the score board and have no borders. I'm fighting my way through morroco & zululand to open trade routes with russia. This is on immortal & I usually have a cake walk on deity. I'm very impressed, someone like you should work for Sid Meier!
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,185
It likely was still a problem, but I noticed a large enough issue in my testing that I decided it was best to clear the slate for myself and start anew.
The debugging tips will help greatly, thank you.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,185
Loaded the experimental branch this morning. General unit movement looks improved significantly.
Settlers still patrol, and when a settler patrols, they get taken by Barbs. If they don't patrol, they don't.
Workers are doing a slightly better job of not being taken, but they walk into moves where they are taken.
A Human player can Radar (Select a move, and see where danger is in the fog), and the AI needs this same understanding of danger in the fog.
I am going to manually shut off Settler Patrolling if I can. It seems like it says first move only, but they patrol more than 1 move. They just move around waiting to get taken by the Barbarians.
Settlers still patrol, and when a settler patrols, they get taken by Barbs. If they don't patrol, they don't.
Workers are doing a slightly better job of not being taken, but they walk into moves where they are taken.
A Human player can Radar (Select a move, and see where danger is in the fog), and the AI needs this same understanding of danger in the fog.
I am going to manually shut off Settler Patrolling if I can. It seems like it says first move only, but they patrol more than 1 move. They just move around waiting to get taken by the Barbarians.
Delnar_Ersike
Prince
Whoops, forgot a line of code that would cause civilians to move into tiles that are patrol-desirable (roads, border tiles), but have a high enough danger value to indicate that they would be captured if they moved there. The next set of commits should fix this.
Radaring was an exploit caused by a poorly implemented getBestDefender(). AFAIK, it should be fixed in AuI (by the tag AUI_PLOT_FIX_GET_BEST_DEFENDER_CHECK_PLOT_VISIBILITY), so no, humans cannot radar.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,185
Fair enough.
seamus2010
Chieftain
- Joined
- Jun 23, 2013
- Messages
- 66
So I can't use Whoward's DLL with this at the same time? He has Ninakoru's mod merged, but not yours? 
Delnar_Ersike
Prince
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. The reason Ninakoru's mod was merged was because it was fairly focused (most of the mod was contained in a few functions) and its development stopped for a long enough time for people to catch up; funnily enough, none of the ports actually fixed some of the issues with Ninakoru's mod, such as move-and-attack functions not working properly for ranged units that did not have a range of 2. From what I've heard, Ninakoru has restarted development on his mod after I notified him of these issues.
This mod has a much broader scope than Ninakoru's, with some changes completely upending previous AI improvements made by others because the underlying algorithms were changed to no longer use the parameters whose values were improved.
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.
ThorHammerz
zzz
- Joined
- Jul 31, 2014
- Messages
- 836
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?
Delnar_Ersike
Prince
By merger, I mean that all functionality afforded by the CPP's DLL will be made available in AuI's DLL; it will also mean that the CPP team can more easily port AuI's changes to the CPP. The added benefit of having me merge the CPP into AuI instead of doing it the other way around is that because I have become quite familiar with most of Civ5's AI systems, I'll know where to look when making ad-hoc AI alterations to account for CPP's changes (eg. algorithm modifications to account for multiple units per tile). This should also give me the chance to clean up some of my messier code segments without having to worry about testing and fleshing out new features, since I trust that the CPP's code is a lot neater than mine.
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. The only CPP-ported features that will be turned on by default will be bugfixes, performance tweaks, and AI-related improvements. I don't plan on including any of the CPP's XML/SQL or Lua changes (changes to eg. policies, units, buildings, civilizations, map generation, UI, etc.) in AuI.
It will also open up the possibility of moving AuI to become a CPP fork, but that depends on how different the final port's codebase will be compared to CPP's codebase; if it's similar enough, forking will help both mods keep up to date on each other's future updates.
