|
berto -> Coder Diary #19 -- A/I Dithering Unit, Backtracking Move Bug -- Fixed! (4/22/2014 7:04:12 AM)
|
Coder Diary #19 -- A/I Dithering Unit, Backtracking Move Bug -- Fixed!
What is the most vexing, most notorious bug in all of the Campaign Series? Might it be this?
A unit, or stack of units, "dithers", can't make up its mind, as it moves forwards, then backwards, forwards again, then backwards again, ... in some cases, turn after turn after turn...
Worse still, this often happens in the rear, out of harms way. There is no rhyme or reason to it. (Well, maybe there is a rhyme: "forwards, then backwards, forwards, then backwards".)
Nothing destroys the immersion so much as seeing your A/I opponent move units back and forth, back and forth so senselessly. No human opponent would move like that. Aggravating!
In the forthcoming JTCS 2.01 Update, the A/I dithering unit, backtracking move bug has been fixed!
In JTCS 2.01, you will have the option to Prohibit A/I Backtracking. See the screenshot.
[image]local://upfiles/5869/97C286A697A44886BD3555AEB9770216.jpg[/image]
Note the new A/I > Prohibit A/I Backtracking menu option.
In the screenshot, the Troop Train invariably runs from the yellow highlighted hot spot hex to the yellow circled hex then back again. It will do this turn after turn after turn. Madness! By setting Prohibit A/I Backtracking, we can prevent that!
Every time an A/I backtracking move is thwarted, this is noted in the ai.log, for example:
2014-04-18 14:29:35 ef.exe: [INFO ID 1] in Move::MoveUnitsI: turn 1, side 1, isai true, ai_nobacktrack true; prev from hex 6,20, prev to hex 5,21, prev position 1, prev number 4; from hex 5,21, to hex 6,20, position 1, number 4; attempted backtrack move, aborted
2014-04-18 14:29:35 ef.exe: [INFO ID 1] in Move::MoveUnitsI: turn 1, side 1, isai true, ai_nobacktrack true; prev from hex 6,20, prev to hex 5,21, prev position 1, prev number 4; from hex 5,21, to hex 6,20, position 1, number 4; attempted backtrack move, aborted
2014-04-18 14:32:14 ef.exe: [INFO ID 1] in Move::MoveUnitsI: turn 2, side 1, isai true, ai_nobacktrack true; prev from hex 6,20, prev to hex 5,21, prev position 1, prev number 4; from hex 5,21, to hex 6,20, position 1, number 4; attempted backtrack move, aborted
2014-04-18 14:32:14 ef.exe: [INFO ID 1] in Move::MoveUnitsI: turn 2, side 1, isai true, ai_nobacktrack true; prev from hex 6,20, prev to hex 5,21, prev position 1, prev number 4; from hex 5,21, to hex 6,20, position 1, number 4; attempted backtrack move, aborted
2014-04-18 14:33:47 ef.exe: [INFO ID 1] in Forces::MoveUnits: turn 2, side 0, isai false, ai_nobacktrack true; prev from hex 68,9, prev to hex 69,9, prev position 1, prev number 1; from hex 69,9, to hex 68,9, position 1, number 1; attempted backtrack move, accomplished
2014-04-18 14:35:25 ef.exe: [INFO ID 1] in Move::MoveUnitsI: turn 3, side 1, isai true, ai_nobacktrack true; prev from hex 6,20, prev to hex 5,21, prev position 1, prev number 4; from hex 5,21, to hex 6,20, position 1, number 4; attempted backtrack move, aborted
2014-04-18 14:35:25 ef.exe: [INFO ID 1] in Move::MoveUnitsI: turn 3, side 1, isai true, ai_nobacktrack true; prev from hex 6,20, prev to hex 5,21, prev position 1, prev number 4; from hex 5,21, to hex 6,20, position 1, number 4; attempted backtrack move, aborted
...
Does this thwarting mechanism prevent you, the human player, from backtracking a move? No, as you can see in the highlighted text above.
Why might you (or the A/I) legitimately want to backtrack a move?
A unit moves forward, comes under heavy fire, then retreats to safety.
A unit moves forward, spots some enemy units from its forward position, then mission accomplished, moves back again.
The unit commander (you) changes his mind!
In all such cases, we give the human player license to backtrack a move.
Why the A/I dithers -- it's still a mystery. I am yet unable to distinguish between legitimate use of the backtracking tactic and mindless indecision. All I can do is to thwart backtracking moves in every case, for whatever the "reason".
Might this handicap the A/I? Could be. Which is one reason why Prohibit A/I Backtracking is an optional choice. Toggle it on or off. Your call.
How widespread is this dithering unit, backtracking move problem? Very widespread. In a series of automated test trials (run to ensure that this new prohibition doesn't maybe lock the A/I in an endless loop of indecision), here are the tested East Front scenarios with 10 or more attempted, and aborted, A/I backtrack moves:
Robert@Berto /cygdrive/c/Games/Matrix Games/John Tiller's Campaign Series 2.00/East Front
$ egrep -ic "backtrack move. aborted" Logs/*.scn_ai.log | awk -F: '$2>10' | tee ai_nobacktrack.dat
Logs/02odessa.scn_ai.log:48
Logs/04odessa.scn_ai.log:41
Logs/16odessa.scn_ai.log:21
Logs/Alushta.scn_ai.log:15
Logs/Babirova.scn_ai.log:25
Logs/Barvenkovo.scn_ai.log:110
Logs/Bernau.scn_ai.log:18
Logs/Blinov.scn_ai.log:12
Logs/Bootcamp10.scn_ai.log:92
Logs/Budy.scn_ai.log:43
Logs/Bukrin.scn_ai.log:23
Logs/Drazna.scn_ai.log:26
Logs/Dubrovka.scn_ai.log:24
Logs/Duderhof.scn_ai.log:18
Logs/Fabulbattyan.scn_ai.log:28
Logs/Gaffron.scn_ai.log:52
Logs/Gorodok.scn_ai.log:18
Logs/Hango.scn_ai.log:12
Logs/Hlusk.scn_ai.log:61
Logs/Izyum.scn_ai.log:16
Logs/Kamenny.scn_ai.log:43
Logs/Kirovograd.scn_ai.log:15
Logs/Klepchevo.scn_ai.log:28
Logs/Kokovkeeno.scn_ai.log:27
Logs/Krasnogorodka.scn_ai.log:12
Logs/Kremlin.scn_ai.log:266
Logs/Kustrin.scn_ai.log:27
Logs/Letornovski.scn_ai.log:32
Logs/Leuenberg.scn_ai.log:16
Logs/Lilienbach.scn_ai.log:41
Logs/Lipki.scn_ai.log:19
Logs/Lopyashna.scn_ai.log:80
Logs/Losevo.scn_ai.log:51
Logs/Lozovenka.scn_ai.log:37
Logs/Lyutezh.scn_ai.log:16
Logs/Maloyaroslavets.scn_ai.log:16
Logs/Molodovka.scn_ai.log:85
Logs/Moscow.scn_ai.log:14
Logs/Naro-Fominsk.scn_ai.log:15
Logs/Novgorod2.scn_ai.log:24
Logs/Ostroye.scn_ai.log:17
Logs/Pabianice.scn_ai.log:13
Logs/Perekop.scn_ai.log:55
Logs/Prusy.scn_ai.log:14
Logs/Radomysl.scn_ai.log:13
Logs/Rappards.scn_ai.log:14
Logs/Raseiniai.scn_ai.log:26
Logs/Sadki.scn_ai.log:11
Logs/Schmergow.scn_ai.log:30
Logs/Semenovka.scn_ai.log:22
Logs/Semiluki.scn_ai.log:13
Logs/Slonim.scn_ai.log:24
Logs/Stalingrad.scn_ai.log:14
Logs/Suomussalmi.scn_ai.log:14
Logs/Szekesfehervar.scn_ai.log:58
Logs/Tac.scn_ai.log:31
Logs/Targul.scn_ai.log:37
Logs/Teploye.scn_ai.log:19
Logs/Titovka.scn_ai.log:45
Logs/Tomarovka.scn_ai.log:15
Logs/Venskyula.scn_ai.log:58
Logs/Veseloye.scn_ai.log:20
Logs/Warka.scn_ai.log:25
Logs/Yakhroma2.scn_ai.log:49
Logs/Zsambek.scn_ai.log:18
Robert@Berto /cygdrive/c/Games/Matrix Games/John Tiller's Campaign Series 2.00/East Front
$ ls -1 Logs/*ai.log | wc -l
190
Out of 190 scenarios tested (without any crashes or freezes, BTW), you can see that in 65 of them, about 1/3rd, the A/I attempts to backtrack move at least 10 times. In many other scenarios (not listed here), the problem still occurs, but not quite so often. In just a small minority of scenarios is there no sign of A/I backtracking whatsoever.
The solution implemented is not quite perfect. It is still possible for the A/I to move a unit or stack from A to B, then back from B to A -- but not consecutively, and not in the same turn. If other units move in the interim, or if the turn rolls over, it is still possible for the A/I to backtrack move. In unusual circumstances, you might still occasionally see sporadic backtrack moves. But they are now rare to nonexistent.
Fixing the dithering unit, backtracking move bug -- a major annoyance eliminated!
Another A/I tweak: In 2.01, in the ai.ini parameters file, we have added the following highlighted moddable parameters:
# AI parameters
#
# AI_hot_max // Maximum hot value.
# AI_hot_trigger // Value which causes hex to be hot.
# AI_move_trigger_AttackHigh // Move trigger for AttackHigh order type.
# AI_move_trigger_AttackLow // Move trigger for AttackLow order type.
# AI_move_trigger_NoOrder // Move trigger for NoOrder order type.
# AI_move_trigger_DefendHigh // Move trigger for DefendHigh order type.
# AI_move_trigger_DefendLow // Move trigger for DefendLow order type.
# AI_bad_health // Bad health value.
# AI_good_health // Good health value.
# AI_unload // Unload distance.
# AI_stand_off // Stand-off distance for IF units.
# AI_smoke_prob // Probability of firing smoke.
# AI_blind_fire_prob // Probability of blind fire.
# AI_dig_prob // Probability of digging in.
# AI_ constant defaults
# AI_move_trigger_NoOrder is 0 for MW, 3 for CS
#12 6 0 2 0 4 6 70 90 2 4 10 15 25
# Allied _AI_ resets
12 6 0 2 0 4 6 70 90 2 4 10 15 25
# Axis _AI_ resets
12 6 0 2 0 4 6 70 90 2 4 10 15 25
(Note: At present, AI_blind_fire_prob is effectively unused. For now, it is just there as a placeholder.)
We invite you to play around with the ai.ini parameters. Increase this, lower that. See what might happen.
AI_smoke_prob & AI_dig_prob have also been factored into the A/I options: Allied or Axis Audacious or Cautious A/I, and Allied or Axis Shifting A/I. As you might expect, with Cautious set, the A/I will tend to fire smoke and dig in more. With Audacious set, the opposite is true: less digging in and hiding under cover of smoke.
Not for JTCS 2.01 but for future releases and for new games in the series, I have implemented special tracing and logging mechanisms to help me observe how the A/I "thinks". Step by step, I'm finding ways to make the A/I better, or at least more moddable.
In other news...
We are now in the final stages of testing the 2.01 Update, paying special attention to the DCGs. We have devoted weeks of intensive effort to reviewing the DCG code and data. A number of issues and crash bugs have been fixed. In 2.01, DCGs should be in much better shape.
When will we release the 2.01 Update? Soon, but not soon enough! In addition to the final testing, we are endeavoring to provide a fully up-to-date manual with this release. We have farmed out work on the Manual PDF to Matrix/Slitherine. When they will finish it is anybody's guess, hence we can't be quite precise about the 2.01 release date. We ask you to be patient a while longer.
Reviewing, fixing, testing, much work going on behind the scenes... [sm=00000028.gif]
Until the next time...
|
|
|
|
