103 APIs – jede sagt dir
„verifiziert oder nicht, wie schnell, wie es darunter funktioniert“

Vollständiger Zustand der gesamten Karte (WorldState): .units .players .items .clock .me; wiederholte Aufrufe innerhalb von max_age Sekunden liefern dieselbe Kopie. ⚠ Arbeiter in einer Goldmine sind nicht in der Liste; standardmäßig ist die ganze Karte sichtbar (im Lockstep-Modell liegt lokal alles vor), erst Game(fair=True) filtert nach Sichtweite.

Mechanismus W3P-Weltblock Local\War3World_<pid> (die Runtime pusht alle 50 ms, seqlock)

Zuletzt gesehene Einheiten des Gegners (oder 'creep' für Creeps, oder einer Spielernummer): [(Zustand der Einheit damals, Spieluhr damals, vergangene Sekunden)], neueste zuerst. Sieht man eine Einheit sterben, fliegt sie aus der Liste. Fair-Modus und normaler Modus erfassen beide nach "was wir gerade sehen" – das ist die Karte im Kopf eines Spielers: aufgeklärte Truppenstärke, wo der gegnerische Held zuletzt war, wann der Gegner seine Expansion gebaut hat. max_age: nur Einträge aus so vielen zurückliegenden Spielsekunden.

Mechanismus visibleTo des Push-Snapshots (bei jeder Aktualisierung des Snapshots werden sichtbare gegnerische Einheiten/Creeps festgehalten)

Geländetabelle dieser Partie, MapInfo: .walkable(x,y) .buildable(x,y) .at(x,y) .bounds (spielbarer Bereich) .starts (Startpositionen) .cells (bit0 nicht begehbar, bit1 nicht bebaubar). Nach Partiebeginn dauert die Berechnung einige Sekunden; bis dahin None. Bäume sind nicht enthalten (dafür trees()).

Mechanismus W3P-Kartenblock Local\War3Map_<pid> (die Runtime berechnet ihn nach Partiebeginn in Etappen, IsTerrainPathable Laufen/Bauen)

Welche Spielernummer ich habe (0~11).

Mechanismus Header des Weltblocks

{'gold','lumber','food_used','food_cap','gold_gathered','lumber_gathered'}; player ist standardmäßig der eigene Spieler, jeder Spieler ist lesbar. Nicht lesbar = None, nicht als 0 behandeln.

Mechanismus Weltblock players[16]

Alle 16 Spieler-Slots: Player(id, gold, lumber, food_used, food_cap, gold_gathered, lumber_gathered, race, known).

Mechanismus Weltblock players[16]

Einheiten nach Besitzer/Typ filtern. owner: 'me' / 'enemy' / 'creep' / 'all' / Spielernummer. types: Menge von Vier-Zeichen-Codes.

Mechanismus Weltblock units[]

Einheit über das Handle-Paar (lo, hi) finden (Order-Ziele, Aufgabenziele und Events liefern alle Handle-Paare).

Mechanismus Weltblock by_handle

Ob es ein Gebäude ist (inkl. Türme). Entschieden wird über Bewegungsgeschwindigkeit 0 laut Einheitentabelle; das Hauptgebäude der Untoten hat eine Grundfläche von 0, also nicht über die Grundfläche entscheiden.

Mechanismus Snapshot + units.json (spd==0 = Gebäude)

Eigene Arbeiter (Bauer/Peon/Akolyth/Irrlicht).

Mechanismus Push-Snapshot

Arbeiter ohne Beschäftigung: keine Order und keine Aufgabe (wem du in diesem Tick gerade etwas zugewiesen hast, zählt nicht). ⚠ Gibst du einem Arbeiter mit Aufgabe erneut einen Sammelbefehl, unterbricht das den Sammelzyklus (Einkommen fällt auf null).

Mechanismus Push-Snapshot (Order-Slot + Aufgaben-Slot)

Eigene lebende Helden (tote stehen in der Wiederbelebungsliste des Altars, siehe revive).

Mechanismus Push-Snapshot

Eigene Kampfeinheiten: keine Arbeiter, keine Gebäude.

Mechanismus Push-Snapshot + units.json

Eigene Gebäude (inkl. Türme und Baustellen); über types lassen sich bestimmte Arten auswählen, z. B. {'hbar'}.

Mechanismus Push-Snapshot

Ob dieser Arbeiter gerade baut (oder zum Bauplatz läuft / beim Reparieren hilft; inkl. gerade in diesem Tick zugewiesener). Bei der Wahl eines Bauarbeiters überspringen, sonst steht die vorige Baustelle still.

Mechanismus Push-Snapshot (Order = Vier-Zeichen-Code eines Gebäudes, oder Bau-/Reparaturbefehl)

Dieses Gebäude ist noch nicht fertig (TP nicht voll). ⚠ Beschädigte Gebäude haben ebenfalls keine vollen TP – für die Eröffnung reicht das, sobald gekämpft wird, zusätzlich die Zeit berücksichtigen.

Mechanismus Push-Snapshot (die TP einer Baustelle steigen von sehr niedrig bis voll)

Goldminen auf der Karte. ⚠ Die Entangled Gold Mine der Nachtelfen und die neutrale Goldmine sind zwei Einheiten an derselben Koordinate; zum Sammeln die eigene zuweisen.

Mechanismus Push-Snapshot (ngol/egol/ugol)

Einheiten gegnerischer Spieler (ohne Creeps). fighters_only: Arbeiter und Gebäude weglassen.

Mechanismus Push-Snapshot

Creeps (neutral feindselig). ⚠ Nachts sinkt die Sichtweite; liegen entfernte Lager im Kriegsnebel, werden Zielbefehle auf sie abgelehnt (Grundcode 1001).

Mechanismus Push-Snapshot (owner 12 = neutral feindselig)

{'hp','hp_max','mana','mana_max'} (Float, Rohwerte der Engine). Für u reicht die Einheit aus dem Snapshot (sie wird durch die neueste Kopie ersetzt).

Mechanismus Einheit im Weltblock: hp/hpMax/mana/manaMax

{'level','xp','skill_points'}.

Mechanismus Einheit im Weltblock: level/xp/skillPoints

[{code, level, cooldown, flags}]; Buffs liefert buffs(u). Nur für Einheiten "mit Details" (Helden > Spielereinheiten > Creeps, bis zu 256).

Mechanismus Details im Weltblock: Fähigkeiten (Code/Stufe/Flags/verbleibende Abklingzeit)

Buff-Codes auf der Einheit (z. B. 'BHds' Gottesschild, 'Bslo' Verlangsamen). Welcher Effekt zu welchem Code gehört, steht in data/game/buffs.json.

Mechanismus Details im Weltblock: Fähigkeitsobjekte, die mit B beginnen

Wie viele Sekunden (Spielsekunden) diese Fähigkeit noch abklingen muss; 0 = einsatzbereit; Fähigkeit nicht vorhanden (oder Einheit ohne Details) = None.

Mechanismus Details im Weltblock: verbleibende Abklingzeit der Fähigkeit (Fähigkeits-Timer)

Vier-Zeichen-Codes der 6 Gegenstandsplätze (leere Plätze = None); ohne Inventar None.

Mechanismus Details im Weltblock: 6 Inventarplätze

{'order','target','x','y'}: die aktuelle Order der Einheit (order ist 0x000D00xx oder der Vier-Zeichen-Code eines Gebäudes, 0 = untätig). target ist ein Handle-Paar; mit g.unit(target) bekommst du die Einheit.

Mechanismus Einheit im Weltblock: order / Order-Ziel / Order-Zielpunkt

Die Einheit, die diese Einheit **tatsächlich angreift/verfolgt** (sonst None). ⚠ Nach einem Angriffsbefehl wird der Order-Slot schnell leer, der Angriff hängt an der Aufgabe – um zu prüfen, "wen sie angreift", diese Funktion nehmen, nicht current_order.

Mechanismus Aufgabenziel der Einheit im Weltblock

Spieluhr der Engine (Spielsekunden, 0 während des Ladens). Bei erhöhter Spielgeschwindigkeit läuft sie schneller als die Echtzeit.

Mechanismus Header des Weltblocks: clockMs (Spieluhr der Engine)

Was dieses Gebäude gerade tut: Production(kind, queue, duration, elapsed, blocked, progress, remaining…); tut es nichts, None. kind 'queue' (Training/Forschung/Held, queue höchstens 7 Plätze, [0] ist das aktuelle) / 'construction' (im Bau) / 'upgrade' (Hauptgebäude/Turm wird aufgewertet); blocked = eingereiht, aber nicht gestartet (meist zu wenig Nahrung – Zeit für einen Bauernhof); progress 0..1. Auch gegnerische Gebäude sind lesbar (im Fair-Modus nur sichtbare Gebäude).

Mechanismus Produktionstabelle im Weltblock (Fähigkeitsobjekte Aque/ABnP/AUnP + von der Runtime verfolgte vergangene Zeit; gemessener Fehler < 0.2 Spielsekunden)

Vier-Zeichen-Codes in der Trainings-/Forschungswarteschlange ([0] ist in Arbeit); untätig oder kein Produktionsgebäude = [].

Mechanismus Produktionstabelle im Weltblock

Alle laufenden Produktionen [(Gebäude, Production)]. owner wie bei units(): 'me' / 'enemy' / Spielernummer / 'all'. Profi-Nutzung: sehen, welche Einheiten der Gegner trainiert, welche Technologien er erforscht und wann er seinen Tier-up macht (sobald seine Gebäude aufgeklärt sind).

Mechanismus Produktionstabelle im Weltblock

Laufweg einer Bodeneinheit von a nach b (a, b als Einheit oder (x,y)); unerreichbar = None. Auf Inselkarten damit prüfen, "ob man zu diesem Creep-Lager/dieser Expansion auf dem Landweg kommt" – zuverlässiger als die Luftlinie (um Wälder, Klippen und Gebäude herum). Genauigkeit eine Zelle (128); Lücken schmaler als eine Zelle gelten als unpassierbar.

Mechanismus Kartenblock (Engine IsTerrainPathable) + Baumblock + Grundfläche der Gebäude, A* auf SDK-Seite (128 pro Zelle)

Ob das Ziel am Boden erreichbar ist (Kartenblock noch nicht berechnet = None).

Mechanismus Wie oben

Knickpunkte des Wegs [(x,y)...] (der letzte Punkt ist b); zusammen mit path(units, Punktliste) folgt die Armee diesem Weg (Türme umgehen, Nebenwege nehmen).

Mechanismus Wie oben

Unterhaltsstufe: {'level': 'none'/'low'/'high', 'income': 1.0/0.7/0.4, 'next_at': Nahrung der nächsten Stufe (keine = None)}. Profi-Wissen: Beim Tier-up auf Stufe 3 und bei Angriffs-/Rüstungs-Upgrades bei 50 Nahrung bleiben, erst vor der Entscheidungsschlacht auf 80 gehen.

Mechanismus Feste Regel in 1.27: 0~50 Nahrung kein Unterhalt, 51~80 Einkommen ×0.7, 81~100 ×0.4

Wie viele EP dem Helden bis zur nächsten Stufe fehlen (Stufe 10 = 0).

Mechanismus Weltblock level/xp + Formel NeedHeroXP aus MiscGame

Fasst die (sichtbaren) Creeps auf der Karte zu Lagern zusammen: [{'x','y','units','level','hp','max_level'}], sortiert nach Entfernung zu unserer Hauptbasis, nah zuerst. level = Gesamtstufe des Lagers (das übliche Maß für die Schwierigkeit beim Creepen), hp = Gesamt-TP. Zusammen mit time_to_kill / path_distance ein Lager auswählen.

Mechanismus Push-Snapshot (Creeps im Abstand von 600 zu einer Gruppe verbunden) + Stufen aus units.json

Was ein Buff-Code ist: {'ability','effect','dur','hero_dur','targets'} (z. B. 'Bslo' -> Verlangsamen). Bei mehreren Zeilen pro Code wird die erste geliefert.

Mechanismus data/game/buffs.json (BuffID aus AbilityData.slk -> Fähigkeit/Effekt/Dauer)

Kampfwerte der Einheit, combat.UnitStats: max. TP/Mana, Rüstung (inkl. Angriffs-/Rüstungs-Upgrades, Beweglichkeit des Helden), Rüstungstyp, Laufgeschwindigkeit, Sichtweite bei Tag/Nacht, Waffen (was sie treffen können, Reichweite, Angriffsintervall, Schadensbereich, Angriffstyp, Flächenschaden). u als Einheit (nutzt automatisch Tech und Heldenstufe ihres Besitzers) oder als Vier-Zeichen-Code (player standardmäßig der eigene). Dazu .dps_vs(gegner) / .hits_to_kill(gegner) / combat.time_to_kill(gruppe, gegner). ⚠ Ohne Gegenstände, Auren und Buffs.

Mechanismus Datentabellen (UnitBalance/UnitWeapons/UpgradeData/MiscGame) + aktuelle Tech-Stufen + Heldenstufe

Wie viele Spielsekunden diese Einheiten gemeinsam brauchen, um target zu töten (mit den aktuellen TP von target; berücksichtigt Konter, Rüstung, Angriffs-/Rüstungs-Upgrades; nicht Stellungsspiel, Flächenschaden, Heilung). Profi-Nutzung: Beim Fokusfeuer zuerst das Ziel, das "am schnellsten stirbt" (kleinstes time_to_kill), nicht das nächstgelegene. Nicht angreifbar = None.

Mechanismus stats() + aktuelle TP

Tageszeit im Spiel (Stunden, 0~24). Die Partie beginnt um 8 Uhr morgens; ein ganzer Tag = 480 Spielsekunden (je 240 Sekunden Tag und Nacht, skaliert mit der Tag-/Nacht-Geschwindigkeit). Nicht lesbar (alte Runtime / nicht in einer Partie) = None.

Mechanismus Erweiterungsbereich im Weltblock: GetFloatGameState(GAME_STATE_TIME_OF_DAY)

Ob gerade Nacht ist (18:00~6:00). Profi-Spielweise: Nachts schlafen Creeps (beim Creepen triffst du zuerst, ohne umzingelt zu werden), alle Einheiten sehen weniger weit (gute Zeit für Überfälle), Schildwachen/Einheiten der Nachtelfen sind nachts neben Bäumen unsichtbar. Nicht lesbar = None.

Mechanismus Erweiterungsbereich im Weltblock (6~18 Uhr Tag)

Wie viele Spielsekunden es noch bis hour Uhr Spielzeit sind (z. B. seconds_until(18) = wie lange bis zum Einbruch der Nacht, zum Planen des nächtlichen Creepens).

Mechanismus Erweiterungsbereich im Weltblock + 480 Sekunden pro Tag (gemessen 20 Spielsekunden/Stunde)

Gegenstände am Boden [Item(addr, handle_lo, handle_hi, type, x, y, life)]. Aufheben/Verbrauchen löst das Event item.removed aus.

Mechanismus Weltblock items[] (nur Gegenstände am Boden: Handle des Besitzers komplett FF)

Lebende Bäume (in DestructableData mit tree in targType); mit (x,y) nach Entfernung sortiert, nah zuerst, höchstens limit Stück. Jeder ist ein Tree(addr, handle_lo, handle_hi, type, x, y, life) und kann direkt an gather zum Holzfällen übergeben werden.

Mechanismus Baumblock Local\War3Trees_<pid> (alle 2 Sekunden aktualisiert)

Was seit dem letzten Aufruf passiert ist: unit.appeared / unit.died / unit.removed / unit.damaged / order.changed / hero.levelup / owner.changed / item.appeared / item.removed / game.started (aus dem Vergleich der Veröffentlichungen, Genauigkeit = Veröffentlichungsperiode 50 ms), dazu damage / killed auf Engine-Ebene (die Runtime zeichnet sie sofort im Spiel-Thread auf, daher gibt es einen für **jeden einzelnen Treffer**): damage: handle = der Getroffene, .source_addr = der Angreifer (mit snapshot().unit_by_addr zur Einheit), .value = tatsächlicher TP-Verlust, .raw_damage = Schaden vor Rüstung, .attack_type (normal/pierce/siege/magic/chaos/hero/spell), .damage_type killed: dieser Treffer hat die Einheit getötet, .source_addr = Killer dazu production.done, abgeleitet aus der von der Runtime verfolgten Produktionstabelle (Genauigkeit = Veröffentlichungsperiode): Einheit = Gebäude, .done_code = Vier-Zeichen-Code des Fertiggestellten, .done_kind = 'training' (Einheit/Held/Wiederbelebung) / 'research' / 'construction' (Gebäude fertig) / 'upgrade' (Tier-up/Turm-Upgrade), .value = benötigte Spielsekunden Seit 09-25 ergänzt: spell.cast: Einheit = Zaubernder, .spell Vier-Zeichen-Code der Fähigkeit, b Stufe, value Abklingzeit in Sekunden, x,y Zielpunkt (erkannt, wenn die Abklingzeit startet, Genauigkeit = Veröffentlichungsperiode) player.left: .player = Nummer des Spielers, der gegangen ist / als besiegt entfernt wurde; game.ended: Partie verlassen selection.changed: Die Auswahl des lokalen Spielers hat sich geändert (Einheiten mit g.selection() holen) message: eine Zeile in einem Nachrichtenfeld auf dem Bildschirm (Spielhinweis, Chat, System): .text voller Text, .frame Nummer des Nachrichtenfelds, .chat = {'channel', 'sender', 'text'} (bei Chat-Nachrichten; was der Spieler ins Chatfeld tippt, liest du hier) ui.click / ui.hover / hotkey / mouse.world: Oberfläche & Eingabe (g.ui), .key ist der Canvas-key / die Hotkey-Schreibweise Jedes ist ein Event(seq, kind, clock, addr, handle, type, owner, a, b, x, y, value, extra). Im Fair-Modus (fair=True) nur: Events eigener Einheiten, Events von Einheiten, die gerade sichtbar sind (oder vor bis zu 1 Sekunde noch sichtbar waren), Schaden gegen uns/durch uns, sowie die lokalen Oberflächen-, Nachrichten- und Partie-Events.

Mechanismus Event-Ring Local\War3Events_<pid> (Veröffentlichungsvergleich + von der Runtime erfasste Schadens-Events)

Die Einheiten, die der lokale Spieler gerade ausgewählt hat (Haupteinheit zuerst; höchstens 12). Ändert sich die Auswahl, kommt ein selection.changed-Event.

Mechanismus W3P-Weltblock, Erweiterungsbereich selAddrs (die Runtime liefert bei jeder Veröffentlichung die Auswahl des lokalen Spielers mit)

Neue Nachrichten in den Nachrichtenfeldern auf dem Bildschirm seit dem letzten Aufruf: [{'text', 'frame', 'repeat', 'seq', 'game_ms'}]. Spielhinweise (etwa, dass mehr Farmen nötig sind oder dass dort nicht gebaut werden kann), Chat und Systemnachrichten stehen alle hier; frame unterscheidet, welches Nachrichtenfeld. Dieselben Nachrichten wie die message-Events im Event-Stream (jeweils mit eigenem Cursor).

Mechanismus Shared Memory Local\War3Msgs_<pid> (von der Runtime erfasste Bildschirmnachrichten)

Forschungsstufe / Anzahl fertiger Gebäude (Upgrade-Ketten zählen mit: ein Schloss zählt auch als htow). player standardmäßig der eigene, jeder Spieler ist abfragbar.

Mechanismus W3P-Abfrage q_tech (Tech-Zähler des Spielers in der Engine)

Machbarkeitsurteil der Engine: 0/220 möglich; 3 Nahrung, 8 Gold fehlt, 9 Holz fehlt, 32 Warteschlange voll, 183 Voraussetzung fehlt, 185 Altar belebt gerade wieder, 221 nicht vorhanden/im Bau. ⚠ Für Arbeiter, die ein Gebäude bauen, immer 221 – taugt nicht zur Prüfung des Bauplatzes (dafür build_near).

Mechanismus W3P-Abfrage q_feasible (Machbarkeitsprüfung der Engine)

Viele can_do auf einmal: pairs = [(Einheit, Vier-Zeichen-Code), ...], liefert die Urteilscodes in derselben Reihenfolge (nicht abfragbar = None). Wenn du planst, was in einem Tick gebaut/trainiert werden soll, frag zuerst alles gesammelt ab – N-mal schneller als einzelne can_do (Referenz-Brain 09-23: Bauplanung 76 -> 25 ms).

Mechanismus W3P-Abfrage q_feasible × N, als ein Batch eingereicht

Viele Tech-/Gebäudezähler auf einmal: {Vier-Zeichen-Code: Anzahl oder None}.

Mechanismus W3P-Abfrage q_tech × N, als ein Batch eingereicht

Ob wir diesen Punkt gerade sehen (nicht im Kriegsnebel/in der schwarzen Maske). Ein Bot im Fair-Modus sollte nur sichtbare Gegner verwenden.

Mechanismus W3P-Abfrage q_visible (sichtbar / Kriegsnebel / schwarze Maske)

Wie viel Gold noch in der Goldmine ist.

Mechanismus W3P-Abfrage q_mine_gold (Restgold der Mine in der Engine)

Captain der Computer-KI: wohin er seine Truppen führt (schon vor dem Abmarsch weißt du, wo er dich angreifen will). Nur gegen Computergegner; folgt die Einheit keinem Captain, None.

Mechanismus W3P-Abfrage q_captain (Computer-Captain, dem die gegnerische Einheit folgt)

Aktuelle Order der Einheit, **inklusive der Befehle, die du in diesem Tick gerade erteilt hast** (solange der Snapshot noch nicht aufgeholt hat, gilt die neue Order aus der Quittung). ⚠ 09-23 im Live-Spiel: hello_bot hatte gerade einen Bauern zum Bau eines Bauernhofs geschickt, im selben Tick sah rush_bot ihn im Snapshot als "untätig" und schickte ihn zur Kaserne – der Bauernhof blieb immer wieder halb fertig liegen. Wenn du "untätige/nicht bauende" Einheiten auswählst, nimm diese Funktion statt u.order.

Mechanismus Order aus dem Snapshot + gerade angenommene Befehle dieses Prozesses (Quittungen)

Ob das aktuelle Gold/Holz für code reicht (Einheiten, Gebäude; nach den Preisen in units.json). Was nicht in der Preistabelle steht, gilt immer als bezahlbar. ⚠ Die Vier-Zeichen-Codes für Tier-ups haben in der Tabelle kumulierte Preise, hier fällt das Ergebnis also eher vorsichtig aus; maßgeblich ist letztlich die Quittung der Engine.

Mechanismus Eigene Ressourcen aus dem Push-Snapshot + Preise aus units.json

Daten der gerade gespielten Karte (openwar3.mapdata.MapData): name_of('HC07') liefert Namen eigener Einheiten/Gegenstände/Fähigkeiten, dazu hero_names, tooltip. Einheiten auf RPG-Karten sind meist von der Karte selbst definiert und fehlen in der eingebauten Namenstabelle; wurde das Spiel nicht vom Launcher gestartet (Kartendatei nicht auffindbar), kommt None zurück.

Mechanismus Kartendatei (Pfad aus --map des Launchers): w3u/w3t/w3a + wts, bei geschützten Karten die TXT-Dateien in der Karte

Fasst die Befehle eines Ticks zu einem Batch zusammen: with g.batch() as b: g.attack(archers, target) # liefert Pending, wird erst nach dem Block zur Quittung g.move(wounded, *home) g.cast(hero, "thunderclap") print(b.sent, b.wait_ms, [r.reason for r in b.receipts]) Jeder einzeln gesendete Befehl wartet einmal auf den Spiel-Thread (ca. 10 ms); ein Batch wartet nur einmal – damit kam das Referenz-Brain am 09-23 pro Runde von 48 -> 26 ms. * Die Claim-Prüfung läuft weiterhin pro Befehl (gehaltene Einheiten bekommen sofort eine held-Quittung und kommen nicht in den Batch); * Befehle im Block liefern Pending: .ok vor dem Ende des Blocks zu lesen löst eine Exception aus (die Quittung existiert noch nicht), danach wie eine Receipt verwenden; * Exception im Block = der ganze Batch verfällt (status 97 cancelled), gehaltene Einheiten werden zurückgegeben; * Abfragen (can_do / tech / visible …) sowie build_near und buy kommen nicht in den Batch, sondern werden wie bisher sofort gestellt – ihre Ergebnisse werden sofort gebraucht; viele auf einmal abfragen mit can_do_many / tech_many; * verschachtelte with g.batch() gehen im äußersten Batch auf; über 16 Befehle teilt die Runtime automatisch in mehrere Abschnitte (je Abschnitt ein Warten).

Mechanismus Befehle im Block werden zu einem Batch gesammelt und am Ende des Blocks auf einmal eingereicht (im selben Frame ausgeführt, nur einmal auf den Spiel-Thread warten)

Nach (x,y) gehen, unterwegs nicht angreifen (für Rückzüge). Nimmt eine Einheit oder eine Liste (Befehl im selben Frame). queue='after': erst die aktuelle Aufgabe erledigen, dann gehen (hinter die aktuelle Order eingereiht). Quittung values[0] = wie viele Orders die Einheit nach dem Befehl in der Warteschlange hat (inkl. der aktuellen).

Mechanismus W3P point: move (extra-Bit = Art des Anstellens)

Angriffsbewegung (A auf den Boden): unterwegs angreifen, was auftaucht. queue wie bei move.

Mechanismus W3P point: attack auf Punkt

target angreifen. Standardmäßig per Rechtsklick (auf Gegner = genau diesen angreifen; am 09-23 gemessen: Order-Ziel und Aufgabenziel sind beide diese Einheit). ⚠ Das Ziel muss in Sicht sein, Unsichtbares wird abgelehnt (Grundcode 1001). force=True nutzt den Angriffsbefehl 0x0F (nötig für eigene Einheiten/neutrale Kleintiere) – gemessen: Er setzt nur die Angriffs-Order und merkt sich das Ziel nicht, die Einheit greift dann andere Gegner in der Nähe an. Für ein bestimmtes Ziel nicht verwenden.

Mechanismus W3P target: Zielbefehl (Rechtsklick smart)

Alles anhalten (Order-ID 0x000D0004), auch eingereihte Orders werden gelöscht.

Mechanismus W3P immediate: stop

Position halten (nicht hinterherlaufen, nur Ziele in Reichweite angreifen).

Mechanismus W3P immediate: holdposition

Zwischen aktueller Position und (x,y) patrouillieren.

Mechanismus W3P point: patrol

Boden angreifen: Artillerie feuert auf eine Fläche (unsichtbare Einheiten und Gegner hinter Bäumen treffen, einen Engpass sperren). Nur Einheiten, die den Boden angreifen können, nehmen den Befehl an.

Mechanismus W3P point: attackground (Belagerungseinheiten / Mörsertrupp / Katapult)

Abbrechen: letzter Platz der Trainings-/Forschungswarteschlange (Geld zurück), Gebäude im Bau (75 % zurück), Hauptgebäude im Upgrade.

Mechanismus W3P immediate: cancel

Eine Reihe von Punkten nacheinander abgehen (Shift-Wegpunkte: Wegpunkte, Türme umgehen, Aufklärungsrouten). attack=True: jeder Abschnitt ist eine Angriffsbewegung. Einmal eingereicht; eine Quittung pro Punkt (in der Reihenfolge von points).

Mechanismus Ein Batch: der erste Abschnitt wird sofort ausgeführt, der Rest in umgekehrter Reihenfolge mit queue='after' eingefügt (die Engine kann nur hinter der aktuellen Order einfügen)

Gold sammeln/Holz fällen (target ist eine Goldmine oder ein Baum aus trees()). ⚠ Nur untätigen Arbeitern zuweisen (idle_workers): Gibst du einem Arbeiter mit Aufgabe den Befehl erneut, unterbricht das den Sammelzyklus. Profi-Nutzung: nach dem Bauen zurück zur Mine = nach build(...) gather(worker, mine, queue='after').

Mechanismus W3P target: harvest (Goldmine oder Baum)

Reparieren / beim Bau helfen (Baustellen der Menschen und Orcs stehen still, wenn niemand daran baut).

Mechanismus W3P target: repair

Lässt den Arbeiter code bei (x,y) bauen (Koordinaten auf 32 ausgerichtet). Quittung angenommen = die Order des Arbeiters ist bereits dieses Gebäude (oder der Baubeginn-Befehl); mit queue='after' = in die Order-Warteschlange des Arbeiters eingereiht (Quittung values[0] = Anzahl in der Warteschlange). ⚠ Angenommen ≠ baubar: Auch einen Punkt im Wald nimmt die Engine sofort an, der Arbeiter scheitert erst, wenn er dort ankommt (am 09-23 gemessen); wird das Geld anderswo ausgegeben, erscheint die Baustelle ebenfalls nicht. Weißt du nicht, wo Platz ist, nimm build_near (verfolgt das Ergebnis, sperrt gescheiterte Punkte). Mehrere hintereinander: build_queue.

Mechanismus W3P build: Bau-Order, im selben Frame wird die Order des Arbeiters zur Bestätigung zurückgelesen

Ein Arbeiter baut mehrere Gebäude nacheinander (Shift-Bauen): plan = [(Vier-Zeichen-Code, x, y), ...]. Einmal eingereicht; Quittungen in der Reihenfolge von plan. ⚠ Das Geld wird erst bei Baubeginn abgezogen (nicht beim Einreihen) – sind 3 Gebäude eingereiht, reicht das Geld aber nur für 1, scheitern die beiden anderen, wenn der Arbeiter dort ankommt.

Mechanismus Ein Batch: das erste Gebäude sofort, der Rest in umgekehrter Reihenfolge mit queue='after'

Sucht um (x,y) von nah nach fern einen freien Platz und baut dort code. **Blockiert nicht**, kann in jedem Tick aufgerufen werden: * Für diesen Gebäudetyp läuft noch ein Versuch (Arbeiter unterwegs) -> liefert diesen Punkt, ohne den Befehl zu wiederholen; * der letzte Versuch hat geklappt (Baustelle erschienen) -> sucht bei Bedarf einen neuen Punkt; * der letzte Versuch ist gescheitert (Arbeiter merkt erst vor Ort, dass kein Platz ist, die Engine zieht die Order zurück, keine Baustelle) -> dieser Punkt wird 45 Sekunden gesperrt, weiter mit dem nächsten; * nicht genug Geld -> liefert direkt None (kein Versuch, keine Sperre); alle Punkte ausprobiert -> None. ⚠ Warum verfolgen: am 09-23 im Live-Spiel nahm die Engine Punkte im Wald **sofort an**, der Arbeiter scheiterte erst vor Ort (die Quittung im selben Frame kann das nicht erkennen); und die Bauplatzprüfung der Engine liefert für Arbeiter, die ein Gebäude bauen, immer 221, man kann also nicht erst "prüfen" und dann bauen. Nur offensichtlich belegte Punkte (mitten im Hauptgebäude) werden sofort abgelehnt.

Mechanismus build Punkt für Punkt + Verfolgung (Baustelle erscheint = Erfolg; Arbeiter gibt die Order auf und es gibt keine Baustelle = dieser Punkt wird gesperrt)

Einheit trainieren / Technologie erforschen / Hauptgebäude aufwerten (Tier-up = dem Hauptgebäude selbst den Vier-Zeichen-Code des Zielgebäudes geben, z. B. 'hkee'). Bei Ablehnung sagt reason in der Quittung, warum (nicht genug Nahrung, Gold fehlt, Holz fehlt, Warteschlange voll, Voraussetzung fehlt …).

Mechanismus W3P immediate: Vier-Zeichen-Code, bei Ablehnung mit Grundcode der Machbarkeitsprüfung

Held lernt eine Fähigkeit (Vier-Zeichen-Code, z. B. 'AHbz' Blizzard).

Mechanismus W3P learn: gilt erst als gelernt, wenn die Fertigkeitspunkte sinken

Zauber wirken. spell ist ein Order-String ('thunderbolt' Sturmblitz, 'blizzard', 'holybolt' Heiliges Licht …, siehe data/order-ids.txt) oder eine Order-ID. Mit target = auf eine Einheit; mit x,y = auf den Boden; ohne beides = ohne Ziel (Donnerknall, Gottesschild, Wasserelementar beschwören). Eine angenommene Quittung heißt nur, dass die Engine akzeptiert hat; ob der Zauber gewirkt wurde, zeigt cooldown() (Abklingzeit läuft) bzw. buffs() (Buff erscheint).

Mechanismus W3P target / point / immediate (je nach Parametern)

Sammelpunkt setzen (auf einen Punkt oder auf eine Einheit/Goldmine).

Mechanismus W3P rally

Toten Helden am Altar wiederbeleben (ohne hero wird der erste der Liste wiederbelebt). Häufige Ablehnungsgründe (stehen in reason der Quittung): nicht genug Nahrung (auch Helden kosten Nahrung), nicht genug Geld, gerade erst gestorben (erst etwa 3 Spielsekunden nach dem Tod möglich), Wiederbelebung läuft bereits (beim Annehmen räumt die Engine diesen Slot sofort).

Mechanismus W3P revive: Liste toter Helden -> der Altar wirkt Wiederbeleben auf den toten Helden

Held hebt einen Gegenstand vom Boden auf (item aus items_on_ground). Danach erscheint er im Inventar, und am Boden wird das Event item.removed ausgelöst.

Mechanismus W3P target: Rechtsklick auf Gegenstand

Gegenstand in Inventarplatz slot (0~5) benutzen; optional mit Zieleinheit oder Zielpunkt. ⚠ Bei Gegenständen auf einen Punkt (z. B. Elfenbeinturm) liefert die Engine auch bei Erfolg 0, die Quittung gilt immer als angenommen – prüf, ob der Inventarplatz leer geworden ist.

Mechanismus W3P use_item (nach Platznummer)

Den Gegenstand aus Inventarplatz slot bei (x,y) ablegen (der Held geht hin und legt ihn ab).

Mechanismus W3P item_drop (nach JASS UnitDropItemPoint: dropitem 0xD0021 auf Punkt + Gegenstand als unmittelbares Ziel)

Den Gegenstand aus Inventarplatz slot an to übergeben (anderer Held / Einheit; der Held geht hin und übergibt ihn). An einen Laden = verkaufen (siehe sell_item).

Mechanismus W3P item_drop (nach JASS UnitDropItemTarget: dropitem auf Einheit)

Den Gegenstand aus Inventarplatz slot an einen Laden verkaufen (der Held muss neben dem Laden stehen; nur verkaufbare Gegenstände werden angenommen, zum halben Preis).

Mechanismus Wie give_item, Ziel ist ein Laden (gemessen: Staff of Sanctuary für 125 Gold verkauft)

Inventarplatz wechseln (Platz slot auf Platz to_slot verschieben; sind beide belegt, werden sie getauscht). Zum Sortieren der Hotkey-Belegung.

Mechanismus W3P target: Order 0xD0022+Platznummer, Ziel = Gegenstand (nach JASS UnitDropItemSlot)

Gegenstand im Laden kaufen (für den Helden, der neben dem Laden steht). Fehlt eine Tech-Voraussetzung, liefert die Engine 0 und zieht kein Geld ab.

Mechanismus W3P buy: der Laden verkauft an einen Helden daneben

Zu den Waffen (Menschen): Bauern werden zur Miliz (das Rathaus auf Stufe 1 hat diese Fähigkeit nicht, nur Bergfried/Schloss).

Mechanismus W3P immediate: townbellon/off

Oberfläche & Eingabe (openwar3.ui.UI): klickbare Buttons und Auswahlkarten, Hotkeys, Position per Klick auf den Boden wählen, lesen, worauf die Maus zeigt. Der Klick auf einen Button kommt beim Spiel nicht an; rein lokale Eingabe + lokales Zeichnen, auch im Multiplayer sicher.

Mechanismus W3P 74 input_enable + Shared Memory Local\War3Input_<pid> (die Runtime empfängt die Fenstereingaben)

Spielgeschwindigkeit (100 = normale Geschwindigkeit).

Mechanismus Aktion 47 (25~800%)

Spiel pausieren / fortsetzen. In der Pause steht die Engine-Uhr still, über die Schnellspur lassen sich weiterhin Befehle erteilen (der Event-Dispatch läuft weiter).

Mechanismus W3P pause

Veröffentlichungsperiode des Weltzustands (16~1000 Millisekunden, Standard 50). Eine Erfassung kostet etwa 0.5 ms, auch 33 ms sind kein Problem; der Wert gilt für den ganzen Rechner, wer zuletzt schreibt, gewinnt.

Mechanismus Weltblock requestedPeriodMs

Über der Einheit erscheint eine Chat-Sprechblase (für Streams/Debugging, beeinflusst das Spiel nicht). Gibt False zurück, wenn keine Sprechblase erschienen ist; der Grund steht in g.last_say_error.

Mechanismus Aktion 56

Schreibt eine Zeile in den Nachrichtenbereich unten links im Spiel (nur lokal sichtbar). Funktioniert erst, nachdem das Spiel selbst einmal einen Hinweis angezeigt hat (die DLL greift das Nachrichtenfeld bei dieser Gelegenheit ab).

Mechanismus Aktion 45

Beendet diesen Spielprozess (farm.py --keep startet anhand von next_game.json automatisch die nächste Partie).

Mechanismus Aktion 22

Canvas: zeichnet Textfelder, Panels, Fortschrittsbalken, Bilder sowie Kreise und Routen auf dem Boden ins Spielbild (openwar3.canvas.Canvas). Die Runtime zeichnet selbst, legt keine Spiel-Handles an und ändert den Spielzustand nicht – auch im Multiplayer sicher; Stil frei wählbar (chinesische Schrift, abgerundete Ecken, Transparenz).

Mechanismus W3P 73 canvas_enable + Shared Memory Local\War3Canvas_<pid> (die Runtime zeichnet in jedem Frame, bevor das Spiel den Mauszeiger zeichnet; der Mauszeiger liegt darüber)

Drückt auf dem Ladebildschirm „Beliebige Taste drücken, um fortzufahren“ einmal die Leertaste. Viele RPG-/Story-Karten starten nach dem Laden erst auf Tastendruck (09-24 mit WarChasers gemessen: ohne Tastendruck bleibt das Spiel im Ladebildschirm, Spieluhr 0, die Schnellspur wird nicht geleert). openwar3.run drückt beim Warten auf den Spielbeginn selbst, manuell ist das meist nicht nötig.

Mechanismus PostMessage WM_KEYDOWN/UP Leertaste an das Spielfenster (ohne den Fokus zu stehlen)

Beliebige JASS-Natives per Name aufrufen: g.jass.CreateUnit(g.jass.Player(1), "Hpal", x, y, 270.0). Parameter I/R/B/S/H werden automatisch konvertiert (Einheiten-/Gegenstandsobjekte direkt übergeben); im Multiplayer sind nur lesende Natives erlaubt. Details in openwar3/jass.py und docs/COMPANION_ZH.md.

Mechanismus W3P 70 jass (die Runtime sucht die Native per Name in der Native-Tabelle, 1291 Stück)

Die 16 Spielerslots: controller (user = echter Spieler / computer / neutral …), state (empty / playing / left), human, me, ally (ob mit mir verbündet). Auf RPG-Karten damit einen freien Slot für den Begleiter finden oder prüfen, ob es ein Einzelspielerspiel ist.

Mechanismus JASS GetPlayerController / GetPlayerSlotState / IsPlayerAlly

Erzeugt eine Einheit bei (x,y) (player standardmäßig der lokale Spieler) und liefert die Einheit aus dem Snapshot (nach der nächsten Weltveröffentlichung, ca. 50 ms); klappt es nicht, None. Die gelieferte Einheit hat zusätzlich das Attribut jass_handle. ⚠ Nur im Einzelspieler nutzbar (im Multiplayer Desync).

Mechanismus JASS CreateUnit + W3P 72 Handle -> Einheit

Bündnis von Spieler a gegenüber b setzen: allied = greifen sich nicht an + rufen sich gegenseitig zu Hilfe; vision teilt die Sicht; control teilt die Einheitensteuerung (b kann die Einheiten von a befehligen); xp teilt Erfahrung. both=True setzt beide Richtungen (control nur a -> b).

Mechanismus JASS SetPlayerAlliance

Ändert den Spielernamen (den in Punktetafel, Chat und Verbündeten-Panel angezeigten). Zum Benennen des Begleiters.

Mechanismus JASS SetPlayerName

Zeigt unten links auf dem Bildschirm eine Textzeile an (wie sie Karten-Trigger verwenden), standardmäßig für den lokalen Spieler. Unterstützt |cffRRGGBB-Farbcodes.

Mechanismus JASS DisplayTimedTextToPlayer

Verbindungsstatus: pid, Weltveröffentlichung (Periode, Erfassungsdauer), Zähler der Schnellspur.

Mechanismus Weltblock + Schnellspur + Claim-Tabelle

Der Kandidat, der to (Einheit oder (x,y)) am nächsten ist; ohne Kandidaten None.

Mechanismus Reine Berechnung