RDietermann/rustkeep
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

16 — Loot-Tabellen #17

New Issue
Closed
opened 2026-08-11 14:27:31 +00:00 by RDietermann · 1 comment
RDietermann commented 2026-08-11 14:27:31 +00:00
Owner
Copy Link

Teil der Map #1 · Type: wayfinder:grilling · Blocked by: — · graduiert aus #3

Wo haengt Beute, wie wird gewichtet, wie wirkt luck, wie skaliert es ueber Etagen, und wie haengen Mods Eintraege in fremde Tabellen ein?

Volle Fragestellung (kanonisch): .scratch/rustkeep-1.0/issues/16-loot-tabellen.md

Teil der Map #1 · **Type: `wayfinder:grilling`** · **Blocked by: —** · graduiert aus #3 Wo haengt Beute, wie wird gewichtet, wie wirkt `luck`, wie skaliert es ueber Etagen, und wie haengen Mods Eintraege in fremde Tabellen ein? Volle Fragestellung (kanonisch): `.scratch/rustkeep-1.0/issues/16-loot-tabellen.md`
RDietermann added the wayfinder:grilling label 2026-08-11 14:27:31 +00:00
RDietermann commented 2026-08-12 12:27:19 +00:00
Author
Owner
Copy Link

Aufgeloest in 9c5efab. Kanonische Fassung: .scratch/rustkeep-1.0/issues/16-loot-tabellen.md

Der Zufall war bereits entschieden: derselbe gesetzte Generator aus #15, dessen Seed im Save liegt — Beute wuerfelt beim Nachladen nicht neu.

Eine Maschinerie fuer Gegenstaende und Affixe

Zwoelfte Registry [[loot_tables]]:

[[loot_tables]]
id    = "core:weapon_affixes"
rolls = "0-1"
entries = [
  { affix = "core:flaming",         weight = 5 },
  { affix = "core:greater_flaming", weight = 1 },   # Stufe, kein Wert
  { nothing = true,                 weight = 20 },
]

[[loot_tables]]
id    = "core:floor_3_table"
rolls = "1-3"
entries = [
  { item = "core:health_potion", weight = 10, count = "1-2" },
  { item = "core:iron_sword",    weight = 3, affixes = "core:weapon_affixes" },
  { table = "core:rare_table",   weight = 1 },
  { nothing = true,              weight = 20 },
  { item = "core:boss_blade",    guaranteed = true },
]

Gewichte statt Prozent — keine Geschmacksfrage, sondern eine Modding-Frage: Prozente muessen sich auf 100 summieren, und ein hinzugefuegter Eintrag macht die Summe kaputt, woraufhin jemand alle anderen anpassen muss.

Nieten sind gewoehnliche Eintraege, kein drop_chance-Feld — die Engine kennt eine Mechanik statt zweier. Tabelle-in-Tabelle liefert Seltenheitsstufen, ohne dass "Seltenheit" ein Begriff wird. guaranteed = true fuer Bosse und Questgegenstaende, weil sich "sicher" mit Gewichten nicht ausdruecken laesst. Mehrfachziehung erlaubt, kein unique-Flag.

Affix-Stufen statt Affix-Werte

#8 hat festgelegt, dass eine ItemInstance nur Affix-IDs traegt. "Flammend" und "Stark flammend" sind deshalb zwei Registry-Eintraege, keine Zahl am Exemplar.

Eine Staerke je Exemplar haette drei Dinge auf einmal gekostet: Save-Format (ID-Liste), Preisformel (base_price × Π price_factor) und Stapelregel — zwei Schwerter "Flammend 3" und "Flammend 4" stapeln nicht mehr, aber wie zeigt man den Unterschied an? Mit Stufen kann der Modder seine Abstufungen benennen.

luck hat genau eine Regel

p_extra = clamp(luck * LUCK_FACTOR, 0.0, 0.9) — eine Chance auf einen zusaetzlichen Zug, auf jeder Tabelle. Wirkt dreifach, ohne dreimal geschrieben zu werden: mehr Gegenstaende, mehr Affixe, und haeufiger die staerkere Stufe (die als eigener Eintrag mit kleinem Gewicht danebensteht).

Der Grund gegen "Glueck verschiebt zur Seltenheit" ist ein Ausschluss: es gibt keinen Seltenheitsbegriff. Ihn erst zu definieren und dann Gewichte umzurechnen waere ein zweites Konzept fuer dasselbe Gefuehl.

Der Mod-Einhaengepunkt existiert bereits

#4 gilt unveraendert (ganzer Eintrag wird ersetzt). Ein neuer Mechanismus wird trotzdem nicht gebraucht — Tabelle-in-Tabelle ist der Einhaengepunkt:

[[loot_tables]]
id = "meinmod:floor_3"
entries = [ { table = "core:floor_3_table", weight = 100 },
            { item  = "meinmod:zauberstab",  weight = 5 } ]

[[floors]]
id = "core:floor_3"
overrides = "core:floor_3"
loot = "meinmod:floor_3"

Decke: zwei Mods, die dieselbe Etage umhaengen, kollidieren — derselbe Konflikt wie bei jeder Ueberschreibung. [[loot_additions]] waere der Nachbau; ihn vorher zu bauen hiesse, einen zweiten Mechanismus fuer etwas einzufuehren, das der erste schon kann.

Beute wird beim Aufheben gezogen

Room haelt eine loot_table plus loot: Vec<Pos> statt fertiger Instanzen — alle Haufen eines Raums ziehen ohnehin aus derselben Tabelle. Die Zahl der Haufen steht bei der Erzeugung fest (die l-Zeichen), ihr Inhalt nicht.

Moeglich ist das nur, weil alle Haufen dasselbe generische Symbol zeigen — die Anzeige verraet nichts, was noch nicht gewuerfelt ist. Der Gewinn: ein Gluecksring wirkt auch auf Beute, die auf dieser Etage schon liegt.

Faellt der Wurf auf eine Niete, verschwindet der Haufen mit einer Meldung. Kein Neuwuerfeln (haengt sich bei einer reinen Nieten-Tabelle auf), keine Ladepruefung, die Modder bevormundet.

Etagenskalierung — Auflage aus #16 strukturell erfuellt

Eine Tabelle je Etage, wie #11 es angelegt hat. Nirgends steht eine Fuenf: Etagen sind Registry-Eintraege, jeder bringt seine Tabelle mit, und der Endlosmodus wiederholt mit der letzten Etage auch deren Tabelle. Bedingungen am Eintrag (floor at_least 3) loesen das Endlos-Problem gerade nicht — echte Tiefenskalierung braeuchte Gewichte als Funktion der Etage, eine Formel statt Daten.

Ein Prefab darf ueber ein optionales loot-Feld seine eigene Tabelle nennen; sonst ist ein Schatzkammer-Raum nur ein Raum mit mehr l-Zeichen.

Zwei Nachtraege

  • #11 (10): Room { loot_table, loot: Vec<Pos> }; optionales Prefab-loot; generischer Beute-Marker
  • #15 (14): LUCK_FACTOR in [balance] (jetzt acht Felder)

Damit sind alle sechzehn Tickets geschlossen und die Destination der Map ist erreicht.

**Aufgeloest** in 9c5efab. Kanonische Fassung: `.scratch/rustkeep-1.0/issues/16-loot-tabellen.md` Der Zufall war bereits entschieden: derselbe gesetzte Generator aus #15, dessen Seed im Save liegt — Beute wuerfelt beim Nachladen nicht neu. ### Eine Maschinerie fuer Gegenstaende und Affixe Zwoelfte Registry `[[loot_tables]]`: ```toml [[loot_tables]] id = "core:weapon_affixes" rolls = "0-1" entries = [ { affix = "core:flaming", weight = 5 }, { affix = "core:greater_flaming", weight = 1 }, # Stufe, kein Wert { nothing = true, weight = 20 }, ] [[loot_tables]] id = "core:floor_3_table" rolls = "1-3" entries = [ { item = "core:health_potion", weight = 10, count = "1-2" }, { item = "core:iron_sword", weight = 3, affixes = "core:weapon_affixes" }, { table = "core:rare_table", weight = 1 }, { nothing = true, weight = 20 }, { item = "core:boss_blade", guaranteed = true }, ] ``` **Gewichte statt Prozent** — keine Geschmacksfrage, sondern eine Modding-Frage: Prozente muessen sich auf 100 summieren, und ein hinzugefuegter Eintrag macht die Summe kaputt, woraufhin jemand alle anderen anpassen muss. **Nieten sind gewoehnliche Eintraege**, kein `drop_chance`-Feld — die Engine kennt eine Mechanik statt zweier. **Tabelle-in-Tabelle** liefert Seltenheitsstufen, ohne dass "Seltenheit" ein Begriff wird. **`guaranteed = true`** fuer Bosse und Questgegenstaende, weil sich "sicher" mit Gewichten nicht ausdruecken laesst. Mehrfachziehung erlaubt, kein `unique`-Flag. ### Affix-Stufen statt Affix-Werte #8 hat festgelegt, dass eine `ItemInstance` **nur Affix-IDs** traegt. "Flammend" und "Stark flammend" sind deshalb zwei Registry-Eintraege, keine Zahl am Exemplar. Eine Staerke je Exemplar haette drei Dinge auf einmal gekostet: Save-Format (ID-Liste), Preisformel (`base_price × Π price_factor`) und Stapelregel — zwei Schwerter "Flammend 3" und "Flammend 4" stapeln nicht mehr, aber wie zeigt man den Unterschied an? Mit Stufen kann der Modder seine Abstufungen **benennen**. ### `luck` hat genau eine Regel `p_extra = clamp(luck * LUCK_FACTOR, 0.0, 0.9)` — **eine Chance auf einen zusaetzlichen Zug, auf jeder Tabelle.** Wirkt dreifach, ohne dreimal geschrieben zu werden: mehr Gegenstaende, mehr Affixe, und haeufiger die staerkere Stufe (die als eigener Eintrag mit kleinem Gewicht danebensteht). Der Grund gegen "Glueck verschiebt zur Seltenheit" ist ein Ausschluss: **es gibt keinen Seltenheitsbegriff.** Ihn erst zu definieren und dann Gewichte umzurechnen waere ein zweites Konzept fuer dasselbe Gefuehl. ### Der Mod-Einhaengepunkt existiert bereits #4 gilt unveraendert (ganzer Eintrag wird ersetzt). Ein neuer Mechanismus wird trotzdem nicht gebraucht — **Tabelle-in-Tabelle ist der Einhaengepunkt**: ```toml [[loot_tables]] id = "meinmod:floor_3" entries = [ { table = "core:floor_3_table", weight = 100 }, { item = "meinmod:zauberstab", weight = 5 } ] [[floors]] id = "core:floor_3" overrides = "core:floor_3" loot = "meinmod:floor_3" ``` Decke: zwei Mods, die dieselbe Etage umhaengen, kollidieren — derselbe Konflikt wie bei jeder Ueberschreibung. `[[loot_additions]]` waere der Nachbau; ihn vorher zu bauen hiesse, einen zweiten Mechanismus fuer etwas einzufuehren, das der erste schon kann. ### Beute wird beim Aufheben gezogen `Room` haelt eine `loot_table` plus `loot: Vec<Pos>` statt fertiger Instanzen — alle Haufen eines Raums ziehen ohnehin aus derselben Tabelle. Die **Zahl** der Haufen steht bei der Erzeugung fest (die `l`-Zeichen), ihr Inhalt nicht. Moeglich ist das nur, weil **alle Haufen dasselbe generische Symbol zeigen** — die Anzeige verraet nichts, was noch nicht gewuerfelt ist. Der Gewinn: ein Gluecksring wirkt auch auf Beute, die auf dieser Etage schon liegt. Faellt der Wurf auf eine Niete, **verschwindet der Haufen mit einer Meldung**. Kein Neuwuerfeln (haengt sich bei einer reinen Nieten-Tabelle auf), keine Ladepruefung, die Modder bevormundet. ### Etagenskalierung — Auflage aus #16 strukturell erfuellt Eine Tabelle je Etage, wie #11 es angelegt hat. **Nirgends steht eine Fuenf**: Etagen sind Registry-Eintraege, jeder bringt seine Tabelle mit, und der Endlosmodus wiederholt mit der letzten Etage auch deren Tabelle. Bedingungen am Eintrag (`floor at_least 3`) loesen das Endlos-Problem gerade *nicht* — echte Tiefenskalierung braeuchte Gewichte als Funktion der Etage, eine Formel statt Daten. Ein Prefab darf ueber ein **optionales** `loot`-Feld seine eigene Tabelle nennen; sonst ist ein Schatzkammer-Raum nur ein Raum mit mehr `l`-Zeichen. ### Zwei Nachtraege - **#11 (10)**: `Room { loot_table, loot: Vec<Pos> }`; optionales Prefab-`loot`; generischer Beute-Marker - **#15 (14)**: `LUCK_FACTOR` in `[balance]` (jetzt acht Felder) --- Damit sind **alle sechzehn Tickets geschlossen** und die Destination der Map ist erreicht.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
Wayfinder ticket: grilling (HITL)
 wayfinder:map
Wayfinder map issue
 wayfinder:prototype
Wayfinder ticket: prototype (HITL)
 wayfinder:research
Wayfinder ticket: research (AFK)
No Label wayfinder:grilling
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
RDietermann
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RDietermann/rustkeep#17
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?