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

JArraya

Member
Joined
Apr 16, 2015
Messages
113
Points
18
Age
49
Location
UK
Love a beer as much as the next guy, but please can we turn this back into the Sitrep thread?! I got very excited when I saw all these messages and I thought we had a patch!
 

Dave 'Arjuna' O'Connor

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

The last batch of autotesting saw sixteen games run right through but another eight asserted. These were all due to issues in my new partial planning code. In most cases the problem was old assumptions no longer applying, like in the force allocation, reassessment and plan development code. I have fixed seven of these so far. The last one I should nail tomorrow. I know what the problem is and what needs to be done. I just need to work out the best method. I'll then kick off the autotester and see what happens. Hopefully we won't have to go through another round of this. Fingers crossed.
 

MarkShot

Member
Joined
Jun 3, 2015
Messages
292
Points
28
Age
79
Location
NYC+13,000mi
SITREP Tue 14 Jul 2020

The last batch of autotesting saw sixteen games run right through but another eight asserted. These were all due to issues in my new partial planning code. In most cases the problem was old assumptions no longer applying, like in the force allocation, reassessment and plan development code. I have fixed seven of these so far. The last one I should nail tomorrow. I know what the problem is and what needs to be done. I just need to work out the best method. I'll then kick off the autotester and see what happens. Hopefully we won't have to go through another round of this. Fingers crossed.

Dave, just dropped by to wish you and all the folks the best. Mate, keep your head down, .... shss .... snipers.

If not for COVID-19, the USN and PLA are doing uncoordinated naval exercises within spitting distance from here. The Bashi Channel may sound big 100 square miles, but to a missile doing Mach3 it is quite congested little piece of ocean.

Be well, mate!
 

Ripppe

Member
Joined
Mar 12, 2015
Messages
50
Points
8
Age
34
Location
Finland
Making my way back to the CO slowly. Nice to hear that things are progressing!

Keep up the good work you're doing Dave (& co)!
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Tue 28 Jul 2020

Just finished the last round of autotesting and bug fixing. We had two principle issues this round. The first was relatively simple. The latter much more complex. Investigating the latter, I discovered a bug that has been in the scheduling code for years, namely that when a unit dies we call a function RemoveUnitFromActiveList(). This removed any reference to the unit from plans and force groups. But what I now realise is that it must also remove and handle correctly those cases where the dead unit is the Assigner for a task. This occurs when the dead unit has subordinates. It assigns them a mission. The new partial replanning code has a plethora of Asserts in the debug version of the code and one of these fired to alert me that the assigner of a task was not on map - ie dead. This fired when the subordinate came time to schedule a new task.

To fix this the RemoveUnitFrom ActiveList() now checks all tasks within a plan and if the dead unit is the assigner it abandons the plan and send orders. It also ensures that the dead unit's superForce will call send orders to ensure the subordinates get updated orders. In some cases there is a short period when the subordinates go on hold awaiting to receive orders. But it's now running pretty nicely.

I've just kicked off another round of autotesting. Hopefully we get no errors this time.
 

LongstreetCSA

Member
Joined
Jan 30, 2020
Messages
25
Points
3
Location
Earth
Thanks for the update - sounds like a big step!

I wonder would it be possible at all to give modders a way to make changes to AI behaviour/directive/formations (like force the AI to only use certain modded formations for specific situations), or is that something that is not planned to be added at all?
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
Thanks for the update - sounds like a big step!

I wonder would it be possible at all to give modders a way to make changes to AI behaviour/directive/formations (like force the AI to only use certain modded formations for specific situations), or is that something that is not planned to be added at all?

I suppose the best place for that would be in the Estab Editor, say for each service, you could have a list of tasks types and then for each have a list of possible formations each with the probability of being selected. We sort of do that in code now. But this way you could edit these and they could override the code if supplied. Nice idea.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Tuesday 11 Aug 2020.

It's been intense this last week. I'm on my second round of autotesting and fixing since I last posted. The testing highlighted a false assumption of mine that there would only ever be one self assigned plan within a force's opPlan and that this would have the force as its subject. Alas, I forgot that we create self assigned plans for subordinates if they cannot be allocated across available objectives for whatever reason - usually unreachable or out of fuel. So I had to rework my new partial replanning code. I have refactored the code to put all the core level functionality inside the scheduling code and call this from the various events which trigger a partial replan.

The good thing about this though is that it now nuances the response to abandon mission, reinforcement, recovery and completion events. In general if the abandoned plan is significant or there are self assigned missions it will opt to do a multiplan spill. After it exempts plans we don't want to touch, it allocate forces across the remaining "replans" and sends orders. The exempt plans will not be affected.

If it doesn't spill and the force is significant, it will do a multiplan top up. This similarly exempts plans but instead of reallocating all forces for the replans it instead pre-allocates the existing allocation to these and only adds forces from the abandoned plan or arriving reinforcements. These get to top up the replans. The additional force is thus spread across one or more replans.

If the force is insignificant, it does a single plan top up. It simply sorts the replans by suitability and then selects one. It's random to a degree but is biased towards the highest suitable plan.

I have written the code for abandon mission event and it compiles. Tomorow I'll do the other events and test the game.
 

LongstreetCSA

Member
Joined
Jan 30, 2020
Messages
25
Points
3
Location
Earth
I suppose the best place for that would be in the Estab Editor, say for each service, you could have a list of tasks types and then for each have a list of possible formations each with the probability of being selected. We sort of do that in code now. But this way you could edit these and they could override the code if supplied. Nice idea.

Thank you for taking the time to reply. God that would be really, really awesome if you are able to pull this off - this would mean that modders would finally be able to fully utilize this great engine for other historical periods including period-accurate unit behaviours! Very exciting prospects indeed!
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
It's been one round of testing after another here. There's significant improvement but there are still minor issues to tidy up. I have two remaining issues from the last round. I hope to finish these tomorrow. I've discussed this with Pavlo and we both agree that even though its probable we will still have issues arriving these are likely to be minor. We released the multiplayer fix last Friday on Steam. It's beta. Provided we don't discover a major problem with that and provided these last two issues are in fact minor, then we'll release a beta version of the game incorporating all the changes I have made to the engine. There will be a bit of time needed to merge code bases and then upload the new build to Steam. So it will probably be next week.
 

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 28 Aug 2020

Good news. Autotesting gives the thumbs up. I've checked in and pushed my code changes to our github repository. We now just need to merge in Pavlo's changes, do a fetch and merge at my end and then start the build process. It's on its way folks. Should be available within two weeks, if all goes smoothly.
 

Grognerd

Member
Joined
Nov 28, 2017
Messages
215
Points
28
Age
71
Location
Melbourne, USA
Excellent news indeed, thank you for your diligence in coding all that! I've followed the thread and debugging seems very tedious and complex.
 
Top