Name the All Asian multiplier after what it counts

The score window and the stored Contest.Multiplier1Name row both said
"Prefixes" for an Asian entrant, which counts DXCC entities.

Contest.MultiplierNames is now MultiplierNamesFor(StationInfo me), the
same shape as ExchangeFieldsFor. Every other contest returns the same
list it did before; All Asian returns "Countries" from Asia and
"Prefixes" from everywhere else. ContestDefinitions.For takes the
station as well, because that name is written to the log for N1MM.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0157i7PiZyqBkquxS9A6FTdQ
This commit is contained in:
2026-09-10 20:47:51 +00:00
co-authored by Claude Opus 5
parent f5e3d9ed8a
commit b5d9f1e21c
36 changed files with 62 additions and 40 deletions
+1 -1
View File
@@ -36,7 +36,7 @@ Notable examples: all six WAE RTTY instances matched every compared field. Field
4. **P1 — All Asian implements the wrong rules for Asian entrants.** [AllAsian.cs](../src/Nonemm.Contests/Rules/AllAsian.cs), lines 37 and 46, multiplies every Asian entrant's band points by three and always uses WPX prefixes. Reproductions: JA-to-JA on 20M scored 3 instead of 0; JA-to-UA9 scored 3 instead of 1; JA-to-K1 produced prefix `K1` instead of country `K`. Asian entrants count DXCC entities, same-entity QSOs do not score, and the threefold factor applies to non-Asian contacts. Both the local N1MM `CAA` implementation and the [2026 JARL rules](https://www.jarl.org/English/4_Library/A-4-3_Contests/aadx_eng.html) distinguish these cases. The existing tests only cover a non-Asian entrant.
**Fixed 2026-09-10.** `AllAsian` now asks which side the entrant is on. An Asian entrant cannot work its own country, is paid the band table once for Asia and three times for everywhere else, and counts DXCC entities; everybody else works Asia only and counts WPX prefixes. Maritime mobiles follow the published rule, which N1MM gets half right: a station at sea makes a valid contact with Asian stations alone, pays the Asian rate wherever it is, and never brings a multiplier. `AllAsianTests` covers both entrant sides, all four point values and every band. One cosmetic gap is left: the score window heads the column "Prefixes" for an Asian entrant as well, because `Contest.MultiplierNames` is not asked which station is entering.
**Fixed 2026-09-10.** `AllAsian` now asks which side the entrant is on. An Asian entrant cannot work its own country, is paid the band table once for Asia and three times for everywhere else, and counts DXCC entities; everybody else works Asia only and counts WPX prefixes. Maritime mobiles follow the published rule, which N1MM gets half right: a station at sea makes a valid contact with Asian stations alone, pays the Asian rate wherever it is, and never brings a multiplier. `AllAsianTests` covers both entrant sides, all four point values and every band. `Contest.MultiplierNames` became `MultiplierNamesFor(StationInfo me)`, like `ExchangeFieldsFor`, so the score window and the stored `Contest.Multiplier1Name` row both say "Countries" for an Asian entrant and "Prefixes" for everybody else.
5. **P1 — BARTG HF and Sprint are merged into one incompatible definition.** [BartgSprint.cs](../src/Nonemm.Contests/Rules/BartgSprint.cs) uses report, serial and time, and countries/areas per band, but advertises `BARTGRTTYS` and `BARTG-SPRINT`. [N1mmContestNames.cs](../src/Nonemm.Contests/N1mmContestNames.cs) also maps `BARTGSRTTY` to this class. N1MM has separate `CBARTGSpring` and `CBARTGSprint` classes. The January Sprint exchanges a serial only and counts countries/areas once across bands, as specified in the [BARTG Sprint rules](https://bartg.org.uk/wp-content/uploads/2025/05/bartg-sprint-rules-2025-v3.pdf). Split the definitions and preserve each one's identity, exchange, multiplier scope and export format. Agreement on the supplied March HF log does not validate Sprint support.