Aircraft on strike mission do not attack target, apparently due to unexpected contradiction in ROE

[meltingSnowdrift]

Procedure to reproduce
Run the attached scenario as side "bbb".
The single target ship should be quickly detected by the patrol mission.
The strike mission should then launch.
If necessary, manually control the movements of the patrol aircraft to keep the target detected by radar and prevent the patrol aircraft from coming into SAM range.
Wait until an aircraft group of the strike mission comes within weapon range of the target. (You may skip to this step by loading the attached save file.)
As discussed below, aircraft groups in this state do not launch their weapons as expected.

To view relevant information in this state:
Select that aircraft group.
Click the "manual engage target" button, and set the target ship as the attack target to show the manual weapon allocation window.
Open the doctrine window of the aircraft group.
Switch the map to unit mode and open the doctrine window of a single aircraft in that aircraft group.

Expected behaviour
When aircraft groups in the strike mission come into range of the target, or perhaps when they reach the "weapon launch" waypoint, they should launch their weapons at the target.
When the user opens the manual weapon allocation window in that state, it should show that "automatic fire" is allowed or show a valid reason it is not allowed.

Actual behaviour
Aircraft groups in the strike mission do not launch any weapons. After reaching their weapon launch waypoints, they turn back and return to base.
When the user opens the manual weapon allocation window, it shows that automatic fire is not allowed because "weapon control status is WEAPONS HOLD".
Opening the doctrine window for such a group shows that its weapon control status is "TIGHT" regarding all target categories.
However, switching the map to unit mode and viewing the doctrine window of a single aircraft shows that its weapon control status is "HOLD" regarding all target categories.
This is despite me never having set WCS "HOLD" on anything throughout the process of making this mission (which is a subset of a larger mission I was trying to make).

Suspected explanation
While creating this mission, I imported the provided template for Yelizovo air base. Upon opening its doctrine window, I find that it has WCS "HOLD" in all target categories.
I suspect that this status was inherited by all individual aircraft launched in groups from that base, but not by the groups containing those aircraft.
Therefore, when aircraft are launched in groups from this base on missions with mission WCS settings other than "HOLD", the groups have the expected mission WCS but every member of those groups individually has WCS "HOLD" from the base.

Questions
Is it intended that air bases imported from the default templates have WCS "HOLD"? [Update: This does not appear to be true. See later posts in this thread.]
Is it intended that the WCS of the base is inherited by individual aircraft but not groups like this?

[thewood1]

First off, RoEs between imported units, sub-units, and sides can get confusing and sometimes wonky. Add missions containing the above and its get even worse. Add templates of units in that mix units and sub-units and it is mind-bending.

If you import a template into another group, it will adopt the groups RoEs, generally without your realizing it. I'm not even sure what happens when you overlay a mission on all of that. Its why the reset buttons were added shortly after the game's release. Because the RoE hierarchy can get confusing and easily out of synch, my practice is always use the appropriate reset button to the mission or group RoE. I am pretty sure it has to do with the how the inheritance gets read on imported templates and the sequence they are added, created, and set to missions.

In your save, I hit one of the reset buttons before the mission launch and all units fired the missiles. Is it a bug? I'm not sure if it is or isn't. I just know that when importing units, adding units, and building missions, the sequence they are all created makes a big difference on inheritance. Again, its why the reset buttons were added.

I'll point out that importing templates will almost always have a side's RoEs. If its a straight up import that's how it should work. I just tested it to make sure. You airbase's hold RoEs are a good example of checking inheritance and using the reset are important in mission building.

I'm no expert on this. I still get totally confused by multi-level inheritance all the time.

[meltingSnowdrift]

Thank you for your general clarification of how and why certain things in this game work the way they do.

In creating this mission, I never imported a template "into" any existing group; the template import was literally the first action taken when creating the mission. The aircraft affected by this issue were then added to the air base.

I admittedly do not know why the base in my mission had ROE "HOLD". I just tried, as you did, importing the same template in a blank mission, and it had default ROE. Sorry for reporting as part of the issue something which likely had an unrelated cause.

More importantly, there remains the question of whether the other unexpected behaviour I noted at the end of my original post is intended by the developers. I find it hard to understand why it may ever be intentional for the game to automatically generate a group such that every member has a different ROE from the group itself but the same ROE as each other instead of simply generating a group in which all members inherit the ROE from the group as usual.

[thewood1]

I don't know on your second point. All I know is I have double check all ROEs when creating units, groups, and missions. Because the sequence in their creation is important to inheritance. I suspect your comment on the devs' intentions is related to there being so many ways to create ROEs for so many permutations, it would just cause issues any way its done.