[quasistatic-setup]

Ausgangspunkt

Im WoW-A/B-Log betrug die gemessene mittlere Anzahl von Timer-Ticks ca. 27,1 ms pro Tick, obwohl SetTimer(...,16) angefordert war. Mit der Glättungsgrenze 20 px/Tick entstehen lange Rückstände bei größeren TeamViewer-Eingaben.

Änderung

• Neue, standardmäßig deaktivierte Einstellung high_res_smoothing_timer. In config-ab-test.json zunächst true; Start-Playing.cmd bleibt beim bisherigen WM_TIMER.
• Hochauflösender Windows-Waitable-Timer mit 16-ms-Periode; eigener Warte-Thread postet maximal eine ausstehende Nachricht auf die bestehende Haupt-Message-Loop. SendInput und die Korrektur bleiben ausschließlich auf dem Hauptthread. Kein Eingriff in den globalen Timer.
• Bei fehlender Unterstützung, fehlgeschlagener Erstellung oder Zeitgeberinitialisierung Rückfall zu WM_TIMER mit Warnung. Bei Fehler während des Betriebs wird sicher beendet, statt unbemerkt die Eingaben zurückzuhalten.
• ## SMOOTH TIMER source=... im Log ermöglicht eindeutige A/B-Zuordnung; bestehende ## TIMING-Felder weiter verfügbar.
• Keine Änderungen am Hook, der Cursor-Ankerlogik, externen Abhängigkeiten oder Eingriffsgrenzen.

Abnahme

• MSVC x64 /WX und CTest erfolgreich
• TeamViewer/WoW, Fix ON: ## TIMING liefert deutlich kürzere Intervalle ohne erhöhte Queue-Drops oder Watchdogs
• Mit high_res_smoothing_timer=false reproduzierbare alte WM_TIMER-Variante
• Ctrl+Alt+C wirksam; OFF/Relative, Fokusverlust, Probe A/B/C fehlerfrei
• own == applied, output_failures=0, dropped=0
• Normales Playing bleibt zunächst beim bisherigen Timing
• High-res-Timer-Ausfall führt zu dokumentiertem Rückfall bzw. kontrolliertem Stopp

Abhängigkeiten

Stacked Draft-PR: #2 (INI, Probe, Zeitdiagnose) → #3 (sichere Ankerneuerkennung) → dieser PR. Die Builds sind automatisierbar; der geforderte praktische Windows-/TeamViewer-Test ist nicht durch CI ersetzbar. Nicht vor dessen Abschluss mergen.

Praxistest 27.10.2026 – Timervergleich WoW über TeamViewer

• Tester: high_res_smoothing_timer=true fühlt sich deutlich besser an als false.
• Log 14:12:58 (high-res-waitable): 100 TIMING-Fenster, 1604 Ticks in insgesamt 26064 ms => 16,25 ms pro Tick (61,6/s), größter gap 25 ms, größter pending_age 500 ms, applied=603, own=603, Queue-Drops 0, Watchdog 0.
• Log 14:15:51 (wm-timer): 79 TIMING-Fenster, 777 Ticks in 20768 ms => 26,73 ms/Tick (37,4/s), größter gap 45 ms, größter pending_age 1032 ms, applied=447, own=447, Queue-Drops 0, Watchdog 0.
• Der Test bestätigt präziseres Timing und subjektive Verbesserung, nicht die Beseitigung der weiter auftretenden ~500-ms-TeamViewer-Input-Lücken. Unterschiedliche Dauer/Bewegungsabläufe, daher keine strikte Aussage über 2x bessere End-to-End-Latenz.
• In der High-Res-Sitzung erfolgten kurz nacheinander zwei Ankerwechsel im selben Hold: (942,568) -> (922,568) -> (942,568), exakt 20px (= maximale Glättungsstufe). PR Fix: WoW-Cursoranker während Kameradrehung kontrolliert neu lernen #3 muss vor Merge gegen eine Fehlübernahme eigener Korrekturpositionen abgesichert werden.

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]

GitHub-Actions-Node-20-Annotation behoben: actions/checkout@v4 → @v7, actions/upload-artifact@v4 → @v7 (Node 24) in den offenen Entwicklungszweigen. Neuer MSVC-x64-Run 40514317562 PASS; Release-Artefakt RemoteMouseFix-win-x64 vorhanden. Diese CI-Änderung betrifft nicht die Windows-Mauslogik; ältere Run-Annotationen bleiben historisch sichtbar.

Praxismessung vom 27.10.2026, Log ab 14:37:44: source=high-res-waitable period_ms=16; 120 Timing-Fenster, 1928 Ticks / 31264 ms = 16,22 ms pro Tick, maximal 26 ms. 556 Korrekturen / 556 eigene Echos, 0 Output-Fehler, 0 Watchdogs, 0 Drops; ein plausibler Ankerwechsel während Hold auf (1006,528) mit 8/8 Samples, kein SMOOTH RESET. Allerdings 28 entfernte Eingabeabstände 450–700 ms bei verstecktem Cursor: TeamViewer-Eingabepausen bleiben ungelöst. PR bleibt Draft für weitere Laufzeitvalidierung.

[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]

Aktueller kombinierter Head c83fc313e879f82ae4e50a214365904fdbf4d920: MSVC x64 /WX und CTest erfolgreich, GitHub Actions Run 40518786739. Artefakt RemoteMouseFix-win-x64 vorhanden. Die letzte Sicherheitskorrektur (warp-evidence confirmed, Fail-open bei fehlendem Warp, 300-ms-Off-Anchor-Revoke) ist enthalten; config-play.json aktiviert weiterhin High-Res. Weiter DRAFT – nicht ohne reale Probe-B/Probe-C- und Playing-Praxisprüfung mergen.

[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.