SITREP

[Dave 'Arjuna' O'Connor]

Jim, I had the same bemusement after I wrote that sentence but let it stand because in a way the victory conditions are like the onMapBoss' orders - eg secure this location by X time. It's a bit gamey, for sure.

Should we factor in doctrine here. IIRC the Italians were highly reluctant to conduct night attacks during WW2. Is there a case for having a percentage value stored at the EstabService which we can use to reduce the probability of initiating a night attack? This would be editable in the EstabMaker.

Should we do something similar for a scenario - ie store a nightAttackProbability value in the scenario file. This could allow the scenario designed to increase or decrease the probability of night attacks for a particular scenario. We could have a different probability per side. JUst an idea.

 

[Tommy.w]

Just to confirm its more to do with 'light' levels rather than time of day/night right?
Would a modifier on the training levels work? Less trained soldiers/nations would suffer a night (darkness) fighting penalty.

Say;
Units with 0%-25% Training receive a morale/cohesion/fatigue penalty of 75% when fighting in darkness.
Units with 26%-50% Training receive a morale/cohesion/fatigue penalty of 50% when fighting in darkness.
Units with 51%-75% Training receive a morale/cohesion/fatigue penalty of 25% when fighting in darkness.
Units with 86% +Training receive a morale/cohesion/fatigue penalty of 0% when fighting in darkness.

Then the player and AI would have to consider if committing poorly trained units into a night-time operation was really worth it.
This way could allow commanders, both AI and player, that knew for sure they had overwhelming odds to still attempt the attack.

Lastly a mechanic like this might be useful should Chinese units/scenarios be implemented. Poorly trained and suffered horrifically, but still there commanders deemed it appropriate to attack.

 

[song]

Just to confirm its more to do with 'light' levels rather than time of day/night right?
Would a modifier on the training levels work? Less trained soldiers/nations would suffer a night (darkness) fighting penalty.

Say;
Units with 0%-25% Training receive a morale/cohesion/fatigue penalty of 75% when fighting in darkens.
Units with 26%-50% Training receive a morale/cohesion/fatigue penalty of 50% when fighting in darkens.
Units with 51%-75% Training receive a morale/cohesion/fatigue penalty of 25% when fighting in darkens.
Units with 86% +Training receive a morale/cohesion/fatigue penalty of 0% when fighting in darkens.

Then the player and AI would have to consider if committing poorly trained units into a night-time operation was really worth it.
This way could allow commanders, both AI and player, that knew for sure they had overwhelming odds to still attempt the attack.

Lastly a mechanic like this might be useful should Chinese units/scenarios be implemented. Poorly trained and suffered horrifically, but still there commanders deemed it appropriate to attack.

I really like Tommy's suggestion, I felt it was a good solution to the situation what DAVE is dealing with, and would made the depth of the game's engine to be further improved.

 

[Dave 'Arjuna' O'Connor]

Tommy, I see where you are coming from. Your reference to "fighting in darkness" is an abstract term, at least from our game design perspective. I presume what you mean is they would suffer an adverse effect each time they fire, move, reorg. Would it also include sightings, task durations, recovery etc. There is a plethora of actions that this could be applied to and in part it already occurs.

As a general rule I try to 'prevent rather than cure'. In this case, rather than penalise them for undertaking an attack at night I want to stop or reduce the probability of them initiating the attacks at night. I want to improve the overall cohesion of forces throughout a scenario and reduce the casualties suffered because of the high tempo of combat, which is more than what happened historically.

So, I would take a different tack and apply an initiateNightAttackProbability to the random check inside InitiateAttack(). This probability would be based on a number of factors. One of these could well be the unit training and experience values you talk about. Eg the probability would be reduced significantly for poorly trained units and less so for highly trained ones and ditto for experience.

 

[Tommy.w]

Tommy, I see where you are coming from. Your reference to "fighting in darkness" is an abstract term, at least from our game design perspective. I presume what you mean is they would suffer an adverse effect each time they fire, move, reorg. Would it also include sightings, task durations, recovery etc. There is a plethora of actions that this could be applied to and in part it already occurs.

As a general rule I try to 'prevent rather than cure'. In this case, rather than penalise them for undertaking an attack at night I want to stop or reduce the probability of them initiating the attacks at night. I want to improve the overall cohesion of forces throughout a scenario and reduce the casualties suffered because of the high tempo of combat, which is more than what happened historically.

So, I would take a different tack and apply an initiateNightAttackProbability to the random check inside InitiateAttack(). This probability would be based on a number of factors. One of these could well be the unit training and experience values you talk about. Eg the probability would be reduced significantly for poorly trained units and less so for highly trained ones and ditto for experience.

Yes Dave I did indeed mean the adverse effects of conducting pretty much any activity in the dark. No matter how hard I try sneak around the bedroom I always clatter into something much to the irritation of the Mrs!

I suppose the penalty for actions at night are already factored in and doubling down on them might not be the best method.
What I as trying to achieve was an attempt to make different nations act differently. The path often taken (but not always correct) is to penalise certain actions so they act as a deterrent in both a persons and the AI's calculations.

On reflection I'm approaching this from a 'player/gamer' perspective whereby I think of a nation and apply my own biases about how they should behave across all battles in a war. .e.g. If they are Italian they are poorly trained, poor morale and therefore cant do X,Y & Z and fighting in the night should be a cluster. (which I know is not always true and I don't wish to disparage Italy they are just an example) What I forgot is this game is more of a simulator that has hand crafted scenarios reflecting either real, or plausible scenarios. And thus I believe your approaching the question with more utility in mind? - where a scenario creator has a greater level of control to craft a battle as per expected behaviours.

So you could have a Chinese army with poor stats making audacious attacks because you would just modify the probability.

In conclusion I think your method is best, or at least better than mine! As it offers the scenario creator more fidelity and therefore gives Song and I greater levels of realism.

p.s. Apologise it took me 3 days to catch up with your thought process!

 

[reg129]

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.

...

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

Jimcarravallah has covered everything I was going to say and probably more succinctly than I would have put it.

However the term I think we are missing from the quote above is momentum. If an attack is faltering it would (and should) peter out at nightfall.
Alternatively if the attack has momentum and the units are capable, the attack should continue to be pressed, albeit at a tempo which takes darkness into account with a potential re-escalation of tempo (relaxation of restrictions?) come dawn.

Cheers,
Reg

 

[Dave 'Arjuna' O'Connor]

Jimcarravallah has covered everything I was going to say and probably more succinctly than I would have put it.

However the term I think we are missing from the quote above is momentum. If an attack is faltering is would (and should) peter out at nightfall.
Alternatively if the attack has momentum and the units are capable, the attack should continue to be pressed, albeit at a tempo which takes darkness into account with a potential re-escalation of tempo (relaxation of restrictions?) come dawn.

Cheers,
Reg

Reg, we already monitor momentum during the AssessAttack() which is called every few minutes of an assault. Perhaps we should review this answer tweak the progress threshold so that it calls off the attack more easily at night. Thanks for bringing this to my attention.

 

[jimcarravallah]

Jim, I had the same bemusement after I wrote that sentence but let it stand because in a way the victory conditions are like the onMapBoss' orders - eg secure this location by X time. It's a bit gamey, for sure.

Should we factor in doctrine here. IIRC the Italians were highly reluctant to conduct night attacks during WW2. Is there a case for having a percentage value stored at the EstabService which we can use to reduce the probability of initiating a night attack? This would be editable in the EstabMaker.

Should we do something similar for a scenario - ie store a nightAttackProbability value in the scenario file. This could allow the scenario designed to increase or decrease the probability of night attacks for a particular scenario. We could have a different probability per side. JUst an idea.

Sorry, I've been out having my heart's aortic valve replaced -- something that sounded extremely serious when I first learned that a deterriorating valve threatened my life, but proved to be correcttable by a relatively non-invasive procedure performed through an artery in the leg. What siounded like a harrowing procedure with the heart took about a 30-hour stay in the hospital.

My health and condition has bounced back rather dramatically. I'm not yet playing baseball, but finally feel good enough to consider taking up golf after a 15-year hiatus because I lacked the stamina to follow my shots around the course (which the way I play is more like a countryside hike than the efficient follow the shot routine one may see in professional torunaments.

Dave, to answer your question about what I'll call the country or main force aggression toggle in the game:

In the one scenario I developed to master the mechanics of scenario development process, I was faced with differentiating four forces' levels of aggression -- The Japanese Army garrison, the Japanese elite Special Naval Landing Force, the US Marines and the US Army.

Historically the Japanese were ordered to fight to the last man, with the SNLF historically more aggressive than the regular army forces, the Marines with a high esprit and historically quite aggressive for American troops and the Army lead by a perceived mediocre general.

Each had a historically documented difference in fighting style and combat behavior. I addressed the issue by tioggling then measures of troop health and command and force aggression available in the game and scenario settings.

I would have welcomed some general historically documented force efficiency guidelines differentiated by country and force type, but with some tweeking it worked out.

All that's to say the toggle of parameter ranges would help scenario developers, but the differentiation can be accomplished using the already available scenario building tools for the developers who take the time to resaerch that sublety.

 

[Grognerd]

Glad to hear/see your health issue is stabilized! Aint aging a PITA...
Seems to me (I'm 71) that the only thing about aging that I like is you can blame everything on it...

 

[Dave 'Arjuna' O'Connor]

Grognard, too true.

Jim, wonderful to hear you're recuperating well. Don't overdo it. We don't want to lose you, mate! We now have some EstabService characteristics that can be used by the code. Pavlo has taken the lead on this. I really should check them out further. "So many things to do...so little time."

 

[jimcarravallah]

Grognard, too true.

Jim, wonderful to hear you're recuperating well. Don't overdo it. We don't want to lose you, mate! We now have some EstabService characteristics that can be used by the code. Pavlo has taken the lead on this. I really should check them out further. "So many things to do...so little time."

Thanks, Dave!

I recall discussing the issue with Pavlo, more likely when I offered him the X3X_Estab XML to help with his Japanese force structure for the Khalkhin Gol scenarios.

He has been on hiatus from any discussions for some time. Miss his input.

Hope he had a chance to get his mother out of the Ukraine and has avoided any danger from that conflagaration.

 

[Dave 'Arjuna' O'Connor]

Thanks, Dave!

I recall discussing the issue with Pavlo, more likely when I offered him the X3X_Estab XML to help with his Japanese force structure for the Khalkhin Gol scenarios.

He has been on hiatus from any discussions for some time. Miss his input.

Hope he had a chance to get his mother out of the Ukraine and has avoided any danger from that conflagaration.

Yes he did manage to get his mother out. He has been doing it tough. It may be some time before he's more active.

 

[jimcarravallah]

Yes he did manage to get his mother out. He has been doing it tough. It may be some time before he's more active.

If you still get in touch with him, please offer him my best wishes.

I'm hoping to get back to a time we worry about the game rather than what he's dealing with.

 

[john connor]

Glad to hear you're ok, Jim. Sounds scary. Hope you recover well, and quickly. The operation sounds amazing - to replace/repair a heart valve via a blood vessel in the leg. Amazing.

 

[jimcarravallah]

Glad to hear you're ok, Jim. Sounds scary. Hope you recover well, and quickly. The operation sounds amazing - to replace/repair a heart valve via a blood vessel in the leg. Amazing.

Thanks, John.

The surgery is considered routine at the hospital where I was treated. It's sometimes treated as outpatient surgery -- in and out the same day if performed early enough in the morning.

Yes, medical science is amazing, however I'd rather be reading about it than participating in it. These days I'm learning more about nutrition, body chemistry and physiology than I ever encountered or was eager to learn in biology studies during my days of formal education.

 

[Dave 'Arjuna' O'Connor]

SITREP Fri 4 Aug 23

Hi all,

I've spent the week auto-testing. I run the autotester. This plays the debug version of the game on a continuous process, where it runs for three minutes of real time, saves and runs some more. THat way we have a recording of the last three minutes in case it asserts. If it does, it saves the latest recording and dumps out a stack call of the code leading up to the assert along with a few other details. I ran it originally on Monday for half an hour and got a plethora of asserts. I sorted these by frequency and tackled my way dopwn the list. Once I got through three or four different asserts, I cleared the recordings and logs and re-ran the autotester.

Today I re-ran it again and all twenty records are for the same assert. Normally, I'd be pleased with that, but this assert is the dreaded referenced corpse assert. In all these cases the circumstances are similar. A mission plan has been destroyed because a unit opts to replan all its plans. Inside the ReplanAll() it first calls DestroyCompletedPlans(). In these cases, the culprit plan is already completed and so it calls Destroy() on the plan. This should and usually does get rid of all the connections, linkages and dependencies with other objects like forces, tasks, opPlans (a force's collection of plans), sides, events etc. But in these cases, there is still an errant reference in the database for this plan. This tells me that I've missed one of these connections. Alas it doesn't tell me with which object.

I have spent all day today trying to track it down. I determined that two new event types that I had introduced - StartMission and OnCallReady - were not being dealt with. I fixed this but still there is a problem. There must be something else, something I am missing. I've stepped through and seen that it has successfully destroyed many other plans before it gets to the one on which it fails. SO there must be something about the perculiar circumstance. I am going to have to review the calling chains of these others and see if that will indicate a pattern of the code where some other object gets a connection with the plan. But after six hours of this, I've had enough for today. It's brain draining work. Writing this post is much easier.

On Monday morning, with a fresh brain, I should nail it.

 

[Tommy.w]

Dave when you have tracked this 'bug' down what does it mean in the overall context of the patch? Is this a key milestone or just another step in the great march?
Glad writing the post is easier - to me they are great morale boosts!

Also FYI it looks like some people mentioned (on DISCORD) they have tried to join the forums but are struggling to sign up or waiting for approval.- Not sure if its your area but thought I'd raise it anyway.

 

[Dave 'Arjuna' O'Connor]

Tommy,

The work I have done these past few years is to overhaul the attack code. By and large I have re-written it along with swags of other code - eg scheduling. I have not finished everything I set out to but it's way past the time a new build was put out. So, I have stopped any more code design/overhaul and focused solely on getting what we have now out there. The first step in that process was to get it to compile and run. It does that now, albeit with asserts (places where the code lets me know something is not right). I always place a lot of asserts that test my assumptions.

Once I can get the tutorial running a for a good period of time, I switch to auto-testing. This highlights the issues over a collection of different scenarios and settings. When I can get the autotester to run without any significant asserts I will create a beta build and release that on Steam for you all to have a play with. At the moment I have just this last referenced corpse assert to fix. However, I will lay good money down that once I do the scenarios will run further but will also encounter other asserts that will need fixing. Thye may not. We can live in hope. So, we could be very close to getting out a beta build or we may have some more work ahead. I can't be more certain than that.

BTW thanks for the heads up on joining the forum. Just to confirm, it's this forum they are having issues with or the one on Steam?

 

[Tommy.w]

Hi Dave,

Thanks so much for the context!

It was the LnL forum they seemed to be having an issue with (2 people that have mentioned it).

 

[Dave 'Arjuna' O'Connor]

OK Tommy, I'll let David Heath know.