Mission craft attacking other unarmed craft

[rsharp@advancedgamin]

The issue is as follows:
Craft assigned to missions, and in general, do not attack unarmed craft identified as hostile. The game engine does not assign any threat to the unarmed craft and will not engage them. This is meant to let the game controlled units more lethal by ordering their priority of engagement.

The workaround suggested by many:
Assign a practically harmless weapon capabale versus any craft. The game engine should now assign a threat.

The problem:
Not everyone believes the workaround is the proper solution.


The purpose of this thread is to collect user opinions on the issue, the pros and cons of the workaround, and possible solutions. Please start with the first two. User contributions will lead to action taken and possibly help design any further game engine changes.

Thanks and please keep it technical,

[noxious]

The problem is when a platform controlled by the AI doesn't fire on imint or elint units, right ?
And that scen authors want control back, right ? So, an AI flag per platform, accessible through scenario editing which will attack unarmed recon units (or even all unarmed units), or use default Game engine behaviour if not set.
So, if the flag is set, the AI will attack unarmed platforms according to the threat picture at that moment, and if that platform is the only one in range, it should be dealt in a way similar to past behaviour
If the flag is not set, all is well and happening as currently does in the Game engine, with unarmed platforms being ignored.
This is a much better option than the workaround for db authors, as it's an unified approach, and gives an interesting tool to scenario authors.
It's also relatively trivial to implement, insofar as adding to a existing codebase can be.
Certainly not an enormous endeavour, far from it : given access to the source, I'd do it.

[FreekS]

ORIGINAL: rsharp@advancedgamin
This is meant to let the game controlled units more lethal by ordering their priority of engagement.

Russell,

I have seen no evidence that 3.9 ANW AI is ever more lethal than the 3.6 counterpart!

I see how by assigning 'threat-values' the AI *might* be focused more on high-threats but:
a. The objective of the AI is NOT to kill the most threatening units of the player. Rather it is to kill those units that are most likely to make achieving the Vicconds for the player harder. These are not nexessarily the same as the most threatening units. Often they wil be merchants in convoy or recce planes.
b. The AI should always prevent players Recce planes from tracking him. Recce-planes are THE most threatening unit to any commander. A sub attacking a convoy should ALWAYS aim at the High-Value-Units not the higher threatening escorts. Thats simple doctrine; if a sub gives away his position by attacking escorts he does not fulfill his mission.

Now maybe it is because I mostly assign detailed missions to all units in scens I build, but I have yet to see a scenario where the AI has become more agressive through the use of threat values. I'd really like a comparative description like the one Ralph put up that shows a situation where the new AI logic works better.

So I seriously question the value of the logic of the threat-values.

Now IF the threat-value logic has any value, and the only unintended consequence has been that unarmed units are not attacked; then:
1. why ask the DB designers to add a phantom non-functioning weapon to ALL platforms instead of just modifying the threat-values?
2. why not set the example with the canned DBs that come with the game? They suffer from exactly the same issue.

Now I could go along with noxious suggestion for a 'Flag' in the SE; however be aware that in spite of the great new features of the ANW SE (such as copying of units), I still do not use it to design scens as its not possible to make and maintain threat-zones in the ANW SE (they will always revert back to the square around the refpoints). That is an enormous limitation.

Freek

[hermanhum]

ORIGINAL: Noxious
The problem is when a platform controlled by the AI doesn't fire on imint or elint units, right ?
And that scen authors want control back, right ? So, an AI flag per platform, accessible through scenario editing which will attack unarmed recon units (or even all unarmed units), or use default Game engine behaviour if not set.

I believe that is a drastic oversimplification of the problem. The problem is not limited to ELint, AEW, IMint units, nor is it limited to armed/unarmed units. It affects all units; targets and strike elements alike. The problem affects both scenario authors and regular players (via the H3ANW Auto-Defense Behavior).

Also, such an AI flag is probably not likely available through scenario editing since not all units within a scenario are directly inserted onto the map. For example, ships, subs, and facilities are inserted into a scenario and this might be possible for them, but planes are generally 'created' every time they are launched.

ORIGINAL: Noxious
It's also relatively trivial to implement, insofar as adding to a existing codebase can be.
Certainly not an enormous endeavour, far from it : given access to the source, I'd do it.

ROFL. [:D] Famous last words. I bet that AGSI had the same thought when they tried to implement this aValue disaster. "Gee, that should be a simple addition that will improve the game without any serious side effects...." There are just a ton of problems on the * Known Harpoon [ANW] Issues created by seemingly innocuous fixes to other problems. Let me know if you want to see the specific examples.

[hermanhum]

ORIGINAL: rsharp@advancedgamin
The issue is as follows:
Craft assigned to missions, and in general, do not attack unarmed craft identified as hostile. The game engine does not assign any threat to the unarmed craft and will not engage them. This is meant to let the game controlled units more lethal by ordering their priority of engagement.

The issue, as it is currenly defined, is far too narrow. IMO, the issue is much broader and encompasses every unit type (sub, ship, facility, and plane) and how it interacts with every other unit type regardless if it is assigned or unassigned to any mission.

Also, the issue affects armed units as well as unarmed units. The decisive factor is whether or not the unit 'poses a threat' to another unit. For example, unarmed units can penetrate a CVBG that is on a Transit mission because they are not deemed a threat to the ships. However, units armed with only anti-submarine/air-to-air/air-to-ground weapons will ALSO not be classified a threat and thus will be ignored by the defenses.

I feel that the proposed work-around solution to arm all platforms with a Generic Weapon so that they present a theoretical threat to all other units will work in only one circumstance. Only if the unit is never armed (i.e. E-3 Sentry, airliner, cruise ship, office building, whale, etc) and is NEVER assigned to a combat mission (strike or combat patrol) does it have a chance of working. Unfortunately, most units do not fall into this category.

Perhaps the best way to show the folly of this proposed work-around is to run through examples of how it will likely fail.

1) All units can become unarmed units. If a unit fires off all of its weapons, it is now considered 'unarmed' and not a threat to any other unit. This can happen for land units, ships, subs, and aircraft.

2) Units can become unarmed intentionally or unintentionally.

a) A player or scen designer can deliberately order aircraft to Minimal loadout and thus become 'unarmed' and then use them as indestructible reconnaissance assets.

b) Units can also become accidentally/unintentionally unarmed by firing off all their available weapons. Also, planes can unintentionally become unarmed due to database changes. See Wrong loadout descriptions

3) Because all units can become unarmed and non-threatening, the Generic Weapon must be added to every single ship/sub/plane/facility in the database. A major problem appears for units that sometimes carry weapons. If a unit (usually a plane) is armed with the Generic Weapon (along with other weapons) and then assigned to a Strike mission, it will fire all the normal weapons and then continue to close on the target in an attempt to launch the Generic Weapon. This will most likely result in the destruction of the unit. The correct behaviour would be for it to retire once all normal weapons are fired.

4) Creation of a Generic Weapon that is actually 'fired' so that units on strike do not attempt to close on a target will not work since all weapons have different stand-off delivery ranges. Also, once fired, the unit, again, becomes unarmed and non-threatening thereby defeating the purpose of the Generic Weapon in the first place.

ORIGINAL: FreekS

1. why ask the DB designers to add a phantom non-functioning weapon to ALL platforms instead of just modifying the threat-values?
2. why not set the example with the canned DBs that come with the game? They suffer from exactly the same issue.

Now I could go along with noxious suggestion for a 'Flag' in the SE; however be aware that in spite of the great new features of the ANW SE (such as copying of units), I still do not use it to design scens as its not possible to make and maintain threat-zones in the ANW SE (they will always revert back to the square around the refpoints). That is an enormous limitation.

This suggestion to simply have the game assign "threat-value" to all platforms would probably solve the problem, but how is this different from the original H2/H3 behaviour in the first place? It certainly appears to be running around in circles to arrive at the same solution that was already being used in H2/H3. Not only that, this aValue problem has already rendered the Weapons Tight function useless (see H3ANW Auto-Defense Behavior)

Both Noxious and Freek have suggested a 'flag' to make use of the aValue behaviour. This may be the wisest choice. The default (non-flag) should be the former H3 behaviour -- All hostile units are attacked by any available weapon (with the one known specific strike exception). Only if an ANW user wants the new aValue behaviour, should he enable it from within the Mission Menu window. This way, all the old scenarios are preserved by the default behaviour. And, if aValues continues to be an unworkable mess, then it can easily be ignored by this process until it is deemed worthwhile by the individual user.

[Shemar]

I don't think a flag is the ideal solution as it means all existing scenarios have to go back and get re-designed. Not to mention that it also changes the data structures. I believe the ideal solution would be to better evaluate the threat potential of each unit. So my suggestion is:
 
a. Assign threat values to sensors, in addition to weapons.
b. Assign threat values to air facilities.
c. The threat value that each unit should take into consideration is not the threat value against that specific unit only, but the threat value towards any friendly unit within the operational range of the potential target.

[jpkoester1]

I would like to vote for restoring the previous behaviour. AI shoots at every unit that is identified as belonging to a side that the AI is hostile to. Using the focussed strike flag and weapons free/weapons tight can take care of those situations where this is not wanted.

Cheers,
JP

[hermanhum]

Not that I am a big proponent of "flags", but I think that the proposed solution was:

Default behaviour = Previous (functional) H3 behaviour. New flag is only for enablement of new ANW behaviour.

This seems to have worked somewhat for the new Focused Strike feature. It was introduced in ANW and can only be enabled when the box is selected in the ANW Mission Menu window. Therefore, all pre-existing scenarios use the default H3 behaviour. Unfortunately, this is not standard operating procedure for the introduction of new ANW functions. [:(]

A deeper look at the aValues leads me to believe that they may be grossly oversimplified. It does seem as though the only requirement to be considered a valid threat is for the relevant aValue to be > 0. This means that a B-52 flying at high altitude over a Stinger team with an AAW aValue of 8 (and unable to hit the bomber because it is limited to low altitude targets) is going to bomb the crap out of the Stinger team the same way it would if it was flying over a more lethal Patriot battery (AAW aValue 42 and capable vs. high altitude targets) simply because the AI evaluates both as threats.

In the PlayersDB, an FIM-92A Stinger has an AAW aValue of 8 while an FIM-92D Stinger has a value of 12. The only difference between the two weapons is an increased Probability of Kill (PoK). However, if a B-52 is flying over them at high altitude, the aValues should probably be 0 since the bomber cannot be engaged by them and is thus impervious.

I think that many things should be considered when evaluating threats. Things like the radar strength, PoK, altitude limitations, weapon speed, range, climb rate, resistance to jamming, weapon guidance (self-guided vs. ground control), etc, etc, etc. To boil all this down into one value seems silly and probably out of the realm of possibility for Harpoon especially since much of it is according to personal preference. For example, a Stinger might be more lethal than an SA-2 for low altitude targets, but does this justify a higher aValue rating for the SA-2 simply because it has a low PoK against higher altitude targets? If an EF-111 Raven jammer is available in the scenario and can degrade the SA-2 radar to nothingness, then shouldn't the Stinger have the higher rating since it is unaffected by ECM jamming? These are all personal judgment factors and the "one value fits all" aValue does not seem to make any distinctions.

I seem to remember an old book where a man asked God the meaning to life and His reply was, "17". [:D]

[rsharp@advancedgamin]

That's good feedback and, of course, I'll still take more. I feel like I've got the majority of the opinions out there.

So far I like Shemar's suggestion the best. It builds on the existing feature incrementally and moving forward is the better alternative given how much code has been changed.

I like the flag idea as that would give more control to the user. That's usually a good thing.

Herman's suggestion of using more detailed weapon's capabilities would also build on the feature and most likely an improvment. However, it would be too CPU intensive given that the values would update periodically or on unit movement.

However, all three constitute new features and that's out of the scope of 3.9.x. I do believe we'll revist the ideas in the future. Indeed a feature offering target priorities based on platform class may work within mission parameters. I'd also like to include a feature where platforms matching a VC item will be given a priority bonus. That would only be as strong as the underlying logic to act on that priority.

My first step in addressing the problem will be to take off the test for a threat value greater than 0. I doubt this will give us the exact behavior of 3.6.3 but that's not my goal anyway. I'll make this change in a 3.9.4 beta and get feedback from our beta testers, some of whom are involved in this discussion. Any further change will be based on that feedback.

I'm not done reading this thread and I think there are a few features we will attack in this manner. Reaching a loose consensus and brainstorming for new ideas in a focused discussion is helping everyone.

[FreekS]

ORIGINAL: hermanhum

I seem to remember an old book where a man asked God the meaning to life and His reply was, "17". [:D]

It was 42 (the answer to God, Life and the Universe IIRC)

[FreekS]

So the verdict is that we're going to change the aValue logic and change all preexisting scens again?
 
What I've read and would make sense is:
- shoot at verything thats hostile and in range as default
- make a flag that when set, will drive the AI to the smarter behaviour (currently letting all Recce planes pass).
 
Please do not again break all existing scens!
 
From a poor scen-designer
 
Freek

[rsharp@advancedgamin]

You just described two changes that would change behavior in most of the scenarios. Please do not hyperventilate. We will proceed cautiously.

[Shemar]

My understanding of Russell's post is that the only immediate action would be to remove the "do not fire if the A value is 0", which means that the main issue of the AI not firing on unarmed units will be resolved.

[FreekS]

Sorry Russell,
 
But if you implemented the first one; effectively stay with the 3.6 logic unless flag is set, then I can (at least for this behaviour) trust that my scens will work as intended.
 
I'm not at all saying stay with 3.6 forever, but I'm glad you will proceed cautiously.
 
Freek

[hermanhum]

Just to be clear, I'm not asking for any new feature or any change in how the aValue makes threat calculations. I only mentioned the factors that would likely be relevant for any future aValue threat evaluation. In fact, I hope that any more changes for aValue-related functions will be not be included until The Next Harpoon version so that ANW doesn't keep breaking down because of this lousy logic. I just want a working version of the game I already paid for and not some constantly shifting, never finished, pie-in-the-sky.

ORIGINAL: rsharp@advancedgamin
I'd also like to include a feature where platforms matching a VC item will be given a priority bonus.

I know that this is only a conceptual idea at the moment, but I will take this opportunity to point out where it can end up as a potentially bad idea.

Here is a simple example to illustrate the point:

A scen has 2 playable sides ("A" and "1").
Each side has two bases (A1, A2, 1A, 1B).
Each side has the same 2 ViConds.

a) Protect one base from destruction b) Destroy 2 enemy bases

Each side has all the assets set to attack ONE (and only one) base from the other side. This is done to increase the difficulty of the human defender. When the scenario is played in solitaire from either side, the AI will concentrate all efforts at destroying one of the player's bases. The AI does not care what the ViConds are for it's side. It's only concern is to deny the player his ViConds.

Here is where the potential difficulty lies:

The Strike mission is against only one base in order to increase its chances of accomplishment and thus denying me my ViConds. When I play the scenario and the AI launches all it's assets against me, I don't want the AI to suddenly divide its fire between the two bases just because they happen to be in range of its weapons and because the AI side has ViConds (that it will ignore) set to destroy both bases.

Now, if that is not the intent of what has been suggested for the "Matching ViCond Item Priority Bonus", that would be fine. I just wish to re-iterate that it is never a good idea to circumvent the intent of the scenario author. They write things in a certain way. Game engine changes should not abrogate their work.

[rsharp@advancedgamin]

Thanks but let's focus back on the immediate issue and potential changes covered in this thread.

Shemar is correct in that unarmed units would be engaged with the change. But as Herman pointed out, threat values are relative to the detecting unit. A sub is threatened by ASW aircraft and not fighters on air patrol because of their loadout. These could also possibly be engaged by that detecting unit. I say possibly because there are other factors such as what sort of patrol they are on and the current ROE.

Simply going back to 3.6.x behavior is not an option at this point. The mission code does not suffer such changes well and we risk breaking any scenarios made for 3.7+. We will make this change and not suppose what the effect will be but test the actual results.

[noxious]

ORIGINAL: Noxious
It's also relatively trivial to implement, insofar as adding to a existing codebase can be.
Certainly not an enormous endeavour, far from it : given access to the source, I'd do it.



ROFL. Famous last words. I bet that AGSI had the same thought when they tried to implement this aValue disaster. "Gee, that should be a simple addition that will improve the game without any serious side effects...." There are just a ton of problems on the * Known Harpoon [ANW] Issues created by seemingly innocuous fixes to other problems. Let me know if you want to see the specific examples.

Glad someone picked up on the humour, hehehe. I was of course joking (after all, I do know code, particularly game code) about it being pretty trivial : nothing is trivial with a complicated, legacy codebase that was created for DOS
But it allowed me to voice, yet again, my interest in helping out sourcecode wise, if the opportunity arises.
And someone had to break the ice (arumph, hehe)

[Anonymous]

Hello Russel,

ORIGINAL: rsharp@advancedgamin

[...]

The purpose of this thread is to collect user opinions on the issue, the pros and cons of the workaround, and possible solutions. Please start with the first two. User contributions will lead to action taken and possibly help design any further game engine changes.

Thanks and please keep it technical,

Ok, my opinion on this issue is well known since my beta tester time.

Attached is a screenshot to demonstrate what I am talking about.

Two Foxbats are loitering right over the US carrier group and radioing its position to the approaching Oscar class SSGN (from the East) and the bombers (from the South). No one attacking them - totally unrealistic ! There is simply no need to discuss that aspect.

The game has just started and it will not last for long.

In fact the Oscar did the job all by itself - sinking both carriers with Shipwreck salvos from about 70nm due to its perfect target solutions delivered by the brave Foxbats.

So the whole scen is no challenge playing it red side.

Under H3 3.6.2 (just playing the scen under that game engine) it is like a good game of chess: Since I know (learned that lesson the hard way back with H2 which in most aspects behaved similiar to H3 3.6.X) the AI will shoot my recce birds I move them carefully "over the board" in order to surround his carrier group; finally detect it and get good target solutions. This needs a lot pf patience; especially since the Russians are badly outgunned and cannot afford even one failed attack. Thus it is a real challenge this way. And yes, I´ve already lost some birds on the ground due to Tomahawk waves, but that´s the second issue...

That´s why I clearly prefer the "classical" behaviour.

[hermanhum]

ORIGINAL: noxious

But it allowed me to voice, yet again, my interest in helping out sourcecode wise, if the opportunity arises.

"Close your eyes. Don't look at it!"

Indiana Jones: Raiders of the Lost Ark

[rsharp@advancedgamin]

Sure. Send your resume to rsharp atsymbol advancedgaming.biz

There might be something you can do.