Battlezone Forums

On an aip, I added all prerequesites to each plan. If the ai was building sabres, it checked for the existance of enough power, the existence of a relaly bunker, and factory. This slowed down AIP execution drastically.

Red Devil wrote:there are a few good reasons to use ContinueEvenIfFail = false

I tend to use it on base building plans since plans after it use no conditions and the ai must build the base first.
Which kinda garantees the following plans dont stall the ai.

Attacker plans: things tend to stall while waiting for the units [to] stage, especially if they're treaded units that have to go a long ways to stage points.

speaking of attacker plans, don't mix treaded and hover units in the same group - the hover units will wait for the treaded units to stage and then they go off to attack, leaving the treaded units stranded halfway to the attack target after the hover units die, then the treaded units have to return to the stage point; rinse, repeat.

also, try not to use ContunueEvenIfFail = false on collectpool plans or on plans that don't require building or collecting/accumulating scrap (distributeunits, defendarea/cleararea, etc.)

I think the general idea of the BuildLoop vs BuildMinimus/Attacker (buildifnoidle) plan set is that the loops don't actually use Attacker plans, but rather let the Idle Dispatcher send the units out to attack when ever there's X amount of units "built up" in the base.

I'm not sure if Idle Dispatcher uses stage points or not.

from what i recall, they do not; same as DefendArea/ClearArea. i could be mistaken, though, this being new years.

I think they don't as well, which is desirable in this case.

the main problem with the idle dispatcher not using stage points is that it produces attacks directly pretty much in a straight line, from one base to another. the other is that it sends a variety of units, some of which may not be suited for the target.

Red Devil wrote:Attacker plans: things tend to stall while waiting for the units [to] stage, especially if they're treaded units that have to go a long ways to stage points.

None of the attacks are handled by th aip. The aip isnt good at it and lacks any form of tactical control. The dll does not

the main problem with the idle dispatcher not using stage points is that it produces attacks directly pretty much in a straight line, from one base to another. the other is that it sends a variety of units, some of which may not be suited for the target.

It is down to the AIP maker to ensure that units do not become idle when an AIP is switched. Units that do become idle need to be disposed of in order to preserve the smooth running of the game. There is no better way than having them converted to loose scrap by the teams defenses. It also causes some attacks to seem quite randomized in their makeup and execution with vehicles attacking from wherever they became idle.
AIP makers should include "exists" conditions and attack commands to vehicles no longer built by the current aip if they don't want them idle dispatched.

If an AIP changes, there is nothing that AIP maker can do. The AIP loses track of units built in the previous plan. I asked for options for the AIP to have access to SetLabel and GetLabel, both DLL functions, to work around this, but was told it would be too much work to be worth it. Basically allowing an AIP to get a unit using it's engine-generated label. I would think this would fix a multitude of things. For example.

1. AI Building multiples of the same building in laggy games. If a game is resyncing constantly, the ai can end up with multiple antenna mounds or bomber bays. I have seen both occurences in resync heavy games.

2. AI losing track of units in II3 or II1 plans when the ai switches to IIL or IIS or IIA plans. Replace II with IF, or FI depending on the player and ai's race.

Looses count of them certainly, a conditional exists attacker plan is only useful if they are not being built by the current AIP.

awhile back, when i was testing a lot, i found that "lost" units are "rediscovered" by the engine/AIP if they are damaged even a just little; pretty sure i bugged it. to get around it, just give them a little kiss of 1 damage every 10..30 ticks. i also found another way to prevent them from getting lost, but i can't remember it right now.

the running AIP gets reloaded on every resync, be that from a join or whatever, so the chances of units getting lost is...high.

Red Spot wrote:

Red Devil wrote:Attacker plans: things tend to stall while waiting for the units [to] stage, especially if they're treaded units that have to go a long ways to stage points.

None of the attacks are handled by th aip. The aip isnt good at it and lacks any form of tactical control. The dll does not

talkig about vsr or something else? i was talking about attacker plans in aip's.

I think he is talking about how he did his mod(???) thing.

Maybe some conditions on build plans would help, like Not exist ivatank 5...build ivatank 5. That way any lost ivatank would end the build after 4 and then presumably get sent off by the attacker plan with the others.
I used conditions extensively in the aip I built and really never noticed many units going idle at all, even when I switched back and forth between AIPS using different strategies.