`C_EncodingUtil` is the one namespace in this family that is pure
algorithm, which is why it is built properly rather than stubbed: all
eight members, in the REAL formats. pfUI's profile sharing is the reader
and its own header names the pipeline — SerializeCBOR → CompressString
(zlib) → EncodeBase64, prefixed `!pf1!` — with the export path NOT inside
a pcall, so clicking Export raised, and the import path inside one, so it
failed silently.
A profile string is pasted between players, so a blob this client writes
has to be readable by the real one and the other way round. So: zlib
through flate2 (already the workspace's inflate for MPQ sectors and its
compressor for CMSG_AUTH_SESSION's addon block, so this adds a crate to
one more manifest and not to the build), RFC 4648 base64, RFC 8949 CBOR,
RFC 8259 JSON. Nothing invented here — the trap a hand-rolled codec falls
into is round-tripping with ITSELF while being wrong.
The decoders are written for hostile input, because a profile string
arrives pasted from a forum: every length is checked against what is
actually left, nesting is capped, the inflate output is capped at 16 MiB,
and a malformed blob answers nil rather than raising or allocating what a
crafted header asked for. Tests run the RFCs' own vectors in both
directions — including the half-float and tag forms we never write but a
real encoder may — a truncated/overlong/deep-nested set, and pfUI's whole
export/import pipeline end to end.
`C_EquipmentSet` and `C_LootHistory` are subsystems 1.12 does not have at
all, and both answer an honest nothing rather than being absent, because
pfUI builds both windows and reaches one member of each OUTSIDE its own
gate (the equipment manager's `CanUseEquipmentSets` test is one line in
one addon; the loot window's Clear button has no test at all).
What each would take is written down rather than guessed at. Equipment
sets are persistent state 1.12's wire has no concept of — a feature to
decide on, not a gap to close, and pfUI already supplies the UI. The loot
log is closer than it looks: both packets already carry what the getters
answer and `ui_loot_roll.rs` handles them, so it is a bounded list plus
three events — but the getters' tuple order is the one thing here that IS
a guess, read out of pfUI's own destructures, and building the log would
make that guess load-bearing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
7bfdefb206