29 replies to this topic

[LarkinVB]

While working on the DowPro AI for SS I wished I could use the old Relic HasThreadOnPath() function. The replacement just doesn't cut it. Remembering that the old one didn't crash on every map I thought it might be interesting to code this :

On gamestart every map will get a unique ID, a file will be openend with this ID as name and a single line will be written to it if it is the first use on this map: "true". This functionality is of course enabled/disabled by a win condition flag like AI highspeed. "true" does mean the AI will use the old terrain analyzer function. Around the old function a wrapper is coded, writing "false" into the file before and overwriting with "true" after the function is called. This wrapper and the old function are only used if the map did not have a "false" in its file on gamestart.

So what will happen ? If the battle ends and the game did not crash, we have a file with unique map ID, "true" written to it. So next time this map is used the old function is used again. If the map crashes the state written to file will be "false" and the old function will not be used next game. Therefore you will only encounter a single crash on any map at max. After multiple runs over all maps you will have a fine collection of files reflection the state of these maps. These files can be distributed with the AI so people don't have to encounter crashes at all if they want to use this AI Map DB functionality and toggle it in win conditions.

I have it coded and working. I tested on 20 maps so far and now the most astonishing part : I did not get a SINGLE crash, even in big battles with 8 AI players !!!
Is it possible that Relic did fix their HasThreadOnPath() function ?

Let me know if you are interested and I can give you the code.

Edited by LarkinVB, 01 April 2009 - 06:47 AM.

[troubadour]

Great idea, i just had a look at SSPRO AI v2.5 to see how you implemented it, if HasThreatOnPath() works well for all std SS map it will be a huge step forward

BTW many thanks for working on SSPro AI, cheers !

[ArkhanTheBlack]

Wow! You've opened the secret seal to map dependant AI information. Pretty much the only way left to really get some significant AI improvements beyond the current state.

What information did you use to generate the map ID? Listening post positions?

The HasThreadOnPath() is a real b*tch. the bug is race, map, and computer dependent. I remember one map where it took me almost two days to cause a crash.
However, there were definitely some maps where we never got a crash, therefore your solution is quite interesting. However, I would modify the flag to once at the beginning and once at the end of the AI cycle. This way only two file accesses are necessary which should keep the AI speed very high, regardless of how many path checks are made.
If the game crashes, we can assume that it was the pathing check.

[LarkinVB]

What information did you use to generate the map ID? Listening post positions?

However, I would modify the flag to once at the beginning and once at the end of the AI cycle. This way only two file accesses are necessary which should keep the AI speed very high, regardless of how many path checks are made.
If the game crashes, we can assume that it was the pathing check.

Yes, I use post count and positions as ID. Will change the code according to your suggestion once SSpro AI is stable.

[thudo]

Awesome work, Larkin! Please keep us posted.

Btw, do you need an additional list of custom maps which can be found in some faction mods?

[LarkinVB]

I suggest making the code a standard feature so faction mods can create their own map database. The files can then be collected and merged to be distributed with the newer AI versions. This idea comes a bit late as DoW is dead, more or less.

Edited by LarkinVB, 03 April 2009 - 06:39 PM.

[thudo]

Faction mods will have to be aware of how to do this to sync with the new AI code coming.

[LarkinVB]

Uploaded the code. Just use cpu_manager.ai (I fixed some debug_display problems too), new mapdb.ai and extra winconditions. NOTE: You have to create a folder named mapdb in DOW root folder (not AI folder!). This is were all AI mods will load/save map informations.

Link

Edited by LarkinVB, 03 April 2009 - 08:13 PM.

[thudo]

So this will work even with custom mod maps? Looking VERY much forward to testing this out.

[LarkinVB]

This should work with all maps. Every AI tweaked to use mapdb code will share the mapdb folder. Note that this code should ONLY be enabled with stable AI ! Otherwise crashes unrelated to terrain analyzer will result in a map entry = 'false', which is a false alarm. Further battles on this map won't use the old HasThreadOnPath().

Edited by LarkinVB, 03 April 2009 - 08:30 PM.

[thudo]

No its pretty stable AI code where using in Advanced AI SS 3.10 AFAIK! No issues at all in terms of CTD.

[LarkinVB]

Of course. I just mentioned if you want to add it to faction mod AI.

[thudo]

Been running the new ThreatOnPath() updated code + Game Mode..

Is there anything specific I should be noticing with the AI behaviour? ie. avoiding paths that had known enemy threats?

Also, a suggestion. How about under the mapdb.ai file on the line:

self.sMapDir =

We set it to an actual DC or SS folder in the game's root like \dxp2 or \logfiles ? Logfiles is preferred as thats where general DoW game debug info is stored.

[LarkinVB]

We should notice more intelligent AI moves.
Perhaps it is necessary to reevaluate some parts of the code. For example I find it strange that AttackPlan:GenerateSafePoint() is using cpu_manager:FindClosestFriendlyStrategicPoint(self.attack_pos, cpu_manager.start_pos, true, false) with HasThreatOnPath() check disabled. My hope is that attackers are less likely moving their army through enemies to reach a certain attack point.

No idea where the best place fo the mapdb folder is. logfiles is more of a temp folder.

[thudo]

No idea where the best place fo the mapdb folder is. logfiles is more of a temp folder.

Its not too big a deal to relocate or keep it in a new folder. Just trying to simplify things by using an existing folder rather than creating a new one.

[troubadour]

It may be also possible to use protected call to catch error from Soulstorm TerrainAnalyzer:HasThreatOnPath() writing sthing such as :

CpuManager:HasThreatOnPath()

local status, hasThreat= pcall( self.terrainAnalyzer:HasThreatOnPath() )

if status == true then -- No error raised by HasThreratOnPath()

if hasThreat == true then
-- Do something
else
--- Do something else
end

else -- Error in HasThreatOnPath()
-- use the same piece of code in cpumanager:hasthreatonpath()

end
end

[ArkhanTheBlack]

I'd prefer to keep the map info folder separated for each mod. Actually, if it comes to crashes, I don't trust other mods. Firestorm seems to be VERY crashy at the moment, the latest stable DowXP version was 4.03 1 - 2 years ago, SL was never stable (at least on some computers like mine), in DowPro DC I had two crashes in 5 games (though that's a while ago, don't know about DowPro SS...). I think the only prominent mods I know which seem to be quite stable are our AI mod, the demon hunters and the bugfix mod.

I'd also like to check the map ID of the Eldar HQ map which seems to crash in the campaign and initiate a complete AI shutdown since it's scripted anyway. Is there a way to play it separate or is it campaign only? (However it wouldn't be good to make a shut down if the map is also used for skirmishes and MP).

I wonder if we could reactivate the distance function to check for valid teleport positions too, using the map crash info. Not sure if the two functions are somehow related...

Perhaps it is necessary to reevaluate some parts of the code. For example I find it strange that AttackPlan:GenerateSafePoint() is using cpu_manager:FindClosestFriendlyStrategicPoint(self.attack_pos, cpu_manager.start_pos, true, false) with HasThreatOnPath() check disabled.

It's deactivated because a lousy scout squad could cause a huge army to change the gathering point. HasThreatOnPath is mainly usefull for capture and builder threat checks.

[thudo]

I'd prefer to keep the map info folder separated for each mod.

Thats my point: keep it to the \logfiles folder where game debug info happens anyway. Regardless, for cleanliness sake, keep the map db reporting to a folder off the game's root as its info we don't need to see except for the AI. I would prefer in the code to first create the \logfiles folder if necessary but thats a luxury.

[LarkinVB]

Do as you please. Its open source.

[thudo]

True but if we're going with a Adv. AI Soulstorm 3.30 release we need to maintain consistency otherwise we'll get sync errors. We have to agree on a location for universal acceptance.