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
SITREP 1030 Wednesday 31 Oct 2018

I managed to get the enemy intel force displays dynamically updating. These have not been doing so. The actual enemy force and the intel force we track within the side's intel data were updating correctly but these updates were not being displayed in the intel force data dialogs you see on the screen. So while an enemy nit may have been pounded and reduced by friendly fire it would appear as though they were immune to it.

Having got that out of the way I have resumed testing the issue of attacks slipping. The fixes to the reassessment duration times for attacks made an impact on this but yesterday I discovered another factor causing this issue. In this instance I had the 1st 318th Inf Bn attacking the Steinbruck crossing in the tutorial scenario. It had C Coy 51st Arm Inf Coy attached and this company was the assault subject. It received its orders fine and created four missions within its op plan - one each for the advance to the FUP, the FUP Reorg, the assault and the final Reorg. It arrived early. What should have happened was it should have determined that it was ready to start the FUPReorg, but it didn't. Hence it went on hold and the scheduling code didn't know how to kick off the next mission because it had no direct linkage. I need to modify thew scheduling code to ensure these linkages are set and work properly. That's my next task.
 

john connor

Member
Joined
Oct 22, 2014
Messages
2,488
Points
63
Age
60
Location
Brussels
Wow. What a monstrous amount of remedial work before you even get to making changes, Dave. Hang in there. Thanks.
 

dwbennett

Member
Joined
Oct 15, 2018
Messages
20
Points
3
Location
117 Broken Circle DR, Evanston, WY 82930
Yeah, Dave, I've made sure I only use "Current" intel reports but still don't see much good with the arty. I've rained steel down on units for hours with very little apparent effect. Even the suppsed Tiger IIB's I've blasted for several hours should have a least been suppressed for a little while.

Take care,
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
It doesn't matter whether the intel status is current or not. There are two issues here, one is the report icon not moving and not aging when it should and the other is the enemy intel data view not updating, regardless of status. Together they paint an errant picture. There may well be an issue with arty fire, but I'm not going to address that till I rule out the intel as the probable cause. So we take it one step at a time.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
I'm making lots of progress. I'm just waiting for a search of the code right now. I've been overhauling the schedule engine and in particular the code relating to attacks where a force bunkers down and recovers. The changes to basing HQs in attacks made the old code for recovering from bunker down non-effective in some cases. This resulted in forces staying put until their boss decided to replan. That's not the way it is supposed to work. It's got to do with the way we handle the data for plans and tasks. It's quite complex. I've had to restructure the code to handle not just a sequence of tasks but a sequence of plans. Anyway I've done all that and am now testing and fine tuning it.

The assaultSubject - usually a line company, assigned to lead the assault - now bunkers down correctly and advises the boss (usually a Bn HQ) who also bunkers down but now sets the formation type to in-situ to prevent the assault force from moving back to the boss's location. The Bn HQ now advises his boss (usually a Brigade HQ) if its part of a bigger complex attack. Previously the Bde HQ was resetting the Bn HQ's task to an independent defend task. But this was causing new orders to be sent that null and voided the bunker down. I now leave the attack task in the Bde HQ's plan as is and don't send orders. This allows the Bn and it's assaultSubject an opportunity to recover and get back into the fray. The Bde HQ may commit reserves to reinforce one of the other subAttacks to offset the bunkering down group.

So as I said, it's coming along nicely now. I still have a few other more minor issues on my task list to do. This includes modifying the AssessToExtendAssault() to avoid cases where the assault runs out of time when it is almost at the objective. I want to tweak the 'making progress' code to give the force a better chance of continuing. The whole thrust here is to improve the attacking performance of the AI and prevent cases where the AI seemingly stalls in the offensive.

I also want to review the morale check code to better factor in recent cas and cas since start of scenario factors. I want to increase the probability of units failing their morale check where they have just taken significant recent casualties. This should reduce the number of cases where a force seemingly ignores the great weight of pain being inflicted upon it.

Also, I want to review the duration we use for recent intel reports and the effects these have on the firepower influence maps. My aim here is to prevent the AI from removing such reports too quickly and thus opting to Move rather than Attack.

With a bit of luck I hope to see the back of these changes this week and then I'll get a build out to our beta testers.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
Just to keep you posted. I have finished modifying the attack and scheduling code and now the results look much better. I haven't tested this extensively yet. That will be done by our beta testers. Tomorrow I move onto reviewing the morale code with the aim of reducing the probability of units holding till they are wiped out. Then I'll review the intel code with the aim of keeping recent intel around for longer.
 
Joined
Oct 20, 2014
Messages
1,181
Points
63
Age
76
Location
Livonia, MI (Detroit-area suburb)
Just to keep you posted. I have finished modifying the attack and scheduling code and now the results look much better. I haven't tested this extensively yet. That will be done by our beta testers. Tomorrow I move onto reviewing the morale code with the aim of reducing the probability of units holding till they are wiped out. Then I'll review the intel code with the aim of keeping recent intel around for longer.
FWIW, the concept of holding ground defending in-situ while pausing / resting / replanning after a successful attack pulse is doctrinally sound.
 

pekische

Member
Joined
Oct 23, 2014
Messages
107
Points
18
Location
Czech rep.
Dave, I have short question, if unit´s log could be extended within this upgrade. Extended log means that "log" tab brings more information about unit´s progress.
 
Last edited:

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Tuedsay 11 Dec 2018

I've finished my overhaul of the scheduling code and I'm in a test phase at the moment. So I've got my laptop on autotest and I'm quashing bugs on my dev machine as they are found. All of these so far are minor and relate to my recent changes. Once I have these ironed out I want to get a recording where a force recovers after bunkering down and go through that in detail to make sure it all works properly. I haven't done any analysis in terms of the effects these latest changes have on casualty levels. I want to look into that too. All in all I'm happy with progress. I'm going to resist any more tweaks except for those required to fix any bugs. Stay tuned.
 
Last edited:
Joined
Feb 24, 2016
Messages
11
Points
3
Age
59
Location
Canada
So glad to see this title is being worked on. I kept checking the DLC’s on the steam store site hoping for inclusion in the steam winter sale and I was worried that it had fallen by the wayside.

I also think that it’s great that you have provided such detailed updates here.

Regards,

Dave.
 

Dave 'Arjuna' O'Connor

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

Well I was on a real high yesterday. The autotesting all went well. I was reasonably happy withe casualty levels after all my change (though that needs further scrutiny). But I thought it worthy at last to put a new beta build for our in beta test group. I converted all the data. worked up the installer. All good. Then I ran the tutorial and it seemed to run fine. But something nagged me and I decided to watch the battle unfold a little longer and then my high hopes were dashed when one of the attacking assault groups was moving to its FUP and got into a formation lockup. I felt gutted.

I mulled over it last night and woke this morning with the conclusion that I need to redo the formation movement model for road column. The existing model works by having all units within a formation use an offset to the formation hub. This works well for all other formation types. But with road column you can have intervening subGroups between the unit and the hub - eg the advance guard can have the main guard between it and the formation hub - ie its boss. What is needed is to enhance the current structure and change the processing just for road columns. We already store the unitAhead in each unit. I'm going to add a unitBehind member to the ScenRealForce class. This will be set when we determine the order of march for the formation. Inside CanMove() I already have a function that tests to see if we should wait for the unit ahead. I'll add another to see if we should wait for the unit behind. If you pass these hurdles it will go into the existing CalcFomationNextmoveLoc(). Inside there, I'll have units in road column ignore all the hub offset logic. They will still be subject to other constraints like the hub routing off etc. This way, we should avoid the lockups caused primarily when we have a lot of small units operating close together. It's a fidelity issue with the 100m map grid we use.

This should fix this problem once and for all. The bad news is it's going to delay things a tad further. I'm sorry.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Thursday 20 December

Hi all. Good news. I have just uploaded a new build for our in-house beta testers to test. It's a nice Xmas present for them and hopefully it will translate into a nice outcome for you all in the New Year, probably in February, given the holiday season. It's a massive set of changes. It won't all fit in one post.

Changes (Part 1). Needless to say there are lots and lots. Here is the change log from builds since 5.1.33:

- Updated Dev installer script. I disabled the condition test for the registry keys. It was interpreting the status result for the Control dialog as null. That's the trouble for using 0 as Open. I'll need to think of something else. But have commented it out for now.
- Refactored ScenFireEvent constructor
- Wrapped on Linux/DXVK due to RenderTarget failure into an exception
- Issue #21: Added support to EstabEditor, EstabManager and core EstabService class for AttackReassessmentDurations, incremented Estab version to 146
- Reassessment Changes, including to the way the reassessment duration is calced. Rather than a fixed value we now use a sliding scale based on efficiency modifier
- Fixed memory leaks in RouteAversionMap and FPRouteInput by migrating from raw pointers to STL RAII
- Changes to GameRecorder code - changed checksum variable size from int to double to prevent data overflow when checking large numbers of units. Also replaced extremely large value being used when an ID Ptr was null. This was resulting in overflows after the second case.
- Added safety checks in all Destroy() that include PodIDPtrs to ScenTaskEvents.
- First hack at tackling the circularity issue with events, tasks and forces. Didn't work. Hence why I'm branching now. Need to make structural changes to the ScenTask, ScenRealForce and ScenTaskEvent classes.
- Out of Sync (OOS) Changes to 27 Jul 2018, including:
- Increased checksum size from INT to DOUBLE
- Restructured ScenTask, ScenRealForce and ScenTaskEvent classes to remove circularity. Specifically, I removed mCurrentEvent from ScenRealForce. The force now accesses this via its current unit task member. Responsibility for destroying ScenTaskEvents now resides in ScenTask and GameEvent loop. ScenTask::SetEvent() will now destroy the old event after setting the new event. If the old event is the current event in the event loop, it will not destroy it, but simply set its mTask member to NULL. The event loop will destroy the event at the conclusion of the loop.
- NOTE ScenTypes has changed: kCurrentScenarioDatabaseFormat is now at version 190 and all scenarios will need conversion. I have changed the Archive members to automatically convert.
- Fixed bug inside ScenRoute that was not capping the mNextMoveRouteIndex to the size of the route.
- OOS Changes as of 3 Aug 2018
- Replaced use of doubles with uint64_t in chechsum code
- Replaced all direct calls to ObjectID() inside GetForceChecksum(). These now use GetPointerChecksum().
- Similarly replaced direct calls to MapLoc members with GetMapLocChecksum().
- Ensured a force has a Depot and a Dump before calling functions on them.
- Added calls to GameRecorder::RecordOrVerifyState() throughout scheduling code in an attempt to narrow down where the game goes out of sync.
- Fixed bug inside ScenRealForce::DetermineFuelRequirement() that was failing to add nonAFVs fuel requirements for static events - such as Defend.
- Refactored ScenPlanScheduling::ScheduleNextEvent(), hiving off over 15000 lines of code into subFunctions.
- Fixed various logic flow errors. These included ensuring ScenTask::IsHHourSet() is called and set at the beginning of functions such as ScenMissionPlan::GetAssaultStart(). This avoids the potential to return a false value when the start time is cribbed.
- Added numerous asserts to advise when logic flows incorrectly.
- Issue #17: Out of Sync, reverted std::unordered_set back to std::set, cleanup of unused code
- Issue #17: Out of sync, disabled sending action-based reports when replaying
- Issue #17: Out of sync, added extra RecordOrVerify calls to enfore synchronisation of every single frame processing, removed commented out or unnecessary calls
- Merge remote-tracking branch 'remotes/origin/master' into RefactorScheduleNextEvent
- Refactor ScheduleNextEvent()
- Changes to address the reassessment and intel issues. Specifically:
* Ensure that the ForceData for GameAnimForce is updated every minute.
* Ensure that that the GameAnim force icon's location is updated every frame.
* Added Observers to all force data dialogs to ensure that those displaying enemy intel force data are updated every minute
* Ensure that if an enemy intel report icon is no longer visible that its corresponding data dialog is cleared. Also ensure that the dialog is re-populated if the icon later becomes visible again.
* Fixed a bug in MapTerrainTable::CanSeeProbability() that was erroneously applying a modifier for intervening vegetation in cases where the ground sloped away and then rose again.
* Removed redundant call to update intel force levels from ScenFireEvent.
* Fixed bug inside ScenIntelEnemyForce::UpdateIntelForceLevels() that failed under certain circumstances to update the location for the enemy force intel icon when the real force had moved
* Changed the behaviour of enemy intel force icons where the force was deployed. Previously all deployed, dug in, entrenched and fortified unit icons had their duration till stale set to whatever the duration was to the end of the scenario. This meant their icons would never expire till the end of the scenario. Now deployed units go stale after four hours.
* Ensure that enemy intel icons temporarily made inactive are activated again when their status changes back.
* Ensure that inside ScenPlanScheduling::SpotEnemyForces() all enemy units are checked if no one else has spotted them so far this minute. This adds extra processing but ensures all enemy forces are checked.
 
Top