Welcome to the LnLP Forums and Resource Area

We have updated our forums to the latest version. If you had an account you should be able to log in and use it as before. If not please create an account and we look forward to having you as a member.

SITREP

song

Member
Joined
Aug 4, 2015
Messages
36
Points
8
Age
42
Location
shanghai China
Well done, DAVE! Congratulations on your critical progress! Can't wait to try out the new beta! Good luck!
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
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! :banghead:

Here's a screen shot of the assault getting underway.Escheloned Attack Assault.jpg

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. :)
 
Last edited:

MarkShot

Member
Joined
Jun 3, 2015
Messages
292
Points
28
Age
79
Location
NYC+13,000mi
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!
 

Keydet

Member
Joined
Jun 7, 2015
Messages
759
Points
18
Age
72
Location
Suffolk, VA
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.
 
Joined
Oct 20, 2014
Messages
1,182
Points
63
Age
76
Location
Livonia, MI (Detroit-area suburb)
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

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
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.

Attack Abandoned lack of time.jpg
 

simovitch

Member
Joined
Nov 15, 2014
Messages
658
Points
28
Age
62
Location
California, USA
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."
 
Joined
Oct 20, 2014
Messages
1,182
Points
63
Age
76
Location
Livonia, MI (Detroit-area suburb)
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),
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
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

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
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.
 
Top