SITREP

[Seb3brv78]

Good luck Dave, wish you and your wife all the best. Take care.

 

[song]

Good luck Dave

 

[Holman]

Thanks, Dave. Best wishes for you and your wife.

 

[song]

SITREP Sat 9 Apr 22

Hi all,

Unfortunately I made no progress these last three weeks. The first two I was laid low with a dreadful virus. I thought it might be covid but the pcr test said I was negative. In the second week my wife had to return to work at the hospital. She had been working from home for a long time and did not want to go back to the hospital. She was there a week and came down with covid. I had another test and again it was negative. We're all self isolating here at home now. Got another ten days to go. My first priority is to look after my wife. So hence no progress on the game. Hopefully my wife will get better and I can remain uninfected. Then I can get back to coding.

Hello Dave, I haven't heard from you for a long time. I am very worried about the current situation of you and your wife. I wonder if everything is getting better? I wish you peace

 

[Dave 'Arjuna' O'Connor]

Thanks Song for your thoughts. All good now - well a lot better anyway. My wife is back at work, alas at the hospital where it is always a risk of an infection of one ilk or another. I actually started back programming on Friday.

 

[song]

Thanks Song for your thoughts. All good now - well a lot better anyway. My wife is back at work, alas at the hospital where it is always a risk of an infection of one ilk or another. I actually started back programming on Friday.

I'm just glad you're getting your life back together. May God bless you in all your works at hand!

 

[Dave 'Arjuna' O'Connor]

SITREP Fri 27 May 22

Hi all,

Late yesterday afternoon I finally got the game running again. I managed to get the initial attacks by CCA 4th Armoured Div to be developed. I have been stomping on other minor bugs caused in part by my recent changes to the slippage code. These were essential to enable the slipping at different rates of HHour and End times in an attack. In the past this shortcoming was causing attacks to be abandoned. I have spent today crushing a swag of downstream issues. I'm three and half hours into the tutorial, so things are looking good. I hope to I get it to run without issues next week. Then I will do some autotesting. Once we get it robust, I'll release a new build.

 

[song]

SITREP Fri 27 May 22

Hi all,

Late yesterday afternoon I finally got the game running again. I managed to get the initial attacks by CCA 4th Armoured Div to be developed. I have been stomping on other minor bugs caused in part by my recent changes to the slippage code. These were essential to enable the slipping at different rates of HHour and End times in an attack. In the past this shortcoming was causing attacks to be abandoned. I have spent today crushing a swag of downstream issues. I'm three and half hours into the tutorial, so things are looking good. I hope to I get it to run without issues next week. Then I will do some autotesting. Once we get it robust, I'll release a new build.

Great progress! Thanks Dave for all your hard works！ and look forward to the new build release!

 

[Art Hall]

sounds great Dave!

 

[Dave 'Arjuna' O'Connor]

SITREP Fri 3 Jun 22

Hi all,

This week I have been bug fixing my new code. I am up to a point where I realise that I need two separate methods for determining the max available HHour slippage for attacks by the onMapBoss. The onMapBoss is the senior force on the map and they need special handling because firstly they are governed by side orders set by the scenario developer and because they often have more scope than subordinate forces. Today I realised that the function GetMaxSlippage() basically gets called from two different parts of the code. There are a plethora of calls to it when assessing a plan that is already underway. But there are also a couple inside the code that develops an attack plan.

Trouble is the calls inside DevelopAttack() deal with multiple approaches or courses of action, while once underway there is only the selected course of action. So I need special case code for those cases where we are developing the plan. My first cut this week sort of worked but it needs more nuance. Bottom line is I'm still plugging away.

 

[Dave 'Arjuna' O'Connor]

SITREP Sat 11 Jun 22

Hi all,

Made good progress this week ironing out bugs introduced by new code. Am getting through more and more of a game before it asserts. I got ambitious and tried autotesting on Thursday night but got too many recordings to use that process just yet. I should be there by end of next week. Very few attacks are being abandoned during the planning process because of lack of time now. That's heartening. Stay tuned.

 

[Le gac]

 

[Tommy.w]

Can anyone point me in the direction of what this 'mega' patch will introduce? I understand it will improve attacking and I'm sure I read somewhere it will introduce a new artillery mechanic?
Like most people on this forum really looking forward to it and the release of Bradley at Bay!

 

[Dave 'Arjuna' O'Connor]

Tommy.w

I'll try and work up a change list next week.

 

[Le gac]

The best opérationnal wargames i've ever played since 30 years ( with Graviteam tactics for 3 D). Very immersive and réalistic. The AI is fantastic for computer one.
And if you improve it again...
Congratulations and thank you for your efforts Dave.
I can't wait for Bradley at bay and other DLC i wish after this patch.

 

[jimcarravallah]

Can anyone point me in the direction of what this 'mega' patch will introduce? I understand it will improve attacking and I'm sure I read somewhere it will introduce a new artillery mechanic?
Like most people on this forum really looking forward to it and the release of Bradley at Bay!

The contents are built into the SITREP reports.

Attack code:

Basically the attack code is being altered to force primary offensive units to take the lead in the attack. In the past, headquarters and artillery units which may be closer to the attack jump off point would initiate the effort and be destroyed before the heavy combat units more suited to attacking arrived on the scene.

It also will eliminate the arbitrary reordering the the offensive line where a battalion on the left side of the line crossed over to the right, and the battalion on the right changed places with the one arriving from the left before the attack proceeded.

It also will establish a more flexible time to initiate an attack calculation that caused attacks to be dropped because time to maneuver exceeded the time set to step off causing an attack to stall while there was still time left on the gameclock.

It will also evaluate the real time effectiveness of the primary attacking force to allow it to replan and advance on an objective despite the loss of units included in the initial plan.

Artillery:

Artillery targeting will be altered to make unobserved and long distance bombardment less lethal. Past artillery efforts focused all projectiles on a small target area without considering time to alter fire instruction, and dispersion of rounds based on the distance from gun to target and the level of observation on the target to pinpoint fire.

Movement:

Movement requirements, an offshoot of refining the attack code, will be calculated to take into account time to cover the distances and time the movement action is expected to be completed rather than to avoid any contact with the enemy at the expense of quickly assembling moved units for an operation. We should see fewer moves to contact where a unit takes a safe circuitous route around the map to avoid contact and observation rather than quickly getting to a point where an operation can be initiated

 

[Dave 'Arjuna' O'Connor]

SITREP Fri 24 Jun 22

Hi all,

I have spent this week trying to get complex attacks working properly. But in the end I had to revise my code for basic attacks as this was not handling all the possible cases. At the root of this are the changes I made to ensure HQs stay with the main attack force. We now achieve this by having the attack force assemble at the assemblyLoc, which is some distance forward of the objective (2 to 3 kms for a Bde). There the force gathers from whatever locations it was deployed across. Then it moves off together to the reserveLoc (1 to 2 kms), drops off the HQs and reserve forces and the assault force then moves to the FUP ( 500m to 1 km) and launches its assault onto the objective.

But we also want to stop forces that are already forward of these locations from moving back only to come forward again. So now the code determines those forces near the FUP and hives these off from the moveToFUP force group (FG). When the moveToFUPFG arrives it will combine with the nearFUPFG to become the assaultFG. We do the same sort of thing at the reserveLoc and assemblyLoc. Picture it like a snake unfurling from the assembly to the objective.

Trouble is the force may be too close to the objective to bother with an assembly and in other cases we may not have a reserve or a HQ or all the forces are already near the assembly or reserveLoc or FUP and we can dispense with the preceding phases altogether. It's complicated. I have now revised the DevelopBasicAttack() to manage these. I have yet to test these changes. But first I now need to do the same for complex attacks.

For a complex attack we determine the approaches, select one and then assign our subordinate forces to the subAttacks and send orders. Eg the Bde sends attack orders to each of its Bn HQs. But I want to have the Bde assemble prior to the Bns doing their subAttacks. And I want them to ignore the need for their own assembly. Ie I want to just have the one assembly for the Bde and then the Bn move off to their reserveLocs and FUPs. Further, I don't want companies near the objective hiking back to the Bde assembly only to march forward again.

So rather than than simply relying on the Bn HQs to develop their own subAttacks and allocate their own forces. I need to determine which of their forces need to be assigned to their nearby FGs and deduct these from the Bde's mainForce that moves to the Bde AssemblyLoc. That's where I am at right now. There are a different options for handling this, but no matter which I choose it invlolves storing and passing more data with the orders to the Bns. In essence the Bde HQ will be specifying more stuff that the Bn HQs will have to comply with - eg. where they will have their reserveLoc and what forces will be assigned to nearbyFGs.

At the moment I am leaning towards adding more fields to the ScenTask class. At the moment it stores the objLoc and FUP. We need to add the reserveLoc and assemblyLoc, flags to ignore both, nearFUPFG, nearResFG and nearAssFG. If there is no one assigned to these FGs then the Bn HQ can do as he pleases, but otherwise the section of code inside DevelopBasicAttack() that does so for a specifiedFUP will need to be expanded to handle a specified reserveLoc and assemblyLoc. We will copy the approach route to the subAttack and then from all this data the Bn HQ will be able to simply calc the various routes without having to develop them from scratch. That should reduce processing load for the subAttacks but increase it a little for the complex attack.

I also need to consider how a human player will be able to manage all this. At the moment the player can order a force to attack by setting the objective location. He can also specify the FUP by placing an additional waypoint prior to the objective. I'm thinking that if the player lays down say five waypoints, then the final one will be the objective, the one prior to that will be the FUP, prior to that will be the reserveLoc and prior to that the assembly loc. That would be the simplest to implement.

OK enough pontificating. As you can see there is still more work to go.

 

[Tommy.w]

Thanks for the update and letting us know that the update marches on to final victory.

 

[Art Hall]

Thanks for all your hard work Dave!

 

[Chertiozhnik]

Already the best wargame I've ever played (out of a lot), and sounds like it's getting even better, great work!