Spring RTS Engine

Posted: **14 May 2007, 21:35**

Thank you, at last...

Posted: **14 May 2007, 21:45**

Tried NTaiCaseTest4.rar
The error ├óÔé¼┼ôproblem occurred loading unit..├óÔé¼┬Ø is gone!

More importantly, NTAI now do NOT skip units due to problems with above. Eg, it now always build in the exact (if it can find a building position) order specified in the list for the unit in the config file.

Error (bug) fixed!

Ok so now I have a version of NTAI that enables me to complete my config file.

A few minor issues remain, and I will help you track├óÔé¼Ôäóem down and fix├óÔé¼Ôäóem if you feel this is necessary.

First issue:
Solobuild, works more like ├óÔé¼┼ôreduced parallel build├óÔé¼┬Ø eg. It doesn├óÔé¼Ôäót stop parallel building, only reduces it.
(SingleBuild works as expected!)
I├óÔé¼Ôäóve setup a simple spawn configfile that spawn corck and make corck only build solar├óÔé¼Ôäós. (Commander continues to build mmakers),
The map is green_field so no obstacles and plenty of build space.

Observation:
1) Corck(a) comes out of factory, starts building solar.
2) New Corck(b) from factory, ├óÔé¼┼ôstutters├óÔé¼┬Ø for a few seconds, meanwhile solar completed.
3) Corck (a&b) starts Simultaneously to parallel building solar├óÔé¼Ôäós.
4) New Corck(c) from factory, goes to assist Corck(a) in building nearest solar.
5) Corck(c) reaches Corck(a)├óÔé¼Ôäós solar, and start to nanolate
6) Corck(c) stops nanolating (after about 50 frames)
7) Corck(c) start to nanolating again on Corck(a)├óÔé¼Ôäós solar
8 ) repeat step 6 and 7 for a while (starts and stops nanolating / assisting Corck(a)
9) Corck(b) has completed solar, start new solar.
10) Corck(c) stops nanolating (after about 60 frames), starts to make own solar. Even tough Corck(a)├óÔé¼Ôäós solar is NOT completed.

Logfile from the repair period (step 6-9), toward step 10:

[06:04] < Frame: 10947 >CUnitConstructionTask::Build solobuild CORSOLAR
[06:04] < Frame: 10949 >issuing command in update()
[06:04] < Frame: 10949 >Command: ID: 40 Timeout: 2147483647 params: 4965, source of command: repair CActions
[06:04] < Frame: 10949 >issuing command in update() succeeded
[06:06] < Frame: 10981 >next task?
[06:06] < Frame: 10981 >CUnitConstructionTask::Init :: CORSOLAR
[06:06] < Frame: 10981 >CUnitConstructionTask::Build solobuild CORSOLAR
[06:06] < Frame: 10981 >Value tasklists\normal\corck missing in file buffer
[06:06] < Frame: 10981 >loading contents of tasklist :: CORCK :: filling tasklist with #1 items
[06:06] < Frame: 10981 >CUnitConstructionTask::CUnitConstructionTask building :: CORSOLAR using builder::CORCK
[06:06] < Frame: 10981 >loaded contents of tasklist :: CORCK :: loaded tasklist at 1 items
[06:06] < Frame: 10981 >CUnitConstructionTask::Init :: CORSOLAR
[06:06] < Frame: 10981 >CUnitConstructionTask::Build solobuild CORSOLAR
[06:06] < Frame: 10982 >issuing command in update()
[06:06] < Frame: 10982 >Command: ID: 40 Timeout: 2147483647 params: 4965, source of command: repair CActions
(A few lines removed here, concerning turn on of metal makers)
[06:07] < Frame: 11012 >issuing command in update() succeeded
(corck(a)├óÔé¼Ôäós solar is completed, but the solar above that corck(c) assisted in building is NOT finished)
[06:07] < Frame: 11038 >Value tasklists\normal\corsolar missing in file buffer
[06:07] < Frame: 11038 >Value tasklists\lists\corsolar missing in file buffer
[06:07] < Frame: 11038 > error loading tasklist :: CORSOLAR :: buffer empty, most likely because of an empty list
[06:08] < Frame: 11051 >next task?
[06:08] < Frame: 11051 >CUnitConstructionTask::Init :: CORSOLAR
[06:08] < Frame: 11051 >Value tasklists\normal\corck missing in file buffer
[06:08] < Frame: 11051 >loading contents of tasklist :: CORCK :: filling tasklist with #1 items
[06:08] < Frame: 11051 >CUnitConstructionTask::CUnitConstructionTask building :: CORSOLAR using builder::CORCK
[06:08] < Frame: 11051 >loaded contents of tasklist :: CORCK :: loaded tasklist at 1 items
[06:08] < Frame: 11051 >CUnitConstructionTask::Init :: CORSOLAR
(corck(c) is allowed to build new solar even tough corck(b) solar is still under construction)
[06:08] < Frame: 11051 >CUnitConstructionTask::RecieveMessage G->OrderRouter->GiveOrder(tc)== true :: CORCK
[06:08] < Frame: 11051 >CUnitConstructionTask::RecieveMessage wiping and creaiing the plan :: CORCK
[06:08] < Frame: 11054 >issuing command in update()
[06:08] < Frame: 11054 >Command: ID: -315 Timeout: 11534 params: 976, 178.333, 1296, 0, source of command: CBuild
[06:08] < Frame: 11054 >issuing command in update() succeeded
[06:08] < Frame: 11069 >next task?

Other observation, corvp NEVER tries to assist commander in building mmakers, so its clearly sticking to corsolars, as instructed (in the config file).

Second Issue: (tested using same setup of map and config as above)
I might not fully understand the purpose and specification of Exclusion zones, but if the purpose is to prevent building another immobile unit within the range of an already existing unit, this doesn├óÔé¼Ôäót work.
Im also unclear as which takes priority: power_spacing=2; or corsolar=500; under ConstructionExclusionRange.

I do NOT see any difference specifying parameters for ConstructionExclusionRange (also tried with a ├óÔé¼┼ôs├óÔé¼┬Ø in the end as well.) Both with and power_spacing=2, and omitting power_spacing, I observed the same behavior.

I├óÔé¼Ôäóve tried to specify: (I also tried doing, same using toolkit)

[ConstructionExclusionRange]
{
corsolar=500;
}

Tried above with parameter values of: 6, 200, 500, 1000, and 5000. No change in spacing between solar├óÔé¼Ôäós was observed.
(also tired with capital letters CORSOLAR, just in case

The log does NOT log anything that could hint about build placement or exclusion ranges/zones.

Posted: **14 May 2007, 22:19**

corvp is a factory not a builder.

spacing tells NTai how much extra space is needed for a build position to be a 'good position'.

Exclusion zones mean dont build one of these within this range of another one.

So say we have an antinuke. It has a range of 5k. We dont want to give it a blocking radius of 5k because then nothing would be built in its radius and it'd be a waste.

At the same time we dont want another antinuke built next to it. So we'd give it an exclusion zone around 5k.

NTais build algorithm is multithreaded. This means while Unit A is searching for a place to put its solar, unit B is deciding if it should build a solar, so unit B sees no existing solar and looks for a position to build one, then unit A finds a position and starts construction while B is looking, then B finds a place and starts building.

Ill see about making a second check after the build algorithm has finished which might cut down on it but the problem can not be totally eradicated atm.

Posted: **14 May 2007, 23:35**

AF wrote:corvp is a factory not a builder.
Typo, meant corck not corvp
spacing tells NTai how much extra space is needed for a build position to be a 'good position'.
Makes sense, so this makes "room" around a factory (and other immobiles) for units to exit/move
Exclusion zones mean dont build one of these within this range of another one.

So say we have an antinuke. It has a range of 5k. We dont want to give it a blocking radius of 5k because then nothing would be built in its radius and it'd be a waste.

At the same time we dont want another antinuke built next to it. So we'd give it an exclusion zone around 5k.
Got it, but this is not working, setting corcom to build only corwin, and corwin=500; in exclusion zone, and the commander is still building corwin with a spacing about 150pixels between them (this is with NO parallel building, corcom is only active unit in game)

NTais build algorithm is multithreaded. This means while Unit A is searching for a place to put its solar, unit B is deciding if it should build a solar, so unit B sees no existing solar and looks for a position to build one, then unit A finds a position and starts construction while B is looking, then B finds a place and starts building.
Expected this, So solobuild do not acount for travling to build spot, and leveling ground. fine minor issue.
BUT, in my logfile from previous post, the corsolar that was build bye corck(a) had been in construction for some time (over 50% build).
I am by no means and expert on multithreaded programming, but remember something about semaphore locks (sometimes implemented as counters), it seams that the completed solar, by unit corck(b) clears (decreases it to 0) this lock, without taking in account, that corck(b) is still constructing.

Ill see about making a second check after the build algorithm has finished which might cut down on it but the problem can not be totally eradicated atm.
Thanks, will look forward to testing.

Posted: **15 May 2007, 13:13**

While the build algorithm is searching the unit does nothing. When a position is found and the thread ends NTai places a 'plan' which should be a part of the exclusion zone calculations etc.

Posted: **15 May 2007, 14:17**

I have to increase my QA of postings

So a few corrections in red, to make things clear:

lale wrote: At the same time we dont want another antinuke built next to it. So we'd give it an exclusion zone around 5k.
Got it, but this is not working, setting corcom to build only corwin, and corwin=500; in exclusion zone, and the commander is still building every and all corwins with a spacing no bigger than 150pixels between them (this is with NO parallel building, corcom is the only active construction-unit in the game)

NTais build algorithm is multithreaded. This means while Unit A is searching for a place to put its solar, unit B is deciding if it should build a solar, so unit B sees no existing solar and looks for a position to build one, then unit A finds a position and starts construction while B is looking, then B finds a place and starts building.
Expected this, So solobuild do not acount for travling to build spot, and leveling ground. fine, minor issue.
BUT, in my logfile from previous post, the corsolar that was build by corck(a) had been in construction for some time (over 50% build).
I am by no means and expert on multithreaded programming, but remember something about semaphore (mutex) locks (sometimes implemented as counters), it seams that the completed solar, by unit corck(b) clears (decreases it to 0) this lock, without taking in account, that corck(a) is still in the middle (50%) of constructing a solar.

Posted: **16 May 2007, 00:23**

http://kein.praeon.net/wtfman.PNG

See the messed up display? The game overlaid Peewees EVERYWHERE the AI wanted to build or had buildings. It caused my FPS to dip down to 1 and slowed the game down to a ridiculous point.

What caused this? I used Goidse's AI and the thing spammed LLTs, Wind Generators, Metal Makers, and Advanced Solar Collectors. A few Rockos here and there, but nothing past 1st tier tech.

Posted: **16 May 2007, 00:26**

hmm you'll have to ask goidse about NTais refusal to tech up, as for the peewees thats the blocking map being drawn by NTai, I'll disable that tomorrow.

Posted: **16 May 2007, 21:40**

Cainen wrote:http://kein.praeon.net/wtfman.PNG

See the messed up display? The game overlaid Peewees EVERYWHERE the AI wanted to build or had buildings. It caused my FPS to dip down to 1 and slowed the game down to a ridiculous point.

Cainen: I do not now what build/version you used of NTAI, but the newest: 9.7b 9.7C and NTaiCaseTest builds do NOT (I've tested) overlay Peewees neither with XTA, BA or other mods. And there a no mention in the log about Peewees either.

What caused this? I used Goidse's AI and the thing spammed LLTs, Wind Generators, Metal Makers, and Advanced Solar Collectors. A few Rockos here and there, but nothing past 1st tier tech.

Using Goidse's config file, NTAI will require a very large amount of resources, before it techs to L2. This can be optimized by limiting construction of tier 1 units in the MaxEnergy section.

Posted: **16 May 2007, 23:21**

I all know that.

That build is made for some fast raid attack. Soon I will implement a tier 2 thing. But first I need to control all the best posibilities for a tier one.

It ins't easy to make a decent config. It is just a tasklist that is run trough every time, so you can't say: mmm lets wait 5 min to build that (or can it, without using 50 b_random_move ? :p)

You have to calculate everything to the point and every test costs lots of time...

With not to much bugging in the start it can win against all other bots I tried so far in 1vs1...

Posted: **16 May 2007, 23:36**

would it possible to have the source of the lastest version (or the version with case fix, for what it matters) so i can try to throw out a linux build of it?

Posted: **17 May 2007, 00:23**

Goidse wrote:I all know that.

That build is made for some fast raid attack. Soon I will implement a tier 2 thing. But first I need to control all the best posibilities for a tier one.

It ins't easy to make a decent config. It is just a tasklist that is run trough every time, so you can't say: mmm lets wait 5 min to build that (or can it, without using 50 b_random_move ? :p)

You have to calculate everything to the point and every test costs lots of time...

With not to much bugging in the start it can win against all other bots I tried so far in 1vs1...

It is? It never attacked once; have you tried making the minimum unit number for an assault lower?

Posted: **17 May 2007, 01:29**

I would warn that Emax and Emin can result in a void region where energy is both too low for tier 2 and too high for tier 1. There must be some overlap otherwise if NTai cannot make the jump from one region to the next it will be stuck in the middle unable to grow because the config says its too expensive for lvl 1 and not expensive enough for lvl 2.

Configs are all fine and mighty but sometimes they give possible outcomes that dont normally arise in automated AI routines. Sometimes they have their uses soemtimes they dont. Emax and Emin can control teching up indirectly, and they can prevent it too depending on the values used.

Posted: **17 May 2007, 08:25**

I├óÔé¼Ôäóve got the best result with a gradual overlap from tier 1 to tier 2, by gradual limiting tier unit 1 units. (emin is only used for some special units)
Eg. EMAX:

CORAK=500
CORTHUD=800
CORSUB=1200

This way I├óÔé¼Ôäóm gradual shutting down tier 1 factories, and thereby leaving resources for tier 2 construction.

Also a very rare energy saturation condition can happen:
- if tier 1 factories are shutdown including production of tier 1 construction units, and all tier 1 construction units are destroy by the enemy WITHOUT the enemy having destroy energy producing units.

Fortunately

this only happens rarely, as the enemy will normally destroy some of the energy producing units as well, and this restarts production of tier 1 construction units.

Posted: **17 May 2007, 08:57**

>> quotes from this thread about 3-4 pages back <<

DJ wrote:none from me I can't progress while the bad build pos spams up the console and slows the pc to a hault...

Perhaps "Couldnt find a build position" is more appropriate than "badpos 6"

I├óÔé¼Ôäóm experience the same slowdown/stutter as DJ reported, though I can live with it.

However I tried to do some analysis of this stutter to find is cause.

I initially believed :idea: it to be a stutter problem within spring engine and the ├óÔé¼┼ôping├óÔé¼┬Ø effect on minimap or map markers.

Deleting map markers quickly proved the stutter problem did not origin from these.

Making my own map marks, thereby generating minimaps ├óÔé¼┼ôpings├óÔé¼┬Ø quickly proved that the ├óÔé¼┼ôpings├óÔé¼┬Ø was NOT a cause for stutter.

Using the ├óÔé¼┼ôB├óÔé¼┬Ø key:
I found that whenever NTAI sets a ├óÔé¼┼ôbadpos 6├óÔé¼┬Ø mark the ├óÔé¼┼ôGLOBAL AI├óÔé¼┬Ø spikes at 100% cpu usage.

Loose observation:
It seems that the spike and stutter happens fractions of seconds before the ping and mapmark appear.

Probable (but not 100% certain) conclusion:
The code that NTAI runs just before setting a ├óÔé¼┼ôbad pos 6├óÔé¼┬Ø mark eats massive amount of cpu cycles. - Leading to very hefty stutter, especially late in the game.

Speculation:

My cpu is only single core, dual core cpu├óÔé¼Ôäós might not be affected as much, as only on core stutters.

Small help for config makes: :idea:
Take control of NTAI team (via .team x) and destroying units spamming ├óÔé¼┼ôbadpos 6├óÔé¼┬Ø sometimes gives a temporary relieving of the problem. (a little)

Posted: **17 May 2007, 10:21**

@Cainen: you used the latest testbuild?
The link is posted some posts up. And try to test it in SmallDevide, because I have tested everything there.

When I test my config they all go attack in groups of 8.

Soon I'll revamp my config and try the tier 2 :p.

Try this one:

After a while the AI just overkills my cpu :s. Maybe some CPU tweaks would be awsome!
When a bot can't reach a destination it keeps spamming that and the cpu-use peaks :/.

Posted: **17 May 2007, 13:54**

The most intensive algorithm of all in NTai is the build placement algorithm.

This is why it was placed in a seperate thread. If it places a marker its because it cant find a position which means it has searched the entire radius and ended up with a worst case scenario. A dual core cpu will help greatly, on my core 2 duo Global AI never takes up more than 5% of the cpu time as the most intensive calculations are done on the other core.

I'll remove the peewees and the markers soon, I'm just somewhat busy atm with coursework.

Posted: **18 May 2007, 11:29**

I have a problem with advance shipyards and build tags: b_assault and b_rand_assault

The problem is minor (as it is easy to work around), but for a future release it might be worth a quick fix:

The problem is that advance shipyards only build Flagships (black hydras) if given a build tag: b_assault and b_rand_assault

The log writes:

LOG wrote:[57:46] < Frame: 103999 >next task?
[57:46] < Frame: 103999 >CKeywordConstructionTask::Init b_assault
[57:46] < Frame: 103999 >Given the go ahead :: CORACSUB
[57:46] < Frame: 103999 >Given the go ahead :: CORMLS
[57:46] < Frame: 103999 >Given the go ahead :: CORRECL
[57:46] < Frame: 103999 >Given the go ahead :: CORSHARK
[57:46] < Frame: 103999 >Given the go ahead :: CORSSUB
[57:46] < Frame: 103999 >Given the go ahead :: CORARCH
[57:46] < Frame: 103999 >Given the go ahead :: CORCRUS
[57:46] < Frame: 103999 >Given the go ahead :: CORBATS
[57:46] < Frame: 103999 >Given the go ahead :: CORMSHIP
(3) insufficient metal to build CORBLACKHY, a stall is anticipated if construction is started
[57:46] < Frame: 103999 >Given the go ahead :: CORCARRY
[57:46] < Frame: 103999 >Given the go ahead :: CORSJAM
[57:46] < Frame: 103999 >Given the go ahead :: CORACSUB
[57:46] < Frame: 103999 >Given the go ahead :: CORMLS
[57:46] < Frame: 103999 >Given the go ahead :: CORRECL
[57:46] < Frame: 103999 >Given the go ahead :: CORSHARK
[57:46] < Frame: 103999 >Given the go ahead :: CORSSUB
[57:46] < Frame: 103999 >Given the go ahead :: CORARCH
[57:46] < Frame: 103999 >Given the go ahead :: CORCRUS
[57:46] < Frame: 103999 >Given the go ahead :: CORBATS
[57:46] < Frame: 103999 >Given the go ahead :: CORMSHIP
(3) insufficient metal to build CORBLACKHY, a stall is anticipated if construction is started
[57:46] < Frame: 103999 >Given the go ahead :: CORCARRY
[57:46] < Frame: 103999 >Given the go ahead :: CORSJAM
if(targ == string("")) for b_assault
[57:46] < Frame: 104001 >next task?

Or for b_rand_assault:

LOG wrote: [57:48] < Frame: 104045 >next task?
[57:48] < Frame: 104045 >CKeywordConstructionTask::Init b_rand_assault
[57:48] < Frame: 104045 >Given the go ahead :: CORACSUB
[57:48] < Frame: 104045 >Given the go ahead :: CORMLS
[57:48] < Frame: 104045 >Given the go ahead :: CORRECL
[57:48] < Frame: 104045 >Given the go ahead :: CORSHARK
[57:48] < Frame: 104045 >Given the go ahead :: CORSSUB
[57:48] < Frame: 104045 >Given the go ahead :: CORARCH
[57:48] < Frame: 104045 >Given the go ahead :: CORCRUS
(3) insufficient metal to build CORBATS, a stall is anticipated if construction is started
[57:48] < Frame: 104045 >Given the go ahead :: CORMSHIP
(3) insufficient metal to build CORBLACKHY, a stall is anticipated if construction is started
[57:48] < Frame: 104045 >Given the go ahead :: CORCARRY
[57:48] < Frame: 104045 >Given the go ahead :: CORSJAM
if(targ == string("")) for b_rand_assault
[57:48] < Frame: 104053 >next task?

These log entries keep repeating until antistall gives OK for CORBLACKHY.
And I have never observed the advance shipyard produce anything other than flagships given: b_rand_assault.

Just for your information

Good luck with the exams AF.

Posted: **19 May 2007, 01:55**

Thankyou, I have completed my academia commitments and I'm taking a rest for a few days.

The antistall algorithm should work perfectly. If this was the OTA engine, it would be extremely accurate. But this is spring, and the sub AI that drives resources is fundamentally flawed. When you are metal stalling you gain free metal. This would make the algorithm okish but not brilliant. Sadly thgins get worse. There's no order to fixed costs and cloaking costs and building costs at all. It may be that all your units are building and have fixed costs of 5 metal. Ideally the 5 metal fixed costs should be taken first then building, but its all jumbled up which makes spring economics extremely unpredictable.

As a result sometimes antistall is extremely strict yet the same setup is extremely lax under different circumstances and its never the same. Antistall can help, but it can also be unreliable at the same time because of springs economics. My agorithms cant create reliable predictions of the future resources available on which to make sound judgements.

btw: Given the go ahead :: is a message that the feasable() routine said yes aka no stall detected. This doesnt mean a unti was added to the list of candidates to be returned instead of the b_assault keyword, it just means thata check occured for stall condition before the unit was definition processed aka "before we check this build option lets see if we'd stall when we built it, if so discard it and dont bother checking"

You would do well to look at ubuild.h/cpp in the NTai source. Its relatively simple in structure and functionality and provides the logistics behind the universal build keywords.

Posted: **19 May 2007, 11:29**

DJ wrote:

none from me I can't progress while the bad build pos spams up the console and slows the pc to a hault...

I have a dual core cpu, an AMD Athlon 64 X2 2.8 ghz. I think the slow downs I have are because I deliberately wrote my config to expand massively. Literally by the time RAI has teched up NTai will have taken 90% of the map. Obviously at this point the build algorithm is really struggling to find a location to build stuff and is causing the slowdown. Whilst my config is perhaps an extreme case I don't think this issue will go away.

Spring RTS Engine

NTai XE10.1b