1. We have added a Gift Upgrades feature that allows you to gift an account upgrade to another member, just in time for the holiday season. You can see the gift option when going to the Account Upgrades screen, or on any user profile screen.
    Dismiss Notice

Artificial Unintelligence

Discussion in 'Civ5 - Mod Components' started by Delnar_Ersike, Oct 23, 2014.

  1. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    From what I can tell, the AI will only ever purchase units, even if they have a ridiculous level of gold. They should purchase buildings as well.
     
  2. ThorHammerz

    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.
     
  3. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    AUI, Beta line as of yesterday.
     
  4. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    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.
     
  5. Delnar_Ersike

    Delnar_Ersike Prince

    Joined:
    Jan 1, 2007
    Messages:
    497
    Location:
    localhost
    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.
     
  6. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    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.
     
  7. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    A city scores the target with your code here

    Spoiler :
    #ifdef AUI_MILITARY_TARGET_WEIGHT_DISTANCE_CONTINUUM
    // Weird decimals in new method are to make sure old values are matched at thresholds
    uliRtnValue *= MAX(1, int(9.21 / pow(947.0 / 900.0, target.m_iPathLength) + 0.5));
    #else


    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.
     
  8. Delnar_Ersike

    Delnar_Ersike Prince

    Joined:
    Jan 1, 2007
    Messages:
    497
    Location:
    localhost
    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.
     
  9. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    Ai is buying in your build, I had an issue. Sorry about that.
     
  10. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    Nevermind - Found an issue on my side.
     
  11. Delnar_Ersike

    Delnar_Ersike Prince

    Joined:
    Jan 1, 2007
    Messages:
    497
    Location:
    localhost
    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).
     
  12. ComradeKristov

    ComradeKristov Warlord

    Joined:
    Dec 30, 2009
    Messages:
    170
    Location:
    Chicago,Il
    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!
     
  13. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    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.
     
  14. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    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.
     
  15. Delnar_Ersike

    Delnar_Ersike Prince

    Joined:
    Jan 1, 2007
    Messages:
    497
    Location:
    localhost
    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.
     
  16. notque

    notque Artificially Intelligent

    Joined:
    Nov 13, 2005
    Messages:
    1,654
    Fair enough.
     
  17. seamus2010

    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? :(
     
  18. Delnar_Ersike

    Delnar_Ersike Prince

    Joined:
    Jan 1, 2007
    Messages:
    497
    Location:
    localhost
    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.
     
  19. ThorHammerz

    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?
     
  20. Delnar_Ersike

    Delnar_Ersike Prince

    Joined:
    Jan 1, 2007
    Messages:
    497
    Location:
    localhost
    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.
     

Share This Page