|
Download docs/research/QVM_ASSISTANCE_BATCH.md from nmarshall/urt-rs: direct link, hf CLI and curl.
- Browser
- Download file 9.34 kB
-
https://huggingface.co/nmarshall/urt-rs/resolve/main/docs/research/QVM_ASSISTANCE_BATCH.md
- Command line
-
hf download hf://nmarshall/urt-rs/docs/research/QVM_ASSISTANCE_BATCH.md
-
curl -L -o QVM_ASSISTANCE_BATCH.md https://huggingface.co/nmarshall/urt-rs/resolve/main/docs/research/QVM_ASSISTANCE_BATCH.md
9.34 kB
| # Assistance search and replay: RE-1004–1013 | |
| Semantic correction from RE-1024: historical capture tags `teleport`, `award` and `sound` for functions205260,283463 and193620 identify score update, indexed counter increment and team radio respectively. Their numeric call arguments remain evidence; the old schemas are retained for compatibility. [Corrected source evidence](QVM_EFFECT_COUNTER.md). | |
| Ten tasks recover five source/Rust contracts across **212 paired scenarios**, including100 snapshots from repeated calls. They extend the [callback batch](QVM_MOVE_CALLBACK_BATCH.md) through complete152792 assistance processing with nonempty client pools. Every task has its own commit and focused `cargo xtask` check. Native effect bodies and the larger client/frame scheduler remain outside this evidence. | |
| | Tasks | Contract | Paired scenarios | | |
| | --- | --- | ---: | | |
| | RE-1004 / RE-1005 | [Source acquisition](QVM_ASSIST_ACQUIRE.md) / [Rust acquisition](RUST_ASSIST_ACQUIRE.md) | 36 | | |
| | RE-1006 / RE-1007 | [Source cancellation](QVM_ASSIST_CANCEL.md) / [Rust cancellation](RUST_ASSIST_CANCEL.md) | 72 | | |
| | RE-1008 / RE-1009 | [Source progress](QVM_ASSIST_PROGRESS.md) / [Rust progress](RUST_ASSIST_PROGRESS.md) | 24 | | |
| | RE-1010 / RE-1011 | [Complete source callback](QVM_ASSIST_COMPLETE.md) / [Rust callback](RUST_ASSIST_COMPLETE.md) | 60 | | |
| | RE-1012 / RE-1013 | [Repeated source calls](QVM_ASSIST_SEQUENCE.md) / [Rust replay](RUST_ASSIST_SEQUENCE.md) | 20 | | |
| ## Acquisition and conditional ownership | |
| The153177 fragment assumes caller routing has already selected a nearby protected target. Client220 mask8192, nonzero active6316 and target6320 together establish ownership. If the first two are set and the target differs, acquisition does nothing. Otherwise it sets mask8192, stores active1, target and clock6328, then requests event104 with the target entity word0 followed by the original thaw-start log. | |
| Stale target state without both the flag and active word does not block replacement. Raw unrelated bits and wrapped tick words survive. Direct fragment cases also cover matching targets; the complete callback routes an existing matching owner to progress before this acquisition fragment, avoiding repeated start requests on normal successive calls. | |
| ## Cancellation | |
| Both153284 far-target and153346 unprotected-target branches require flagged active ownership of the current candidate. They clear mask8192, active6316 and target6320, preserve clock6328 and unrelated bits, then request event105 with parameter0xffffffff. Other ownership states remain unchanged. Cancellation after clearing is silent on repetition. Source probes cover both branches; publication278003 is captured rather than executed. | |
| ## Assisted progress and actual target feedback | |
| The153121 progress path uses staged f32 arithmetic: | |
| `32000 / (global34062368 * 1000) * signed_word(global34992532 - helper6328)` | |
| It adds progress to target carry6332 and executes actual152386 with target/helper entity pointers and assisted-completion mode. The target meter result mirrors into helper232. Helper clock6328 advances after the child. The original meter conversion, clamp, threshold and flag/movement changes are exercised directly. | |
| Completion requests score update205260, reset6369, event108 and the original thaw-finished log in order. The supplied event receives the target owner168 and mask32. Completed target meter and mirrored helper meter both become zero. Ownership is retained immediately after completion; a later candidate scan observes the now-unprotected target and cancels it. | |
| Twenty-four progress cases cover negative and wrapped elapsed time, negative duration, fractional carry, f32 precision and exact/near threshold behavior. Rust rejects active invalid float/conversion domains before committing helper or target updates. Captured score/recipient reset bodies do not change health or positions in these probes. | |
| ## Complete152792 callback | |
| Sixty cases execute the body from its entry through the153417 void-return boundary with actual distance65655 and meter152386. The earlier admission/cleanup policy now runs together with the proximity search. Self must have an entity/client, mode10, connection2, positive signed health and zero follow. Protected self clears its assistance and returns. The first loop removes assistance whose target is disconnected, dead or following. | |
| The second loop visits entity slots in ascending order, excluding self and clients that are disconnected, dead, following or on another team. Protected candidates use actual65655 distance, with a supplied finite native sqrt model. Distance must be strictly less than75; equality is far. Matching nearby ownership advances progress. Unowned/stale nearby state can acquire; ownership of another candidate blocks switching. Far or unprotected matching candidates cancel. | |
| Cases include competing candidates, existing ownership, cancellation then acquisition of a later candidate in the same scan, team filtering, exact radius, wrapped progress, zero/64 counts and a candidate at slot63. Distance fixtures here are axis-aligned finite inputs. Original entity/client identity is supplied through fixed880/6336 strides; allocation aliasing and stale-pointer lifecycle are not established by this table model. | |
| Rust validates shared flag views, uses typed target indices and stages all clients/event plans before committing. A late invalid distance can therefore discard an acquisition planned earlier in the same scan. These typed domain/atomicity guarantees are adapter behavior, not additional original-game semantics. | |
| ## Repeated coherent calls | |
| Twenty scenarios execute five complete callbacks at offsets0/100/200/2200/2300 from the supplied starting tick, preserving one coherent memory state. They compare100 original/Rust snapshots containing every projected client word, distance result, effect request and allocated event state. Positive/negative duration, wrapped ticks, two candidates and64-slot pools are included. | |
| The snapshots establish transition order across acquisition, progress, completion and later cancellation/reacquisition. A candidate visited earlier cannot retroactively acquire after a later candidate cancels ownership in the same scan. Rust replay stores separate immutable snapshots and stages the bounded replay on errors; the original callback remains a per-call source body. The unit regression where NaN duration becomes active only on a second call checks rollback after an earlier planned acquisition. | |
| ## Validation and limits | |
| Each task runs its corresponding `cargo xtask test-group qvm-assist-*` or `rust-assist-*` before its commit. Selected reports regenerate twice identically. Source reports retain verified QVM identity and trace summaries; independent arithmetic/state/order expectations check the source. Rust reports project every compared source field and retain source-report SHA256. Ten additional Rust tests cover ownership, order, clock preservation, idempotence, mirrored progress, completion, candidate selection and late-error rollback. | |
| Dependency mappings include all five source/Rust pairs, the shared assistance module/CLI and recovered meter/cleanup module. Changes select affected parity producers and gameplay test-count metadata. The registry regression verifies those mappings. One full-suite run follows task ten: `cargo xtask test-full --since 19fce7e8`. Python uses only the flake-declared Nix runtime, including Git hooks. Assets and original binaries are unchanged. | |
| Event publication278003, logs7259, score update205260 and reset6369 remain captured plans; event allocation277695 is supplied. Native feedback, scheduler behavior, platform/runtime acceptance and complete game behavior are not established by these fixtures. | |
| The single `cargo xtask test-full --since 19fce7e8` run at the tenth-commit boundary passed: **1,958 Python tests** across529 modules, **309 Rust tests** (assets10, gameplay269, xtask30), **126 deterministic affected report producers**, storage policy, links across **590 documentation files** and whitespace guards. Regeneration left no changes. Focused dependency-registry regression passed. Validation notes are amended into task ten, preserving ten commits. | |
| ## Follow-up from RE-1014 | |
| The [RE-1014–1023 defuse batch](QVM_DEFUSE_BATCH.md) now covers mode8 objective transitions, actual hash/distance lookup and coherent replay. Native effect feedback and full client/physics integration remain open. The original follow-up scope was: | |
| - [ ] Recover153596 onward mode8 objective lookup, distance/progress/clock transitions, weapon/animation changes and completion effects. | |
| - [ ] Resolve actual event publication278003, score update205260, reset6369 and allocation277695 for assistance consumers; replace captured native feedback and verify field ownership. | |
| - [ ] Compose nonempty assistance, self-recovery152673 and movement setup in the same full154089 client path, then integrate actual physics54475 and timer155714. | |
| - [ ] Expand distance fixtures to varied3D geometry and finite extremes, plus client identity/aliasing, larger time/configuration domains and source-backed longer replays. | |
| - [ ] Continue post-movement events/linking/health feedback, native time/file/network adapters, assets/rendering/Bevy/Solari integration and native macOS/Linux acceptance. | |