[quasistatic-setup]

Ausgangspunkt

Neue TeamViewer/WoW-A/B-Messung (27.10.2026, ~13:40 Uhr): nach Fensterverschiebung blieb der alte Anker (714,564) aktiv, während WoW auf (847,573) zurücksetzte. 69 Timer-Ticks mit off_anchor, 106 eingehende Bewegungen ohne Ausgabe, unsent pending bis 817px und ca. 1,9s. Die Korrektur sperrte sich bis zum Loslassen.

Implementierung

• Begrenzter Ring aus 12 Zustands-Samples; ein neuer Anker wird nur akzeptiert, wenn mindestens 8 Samples identisch sind und 75% der letzten Samples übereinstimmen und beim Übergang zum versteckten Cursor eine Positionsdiskontinuität >=30px beobachtet wurde.
• Bereits gelernte Anker dürfen nun innerhalb einer laufenden Haltephase aktualisiert werden; Zufallskoordinaten oder bloßer Stillstand genügen nicht als Beleg einer Warp-Rücksetzung.
• ## STATE anchor-relearned during hold und vorhandenes anchor-learned protokollieren den Wechsel.
• Bei einer Ankeränderung über die konfigurierte Toleranz werden bereits aufgelaufene, zum alten Anker gehörende Glättungsdeltas vom Message-Loop verworfen statt verspätet auszuspielen; ## SMOOTH RESET reason=anchor-relearned im Log.
• Keine Korrekturaufrufe im Sampler/Hook. Alle bisherigen Grenzen (nur Ziel im Vordergrund, versteckter Cursor, fremde injizierte Mausbewegungen, kein Keyboard-Hook, Not-Aus) bleiben.
• Regressions-Test für stabilen Anker, Rauschen, Fensteränderung und Reset; MSVC CI führt ihn per CTest aus.

Abnahme

• MSVC x64 /WX und CTest erfolgreich
• TeamViewer → WoW, Fix ON: Fenster verschieben, erneut drehen; neue Ankererkennung während der Haltephase, kein mehrsekündiger off_anchor-Stillstand
• MouseLookProbe A/B/C inklusive Fix ON/OFF/Relative, keine falsche Neuerkennung im Modus B
• Keine queue drops, watchdog trips oder fehlende eigene Input-Echos, Ctrl+Alt+C weiter wirksam
• Stale backlog beim Ankerwechsel nicht nachträglich ausspielen

Abhängigkeit

Dieser Draft basiert auf PR #2, der die diagnostischen Timing-Zähler und den Probe enthält. PR #1 wurde noch nicht gemergt. Keine Freigabe ohne reale Windows-Laufzeitprüfung.

Praxistest 27.10.2026 – weiterer Befund

• Bei aktivem High-Res-Timer sprang der während eines Holds neu gelernte Anker zunächst von (942,568) auf (922,568) und unmittelbar zurück.
• Der Zwischenpunkt ist exakt 20 Pixel neben dem vorherigen Anker, genau die im Code verwendete maximale Glättungsstufe. Im Log stehen direkt davor wiederholt OWN-Ereignisse an (922,568), während APPLY before=(942,568) target=(922,568) läuft. Daher spricht die Evidenz stark für eine falsche Ankerübernahme der eigenen Korrekturausgabe, nicht für einen echten WoW-Warp.
• Dabei wurde ## SMOOTH RESET ... discarded=(-76,+0) ausgelöst. Die jetzige 12-Sample-Stabilitätsheuristik ist damit noch nicht ausreichend.
• Vor Merge beheben: Neue Anker dürfen nicht mit bereits als eigene SendInput-Zielkoordinaten bekannten Positionen verwechselt werden; ohne unabhängigen Warpnachweis die Korrektur lieber blockieren als den falschen Anker übernehmen. Danach Regression/Win-Test wiederholen.
• In der Standardtimer-Sitzung wurde der Anker von (1008,446) auf (1001,623) während des Holds umgelernt. Ob dieser Wechsel korrekt war, erfordert den Gesamtkontext/Runtime-Rückmeldung.

Nachbesserung gegen falsch positiven Eigenbewegungs-Anker (27.10.2026)

• Die in den neuen WoW-Logs beobachtete scheinbare Ankerverlagerung um exakt 20 Pixel (eigene SendInput-Schrittgröße) war ein Fehlkandidat aus den eigenen Mausausgaben.
• Behoben im Draft: Der Sampler nimmt keine Koordinaten nahe dem letzten erfolgreichen eigenen absoluten SendInput-Ziel (±2 px) mehr als Ankersamples an. Nach jedem eigenen Ausgabeereignis wird die aktuelle Konsens-Sammlung zurückgesetzt; für die folgenden 160 ms werden keine Kandidaten gesammelt.
• Auch der bisherige Ganz-Haltephase-Schätzer darf beim Loslassen einen bereits gültigen Anker nicht mehr überschreiben, wenn im selben Hold eigene Korrekturbewegungen ausgegeben wurden.
• Regressionstests simulieren den eingefrorenen 20-Pixel-Eigenzielpunkt, laufende Ausgaben, das sichere Löschen der Sammlung bei neuen eigenen Bewegungen und einen tatsächlich stabilen neuen Spiel-Warp nach ruhiger Ausgabephase.
• Der Timer-PR enthält die Sicherheitsänderung durch einen Zweig-Merge als echte Abhängigkeit von PR Fix: WoW-Cursoranker während Kameradrehung kontrolliert neu lernen #3.
• Weiter erforderlich: manuelle Validierung der Win32-/TeamViewer-Laufzeit, insbesondere erneute Kameradrehung nach Fensterpositionwechsel und Probe-B-Test, bevor der PR gemergt wird.

[quasistatic-setup]

Praxistest mit der gehärteten Ankerlogik, Log vom 27.10.2026 ab 14:37:44: 9 Hold-Enden mit anchor-release-estimate ignored: own output during hold, keine erneute falsche 20-Pixel-Anker-Umlernung im Log, ## SMOOTH RESET 0. Nach einer geänderten Rücksetzposition erfolgte um 14:38:33 während des Holds eine neue Ankererkennung von (1010,433) auf (1006,528), 8/8 stabile Samples. Korrektur sendete 556 und erkannte 556 eigene Events wieder, Output-Fehler/Queue-Drops/Watchdog jeweils 0. Das bestätigt diesen Durchlauf, kein allgemeiner Beweis gegen weitere Fehlkandidaten. Probe-A/B/C und der subjektive WoW-Eindruck sind vor Merge weiterhin zu validieren.

[quasistatic-setup]

Praxisprüfung MouseLookProbe am 27.10.2026, gekoppelte Logs mouselook-probe(2).log und remotemousefix-20261027-144739.log:

• Nur Modus C / warp ausgeführt: 4 Haltephasen (4,562 + 5,109 + 3,141 + 6,297 ms), sämtlich mode=warp, Fix absolute.
• Zwischen Phase A/B und Playing: Ziel-EXE/Pfad per INI, Marker und Probe-Modi #2 und Fix: WoW-Cursoranker während Kameradrehung kontrolliert neu lernen #3 Fenster verschoben; Probe-Anker ging von (1080,521) auf (438,543), weiterhin genau anchor_offset=(380,330). Kein anchor-relearned during hold, kein SMOOTH RESET und keine weitere 20-px-Fehlübernahme.
• ## TIMING: 1156 Ticks in 18820 ms = 16,28 ms/Tick, größter Gap 22 ms, 6 off_anchor-Skip-Ticks, maximaler pending age 458 ms.
• RemoteMouseFix: suppressed=289, applied=439, own=439; Fehler/Watchdogs/Queue-Drops je 0.
• Remote-Eingabepausen bestehen: zehn geloggte fremdinjizierte Bewegungslücken von 450–700 ms bei verborgenem Cursor (max. 656 ms).
• Keine Modus-B-Prüfung in diesen Logs. Keine vollständige Probe-Modi-Regressionsfreigabe behaupten; vor Merge ist ein kurzer Probe-Modus-B-Fix-ON-Test erforderlich.

Zusätzlich ist high_res_smoothing_timer=true jetzt auf diesem PR-Zweig in config/config-play.json aktiviert; bisher nur im A/B-Profil. Dies macht nach neuem Build einen kurzen Smoke-Test mit Start-Playing.cmd nötig. PR bleibt Draft; andere PRs nicht gemergt.

[quasistatic-setup]

Merge-Blocker aus Modus-B-Gegenprobe (27.10.2026, 14:54:01)

Reale TeamViewer-Messung mit MouseLookProbe.exe, mode=hidden (kein SetCursorPos-Warp), config-ab-test.json im Modus absolute, high-res Timer aktiv:

• 8 vollständige Hidden-Haltephasen, davon 1x rechte Maustaste, die übrigen links. In allen 8 Phasen erfolgen viele fremdinjizierte Mausbewegungen, aber das Probe-Protokoll meldet lediglich 8 Bewegungstakte insgesamt (1+1+0+0+1+2+1+2). Ein nachfolgender Nullzeit-Klick wurde nicht als eigene Testphase gewertet.
• RemoteMouseFix 1661 unterdrückte Eingabeereignisse, nur 5 Korrekturen (5/5 OWN wiedererkannt), 1476 off_anchor-Skips bei 1495 Timer-Ticks aus 93 Zeitfenstern. pending_age_ms maximal 5478 ms; 7x ## SMOOTH RESET reason=anchor-relearned und 3x anchor-relearned during hold trotz Probe-Modus ohne Warp. output failures=0, watchdog trips=0, queue drops=0.
• Timing bleibt normal: 1495 Ticks / 24291 ms = 16,25 ms/Tick, maximal 22 ms.
• Mechanismus: Der Algorithmus akzeptiert stationäre GetCursorPos-Samples nach Cursorverbergen als Warp-Beweis (z.B. anchor-learned=(1119,577) hits=5/5), obwohl es hier keinen Warp gibt. Nach eigenen 20px-Schritten steht der Cursor dauerhaft off_anchor, alle weiteren Remote-Moves werden weiter unterdrückt. Auch der zusätzliche angebliche warp transition observed-Nachweis kann in Modus B bei Beginn der Haltephase fälschlich erfüllt sein.

Bewertung: Keine Freigabe für Merge von #3/#4. Die aktuelle Ankerlogik kann in Hidden-aber-No-Warp-Modus die Maus faktisch vollständig blockieren. Vor Merge einen belastbaren externen Nachweis von tatsächlichem Game-Warp und fail-open bei fehlendem Warp entwickeln, statt reine Positionsruhe/Onset-Sprünge als Beweis zu behandeln. Bestehende Hook-/Emergency-Off-/Zielprozessgrenzen unverändert. Der schnellere Timer selbst zeigt keinen Fehler und soll erhalten bleiben. Danach Probe A/B/C mit Fix ON/OFF und WoW erneut testen. Start-Playing.cmd-Smoke-Test wurde für diese Abnahme noch nicht eingereicht.

Unverändert: Draft, nicht mergen.

[quasistatic-setup]

Nachbesserung zum Merge-Blocker „Probe B ohne Warp“ (27.10.2026)

Der Hook greift nicht mehr allein bei verstecktem Cursor ein. Für das Unterdrücken fremdinjizierter Bewegung muss die State-Sampler-Logik nun pro versteckter Haltephase einen plausiblen Game-Warp aus mehrfachen unerklärten Rücksprüngen nachweisen (mindestens 2 Rücksprünge zum gleichen inneren Punkt, 5 verschiedene remote input updates, mindestens 60 px remote travel, 80 ms Zeitfenster). Eigene SendInput-Ausgaben sind als Beleg ausgeschlossen, inklusive 160-ms-Sperrzeit. Stabilität allein, das Verstecken selbst oder ein einzelner Onset-Sprung zählen nicht mehr. Ohne Beleg werden alle fremden Mausbewegungen durchgelassen; nach Hold-Ende/Moduswechsel/Fokusverlust gilt der Beleg nicht mehr. Bei >300 ms dauerhaftem off-anchor ohne eigene Ausgaben wird die Freigabe widerrufen und die Glättungswarteschlange verworfen (fail-open).

MSVC-/CTest-Fälle decken B mit normaler Bewegung, stillstehende/laggende Maus, manuelle Rückkehr zum selben Ort, Randposition, eigene SendInput-Ausgabe, Modus-/Hold-Reset und C-artige unbeobachtete Positionsrücksprünge ab. Die alte fehlerhafte Stille-basierte Ankervergabe wurde aus dem Laufzeitcode entfernt. Der schnelle 16-ms-Timer bleibt bestehen; im gestapelten PR #4 ist er auch in config-play.json aktiviert.

Wichtig: Das ist eine konservative Heuristik aus extern beobachtbaren Daten, keine technische Benachrichtigung von Win32 über SetCursorPos im Spiel. Damit kann eine echte Rücksetzung übersehen werden: dann bleibt die Korrektur bewusst aus. PR #3 und #4 sind weiter DRAFT. Vor Merge: realer TeamViewer-Probe-Test B ON (keine DROP, flüssige Mausbewegungen) und C ON (sollte warp-evidence confirmed und anschließend APPLY/OWN zeigen), danach kurzer Start-Playing.cmd-/WoW-Test und Emergency OFF.

[quasistatic-setup]

Neuer Merge-Blocker: subjektiv deutlich schlechtere WoW-Kamera, auch einzelne Klicks lösen Sprünge aus (Praxistest 27.10.2026, 15:20:03).
Die letzte Regression gegen den Modus-B-Bug ist auf dem neuesten Windows-ZIP (Actions 40518786739) in der Praxis nicht für WoW geeignet.

Belegte Daten aus vier neuen Logdateien:

• Zwei MouseLookProbe/AB-Aufnahmen 15:18:06 und 15:19:04: MouseLookProbe.exe, Fix absolute, high-res 16 ms, 0 suppressed, 0 applied, 0 own. Zugehöriges mouselook-probe(4).log: ausschließlich mode=hidden, 4 Holds, nicht Mode C. Modus B wird also korrekt durchgelassen.
• Playing 15:20:03 (config-play.json, Wow.exe, high-res): vier warp-evidence confirmed bei (1006,528), jeweils erst innerhalb einer länger laufenden Haltephase. 66 suppressed, 140 applied, 140 own, 0 output failures, 0 watchdogs, 0 queue drops. Kurze LDOWN/LUP-Holds um 15:20:19–15:20:27 werden NICHT klassifiziert; die TeamViewer-Bewegungen werden während der versteckten Cursorphase durchgelassen. Beispiel: 15:20:22.327 LDOWN bei (1515,548), nächster State cursor=HIDDEN bei (1006,528), 15:20:22.433 LUP bei (1515,548), anchor=(–,–). Der Ortsunterschied ist 509 px; wie viele davon die Spielkamera konsumiert hat, misst das Log nicht.
• Das ist ein starker, noch nicht experimentell isolierter Erklärungsansatz für Einzelklick-Kamerasprünge und unruhige Bewegung. Der langsame 27-ms-WM_TIMER ist nicht der Verursacher (laut Log high-res aktiv).

Konsequenz: PRs #3/#4 weiterhin DRAFT und NICHT MERGEN. Die automatische warp-evidence-Erkennung macht ausgerechnet die anfänglichen Mausbewegungen eines bekannten warp-basierten Spiels ungeschützt und schaltet die Korrektur mitten im Hold ein. Vor weiterer Implementierung die Policy trennen: konservativ fail-open für unbekannte/Probe-B-Ziele; für vom Nutzer ausdrücklich als warp-basiert freigegebene Spiele (z.B. Wow.exe) von Beginn des versteckten Holds eine bewährte Korrektur verwenden, ohne einen Anchor aus der Clientmitte zu erfinden. Alternativ sichere Preflight-Entscheidung vor jeder Haltephase, keine Umstellung während eines Klicks. Zurück zur subjektiv besseren Vor-Gate-Version für WoW ist vorerst vernünftiger; keinesfalls wieder global für Probe B unterdrücken. Erneute Wow-/Probe-C-Praxisprüfung nötig.

[quasistatic-setup]

Geschlossen zugunsten von PR #5, der den vom Betreiber praktisch bestätigten stabilen WoW-Stand mit High-Res-Timer exakt als Commit 32f857c664c29da8d7689f84829b06a60e4a629a nach main übernommen hat (Merge 8115f260eac09fb999072c5967ed7d6ce3458b9d). Nicht separat mergen: Dieser experimentelle/gestapelte PR-Kopf enthält entweder überholte Zwischenstände oder würde den bereits gemergten stabilen Zustand erneut verändern. Die dokumentierten Grenzen für Hidden-/No-Warp-Probe-B bleiben bestehen.