Nico
1164a72ea3
Add native transport recording and execution with grid lifecycle handling, clientless teleport acknowledgements, and regression tests. Support targeted same-map portal imports and preserve disabled taxi nodes. Document live transport and portal verification and the remaining portal inventory.
4.2 KiB
Allgemeiner Lifecycle animierter GameObject-Transporte
Ursache
Die Tiefenbahn besteht aus sechs GAMEOBJECT_TYPE_TRANSPORT-GameObjects
(Typ 11). Drei Wagen besitzen ihre Datenbank-Spawnposition in Eisenschmiede,
drei in Sturmwind. Diese GameObjects werden beim Erstellen bereits über
setActive(true) für Aktualisierung und einen Unload-Lock ihres Spawn-Grids
registriert. Vorher müssen sie jedoch vom normalen Grid-Loader erzeugt werden.
Bei ausschließlich in Sturmwind anwesenden Spielern blieb das entfernte Spawn-Grid ungeladen. Der dort startende Zug existierte daher serverseitig noch nicht. Das betrifft Netzwerkspieler ebenso wie clientlose Spieler. Ein Besuch in Eisenschmiede lud die fehlenden Wagen und ließ den Fehler bis zum nächsten Neustart verschwinden.
Änderung
ObjectMgr::LoadGameObjects indexiert nach Abschluss der vorhandenen
Validierungen reguläre Typ-11-Spawns nach Karte. Ereignisgebundene Spawns
bleiben außerhalb dieses Index und behalten die bisherige Ereignisverwaltung.
MapManager ruft nach Initialisierung der Respawn-Daten beziehungsweise der
Instanz-/Battleground-Daten Map::LoadTransportGameObjectGrids auf. Diese
Funktion lädt ausschließlich die Spawn-Grids der indexierten Transporte für die
jeweilige Karte und Spawnmaske. Das Laden erfolgt über EnsureGridLoaded:
vorhandene Pools, Spawn-Gruppen, Respawn- und Phasenmechaniken gelten weiter.
Bereits geladene Grids erzeugen keine zusätzlichen Objektinstanzen.
Die Änderung verwendet keine CPC-, AdventureBot- oder TravelGraph-Komponenten. Die getrennt verwalteten Typ-15-Transporte (Schiffe/Zeppeline) bleiben im vorhandenen Transport-Lifecycle. Es werden keine Transportfahrpläne verändert.
Im Testdatenbestand liegen zwischen 1 und 47 Typ-11-Spawns pro betroffener Karte, sechs davon auf Karte 369. Benachbarte Wagen teilen sich Spawn-Grids. Durch das frühe Laden werden auch die normalen Inhalte dieser Grids früher erzeugt; ein vollständiges Vorladen sämtlicher Kartengrids erfolgt nicht.
Prüfung
python3 tests/clientless/test_transport_grid_loading.py prüft die tatsächlichen
neuen Indexierungs- und Ladeblöcke mit deterministischen Core-Doubles:
beide Stationen ohne Spieler, wiederholtes Laden, andere Karten,
Spawnmasken, entfernte/verschobene Spawns und Ausschluss ereignisgebundener
Objekte sowie Typ-15-Transporte.
Für den entscheidenden Live-Test ist ein frischer Worldserverprozess nötig.
Danach darf zunächst ausschließlich die Sturmwindseite betreten werden.
Alle sechs Spawns 18802–18807 müssen dort bereits über transport inspect
auflösbar sein. Zwei zeitlich getrennte Zustandsaufnahmen müssen Bewegung
beider Zuggruppen zeigen. Das erstmalige manuelle Betreten der Gegenseite
wäre für diesen Test eine unzulässige Vorbedingung, da es den ursprünglichen
Fehler verdecken würde.
Live-Ergebnis, 26.10.2026
Build und Installation bestanden, Build-ID
28fa55f1b9604a57da4616b23a195c117d2fcc82. Neuer Worldserverprozess: PID 36683;
Ready-Meldung und Port 8085 geprüft. Vor dem Test war kein GM eingeloggt.
Arthoran wurde ausschließlich an tram_sw mit einem untätigen Lua-Skript
eingeloggt; ein Besuch am anderen Ende entfiel vollständig.
Die neue Core-Diagnostik meldete für Karte 369 drei geladene Spawn-Grids und
sechs Transportkandidaten. Alle sechs Spawns 18802–18807 waren auflösbar.
Zwei mindestens 20 Sekunden getrennte Aufnahmen bestätigten für jeden Wagen
geänderte Position und Animationsfortschritt. Beide Zuggruppen bewegten sich.
Ergebnis und Konsolenausgaben:
/tmp/vcore-tram-ride.1i65g2dm/cold-grid-test-result.json und
cold-grid-test-console.txt im selben Verzeichnis. Das vorherige Reise-Lua wurde
anschließend wiederhergestellt; Arthoran blieb online und untätig in Sturmwind.
Eine visuelle Abnahme durch einen normalen WoW-Client bleibt Aufgabe des GM.
Separater offener Befund: Beim vorhergehenden Shutdown des noch unveränderten
Servers (PID 30922, alter Build) erschien Object.h:448 in GetMap ASSERTION FAILED: m_currMap. Der Prozess endete. Diese Assertion trat vor Installation des
Grid-Fixes auf; ihre Ursache ist noch nicht festgestellt. Vorherige Logs liegen
unter before-grid-fix-restart im obigen Testverzeichnis. Die Konsolenmeldung
enthielt keinen auswertbaren Stacktrace.