unit-production of YMSAI is broken... but WHY?

[yanom]

Knorke said:

the makeSomeUnits() would have to be fixed to follow the list more closely. Right now it often builds more units then defined.

knorke says here that the makeSomeUnits() function of YMSAI often queues up a unit on it's production list twice, producing more units than intended. This is true, and the bug was present in the original Schwarm AI and has not been fixed in YMSAI because, unfortunately, I cannot find the bug, let alone fix it. Can anyone locate the source of this bug for me?

[hoijui]

what i can see working, possibly (likely even):
you publicize the code right here, and then some people will have a look and one of them might find the bug.

much lower chance of success:
you wait till someone says he will fix the bug, and only then you give the code to that person alone.
it goes along the lines of how to get help on IRC.

-> show code please

[yanom]

oops. forgot to attach it. Here it is:

[knorke]

just link to the SVN:
http://code.google.com/p/conflictterra/ ... warmAI.lua

Anyway, every second the AI does this

Code: Select all

local h, missing = getHighestCompleteStage (myTeam[t])
makeSomeUnits (myTeam[t], missing)

It gets what units it needs to reach the next stage and then orders other units to build those.

Now the problem is, if a unit is given the order to build ie a factory, it does not do so instantly.
It has to walk to the construction site. If this walking takes longer then 1 second, the AI is already checking the "needed units list" again, notices there still is no factory and assign the "factory task" again to a second builder.
(It assigns to a new unit because the AI remembers that the first builder already has an order.)
Now there are two units building a factory.

Same with morphing, if the morphing takes too long (it usually does) then more units are orderd to morph then needed.

So to fix it, the AI has to be keep track what units are still missing but do not need to be ordered to built, because somebody "will do it" in the next few seconds.
A table like
inProgress[unitName] = number of units already ordered to be build

Of course if a builder dies while walking to a construction site, his job would have to be reassigned. Same if the builder takes too long to reach the site (ie stuck)

Or just make the AI give build orders slower, not every second but only every 10 seconds or so. But that is not really a good solution.

function gadget:GameFrame(frame)
if (frame % 30 ~=0) then return end

[PicassoCT]

You could make a table of stunned units (means the AI can for a defined time, or amount of loops not touch or use them) and then attach the stunned virtual factory to the unit with the job to built it. Once the unit goes, it takes the virtual factory with it, allowing for a new try.

Even neater, this way you can really check with the AI if something takes longer than usual (conunit stuck, ressource stall) and if something stunned is not done within its timelimit, you can check for the error ( unionizing Cons, not enough crystalls from the sky)..

[knorke]

You could make a table of stunned units (means the AI can for a defined time, or amount of loops not touch or use them)

already possible and being used by doing
unitOnMission [unitID] = 90
Not relevant for this problem though which goes like this:

loop 1:
missing units: 1 factory
->select a random builder for the job
->Bob, I chose you!

Bob the builder walks to construction site.

30 frames later
loop 2:
missing units: 1 factory, because Bob is still walking'n'talking
->select a random builder for the job
->Hey Bob! oh never you mind you are already doing something
->Hey Joe, I chose you!

Joe the builder walks to construction site.

30 frames later
eventually Bob has started construction, no more missing units
Joe is still walking to construction site

loop 3:
missing units: 0 factory -> advance to next stage

So the AI should be asking Hey Joe, where are you going to with that nano beam in your hand?

[PicassoCT]

I understood that already, (something mumbled about programers always perceving everyone else as stupid, and acting that out in attitude)

my suggestion was that the moment, the factorybuiltcomand is given, a placeholder for a factory is created at the place where it is going to exist, and this placeholder is percived by the AI as a factory(not on a mission, because then the AI would start adding buildorders for the factory..ups, why not..)

why downcompare two tables (is there a builder (table1) who has mission to build (table2) a fagtorrie (not a table) if you could just search the list of units for a existing (although stunned) virtObj...

so whose suggestion is moar elegant? The ModArtMadmen ones...

[oksnoop2]

Wow, I have no way to contribute to this conversation in a meaningful manner... Knorke, I loved your Hendrix reference.

[yanom]

[quote="knorke"

So to fix it, the AI has to be keep track what units are still missing but do not need to be ordered to built, because somebody "will do it" in the next few seconds.
A table like
inProgress[unitName] = number of units already ordered to be build
[/quote]


I'm working on that solution... made a table unitsInProgress[teamID] to store units in progress

[yanom]

I'm working on that solution... made a table unitsInProgress[teamID] to store units in progress

Ok, I'm having a lot of trouble with this... can someone give me a good solution in more detail?