Und was machst du bei magischen Items? :DRober hat geschrieben: ↑30. Mai 2026, 12:08Wurde bisher nicht eher betont, dass eben doch insbesondere "viele Items von einer Sorte" das größere Problem seien? (Oder wirklich nur das am leichtesten behebare?)Schlawacko hat geschrieben: ↑30. Mai 2026, 11:38 Sehe halt (außer dem Programmieraufwand, den ich nicht einschätzen kann) nichts was gegen solche Funktionen spricht. Am Ende sind es nicht viele Items von einer Sorte, aber viele Items von vielen Sorten die sicherlich Teile des Problems bekämpfen und Spieler auf ihr Bankmanagement aufmerksam machen.
Interessehalber: Weg von "jedes Item hat eine eigene ID und einen eigenen Eintrag in der DB" hin zu "für jedes Item gibt es einen Eintrag in der DB und es wird pro Spieler/Feld die Anzahl der vorhandenen Items gespeichert" ist viel zu aufwendig? Es gibt halt einige Sonderfälle (Items mit X Anwendungen, usw), welche man ggf durch geeignete Codierungen innerhalb der IDs (oder DB-Einträge) beheben könnte. Transaktionsfehler sind natürlich nochmal etwas anderes, wobei man aufpassen müsste.
Nur um die Richtung zu skizzieren (da gibt's bestimmt einige Spezialfälle): "Jedes Item i hat eine Basis ID_i" (Item-Templates habt ihr ja eh). Wenn es erzeugt wird und auf Feld X/Y gelegt wird, dann wird es in der DB mit ID_i||X||Y gespeichert. Bekommt User mit ID_u es, dann Änderung zu ID_i||ID_u . Hatte der Spieler bereits ID_i||ID_u, dann wird einfach nur ein Counter entsprechend inkrementiert. Zusatzinformationen (wie das X bei gzk, oder ob es im SF liegt) kann man dann einfach dranhängen.
Da muss bei jedem einzeln hinterlegt sein, wann es sich auflöst. Außerdem musst du per Query jede Minuten prüfen, was sich jetzt auflösen muss.
