[AWAITING FEEDBACK] performing mission outside defined mission area

[Rongor]

Hey there,
I am playing the first NI campaign mission "Opening Moves" in v1.11 SR2 B839.4.

To hunt down those nasty commie subs, I sent several MPAs on ASW-patrol missions. I defined the mission areas encircling the ambiguity areas in which the SOSUS evaluation detected the enemy contacts. I created the missions first. Then assigned them to selected MPAs later from the map by right clicking assign...

There are basically 2 MPAs available in the mission: Nimrods (DB ID 3003) and Orions (DB ID 1583).
Both aircraft have ASW Patrol Loadouts, the Nimrods have the loadout ID 2663, the Orions are loaded with ID 7347.
Both loadout IDs profiles prescribe a respectively high transit altitude, followed by 1k ft alt on station.

Now the problem, whenever I assign one of these airborne MPAs to one of the ASW patrols, the instantly drop to 1k ft and continue in that altitude to their mission area. So it takes them much longer, uses up way more fuel
I have to set the altitude manually to keep them transiting at an optimum (high) altitude. I then only have to react again upon noticing they reached their mission zone.

Of course I could/will define the station altitude in the mission editor, but this won't work perfectly for the transit altitude when assigning different types of a/c (alike in this mission, we have Nimrods regularly transiting @ 36k ft and Orions @ 25k ft) to the same mission at the same time. And of course, it may cause problems if those missions are created for the AI side, taking a while for scenario creators to notice this problem.

I didn't post this into the NI subforum because I didn't deem the described problem as bound to that campaign.

Was there some data mix up for MPAs some time in the past? We had that similar issue with the MPA loadouts some days ago with the Turkish CN-235 and ATR72 and I remember I reported P-8 Poseidons suffering from this sometime last year or so.

Thank you!

[Rongor]

Wanted to add that I just tried helping the MPAs by entering transit and station altitudes into the mission editor. This didn't work, they still drop down to 1k ft. So apparently regarding the altitude they are currently unable to notice that they didn't reach station yet.

[mikmykWS]

Looks like this only happens if there is a sub detected in the patrol zone fo the mission and the aircraft goes engaged offensive which in many cases is the right behavior as you want the aircraft to drop on the first pass. Obviously if you assign an aircraft to this mission that's a 1000 miles away that's a problem. Added to our list. For now you can get around it by not assigning aircraft great distances away.

Mike

[Rongor]

Hi, me again. Just wanted to add another save. While you were correct with this issue connecting to engaged offensive, I just stumbled over one case of "on plotted course (airborne)" and still disregarding speed/alt setting, dropping to station altitude instantly.

It is the VP-26 Dragons #6, assigned to "ASW patrol" (smart naming right?) between Greenland and Jan Mayen Island.

[mikmykWS]

Ok thanks noted

Mike

[ComDev]

Okay some notes:

Save #1: If you want to have some control over when aircraft go to attack speed/altitude, you can use the Attack Distance field in the Mission Editor.

Save #2: VP-26 Dragons #6 drops to 25k ft which is the loadout's patrol altitude? Which speems right? It then drops to 1k ft when closer to the patrol zone.

Which seems about right?

[Rongor]

Hey Emsoy, thanks for looking into this.

Save #1 Tried that, didn't work.
Still, as Mike indicated, they go "engaged, offensive" instantly, in case that enemy contact symbol is within the defined patrol zone of the mission.
I unassigned the units, edited the mission by entering 10 NM manually as attack distance. Reassigned the mission, my units outright returned into "engaged, offensive" state.

Manually entering the attack distance in the mission editor would be nothing as a workaround, as I will try to establish in the following, that the problem is somewhat different:
Maybe I interpret the intention of the mission editor wrong, but if I have large ambiguity zones like in this scenario, of course I will define (several) ASW patrols covering these exact areas, as these red outlined zones are the areas in which I will very likely find the easter eggs. The problem kicks in when one of the patrol zones contains that red contact symbol. Then the patrol zone is disregarded completely for that mission and instead the whole dimension of that SOSUS ambiguity zone is "acting" as the new patrol zone. Since the contact symbol is in fact nothing but a place holder, to show me which type of contact can be assumed somewhere within that rather huge ambiguity zone, it should not serve as a trigger to replace the defined patrol zone of the mission editor with that ambiguity zone.
As explained in the other report, if that ambiguity zone extends across land, it even triggered my ASW patrol to engage there... (wasting time and fuel and of course doing total nonsense)

This contact symbol doesn't display the actual location of the target, so it shouldn't trigger "engaged offensive" and it shouldn't trigger "station behavior" when my unit is still on the transit leg on it's way to the patrol zone, which actually is the only area I defined "station". I hope I explained it better this time.[:)]

Save #2 yep, seems to work now. Not sure if some fix included in SR3 B839.5 also fixed that. Will keep my eyes open for this one and report again in case I see it another time. The assigned #6 now follows the mission profile, BUT only as long the defined mission patrol zone doesn't include the enemy contact symbol (as elaborated with save #1).

[ComDev]

Thanks for your feedback Rongor, please give SR4 a spin as soon as it is out. Have made various minor improvements here-and-there.