erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

feat(net,runtime): Campaign CC CC2 — CharacterCreate wire, 0xF643 correlation, creation status events

Browse source 
Wire (Core.Net):
- CharacterCreate.cs: outbound 0xF656 builder, byte-exact port of
  Proto_UI::SendCharGenResult@0x00546a70 -> ACCharGenResult::Pack@0x005c7570
  -> CG_Pack@0x005c7200. Account String16L first (packed outside CG_Pack),
  then the constant-1 u32, heritage/gender, 14 appearance strip/style/color
  u32s, 6 f64 shades (skin/hair/headgear/shirt/trousers/footwear, retail
  order), template, 6 attributes, slot, classId, numSkills + exactly 55
  u32 skill-advancement classes (ReadOnlySpan validated ==55, throws
  ArgumentException otherwise — ACE terminates the session on any other
  count via PlayerFactory.CreateResult.ClientServerSkillsMismatch), name
  String16L, startArea, isAdmin, isEnvoy, and a trailing checksum whose
  exact 19-term accumulation set (heritage+gender+3 strips+hairColor+
  eyeColor+hairStyle+headgearStyle+shirtStyle+trousersStyle+footwearStyle+
  template+6 attributes) is read byte-for-byte off CG_Pack's decompiled
  accumulator (0x005c7213-0x005c74c3) — headgearColor/shirtColor/
  trousersColor/footwearColor/shades/slot/classId are deliberately absent
  from the sum despite sitting adjacent on the wire. Cross-checked against
  ACE's CharacterCreateInfo.Unpack/Appearance.Unpack and holtburger's
  CharacterCreateRequestData (types.rs:236-369), which agree on every
  field and order. Retail routes via SendToLogon — the same queue
  CharacterDelete already uses.
- CharGenVerificationResponse.cs (new): promotes the shared 0xF643 parse
  out of CharacterRestore — full Code enum (Undef..AdminPrivilegeDenied=7,
  ACE's CharacterGenerationVerificationResponse) plus the conditional
  Ok-only identity payload (guid/String16L name/u32 secondsGreyedOut).
  CharacterRestore.Parse now delegates to it; CharacterRestore's public
  Parsed shape, Parse signature, and every existing test expectation are
  UNCHANGED.
- PacketWriter.WriteDouble: f64 little-endian helper for the shade fields.

WorldSession dispatch (Core.Net):
- Added an awaiting-request latch (None/Restore/Create), armed by
  SendRestoreCharacter/the new SendCharacterCreation immediately before
  each send (SendCharacterCreation builds the body first so a skill-count
  throw never arms the latch for a request that was never sent), cleared
  the instant a matching 0xF643 is dispatched (success OR parse failure —
  a malformed reply must never wedge the latch open) and on Dispose.
  0xF643 now routes to CharacterRestoreReceived or the new
  CharacterCreateResponseReceived (Action<CharGenVerificationResponse.Parsed>)
  by that latch; an unexpected 0xF643 with nothing outstanding logs once
  and is dropped, never misattributed. Fixed
  WorldSessionCharacterSelectionTests' restore-dispatch test, which
  previously fed a bare CharacterRestore response with no preceding
  SendRestoreCharacter — that shape is now the "no outstanding request"
  drop path by design.

Status events (Runtime + Launcher.Core, contract first):
- Amended docs/plans/2026-08-14-launcher-campaign.md §LA1's pinned status
  vocabulary to add characterCreated{guid,name} (Ok reply identity, named
  to mirror CharGenVerificationResponse's own fields and to read distinct
  from enteredWorld — retail logs a freshly created character straight in
  without a fresh characterList) and creationFailed{code,name} (raw Code
  value + its enum member name).
- SessionStatusWriter.CharacterCreated/CreationFailed implement that
  contract.
- Launcher.Core: CharacterCreatedStatusEvent/CreationFailedStatusEvent +
  StatusEventParser cases, in lockstep.

Tests: CharacterCreateTests (byte-exact layout incl. checksum term-set,
55-slot fixture, wrong-count throws), CharGenVerificationResponseTests
(every Code value), WorldSessionCharacterCreationTests (create-then-
response routes correctly, restore unaffected, no-outstanding drop,
second-response-after-consumed drop, Dispose clears the latch, a builder
throw never arms it), SessionStatusWriterTests + Launcher.Core
StatusEventParserTests/StatusFileTailerTests (pinned shape + tailer
round-trip) for the two new events.

Verified: dotnet build AcDream.slnx -c Release — 0 errors. Full solution
test run green (Core.Net.Tests 993/993, Runtime.Tests 1667/1667,
Launcher.Core.Tests 323/323, plus every other project in the solution).
WSL Ubuntu: Core.Net.Tests 993/993, Runtime.Tests 1667/1667.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-15 12:49:52 +02:00
parent ee80138fba
commit 5eaad2c88c
16 changed files with 1548 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

138
src/AcDream.Core.Net/WorldSession.cs
View file

@ -598,6 +598,16 @@ public sealed class WorldSession : IDisposable
public event Action<CharacterList.Parsed>? CharacterListReceived;
public event Action? CharacterDeleteAcknowledged;
public event Action<CharacterRestore.Parsed>? CharacterRestoreReceived;
/// <summary>
/// Campaign CC CC2: fires when a <c>0xF643</c>
/// (<see cref="CharGenVerificationResponse"/>) response arrives while
/// this session's awaiting-request latch says <c>Create</c> — i.e. the
/// reply to <see cref="SendCharacterCreation"/>. See
/// <see cref="CharGenVerificationResponse"/>'s doc comment for the
/// opcode collision with <see cref="CharacterRestoreReceived"/> and how
/// the two are disambiguated.
/// </summary>
public event Action<CharGenVerificationResponse.Parsed>? CharacterCreateResponseReceived;
public event Action<CharacterError.Parsed>? CharacterErrorReceived;
/// <summary>
/// Campaign LA gate round 2 finding 3: ACE sends this in the same batch
@ -706,6 +716,41 @@ public sealed class WorldSession : IDisposable
public ServerName.Parsed? ServerInfo { get; private set; }
private CharacterError.Parsed? _lastCharacterSelectionError;
/// <summary>
/// Campaign CC CC2: which outbound character-generation request (if any)
/// this session is awaiting a <c>0xF643</c>
/// (<see cref="CharGenVerificationResponse"/>) reply to. Restore and
/// create requests share that opcode on the wire (see
/// <see cref="CharGenVerificationResponse"/>'s doc comment) with no
/// self-describing discriminant, so this latch is the only thing that
/// tells the dispatcher which event to fire. Set by
/// <see cref="SendRestoreCharacter"/> / <see cref="SendCharacterCreation"/>
/// immediately before the send; cleared the moment a matching 0xF643 is
/// dispatched (success OR parse failure — a malformed reply must not
/// wedge the latch open forever) and on session teardown
/// (<see cref="Dispose"/>). Read/written only from the caller's frame
/// thread — the same single-threaded invariant every other per-session
/// field here (e.g. <see cref="_lastCharacterSelectionError"/>) relies
/// on; <see cref="ProcessDatagram"/> is never invoked concurrently with
/// a send (see the class doc comment's thread-id probe note).
/// </summary>
private enum PendingCharGenVerificationRequest
{
None,
Restore,
Create,
}
private PendingCharGenVerificationRequest _pendingCharGenVerification =
PendingCharGenVerificationRequest.None;
/// <summary>
/// One-shot guard so an unexpected 0xF643 (no outstanding create/restore
/// request) logs exactly once per session rather than spamming on a
/// misbehaving or replaying server.
/// </summary>
private bool _loggedUnexpectedCharGenVerificationResponse;
private readonly IWorldSessionTransport _net;
private long _lastInboundPacketTicks = Stopwatch.GetTimestamp();
private long _lastPingRequestTicks;
@ -1823,18 +1868,56 @@ public sealed class WorldSession : IDisposable
{
CharacterDeleteAcknowledged?.Invoke();
}
else if (op == CharacterRestore.ResponseOpcode)
else if (op == CharGenVerificationResponse.ResponseOpcode)
{
CharacterRestore.Parsed parsed;
try
{
parsed = CharacterRestore.Parse(body);
}
catch
// Campaign CC CC2: this opcode is a genuine retail reuse
// between CharacterRestore and CharacterCreate responses
// (see CharGenVerificationResponse's doc comment) — the
// awaiting-request latch is the only thing that tells us
// which family a given 0xF643 belongs to. Clear it before
// parsing (not after) so a malformed reply can never leave
// the latch stuck open, awaiting a response that will now
// never come and misattributing whatever arrives next.
PendingCharGenVerificationRequest awaited = _pendingCharGenVerification;
if (awaited == PendingCharGenVerificationRequest.None)
{
if (!_loggedUnexpectedCharGenVerificationResponse)
{
_loggedUnexpectedCharGenVerificationResponse = true;
Console.Error.WriteLine(
"[session] unexpected CharacterGenerationVerificationResponse "
+ "(0xF643) with no outstanding create/restore request — dropped.");
}
continue;
}
CharacterRestoreReceived?.Invoke(parsed);
_pendingCharGenVerification = PendingCharGenVerificationRequest.None;
if (awaited == PendingCharGenVerificationRequest.Restore)
{
CharacterRestore.Parsed parsed;
try
{
parsed = CharacterRestore.Parse(body);
}
catch
{
continue;
}
CharacterRestoreReceived?.Invoke(parsed);
}
else
{
CharGenVerificationResponse.Parsed parsed;
try
{
parsed = CharGenVerificationResponse.Parse(body);
}
catch
{
continue;
}
CharacterCreateResponseReceived?.Invoke(parsed);
}
}
else if (op == CharacterError.Opcode)
{
@ -2223,9 +2306,39 @@ public sealed class WorldSession : IDisposable
/// <summary>
/// Send retail CharacterRestore through the control queue. This is
/// deliberately non-blocking because ACE silently drops unknown guids.
/// Arms the awaiting-request latch as <c>Restore</c> BEFORE the send so
/// a reply that arrives on a later Tick is never misattributed to a
/// different request (Campaign CC CC2).
/// </summary>
public void SendRestoreCharacter(uint characterId) =>
public void SendRestoreCharacter(uint characterId)
{
_pendingCharGenVerification = PendingCharGenVerificationRequest.Restore;
SendControlMessage(CharacterRestore.BuildRequestBody(characterId));
}
/// <summary>
/// Send retail CharacterCreate (opcode <c>0xF656</c>) through the
/// login/logon queue — <c>Proto_UI::SendCharGenResult</c> routes via
/// <c>SendToLogon</c>, the same queue
/// <see cref="SendDeleteCharacter"/> uses (see
/// <see cref="CharacterCreate"/>'s class doc comment). Deliberately
/// non-blocking, matching <see cref="SendRestoreCharacter"/> — ACE
/// silently drops a request whose packed account name doesn't match the
/// session's own account. Arms the awaiting-request latch as
/// <c>Create</c> BEFORE the send (Campaign CC CC2).
/// </summary>
public void SendCharacterCreation(
string accountName,
CharacterCreate.Request request,
ReadOnlySpan<uint> skillAdvancementClasses)
{
byte[] body = CharacterCreate.BuildRequestBody(
accountName,
request,
skillAdvancementClasses);
_pendingCharGenVerification = PendingCharGenVerificationRequest.Create;
SendGameMessage(body, GameMessageGroup.LoginQueue);
}
/// <summary>
/// Phase I.3: test-only hook. When non-null, <see cref="SendGameAction"/>
@ -3177,6 +3290,13 @@ public sealed class WorldSession : IDisposable
if (Interlocked.Exchange(ref _disposeStarted, 1) != 0)
return;
// Campaign CC CC2: a teardown mid-flight must not leave a stale
// Restore/Create latch behind it — this session object is never
// reused (a fresh WorldSession is constructed per connection
// attempt), but clearing here keeps the invariant "no outstanding
// request survives teardown" true rather than merely true-in-practice.
_pendingCharGenVerification = PendingCharGenVerificationRequest.None;
SessionShutdownPlan shutdown = BuildShutdownPlan(
CurrentState,
_transportNegotiated,