DarkBlizz

Quote from: Astazha on March 16, 2010, 09:35:12 AM
Ok, this is actually really straightforward.  I thought I was going to have to jump through some hoops, but it turns out to be extremely simple.


The two functions we are interested in are:
AICounterUnit()
AICounterUnits()

...

We delete all the existing entries.  Then we make an entry for each unit and building, listing it as the counter to itself with a ratio of 1.00


Then when you call


countPBGateways=AICounterUnits(player, 4, c_PB_Gateway);


it will tell you how many Gateways player 3 has.  Wash Rinse Repeat for every unit in the game.  Once you get a read of what race you're dealing with you no longer have to check 2/3 of the units and we can begin to make match-specific decisions about the build order and general strategy.


I'll post actual code when I have something working, but if you want to mess with it now that's how it works.

AIKnownUnitCount(player, 4, c_PB_Gateway); will return the number of units player knows that player 4 has; if you haven't enabled the cheating vision it will only return what it can/has seen.

Quote from: Astazha on March 16, 2010, 04:23:20 AM
I have a question about this.  Why 109?  The only documentation I can find on the UserInt functions is:

const int c_playerPropMinerals              = 0;
const int c_playerPropVespene               = 1;
const int c_playerPropSuppliesUsed          = 4;
const int c_playerPropSuppliesMade          = 5;


Is 109 an arbitrary user-defined spot in that player array?  How big is it? 


If they are user-defined, should we create a thread documenting which slots are being used and by what scripts for what purpose so that conflicts can be minimized?

The player prop constants aren't used for Get/SetUserInt; I think blizzard's functions are using 1-10 (I remember seeing this somewhere). 109 is just an arbitrary index in the array; I'm not sure how large of an index we can use but so far I've been using indices below 256.

Unfortunately you can't do either :/


What are you trying to do with this function?

As an update I've decided to hard code a graph of points of interest on the map (right now just Lost Temple but it should be easy to determine the map based on starting positions) to help create a much improved tactical AI. As a start I'm rewriting the scouting routines.


Here's the graph I'm using for Lost Temple:





Connections have a type (blue lines are air only, orange cliffs, and black normal).

Quote from: vjeux on March 12, 2010, 05:42:40 AM
If you want to use basic math functions, I've recoded "cos, sin, tan, round, floor, ceil, isInt, mod". You can find the file here: http://www.sc2mapster.com/assets/basic-mathematic-functions/

Thanks for the link to the math file; the PointX & PointY functions are very much appreciated. I almost got to the point of writing something similar myself after getting frustrated trying to get the x & y variables from a point. I recently had a problem including your math file in MeleeAI.galaxy though; I'm not sure what the problem was because I was able to remove the include (it was buried 3 files deep) because I wasn't actually using it.

Quote from: Astazha on March 12, 2010, 12:28:36 AM
I believe this function would allow you to do away with the need to pass the required building as an argument.

http://galaxywiki.com/wiki/AIGetFirstUnfinishedReq

Yeah it would; except I'm not always using the functions to check the building/tech requirements but other conditions.

I've glanced over this thread and wanted to comment on how I'm currently programming my build logic. One of the key things I've noticed is you need to make sure you only use AISetStock when something needs to get built otherwise it will just hold up anything below it. Thus for buildings I use a couple custom functions that basically check certain conditions and if the building is already under construction (this is key because otherwise AISetStock(player, 1, c_TB_Barracks) will block anything untill the barracks is finished.


Then in the varying states my basic logic is as such:
-Buildings and tech in order with conditions (only one of these should ever be calling AISetStock at any one time)
-MakeArmy
-MakeWorkers
-BuildSupply


The last three I might change the order on but they are using resources whenever anything above it is waiting for construction etc...


MakeArmy basically checks what production queues I have available and will call SetStock with a number that will only enqueue one unit per available building (2 for terran reactors).
MakeWorkers is the same for Command Centers etc..
Finally BuildSupply will add supply buildings when needed (this isn't used in the very beginning of the game due to strict timing being necessary).


I've also added a GasBlocked flag that will check when building units if they can't be built due to a lack of gas and thus won't call AISetStock and can allow any mineral only units/buildings after that function call to be built.


Here's the current version of my framework functions if anyone wants to check them out: http://pastebin.com/xa88Q2AU
I posted some of them in http://darkblizz.org/Forum2/ai-development/code-snippets-functions/ but I've since changed/added some.


All of this basically adds up to help streamline builds by reducing the time the AI is waiting for anything to be built; instead of using AISetStock as a long queue of what to build in order I use it as a list of what I want built now.

Quote from: Astazha on March 14, 2010, 11:27:41 AM
I did some more testing on this.


This code:

QuoteAISetStock(player, 2, c_ZB_Hatchery_Alias);
   AISetStock(player, 1, c_ZB_Hive);

will produce 1 Hive and 1 additional Hatchery.


This code:

QuoteAISetStock(player, 2, c_ZB_Hatchery);
   AISetStock(player, 1, c_ZB_Hive);

will produce 1 Hive and 2 additional Hatcheries.


Based on that, I would say that c_ZB_Hatchery_Alias does include the basic Hatchery.  It appears to me that aliases are just not appropriate for us in AIFindUnit() even though they work correctly in the Stock functions.

I've seen some strange behavior using the Alias types; it seems they were designed for the SetStock functions but a lot of other functions don't use them correctly.

Quote from: Astazha on March 13, 2010, 08:58:47 PM
I'll try to look into it.  I've been playing with expansion/base development stuff.  Really just trying to figure out what is possible at this point... so many functions without clear documentation...


In the BuildAI.galaxy file there are some constants for build locations, and the protoss Starcrack code makes some use of them to put the pylons next to "factories" once a reasonable powerfield has been established.  One of the locations you can specify is choke point, but I haven't done any testing to see whether telling the Terran AI to build supply depots and barracks and bunkers at the choke point will actually result in a wall in or if they will just put it in the vicinity.  I fear the latter.

They'll just put it in the vicinity; I doubt we'll be able to get actual wallins working unless we can manually order them to build at a specific point.

Quote from: Kernel64 on March 12, 2010, 04:38:43 PM
Do you guys know how to make multiple waves? Like, two main attack waves, one for main attack and the other for back door drops?

Or is this even possible?

How do we control attack waves?

Yeah that should be easy; the attack waves are usually controlled by setting the AI attack state.

Quote from: hd on March 09, 2010, 04:44:54 PM
I wonder, can we set a location like UnitGetPosition(UnitGroupUnit(AIWaveGetUnits(c_waveAttack), RandomInt(1, AIWaveUnitCount(c_waveAttack)))) and modify it to be a little ways back towards their main base so we can set a rally location not too far from where they last fought if an attack was successful.

Yeah, that should be possible; I'll look into it; access to a point's data would help a lot. I've also been messing around with getting a contain state working that'll sit outside an opponent's base.

Quote from: hd on March 09, 2010, 12:51:59 AM
I am curious how you set the gather location and I assume it can be adjusted on the fly...

I just made a function to set which town the attack waves gather at (it was using c_townMain). So once your nat goes up you can just call it and set it to the natural and they'll start gathering outside of it.

Quote from: Kernel64 on March 09, 2010, 05:37:47 AM
Cool.

I'm currently needing a function that returns the free available food supply with two conditions:

This is what I use to check supply:


    int used = PlayerGetPropertyInt(player, c_playerPropSuppliesUsed);
    int created = PlayerGetPropertyInt(player, c_playerPropSuppliesMade); //current supply


    // queued supply count:
    if (PlayerRace(player) == "Zerg") {
    created = TechTreeUnitCount(player, c_ZU_Overlord, c_techCountQueuedOrBetter) * 8 + TechTreeUnitCount(player, c_ZU_Overseer, c_techCountQueuedOrBetter) * 8;
        created += TechTreeUnitCount(player, c_ZB_Hatchery, c_techCountQueuedOrBetter) * 2 + TechTreeUnitCount(player, c_ZB_Lair, c_techCountQueuedOrBetter) * 2 + TechTreeUnitCount(player, c_ZB_Hive, c_techCountQueuedOrBetter) * 2;
    } else if (PlayerRace(player) == "Prot") {
    created = TechTreeUnitCount(player, c_PB_Pylon, c_techCountQueuedOrBetter) * 8 + TechTreeUnitCount(player, c_PB_Nexus, c_techCountQueuedOrBetter) * 10;
    } else if (PlayerRace(player) == "Terr") {
    created = TechTreeUnitCount(player, c_TB_SupplyDepot, c_techCountQueuedOrBetter) * 8 + TechTreeUnitCount(player, c_TB_CommandCenter, c_techCountQueuedOrBetter) * 11;
        created += TechTreeUnitCount(player, c_TB_OrbitalCommand, c_techCountQueuedOrBetter) * 11 + TechTreeUnitCount(player, c_TB_PlanetaryFortress, c_techCountQueuedOrBetter) * 11;
        created += TechTreeUnitCount(player, "SupplyDepotLowered", c_techCountQueuedOrBetter) * 8;
        // Alias doesn't seem to work right here...
    }


Quote
Also, one question, will two while blocks run simultaneously?

Say,

while(A) {
   do(x)...
}
while(!B) {
   do(y)...
}

Will do(x) and do(y) run simultaneously?

What do you mean simultaneously? What are you trying to do with the two loops?

Ability Improvements:
Guardian Shield function for the Sentry:
http://pastebin.com/dEJeJLG0
(As of right now the sentry will default to using the Guardian Shield. Also, all sentries with enough energy in a group will use it as soon as possible; I intend to fix this soon.


include and add the following to the begging of AIThinkDisruptor in TactProtAI.galaxy:


    if (GuardianShield(player, aiUnit, scanGroup)) {
        return;
    }



Todo:
-Command Centers lift off when under attack.

I've been spending a lot of time lately on improving the games ridiculous combat AI and have come up with the following that I think a lot of people would be interested in so I'm posting it here. Any suggestions and feedback would be appreciated, thanks. 


Features:
-Several new attack states to provide a wider range of tactical options to the AI.
-Added a function to set the town gather location (for example to the Natural so the army will gather outside there instead of inside your main)
-Tweaked some values in the attack handling to hopefully provide better engagement/retreat logic
-Raised the retreat threshold so the AI will not abandon attacked towns so quickly and easily.
-The AI will now try and regroup instead of retreating all the way back to its main base.
-The AI will turn around and fire on pursuing units while its retreating if it has a distinct advantage (will revert to retreat when odds drop).




Usage:
Here's the current source for the new and changed code:
http://pastebin.com/nwgRtS1c


If you want to use this copy the constants and town gather functions to the top of MeleeAI.galaxy; and replace the AttackStateName, AIDefendTown, and AIWaveAttack functions.


Or, if you haven't changed MeleeAI or just want a .sc2data version here's the mpq with just a changed MeleeAI.galaxy:
http://dl.dropbox.com/u/5031322/CombatMod/Base.SC2Data


New States:
-Pressure: similar to attack but with a lower threshold for retreating
-Commit: commit to a fight with no chance of retreat (don't set this manually, it is used when the AI is close in strength to the enemy and retreating would most likely result in many losses).
-Defend: Stay back and defend the main base
-Regroup: Retreat for a little ways until out of combat; then regroup, wait for reinforcements and try to move in again (used instead of retreat in most instances).
-Scared_Snipe/Regroup_Snipe: if retreating and spotting a target of opportunity (like lead elements of a pursuit) stop and engage while we have a distinct advantage.


Todo:
-Fix drop attacks
-Fix retreating through the enemy
-Add multiple attack waves (harassing expos with a small force while your main army is engaged)
-Improve idle state logic to improve attack decisisons