SITREP

[jimcarravallah]

Dave, it's just an esoteric homage to Cheech and Chong from the early '70's. There is only one you, thank goodness...

Great to hear about the progress!

I had to look it up.

 

[song]

Well done, DAVE! Congratulations on your critical progress! Can't wait to try out the new beta! Good luck！

 

[Dave 'Arjuna' O'Connor]

SITREP Fri 12 Nov 21

Hi all,

It's taken me all week to crack the scheduling of the new attack. I still have work to do to tidy up some minor issues with the scheduling. In the process I have fixed a silly bug inside the Plan Development code for an assault that was erroneously reporting the stored assault route as invalid. This was causing the attack to be replanned. This has been in the code from before my overhaul and probably accounts for a swag of reports from users about attacks being replanned. My bad!

Here's a screen shot of the assault getting underway.

I will see how this attack plays out and stomp any other bugs that arise. I will then make a change to the way we determine the execution time of ReceiveOrdersEvents when we are just slipping timings. Currently these enjoy a reduced orders delay but this can result in the slip order arriving before the full plan order. I want to remove the kludge I have in the code now for handling this as it sometimes fails. I am going to store the last order execution time inside the plan and then use this as a minimum time for executing any subsequent slip orders. That will ensure the slip orders do not get ahead of the full plan orders and avoid problems.

Next I want to stop assaults in line from crossing paths. At the moment when conducting complex attacks in line the subAttack force assigned to the left FUP can actually aim for the right objective and vice versa. It's unrealistic and annoying. I will have to go back and check but I think that should be it as far as changes go. I should then be able to release a beta for testing - fingers crossed.

One other thing on my list is to review the offsets used to deploy forces at the FUP. In my example above, not how far back the forward edge of the assault is from the four units up front. These in fact are staying put there because they have been deemed near enough to the sub attack reserve locations. The forward edge of the assault formation should be a little forward of them, not a kilometre behind them.

I'm sure I'll think of a few other minor things like that to add to my to do list.

 

[MarkShot]

Yes, Dave, the addition of a degree of initiative into the AI's routines will give it a much more human like behavior.

I remember from early on the HQ's sometime leading the charge. Then, of course, if they get stomped everything falls apart. Even when they didn't they were often motorized, and rather than following the infantry on the shortest path would take a circuitousness road which was not safe, and run into the enemy. Looking forward to this update!

 

[Grognerd]

Excellent news indeed! Thank you for your hard work!

 

[Keydet]

SITREP Fri 12 Nov 21
........

Next I want to stop assaults in line from crossing paths. At the moment when conducting complex attacks in line the subAttack force assigned to the left FUP can actually aim for the right objective and vice versa. It's unrealistic and annoying. ...

Oh this is wonderful. There is another version of this problem. Subordinate formations trading places to occupy FUPs. That is there are cases where subordinate formations are not assigned sub-objectives closest to each subordinate. Instead these will be given FUP's in the area where the other subordinate was. I am not talking about one subordinate being mech heavy and the other infantry heavy and these being realigned to the appropriate avenue of approach.

 

[Dave 'Arjuna' O'Connor]

Keydet/Paul,

I know about those and I believe my overhaul of the attack allocation code has fixed that behaviour. But need more testing to confirm for sure.

 

[john connor]

Great progress, Dave! The end in sight!

 

[Art Hall]

great news Dave!

 

[jimcarravallah]

One other thing on my list is to review the offsets used to deploy forces at the FUP. In my example above, not how far back the forward edge of the assault is from the four units up front.

Unless there's a separate reserve point where the second wave support is deployed, it occurs to me that the FUP is located at a distance that allows for fire support from the rear with some consideration of how much time it would take any of those reserves to get to the front line when called.

 

[Dave 'Arjuna' O'Connor]

SITREP Monday 22 Nov 21

Hi all,

At the beginning of work this morning I could only replay my recording to D1, 07:05 before it asserted. I just ran through a complete attack by CCA 4 AD. I stopped it at D1, 13:38. Alas the attack got called off at 13:02 due to lack of time. This was a player designated attack. I hadn't set a specific end time. So it would have guestimated a duration for it. I reckon we need to allow it a bit of leeway. I'll step through what happened when it abandoned it just short of its final sub attack objective. But hey, we're making good progress.

 

[john connor]

Is this a Divisional level attack you're trying to get to work, Dave?

 

[Dave 'Arjuna' O'Connor]

No Peter, it's brigade level. Combat Command Alpha has a tank Bn and a mech inf Bn plus an attached leg inf Bn.

 

[simovitch]

That "lack of time" notice has been around for a while, and it is quite a vexing annoyance, especially when no reason or warning is given and it appears there is plenty of game time left. I guess a good player will manually set the completion time.... but why? Maybe just a periodic message reminder to the player: "Sir, this task is taking longer than expected."

 

[jimcarravallah]

That "lack of time" notice has been around for a while, and it is quite a vexing annoyance, especially when no reason or warning is given and it appears there is plenty of game time left. I guess a good player will manually set the completion time.... but why? Maybe just a periodic message reminder to the player: "Sir, this task is taking longer than expected."

If I recall correctly, unless a time is set by the player (e.g. tp support two or more separate coordinated orders), the notice was intended to tell the player the plan couldn't be coordinated and initiated before the game ends. If the player doesn't set a step off time and the AI calculated time is still inside the remaining game play time, why bother to check unless there's a replan (which starts a whole new planning cycle anyway),

 

[simovitch]

And, it's not like the "battle" ends when the scenario time limit is reached. I say keep up the attack or let the player, not the system, cancel it.

 

[Dave 'Arjuna' O'Connor]

I've investigated further and conclude that this is a scheduling issue. Every minute the attack boss will AssessToReschedule(). This is complex function that goes through various steps. It has to pass each step to actually reschedule. In this case because it's a complex attack, it calls IsObjectiveReached() on each of the subAttacks. It passes in a flag to ensure the final reorg task of each subAttack has done its job. I stepped through the code and confirmed that two of the attacks return true but the third one returns false. This is the attack furthest north. Trouble is the code then determines the reachedRatio ( = reachedCount / subAttackCount ) and if this is greater than 50% then it deems the overall attack reached and reorged and reschedules.

IIRC we added the reachedRatio test to end attacks that were continuously extending but not achieving all their subAttack objectives. Eg where we may have one subAttack that was too weak to clear their objective. I can certainly exempt this ratio test where the force is human controlled, but what of the AI side.

Perhaps we get rid of the ratio test but add a separate IsAttackStalled(). To make this work we may need to add some historical data fields to the task, so we can see how many times it has extended the attack already. Need to ponder a bit more.

 

[Dave 'Arjuna' O'Connor]

Went for a walk around the nearby wetland ponds to ponder. Watching the ducks gliding through the water made me recall that we do already have an AssessForStalledAttack() that is called as part of the regular reassessment process. This doesn't occur every minute but every few minutes during an attack. It maybe every minute during the assault. So this should suffice. I will ditch the ratio test inside AssessToReschedule(). This should solve the problem. Stay tuned.

 

[john connor]

Clever ducks, those...

 

[song]

Clever ducks, beautiful pond