USAF career awards blocked by noAwards / AwardRemove interaction

[Arrow_1974]

Hi @Akephal — I believe there is a reproducible bug in the USAF award ladder in Korea.

Short version: the Medal of Honor, Distinguished Service Cross clusters, and Silver Star clusters can become effectively unobtainable in a normal American career after the first few missions. This reproduces with the shipped scg/2/Awards.cfg, with no mods installed.

The affected awards

Nine USAF award entries gate AwardInProc on (noAwards=1):

• 601018–601020 — Silver Star and its clusters

• 601021–601025 — Distinguished Service Cross and its clusters

• 601026 — Medal of Honor

Seven of these have AwardByDef="(RND<0)", so AwardInProc is their only possible route.

Only 601018 and 601021 have a functional AwardByDef fallback in the stock configuration, which is the 10% roll during the daily award sweep.

What appears to be happening

When a higher rung of an award ladder is granted, AwardRemove sets isDeleted = 1 on the superseded lower rung.

The per-pilot award loader uses:

SELECT * from award WHERE pilotId=%d %s ORDER BY earnedDate

with %s receiving:

and isDeleted=0

That means a superseded award is no longer present in the list used by subsequent award checks.

The engine therefore no longer sees the lower rung as already held.

If its cumulative condition is still true, the lower rung can be awarded again on a later sortie. That re-grant sets:

noAwards = 0

and AwardRemove immediately retires the award again.

The re-grant does not appear in the event table because it is removed before the award event is written, but it is visible in _career.log. For example:

[INFO] Earned award for Pilot:20 Type:601018
[INFO] Award TYPE:601018 removed of award TYPE:601020

Why this affects essentially every USAF career

The Air Medal ladder appears earlier in Awards.cfg and begins retiring previous rungs with 601003.

Its base condition is cumulative:

(AirObj>=1)|(ComplSorties>=5)|...

Once the pilot has earned the second Air Medal rung, 601002 has been marked deleted.

On subsequent sorties the base Air Medal can therefore satisfy its condition again, be re-granted, and set:

noAwards = 0

before evaluation reaches the Silver Star / DSC / Medal of Honor entries later in the file.

The result is that, from roughly the fifth mission onward:

• the Medal of Honor cannot normally fire through AwardInProc;

• the six Silver Star / DSC cluster rungs cannot normally fire through AwardInProc;

• the base Silver Star and DSC are effectively left with only their 10% AwardByDef daily-roll fallback.

Reproduction

I reproduced this with a USAF pilot flying a sortie with three clean airborne victories, with no competing award expected.

601019 did not fire.

Removing only:

&(noAwards=1)

from the affected conditions caused the award ladder to behave normally.

There appears to be a second, separate issue

The stock Silver Star / DSC / Medal of Honor conditions overlap rather than forming exclusive bands.

The ladders effectively use:

Silver Star: AirObjSortie >= 2
DSC:         AirObjSortie >= 4
MoH:         AirObjSortie >= 6

Because the Silver Star entries occur first, a six-victory sortie also satisfies the Silver Star condition.

The Silver Star therefore takes noAwards first and suppresses the DSC and Medal of Honor later in the same evaluation.

This can happen even in a fresh career before any award has been superseded: a pilot's first six-victory sortie can produce a Silver Star instead of the Medal of Honor.

This banding issue is separate from the deleted-award problem above and could be corrected in Awards.cfg once noAwards is functioning as intended.

Possible underlying fix

The root problem appears to be that isDeleted is being used for two different concepts:

1. this award record no longer exists; and

2. this award has been superseded by a higher rung and should no longer be displayed.

A possible fix would be to preserve superseded award records for award-eligibility purposes while hiding them only from the displayed ribbon/medal set.

For example:

supersededBy = <higher award id>

instead of setting:

isDeleted = 1

for AwardRemove.

Then:

• the "already held" check can continue to see superseded awards;

• the ribbon/medal display can filter on supersededBy IS NULL;

• cumulative lower rungs will not be repeatedly re-granted;

• noAwards will no longer be consumed by phantom awards.

Obviously the implementation may have a simpler internal solution; this is just one possible way of separating the two states.

Other nations

The Soviet and DPRK ladders do not appear to suffer from the same failure mode.

Their use of noAwards is generally an OR path rather than a mandatory gate, and the relevant awards do not use AwardRemove in the same way.

One unrelated Awards.cfg issue

OpSuccess is documented in the variable legend at the bottom of Awards.cfg, but it does not appear to be registered as an available condition variable.

Conditions using OpSuccess therefore evaluate as zero and never fire.

OpGood appears to be the functioning variable for successful operations.

I can provide the affected career save, _career.log, database rows, modified test configuration, and exact code offsets if useful.