Modeling variable readiness/alert levels

[KnightHawk75]

Sorry, but I disagree with your disagree. That a 1-2 person crewed aircraft can't stay airborne indefinitely without the pilots becoming too tired at some point to safely land or function at all is about the most universal thing that I can imagine

I don't disagree, but that's my point though, not everything is a 1-2 person aircraft, not all aircraft are going to be effected the same way, one size doesn't fit all, a b-2 or e-3 can't be treated the same as an f-15.

Letting your CAP aircraft refuel seven times to loiter for 17 hours at a time is an unrealistic force-multiplier.

Sure it not, and given how weak the ai sometimes can be at fighting or evading, it's a handy multiplier to have available to give the ai at times, should one desire to ignore reality for whatever the reasoning, I'd hate to see flexibility hampered.

[KnightHawk75]

ORIGINAL: thewood1

Can you currently set a unit to blind through Lua? I have never seen it and it might also be used to set individual units readiness in a rough way.

You mean it's awareness level? Far as I know that's a side level setting only ATM. Might be interesting if it was unit level, but might also be more complication than it's worth. You can basically accomplish the same thing by disabling or temp-damaging certain (or all) sensors on a unit. I've done that with certain radars before simulating over-heating or problem after X amount of time needing a cool-down period, or just to randomly inject temporary equipment failures on random sensor entries.

[c3k]

OODA degradation and Crew Size

A few points have been made about this. IF OODA degradation based on accumulated fatigue will be incorporated, then crew size needs to be taken into account.

A 4-man tank crew can endure better than a 3-man. (loading, digging, sitting watch, etc.)
A 2-pilot aircraft (B2, C17, etc.) can mitigate fatigue whereas a 1-pilot plane cannot (F15, F22, etc.). (One pilot naps, the other flies.)
A 15,000 ton ship with a crew of 400 can relieve shifts far better than the same ship with a crew of 250.

[thewood1]

And I think that last post highlights the need to be careful with the slippery slope. How far down the detail hole do you go before it becomes unsupportable and unmanageable. We've gone from high level readiness discussions to specific crew size discussions. How long before we start worrying about what someone had for breakfast or if they had coffee? We are already seeing this with aircraft maneuvering. You have people staring at TacView and complaining about climb angles that have no bearing on the final result.

That's why letting scenario designers decide on how to use a basic and abstracted tool might be the best approach.

[Randomizer]

While I hope that the Developers choose not to go down this rabbit hole, having the ability to set proficiency via Lua script or event action (preferred) might be a simple expedient in this direction. Perhaps a new proficiency, "Unready", could be added slowing reaction times and then an action or script could raise the side (or unit) proficiency to that desired by the scenario author. Despite the listed studies, much of this is very subjective and exceptions can probably be easily found for every rule.

I cannot see how universally implementing readiness conditions would appreciably improve the commercial, single-player CMO experience.

-C

[pbrowne]

Units have a strength indicator, presumably based on damage.

According to the manual, there are built-in OODA loop delays, based on proficiency either for the side or the unit level.

If a unit's strength is diminished past a certain point, does the unit withdrawal from engagement, or panic and run, or surrender, or just continue to fight until destroyed?

I know other tactical games have unit indicators for suppression which incorporates strength, morale etc, e.g. Steel Division 2 where units will tactically retreat or flee or surrender.

The discussion on how better to manage OODA loop delay is one thing, but I think it needs to be more encompassing to account for things like fatigue and moral based on factors that include proficiency, situation in combat, proximity of friendly units, resupply etc.

[Twistedpretzel]

I always considered this program to be a simulator designed to simulate platforms, sensors, weapons, and their effectiveness more than anything else. I think that adding fatigue or variable readiness will be a detractor. Some scenarios last several days, the majority less than a day. Most scenarios are planned attacks/defenses with missions, not unexpected defensive actions. I think CMO shines when you are given resources and clear objectives that need to be accomplished with those resources.

If it is decided that it would be beneficial to delve into "readiness" status I think the best course of action would be to use the example given by Dimitris using Global Thunder MBX, but maybe even scaled back.

Model various levels of general quarters with allowable time limits. Increase the OODA for each lower level of GQ. No fatigue. Nothing else. Just increase the time required to respond, allow all weapons and sensors to be available. Maybe instead of increasing OODA just increase reload times for weapon systems at lower levels of GQ. I remember always having someone ready to utilize weapon systems at lower GQ levels, but chances were you didn't have a full gun crew on station. Expend one loadout whether that is a belt of .50, drum of 76mm, or belt of 25mm and you're reloading single handedly until the rest of the gun crew arrived. Sensors I have less experience with but feel like they didn't have any extra personnel missing than normal and their watch stations weren't necessarily effected by manning deficiencies at lower levels of readiness.

Keep it simple, increase OODA for each decreased level of GQ or increase reload time for weapon systems. I don't think it would be necessary to implement more and maintain what I consider in my opinion to be the spirit and core of CMO. That being said, you guys make CMO so my opinion of what it exists as and for is moot. I just think in most scenarios there will typically be two default states. Totally prepared for attack/defense, or totally unprepared, and CMO definitely shines with the former.

[Twistedpretzel]

ORIGINAL: Gunner98
The side proficiency levels and the OODA-loop setup that exist already do some of this, and I think that generally works well.

Well said. It would be tough to justify getting into a higher readiness level if you get hit with your pants down. I think for scenarios such as the real world events described just assigning the unit/platform in scenario a low proficiency level would be sufficient. Their OODA loop is already lengthy, and in real world it is unlikely that OODA loop is going to get any quicker or their readiness will improve if they have been hit with hostile fire while at a low readiness status.

[thewood1]

"If a unit's strength is diminished past a certain point, does the unit withdrawal from engagement, or panic and run, or surrender, or just continue to fight until destroyed?"

There is an entire set of ROEs, options, and even lua code if desired for this in the game already. Its a key part of the game and planning. If your not using it, you are using your units like robots. The main issue is scenario designers don't punish the player enough if saving a damaged unit is a goal. There are all kinds of things in the game already to do 80% of what is being asked about. The other 20% is what lua is for.

The question to me isn't about readiness, fatigue, etc. You can model it today. The question is some global readiness setting that does it all at once for scenario designers. Being able to connect OODA and proficiency is what most scenario designers would need.

[Dimitris]

ORIGINAL: pbrowne

Units have a strength indicator, presumably based on damage.

According to the manual, there are built-in OODA loop delays, based on proficiency either for the side or the unit level.

If a unit's strength is diminished past a certain point, does the unit withdrawal from engagement, or panic and run, or surrender, or just continue to fight until destroyed?

I know other tactical games have unit indicators for suppression which incorporates strength, morale etc, e.g. Steel Division 2 where units will tactically retreat or flee or surrender.

The discussion on how better to manage OODA loop delay is one thing, but I think it needs to be more encompassing to account for things like fatigue and moral based on factors that include proficiency, situation in combat, proximity of friendly units, resupply etc.

There are a set of Withdraw/Redeploy doctrine settings that are dedicated to this:

[stilesw]

IMO if CMO is going to incorporate modelling of OODA concepts, or indeed the whole domain of humans in conflict, then there should be an appreciation of all dimensions, not just physical. This includes, in Boyd's concept, Physical, Mental and Moral - yes moral, not morale, e.g. Mao's War of Resistance against Japan, Vietnam and Afghanistan etc.

A paper on morale and combat effectiveness, part of the mental dimension of Boyd's OODA Loop:

https://scholarship.richmond.edu/cgi/vi ... ors-theses

Some casual reading on OODA and a holistic literature review on relationships with numerous theories, including Innovation Theory, Second Law of Thermodynamics, Gödel’s Incompleteness Theorem, Heisenberg’s Uncertainty or Inderminacy Principle and Boyd’s Integration Principle...

https://apps.dtic.mil/dtic/tr/fulltext/u2/a425228.pdf

Peter,
Thanks, also added to the reference library.

[Midane]

If add a fatigue model, please don't forget about aircraft that have been airborne for 15 hours.

Big time. Right now, with proper refueling, a Growler can perform its functions for 5 days in a row without ever touching the land ...

[boogabooga]

Recent events have led me to change my mind somewhat about this issue.

I would like to propose a compromise. Instead of developing a system that influences the OODA cycle for all proficiency levels in some complicated way, just take the current "Novice" proficiency and make it way, way worse than the others (say, 15 or 30 or 100, or whatever times 'Regular') to represent a poor-performing unit (for whatever reason).

Advantages:

-It's a really minimal change, and perhaps at the database level (?)
-Scenario designers have an easy way to model a poor-performing unit using existing Lua, variables, Scenario Editor GUI, etc.
-Preserves the spirit of existing scenarios. In the uncommon event that the scenario designer bothered to set the unit proficiency to "Novice," their intent was already to get the worst performance possible.

As it is, under most circumstances, I don't think there is much of a practical difference between a 'Novice' at 16 seconds targeting OODA and an Ace at '6,' anyway.

[thewood1]

You can also just set the unit to blind until a unit or weapon enters a certain point or a weapon hits. That way, you get that first shot in on an unready unit/side and then just remove the blind condition.

[boogabooga]

You can also just set the unit to blind until a unit or weapon enters a certain point or a weapon hits. That way, you get that first shot in on an unready unit/side and then just remove the blind condition.

Can you set a unit to blind without setting the whole side?

[thewood1]

Good question. I don't know, but I think you can. I assume you can check the scenario editor.

Edit: You can do it through lua through a unit.AI_evaluatetargets function. I played around with it a couple years ago and know I got it to work in an isolated test. But nothing beyond that. I suspect you can also do it through events switching sides. A unit is on one side blinded until attacked and then comes into the main side.

https://www.matrixgames.com/forums/view ... 7#p4535607

[BDukes]

There are a couple of these

unit.AI_DeterminePrimaryTarget_enabled = false
unit.AI_EvaluateTargets_enabled = false

Useful for sides that don't need to do any detecting as well. Improves performance.

Mike

[BDukes]

Yooper has been demonstrating working with OODA values too.

https://weaponsrelease.com/2022/04/18/s ... the-moska/

Mike