Spring RTS Engine

AF wrote: I've made it totally impossible to issue a command containing the top corner location, they're intercepted and discarded on sight now before they ever reach the engine.

From the new version, AI vs. AI
Arm vs. Core
AbsoluteA on Hells Pass
(Cheating was on as well, if that helps)



Top left strikes back!

OK, I've done some testing and buildtree revision, and I have some suggestions:

1) Increase the range of B_GUARDIAN. It's my understanding that currently it only repairs units within its repair range, which is bad. It should repair any unit within its sight range. Currently I have to do a bunch of B_GUARDIAN, B_RAND_MOVE, B_GUARDIAN, B_RAND_MOVE which is very inefficient

2) Currently: A construction unit wants to build a mex. All of the spots in its base have been capped. It tries to look for some in its opponents base. It is blown up, wasting metal.

Ideal: A construction unit wants to build a mex. All of the spots in its base have been capped. It decides to go onto the next item on its agenda.

I don't need it to be complex; just something where construction units do not go into any area of threat level X or higher.

3) What's with all the pauses? After NTai completes anything, that construction unit pauses for an entire second. This really slows NTai down early game, allowing KAI to gain a slim lead.

4) I don't think B_GUNSHIP is properly detecting gunships, at least it wasn't last version

Oh, and what is the tag for guarding a factory? You mentioned it, but never gave the syntax...

I have a much improved build tree, but I won't release it until it is capable of consistantly defeating KAI on deltasiege.

* * *

On another note:

Yes, I know that you wanted to stop development of NTai, to work on Epic and the "secret project" ( ), but if you did that, NTai would just fall farther and farther behind KAI, which would be very depressing.

What you should do instead is just sort of combine NTai and Epic (you can just start calling it Epic AI at some point.) Keep updating NTai, gradually coding and adding the features that you wanted in Epic. Eventually, there will be no NTai left, and lots of Epicness.

IMO it makes no sense to completely code a new AI from the ground up when you already have a decent working AI. Just rebuild the current AI from the ground up.

Just thought I'd say props on the new version. It is much more stable on my computer. I just finished a two hour long match against a few of them - very nice to not get a hardlock as soon as I went on the offensive.

Up till now I've preferred aai because a spring crash > a computer hardlock, but the new version seems to be playing much better, so grats.

i see the problem with atatck units, so last night I did a bit of meddling ;D

Attack unti behaviour ahs been greatly improved, untis wotn just aimlessly wander now, if a unti gets atatcked then it fires off a Beacon and any unit randomyl moving or seeking out points of interest withina 2000 pixel radius is sent to their locationa nd end up helping. Remember that Brazillian Battlefields is 8000x8000 pixels.

Whatsmore, I applied a lot of new logic to the points of interest to make units want to seek them out even more, and i believe I've fixed the issue with b_gunship.

Lindir, add corsy adn armsy to the bit at the bottom of mod.tdf that prevents them starting new constructions if an existing one in range isnt finished, add B_RANDMOVE tags to them, andmake them want to tech up more and make corsy/armsy build mroe ships than cons.

I also now know why those pauses occur. They're because not all of your buildtree is being executed properly. The tasks are going through the system reaching the engine then getting a bad return and getting ignored. This is a building placement problem, and I have a solution that is underway but will take time. It will bring with it a whole new set of improvements that'll affect the entire AI so it looks as if this is XE10 stuff.

try B_GUARD_FACTORY and B_GUARD_LIKE OR B_GUARDFACTORY and B_GUARDLIKE.

But dont withhold lindir, I'm releasing RC18 tongiht and I need errors fixed in the buildtree such as reatreat instead of B_RETREAT as they're showing up in the console.

Also the crash to desktop bug once again vanishes when I compile in debug mode so i might aswell release a debug build.

Download here

I've added NTaiDEBUG.dll as it seems to be 100% stable and have no crash errors at all

Yeah... Tonight for you is noon for me...

And I don't have access to my home computer until 5:30 my time.

But I'll get you a buildtree tonight my time.

* * *

add B_RANDMOVE tags to them, andmake them want to tech up more and make corsy/armsy build mroe ships than cons.

I really don't like B_RANDMOVE; I think the unit's time could be better spent building something than moving randomly.

To make them want to tech up more I'll increase max_stall_time back to what it was before you lowered it.

And that should fix the building so many cons.

Played for a while last night, can't recall, at least 120 minutes, and there were lag spikes.

I was fumbling and happened to hit 'b' on the keyboard, and was presented with all kinds of data and a graphical representation of what must of been some type of AI thinking. Anyway, I noticed during the lag spikes, the AI registered as 33+%, which I assume is CPU time. It'd last for a second or two or three, and subside.

I had logs.. but deleted them thinking they were old. Hopefully I'm not the only one that gets it on occasion though.

Oh, and ".give 100 team1 armcom" in the middle of the AI base created, in short order, a massive explosion. ".give 1000 team1 armcom" just resulted in Spring crashing. Very pretty :) Nothing to do with NTai, but, well, it was cool.

Updated buildtree!

I decided to make NTai more flexible by setting up B_RULE to almost always build a resource structure, depending on M and E levels. So I put this:
into the mod.tdf file. I then went through and replaced almost every B_POWER and B_MEX with a B_RULE.

Unfortunately, when I tested it, B_RULE was borked.

It always executed a B_POWER, even when NTai was m-stalling and had max capacity e. This is a bug.

But if you can fix it to work as advertised, the following buildtree should work very well:
http://www.fileuniverse.com/?p=showitem&ID=3528

I can't believe it. the DEBUG one just started to build something. That's the first one working since 7.5. The other two still don't work.
AI1 = DEBUG
AI2 = LOG
AI3 = normal

I had amde an error with b_rule_extreme and B_RULE. I mixed up power and mexes, so if the AI needed mexes it built energy stuff and vice versa.

I'll have a fix tomorrow morning

Excellent.

I should have another completely untested currently untestable buildtree tonight.

Lindir, get rid of B_SOLAR and use B_POWER, the next version will make it mandatory, parsing B_SOLAR as B_POWER.

Change your rule modifiers so that storage has a modifier of 0.99 nto 1.2, storage increases the AI's ability to juggle metalmakers and it makes the rules more accurate.

And if the NTai commander is blown up then the storage is all gone as you didnt tell it to build any, and all the rule systems and the metalmaker stuff start to go haywire as they wherent designed for such an event.

In the buildnear thing, increase the ranges of HLT's from 50 to 500, and increase mohometal makers likewise.

And why do you want 7 seconds of stall time allowed?

dammit I dont have time to reupload source

And add a B_RANDMOVE to con ships, the whole point of that tag in construction lists wa to spread buildings out, as a result shipyards tend to get close togetehr and hordes fo repairing con ships stop atatck ships/subs from getting out.

And decrease the con to atatcker ratio for ships.

And add a tag that makes it stop building lvl 1 shipyards once energy surpasses 1500.

Actually, take a break for now. I'm gonna edit it myself for tomrorow when i do RC18

AF wrote:Lindir, get rid of B_SOLAR and use B_POWER, the next version will make it mandatory, parsing B_SOLAR as B_POWER.

I did... B_POWER is in only 1 place, in the commander buildtree. And B_SOLAR is non-existant.

Note that corcom.txt, armcom.txt, corck.txt, armck.txt, corcv.txt, armcv.txt, corca.txt, and armca.txt are no longer used, and are not included with the most recent buildtree on FU.

Change your rule modifiers so that storage has a modifier of 0.99 nto 1.2, storage increases the AI's ability to juggle metalmakers and it makes the rules more accurate.

When you are maxed out in metal you should NOT build a metal storage. You should build a factory.

But I guess I could add a few storages manually in the buildtree

In the buildnear thing, increase the ranges of HLT's from 50 to 500, and increase mohometal makers likewise.

Yes, I will completely redo that section, keeping in mind that BB is 8000 units long. I thought it was closer to 1000.

And why do you want 7 seconds of stall time allowed?

Because stalling for 7 seconds is not very bad; I often stall for minutes or more when I'm getting my first cloackable fusion up.

And add a B_RANDMOVE to con ships, the whole point of that tag in construction lists wa to spread buildings out, as a result shipyards tend to get close togetehr and hordes fo repairing con ships stop atatck ships/subs from getting out.

Fine, I'll add it right before a few factories. I still don't like it though... But I guess I understand it for ships.

And decrease the con to atatcker ratio for ships.

OK. I'll add a few more B_ASSAULTs to the end.

And add a tag that makes it stop building lvl 1 shipyards once energy surpasses 1500.

Hmm... That's an interesting idea. Stopping construction of lvl 1 plants after a certain point... I'll set some of that up.

Actually, take a break for now. I'm gonna edit it myself for tomrorow when i do RC18

NO! I want to do this.

You are good at AI coding, but you don't understand how my buildtree is supposed to fit together. That's why I almost never like your changes.

If it is a really good change, convince me to implement it and I will. But don't just go around changing stuff at whim.

P.S.

Actually, you have my stamp of approval on any change to the B_RULE stuff. Because all of it is untested and, due to the current problems, untestable.

And no, I will not go through and change all the B_RULES back just for testing.

Edit: And here's the buildtree!

http://www.fileuniverse.com/?p=showitem&ID=3542

Your buildtree isn't very useful on Delta Siege because it keeps spamming windgens and nothing else, Lindir.

Though both buildtrees need some more defensive structures here and there, at least an early LLT.

B_RULE will build storage but Factorys take priority, it will in the vast majority of cases build a factory, so theres no reason to have 1.2 as a storage rule value.

As for spamming windgens maybe that'll change with RC18.

And nanostall at all is a bad thing. If you stall for minutes at a time when trying to get your first cloakable fusion up then that is VERY bad. You need to build more infrastructure before starting it.

Resources should never be maxed out, and resources should never be at <5%, this isnt an AI rule this is a general set of rules for anyone AI or player.

IMO NTAI is too docile. It needs to attack more. On normal maps whenI set starting res insanely high, it buildloads of units, but doesn't send themto attack me often.

rattle wrote:Your buildtree isn't very useful on Delta Siege because it keeps spamming windgens and nothing else, Lindir.

Have you been paying attention at ALL?

I wrote:It always executed a B_POWER, even when NTai was m-stalling and had max capacity e. This is a bug.

AF wrote:I had amde an error with b_rule_extreme and B_RULE. I mixed up power and mexes, so if the AI needed mexes it built energy stuff and vice versa. I'll have a fix tomorrow morning

I wrote:NTai XTA buildtree V.0.7.2. Won't work well until RC18.

And then you tell me that my buildtree is broken in RC17.

* * *

AF wrote:B_RULE will build storage but Factorys take priority, it will in the vast majority of cases build a factory, so theres no reason to have 1.2 as a storage rule value.

I changed that. Check the FU buildtree. Now it should build a storage when it is maxed out.

As for spamming windgens maybe that'll change with RC18.

It had better!

Resources should never be maxed out, and resources should never be at <5%, this isnt an AI rule this is a general set of rules for anyone AI or player.

I disagree. And every strategy guide that I have read also dissagrees.

The best player is ALWAYS m-stalling, because that means that he is at max production. Any m in storage is just wasted; it would be better spent in combat units.

But E should always be near the top, in case an e-using weapon needs to fire. Now, ideally, e should be fluctuating near the bottom due to metal makers normally, and then near the top during battles, but NTai is not smart enough to do this. So NTai should always have excess e.

But, anyways, I am completely redoing everything again, to work better with the B_RULE construction system. And, hey, where's RC18?

I have RC18 ready here with installer + source and I have found the crash bug that kicked people out of spring and banished ti once and for all

The cause?!?!?!?!? Well there's 2 of them

- A divide by zero bug in the rule system.
- Faulty syntax in Lindirs buildtree.

The latter one was found as a result of me porting TDFParser to replace the CSunParser class (aren't you lucky rattle(his NTai crashed because of the error in CSunParser that forced the spring devs to move to TDFParser to begin with)).

Lindir you keep doing "\\" but it's actually "//", and multiline comments are encase in /* */, you keep putting a "\\" then writing laodsa lines of comments afterwards, you need a "//" at the beginning of each new line or encase the Lot in a /* */.

New feature time.

I intended much greater changes to the buildtree after I noticed something while debugging that got me very happy, I want the commander to guard the lvl 1 factory, even just temporarily, and let the construction units do the expanding. NTai seems better able to expand and build now since it doesn't idle builders as much (I have a total solution around the corner that brings a bag full of goodies with it).

Most notably I've fiddled mod.tdf values and some factories. I've also fiddled the units random idle movement to be even more aggressive to move them onto a target faster, which when combined with greater attack unit output makes for a much bigger offensive, tests showed on small supreme battlefield that it was NTai who was sending the units towards KAI's base and NTai who had control of the middle land bridge.

I have also added a feature I've crudely named Rule Interpolation.

When turned on say the build list is a,b,c,d,e,f, what it does is add a B_RULE_EXTREME in between each so a,*,b,*,c,*,d,* etc. This can be halted and resumed using keywords no_polate and interpolate.

Also as a consequence of the new TDFParser, AI\\MetaTags is now useless and is ignored as it isn't needed anymore. Also all metatags need to be lowercase to be detected properly.

I also fixed an array of warnings and problems with the source code on Mingw32/GCC Linux. There will now be no warnings about newlines missing at the end of files, no process.h/io.h errors, and no files that're there for reference, e.g. factor.h/cpp (removed).

Also one or two speed improvements, not sure how noticeable.