Dale wrote:
Ok I was wondering, I've been working on coverting some of my muds files to
an SQL database. This way I can add more features to our website.... So you
can control a little bit more from the site. For those who might not have
time to login to the mud. But need to agree to some invoices or what not.
^^ Sounds familiar, I've been doing the same ;)
My question is I would like to put the pfiles into the database. But the
problem I'm running into is the Objects, and Pets the player has.... Now I
realize I could make an object table and spill all the players objects into
that table. And store it by the ch_id and just call them in and out by
that.. But my problem with that, is won't that cause me to start taking up
more server space? Cause how objects works now it only saves whats changed
about the object... This would make it so the full object information was
being stored for each item.... IDK seems like a waste of space reallly...
Anyone have any advice on how maybe they cleaverly did their objects? I was
debating maybe still leaving a txt pfile and storing the recursive things
like objects in there.... But I figured I might ask to see if anyone else
had found a cleaver way to handle this.
This is one I've been struggling with for a while myself. I think the
best idea I've come up
with so far is something like this (but haven't tried it out yet):
Table 1: Objects
----------------------
ID (Primary Key, Auto Incr, Unsigned Int) - Unique Identifier
Vnum (Whatever type of int vnums are set to) - Base Obj
Name: (Varchar) - Alt name of object or NULL if there's no change to the
base obj.
Weight (int) - Alt weight of object or NULL if there's no change to the
base obj.
And so on down the line for all *changeable* fields on an obj.
Table 2: Inventory
------------------------
ID (Primary Key, Auto Incr, Unsigned Int) - Unique Identifier (helps in
making things easier to mod/del)
CharID (Int type) - Pointer to the pfile ID
Quantity (Int type) - Number of the particular object (Better than
having 100 pill entries for each of x number of people!)
ObjID (Unsigned Int) - Pointer back to the Objects table's `ID`
*Flag (enum 'D','M') - This is for idea #2*
Person 'A' picks up a 'rock', mud checks the database to see if a plain
old 'rock' exists, if not, it adds a record for it in
`Objects`, along with a character record in `Inventory`. Person 'A'
picks up 20 more 'rocks', mud finds a 'rock' in the `Objects`
table, so it changes the quantity field for the character to '21'.
Person 'B' and 'C' both have a restrung sword called "The
golden sword of Clan Whatchamacallit". Rather than having 2 entries in
the `Objects` table for the swords (since they're identical),
there is only one record, but both characters have a pointer in
`Inventory` referencing the restrung details.
Idea #2:
Similar to above, but a 'Flag' field is added to `Inventory`. If the
flag is set to 'D', it means that the object is a default object and
no changes were made to it, so it reads the information from the object
prototype loaded by the mud. If the object has some sort
of modification done to it, THEN it lists the object in the `Objects`
table, and sets the 'Flag' field in `Inventory` to 'M' so that
it knows to look for the info in the `Objects` table.
Idea #3:
Majorly limit what can and cant be changed on an obj.
No matter which of these possibilities someone goes with, it's going to
be some extensive changes. I think that's the only
reason I haven't tried it yet... no time!
Good luck, and let me know what you think :)
-- Jen
---
RogueDragon @ A Merging of Fates MUD
telnet://mud.merging.org:5454
icq: 2072355 (inactive atm), yim: roguedragon, aim: roguedragon69
---
Windows - Where do you want to go today?
Linux - Where do you want to go tomorrow?
FreeBSD - When are they going to catch up?
