gromandClaude Opus 5
7bfdefb206
`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
21 lines
888 B
TOML
21 lines
888 B
TOML
[package]
|
|
name = "benilla-ui"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
license.workspace = true
|
|
description = "Engine-free WoW UI engine core: TOC and FrameXML parsing, templates, anchors, z-order"
|
|
|
|
[lints]
|
|
workspace = true
|
|
|
|
[dependencies]
|
|
roxmltree = "0.20"
|
|
# The script host's Lua 5.1; `vendored` builds it from the workspace's patched `lua-src`.
|
|
mlua = { version = "0.11", features = ["lua51", "vendored"] }
|
|
# zlib for ClassicAPI's `C_EncodingUtil.CompressString`/`DecompressString`
|
|
# (`script/compat/classic_api/encoding_util.rs`): a profile blob is pasted between players, so it
|
|
# has to be a REAL zlib stream in both directions. Already the workspace's inflate — `benilla-mpq`
|
|
# reads MPQ sectors with it and `benilla-protocol` builds `CMSG_AUTH_SESSION`'s addon block with
|
|
# its compressor — so this adds a crate to one more manifest, not to the build.
|
|
flate2 = "1.1"
|