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

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
Thanks Dave. Once this issue is sorted and the new build is ready, does it have the arty fixes we've spoken about, or are they still to be worked out? Plus, what's the plans for resolving the issues with the basing code to stop non-line units ending up in strange, exposed positions, especially on Move orders (HQs and bases out front, for example)? Is that done already, or is that still to happen? Thanks.
How are you going Peter?

I made a swag of tweaks to the arty months ago now. They have still to go out to beta testers, but that's waiting on this out of sync bug to be nailed.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP 1500 Fri 14 Sep 2018

Hi all,

I'm down with a cold. While physically I'm all stuffed up, I can report that we made a breakthrough in the Out of Sync issue this week. I can't believe it's been so long getting here. It turns out that a previous programmer had made some low level changes that I was unaware of. One of these changed the data type of the subordinates list of a force group from a sorted set to an unsorted set. The nature of an unsorted set is that you can't guarantee the order in the set of values. This meant that when replayed the order sometimes got changed and hence the game went out of sync. We changed back to an ordered set and ran a series of tests with small and large scenarios. For AI v AI games, which we can run on our debug version of the game, the game no longer goes out of sync. So that's a great step forward.

However, human v AI still goes out of sync but not straight away like it was previously. Pavlo emailed me this morning saying he thinks he's found the cause for that. I'll be discussing this with him soon. Hopefully we'll be able to put this to bed real soon.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP 2333 Tuesday 18 Sep 2018.

We thought we had it licked on Sunday when we found and fixed an error related to reports being played twice in the replay of a recording. That was cause two of the out of sync issue. Alas, further testing yesterday revealed that we must still have another. At least we got to Day 4 before it fired. So once again Pavlo is working his magic and writing some new test logger code for me to run and hopefully track down this latest cause. Trouble is the longer the game runs before it fires the larger the log files. I think the last ones were like 18 Gb of log data and that was just to Day 2. It's enough to try the patience of a saint. But the good news is that we have made significant progress. Fingers crossed.
 
Joined
Oct 20, 2014
Messages
1,182
Points
63
Age
76
Location
Livonia, MI (Detroit-area suburb)
SITREP 2333 Tuesday 18 Sep 2018.

We thought we had it licked on Sunday when we found and fixed an error related to reports being played twice in the replay of a recording. That was cause two of the out of sync issue. Alas, further testing yesterday revealed that we must still have another. At least we got to Day 4 before it fired. So once again Pavlo is working his magic and writing some new test logger code for me to run and hopefully track down this latest cause. Trouble is the longer the game runs before it fires the larger the log files. I think the last ones were like 18 Gb of log data and that was just to Day 2. It's enough to try the patience of a saint. But the good news is that we have made significant progress. Fingers crossed.
Ugh. I don't envy yours and Pavlo's task(s) but really appreciate the effort to make things work.

There's nothing more mind numbing than reviewing thousands of lines of code to find the one fly in the ointment.
 

john connor

Member
Joined
Oct 22, 2014
Messages
2,488
Points
63
Age
60
Location
Brussels
Hey Dave. I'm good, thanks. Would love to be playing CO2, testing the long-lost Bradley at Bay pack, testing the arty tweaks, testing (if that's happening) the basing code changes, so glad you are getting somewhere with the bug. Thanks. It has been a loooong process, it seems. Many thanks to Pavlo! Glad you're not both giving up on it....

Peter
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
Far from it. Pavlo and I have been burning the candles on this one. Pavlo is in Berlin and I'm on the other side of the world in Canberra. This morning I wake 0630; check out Pavlo's latest email to me in which he claims to have fixed it. But after an email exchange over the ensuing hours he admits that this is the third thing causing the game to go out of syn that we've fixed so far and he reckons he won't be surprised if there's a fourth.

I'm testing his code change now. This latest cause was in the Game Event Loop and I don't want to think about how many times I've been through that code and never twigged. We only discovered the anomaly because of Pavlo's test logs which went through frame by frame, event by event. It dumps over 18 Gb of data. But he found it. That's good programming skills I tell you.

Anyway fingers crossed this is the last of it.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
PS. We think we've nailed the out of sync bug, but it needs extensive testing. Prior to succumbing to this cold on Friday, I'd investigated reports about forces continually slipping attacks. I did find some code changes in there made by an earlier programmer that had in effect turned off the modifiers for bringing attack reassessments forward. Instead they were using the standard reassess times. Now for a Battalion that can be three to four hours, which is way too long. I've made changes but need to test those too.
 

JArraya

Member
Joined
Apr 16, 2015
Messages
113
Points
18
Age
49
Location
UK
PS. We think we've nailed the out of sync bug, but it needs extensive testing. Prior to succumbing to this cold on Friday, I'd investigated reports about forces continually slipping attacks. I did find some code changes in there made by an earlier programmer that had in effect turned off the modifiers for bringing attack reassessments forward. Instead they were using the standard reassess times. Now for a Battalion that can be three to four hours, which is way too long. I've made changes but need to test those too.

This sounds like the bug I mentioned before, where a Batallion or Regiment sized unit would get an order but never move. Great job!
 

Txema

Member
Joined
Dec 11, 2014
Messages
34
Points
8
Location
Basque Country
It sounds great, Arjuna!

Really looking forward to more news on the fixes!

Thank you very much for all your work!

Txema
 

Miquel Ramirez

Panther Games Designer
Joined
Aug 14, 2014
Messages
9
Points
3
Age
45
Location
Melbourne, Australia
Website
www.linkedin.com
I did find some code changes in there made by an earlier programmer that had in effect turned off the modifiers for bringing attack reassessments forward. Instead they were using the standard reassess times. Now for a Battalion that can be three to four hours, which is way too long. I've made changes but need to test those too.

Happy to refresh your memory

Hi Dave (and everyone else interested on how command & control works in the engine),

on my quest to expose relevant command & control parameters in the engine, I've come across the routine

TaskDoctrine::DetermineReassessmentPeriod()

which regulates the duration of units replanning - that is, any reassessment of on-going plans. This is a quite critical bit of the engine, as it sets to how fast are forces able to adapt their plans to changing conditions (what Robert S. Leonhard calls "inertia").

I see this routine to use the orders delay tables in ScenCommonAI as a 'base' to determine the duration of these re-planning events. It is a quite complicated routine, and I'd like you to confirm my reading of the code there, as well as, illustrating its meaning with some remarks regarding the design rationale. Let's work out the process

1) Determine Standard Reassessment Duration

This is done by referring to the table in ScenCommonAI that establishes the average (?) duration of a reassessment depending on force size. These durations are given as

Army Group = 1440 minutes
Army = 1440 minutes
Corps = 1440 minutes
Division = 720 minutes
Brigade = 360 minutes
Battalion = 240 minutes
Coy = 120 minutes
Platoon = 60 minutes
Section = 40 minutes

2) Establish Commander Efficiency

As per the values obtained from the force's commander attributes and that can be set from within ScenMaker. A commander with an efficiency rating of 0, increases reassessment duration by 20%, with a rating of 100% decreases the time by a 20%. A commander with a rating of 50% doesn't affect reassessment duration.

3) Establish Staff Efficiency

Uses the Staff Quality, Capacity and Load attributes (ScenMaker settable attributes) to determine to what degree the staff is overloaded. Efficiency with no overload corresponds to Staff Quality, and that value degrades proportionally to overload. Varies times in the same way as the Commander Efficiency.

4) Comms modifier

This comms mod is obtained by determining to what degree the force is motorized. This is obtained by dividing the number of motorized units (as per the Estab) over the total number of units in the force.

When the ratio is above 1/3rd, then the modifier is set to

motorization ratio - 0.33 / 0.67 -> mapped into the [0.8,1] interval

which means that a force with just 1/3rd of motorized units gets no benefit, and a fully motorized force gets a 20% reduction in reassessment times.

5) The reassessment time is bounded to lie anywhere within 0 and 120 minutes by default.

6) Determine whether the force is part of an attack, that is, it's executing an Assault or a FUP Reorganization task, if so

a) the force reassessment period is set to a 5% of the standard reassessment time, modified by the efficiency and comms modifiers. For instance, a pure infantry Bn size force, with 50% efficiency ratings, will be scheduling the plan reassessment 12 minutes into the future.

b) this reassessment period is restricted to a minimum of 5 minutes, and a maximum of 120 minutes.

c) if "we are to reschedule forward another reassessment" (I don't understand what does this exactly mean), the reassess period is then the minimum between 3 minutes and a third of the previous value. For the Bn force above, it would be 4 minutes.

7) if the force isn't part of an attack,

a) if "we are to reschedule forward another reassessment",
i) the reassessment delay is set to a 10% of the standard time, for the Bn force above, 24 minutes

ii ) this value is then restricted to a minimum of 10 minutes and a maximum of 60 minutes

b) otherwise, if the force is performing a sub-task of an Attack or Probe task

i) the reassessment delay is set to a 25% of the standard time, for the Bn force above, 1 hour

ii) this time is then restricted to a minimum between 30 minutes and 180 minutes

c) otherwise, if the force is performing something unrelated to an Attack or a Probe

i) the modified standard reassessment time (4 hours for the Bn force above), is then randomly decreased or increased up to a 25% (i.e. the reassessment delay could be between 5 and 3 hours)

ii) if the force is resting, an hour is added to the reassessment period

My observations:

* I can get this in the Estab, it's quite straightforward, by introducing a new kind of object that implements the above, triggering the corresponding computations on the basis of

force task being a member of a given set of tasks
force task being part of a member of a given set of tasks

* By introducing Bil's comms ratings I think we can do away with the Motorised-based comms rating above

* Seeing this code, now I understand the - relative - tardiness of the AI to react in certain contexts, like Secure Crossing or Delay, where I reckon the tempo on the command loop should be higher.


Exposing this (and the other tables on ScenCommonAI) would allow people to model a great variety of armies with wildly different doctrines over broad periods of time. For instance, it would allow us to account for that behaviour you commented about the Japanese Army tactical decision making being very fast at the lowest levels of the command chain (with Sections or Platoons taking initiatives such as charging an enemy), but not at the higher levels.

Also this should help to remember

https://docs.google.com/document/d/...SWWAOv56AZPfs2gMI/edit#heading=h.kc321dwymgx7

especially these items:

  • Forces now have a comms rating attribute, which represents the level of wireless connectivity of the units’ elements. The higher this rating, the less time units will need to process and send orders, and speeds up as well slightly reassessments.
  • Command & Control durations are now exposed in the EstabEditor as Service attributes. This allows to model forces with very different command loop lengths. The values in the tables are taken to be the “standard” times, that is, for units with average communications, with average commanders and staffs.
  • Estab Editor: New Feature: Force comms rating and ready to bombard duration available for edition
  • Estab Editor: New Feature: Delays and periods of Command & Control are now exposed on a per-Service basis
Hope this helps.
 
Joined
Oct 20, 2014
Messages
1,182
Points
63
Age
76
Location
Livonia, MI (Detroit-area suburb)
Happy to refresh your memory

Hi Dave (and everyone else interested on how command & control works in the engine),

on my quest to expose relevant command & control parameters in the engine, I've come across the routine

TaskDoctrine::DetermineReassessmentPeriod()

which regulates the duration of units replanning - that is, any reassessment of on-going plans. This is a quite critical bit of the engine, as it sets to how fast are forces able to adapt their plans to changing conditions (what Robert S. Leonhard calls "inertia").

I see this routine to use the orders delay tables in ScenCommonAI as a 'base' to determine the duration of these re-planning events. It is a quite complicated routine, and I'd like you to confirm my reading of the code there, as well as, illustrating its meaning with some remarks regarding the design rationale. Let's work out the process

1) Determine Standard Reassessment Duration

This is done by referring to the table in ScenCommonAI that establishes the average (?) duration of a reassessment depending on force size. These durations are given as

Army Group = 1440 minutes
Army = 1440 minutes
Corps = 1440 minutes
Division = 720 minutes
Brigade = 360 minutes
Battalion = 240 minutes
Coy = 120 minutes
Platoon = 60 minutes
Section = 40 minutes

2) Establish Commander Efficiency

As per the values obtained from the force's commander attributes and that can be set from within ScenMaker. A commander with an efficiency rating of 0, increases reassessment duration by 20%, with a rating of 100% decreases the time by a 20%. A commander with a rating of 50% doesn't affect reassessment duration.

3) Establish Staff Efficiency

Uses the Staff Quality, Capacity and Load attributes (ScenMaker settable attributes) to determine to what degree the staff is overloaded. Efficiency with no overload corresponds to Staff Quality, and that value degrades proportionally to overload. Varies times in the same way as the Commander Efficiency.

4) Comms modifier

This comms mod is obtained by determining to what degree the force is motorized. This is obtained by dividing the number of motorized units (as per the Estab) over the total number of units in the force.

When the ratio is above 1/3rd, then the modifier is set to

motorization ratio - 0.33 / 0.67 -> mapped into the [0.8,1] interval

which means that a force with just 1/3rd of motorized units gets no benefit, and a fully motorized force gets a 20% reduction in reassessment times.

5) The reassessment time is bounded to lie anywhere within 0 and 120 minutes by default.

6) Determine whether the force is part of an attack, that is, it's executing an Assault or a FUP Reorganization task, if so

a) the force reassessment period is set to a 5% of the standard reassessment time, modified by the efficiency and comms modifiers. For instance, a pure infantry Bn size force, with 50% efficiency ratings, will be scheduling the plan reassessment 12 minutes into the future.

b) this reassessment period is restricted to a minimum of 5 minutes, and a maximum of 120 minutes.

c) if "we are to reschedule forward another reassessment" (I don't understand what does this exactly mean), the reassess period is then the minimum between 3 minutes and a third of the previous value. For the Bn force above, it would be 4 minutes.

7) if the force isn't part of an attack,

a) if "we are to reschedule forward another reassessment",
i) the reassessment delay is set to a 10% of the standard time, for the Bn force above, 24 minutes

ii ) this value is then restricted to a minimum of 10 minutes and a maximum of 60 minutes

b) otherwise, if the force is performing a sub-task of an Attack or Probe task

i) the reassessment delay is set to a 25% of the standard time, for the Bn force above, 1 hour

ii) this time is then restricted to a minimum between 30 minutes and 180 minutes

c) otherwise, if the force is performing something unrelated to an Attack or a Probe

i) the modified standard reassessment time (4 hours for the Bn force above), is then randomly decreased or increased up to a 25% (i.e. the reassessment delay could be between 5 and 3 hours)

ii) if the force is resting, an hour is added to the reassessment period

My observations:

* I can get this in the Estab, it's quite straightforward, by introducing a new kind of object that implements the above, triggering the corresponding computations on the basis of

force task being a member of a given set of tasks
force task being part of a member of a given set of tasks

* By introducing Bil's comms ratings I think we can do away with the Motorised-based comms rating above

* Seeing this code, now I understand the - relative - tardiness of the AI to react in certain contexts, like Secure Crossing or Delay, where I reckon the tempo on the command loop should be higher.


Exposing this (and the other tables on ScenCommonAI) would allow people to model a great variety of armies with wildly different doctrines over broad periods of time. For instance, it would allow us to account for that behaviour you commented about the Japanese Army tactical decision making being very fast at the lowest levels of the command chain (with Sections or Platoons taking initiatives such as charging an enemy), but not at the higher levels.

Also this should help to remember

https://docs.google.com/document/d/...SWWAOv56AZPfs2gMI/edit#heading=h.kc321dwymgx7

especially these items:

  • Forces now have a comms rating attribute, which represents the level of wireless connectivity of the units’ elements. The higher this rating, the less time units will need to process and send orders, and speeds up as well slightly reassessments.
  • Command & Control durations are now exposed in the EstabEditor as Service attributes. This allows to model forces with very different command loop lengths. The values in the tables are taken to be the “standard” times, that is, for units with average communications, with average commanders and staffs.
  • Estab Editor: New Feature: Force comms rating and ready to bombard duration available for edition
  • Estab Editor: New Feature: Delays and periods of Command & Control are now exposed on a per-Service basis
Hope this helps.
Damn! Software documentation :).
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP 1600 Friday 26 Oct 2018

Hi all. It's the end of another grueling week in the programming trenches here.I fixed the issue with attacking forces slipping attacks. As I reported above, it was in fact caused by a mod to the reassessment code that hadn't been tested properly. I reworked the code and began testing last week only to find nigh impossible because the enemy intel reports were not functioning properly.

To cut a very long story short I have overhauled the enemy force intel system. In the process I have fixed some bugs that were there all along and others that were introduced more recently. The most profound are these were that the location of the enemy was not being updated correctly. Enemy icons would hand around out in the open when the real force had actually gone into the woods. The code that would force a location update was not firing when a friendly unit got close enough to see that there was no one there. So it would look like the enemy was in fact still there, when it wasn't. You could be forgiven for pounding these interminably with arty. That was also compounded by another issue, namely that the force data used by the user interface version of the force was not being updated from the AIs version. Thus they always appeared to be at whatever strength you first encountered them. I think this explains many of your reports about enemy not succumbing to fire and bombardments. Either they were but the display was wrong or they weren't where the display said they were. My apologies for that.

At least now I can get back to testing the reassessment code which was my intention before I jumped into this particular swamp.
 
Top