SITREP

[Tommy.w]

Dave, if the community (or me) were to pull together more pictures, bio's and the such would you be interested in adding it to the game? I dont mean as a Mod but something that all players would benefit from?

I only ask because I love coming across some commanders personalities/bio's and with access to the internet we have more historical information at our fingertips.

I don't want to generate anymore work for you though, so if this is something your either not interested in - or want would prefer to park until after the update, I will happily wind my neck in!

 

[jimcarravallah]

Dave, if the community (or me) were to pull together more pictures, bio's and the such would you be interested in adding it to the game? I dont mean as a Mod but something that all players would benefit from?

I only ask because I love coming across some commanders personalities/bio's and with access to the internet we have more historical information at our fingertips.

I don't want to generate anymore work for you though, so if this is something your either not interested in - or want would prefer to park until after the update, I will happily wind my neck in!

This is probably a more suitable question for Simovitch, who had been assigned the job of data manager on the team. As I recall, the bios of the commanders are kept under the scenario file OOB estabs added at the discretion of the scenario designer.

The best way to flesh them out would be to pick a scenario, identify the item in the OOB that lacks a commander bio and research the history under the specific unit designation to identify it's commander at the time the battle was fought.

As you go down in echelons, the historical detail wanes, but fleshing out the data to the regimental level could be fruitful.

After validating the data and it's ability to be displayed in the user interface in term of characters used, Simovitch could either release the commercial files for update or insert the information for a future patch.

 

[simovitch]

Bio's are added to the individual scenarios, and commanders of the same unit will change, sometimes in a matter of days or weeks at the lower echelons.

Once we have something that resembles a release version of this new patch and I'm still lucid I would be happy to work on getting some help integrating more bio's into the official scenarios. The other thing we need is Rich's (the Plodder) exceptional situation map graphics done for Bradley at Bay.

I don't have the bandwidth to do this for the current version of the game though. That should be done by someone who provides the updated scenarios as a mod.

 

[Dave 'Arjuna' O'Connor]

SITREP Thu 13 Jul 23

Hi all,

I'm nearing the end of the scheduling overhaul for the attack. It's been a long and arduous effort. But I do believe I've substantially reduced the amount or replanning that was going on. I have made a lot of changes, some of which turned out to be less than optimum and have been subsequently changed again. In the end it boiled down to a compromise, choosing a workable solution over the perfect.

The perfect solution would have meant taking a snapshot of the boss's opPlan and sending a copy with the orders. But this would blow out the data and network traffic. Instead, the ReceiveOrdersEvent (ROE) just passes a pointer to the bossTask along with a version number. and a slip status. The version number is copied to the subordinate's plan when he processes the ROE. But if the subordinate is waiting on another order from the boss and it includes the same task and that task's version is greater than the subordinate's plan version it won't process the ROE. Instead it will wait to process the later one. The new code will ensure that if the current ROE's slip status is not slipping and that of the later ROE is slipping, then it will change that status to not slipping so a full plan is developed.

I've ran my recording through the first morning and it's looking good. I've hit an assert that will require some refinement to the code that sets the version when we just slip the plan. I will get to that next week. Looking good!

 

[john connor]

Great, Dave. So, what, only a couple of weeks before it's finally done - the update, I mean?

 

[Grognerd]

Well excellent then, perseverance pays off!

 

[Dave 'Arjuna' O'Connor]

SITREP Fri 21 Jul 23

Hi all,

I've made good progress with the scheduling issues. I have stomped on numerous bugs with the new attack code. This is stress testing the scheduling code like never before. The versioning of tasks now appears to work properly both when the version of a task is set and when it's processed on receipt of orders. This fixes a number of cases that caused a force to replan immediately after it slipped a plan it was developing. This afternoon I have been knee deep in the slippage code and realise that the existing GetMaxSlippage() is no longer fit for purpose. It needs to handle next and concurrent tasks differently and it needs to cap any slippage for tasks that end after the desiredEnd of the sourceTask. I'll get onto this on Monday.

 

[Tommy.w]

Great timing as I have seen a small flurry of activity on the Steam, Hex and other media forms. People are still really excited by this game - such a testament to its potential and the communities appetite for it.

 

[Grognerd]

I have a question if it's Okay. If it is still too early there is no need to answer, no way I'm trying to pressure anyone.

Can you put a rough time-frame on how long until a Beta is released on Steam to evaluate? Days/weeks/months?

 

[song]

I have a question if it's Okay. If it is still too early there is no need to answer, no way I'm trying to pressure anyone.

Can you put a rough time-frame on how long until a Beta is released on Steam to evaluate? Days/weeks/months?

I have the same question

 

[jimcarravallah]

I have the same question

Typically, the internal beta team will have at least a few weeks to stress the software before it is publically released.

This evaluation will most likely include a second evaluation of the Bradley at Bay module with the new attack code and the attack code as a standalone with the remaining game modules, so I'd aanticipate at least a couple of months in test / fix / test mode before a public beta reelase.

 

[john connor]

Though it's possible Dave might opt for a public beta, no? To speed things up. But the big question is how long Dave thinks it will be to get anything that can be tested in any way. I too would love to hear his time frame on that.

 

[Dave 'Arjuna' O'Connor]

Yes, we will go straight to a public beta when the game is reasonable - ie when I'm not getting constant asserts in the code. I'm not there yet.

So far, I have rewritten the attack code to prevent non-line units from getting ahead of the main force; to prevent unnecessary replanning of attacks; and to prevent unnecessary abandonment of attacks. I am not completely happy with the slippage code and its effects on attacks, but I have whipped it into as good a shape as I can without a major overhaul of it. Right now, I am looking at reducing the number of night attacks. Reducing the probability of these will improve the overall fatigue levels of the forces - they often end up knackered all the time because they rarely get to rest at night, which was the norm in WW2.

Currently, there is a StandardNightReassessment() that determines if a force should rest at night. But this bypassed if the force is in the middle of an attack - ie we don't want to stop the attack midway. What is missing is a test when we initiate the attack to determine if instead we should not attack because it is night or night is soon approaching. I am just considering right now the factors we need to consider for that test.

The training and experience of the force should be a factor - eg. green forces should have a next to zero probability of attacking at night. It should be higher for trained units and higher still for elite forces.

Please help me out here and suggest some other factors I should consider.

 

[MarkShot]

Well, maybe forces despite experience who are too far beyond the fatigue limit should not be forced into a new offensive evolution.

---

BTW, for those who are not programmers.

ASSERT: Also known in programmer speak as a "sanity test" is piece of code that tests for conditions which are implicitly expected to true. In "release" their failure to be true could cause unexpected behavior or even crashes. Thus, asserts is a form of realtime quality control of the coding process. If triggered (usually) logged, there is something which needs further investigation.

Assert are often supported directly by the coding language -> EXE process. Thus, they are removed with a simple one word switch when building the EXE (since they should not be needed in solid code). It should be noted, you should not judge betas by their runtime performance. They contain extra code which slows them down.

This is how Dave is coding. Other game developers may mean something different when they say "beta".

PS: Dave is following industry standard practices.

 

[Tommy.w]

Dave not sure if its what your after but;

A commanders 'Stubbornness' - I think this mainly refers to defence but a commanders insistence on attacking an objective might have an influence.

At the unit level obviously you have fatigue - but I wonder if cohesion should factor - i.e. if a units cohesion is already below a certain level and your about to head into night, its only going to get (significantly) worse. Therefor a unit might be unable/unwilling to conduct an attack or even prepare itself.
This might also be balanced against a units aggression.
Also I cant really recall but if a unit is at the FUP should/could it take longer to re-org at night? This might reduce the number of attacks being conducted at night because it consumes time. Perhaps an additional penalty if its not a plan that was generated in daylight hours.

AI night attacks have cropped up a few times so really happy this is now being tested.

MarkShot really appreciate the explanation - I have no real coding experience so having things explained is not only useful but really interesting!

 

[Dave 'Arjuna' O'Connor]

Tommy,

Yes, I agree that reorgs at night should take longer. I'll add that, thanks.

 

[jimcarravallah]

Yes, we will go straight to a public beta when the game is reasonable - ie when I'm not getting constant asserts in the code. I'm not there yet.

So far, I have rewritten the attack code to prevent non-line units from getting ahead of the main force; to prevent unnecessary replanning of attacks; and to prevent unnecessary abandonment of attacks. I am not completely happy with the slippage code and its effects on attacks, but I have whipped it into as good a shape as I can without a major overhaul of it. Right now, I am looking at reducing the number of night attacks. Reducing the probability of these will improve the overall fatigue levels of the forces - they often end up knackered all the time because they rarely get to rest at night, which was the norm in WW2.

Currently, there is a StandardNightReassessment() that determines if a force should rest at night. But this bypassed if the force is in the middle of an attack - ie we don't want to stop the attack midway. What is missing is a test when we initiate the attack to determine if instead we should not attack because it is night or night is soon approaching. I am just considering right now the factors we need to consider for that test.

The training and experience of the force should be a factor - eg. green forces should have a next to zero probability of attacking at night. It should be higher for trained units and higher still for elite forces.

Please help me out here and suggest some other factors I should consider.

I tend to play cautiously with the fatigue / cohesion factors during the game.

Because of this I'm careful about offering the force a time to rest, normally at night, to recover whatever is lost in the daylight high activity times. During the nightime rest periods, I may plan an attack and initiate it before the sunrise if my troops have had at least eight hours of inactivity or standing on in-situ defense to recover. But I expect t to accomplish what I desire during the good daylight hours using whatever is accomplished before full sun as the surprise factor.

In the event a daylight attack drifts into the night time hours, I'll order the force to defend in situ to avoid destroying its combat capability by pressing on.

Thus the force is always at its healthiest standard to conduct effective combat operations, even if it reaches its combat goals later than I originally planned.

All this is to say that I don't shy away from halting an attack at night if the penalty for accomplishing its goals is a force disrupted to the point it can't continue effective combat operations.

 

[Dave 'Arjuna' O'Connor]

I take your point Jim about not shying away from halting an attacking force. But in most cases, such a situation should have been foreseen during the planning of the attack. Estimates for timings ca always blow out but if the estimate is telling you that your assault will be in the dark then unless time is of the imperative your best to move the force to your intended assembly during the remaining daylight, rest up till an hour before dawn and then mount your attack so HHour is near dawn.

There are always exceptions to this and that is something we need to canvass. For instance, what are those cases where a night attack is needed? It may be because the scenario is about to end, and you need the victory points pronto. It may be because the enemy has a significant advantage in artillery and the dark will help offset its effectiveness. What are some others, folks?

 

[Tommy.w]

If the enemy force holds better ground giving it a defensive advantage, or the enemy force has supporting fire from other units (such as AT guns).

Manhay Crossing is a good example where attacking at night means you only fight what you stumble over/into. If I'm playing as allies getting close quarters with the Panthers helps take them down.

Also if I'm trying to surprise or fix the enemy force - night time attacks can be unsettling because as a defender its harder to appreciate the enemy force.

 

[jimcarravallah]

I take your point Jim about not shying away from halting an attacking force. But in most cases, such a situation should have been foreseen during the planning of the attack. Estimates for timings ca always blow out but if the estimate is telling you that your assault will be in the dark then unless time is of the imperative your best to move the force to your intended assembly during the remaining daylight, rest up till an hour before dawn and then mount your attack so HHour is near dawn.

There are always exceptions to this and that is something we need to canvass. For instance, what are those cases where a night attack is needed? It may be because the scenario is about to end, and you need the victory points pronto. It may be because the enemy has a significant advantage in artillery and the dark will help offset its effectiveness. What are some others, folks?

I kind of chucklesd when you discuss needing a night attack because time is growing short.

There have been a significant number of complaints about the AI "cheating" by pursuing just such an attack at the end of the game.

If the AI is acting on the time constraints to eke out a victory, it actually shows the programming is generating quite human-like behavior.
I agree with your premise of taking into account the time of day to minimize night attacks.
The only issue I see is trust in the progress estimate.

It's based on available intel at the start of the attack. The intel's accuracy could be affected by the enemy bringing up reinforcements or being better prepared than antticipated to slow the attack's progress, leading to effort continuing the nighttime hours.

That's primarily the contingency my decision to halt and rest is based on.

Perhaps that contingency could be addressed by some evaluation of the effort's time estimate for completion plus. a percentage overrun on that estimate triggering a decision for a resting halt. I don't want to complicate the solution, but my seat of the pants decision is based on how much twillih]ght remains and the health status of my force compared to the same status of the defending force. -- it may be worthwhile to accept a greater level of nighttime disruption if the enemy breaks and runs as a result.