SITREP

Discussion in 'Command Ops Series' started by Dave 'Arjuna' O'Connor, Jan 15, 2015.

  1. Dave 'Arjuna' O'Connor

    Dave 'Arjuna' O'Connor Panther Games Designer

    Joined:
    Jul 31, 2014
    Messages:
    2,881
    Likes Received:
    251
    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.
     
  2. Dave 'Arjuna' O'Connor

    Dave 'Arjuna' O'Connor Panther Games Designer

    Joined:
    Jul 31, 2014
    Messages:
    2,881
    Likes Received:
    251
    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.
     
    ghibli, Art Hall and BigDuke66 like this.
  3. BigDuke66

    BigDuke66 Member

    Joined:
    Dec 14, 2014
    Messages:
    65
    Likes Received:
    5
    Great news!!!
     
  4. col.sanders

    col.sanders Member

    Joined:
    Nov 25, 2016
    Messages:
    49
    Likes Received:
    10
    That's great news ,sounds like this might be rolling along soon.Really been looking forward for this.
     
  5. Dave 'Arjuna' O'Connor

    Dave 'Arjuna' O'Connor Panther Games Designer

    Joined:
    Jul 31, 2014
    Messages:
    2,881
    Likes Received:
    251
    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.
     
    Panman, panzerpit and Art Hall like this.
  6. jimcarravallah

    Joined:
    Oct 20, 2014
    Messages:
    609
    Likes Received:
    44
    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.
     
  7. john connor

    john connor Member

    Joined:
    Oct 22, 2014
    Messages:
    1,811
    Likes Received:
    83
    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
     
  8. Dave 'Arjuna' O'Connor

    Dave 'Arjuna' O'Connor Panther Games Designer

    Joined:
    Jul 31, 2014
    Messages:
    2,881
    Likes Received:
    251
    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.
     
  9. ironsight

    ironsight Member

    Joined:
    Oct 18, 2015
    Messages:
    19
    Likes Received:
    3
    The sun never sets on Panther Games! :)
     
    pekische likes this.
  10. Kurt

    Kurt Member

    Joined:
    Jan 4, 2015
    Messages:
    866
    Likes Received:
    35
    You two guys are hard core .
     
  11. Keydet

    Keydet Member

    Joined:
    Jun 7, 2015
    Messages:
    598
    Likes Received:
    11
    All very exciting to me. ;)
     
  12. Txema

    Txema Member

    Joined:
    Dec 11, 2014
    Messages:
    33
    Likes Received:
    1
    :):):)
     
    #632 Txema, Sep 28, 2018
    Last edited: Sep 28, 2018
  13. Txema

    Txema Member

    Joined:
    Dec 11, 2014
    Messages:
    33
    Likes Received:
    1
    Are we there yet? Are we there yet? ;)
     
  14. Dave 'Arjuna' O'Connor

    Dave 'Arjuna' O'Connor Panther Games Designer

    Joined:
    Jul 31, 2014
    Messages:
    2,881
    Likes Received:
    251
    Sorry, I'm down with a cold. Too much work, that's what I blame it on.
     
  15. Dave 'Arjuna' O'Connor

    Dave 'Arjuna' O'Connor Panther Games Designer

    Joined:
    Jul 31, 2014
    Messages:
    2,881
    Likes Received:
    251
    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.
     
    panzerpit likes this.
  16. JArraya

    JArraya Member

    Joined:
    Apr 16, 2015
    Messages:
    54
    Likes Received:
    5
    This sounds like the bug I mentioned before, where a Batallion or Regiment sized unit would get an order but never move. Great job!
     
  17. Txema

    Txema Member

    Joined:
    Dec 11, 2014
    Messages:
    33
    Likes Received:
    1
    It sounds great, Arjuna!

    Really looking forward to more news on the fixes!

    Thank you very much for all your work!

    Txema
     
  18. Miquel Ramirez

    Miquel Ramirez Panther Games Designer

    Joined:
    Aug 14, 2014
    Messages:
    9
    Likes Received:
    2
    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.
     
  19. jimcarravallah

    Joined:
    Oct 20, 2014
    Messages:
    609
    Likes Received:
    44
    Damn! Software documentation :).
     
  20. Dave 'Arjuna' O'Connor

    Dave 'Arjuna' O'Connor Panther Games Designer

    Joined:
    Jul 31, 2014
    Messages:
    2,881
    Likes Received:
    251
    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.
     
    Bie, ghibli and panzerpit like this.

Share This Page