The decode window after a visitor call leaks the next option's arithmetic

Crate: tools/minecraft-options

Commit: 2b2af1e4f8166d02e4732d19e040a53745d97a51

Behavior

extract_visitor takes post = insns[i+1:i+14], a fixed window of 13 instructions after the call, and arithmetic_chain scans it for any <const> <arith-op> pair without regard to statement boundaries. In 1.17, 1.17.1, 1.18, 1.18.1, and 1.18.2, mouseSensitivity is recorded with storage_to_value (((file - 70) / 40) * 40), which is the following fov statement's arithmetic. build_setting emits ui_to_file_transform with confidence: high whenever either direction is set, and value_to_storage is null, so the record describes a one-sided transform on a plain double.

arithmetic_chain also drops the left-constant form (1.0 - x), nested sub-expressions, and constants separated from the opcode by a conversion. An unreadable transform on the field_access path then looks like "no transform" (only the xmap path has a guard).

Expected behavior

The window stops at the first putfield, and an expression the chain cannot fully read is reported unresolved, not as an empty or partial transform.

Impact

The committed dataset is unaffected because dataset.py reads only value_to_storage, but normalized data, reports, and compatibility output state a false high-confidence transform, and a left-constant transform such as 70 - x would be treated as stored as-is.

Locations

• tools/minecraft-options/analyze_options.py extract_visitor (1080-1101), arithmetic_chain (369-377)
• tools/minecraft-options/analyze_options.py build_setting (2136-2139)

Validation and limitations

Scan of all cached raw records: only fov (correct, all releases) and these five mouseSensitivity records have any transform. arithmetic_chain([dconst_1, dload_0, dsub]) returns [] in a scratch script.