Tabellensyntax

Eine SheetForge-Tabelle ist selbstbeschreibend: Spalte A ist für Markierungen reserviert, die eigentlichen Daten beginnen in Spalte B. Zeilen werden anhand ihrer Markierung identifiziert, nicht anhand ihrer Position, sodass Sie überall Kommentarzeilen einfügen können, ohne dass etwas kaputtgeht.

Um eine bestehende Tabelle anzupassen, fügen Sie eine Markierungsspalte vor Ihren Daten ein und ergänzen die drei Markierungszeilen. Bestehende Datenspalten bleiben unverändert.

Markierungen (Spalte A)

• @name, @type, @desc sind erforderlich; @overlap, @style und alle benutzerdefinierten Markierungen sind optional.
• Markierungszeilen dürfen in beliebiger Reihenfolge erscheinen, solange sie über den Datenzeilen stehen.
• Eine unbekannte @marker ist ein Fehler, mit einem Vorschlag für die nächstliegende Übereinstimmung („meinten Sie @desc?"). Registrierte benutzerdefinierte Markierungen werden in den Vorschlagspool aufgenommen.
• Daten in einer Spalte ohne @name/@type-Kopfzeile sind ein Fehler (Schutz vor verwaisten Daten – stiller Datenverlust ist nie erlaubt).

Beispiel (Spalten dargestellt als A | B | C | D):

#        | Item definitions — hand-edited by design team
@name    | codeName      | displayName | price
@type    | RecordId      | string      | int=10
@desc    | unique key    | shown in UI | shop price (gold)
         | item.sword    | Sword       | 120
         | item.potion   | Potion      |

(Die leere price-Zelle von item.potion materialisiert den expliziten Standardwert 10.)

Typsystem

Jeder Typ ist selbstbeschreibend – ein Leser erkennt allein anhand der @type-Zelle, was eine Spalte enthält.

<> und @ bedeuten unterschiedliche Dinge und bestehen nebeneinander: <> = Art/Wrapper (eingebautes List, oder ein Plugin-MyWrapper<T>), @ = Ziel. So ist List<RecordId@Effects> eine Liste von Referenzen, und Pair<RecordId@Effects> packt zwei Referenzen — beide in den Tab Effects. Der Integer-Schlüssel setzt sich auf dieselbe Weise zusammen: List<IntId@Effects> ist eine Liste von Integer-Schlüssel-Referenzen.

Wrapper-Typen (MyWrapper<T>)

Ein Plugin kann einen Wrapper registrieren — eine generische Wertform, die eine äußere Syntax (Trennzeichen, Arität) besitzt und den inneren Typ an den Core delegiert. Der Wrapper lässt sich mit jedem inneren Typ kombinieren. Alle darin enthaltenen Referenzen werden weiterhin validiert, bei Schlüssel-Umbenennung propagiert und bei Tab-Umbenennung umgeschrieben (vollständiges Pass-Through).

Ablehnungsregeln (konsistent mit List):

Erforderlich / optional / Standardwerte

Wo ? nicht akzeptiert wird, ist der Grund stets derselbe: Der Core kann keinen Wert aus dem Nichts erfinden, daher benötigen diese Typen ein explizites =default. Das betrifft:

• Enum<T>?
• einen benutzerdefinierten Plugin-Typ — Modifier?, einschließlich Modifier@Tab?
• einen Wrapper — Pair<int>?

Die Schlüsselspalten sind aus einem anderen Grund ausgeschlossen: Ein leerer Schlüssel würde Duplikate erzeugen. Daher werden auch RecordId? (die schlüssellose Selbstidentifikator-Form) und IntId? abgelehnt.

Weitere bewusst abgelehnte Notationen:

• int?=1 und RecordId@Effects?=fire — ? und = bedeuten beide „optional", wählen Sie also eines.
• List<T>? — eine Liste erlaubt Leerheit bereits.
• List<List<T>> — keine verschachtelten Listen.
• Pair<int?> — Optionalität ist feldbezogen, nicht Teil eines inneren Typs.

Wertregeln

• bool: nur true / false, bei der Eingabe wird Groß-/Kleinschreibung ignoriert; die kanonische Form ist Kleinschreibung.
• Zahlen: immer . als Dezimaltrennzeichen (unabhängig vom Gebietsschema). Komma-Dezimalzahlen, NaN und Infinity werden am Eingang abgelehnt.
• Floats im Round-Trip: Export erzeugt das kürzeste round-trip-fähige Format, sodass 1.0 als 1 zurückkommen kann — der Wert bleibt exakt erhalten (semantischer Round-Trip).
• Vergleiche von Markierungen und enum-Werten erfolgen ordinal (keine Überraschungen durch das Gebietsschema).

Typisierte Asset-Referenzen (AssetRef@Group<Type>)

AssetRef@Icons akzeptiert jede Adresse in der Gruppe. AssetRef@Icons<Sprite> schränkt das auf einen Asset-Typ ein, und diese Einschränkung wird an drei Stellen geprüft: Validierung, Codegenerierung und die Authoring-Oberfläche.

• Welche Namen sich auflösen. Der Typ ist ein beliebiger von UnityEngine.Object abgeleiteter Asset-Typ, den das Projekt laden kann — Engine-Typen (Sprite, Texture2D, AudioClip, eine abstrakte Basis wie Texture) ebenso wie Ihre eigenen ScriptableObjects; es gibt keine Allowlist. Components und reine Editor-Typen kommen nicht infrage. Schreiben Sie den Kurznamen, wenn genau ein Typ ihn trägt, sonst den vollständigen Namen samt Namespace. Mehrdeutige Namen (AmbiguousAssetType, mit jedem Kandidaten aufgelistet) und unbekannte Namen (UnknownAssetType, mit einem Vorschlag für die nächstliegende Übereinstimmung) werden einmal pro Spalte gemeldet, auf der @type-Zeile.
• Was besteht. Eine Adresse erfüllt die Einschränkung, wenn das Asset an dieser Adresse — oder eines seiner Sub-Assets — sich als dieser Typ laden lässt — sodass eine im Sprite-Modus importierte Textur <Sprite> besteht, während eine gewöhnliche Textur pro Zelle als AssetTypeMismatch gemeldet wird. Das Sub-Asset selbst ist als parent[sub] adressierbar, und dieser Schlüssel wird nur gegen seinen eigenen Typ geprüft.
• Ein Typ, den der generierte Code nicht referenzieren kann, wird abgelehnt. Ein Typ, der in einer vordefinierten Assembly liegt (Assembly-CSharp und ihre Geschwister — jeder Skriptordner ohne Assembly-Definition), wird gefunden, aber als AssetTypeNotReferenceable gemeldet, weil die generierte Begleitassembly diese Assemblies nicht referenzieren kann und AssetReferenceT<T> nicht kompilieren würde. Verschieben Sie den Typ in eine Assembly-Definition, oder lassen Sie das <…> weg.
• Was Codegen ausgibt. AssetReferenceT<global::UnityEngine.Sprite> für einen aufgelösten Typ, AssetReference für eine uneingeschränkte Spalte. Die Begleitassembly-Definition referenziert automatisch die Assembly, in der der Typ liegt, und der aufgelöste vollständige Name ist Teil des Schema-Fingerabdrucks, sodass eine Neuzuordnung des Namens den Code neu generiert.
• Setzt sich zusammen wie jeder andere Typ: AssetRef@Icons<Sprite>?, List<AssetRef@Icons<Sprite>> und ein Wrapper wie Pair<AssetRef@Icons<Sprite>> funktionieren alle; AssetRef@Icons<> (leer), AssetRef@Ic<ons (eine spitze Klammer im Gruppennamen) und RecordId@Skills<X> (die Einschränkung gilt nur für AssetRef) sind Syntaxfehler.
• Das Spaltenformular des Data Studio hat eine Schaltfläche Typ…, die die Kandidatentypen auflistet und die @type-Zelle für Sie umschreibt — siehe Data Studio.

Visuelle Werttypen (Color, AnimationCurve, Gradient)

Drei eingebaute Typen tragen Werte, die als Rohtext unlesbar sind. Ihre Textform ist so gestaltet, dass eine Person von Hand eine kurze Version eintippen kann, während jedes Werkzeug — die Editoren, Export, Push, die Web-App — stets die kanonische, vollständige Form schreibt, und ein Wert übersteht Tabelle → Unity → Tabelle ohne Verlust.

Die Trennzeichen sind bei allen dreien gleich und liegen eine Ebene unter dem Listentrennzeichen: Innerhalb eines Werts werden Einträge durch , getrennt, Felder innerhalb eines Eintrags durch :, Abschnitte durch |, und die Zeit eines Schlüsselpunkts wird mit @ angehängt. Elemente einer List<> werden weiterhin durch ; getrennt, und keine der drei Notationen enthält jemals ein ; — sodass sich List<AnimationCurve> = 0:0,1:1;0:1,1:0 sauber aufteilen lässt. Zahlen verwenden überall . als Dezimalpunkt (ein Gebietsschema-Komma zeigt sich als falsche Feldanzahl, niemals als still falscher Wert), Leerraum um Trennzeichen wird getrimmt, und der Round-Trip parse(render(parse(x))) == parse(x) gilt für jede akzeptierte Eingabe.

Farbe: Der Wert wird als vier Bytes gespeichert. HDR (Kanäle über 1) wird nicht unterstützt — eine gebackene Farbe wird beim Export auf 0…1 begrenzt. Der Typ-Standardwert ist transparentes Schwarz, #00000000.

Kurve: wm ist das Gewichtete-Tangenten-Flag (0 keine · 1 eingehend · 2 ausgehend · 3 beide) und tm das Tangenten-Modus-Paar Left/Right, optional gefolgt von /broken — jede Seite ist eine von Free, Auto, Linear, Constant, ClampedAuto, dieselben Namen, die Unitys Kurven-Editor verwendet. Kürzere Formen füllen den Rest auf: Ein 2-Felder-Schlüsselpunkt übernimmt die Steigung zu seinen Nachbarn als Tangenten (Linear/Linear), Gewichte von 0.33333334 und keine Gewichtung; ein 4-Felder-Schlüsselpunkt behält Ihre Tangenten (Free/Free); ein 7-Felder-Schlüsselpunkt fügt Gewichte hinzu. Tangentenfelder dürfen Infinity oder -Infinity sein (eine Constant-Stufe); Zeit, Wert und Gewicht müssen endlich sein, die Zeiten der Schlüsselpunkte müssen sich voneinander unterscheiden (Schlüsselpunkte werden beim Import nach Zeit sortiert, daher spielt die Reihenfolge, in der Sie sie eintippen, keine Rolle), und es gibt keine Begrenzung für die Anzahl der Schlüsselpunkte. Der Modus gewinnt gegenüber der Zahl: Für jede Seite, die nicht Free ist, wird der Tangentenwert beim Import aus dem Modus neu berechnet — dieselbe Berechnung, die Unity durchführt —, sodass eine von Hand eingetippte Zahl, die ihrem Modus widerspricht, ersetzt wird, und die Tabelle, die Editoren und das Spiel alle dieselbe Kurve zeigen. Wrap-Modi sind ClampForever, Loop, PingPong und Default; Once wird als Alias für ClampForever akzeptiert (Unity normalisiert es) und nie zurückgeschrieben. Eine Kurve ohne Schlüsselpunkte hat keine Textform: Sie existiert nur als leere Zelle einer optionalen Spalte, und Export gibt sie als leere Zelle aus.

Verlauf: Farbpunkte tragen kein Alpha (#RRGGBBAA im Farbabschnitt ist ein Fehler — Alpha hat seinen eigenen Abschnitt); innerhalb eines Abschnitts sind die @t-Zeiten entweder alle vorhanden oder alle fehlend, und wenn sie fehlen, werden die Schlüsselpunkte gleichmäßig verteilt (n = 1 → 0, n ≥ 2 → i/(n−1)); ein fehlender Alpha-Abschnitt bedeutet 1@0,1@1, ein fehlender Modus bedeutet Blend. Modi sind Blend, Fixed (Stufen) und PerceptualBlend; der optionale Farbraum (Gamma oder Linear) ändert nur, wie PerceptualBlend interpoliert. Zeiten und Alphawerte liegen bei 0…1; Zeiten werden beim Import auf 16 Bit quantisiert, genau wie Unity sie speichert, sodass der angezeigte Wert der Wert ist, den die Engine hält. Ein Verlauf mit einem einzelnen Schlüsselpunkt kommt durch Unity im Round-Trip als zwei identische Schlüsselpunkte zurück — das Bild bleibt unverändert, nur die Anzahl der Schlüsselpunkte wächst.

Listen: List<Color> = #F00;#0F0, List<Gradient> = #F00,#00F;#0F0,#000 — das Listentrennzeichen bleibt unverändert.

Das Data Studio zeigt diese Zellen als native Farb-, Kurven- und Verlaufsfelder, die Web-App als Vorschauen mit vollständigen Editoren — siehe Data Studio und SheetForge Web. Beide schreiben die kanonische Form; die Minimalformen sind für Menschen gedacht.

Schlüssel und Eindeutigkeit

• RecordId (ohne @) ist die Schlüsselspalte: höchstens eine pro Tab.
  • Null Schlüsselspalten sind gültig — bis ein anderer Tab diesen Tab referenziert (TargetTabHasNoKey).
  • Zwei oder mehr sind ein Fehler (MultipleKeyColumns).
  • Doppelte Schlüsselwerte (DuplicateRecordId) und leere Schlüsselzellen sind Fehler.
• IntId ist ein sekundärer Integer-Schlüssel: Die Eindeutigkeit wird unabhängig erzwungen, und andere Tabs können ihn über IntId@Tab referenzieren.
  • Integer-Schlüssel-Referenzen erhalten dieselbe Integritätsprüfung, dieselben Vorschläge für die nächstliegende Übereinstimmung, dieselbe Umbenennungs-Propagation und dieselbe Graph-/Canvas-Unterstützung wie RecordId@Tab.
• Ein Tab kann nur über RecordId, nur über IntId oder über beide schlüsseln — alle drei Fälle verhalten sich überall symmetrisch.
  • Trägt ein Tab beide, ist RecordId der Anzeige-/Identitätswert, und der Integer wird daneben angezeigt.
  • Ein anderer Tab kann auf denselben Datensatz auf beide Arten verweisen: RecordId@ThisTab über dessen String-Schlüssel, oder IntId@ThisTab über dessen Integer-Schlüssel.
• @overlap: gewöhnliche Spalten erlauben standardmäßig doppelte Werte. Setzen Sie false in die @overlap-Zelle einer Spalte, um wertbasierte Eindeutigkeit zu erzwingen.
  • 1.0 und 1 gelten als derselbe Wert; zwei Listen sind Duplikate, wenn alle Elemente und deren Reihenfolge übereinstimmen.
  • Zwei leere Referenzen sind niemals Duplikate voneinander (ein leerer Skalar-Standardwert bleibt dagegen ein gewöhnlicher Wert).
  • Schlüsselspalten sind immer eindeutig; @overlap true auf eine Schlüsselspalte zu schreiben, ist ein Widerspruchsfehler.

Anzeigemetadaten der Tabelle (@style)

@style lässt eine Tabelle festlegen, zu welcher Gruppe sie gehört und welche Farbe sie hat, sodass Gruppierung und Färbung in der Tabelle leben statt nur im Editor. Es ist die einzige Markierung, die die Tabelle statt ihrer Spalten beschreibt. Ihre Zellen sind daher nicht an Spalten ausgerichtet — sie bilden eine freie Liste von key=value-Paaren, die bei Spalte B beginnt.

@style   | title=Combat  | color=#4D8FF0
@name    | codeName      | displayName | power
@type    | RecordId      | string      | int
@desc    | unique key    | shown in UI | attack power
         | skill.fire    | Fireball    | 12

• Beide Schlüssel sind optional, und die Reihenfolge spielt keine Rolle; schreiben Sie einen, beide oder keinen. Eine leere Zelle wird ignoriert (Füllzellen sind unproblematisch).
• Validierungsfehler werden alle als MarkerCellInvalid gemeldet, mit Zellkoordinate und einem konkreten Lösungsvorschlag:
  • ein unbekannter Schlüssel (mit Vorschlag für die nächstliegende Übereinstimmung),
  • ein wiederholter Schlüssel,
  • ein fehlender Wert,
  • eine Farbe, die nicht #RRGGBB ist.
• Die Drei-Ziffern-Kurzform (#4AF) und benannte Farben werden bewusst abgelehnt, damit der Wert als eine einzige Notation round-trip-fähig bleibt.
• Nur Anzeige: Codegen, Bake und der Schema-Fingerabdruck lesen @style nie. Das Ändern der Farbe einer Tabelle löst weder eine Codegenerierung noch ein erneutes Backen von ScriptableObjects aus.
• Round-Trip-sicher: Die @style-Zeile wird wie eine Kommentarzeile bewahrt. Hinzufügen, Löschen, Verschieben und Umbenennen von Spalten lassen sie unberührt, weil ihre Zellen zu keiner Spalte gehören. Das Bearbeiten erfolgt über das Formular Group & color (Rechtsklick auf eine Tabelle in der Data-Studio-Seitenleiste), das die Zeile in kanonischer Form neu schreibt.
• Eine Tabelle, die nur @style (plus Kommentare) besitzt, zählt als „noch keine Tabelle": Der Import überspringt sie mit einer Warnung, statt an den drei fehlenden Pflichtmarkierungen zu scheitern. Sobald Sie @name/@type/@desc hinzufügen, wird sie normal geparst. Siehe Möglichkeiten & Grenzen.
• style ist ein reservierter Markierungsname — ein Plugin, das versucht, ihn zu registrieren, wird abgelehnt, und ein Tippfehler wie @styl erhält @style als Vorschlag.

Enum-Definitionstabellen (@enum)

Eine Enum<T>-Spalte benötigt ein T. Sie können eines aus Plugin-C#-Code registrieren (EnumRegistry), aber Sie können es auch einfach in die Tabelle schreiben — ohne Code, ohne Plugin. Eine Tabelle wird als Enum-Definitionen gelesen, wenn eine der beiden Bedingungen zutrifft:

• sie trägt eine @enum-Markierungszeile (der Tab kann beliebig benannt sein), oder
• der Tab heißt exakt Enum (Groß-/Kleinschreibung beachtet) und besitzt keine @type-Zeile.

Die zweite Regel verlangt bewusst, dass @type fehlt: Eine Datentabelle besitzt sie immer, daher bleibt eine bestehende Tabelle, die zufällig Enum heißt, weiterhin eine Datentabelle. Eine Tabelle, die sowohl @enum als auch @type trägt, ist widersprüchlich und wird als EnumSheetMarkerConflict gemeldet, statt erraten zu werden.

@desc spielt bei dieser Entscheidung keine Rolle — sie ist auf beiden Tabellenarten zulässig, und auf einer Enum-Definitionstabelle beschreibt sie das Enum in dieser Spalte (siehe unten).

Eine Enum-Definitionstabelle hat keine Datentabelle — kein Schema, keine Schlüsselspalte, keine Datensätze. Eine Spalte ist ein Enum: Die @name-Zelle trägt den Namen des Enums, und jede Zeile darunter (Spalte A bleibt leer) ist ein Member.

@enum    | byte       |
@desc    | Damage kind| Elemental affinity
@name    | DamageType | Element
         | Physical   | Fire
         | Magical=10 | Ice
         | True       | Lightning

Diese Tabelle definiert zwei Enums, und Enum<DamageType> / Enum<Element> lösen sich nun in jeder @type-Zelle auf — die Spaltensyntax bleibt unverändert. Alle drei oben gezeigten Extras sind optional; eine nackte @name-Zeile plus Member ist weiterhin eine vollständige Enum-Definitionstabelle.

Sie müssen dieses Gerüst nicht selbst eintippen: Sheet erstellen liefert eine Enum definitions-Vorlage, die die Tabelle für Sie anlegt — eine der beiden eingebauten Vorlagen (siehe Data Studio ▸ Sheet create / delete).

• Die Reihenfolge ist der Wert, und Name=value legt sie fest. Eine Member-Zelle ist entweder ein reiner Name oder Name=value mit einem expliziten Integer — genau nach C#s Enum-Regeln: Ein unnummerierter Member ist der vorherige Wert plus eins, der erste ist 0.
  • Normal / Rare=10 / Epic kompiliert zu 0 / 10 / 11. Codegen gibt das = value nur dort aus, wo Sie eines geschrieben haben.
  • Datenzellen und Dropdowns verwenden immer den Namen (Rare, niemals Rare=10).
  • Ein Wert, der kein reiner Integer ist oder außerhalb des Wertebereichs des zugrunde liegenden Typs liegt (auch durch Auto-Inkrement), ist InvalidEnumMemberValue.
  • Das ist auch der Grund, warum das Data Studio Member nie umordnet und nie eine Lücke auffüllt: Das Verschieben eines Members würde stillschweigend Werte ändern, die bereits in Assets gebacken und in Spielständen gespeichert sind.
• @desc beschreibt das Enum. Die @desc-Zelle einer Spalte wird im generierten Code zum XML-<summary> dieses Enums (Tooltips in der IDE) — im selben Sinne wie das @desc eines Felds in einer Datentabelle. Leere Zelle = keine Beschreibung; die Markierungszeile selbst ist optional.
• @enum-Zellen wählen den zugrunde liegenden Typ. Die Zelle der @enum-Zeile in einer Spalte kann den zugrunde liegenden C#-Typ für dieses Enum benennen — einen von byte, sbyte, short, ushort, int, uint, long, ulong.
  • Eine leere Zelle (oder gar keine @enum-Zeile, auf einem Tab namens Enum) bedeutet int. Alles andere ist InvalidEnumUnderlyingType.
  • Codegen gibt public enum Grade : byte { … } aus.
  • Für ulong werden explizite Werte oberhalb von long.MaxValue aus einer Tabelle nicht unterstützt — registrieren Sie ein solches Enum stattdessen aus Plugin-C#-Code.
• Leere Zellen werden übersprungen, nicht als Member gelesen, daher dürfen Spalten unterschiedlich lang sein, und eine Lücke in der Mitte wird einfach überlesen.
• Kommentarzeilen (#) werden überall in der Tabelle ignoriert. Mehrere Enums pro Tabelle und mehrere Enum-Definitionstabellen sind beide unproblematisch. Namen müssen über alle hinweg eindeutig sein, und ein Name, den ein Plugin bereits aus C# registriert hat, gewinnt — die Tabellen-Definition wird mit DuplicateEnumName abgelehnt.
• Namen und Member müssen als C#-Bezeichner nutzbar sein: ASCII-Buchstaben, Ziffern und _, nicht mit einer Ziffer beginnend, und kein reserviertes Schlüsselwort (InvalidEnumIdentifier).
  • Nicht-ASCII wird bewusst abgelehnt, weil zum Verwechseln ähnliche Unicode-Bezeichner einen Typ erzeugen würden, den niemand von einem anderen unterscheiden kann.
  • Ein deklarierter Name ohne Member darunter ist EnumSheetEmptyColumn.
  • Scheitert ein Member einer Spalte, wird das gesamte Enum verworfen, statt halb registriert zu werden.
• Was der Import erzeugt. Eine einzige SheetForgeEnums.cs für das gesamte Projekt — Enums sind eine projektweite Ausgabe, keine pro Tab. Sie wird in den in den Einstellungen konfigurierten Ordner für generierten Code geschrieben, im selben Namespace wie die generierten Tab-Typen. Der erste Import erzeugt den Typ, kompiliert ihn und schließt den Bake nach dem Domain-Reload ab, ohne zusätzlichen Klick.
• Einen Member hinzufügen, ohne die Tabelle zu öffnen: Das Dropdown einer Enum<T>-Zelle im Data Studio trägt „Add a new member…", das den Member als einen Undo-Schritt auf die Enum-Definitionstabelle vormerkt. Ein aus Plugin-C#-Code registriertes Enum bietet diese Zeile nicht an — der Code besitzt es.
• Enum-Definitionstabellen haben keine Datensätze, daher werden sie nie in ein ScriptableObject gebacken, und Export/Push lassen ihren Text unangetastet; der Import meldet sie getrennt von übersprungenen Tabs.
• Siehe Möglichkeiten & Grenzen für die beiden Grenzen: per Plugin registrierte Enums lassen sich nicht aus einer Tabelle erweitern, und die generierte Enum-Datei landet immer im Einstellungsordner.

Lokalisierungstabellen (@loc)

Eine @loc-Markierungszeile macht aus der Tabelle eine Lokalisierungstabelle: Zeilen sind Schlüssel, Spalten sind Sprachen, und die @loc-Zelle jeder Sprachspalte benennt deren Sprachcode.

• Die RecordId-Schlüsselspalte ist erforderlich – der Schlüsselwert ist der Lokalisierungsschlüssel.
• Die erste Sprachspalte ist die Quellsprache.
• Sprachspalten sind String-Spalten. string? ist die empfohlene Form: Eine leere Zelle ist dann eine Abdeckungslücke, kein Fehler.
• Zwei optionale Spalten sind namentlich reserviert: smart (bool) und comment (string).

@loc     |            | en          | ko    |
@name    | codeName   | en          | ko    | comment
@type    | RecordId   | string?     | string? | string?
@desc    | key        | source text |       |
         | ui.ok      | OK          | 확인  | Confirm button

Für Bearbeitung, Export, Push, xlsx und die Web-App bleibt die Tabelle eine gewöhnliche Tabelle. Was sich ändert, ist die Ausgabe: keine Record-Klasse und kein Database-SO, sondern pro Tab Schlüsselkonstanten und – wenn das Unity-Localization-Paket installiert ist – StringTable-Synchronisierung. @enum und @loc auf derselben Tabelle ist ein Konfliktfehler.

Die vollständige Geschichte – LocRef-Referenzen, Prägen neuer Schlüssel, die Bridge, Übersetzungs-Workflows – steht auf Lokalisierungstabellen.

Benutzerdefinierte Strukturmarkierungen (per Plugin registriert)

@overlap ist das eingebaute Beispiel für eine spaltenweise Markierung: eine Markierungszeile, deren Zellen einen Wert pro Spalte tragen, validiert Spalte für Spalte. Ein Plugin kann auf dieselbe Weise eigene Markierungen registrieren — z. B. eine @curve-Markierung, die annotiert, wie jede numerische Spalte interpoliert.

Der Wert wird als domänenunabhängige Metadaten (FieldSchema.MarkerValues) gespeichert, die Validatoren, Kanten-Contributor und der Spalten-Header-Tooltip des Authoring-Fensters lesen können. Der Core interpretiert den Wert selbst nie — die Validierung wird an die Markierungsdefinition delegiert.

• Registrierte benutzerdefinierte Markierungen werden genau wie @overlap akzeptiert: beliebige Reihenfolge über den Daten, Duplikate werden abgelehnt, eine Markierung unterhalb der Daten ist ein Fehler.
• Jede Markierung besitzt nur ihre spaltenweise Wertvalidierung (einschließlich der Bedeutung einer leeren Zelle) — sie übernimmt nicht das Parsen der gesamten Zeile. Daten-„Formen" bleiben Sache der Normalisierung (Referenzen, List<T>, type-Spalten).
• Benutzerdefinierte Markierungen sind für Metadaten auf Spaltenebene gedacht, nicht für neue Datenformen. Siehe Plugin-Erstellung §4.5 für ein Registrierungsbeispiel.
• @style ist die einzige eingebaute Markierung, die nicht spaltenweise ist (sie beschreibt die Tabelle) — sie ist also nicht das Vorbild dafür, @overlap ist es.

Komplexe Daten zusammensetzen: zuerst normalisieren

Der empfohlene Weg, komplexe Strukturen auszudrücken, ist der Zusammenbau über Referenzen („zusammensetzen statt skripten"):

• Atome leben als Zeilen in ihrem eigenen Tab.
• Kombinationen sind Referenzlisten: List<RecordId@Effects>.
• Eine type-Spalte (ein enum) verknüpft eine Datenzeile mit einem Code-Atom — Ihre Runtime führt darauf ein switch aus, um Verhalten zu dispatchen. Keine eingebettete Skriptsprache nötig.

Mini-Grammatiken (benutzerdefinierte Zelltypen wie attack:add:10) sind für kleine Tupel gedacht — der Core stellt die Konventionen ; und : bereit; überstrapazieren Sie sie nicht.

Für wirklich prozedurale Einmal-Logik referenzieren Sie ein Skript-Asset genauso, wie Sie ein Bild referenzieren würden: List<AssetRef@Scripts>. SheetForge validiert die Referenz und bakt das Addressable; das Ausführen des Skripts ist Aufgabe Ihres Spiels.

Besondere Daten-„Formen": Selbst kompliziert wirkende Daten (Level-Kurven usw.) lassen sich sauber normalisieren (List<float>, Zusammenbau über Referenzen). Eine benutzerdefinierte Strukturmarkierung fügt Metadaten auf Spaltenebene hinzu (spaltenweise validiert), keine neue Datenform – normalisieren Sie die Daten zuerst, und greifen Sie nur bei wirklich umfangreichen spaltenweisen Annotationen zu einer benutzerdefinierten Markierung. Siehe Plugin-Erstellung.

Verwandte Seiten

• Kernkonzepte – was mit diesen Zellen nach dem Parsen geschieht
• Data Studio – Spalten/Typen bearbeiten, ohne die Tabelle zu öffnen
• Lokalisierungstabellen – die @loc-Tabellenform und LocRef-Referenzen im Detail
• Plugin-Erstellung – enums und benutzerdefinierte Zelltypen registrieren
• Möglichkeiten & Grenzen – die Grenzen der <>-Wrapper- und Custom-Marker-Syntax