Oggetti: istanze inventario o nuovi ID oggetto?

17/08/2026 10:24:56

Ciao a tutti, in SID – L’Avventura Continua sto ragionando su una modifica al sistema oggetti di GDR-CD e mi farebbe comodo capire come avete affrontato casi simili nei vostri giochi.Attualmente abbiamo la classica struttura in cui id_oggetto identifica il modello/tipologia dell’oggetto: quindi tutte le copie di una “Spada bastarda”, indipendentemente dal possessore, fanno riferimento allo stesso oggetto.Finché gli oggetti sono standard funziona bene. Il problema nasce quando vogliamo avere oggetti personalizzati o modificati: per esempio una determinata Spada bastarda che diventa la “Spada di Ugo”, con nome, descrizione e immagine propri; oppure un oggetto temporaneamente alterato, con bonus/statistiche differenti e che successivamente può tornare alla versione originale.Sto valutando due strade.1. Identificativo dell’istanza o del lotto in inventarioMantenere lo stesso id_oggetto, ma aggiungere alla tabella di possesso un ID univoco della riga inventario.Concettualmente è molto pulito: separa il modello dell’oggetto dalla specifica istanza posseduta.Di contro, richiede di adeguare parecchie funzioni che oggi lavorano direttamente con id_oggetto: equipaggiamento, cessione, deposito, uso in chat, consumo e così via.2. Creare un nuovo id_oggetto quando nasce una varianteLa “Spada di Ugo” diventerebbe quindi un nuovo record della tabella oggetti, eventualmente collegato alla Spada bastarda originale.È meno rigoroso dal punto di vista della distinzione tra modello e istanza, ma ha un vantaggio importante: tutto il sistema esistente continua naturalmente a trattarla come un oggetto distinto, senza dover modificare buona parte delle funzioni già presenti.Per gli oggetti normali le quantità continuerebbero comunque a essere aggregate: non vorrei creare una riga per ogni singola spada, boccetta o pergamena esistente.Voi come avete risolto?Avete introdotto un ID dell’istanza inventario, creato oggetti derivati con nuovi ID, oppure utilizzato un’altra soluzione?E soprattutto, con il senno di poi, quale scelta vi ha creato meno problemi nel resto di GDR-CD?Ogni esperienza diretta è più che benvenuta: stiamo cercando di far crescere il sistema oggetti di SID – L’Avventura Continua senza trasformare una miglioria in una ristrutturazione archeologica dell’intero codice.

17/08/2026 12:23:33

Mi sembra un quadro già ben delineato ed entrambi gli approcci rappresentano un modo valido di gestire la casistica. Un ulteriore approccio, che mi permetto di suggerire, potrebbe essere quello di creare una nuova tabella per le personalizzazioni degli oggetti. Ogni riga in questa nuova tabella rappresenterebbe una personalizzazione (si potrebbero duplicare le colonne della tabella oggetto che interessa poter personalizzare, con default tutto null) e questa sarebbe agnostica e identificata con uno specifico ID univoco.A quel punto, la specifica personalizzazione si potrebbe linkare in clgpersonaggio oggetto mediante una nuova colonna. Per cui, creare una nuova personalizzazione consisterebbe nel creare una riga in questa tabella e assegnare il link in clgpersonaggio oggetto. Lato modifiche necessarie bisognerebbe far si che, quando l'oggetto viene ceduto, il link alla corretta personalizzazione venga preservato. Mentre nelle queries di lettura degli oggetti in zaino/inventario/chat sarebbe necessario applicare una left join dove vengono recuperati i valori della personalizzazione al posto di quelli della tabella oggetto se definiti ( IFNULL ).Il cambiamento a livello di logica del sistema esistente sarebbe minimo in questo modo, andrebbe solo creato un pannellino admin per gestire le personalizzazioni.Ho scritto un po' di fretta, ma spero di essere stato comprensibile.

17/08/2026 12:27:38

Come gestisci l'assegnazione oggetto? Se hai una tabella personaggio_oggetto con id_oggetto e id_personaggio puoi aggiungerci altri campi come descrizione e immagine. Quando compri/assegni l'oggetto importi i dati originali, quando lo personalizzi salvi direttamente la nuova descrizione e immagine in questi campi.Senza modificare la struttura di gdrcd si crea una tabella a parte caricando i dati con un leftjoin e un IFNULL esattamente come proposto da Blanks. Questo è il metodo migliore perchè ti permette di popolare la tabella nuova SOLO se ci sono effettivamente personalizzazioni dell'oggetto, evitando il salvataggio di record obsoleti che appesantirebbero nel tempo il caricamento dei dati e della scheda.

Modificato da brom87 il 17/08/2026 12:38:46

17/08/2026 14:59:18

Grazie, entrambe le proposte mi sono molto utili.Provo a spiegare meglio la casistica concreta che devo coprire, perché in realtà ho due esigenze differenti.1. Oggetti personalizzatiQui la modifica è sostanzialmente estetica/narrativa.Esempio: una normale Spada bastarda può diventare la “Spada di Ugo”, con nome, descrizione e immagine propri, ma senza modificare i bonus o le caratteristiche meccaniche dell’oggetto base.In questo caso una tabella separata delle personalizzazioni, collegata alla riga posseduta, mi sembra effettivamente molto pulita: i campi non personalizzati continuerebbero a essere letti dall’oggetto originale.2. Oggetti alterati/incantatiQuesta è la parte un po’ più particolare.Vorrei poter prendere un oggetto normale e applicargli temporaneamente un effetto che può modificarne anche le caratteristiche meccaniche.Esempio: una normale Collana viene incantata con uno “Scudo Magico”. La Collana rimane fisicamente la stessa, ma finché l’incantamento è presente può avere nome, descrizione, reazione e bonus differenti.Quando l’effetto viene utilizzato o esaurisce le proprie cariche, l’incantamento deve sparire e l’oggetto deve tornare automaticamente alla normale Collana originale, invece di essere eliminato come accadrebbe a una pozione consumabile.Stesso concetto, per esempio, per dei Guanti normali temporaneamente alterati con +1 Atletica: terminato l’effetto, rimangono dei Guanti normali.Quindi la personalizzazione sarebbe tendenzialmente permanente ed estetica, mentre l’alterazione sarebbe uno stato funzionale anche temporaneo.Il dubbio che mi rimane sulla soluzione con tabella separata riguarda soprattutto l’identificazione della riga posseduta.Attualmente clgpersonaggiooggetto ha come chiave primaria composta nome + id_oggetto. Quindi, di fatto, uno stesso personaggio può avere una sola riga per ogni id_oggetto.Se un personaggio possiede:Spada bastarda ×4e ne personalizzo o altero soltanto una, vorrei arrivare a:Spada bastarda ×3Spada bastarda personalizzata/alterata ×1mantenendo però lo stesso id_oggetto del modello originale.A quel punto avrei bisogno di due righe riferite allo stesso personaggio e allo stesso id_oggetto, ma con stato differente, cosa che con la PRIMARY attuale non è possibile.Voi come modifichereste questa parte?Aggiungereste comunque un identificativo univoco della riga, tipo id_inventario, rendendolo la nuova chiave primaria? Oppure usereste id_personalizzazione anche come elemento discriminante della chiave? O ancora avete adottato un’altra soluzione?Il dubbio nasce anche dal fatto che equipaggiamento, cessione, deposito in banca, vendita, uso in chat, consumo delle cariche ecc. nel GDR-CD attuale tendono a lavorare direttamente con personaggio + id_oggetto.Pensavo inizialmente a un id_inventario univoco proprio per poter distinguere in sicurezza due lotti dello stesso oggetto, ma vorrei capire se con la vostra soluzione della tabella separata riuscite a evitare un refactor troppo esteso.In particolare mi interessa molto l’idea del LEFT JOIN + IFNULL, perché permetterebbe di conservare l’oggetto base e sovrascrivere soltanto i campi realmente modificati.grazie

Modificato da rad il 17/08/2026 15:04:17

17/08/2026 15:15:33

Ho anch’io nella mia to-do list una modifica analoga, legata alla questione Artigianato / Upgrade degli oggetti.Non usando GDRCD, ma una struttura analoga per la gestione degli oggetti, penso che opterò per una tabella separata per i “potenziamenti”, aggiungendo un campo has_upgrade agli oggetti, che punti all’ID relativo della tabella items_upgrades, che a sua volta mi colleghi alla table upgrades.In questo modo devo “solo” passare anche questo valore nelle aste, nella cessione degli oggetti, nelle casse di gilda e in tutti gli altri sistemi che gestiscono gli oggetti, così da trascinarmi dietro anche i relativi potenziamenti.Inoltre, potrei gestire anche migliorie “multistrato” in una singola riga, con campi tipo id_item, upgrade_id e upgrade_level. In questo modo posso avere più tipologie di migliorie (Affilatura, Rinforzi, Gemme incantate, Accessori, ecc.) e al tempo stesso aumentare i vari livelli, mantenendo un sistema abbastanza snello ma molto scalabile.Non so se sia fattibile anche con GDRCD, ma penso che gestire i potenziamenti in una tabella separata e utilizzare una relazione molti-a-molti per collegarli agli oggetti sia probabilmente il modo più pulito per strutturare e gestire il tutto.Bisogna poi, ovviamente, “tirarsi dietro” questo ID in tutti i punti del codice in cui è necessario.Detto questo, magari ci sono soluzioni più pratiche o più pulite: questa è semplicemente la prima struttura che mi è venuta in mente.

Modificato da vortexdgdr il 17/08/2026 15:17:39

17/08/2026 15:48:40

rad ha scritto: [center] ...

La soluzione sulle personalizzazioni che ho proposto era pensata sul dover modificare il minimo necessario per fare le cose in modo comunque "pulito", ma la nuova esigenza sui bonus temporanei cambia un po' le carte in tavola. A questo punto non conviene unire tante soluzioni "a risparmio", ma la strada migliore e con meno imprevisti, a mio personale avviso, è di effettuare dei cambiamenti più formali sul modello dati.Questo richiederà qualche modifica di codice in più in giro, ma il sisistema sarebbe più flessibile per ulteriori aggiunte future e in generale dovrebbe semplificarne la gestione.Rendi entità univoche gli oggetti in clgpersonaggiooggetto:- Aggiungi una chiave primaria univoca su clgpersonaggiooggetto e rendila primary key.- Le colonne per la personalizzazione creale su clgpersonaggiooggetto, puoi ancora applicare il concetto dell'IFNULL.- Aggiorna la procedura di cessione di modo che non crei un oggetto nuovo nella borsa del destinatario, ma si limiti a cambiare il nome della riga dello specifico id bersgliato.- Aggiorna la procedura di cancellazione di modo che lavori sempre sull'id primario e non sulla coppia di colonne originali.- Aggiorna tutte le queries in lettura di modo che leggano i valori su clgpersonaggio se presenti - Aggiungi una nuova colonna "unico" con valori possibili 0/1 e usala come discriminante quando assegni al player lo stesso tipo di oggetti per determinare se puoi incrementarne il numero o creare una nuova riga.Questo risolve il problema della personalizzazione in modo formale.Per quanto riguarda i bonus temporanei serve invece necessariamente una nuova tabella.In questa nuova tabella puoi creare le colonne per tutti i possibili modificatori e ogni riga rappresenta un bonus temporaneo. Le colonne minime necessarie da creare sono un id autoincrementante univoco per ciascuna riga, l'id univoco dell'oggetto in clgpersonaggiooggetto, quelle dei bonus che possono essere modificati e il numero di cariche (o una data nel futuro se prevedi anche scadenze a tempo). Volendo anche una colonna che identifichi la fonte del modificatore in base a come funziona il sistema di assegnazione.Quando l'oggetto viene letto dal db, andrebbe fatta una ricerca nella tabella dei bonus temporanei per recuperare tutti i bonus attivi presenti sull'oggetto e sommati per ogni tipologia. A quel punto basta sommarli al totali precedentemente estratti dalla tabella oggetto.

18/08/2026 09:55:38

Grazie davvero a tutti per gli interventi, soprattutto a blancks, brom87 e vortexdgdr: ci avete dato parecchi spunti utili e alla fine ci avete aiutato a scegliere una strada molto più pulita di quella da cui eravamo partiti.Alla fine abbiamo separato in modo netto il concetto di oggetto base da quello della singola copia posseduta. Ogni riga di inventario ora ha un proprio identificativo univoco, mentre le personalizzazioni e le alterazioni vivono in tabelle dedicate collegate a quella specifica istanza.Questo ci permette di avere più copie dello stesso oggetto base, anche nello stesso inventario, ma con stati diversi: una normale, una personalizzata, una alterata, oppure una pila intera con la stessa modifica.Per i Custom abbiamo poi separato i dati descrittivi dagli eventuali bonus/malus, così possiamo gestire anche modifiche temporanee a usi senza creare nuovi oggetti base ogni volta. Quando l'effetto termina, l'oggetto torna semplicemente alla sua versione normale.La parte più lunga, come avevate giustamente previsto, è adattare tutti i punti che spostano o leggono gli oggetti — inventario, equipaggiamento, chat, cessioni, banca, mercato e così via — perché ora bisogna trascinarsi dietro l'identità della singola istanza e non solo l'ID del modello.Abbiamo anche migrato i vecchi Custom già esistenti nel nuovo sistema senza perdere descrizioni, immagini o commenti, quindi almeno la parte “archeologica” è passata indenne. 😅Grazie ancora davvero: questa è una di quelle volte in cui il confronto con la community ha evitato di costruire un sistema molto più fragile del necessario.

18/08/2026 11:50:30

rad ha scritto: Grazie ancora davvero: questa è una di quelle volte in cui il confronto con la community ha evitato di costruire un sistema molto più fragile del necessario.

Concordo pienamente: il confronto con la community è sempre motivo di crescita per tutti, non importa quanto si sia pratici col codice. In era LLM in molti non vengono più a confrontarsi con gli altri credendo, ingenuamente, che il risultato prodotto dall'IA sia sempre quello ottimale allo scopo e il tuo thread è stato una ventata d'aria fresca in tal senso, mostrando l'importanza di aprirsi ai suggerimenti esterni nonostante l'uso del tool. Se volessi offrire qualcosa in ritorno alla community, scrivere una piccola guida su come hai risolto questo problema condividendo, ad esempio, la struttura esatta delle tabelle che hai creato, i files di gdrcd che è stato necessario modificare e come, sarebbe un fantastico contributo per tutti 😉

21/08/2026 21:56:40

Grazie! Una guida completa non credo di esserne in grado, però posso lasciare volentieri qualche indicazione più concreta su quello che abbiamo fatto: magari può essere utile a chi volesse lavorare sugli oggetti di GDRCD.Il problema di partenza era che avevamo cominciato ad attribuire agli oggetti molte più informazioni rispetto al sistema standard: bonus, cariche, utilizzi in chat, oggetti consumabili e soprattutto oggetti personalizzati. Finché due copie dello stesso oggetto sono perfettamente identiche, ragionare soltanto per id_oggetto funziona; comincia invece a diventare limitante quando, per esempio, due personaggi possiedono lo stesso oggetto ma una delle due copie ha nome, descrizione, immagine, commento o caratteristiche proprie.La modifica strutturale più importante è stata quindi introdurre un id_inventario univoco, in modo da poter identificare la specifica riga/copia posseduta dal personaggio e non soltanto il modello di oggetto da cui deriva. Da lì abbiamo rivisto la gestione dell'inventario affinché operazioni come spostare, equipaggiare, cedere, dividere/riunire pile, modificare o utilizzare un oggetto continuassero a riferirsi alla copia corretta.Abbiamo poi separato meglio i dati. L'oggetto base continua a contenere le caratteristiche comuni dell'oggetto, mentre per le personalizzazioni abbiamo introdotto una gestione dedicata degli oggetti customizzati, così da poter conservare nome, immagine, descrizione e altre proprietà della singola variante senza dover duplicare l'intero oggetto di partenza. Lo stesso principio è stato applicato ai bonus degli oggetti, che da noi possono intervenire sui tiri soltanto nei casi previsti.Un altro passaggio è stato aggiungere la distinzione tra consumabili e permanenti e gestire quantità/cariche: quando un consumabile viene utilizzato, il sistema scala l'utilizzo e, una volta esaurito, lo elimina; un oggetto permanente può invece essere riutilizzato senza essere consumato.A quel punto è stato necessario propagare la nuova logica nelle varie parti di GDRCD che utilizzano gli oggetti: Inventario, Zaino, Equipaggiamento, cessioni, Banco/Mercato e chat. In chat abbiamo aggiunto anche “Usa oggetto”, che permette di richiamare realmente uno degli oggetti trasportati dal PG, con eventuale reazione e, dove previsto, collegamento ai tiri e ai bonus.La lezione principale, almeno nel nostro caso, è stata proprio quella emersa qui nella discussione: non conviene modificare soltanto la pagina Inventario. id_oggetto e le righe dell'inventario vengono richiamati in parecchi punti di GDRCD e, appena si introduce l'identità della singola copia, bisogna seguire tutto il percorso dell'oggetto: acquisto → inventario → eventuale personalizzazione → zaino/equipaggiamento → utilizzo → cessione o consumo.Non è quindi una modifica da “due righe”, ma neppure è stato necessario riscrivere da zero il sistema oggetti: abbiamo cercato il più possibile di estendere quello esistente mantenendo id_oggetto come riferimento all'oggetto base e id_inventario come riferimento alla specifica istanza posseduta. File che ho modificato, oltre inventario, equip, anche frame chat, mercato, ref header, e grosso modo questiSe può essere utile, posso recuperare anche lo schema preciso delle tabelle/campi che abbiamo aggiunto e i file GDRCD interessati, ma almeno questa è l'ossatura della soluzione che abbiamo adottato.