ich will eine python datei die die spielelisten neu befüllt um eine zufällige neue situation zu schaffen.
bevor du code schreibst überlegen wir die regeln.
Part 1
Wo rohstoffe erstellt werden bleibt gleich. auch die menge/zeit zur herstellung bleibt gleich.
1. eine liste aller gebäude aus der datenbank auslesen. Dabei werden 4 gebäude nicht abgerufen. als erkennung nehmen wir aber nicht namen oder id sondern was sie herstellen. nicht abgerufen werden sollen die gebäude die Holz, Stein, Wolle und Getreide in level 1 herstellen, diese werden nur 20 Münzen als Baukosten haben und keine vorraussetzungen, da sie die startgebäude sind. alle anderen gebäude bekommen keine münzkosten
2. eine liste aller im spiel vorhandenen rohstoffe auslesen
3.  den aktuellen handelswert aller rohstoffe auslesen.
4. aus dem niedrigsten und dem höchsten handelswert einen durchschnitt errechnen. dann wird dieser wert mit 30 multipliziert. das sind unsere grundkosten.
5. jedem gebäude sollen jetzt rohstoffe als kosten zum bau oder für ein upgrade (falls vorgesehen laut gebäude verwalten) zugewiesen werden. es müssen immer zwischen 2 und 3 rohstoffe pro gebäude benutzt werden. mindesten 1 rohstoff muss ein basisrohstoff sein. es können auch nur basisrohstoffe benutzt werden. die grungkosten gelten als anhaltspunt für den wert der ungefähr mit den handelswerten der einzelnen rohstoffe erreicht werden muss. leicht darüber oder darunter ist ok. rohstoffe aus den bereichen werkzeug, element und expedition sollen immer weniger benötigt werden als basisrohstoffe. es muss absolut gewährleistet sein das alle rohstoffe genutzt werden. bei verschiedenen gebäuden dürfen natürlich gleiche rohstoffe vorkommen aber es darf kein rohstoff ohne verwendung übrig bleiben. die gewählten basisrohstoffe sollten möglichst gleich verteilt werden.
6. jedem gebäude und gebäude upgrade soll ein rang zum freischalten zugewiesen werden. sollten ränge übrig bleiben weil nicht genügend gebäude oder upgrades vorhanden sind ist das ok, sollten zu wenig ränge vorhanden sein fehlermeldun "Zu wenig Ränge". jedem gebäude und upgrade muss zwingend ein rang zugeordnet werden.
Ausnahme bilden die folgenden Gebäude: die 4 Startgebäude auf level 1 da diese schon von anfang an frei sind. Der Marktplatz soll immer eine zählervorrausssetzung haben (zwischen x und y mit dem fahrenden Händler gehandelt). Alchemielabor und Werkstatt zählervoraussetzung (x anzahl Gebäude). lotterie zählervorraussetzung (x anzahl herstellbarer Rohstoffe). Expedition zählervorraussetzung ( x menge an Rohstoffen erhalten).
 
Part 2
Der Rang Wanderer bleibt wie er ist da es der startrang ist.
1. Ränge sollen immer 1-2 münzen kosten. zusätzlich sollen auch hier jedem rang rohstoffe als kosten zugewiesen werden indem die selbe logik wie bei den gebäuden verwendet wird. mittelwert aller handelswerte mal 30 um grundkosten zu ermitteln, 2-3 rohstoffe, mindestens 1 Basisrohstoff, weniger werkzeuge, elemente oder expeditionsrohstoffe als basisrohstoffe, ungefähres erreichen der grundkosten mit den addierten handelswerten, zwingende benutzung aller rohstoffe, mehrfachnutzung von rohstoffen möglich. 
2. Jeder rang braucht zwingend eine vorraussetzung zum freischalten. Hier sollen zufällig aus der liste der gebäude, deren upgrades oder zählern gewählt werden. Es muss darauf geachtet werden das eine vorraussetzung nicht das selbe gebäude oder upgrade beinhaltet das der rang laut der neu errechneten werte für gebäude verwalten frei schaltet.
 
Part 3
1. die Expeditionen sollen einem zufälligen rang zugeordnet werden. sollten ränge vorhanden sein die noch nichts anderes freischalten sollen diese bevorzugt gewählt werden. an sonsten zufällig irgend einer.
2. die rohstoffkosten sollen neu vergeben werden. zwischen 3 und 4 zufällige basisrohstoffe. hier soll der mittlere Handelswert aller basisrohstoffe ermittelt werden und diese zahl mit 30 multipliziert werden um die grundkosten zu ermitteln. dann sollen die gewählten Rohstoffe so verteilt werden daß deren gesamter Handelswert ungefähr den grundkosten entspricht. gleichmäßige Verteilung.

Part 4
1. Boosts sollen nur gefunden werden in lotterie oder Expeditionen. keine rang vorraussetzungen. für die aktivierungskosten sollen neue Rohstoffe vergeben werden. nur aus basisrohstoffen. es dürfen nicht die Rohstoffe gebraucht werden die in dem zielgebäude erzeugt werden. auch hier wird erst ein Grundwert ermittelt mit dem mittleren Handelswert aller basisrohstoffe mal 5 und dann 2 zufällige basisrohstoffe gewählt. die summe der gewählten menge an basisrohstoffen soll ungefähr dem errechneten Handelswert entsprechen.

python3 randomize_game_data.py

ssh Nostrala@192.168.178.44

cd /volume1/web/spielegruppe

python3 start_randomization.py

Übergabe-Dokument: Randomisierungs-Skript für "Das Wandelnde Dorf"

Ziel:
Erstellung eines Python-Skripts (randomize_game_data.py), das die Kosten und Voraussetzungen für Gebäude, Upgrades, Ränge, Expeditionen und Boosts im Spiel "Das Wandelnde Dorf" neu und zufällig zuweist. Das Skript soll dem Admin eine neue, zufällige Spielbalance als Startpunkt liefern, die dann manuell im Admin-Panel feingetunt werden kann.

Voraussetzungen vor Ausführung:

Datenbank-Backup: Ein vollständiges Backup der wandelndes_dorf_game-Datenbank ist zwingend erforderlich.

Python-Umgebung: Eine funktionierende Python 3-Installation auf dem System, auf dem das Skript ausgeführt wird (idealerweise direkt auf dem NAS).

MySQL Connector: Die Python-Bibliothek mysql-connector-python muss installiert sein (pip install mysql-connector-python).

Datenbank-Schema Anpassungen (WICHTIG!):

Die Tabelle game_buildings muss die Spalte is_starter_building (BOOLEAN/TINYINT(1), DEFAULT 0) enthalten. Die 4 Startgebäude müssen in dieser Spalte manuell auf 1 gesetzt werden.

Die Tabelle game_ranks muss die folgenden Spalten für Zähler-Voraussetzungen enthalten (Datentypen prüfen/anpassen):

req_stat_buildings_built_total (INT)

req_stat_resources_collected_total_amount (DECIMAL(20,4) oder ähnlich)

req_stat_distinct_resources_collected (INT)

(Überprüfe, ob alle anderen benötigten req_stat_*-Spalten ebenfalls existieren).

Konfiguration im Skript:

Die DB_CONFIG-Variable muss die korrekten Zugangsdaten zur wandelndes_dorf_game-Datenbank enthalten (Host-IP des NAS, Port, Benutzer, Passwort).

Diverse Parameter für die Randomisierung (z.B. Kosten-Multiplikatoren, Toleranzen, Wertebereiche für Zähler) sind am Anfang des Skripts definiert und können angepasst werden.

Ausführungsmodell (Phasen mit finaler Bestätigung):

Phasenweiser Aufbau im Speicher: Das Skript durchläuft die Randomisierungsphasen (Gebäude, Ränge, Expeditionen, Boosts) nacheinander. Die geplanten Änderungen jeder Phase werden nur im Arbeitsspeicher in einem globalen Dictionary (planned_changes) gesammelt.

Bestätigung pro Phase (Simuliert): Nach jeder Phase zeigt das Skript die für diese Phase geplanten Änderungen an und fragt den Benutzer: Plan für Phase X übernehmen und fortfahren (ja/nein/neu)?

ja: Die Änderungen dieser Phase werden zum globalen planned_changes-Plan hinzugefügt. Das Skript geht zur nächsten Phase.

nein: Das Skript bricht sofort ab. Keine Änderungen werden in die Datenbank geschrieben.

neu: Die Randomisierung nur für die aktuelle Phase wird erneut durchgeführt und das Ergebnis wieder zur Bestätigung angezeigt.

Finale Gesamtübersicht: Nachdem alle Phasen bestätigt wurden, zeigt das Skript eine vollständige Liste aller Änderungen aus dem planned_changes-Dictionary an (idealerweise als "Alt -> Neu"-Vergleich) und listet alle während der Randomisierung aufgetretenen Warnungen auf (z.B. ungenutzte Rohstoffe, fehlgeschlagene Kostenzuweisungen).

Finale Bestätigung: Das Skript fragt ein letztes Mal: Sollen ALLE diese Änderungen jetzt unwiderruflich in die Datenbank geschrieben werden? (ja/NEIN):

Datenbank-Update (Atomar): Nur wenn die finale Bestätigung "ja" lautet, wird EINE Datenbank-Transaktion gestartet, alle alten relevanten Daten (Kosten, Voraussetzungen) gelöscht und alle neuen Daten aus planned_changes eingefügt/aktualisiert. Bei Erfolg -> Commit. Bei Fehler -> Rollback.

Detaillierte Logik der Randomisierungs-Phasen:

Phase 0: Daten lesen & Vorbereitung

Alle relevanten Daten aus game_resources, game_ranks, game_buildings, game_building_levels, game_expedition_missions, game_boosts, etc. in Python-Datenstrukturen laden.

starter_building_ids und special_building_ids anhand von is_starter_building und SPECIAL_BUILDING_NAMES identifizieren.

Die Ränge der Spezialgebäude (reserved_rank_ids) ermitteln und prüfen, ob alle Spezialgebäude einen gültigen Rang zugewiesen haben (Fehler bei Fehlen). Rang 1 auch reservieren.

Gültige trade_value (> 0) extrahieren und prüfen, ob mindestens 2 vorhanden sind (Fehler bei weniger).

grundkosten berechnen: ((min_trade_value + max_trade_value) / 2) * BASE_COST_TARGET_MULTIPLIER.

upgrade_grundkosten berechnen: grundkosten * UPGRADE_COST_TARGET_FACTOR.

Listen für Basis- und Nicht-Basis-Rohstoffe mit gültigem trade_value erstellen.

Initialisiere leere Zähler für Rohstoffverwendung (resource_usage_counter, basis_resource_usage_counter).

Phase 1: Gebäude Randomisierung

Ziel: Kosten & Rang-Reqs für Gebäude Lvl 1 und alle Upgrades (>1) neu zuweisen.

Startgebäude:

Setze build_cost_coins = STARTER_BUILDING_COST_COINS.

Setze required_rank_id_build = NULL.

Lösche Einträge aus game_building_build_costs.

Behandle ihre Upgrades (Lvl > 1) wie normale Upgrades (siehe unten).

Andere Gebäude (Bau Lvl 1):

Setze build_cost_coins = 0.

Lösche alte Einträge aus game_building_build_costs.

Generiere neue Rohstoffkosten (2-3 Rohstoffe, min 1 Basis/max 1 Nicht-Basis, Wert ~grundkosten +/- Toleranz, bevorzuge wenig genutzte Rohstoffe). Bei Fehler -> Warnung speichern. Tracke Nutzung in resource_usage_counter / basis_resource_usage_counter.

Alle Upgrades (Lvl > 1, auch für Starter):

Lösche alte Einträge aus game_building_upgrade_costs für das jeweilige Gebäude/Level.

Generiere neue Rohstoffkosten (2-3 Rohstoffe, min 1 Basis/max 1 Nicht-Basis, Wert ~upgrade_grundkosten +/- Toleranz, bevorzuge wenig genutzte). Bei Fehler -> Warnung speichern. Tracke Nutzung.

Rang-Reqs zuweisen:

Identifiziere Ziele: Bau Lvl 1 (Nicht-Starter/Nicht-Spezial) + Upgrades Lvl > 1 (Nicht-Starter).

Identifiziere verfügbare Ränge: Alle Ränge außer Rang 1 und reserved_rank_ids.

Prüfe, ob anzahl(Ziele) <= anzahl(verfügbare Ränge). Wenn nicht -> Fehler & Abbruch.

Mische verfügbare Ränge. Weise jedem Ziel eindeutig den nächsten verfügbaren Rang zu. Speichere Updates für game_buildings.required_rank_id_build und game_building_levels.upgrade_requires_rank_id.

Zähler für Spezial-Ränge planen:

Für jeden reserved_rank_id: Setze die vordefinierte Zähler-Voraussetzung (aus EXCEPTION_BUILDING_RANK_STATS) und setze alle anderen req_stat_*-Spalten für diesen Rang auf NULL/0. Prüfe, ob die Zähler-Spalte existiert (Warnung bei Fehlen).

Prüfung "Alle genutzt" (Phase 1): Prüfe resource_usage_counter. Wenn Rohstoffe ungenutzt -> Warnung speichern.

Phase 2: Rang Randomisierung

Ziel: Kosten & Voraussetzungen für Ränge neu zuweisen; Boni verteilen.

Rang-Kosten:

Für alle Ränge (außer Wanderer): Setze cost_coins zufällig auf 1 oder 2.

Lösche alte Einträge aus game_rank_req_resources.

Generiere neue Rohstoffkosten (2-3 Rohstoffe, min 1 Basis/max 1 Nicht-Basis, Wert ~grundkosten +/- Toleranz, benutze eigenen Satz Nutzungszähler rank_*_usage_counter). Bei Fehler -> Warnung speichern.

Bonus-Zuweisung:

Bauplätze: Berechne Bedarf (total_buildings - specials - starters - 4). Wähle zufällig geeignete Ränge (nicht Wanderer, nicht reserviert, noch kein Bonus) und weise +3/+4 bonus_building_slots zu, bis Bedarf gedeckt. Abbruch bei zu wenig Rängen. Markiere Ränge.

Kapazität: Wähle zufällig geeignete Ränge (nicht Wanderer, nicht reserviert, noch kein Bonus) und weise +15/20/25 bonus_capacity zu, bis Ziel (~100) erreicht. Markiere Ränge.

Rang-Voraussetzungen:

Für alle Ränge (außer Wanderer, reservierte Ränge, Ränge mit Bonus):

Lösche alte Einträge aus game_rank_req_buildings. Setze alle req_stat_* auf NULL/0.

Ermittle gültige potenzielle Voraussetzungen (Gebäude/Upgrades, deren required_rank_id eine niedrigere rank_order hat; Zähler, deren Quelle vor diesem Rang verfügbar ist).

Wähle zufällig eine gültige Voraussetzung (Gebäude, Upgrade oder Zähler). Bevorzuge selten genutzte.

Wenn Zähler: Wähle Wert zufällig aus definiertem Bereich (STAT_VALUE_RANGES). Bei item_crafted wähle zufälliges Werkzeug/Element.

Speichere die neue Voraussetzung (entweder als Eintrag in game_rank_req_buildings oder durch Setzen der passenden req_stat_*-Spalte in game_ranks).

Bei Fehler (keine gültige Option gefunden) -> Warnung speichern.

Prüfung "Alle genutzt" (Phase 2): Prüfe rank_resource_usage_counter. Wenn Rohstoffe ungenutzt -> Warnung speichern.

Phase 3: Expeditionen Randomisierung

Ziel: Rang-Reqs und Kosten für Missionen neu zuweisen.

Rang-Reqs:

Für jede Mission: Weise einen zufälligen Rang zu (aus nutzbaren Rängen, bevorzuge Ränge ohne wichtige Freischaltung/Bonus).

Speichere Updates für game_expedition_missions.requires_rank_id.

Kosten:

Berechne expedition_grundkosten (avg_basis_trade_value * EXPEDITION_COST_TARGET_MULTIPLIER).

Lösche alte Einträge aus game_expedition_mission_costs.

Für jede Mission: Wähle 3-4 zufällige Basis-Rohstoffe. Berechne Mengen, um expedition_grundkosten +/- Toleranz zu treffen. Bei Fehler -> Warnung speichern. Füge neue Kosten in game_expedition_mission_costs ein.

Phase 4: Boosts Randomisierung

Ziel: Aktivierungskosten neu zuweisen.

Kosten:

Berechne boost_grundkosten (avg_basis_trade_value * BOOST_COST_TARGET_MULTIPLIER).

Für jeden Boost:

Ermittle produzierte Rohstoffe des Zielgebäudes (forbidden_resources).

Wähle einen zufälligen Basis-Rohstoff, der nicht in forbidden_resources ist.

Berechne Menge (round(boost_grundkosten / trade_value)).

Speichere Update für game_boosts.activation_cost_resource_id, game_boosts.activation_cost_amount, game_boosts.activation_cost_coins = 0. Bei Fehler -> Warnung speichern.

Finale Phase: Bestätigung & Schreiben

Zeige alle Änderungen aus planned_changes im "Alt -> Neu"-Format an.

Liste alle gesammelten Warnungen auf.

Hole finale ja/nein-Bestätigung.

Bei "ja": Führe alle geplanten DELETEs, UPDATEs, INSERTs in einer Transaktion aus. Commit oder Rollback.

Ausgeschlossen:

Die Neuberechnung von trade_value ist nicht Teil dieses Skripts.

Dies sollte eine vollständige und genaue Beschreibung der vereinbarten Logik sein, die als Grundlage für die Python-Implementierung dient.


Okay, verstanden. Hier ist die vollständige Zusammenfassung aller besprochenen Logiken und Entscheidungen für das Python-Randomisierungs-Skript (randomize_game_data.py). Diese Zusammenfassung kann an einen anderen Chat/AI übergeben werden, der den Code dann implementieren soll.

Übergabe-Dokument: Randomisierungs-Skript für "Das Wandelnde Dorf"

Ziel:
Erstellung eines Python-Skripts (randomize_game_data.py), das die Kosten und Voraussetzungen für Gebäude, Upgrades, Ränge, Expeditionen und Boosts im Spiel "Das Wandelnde Dorf" neu und zufällig zuweist. Das Skript soll dem Admin eine neue, zufällige Spielbalance als Startpunkt liefern, die dann manuell im Admin-Panel feingetunt werden kann.

Voraussetzungen vor Ausführung:

Datenbank-Backup: Ein vollständiges Backup der wandelndes_dorf_game-Datenbank ist zwingend erforderlich.

Python-Umgebung: Eine funktionierende Python 3-Installation auf dem System, auf dem das Skript ausgeführt wird (idealerweise direkt auf dem NAS).

MySQL Connector: Die Python-Bibliothek mysql-connector-python muss installiert sein (pip install mysql-connector-python).

Datenbank-Schema Anpassungen (WICHTIG!):

Die Tabelle game_buildings muss die Spalte is_starter_building (BOOLEAN/TINYINT(1), DEFAULT 0) enthalten. Die 4 Startgebäude müssen in dieser Spalte manuell auf 1 gesetzt werden.

Die Tabelle game_ranks muss die folgenden Spalten für Zähler-Voraussetzungen enthalten (Datentypen prüfen/anpassen):

req_stat_buildings_built_total (INT)

req_stat_resources_collected_total_amount (DECIMAL(20,4) oder ähnlich)

req_stat_distinct_resources_collected (INT)

(Überprüfe, ob alle anderen benötigten req_stat_*-Spalten ebenfalls existieren).

Konfiguration im Skript:

Die DB_CONFIG-Variable muss die korrekten Zugangsdaten zur wandelndes_dorf_game-Datenbank enthalten (Host-IP des NAS, Port, Benutzer, Passwort).

Diverse Parameter für die Randomisierung (z.B. Kosten-Multiplikatoren, Toleranzen, Wertebereiche für Zähler) sind am Anfang des Skripts definiert und können angepasst werden.

Ausführungsmodell (Phasen mit finaler Bestätigung):

Phasenweiser Aufbau im Speicher: Das Skript durchläuft die Randomisierungsphasen (Gebäude, Ränge, Expeditionen, Boosts) nacheinander. Die geplanten Änderungen jeder Phase werden nur im Arbeitsspeicher in einem globalen Dictionary (planned_changes) gesammelt.

Bestätigung pro Phase (Simuliert): Nach jeder Phase zeigt das Skript die für diese Phase geplanten Änderungen an und fragt den Benutzer: Plan für Phase X übernehmen und fortfahren (ja/nein/neu)?

ja: Die Änderungen dieser Phase werden zum globalen planned_changes-Plan hinzugefügt. Das Skript geht zur nächsten Phase.

nein: Das Skript bricht sofort ab. Keine Änderungen werden in die Datenbank geschrieben.

neu: Die Randomisierung nur für die aktuelle Phase wird erneut durchgeführt und das Ergebnis wieder zur Bestätigung angezeigt.

Finale Gesamtübersicht: Nachdem alle Phasen bestätigt wurden, zeigt das Skript eine vollständige Liste aller Änderungen aus dem planned_changes-Dictionary an (idealerweise als "Alt -> Neu"-Vergleich) und listet alle während der Randomisierung aufgetretenen Warnungen auf (z.B. ungenutzte Rohstoffe, fehlgeschlagene Kostenzuweisungen).

Finale Bestätigung: Das Skript fragt ein letztes Mal: Sollen ALLE diese Änderungen jetzt unwiderruflich in die Datenbank geschrieben werden? (ja/NEIN):

Datenbank-Update (Atomar): Nur wenn die finale Bestätigung "ja" lautet, wird EINE Datenbank-Transaktion gestartet, alle alten relevanten Daten (Kosten, Voraussetzungen) gelöscht und alle neuen Daten aus planned_changes eingefügt/aktualisiert. Bei Erfolg -> Commit. Bei Fehler -> Rollback.

Detaillierte Logik der Randomisierungs-Phasen:

Phase 0: Daten lesen & Vorbereitung

Alle relevanten Daten aus game_resources, game_ranks, game_buildings, game_building_levels, game_expedition_missions, game_boosts, etc. in Python-Datenstrukturen laden.

starter_building_ids und special_building_ids anhand von is_starter_building und SPECIAL_BUILDING_NAMES identifizieren.

Die Ränge der Spezialgebäude (reserved_rank_ids) ermitteln und prüfen, ob alle Spezialgebäude einen gültigen Rang zugewiesen haben (Fehler bei Fehlen). Rang 1 auch reservieren.

Gültige trade_value (> 0) extrahieren und prüfen, ob mindestens 2 vorhanden sind (Fehler bei weniger).

grundkosten berechnen: ((min_trade_value + max_trade_value) / 2) * BASE_COST_TARGET_MULTIPLIER.

upgrade_grundkosten berechnen: grundkosten * UPGRADE_COST_TARGET_FACTOR.

Listen für Basis- und Nicht-Basis-Rohstoffe mit gültigem trade_value erstellen.

Initialisiere leere Zähler für Rohstoffverwendung (resource_usage_counter, basis_resource_usage_counter).

Phase 1: Gebäude Randomisierung

Ziel: Kosten & Rang-Reqs für Gebäude Lvl 1 und alle Upgrades (>1) neu zuweisen.

Startgebäude:

Setze build_cost_coins = STARTER_BUILDING_COST_COINS.

Setze required_rank_id_build = NULL.

Lösche Einträge aus game_building_build_costs.

Behandle ihre Upgrades (Lvl > 1) wie normale Upgrades (siehe unten).

Andere Gebäude (Bau Lvl 1):

Setze build_cost_coins = 0.

Lösche alte Einträge aus game_building_build_costs.

Generiere neue Rohstoffkosten (2-3 Rohstoffe, min 1 Basis/max 1 Nicht-Basis, Wert ~grundkosten +/- Toleranz, bevorzuge wenig genutzte Rohstoffe). Bei Fehler -> Warnung speichern. Tracke Nutzung in resource_usage_counter / basis_resource_usage_counter.

Alle Upgrades (Lvl > 1, auch für Starter):

Lösche alte Einträge aus game_building_upgrade_costs für das jeweilige Gebäude/Level.

Generiere neue Rohstoffkosten (2-3 Rohstoffe, min 1 Basis/max 1 Nicht-Basis, Wert ~upgrade_grundkosten +/- Toleranz, bevorzuge wenig genutzte). Bei Fehler -> Warnung speichern. Tracke Nutzung.

Rang-Reqs zuweisen:

Identifiziere Ziele: Bau Lvl 1 (Nicht-Starter/Nicht-Spezial) + Upgrades Lvl > 1 (Nicht-Starter).

Identifiziere verfügbare Ränge: Alle Ränge außer Rang 1 und reserved_rank_ids.

Prüfe, ob anzahl(Ziele) <= anzahl(verfügbare Ränge). Wenn nicht -> Fehler & Abbruch.

Mische verfügbare Ränge. Weise jedem Ziel eindeutig den nächsten verfügbaren Rang zu. Speichere Updates für game_buildings.required_rank_id_build und game_building_levels.upgrade_requires_rank_id.

Zähler für Spezial-Ränge planen:

Für jeden reserved_rank_id: Setze die vordefinierte Zähler-Voraussetzung (aus EXCEPTION_BUILDING_RANK_STATS) und setze alle anderen req_stat_*-Spalten für diesen Rang auf NULL/0. Prüfe, ob die Zähler-Spalte existiert (Warnung bei Fehlen).

Prüfung "Alle genutzt" (Phase 1): Prüfe resource_usage_counter. Wenn Rohstoffe ungenutzt -> Warnung speichern.

Phase 2: Rang Randomisierung

Ziel: Kosten & Voraussetzungen für Ränge neu zuweisen; Boni verteilen.

Rang-Kosten:

Für alle Ränge (außer Wanderer): Setze cost_coins zufällig auf 1 oder 2.

Lösche alte Einträge aus game_rank_req_resources.

Generiere neue Rohstoffkosten (2-3 Rohstoffe, min 1 Basis/max 1 Nicht-Basis, Wert ~grundkosten +/- Toleranz, benutze eigenen Satz Nutzungszähler rank_*_usage_counter). Bei Fehler -> Warnung speichern.

Bonus-Zuweisung:

Bauplätze: Berechne Bedarf (total_buildings - specials - starters - 4). Wähle zufällig geeignete Ränge (nicht Wanderer, nicht reserviert, noch kein Bonus) und weise +3/+4 bonus_building_slots zu, bis Bedarf gedeckt. Abbruch bei zu wenig Rängen. Markiere Ränge.

Kapazität: Wähle zufällig geeignete Ränge (nicht Wanderer, nicht reserviert, noch kein Bonus) und weise +15/20/25 bonus_capacity zu, bis Ziel (~100) erreicht. Markiere Ränge.

Rang-Voraussetzungen:

Für alle Ränge (außer Wanderer, reservierte Ränge, Ränge mit Bonus):

Lösche alte Einträge aus game_rank_req_buildings. Setze alle req_stat_* auf NULL/0.

Ermittle gültige potenzielle Voraussetzungen (Gebäude/Upgrades, deren required_rank_id eine niedrigere rank_order hat; Zähler, deren Quelle vor diesem Rang verfügbar ist).

Wähle zufällig eine gültige Voraussetzung (Gebäude, Upgrade oder Zähler). Bevorzuge selten genutzte.

Wenn Zähler: Wähle Wert zufällig aus definiertem Bereich (STAT_VALUE_RANGES). Bei item_crafted wähle zufälliges Werkzeug/Element.

Speichere die neue Voraussetzung (entweder als Eintrag in game_rank_req_buildings oder durch Setzen der passenden req_stat_*-Spalte in game_ranks).

Bei Fehler (keine gültige Option gefunden) -> Warnung speichern.

Prüfung "Alle genutzt" (Phase 2): Prüfe rank_resource_usage_counter. Wenn Rohstoffe ungenutzt -> Warnung speichern.

Phase 3: Expeditionen Randomisierung

Ziel: Rang-Reqs und Kosten für Missionen neu zuweisen.

Rang-Reqs:

Für jede Mission: Weise einen zufälligen Rang zu (aus nutzbaren Rängen, bevorzuge Ränge ohne wichtige Freischaltung/Bonus).

Speichere Updates für game_expedition_missions.requires_rank_id.

Kosten:

Berechne expedition_grundkosten (avg_basis_trade_value * EXPEDITION_COST_TARGET_MULTIPLIER).

Lösche alte Einträge aus game_expedition_mission_costs.

Für jede Mission: Wähle 3-4 zufällige Basis-Rohstoffe. Berechne Mengen, um expedition_grundkosten +/- Toleranz zu treffen. Bei Fehler -> Warnung speichern. Füge neue Kosten in game_expedition_mission_costs ein.

Phase 4: Boosts Randomisierung

Ziel: Aktivierungskosten neu zuweisen.

Kosten:

Berechne boost_grundkosten (avg_basis_trade_value * BOOST_COST_TARGET_MULTIPLIER).

Für jeden Boost:

Ermittle produzierte Rohstoffe des Zielgebäudes (forbidden_resources).

Wähle einen zufälligen Basis-Rohstoff, der nicht in forbidden_resources ist.

Berechne Menge (round(boost_grundkosten / trade_value)).

Speichere Update für game_boosts.activation_cost_resource_id, game_boosts.activation_cost_amount, game_boosts.activation_cost_coins = 0. Bei Fehler -> Warnung speichern.

Finale Phase: Bestätigung & Schreiben

Zeige alle Änderungen aus planned_changes im "Alt -> Neu"-Format an.

Liste alle gesammelten Warnungen auf.

Hole finale ja/nein-Bestätigung.

Bei "ja": Führe alle geplanten DELETEs, UPDATEs, INSERTs in einer Transaktion aus. Commit oder Rollback.

Ausgeschlossen:

Die Neuberechnung von trade_value ist nicht Teil dieses Skripts.

Dies sollte eine vollständige und genaue Beschreibung der vereinbarten Logik sein, die als Grundlage für die Python-Implementierung dient.