WIP new API for the AIs, along with new version of Aegis.

[wraitii]

Alright, in the interest of speeding AIs up, and for setting new groundworks before further development, I've been for the past 2.5 months working on some new AI API. It's mostly done by now, and I'm beta-testing it. In this interest, I'm posting the WIP version here so anybody can try it. The installation process is kind of tedious and requires being able to compile, sorry.

(edited as of 11/11/12)

This implements an (optional) shared component between AIs, mainly to speed them up but also to try reducing their memory signature. It also include the latest version of Aegis. I've rewritten the defense system to be faster, and have found Aegis to be generally slightly faster than qBot. It's also usually more efficient (though the defense could use some work in that aspect, it's not yet perfect). it includes a very basic setting for difficulty in config.js.

The AI and the v3 API also support technologies to some extent. Aegis will go up in phases (it's currently the only tech it researches, though).

It will also try to attack you over water by transporting units in ship.

Retrocompatibility is assured: you can start a game without using qBot only, or even no AIs, or a mix between qBot and Aegis bot (one using the shared component, the other not).

The memory heap has been reduced to a maximum of 24 MB, and the garbage collection made slightly more efficient in particular right before Aegis starts a pathfinding, so you should get fewer OOM errors.

Procedure to test:

Go to binaries/data/mods/public/simulation/components/interfaces, erase the "TechnologyTemplateManager.js" file.

Put the files from "Simulation.7z" in source/simulation2/components/ . These files replace older ones.

Put the files from "AI.7z" in binaries/data/mods/public/simulation/ai/ (replace the existing files, don't combine them).

Apply the patch.

Run update-workspaces.

Recompile.

Run the game and choose "Aegis Bot".

PM me for mor information.

AI.7z

API3.patch

Simulation.7z

[memmaker650]

Create an API I think is the best option.

Create an strong base is basic to grow in the right direction.

[MishFTW]

I've downloaded the files and will test them out perhaps tomorrow. Look forward to a much tougher AI

If only naval support was here... the skies would be shaded with my arrows

[MishFTW]

Excelent, nice wraitii.

how may i can use it?

Wraitii was quite clear on this:

Procedure to test:

Go to binaries/data/mods/public/simulation/components/interfaces, erase the "TechnologyTemplateManager.js" file.

Put the files from "TechTemplate.7z" in source/simulation2/components/

Put the files from "AI.7z" in binaries/data/mods/public/simulation/ai/

Apply the patch.

Run update-workspaces.

Recompile.

Run the game and choose "Aegis Bot".

(tell me too if there's a problem with the patch).

[wraitii]

Geek: not quite yet more powerful, this is still a beta, I know for a thing it'll bug here and there . Particularly in the defence, I'll probably post an updated script for that at some point of the day.

@Lion: this means you have to run the script "update-workspaces.sh" and that you must recompile your game.

Edit: I'm not quite sure what I've done yesterday, but the AI seems to run really fast right now.

[Pedro Falcão]

Edit: I'm not quite sure what I've done yesterday, but the AI seems to run really fast right now.

That's good news!

[wraitii]

Yup.

I just updated the AI.7z archive with a new version that should fix most of the defense bugs, and perhaps some weird stuffs in attack. Should also allow the AI to reach city phase, there was an issue with a recent change.

[zoot]

how run that script?

It's described here: http://trac.wildfiregames.com/wiki/BuildInstructions

[wraitii]

Just posted a new version. Fixes a few fairly critical economic/attack bugs, and also allows retrocompatibility: qBot will now work (you'll get a small warning but I'll fix that).

[historic_bruno]

After applying the patches, playing against only qBot seems to work fine in most cases.

The game crashes on load when playing Acropolis 4 against multiple AegisBots, and also on some other maps (it's consistent and reproducible, but I don't know why it only affects certain maps). I'm not sure the call stack is very useful but here it is:

ntdll.dll!_ZwRaiseException@12()  + 0x12 bytes	
ntdll.dll!_ZwRaiseException@12()  + 0x12 bytes	
pyrogenesis_dbg.exe!ScriptInterface::CallFunction_(unsigned __int64 val=18446462629364795072, const char * name=0x01a388a0, unsigned int argc=1, unsigned __int64 * argv=0x0038df28, unsigned __int64 & ret=14757395258967641292)  Line 737 + 0x20 bytes	C++
pyrogenesis_dbg.exe!ScriptInterface::CallFunctionVoid<CScriptVal>(unsigned __int64 val=18446462629364795072, const char * name=0x01a388a0, const CScriptVal & a0={...})  Line 383	C++
pyrogenesis_dbg.exe!CAIWorker::RunGamestateInit(const boost::shared_ptr<ScriptInterface::StructuredClone> & gameState={...}, const Grid<unsigned short> & passabilityMap={...}, const Grid<unsigned char> & territoryMap={...})  Line 467	C++
pyrogenesis_dbg.exe!CCmpAIManager::RunGamestateInit()  Line 872 + 0x4e bytes	C++
pyrogenesis_dbg.exe!ScriptInterface_NativeMethodWrapper<void,ICmpAIManager>::call<void (__thiscall ICmpAIManager::*)(void)>(JSContext * __formal=0x0a8a2990, JSContext * __formal=0x0a8a2990, ICmpAIManager * c=0x0e1db330, void (void)* fptr=0x0114aad0)  Line 70 + 0xc bytes	C++
pyrogenesis_dbg.exe!ScriptInterface::callMethod<void,&class_ICmpAIManager,ICmpAIManager,&ICmpAIManager::`vcall'{40}'>(JSContext * cx=0x0a8a2990, unsigned int argc=0, unsigned __int64 * vp=0x0f400090)  Line 122 + 0x1d8 bytes	C++
mozjs185-ps-debug-1.0.dll!77b9e069() 	
[Frames below may be incorrect and/or missing, no symbols loaded for mozjs185-ps-debug-1.0.dll]	
mozjs185-ps-debug-1.0.dll!77bb29bd() 

If I play against 3 AegisBots on Fast Oasis, I get the following error output with the last lines repeating endlessly after a few minutes:

WARNING: JavaScript warning: simulation/ai/qbot-wc/plan-research.js line 14 anonymous function does not always return a value
WARNING: JavaScript warning: simulation/ai/qbot-wc/plan-research.js line 14 anonymous function does not always return a value
WARNING: watching 1
WARNING: watching 3
WARNING: watching 4
WARNING: watching 1
WARNING: watching 2
WARNING: watching 4
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 100 TypeError: pathFinder.markImpassableArea is not a function ([object Object])@simulation/ai/qbot-wc/qbot.js:100 ([object Object])@simulation/ai/qbot-wc/qbot.js:129 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:124 @:0
WARNING: watching 1
WARNING: watching 2
WARNING: watching 3
WARNING: JavaScript warning: simulation/ai/qbot-wc/economy.js line 489 reference to undefined property gameState.ai.distanceFromMeMap
WARNING: JavaScript warning: simulation/ai/qbot-wc/economy.js line 489 reference to undefined property gameState.ai.distanceFromMeMap
ERROR: JavaScript error: simulation/ai/qbot-wc/economy.js line 489 TypeError: gameState.ai.distanceFromMeMap is undefined ([object Object],"wood")@simulation/ai/qbot-wc/economy.js:489 ([object Object],[object Object])@simulation/ai/qbot-wc/economy.js:702 ([object Object],[object Object],[object Array])@simulation/ai/qbot-wc/economy.js:753 ([object Object])@simulation/ai/qbot-wc/qbot.js:165 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:124 @:0

[wraitii]

I can't seem to be able to reproduce any of those, though I recall the first one happening to me at some point…

I'll post a new version today, I think, could you try then if they still appear?

[wraitii]

Okay, latest version for the time being. More streamlining, I redid the defense manager so hopefully now it works about properly. Early naval support: the bot will try to attack you over sea (won't do anything else with its dock though). May bug, but it should mostly work. A few other things have been fixed or improved upon.

The procedure has slightly changed, so take care.

historic_bruno: I've fixed a crash that sounds very similar to yours, could you try again?

[rjs23]

Glad to see a new version of api and its improvements! I'll build a new ai from scratch using common-api-v3 during christmas break!

Edit: when you say ' apply the patch' after you update AI bots in AI folder, what do you mean? Apply with what? I'm a newbie with C programming so bear with me. I'd like to try out this api and play with it.

Edited December 22, 2012 by rjs23

[Yves]

Edit: when you say ' apply the patch' after you update AI bots in AI folder, what do you mean? Apply with what?

Apply it using

patch -p0 -i /path/to/patch/file

Or if you already have a subversion 1.7 client

svn patch /path/to/patch/file

Or if you are on windows and using tortoise svn there should be a menu item to apply patches.

[alpha123]

Hello. I wanted to take a look at this patch. Is the version you posted in the OP still the latest version? Also, is there a Trac ticket for this? (I can't seem to find one.)

[wraitii]

I believe it is the latest version, yes. The ticket is #1650.

[Yves]

Historic_bruno has created a patch that uses JS_SetGCCallback to profile how long garbage collection takes and when it happens (patch is attached).

We figured out that Aegis (old/svn version) has a lot more problems than Qbot and that this is the main factor that makes it slower.

The new version in this thread is a bit better but garbage collection is still a major performance problem.

I've attached some screenshots from profiling (new version with your patch).

This is the command I used for starting the test-game:

./pyrogenesis -quickstart -autostart="Oasis 04" -autostart-ai=1:qbot-wc -autostart-ai=2:qbot-wc -autostart-ai=3:qbot-wc -autostart-ai=4:qbot-wc

I did the profiling when all players had between 180 and 190 population.

Do you think it's possible to reduce the amount memory that needs to be garbage collected in each frame/sim update?

If we upgrade Spidermonkey it should be possible to use incremental GC, but that doesn't help when the garbage collection takes that long and happens as often as it does now.

If it's not possible to reduce the amount of memory that needs to be garbage collected, the only other solution is to move the AI to another thread completely, which we should probably do at some point anyway.

jsgc_profiling.diff

[wraitii]

Hm, I have hardly any accurate data to give you on that topic right now, it'd require testing and stuffs like that...

I do believe, from my testings when trying to lower the AI memory heap, that there is a problem of memory cluttering because of the simulation state update. Memory is allocated to it, and never really deleted until GC. And this is quite expansive, memory-wise (probably too much, there are certainly issues there, but lacking proper debugging tools, it was hard to tell).

I'm not too sure why Aegis is much worse than qBot, but there are probably even more stuffs being created regularly, so it's not that surprising.

Reducing the amount of times GC has to be executed is therefore linked to the amount of "memory creation" every frame which is kind of out of control right now (lack of debugging tool, and I must say also lack of care, at least on my part), and the fact that since it's bloating so fast, and the heap is quite low, it needs to be run often to avoid going OOM.

I'm not sure if it's faster to run the GC regularly with a small heap, or once in a while with a big heap (thus a slower GC, perhaps?)

[Yves]

I'm not sure if it's faster to run the GC regularly with a small heap, or once in a while with a big heap (thus a slower GC, perhaps?)

I think that the time for GC more or less proportionally depends on the amount of memory to collect. At least this sentence from the blog post I linked above gives that impression:

Rather than do a 500 millisecond garbage collection, an incremental collector might divide the work into fifty slices, each taking 10ms to complete.

I'm not sure how much further it can be divided, though. Probably there's an overhead somewhere that doesn't allow us to divide it further.

Anyway, as you can see it takes more than 40 ms which is more time than the whole frame should take (someday... ).

40 ms per frame would be only 25 FPS!

And you can also see that it happens three times in four frames on the first screenshot, which is already quite regularly (we can't call it more often).

[wraitii]

Certainly. 40ms alone seems a lot though, I assume debugging slows things down slightly.

[Yves]

Certainly. 40ms alone seems a lot though, I assume debugging slows things down slightly.

It's a release build. It should be quite accurate.

[wraitii]

Ah. Then I believe the word bad accurately describes this situation. Though then again 4 Aegis at 200 units is not exactly fast right now...

[wraitii]

Allright, everyone, so this has finally been committed to SVN, and will show up in Alpha 13.

A short list of new features (the AI referring to Aegis):

-Speed ups in many parts of the AI, in particular having many Aegis Bots should be noticeably faster (though not yet fast)

-Improvements in many parts of the AI. Defense should be slightly better, dropsite placement has been noticeably improved. Aegis should be able to be more efficient. Many many bug fixed.

-Support for technologies. Aegis itself goes up in phases, and will research technologies (though it chooses which randomly)

-Early support for naval maps. On some maps, the AI will build a dock and try an amphibious attack (very experimental still).

-Early difficulty support. You can choose from one in three settings (note: this may get a GUI side before Alpha 13).

More technically:

-Introducing a shared script that runs for All Aegis bots, and does the entity filtering only once instead of once per AI. Faster with multiple AIs.

-Changed the way Aegis deals with training/building/research plans. It should work more like you expect it, and it supports fairly well planning for many units as well as some resource-costly stuffs. Also improved how the bot will choose to Train more than one unit at once.

-Improvement to the attack plan logic will make Aegis train better siege units.

-Ability to build a farmstead.

-Aegis will use the statistics to change its default resource priorities (only on the highest difficulty).

-Improvements to how workers choose the resource they gather from.

API v3 features tech support, some other stuffs. It's not quite cleaned up, though.

There are slight changes to AIInterface: it sends the extended simulation state as that was required for, for example, techs (I think).

Also: when trying to place a dock, the helper will now determine the position at placement time too. Changes nothing for the player, helps the AIs considerably. This means duplicated code, though.

I also made the GC only called when the AIs are about to OOM. If you notice a lag late in the game, it may be caused by the GC being called every frame... In which case please report.

You may experience a little lag when the map generation reaches 100%: that's from the AIs initializing. It should not feel too long. I can't recall if there was still some, but that should seriously help with the weird "initial lag" that sometimes happened right at the start of a game.

Expect Aegis on the hardest difficulty to be noticeably sharper in the first 15 minutes if you leave it alone.

[zoot]

I just tried it. It worked well for some time, but then it began printing an error endlessly. Should that be reported somewhere?

[wraitii]

Do report it here, it's as good as any other place (also, please post your map settings)