Tileset / Autotiles #118

Closed
opened 2026-09-17 20:15:08 +02:00 by admin · 3 comments

Ich will es einfach halten, darum die Files im Anhang (RPG Maker MZ Files, Mehrere Tiles in einem File) - wieviele Autotiles in einer Texture sind ist egal, entscheidend ist ein Frame in der Texture (oder im die komplette texture wenn es nur ein autotile ist). Man soll dann zwischen verschiedene Arten von von Autotiles auswählen können.

Outside_A1 und Outside_A2 sind ähnlich mit dem Unterschied dass A1 animiert ist (besteht aus 3 Frames). da müssten wir uns überlegen wie wir das definieren kann. klassisch natürlich 1 frame (keine animation), aber es soll frei wählbar sein wieviele frame, folgender vorschlag

eigenes asset: Autotile - dort wählt man die textures/frames aus und entscheidet zwischen loop oder pingpong und natürlich der framerate. außerdem auch die art des autotile, gibt glaube ich nur 2 möglichkeiten, wie bei A1/A2, oder A3 (ist eine abgespeckte version von (A1/A2, dach ist ein eigenes autotile und die wand ein eigenes) A4 ist eine kombination aus beidem (A2, A3).

diese autotiles dann verwenden muss dann über eine tilemap funktionieren. aber das behandeln wir in einem (noch existenten) folge issue.

Ich will es einfach halten, darum die Files im Anhang (RPG Maker MZ Files, Mehrere Tiles in einem File) - wieviele Autotiles in einer Texture sind ist egal, entscheidend ist ein Frame in der Texture (oder im die komplette texture wenn es nur ein autotile ist). Man soll dann zwischen verschiedene Arten von von Autotiles auswählen können. `Outside_A1` und `Outside_A2` sind ähnlich mit dem Unterschied dass A1 animiert ist (besteht aus 3 Frames). da müssten wir uns überlegen wie wir das definieren kann. klassisch natürlich 1 frame (keine animation), aber es soll frei wählbar sein wieviele frame, folgender vorschlag eigenes asset: Autotile - dort wählt man die textures/frames aus und entscheidet zwischen loop oder pingpong und natürlich der framerate. außerdem auch die art des autotile, gibt glaube ich nur 2 möglichkeiten, wie bei A1/A2, oder A3 (ist eine abgespeckte version von (A1/A2, dach ist ein eigenes autotile und die wand ein eigenes) A4 ist eine kombination aus beidem (A2, A3). diese autotiles dann verwenden muss dann über eine tilemap funktionieren. aber das behandeln wir in einem (noch existenten) folge issue.
admin added this to the Development project 2026-09-17 20:15:08 +02:00
admin moved this to Next in Development on 2026-09-17 20:17:15 +02:00
Owner

Entscheidungen (durchgeplant, noch nichts gebaut)

  1. Die Art wird explizit gewählt, nicht geraten: Floor (2×3-Block) oder Wall (2×2-Block).
    Outside_A4 ließe sich zwar raten (die Zeilen wechseln sich ab, erste Zeile verhält sich wie
    Floor, zweite wie Wall) — die explizite Wahl ist trotzdem die sauberere Lösung.
  2. Der Grid-Slicer wird dafür nicht erweitert. Was er nicht in einem Rutsch schneidet
    (Outside_A4, ungleiche Zeilenhöhen), schneidet man von Hand bzw. in zwei Durchgängen.
  3. Eigenes Asset autotile, nicht Teil der Tilemap — dasselbe Autotile kommt in mehreren
    Tilemaps vor.
  4. Umfang dieses Issues: Asset + eigener Tab mit Vorschau. Die Tilemap (Platzieren, Malen,
    Scene-View) ist komplett das Folge-Issue #128. Bis dahin ist ein Autotile nur in seinem
    eigenen Tab sichtbar.

Gemessen an den Anhängen

Tilegröße ist überall 48 px.

Datei Größe Blöcke Einträge in der .txt
Outside_A1 768×576 8×4 Blöcke à 2×3 Tiles (96×144) 16
Outside_A2 768×576 8×4 Blöcke à 2×3 Tiles 32
Outside_A3 768×384 8×4 Blöcke à 2×2 Tiles (96×96) 32
Outside_A4 768×720 Zeilen abwechselnd 2×3 und 2×2 48 (24 + 24)
  • A1 ist animiert, 3 Blöcke nebeneinander: Block 0/1/2 der ersten Zeile unterscheiden sich nur
    in 13 % der Pixel (die Wasseroberfläche), Block 3 zu 99,9 % — dort beginnt die nächste Art.
    Die Frames liegen also horizontal.
  • Es gibt nur zwei Arten: der 2×3-Block (A1/A2, Boden, mit Innenecken) und der 2×2-Block
    (A3, Wand/Dach, ohne Innenecken). A4 ist keine dritte Art, sondern beide in einer Datei.
  • Die .txt sind nur die Namenslisten aus dem MZ-Editor (Englisch|Japanisch), keine Geometrie.

Zu bauen

Modell (src/core/model/Asset.ts, neu src/core/model/autotile.ts):

interface AutotileAsset extends AssetBase {
  type: 'autotile';
  kind: 'floor' | 'wall';   // 2×3-Block bzw. 2×2-Block
  pictures: string[];       // Texture- oder Frame-Ids, Reihenfolge = Animationsreihenfolge
  mode: 'loop' | 'pingpong';
  fps: number;
}
  • Eine Frame-Id meint den ausgeschnittenen Block, eine Asset-Id die ganze Textur (für den Fall,
    dass nur ein Autotile in der Datei liegt).
  • Ein Bild = keine Animation. Drei Bilder wie bei Outside_A1 sind drei Animationsschritte;
    mode und fps zählen erst ab zwei Bildern.
  • autotile kommt in ASSET_TYPES und ist nicht platzierbar (wie texture/animation) —
    platziert wird die Tilemap aus #128.
  • Geprüft wird: Seitenverhältnis passend zur Art (Floor 2:3, Wall 1:1), Kantenlängen durch 4
    teilbar (Quadranten sind Viertelkacheln, bei 48 px also 24 px), alle Bilder einer Animation
    gleich groß. Passt etwas nicht, meldet es der Tab — verworfen wird nichts.
  • Zusammensetzen nach dem klassischen RPG-Maker-Schema aus Viertelkacheln: Floor 47
    Kombinationen (mit Innenecken), Wall 16 (ohne). Das Mapping wird beim Bauen an den vier
    angehängten PNGs verifiziert, nicht aus dem Gedächtnis geschrieben.
  • Serialisierung (serialize.ts) und usages.ts: ein Autotile hält Texture-/Frame-Ids, das Löschen
    einer Textur muss sich also melden.

Tab „Autotile" (src/editor/autotile/, auf Basis von AssetTabEditor,
siehe src/editor/AssetTabEditor.ts:39 — Picker, Fit und Readout kommen von dort):

  • Bilderstreifen: hinzufügen (Frame-Picker), entfernen, sortieren.
  • Felder: Art (Floor/Wall), mode (loop/pingpong), fps.
  • Vorschau: alle Kombinationen der Art als beschriftetes Raster und ein zusammengesetztes
    Beispielmuster, beides animiert mit der eingestellten Rate.
  • Readout: Art, Kachelgröße, Anzahl Bilder; bei ungültiger Größe eine Meldung statt einer Zahl.
  • Alle Änderungen über Kommandos mit Undo, wie bei den übrigen Asset-Tabs.

Tests: Unit-Tests für Validierung, Kombinationsindex → Quadranten und den Animationsschritt
(inkl. pingpong); ein neues e2e-Modul (Autotile anlegen, Frames zuweisen, Art umstellen,
Vorschau zählen, Undo). Doku: Wiki-Seite Autotiles.md, Einträge in Home.md/_Sidebar.md,
Check-Summe in README und Development.md.

Noch offen (mit Vorschlag)

  • Kachelgröße: aus dem Bild ableiten (Blockbreite / 2) statt als eigenes Feld. Bei allen vier
    Anhängen ergibt das 48 px. Vorschlag: ableiten, kein Feld.
  • Wall/Dach: In MZ ist bei A3/A4 das Dach ein eigenes Autotile und die Wand ein eigenes —
    das fällt hier automatisch raus, weil jedes Autotile-Asset genau einen Block meint.
## Entscheidungen (durchgeplant, noch nichts gebaut) 1. **Die Art wird explizit gewählt**, nicht geraten: `Floor` (2×3-Block) oder `Wall` (2×2-Block). `Outside_A4` ließe sich zwar raten (die Zeilen wechseln sich ab, erste Zeile verhält sich wie Floor, zweite wie Wall) — die explizite Wahl ist trotzdem die sauberere Lösung. 2. **Der Grid-Slicer wird dafür nicht erweitert.** Was er nicht in einem Rutsch schneidet (`Outside_A4`, ungleiche Zeilenhöhen), schneidet man von Hand bzw. in zwei Durchgängen. 3. **Eigenes Asset `autotile`**, nicht Teil der Tilemap — dasselbe Autotile kommt in mehreren Tilemaps vor. 4. **Umfang dieses Issues:** Asset + eigener Tab mit Vorschau. Die Tilemap (Platzieren, Malen, Scene-View) ist komplett das Folge-Issue #128. Bis dahin ist ein Autotile nur in seinem eigenen Tab sichtbar. ## Gemessen an den Anhängen Tilegröße ist überall 48 px. | Datei | Größe | Blöcke | Einträge in der `.txt` | |---|---|---|---| | `Outside_A1` | 768×576 | 8×4 Blöcke à 2×3 Tiles (96×144) | 16 | | `Outside_A2` | 768×576 | 8×4 Blöcke à 2×3 Tiles | 32 | | `Outside_A3` | 768×384 | 8×4 Blöcke à 2×2 Tiles (96×96) | 32 | | `Outside_A4` | 768×720 | Zeilen abwechselnd 2×3 und 2×2 | 48 (24 + 24) | - **A1 ist animiert, 3 Blöcke nebeneinander:** Block 0/1/2 der ersten Zeile unterscheiden sich nur in 13 % der Pixel (die Wasseroberfläche), Block 3 zu 99,9 % — dort beginnt die nächste Art. Die Frames liegen also horizontal. - Es gibt nur zwei Arten: der 2×3-Block (A1/A2, Boden, mit Innenecken) und der 2×2-Block (A3, Wand/Dach, ohne Innenecken). A4 ist keine dritte Art, sondern beide in einer Datei. - Die `.txt` sind nur die Namenslisten aus dem MZ-Editor (Englisch|Japanisch), keine Geometrie. ## Zu bauen **Modell** (`src/core/model/Asset.ts`, neu `src/core/model/autotile.ts`): ```ts interface AutotileAsset extends AssetBase { type: 'autotile'; kind: 'floor' | 'wall'; // 2×3-Block bzw. 2×2-Block pictures: string[]; // Texture- oder Frame-Ids, Reihenfolge = Animationsreihenfolge mode: 'loop' | 'pingpong'; fps: number; } ``` - Eine Frame-Id meint den ausgeschnittenen Block, eine Asset-Id die ganze Textur (für den Fall, dass nur ein Autotile in der Datei liegt). - **Ein Bild = keine Animation.** Drei Bilder wie bei `Outside_A1` sind drei Animationsschritte; `mode` und `fps` zählen erst ab zwei Bildern. - `autotile` kommt in `ASSET_TYPES` und ist **nicht platzierbar** (wie `texture`/`animation`) — platziert wird die Tilemap aus #128. - **Geprüft wird:** Seitenverhältnis passend zur Art (Floor 2:3, Wall 1:1), Kantenlängen durch 4 teilbar (Quadranten sind Viertelkacheln, bei 48 px also 24 px), alle Bilder einer Animation gleich groß. Passt etwas nicht, meldet es der Tab — verworfen wird nichts. - **Zusammensetzen** nach dem klassischen RPG-Maker-Schema aus Viertelkacheln: Floor 47 Kombinationen (mit Innenecken), Wall 16 (ohne). Das Mapping wird beim Bauen an den vier angehängten PNGs verifiziert, nicht aus dem Gedächtnis geschrieben. - Serialisierung (`serialize.ts`) und `usages.ts`: ein Autotile hält Texture-/Frame-Ids, das Löschen einer Textur muss sich also melden. **Tab „Autotile"** (`src/editor/autotile/`, auf Basis von `AssetTabEditor`, siehe `src/editor/AssetTabEditor.ts:39` — Picker, Fit und Readout kommen von dort): - Bilderstreifen: hinzufügen (Frame-Picker), entfernen, sortieren. - Felder: Art (`Floor`/`Wall`), `mode` (`loop`/`pingpong`), `fps`. - Vorschau: alle Kombinationen der Art als beschriftetes Raster **und** ein zusammengesetztes Beispielmuster, beides animiert mit der eingestellten Rate. - Readout: Art, Kachelgröße, Anzahl Bilder; bei ungültiger Größe eine Meldung statt einer Zahl. - Alle Änderungen über Kommandos mit Undo, wie bei den übrigen Asset-Tabs. **Tests:** Unit-Tests für Validierung, Kombinationsindex → Quadranten und den Animationsschritt (inkl. `pingpong`); ein neues e2e-Modul (Autotile anlegen, Frames zuweisen, Art umstellen, Vorschau zählen, Undo). Doku: Wiki-Seite `Autotiles.md`, Einträge in `Home.md`/`_Sidebar.md`, Check-Summe in README und `Development.md`. ## Noch offen (mit Vorschlag) - **Kachelgröße:** aus dem Bild ableiten (Blockbreite / 2) statt als eigenes Feld. Bei allen vier Anhängen ergibt das 48 px. Vorschlag: ableiten, kein Feld. - **Wall/Dach:** In MZ ist bei A3/A4 das Dach ein eigenes Autotile und die Wand ein eigenes — das fällt hier automatisch raus, weil jedes Autotile-Asset genau einen Block meint.
Owner

Umgesetzt in 1a9f07c

Asset-Typ autotile plus eigener Tab, wie in der Spezifikation oben entschieden. Die Tilemap bleibt in #128.

Das Quadranten-Mapping

Nicht aus dem Gedächtnis geschrieben, sondern an den Anhängen dieses Issues hergeleitet: Block aus Outside_A2 vergrößert, Quadrantenraster drübergelegt, daraus das Modell gebaut und ein Testmuster gerendert (Ring mit Loch und Stufe) — Kanten laufen nahtlos durch, Innenecken sitzen an den konkaven Stellen. Dasselbe mit zwei verschiedenen Blöcken aus Outside_A3 (Wall), um links/rechts nicht zu vertauschen.

  • Floor = 47 Kacheln, Wall = 16, beides ausgezählt.
  • Das Modell ist semantisch (Füllung, Kante waagerecht/senkrecht, Außenecke, Innenecke je Ecke), keine 48-Zeilen-Tabelle.
  • Die vier Quadranten der oberen rechten Kachel eines Floor-Blocks werden nicht genutzt: dort steht in den MZ-Blättern schlichter Untergrund.

Gebaut

  • autotile in ASSET_TYPES, nicht platzierbar (wie Texture/Animation). pictures ist eine Liste von Textur- oder Frame-Ids, ein Bild je Animationsschritt.
  • Abweichung vom Entwurf: kind, fps und playback sind Properties, nicht Felder am Asset. Damit zeigt der Inspector sie von selbst, mit Undo und Gold-Markierung — derselbe Weg, den Animation und Texture schon gehen. Die Art gibt es zusätzlich als Dropdown im Tab-Header.
  • Kachelgröße wird abgeleitet (Blockbreite / 2). Geprüft werden Blockform, Teilbarkeit durch 4 und gleiche Größe aller Schritte; ein Bild, das nicht passt, bleibt stehen und wird benannt.
  • Tab „Autotile" auf Basis von AssetTabEditor: alle Kacheln als beschriftetes Raster (NESW-nw, ·), darunter das zusammengesetzte Beispielmuster, beides animiert. Ziehen schiebt, Rad zoomt, Fit rahmt. Rechts die Bilderliste mit + Picture, Remove und Umsortieren per Drag, je ein Undo-Schritt.
  • Ping-pong dreht auf dem letzten Bild um (0 1 2 1).
  • Ein Autotile zählt als Nutzung seiner Textur: der Löschdialog nennt es mit.

Tests (lokal)

npm run check                              → 95 Files, 1276 Tests (vorher 1256), CHECK EXIT 0
npm run build                              → BUILD EXIT 0
GM_STEPS=39 (frisch geseedet)              → ALL PASSED – 20 checks
GM_STEPS=1-16,19,23,25,26,31,36,37,38,39   → ALL PASSED – 698 checks
  • 20 neue Unit-Tests: Kachelzahlen und ihre Eindeutigkeit, die vier Eckfälle, dass eine Wand Diagonalen ignoriert, Beschriftungen, Geometrie aus Textur und aus Frame, die drei Fehlermeldungen, Animationsschritt, Kommandos mit Undo, Serialisierung samt Müll in der Liste, dazu 3 Tests für die Umsortier-Arithmetik.
  • Gegenprobe mit 4 absichtlich eingebauten Fehlern: Diagonale ignorieren (4 Tests fallen), waagerechte/senkrechte Kante vertauscht (1), Größenprüfung aus (1), Undo des Verschiebens in dieselbe Richtung (1). Originale danach zurückgespielt und per cmp geprüft.
  • e2e-Modul 39 (18 eigene Checks): Es zeichnet sein Blatt selbst und fügt es als Bild ein, jede Viertelkachel in eigener Farbe. Die Checks lesen Pixel vom Board und belegen damit, dass die richtige Viertelkachel in der richtigen Ecke landet — für die einsame Kachel, für eine rundum umgebene und für die Wand. Dazu Animation, Fit/Pan/Zoom, Kindwechsel mit Fehlermeldung, Bilder rein/raus, Undo und Umsortieren. Modul 04 bekommt 2 Checks (Autotile öffnen).
  • Screenshot angesehen: Raster, Beispielmuster, Bilderliste und die drei Inspector-Zeilen stehen wie geplant.

Zwei Fehlversuche, beide meine:

  1. Mein Sollwert für das Beispielmuster war falsch gerechnet (Zeile verzählt) — der Code war richtig. Der Check fragt jetzt über einen Hook nach der Zelle, statt eine Kachelnummer zu raten.
  2. Ich hatte das Autotile-Blatt zuerst in die Fixture geseedet. Das hat 26 Checks in den Modulen 04, 11, 12 und 13 gerissen: die Textur-Schritte gehen davon aus, dass die Fixture keine Textur hat. Fixture zurückgenommen, Modul 39 erzeugt sein Blatt selbst. Echter Fund dabei: Ein Drop auf die Mitte einer Zeile hob sich beim Ziehen nach unten selbst auf — behoben und durch die 3 Arithmetik-Tests abgedeckt.

Doku

Neue Wiki-Seite Autotiles.md, Einträge in Home.md und _Sidebar.md, Architecture.md und Development.md nachgezogen. Check-Summe 989 (969 + 18 + 2) in README und Development.md — gerechnet, CI auf 1a9f07c ist noch nicht gelesen.

## Umgesetzt in `1a9f07c` Asset-Typ `autotile` plus eigener Tab, wie in der Spezifikation oben entschieden. Die Tilemap bleibt in #128. ### Das Quadranten-Mapping Nicht aus dem Gedächtnis geschrieben, sondern an den Anhängen dieses Issues hergeleitet: Block aus `Outside_A2` vergrößert, Quadrantenraster drübergelegt, daraus das Modell gebaut und ein Testmuster gerendert (Ring mit Loch und Stufe) — Kanten laufen nahtlos durch, Innenecken sitzen an den konkaven Stellen. Dasselbe mit zwei verschiedenen Blöcken aus `Outside_A3` (Wall), um links/rechts nicht zu vertauschen. - **Floor** = 47 Kacheln, **Wall** = 16, beides ausgezählt. - Das Modell ist semantisch (Füllung, Kante waagerecht/senkrecht, Außenecke, Innenecke je Ecke), keine 48-Zeilen-Tabelle. - Die vier Quadranten der oberen **rechten** Kachel eines Floor-Blocks werden nicht genutzt: dort steht in den MZ-Blättern schlichter Untergrund. ### Gebaut - `autotile` in `ASSET_TYPES`, **nicht platzierbar** (wie Texture/Animation). `pictures` ist eine Liste von Textur- oder Frame-Ids, ein Bild je Animationsschritt. - **Abweichung vom Entwurf:** `kind`, `fps` und `playback` sind **Properties**, nicht Felder am Asset. Damit zeigt der Inspector sie von selbst, mit Undo und Gold-Markierung — derselbe Weg, den Animation und Texture schon gehen. Die Art gibt es zusätzlich als Dropdown im Tab-Header. - Kachelgröße wird abgeleitet (Blockbreite / 2). Geprüft werden Blockform, Teilbarkeit durch 4 und gleiche Größe aller Schritte; ein Bild, das nicht passt, bleibt stehen und wird benannt. - **Tab „Autotile"** auf Basis von `AssetTabEditor`: alle Kacheln als beschriftetes Raster (`NESW-nw`, `·`), darunter das zusammengesetzte Beispielmuster, beides animiert. Ziehen schiebt, Rad zoomt, Fit rahmt. Rechts die Bilderliste mit *+ Picture*, *Remove* und Umsortieren per Drag, je ein Undo-Schritt. - Ping-pong dreht auf dem letzten Bild um (0 1 2 1). - Ein Autotile zählt als Nutzung seiner Textur: der Löschdialog nennt es mit. ### Tests (lokal) ``` npm run check → 95 Files, 1276 Tests (vorher 1256), CHECK EXIT 0 npm run build → BUILD EXIT 0 GM_STEPS=39 (frisch geseedet) → ALL PASSED – 20 checks GM_STEPS=1-16,19,23,25,26,31,36,37,38,39 → ALL PASSED – 698 checks ``` - **20 neue Unit-Tests:** Kachelzahlen und ihre Eindeutigkeit, die vier Eckfälle, dass eine Wand Diagonalen ignoriert, Beschriftungen, Geometrie aus Textur und aus Frame, die drei Fehlermeldungen, Animationsschritt, Kommandos mit Undo, Serialisierung samt Müll in der Liste, dazu 3 Tests für die Umsortier-Arithmetik. - **Gegenprobe mit 4 absichtlich eingebauten Fehlern:** Diagonale ignorieren (4 Tests fallen), waagerechte/senkrechte Kante vertauscht (1), Größenprüfung aus (1), Undo des Verschiebens in dieselbe Richtung (1). Originale danach zurückgespielt und per `cmp` geprüft. - **e2e-Modul 39 (18 eigene Checks):** Es zeichnet sein Blatt selbst und fügt es als Bild ein, jede Viertelkachel in eigener Farbe. Die Checks lesen **Pixel vom Board** und belegen damit, dass die richtige Viertelkachel in der richtigen Ecke landet — für die einsame Kachel, für eine rundum umgebene und für die Wand. Dazu Animation, Fit/Pan/Zoom, Kindwechsel mit Fehlermeldung, Bilder rein/raus, Undo und Umsortieren. Modul 04 bekommt 2 Checks (Autotile öffnen). - Screenshot angesehen: Raster, Beispielmuster, Bilderliste und die drei Inspector-Zeilen stehen wie geplant. **Zwei Fehlversuche, beide meine:** 1. Mein Sollwert für das Beispielmuster war falsch gerechnet (Zeile verzählt) — der Code war richtig. Der Check fragt jetzt über einen Hook nach der Zelle, statt eine Kachelnummer zu raten. 2. Ich hatte das Autotile-Blatt zuerst in die **Fixture** geseedet. Das hat 26 Checks in den Modulen 04, 11, 12 und 13 gerissen: die Textur-Schritte gehen davon aus, dass die Fixture *keine* Textur hat. Fixture zurückgenommen, Modul 39 erzeugt sein Blatt selbst. **Echter Fund dabei:** Ein Drop auf die *Mitte* einer Zeile hob sich beim Ziehen nach unten selbst auf — behoben und durch die 3 Arithmetik-Tests abgedeckt. ### Doku Neue Wiki-Seite `Autotiles.md`, Einträge in `Home.md` und `_Sidebar.md`, `Architecture.md` und `Development.md` nachgezogen. Check-Summe **989** (969 + 18 + 2) in README und `Development.md` — **gerechnet, CI auf `1a9f07c` ist noch nicht gelesen.**
admin moved this to Done in Development on 2026-09-17 21:39:14 +02:00
Owner

Nachtrag: Innenflächen und Innenecken korrigiert (0607221)

Der User hat gemeldet, dass die Innenecken und die Innenflächen beim Floor-Block (2×3) nicht stimmen. Der Befund war richtig, an zwei Stellen.

Was falsch war

  1. Die Quadranten der Innenfläche waren geometrisch naheliegend zugeordnet (obere linke Ecke der Kachel ← obere linke Viertelkachel der Innenfläche). RPG Maker nimmt sie um eine halbe Kachel gedreht: die obere linke Ecke bekommt die Viertelkachel unten rechts. Nur so treffen an der Nahtstelle zweier Kacheln die Viertel aufeinander, die im Blatt auch nebeneinander liegen — daher die zerrissenen Flächen.
  2. Die Innenecken kamen aus der oberen linken Kachel des Blocks. Dort liegt die einzelne Kachel; die Innenecken stehen in der oberen rechten.

Herleitung statt Gedächtnis

Grundlage ist rpgmz/newdata/js/rmmz_core.js (Tilemap._addAutotile, FLOOR_AUTOTILE_TABLE, WALL_AUTOTILE_TABLE), vom User im Workspace abgelegt. Daraus ist die Semantik zurückgerechnet, keine Zahlen abgeschrieben. Drei Proben:

  • Formal: Das semantische Modell erzeugt als Menge exakt die MZ-Tabellen — Floor = Zeilen 0–46, Wall = alle 16. Keine Zeile zu viel, keine zu wenig.
  • Am echten Blatt: Outside_A2 Block 0 und Outside_A3 Block 0 mit dem korrigierten Modell zum Ringmuster zusammengesetzt und angesehen: Kanten laufen durch, Innenecken sitzen an den konkaven Stellen, kein Versatz.
  • MZ-Zeile 47 (obere linke Kachel) bleibt ungenutzt: sie ist pixelgleich mit der einzelnen Kachel aus den vier konvexen Ecken (Zeile 46), per Differenzbild geprüft, max. Abweichung 0. Es bleibt bei 47 Kacheln.

Geändert

  • src/core/model/autotile.ts: FLOOR_CORNERS und WALL_CORNERS auf die MZ-Werte, Kommentar erklärt die halbe Drehung und die Herkunft.
  • tests/core/autotile.test.ts: neuer Test, der das Modell Zeile für Zeile gegen die MZ-Tabellen stellt. Die Tabellen sind aus rmmz_core.js generiert, nicht abgetippt. Die vier alten Sollwert-Tests nachgezogen.
  • tools/e2e/39-autotile.mjs: Sollwerte der Innenfläche, dazu ein Flake-Fix (unten).
  • eslint.config.js: rpgmz/** und wiki/** werden nicht gelintet, sonst reißt der abgelegte MZ-Code das Gate (11 Fehler, 53 Warnungen). .gitignore: /rpgmz/ und /pasted-*.png.
  • Wiki Autotiles.md: die halbe Drehung und die Herkunft der Innenecken stehen jetzt dort.

Tests

npm run check                              → 95 Files, 1277 Tests (vorher 1276), CHECK EXIT 0
npm run build                              → BUILD EXIT 0
GM_STEPS=39 (frisch geseedet)              → ALL PASSED – 20 checks
GM_STEPS=1-16,19,23,25,26,31,36,37,38,39   → ALL PASSED – 698 checks
  • Gegenprobe: alte Fill-Zuordnung zurück → 3 Tests fallen; Innenecke wieder aus der linken Kachel → 2 Tests fallen. Original danach per cmp geprüft.
  • Ein echter Testfehler nebenbei: Der verkettete Lauf war zuerst rot in der Animationsprüfung — die vier Pixel wurden einzeln gelesen, und die 4-fps-Animation schaltete mittendrin um. Ein Flake, kein Befund. Schritt und Pixel werden jetzt in einem Aufruf in die Seite gelesen; danach zweimal grün.
  • Die Prüfsumme bleibt 989, es kam kein e2e-Check dazu. CI auf 0607221 ist noch nicht gelesen.

Der User hat das Ergebnis im Tab bestätigt.

### Nachtrag: Innenflächen und Innenecken korrigiert (`0607221`) Der User hat gemeldet, dass die Innenecken und die Innenflächen beim Floor-Block (2×3) nicht stimmen. Der Befund war richtig, an **zwei** Stellen. **Was falsch war** 1. Die Quadranten der **Innenfläche** waren geometrisch naheliegend zugeordnet (obere linke Ecke der Kachel ← obere linke Viertelkachel der Innenfläche). RPG Maker nimmt sie **um eine halbe Kachel gedreht**: die obere linke Ecke bekommt die Viertelkachel unten rechts. Nur so treffen an der Nahtstelle zweier Kacheln die Viertel aufeinander, die im Blatt auch nebeneinander liegen — daher die zerrissenen Flächen. 2. Die **Innenecken** kamen aus der oberen **linken** Kachel des Blocks. Dort liegt die einzelne Kachel; die Innenecken stehen in der oberen **rechten**. **Herleitung statt Gedächtnis** Grundlage ist `rpgmz/newdata/js/rmmz_core.js` (`Tilemap._addAutotile`, `FLOOR_AUTOTILE_TABLE`, `WALL_AUTOTILE_TABLE`), vom User im Workspace abgelegt. Daraus ist die Semantik zurückgerechnet, keine Zahlen abgeschrieben. Drei Proben: - **Formal:** Das semantische Modell erzeugt als Menge exakt die MZ-Tabellen — Floor = Zeilen 0–46, Wall = alle 16. Keine Zeile zu viel, keine zu wenig. - **Am echten Blatt:** `Outside_A2` Block 0 und `Outside_A3` Block 0 mit dem korrigierten Modell zum Ringmuster zusammengesetzt und angesehen: Kanten laufen durch, Innenecken sitzen an den konkaven Stellen, kein Versatz. - **MZ-Zeile 47** (obere linke Kachel) bleibt ungenutzt: sie ist pixelgleich mit der einzelnen Kachel aus den vier konvexen Ecken (Zeile 46), per Differenzbild geprüft, max. Abweichung 0. Es bleibt bei 47 Kacheln. **Geändert** - `src/core/model/autotile.ts`: `FLOOR_CORNERS` und `WALL_CORNERS` auf die MZ-Werte, Kommentar erklärt die halbe Drehung und die Herkunft. - `tests/core/autotile.test.ts`: neuer Test, der das Modell Zeile für Zeile gegen die MZ-Tabellen stellt. Die Tabellen sind aus `rmmz_core.js` **generiert**, nicht abgetippt. Die vier alten Sollwert-Tests nachgezogen. - `tools/e2e/39-autotile.mjs`: Sollwerte der Innenfläche, dazu ein Flake-Fix (unten). - `eslint.config.js`: `rpgmz/**` und `wiki/**` werden nicht gelintet, sonst reißt der abgelegte MZ-Code das Gate (11 Fehler, 53 Warnungen). `.gitignore`: `/rpgmz/` und `/pasted-*.png`. - Wiki `Autotiles.md`: die halbe Drehung und die Herkunft der Innenecken stehen jetzt dort. **Tests** ``` npm run check → 95 Files, 1277 Tests (vorher 1276), CHECK EXIT 0 npm run build → BUILD EXIT 0 GM_STEPS=39 (frisch geseedet) → ALL PASSED – 20 checks GM_STEPS=1-16,19,23,25,26,31,36,37,38,39 → ALL PASSED – 698 checks ``` - **Gegenprobe:** alte Fill-Zuordnung zurück → 3 Tests fallen; Innenecke wieder aus der linken Kachel → 2 Tests fallen. Original danach per `cmp` geprüft. - **Ein echter Testfehler nebenbei:** Der verkettete Lauf war zuerst rot in der Animationsprüfung — die vier Pixel wurden einzeln gelesen, und die 4-fps-Animation schaltete mittendrin um. Ein Flake, kein Befund. Schritt und Pixel werden jetzt in einem Aufruf in die Seite gelesen; danach zweimal grün. - Die Prüfsumme bleibt **989**, es kam kein e2e-Check dazu. CI auf `0607221` ist noch nicht gelesen. Der User hat das Ergebnis im Tab bestätigt.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: meleki/feuerwerk#118