Commit graph

3 commits

Author SHA1 Message Date
Erik
581a61ef0c feat(chat): the talk-focus menu's Tell-to / Squelch entries actually work
Both entries were deliberate no-ops — the code said so — and both showed a
static label where retail shows the selected player's NAME.

Retail builds them in gmMainChatUI::InitTalkFocusMenu @0x004CDC50 and rebuilds
their labels every time the menu opens, substituting the selection through
StringInfo::AddVariable_String (@0x004CD91C / @0x004CD982). So they now read
"Tell to Dww" / "Squelch (ignore) Dww", rebuilt on open from a live selection
provider, and grey out with nothing selected — retail arms the tell slot only
for a talkable target (SetTalkFocusEnabled(2, 1) @0x004CD9B0).

Picking "Tell to X" aims the chat bar at X. That needed one piece of plumbing:
the parser's plain-speech fallthrough returned a null target, so a line typed
under a Tell focus was dropped by the router for having no one to send to.
Parse/Submit now carry an optional default tell target for exactly that case.

"Squelch X" publishes the ALREADY-REGISTERED /squelch verb rather than
reimplementing the request — the ModifyCharacterSquelch wire builder
(CM_Communication::Event_ModifyCharacterSquelch @0x006A42D0) has been there all
along; only the menu path to it was missing.

UiMenu gains an OnOpen seam, because a menu whose Items are fixed at Bind can
only ever say "Tell to Selected". It fires before _open flips so the rebuilt
rows are measured and drawn in the same opening.

Solution builds clean; 14,480 tests pass on the standard hermetic lane filter,
0 failures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 06:23:46 +02:00
Erik
955c618013 fix: make locale-independence real, not assumed — parsing, casing, comparison
All checks were successful
CI / linux-portable (push) Successful in 3m46s
CI / windows-gate (push) Successful in 5m5s
CI / release (push) Successful in 1m56s
Follow-up to the retail-text fix. "Green under sv-SE" is not the same as "runs
on any locale", so this establishes the latter by running the suite under
cultures chosen to break different things, and fixing what they broke.

ar-SA found a genuine defect the Swedish runner cannot see: the resolution
parser read "1920x-1" through the ambient culture, and ar-SA's negative sign is
not ASCII '-', so the parse failed and the height silently became 0 instead of
-1. Both copies of that parser (App settings targets and the UI settings store)
now parse invariantly.

Audited every remaining culture-sensitive operation in src/ rather than fixing
only what a test happened to catch:

- Numeric Parse/TryParse with no IFormatProvider: 11 sites, all reading
  MACHINE-readable input — env vars (ACDREAM_LIGHT_DEBUG, ACDREAM_NET_DROP_*,
  streaming/quality knobs), CLI arguments, "1920x1080" settings keys, a chat
  command's price argument, and the launcher's bake thread count, which is
  handed straight to a child process command line. All pinned to
  InvariantCulture.
- ToUpper()/ToLower() with no culture: none. The Turkish-I class was already
  clean, and tr-TR confirms it.
- StartsWith/EndsWith/IndexOf(string) with no StringComparison: one —
  ChatInputParser's "@" prefix test, which is a culture-sensitive comparison
  for a single ASCII character. Now the ordinal char overload.

Verified: 13,958 tests pass identically under the machine default, sv-SE,
tr-TR, ar-SA, and de-DE. (The two launcher test assemblies are excluded from
this run only because a running acdream-launcher.exe holds its own binary; the
one launcher change here is the thread-count parse.)

Dates remain on the current culture by intent, unchanged from the previous
commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 20:11:32 +02:00
Erik
41b15efd4d feat(runtime): share chat commands and run login sequence 2026-08-14 20:27:45 +02:00
Renamed from src/AcDream.UI.Abstractions/Panels/Chat/ChatInputParser.cs (Browse further)