Screenshots from NTAI, to AF

[lale]

This thread is for documenting a performance issue with NTAI.
ALL units below Spammed "Can't reach destination" ("C.r.d")

OK first two shots are from a stuck constructor.
No fps drop was noticed for this:



However during a 8 minut period, the constructor NEVER gave up or tried to start a new construction somewhere else:



OK now for the REAL problem. A Sumo "C.r.d" spamming, stuck "f2" view:



zoomed out:



Without "f2" (normal view):



After the Sumo got attacked, it still spammed "C.r.d.", but got some new pathlines:



Since the most probale destination, is the "Attack pos" I took a shot in this direction, the Sumo is in the right, and the center cross is on the "Attack pos" mark.



After this the Sumo got attacked, and STOPED SPAMMING "C.r.d"'s
Notice how it now got an attack direction line:



Here is another unit, same "C.r.d" problem, A Banisher tank:
(I'm Red and the enemy is white dots on radar. The selected banisher is also white, due to being selected :douhhh:)


Overhead:



Closeup of ruble in-front:



Notice how the tank are trying to pathfind trough the ruble:



And finally a Goliath on a ledge:



With "F2":



In this final image, the Goliath unsticks it self, after several minuts, because it is getting attacked. When this happens, the "C.r.d" spam stops, and the FPS raises.

[AF]

I'm still not sure what I'm supposed to do to fix this short of attempting to implement a full pathfinder (ETA 6 months minimum).

I take it these units do not have a tasklist? If they do I'd scratch them but I suspect they dont anyway.

Is this just attack units?

As a tip, if the cursor is bigger than the unit your trying to show then your 150% too far zoomed out, and as you zoom out the amount of unit specific information degrades very quickly.

Can you try to recreate this with 1 unit (aka no side factories, conbots etc cluttering up the logs, interfering), via .cheat .give select com self destruct wait.

[lale]

I take it these units do not have a tasklist? If they do I'd scratch them but I suspect they dont anyway.

If you refer to a tasklist in the config file the answer is NO. (Except constructor in first 2 shots, but see below)

Is this just attack units?

I am only 99% sure but: Construction units messaging ├óÔé¼┼ôCan├óÔé¼Ôäót reach destination├óÔé¼┬Ø do NOT affect framerate / performance. Framerate drop are ONLY for semi-big and big attack units.
My suggestion: Narrow focus on attackers with big footprint, they are the ones responsible for big framrate drop.

As a tip, if the cursor is bigger than the unit your trying to show then your 150% too far zoomed out, and as you zoom out the amount of unit specific information degrades very quickly.

OK; the zoomed-out views, was to give you an overview of the settings

Can you try to recreate this with 1 unit (aka no side factories, conbots etc cluttering up the logs, interfering), via .cheat .give select com self destruct wait.

OK I will try, but I need to find out, if this is somehow related to attack group thing. E.g. if the ├óÔé¼┼ôinitial attack size├óÔé¼┬Ø parameter has something to do with this, because if it does, destroying other elements in an attack group, might trigger NTAI to re-evaluate offending units destination? (unsticking it)

I'm still not sure what I'm supposed to do to fix this short of attempting to implement a full pathfinder (ETA 6 months minimum).

OK... I really do not understand NTAI interaction with Springs pathfinding. But if NTAI simply sets a long distance destination for the unit, and leaves Spring do the pathfinding, (except if unit is attacked) then two really dirty solutions come to mind :idea:

• 0) Develop a method to identify attack units spamming (├óÔé¼┼ôC.r.d├óÔé¼┬Ø) (trying constantly to get new orders ). For example, if a unit asks for new orders 10 times within 100 frames. Or another method could be, if unit hasn├óÔé¼Ôäót moved for 100 frames despite given several orders.
  1) Send unit a STOP command, and leave it abandoned (guarding
  2) Improvement on above: When a STOP command is issued, set a timer (500 frames) for this unit, when timer runs out, try to reactivate unit. If fails, repeat step 0 and 1, and set timer larger (1000 frames)
  B) Alternative, instead of sending STOP, set unit to ├óÔé¼┼ôretreat├óÔé¼┬Ø mode, like when its damaged. This way it goes in the opposite direction, hopeful (in theory) unsticking it self.

[lale]

Big├óÔé¼┬ØGolden├óÔé¼┬Ø solution: (AF, see previous post for a quick dirty fix)

First NTAI needs a method of identifying ├óÔé¼┬ØCan├óÔé¼Ôäót reach destination├óÔé¼┬Ø. Since this message is for a human ├óÔé¼┼ôAI├óÔé¼┬Ø, Spring should also transpires the same message to NTAI. If not , then lobbying Spring devs to get this message to AI, is one place to start├óÔé¼┬ª

Second, let├óÔé¼Ôäós split this problem for an assault unit

4├é┬¢ reasons and attacker can spam ├óÔé¼┼ôC.r.d├óÔé¼┬Ø s:

• 1) Its stuck on a corpse or entangled with a building
  2) Its entangled with another unit.
  4) Its under attack, and can not manoeuvre into weapons range.
  4) Its trying to reach a destination, but have no possible path to destination, or the path is to complex for the pathfinder to resolve.
  4›) There is a bug in the Spring engine / Pathfinder.

(In the solution below, Im presuming that a retreating unit is re-evaluted, from time to time by NTAI. Otherwise NTAI will become the "coward" AI
Solutions:

• 1) If it├óÔé¼Ôäós entangled with a corpse or building. The solution is in the Spring engine, as movement routine should allow unit to move out. I believe that Spring is currently doing this to a certain extent. But there might still be a problem in spring engine with corpses / ruble (See Banisher screenshot)
  2) If it├óÔé¼Ôäós entangled with another unit, solution: WAIT. (for 300 frames) Let the other unit solve the problem.
  3) Solution: RETREAT. And if retreat path is block, then this falls under solution 4.
  4) Solution: Random direction/destination 50-200pixels away. Let Spring handle the unit until it reaches the destination, then Spring should call NTAI again for new orders. If unit can NOT reach new destination choose another Random. This way the unit goes into a ├óÔé¼┼ôsearch and guard area├óÔé¼┬Ø mode.
  4›) Unfortunately this needs addressing to Solution (Quick and Dirty) send STOP and HOLD POS to unit, or selfdestroy unit. (Might give human players a kick
  X) Special solution for water units: Check taget type, taget should be ship or sub, otherwise find a sub/ship target or retreat

Granted, all above solutions requires a method of identifying what the cause for ├óÔé¼┼ôC.r.d├óÔé¼┬Ø is for the offending assault unit. And this is the hard coding problem.

[AF]

For now I guess I'll have to work on making them retreat fi they get a movefailed.

The reason construction units dont get this is because when a task is finished theres a small random wait before the next task is started preventing 30 tasks per second syndrome, which can grind the game to a halt. The task system however is not whats driving attackers, and the attacker routine isn't flexible enough to allow a time wait. The default behaviour for the unitmovefailed is to interpret it as a unitidle() call and move to the next task or behaviour.

And indeed spring has a bug with units getting stuck. Its todo with pushing units out of the way and rubble. Order 10 con kbots to build 2 large rows of metalmakers. there's a good chance at the end you'll have at least 1 kbot partially stuck inside a metalmaker.

The same thing can happen with units and rubble.

There's also when a unit goes into a wreckage but because it cant turn to get out it gets stuck untill the user manages to free the trapped unit.

I could always call the engine to ask if there is a path to the destination but there's 2 problems:

a) It was commented out and set to always return true regardless, this may have changed I'd have to check
b) Its a very cpu expensive call to make

[AF]

http://www.darkstars.co.uk/randomfiles/NTaiXE9.71a.zip

Try that build. When an attacker gets a movefailed order it will get told to retreat back to base.

[lale]

For now I guess I'll have to work on making them retreat fi they get a movefailed.

OK, but I├óÔé¼Ôäóm somewhat concerned, about ├óÔé¼┼ôC.r.d├óÔé¼┬Øs happen during a retreat, but have yet to observe one, so let├óÔé¼Ôäós forget it for now.

The reason construction units dont get this is because when a task is finished theres a small random wait before the next task is started preventing 30 tasks per second syndrome, which can grind the game to a halt.

Also what I observe, and construction units furthermore sometimes skip to next item in list, meaning that they are given a new destination. (For some waayyy future release of NTAI, it might be nice to have a handler for the situation with the convp in the first screenshots)

The task system however is not whats driving attackers, and the attacker routine isn't flexible enough to allow a time wait. The default behaviour for the unitmovefailed is to interpret it as a unitidle() call and move to the next task or behaviour.

NO timed wait rats! ├óÔé¼ÔÇ£ this really makes my suggested solutions impossible.

And indeed spring has a bug with units getting stuck. Its todo with pushing units out of the way and rubble. Order 10 con kbots to build 2 large rows of metalmakers. there's a good chance at the end you'll have at least 1 kbot partially stuck inside a metalmaker.

Luckily NTAI seem to handle this very well. I have yet to see constructor permanently stuck in a building.
The only units stuck in buildings, is when NTAI constructs a factory with exit too close to a cliff or mex.

The same thing can happen with units and rubble.

There's also when a unit goes into a wreckage but because it cant turn to get out it gets stuck untill the user manages to free the trapped unit.

It├óÔé¼Ôäós my deep feeling, that a good amount of ├óÔé¼┼ôC.r.d├óÔé¼┬Ø spam├óÔé¼Ôäós is due to Spring not handling decimating of wreckage/rubble correctly, when a unit tries to pass through.

I could always call the engine to ask if there is a path to the destination but there's 2 problems:

a) It was commented out and set to always return true regardless, this may have changed I'd have to check
b) Its a very cpu expensive call to make

Well, human ├óÔé¼┼ôAI├óÔé¼┬Ø getting ├óÔé¼┼ôC.r.d├óÔé¼┬Øs can├óÔé¼Ôäót figure out if there is a path to destination either. So NTAI├óÔé¼Ôäós should respond like a human, try random walk combined with time wait, but as you already point out, this solution is currently motd.

I├óÔé¼Ôäóle test the new build this evening.

If this build do not solve the problem, is it possible for you to include debug log info in a build, that gives info about objective for move or attack destination orders (from NTAI to spring)?

[lale]

Problem solved, no more drastic slowdowns due to ├óÔé¼┼ôCan├óÔé¼Ôäót reach destination├óÔé¼┬Ø
Also the stutter due to "bad pos1" is (almost?) gone
Actually ├óÔé¼┼ôC.r.d.├óÔé¼┬Ø├óÔé¼Ôäós are rare with the new build, except with water units that keep trying to attack land units.
Games with NTAI water units are still somewhat ineffective, but at least without fps slowdowns.

However, the new build introduces a new issue.
Geo hunting is TOO effective.
Basically, in the old build, constructors would only go for geo spot within a close range of ├óÔé¼┼ôbase├óÔé¼┬Ø limits.
In the new build, they will try to build geos at every spot on the map, even though a spot is in the centre of enemy base.
If the enemy has a good defended area in constructor├óÔé¼Ôäós path to ANY geo, then this causes lemming effect.
Only solution is to either remove all geos from constructor list, or be prepared to pay bigtime for geos.
- ohh well, I understand your motives for helping kernel-mod. And geo├óÔé¼Ôäós aren├óÔé¼Ôäót that important for TA mods.

AF, when you make a ├óÔé¼┼ôend users├óÔé¼┬Ø build, will you consider doing the following small things:
Do NOT remove the debug info; instead make ├óÔé¼┼ô.verbose├óÔé¼┬Ø default false, find the 4 info sentences:

• ├óÔé¼┼ônext task?├óÔé¼┬Ø
  ├óÔé¼┼ôloading content of tasklist ::├óÔé¼┬Ø
  ├óÔé¼┼ôfilling tasklist with #xx items├óÔé¼┬Ø
  if string =├óÔé¼┬Ø├óÔé¼┬Ø (this one log's, if a build keyword has no match like b_sub)

And make these info sentences also be affected by the .verbose command. This way, its still possible for config builder to trace problems with NTAI. And "End users" not having there console spammed with log info.

Finally, you might want to update the info in your toolkit with the current list of build keywords that do not work (e.g. b_sub, b_fighter)

[AF]

Thats kernel panics fault. I'll extend the enemy radius check from 50 to 300.

[lale]

I'll extend the enemy radius check from 50 to 300.

This is NOT going to affect commanders check for enemy scouts, during construction?!?

E.g. Commander in the middle of shipyard construction, enemy scoutship comes within 300, Commander abbandons constructions to fight.

Otherwise I will strongly prefer that you keep it at 50.

- I can accept not building geos.. But the commanders constant quiting constructions, due to enemy scouts, is already problematic. Making it worse is a very bad idea.

[AF]

No this si different. This si while its looking for a buildspot to begin with, itll see how many enemies are within a radiu of that position been tested and if its bigger than 0 it skips it.

The reason its 50 is so that it can detect sockets and windows in kernel panic.

[zwzsg]

Geo hunting is TOO effective.

Too effective? Sounds like a good thing, not an issue.

Thats kernel panics fault.

Hey!

• Don't blame Kernel Panic!
• I need NTai to keep on working with Kernel Panic!

For Kernel Panic, it is super extra important that builders cover all geos as soon as possible. If the AI forget any geo, or even is a bit too slow to cover it, then it'll loose the game.

Although I agree that even for Kernel Panic, sending lone builder to die one by one at the hand of the enemy is kinda stupid. But if I had to choose, I'd rather have AI lose a builder from time to time, than to risk having the AI ignore geos close to enemy.

Come to think of it, it also applies to TA mods to a certain extent: a cons kbot or a cons veh is not a big loss, but having a geo provide a huge economic advantage.

If the new "build geo" task really cause problems in other mods, then, add something to make it controllable with the profile. Either split it between b_geo_safe and b_geo_daring, or add some radius setting, or whatever. You've made an AI configurable with profile, that makes it the only AI able to play different mods such as KP, so leverage the advantage given by profile to the fullest extent!

I'll extend the enemy radius check from 50 to 300.

Hint: hard coding values like that is a bad approach, you can't have one radius fit all. Instead, make it definable in the profile.

Do NOT remove the debug info; instead make ├óÔé¼┼ô.verbose├óÔé¼┬Ø default false, find the 4 info sentences:

├óÔé¼┼ônext task?├óÔé¼┬Ø
├óÔé¼┼ôloading content of tasklist ::├óÔé¼┬Ø
├óÔé¼┼ôfilling tasklist with #xx items├óÔé¼┬Ø
if string =├óÔé¼┬Ø├óÔé¼┬Ø (this one log's, if a build keyword has no match like b_sub)

And make these info sentences also be affected by the .verbose command. This way, its still possible for config builder to trace problems with NTAI. And "End users" not having there console spammed with log info.

I fully agree with that. I'll paraphrase it for added emphase:
Make all debug info OFF by default, but turnable on with a simple command such as .verbose.

That way:
- By default, and for end users, there's zero console & marker spam.
- Profile makers and testers can turn it on when they have issues to investigate.