Zugg Software :: View topic

Beginner Joined: 16 Jan 2002 Posts: 12

Quick question: was wondering if such endeavours have some practical limits. For example, I made a script which loops through items by vnum and records each attribute about every item by triggering off the "/stat itemname" info. ie statting an egg gets me:

I104 R:14895 S:Inside > /stat i egg
Name: 'an egg', Aliases: egg
Creator: Creator
Num: [ 240], Type: FOOD, SpecProc: Exists
L-Des: An egg is here.
Is bound to : None
Can be worn on: TAKE
Set char bits : NOBITS
Extra flags : NOBITS
Weight: 0.1, Cost: 3, Rent/day: 0, Timer: 0
In room: 14895, In object: None, Owned by: Nass
Makes full: 4, Poisoned: 0
Equipment Status: Inventory
Affections: None

and I've got a trigger set like:

Makes full: &hasmakesfull, Poisoned: &haspoisoned

which, together with all the other info gets put into a database variable and populates my database (but the window has to be open). It works just fine, other than two things: the window has to be open (and you actually see the cursor moving down the rows to check if the vnum is already in there - a part of the script which is the performance limiter) but there's also corruption as it gets bigger. Altogether, for the mud that I work at, the db amounts to about 30 fields per item, with about 1500 items in the mud. So that's about 45,000 separate bits of info for a complete database.

Really my question is this, is the above approach the best way to do this and is there anyway to stop corruption when it gets bigger? By corruption I mean stuff like fields going blank for no particular reason, and values in one field ending up in another whilst I'm using it and cursoring around, all of which I assume is really to do with the size of the thing and when it gets bigger these things just "happen".

GURU Joined: 15 Jun 2001 Posts: 654 Location: USA

It may be helpful to break it into several tables. The main table can hold all the generic item information (vnum, keywords, name, L-desc, weight, rentable and/or rent cost, wearability flags, etc) and indicate what type of object it is. Then a specialized table for that type can hold the type-specific data. They'd have to reference each other through record numbers. This works to eliminate the empty fields for the objects.

And what you note with having to have the database window open is normal. If it is not, then zMUD doesn't load that module and its associated commands are disabled.

You can vastly increase performance by putting it in offline mode while you are scripting changes to it.

- Charbal