Item System Efficiency
 

I want to redo Zodiacs item system. It's currently a mess. Each weapon has a file. There is than another file for every suffix/prefix/combination available for that weapon. In short: it's disgusting.

The items the player has are then stored as so

clientr.item-Bronze Cutlass=4,weapons/sword/bronzecutlass

The descriptions for each item the player has seen are stored like this

clientr.muditem_Bronze Cutlass="Bronze Cutlass",weapon,sword,hadez-bronzecutlassicon.png,hadez-bronzecutlass.png,zodsword,12,46,"","level,8",0.4, 1230,Neutral,0,0,0,1212634527.719118118

First off: I'm going to remove the need for new files for suffixes/prefixes. That's easy enough to do without a new file. Secondly, I want to do away with the item descriptions in clientr. vars. Can make a cache of item descriptions which is downloaded when you connect. Can make it check if the cache has been updated.

My question concerns how to make the most efficent item system possible. Should I

• Keep all these individual files and load from them when required? (harddrive access, lots of little files)
• Create one large online cache file which can then be parsed for the item details (harddrive again, read time)
• Load each file into a kind of object database so scripts can access the data directly (memory usage, no harddrive)
• Make each item into a wnpc (soo many damn weapons)

Possibly even a combination of these (like load the online cache into an object database). I could maybe only make the server load an item into memory when it's needed and have it clear the object database every hour or something?) Maybe a SQL server would be the best option in the end. I'm leaning towards loading the items into memory but I don't know how much memory each vserver has available to it plus the harddrive access time on the servers could be so minimal it doesn't even matter.

I talked to Zero about a similar system.
He told me about keeping the item information on the serverside(in .txt, .arc, whatever you want to use), and loading the data when necessary.

I figured whenever the player logged on, loading all their weapon data, and when information changed(new weapon, lost a weapon, so on and so forth), was the best way to make sure data is up-to-date. He also told me instead of clientr.vars, it would be best to load all the data into a player object.

The problem I had with that was I wasn't able to transfer the objects from the serverside(I loaded all the data into objects) to clientside. I never got to talk to Zero about that though.

I already have that kind of system for players. When they login, it loads their player data into PMUD.(player). It has everything the player needs. Clientside, they just get an array of what they have which can link to the clientside cache for information. The client-server will sync at changes only to avoid major triggers.

The good thing about players is that you can load/unload the data when they leave. Not so sure about weapons though :(. I might just end up loading them from their respective files as needed. I could keep them loaded for like 5 minutes afterwards but I don't think that would work out in the end.

As for sending the data clientside, I originally just send all the data clientside in a big trigger then build it clientside into a cache file. One off transfer. This time I think i'll just have the cache updated with any weapon changes then update it's version. I'll then use the package stuff to auto download the latest version :)

Well if you're just looking for how to save the data... I say serverside text files is the best way.

I made a system that copied template weapons when a weapon was created, and then saved it to an individual weapon with an ID to a serverside file, where it could then be customized. That made it possible to have weapons that started out as a normal weapon, but could be customized and given stats like dex+1 or such, without needing to actually have a system that managed the extra stats.

Saving is not the issue...it's loading all the item data and what's the best way to do it. As for customisation, the player has an array like so for weapons

{itemname, buffs}. The itemname grabs the stats from the standard weapon while the buffs contain the personalisations.

Like I said, do it the same way you do for player data. Instead of using clientr.vars, load them into a player object.

Hmm, I have all items in textfiles in a folder, and in a system I load all those files into objects so I don't have to load the files everytime I need data from the weapons (MudItem_blabla) (Serverside)

I also make it so you can't edit the clientr.mud.* flags, so if you reconnect they will go back to what they were before :o (I also have a detector which detects changes in the clientr.mud.* flags). I only use clientr.mud.* flags so systems like Inventory and such can read it clientside

And about caching data to the clientside, why not just parse an object into an array, send it to the clientside and then reparse it into an object on clientside? Quite easy script :o

Ok so you think loading it into memory is the way forward (though I still think you missed the actual question) and Chompy does too. Skyld & Kristi both said this was bad :(

I don't know of any other efficient way. If Skyld and Kristi have better ideas I guess just do what they say?

You need to be able to access the data clientside, and it's either objects or clientr vars. If security is an issue, just encode it?

That's what I did before for them. All that happened was having over 200mb of textfiles for the databases (npcItemDB#.txt). It takes too much time to start up the server then (Stefan said).

200mb of text files???
Geez. Although, I don't see how 200mb is so bad when servers like UN probably have more than a gig of just graphics and such.

I'd use a database, but maybe for each item type.
for a sword, make a sword database etc, could easy set out a basic item then the player can just modify the strings to their advantage. [different database types]

They didn't actually say what was better in the long run either :frown:

Also, the clientside cache would provide clientside data. No clientr. vars and security is definitely not an issue clientside since nothing can happen there anyways :D

For now I think i'll just load all the items into MUD.itemcat.itemname style DB.

For the amount of MUD data that Zodiac has, I suggest just keeping all the data in the text files and just load from each file when necessary. You could also put into your getData function (or whatever it is) to load the text file into a database npc when it has never been loaded before (![filename].loaded) and when it has been loaded just read the information for the npc. This then requires 1 extra comparison but reduced harddrive usages by a bit (database npcs still have harddrive usage but I think it is more optimized?).

As for sending the data to the player:
For all variables starting with "itemdata." for a given item "n":
And clientside:

Where params[1] is "n" and params[2] is "a".

One last thing:
Don't store any mud data in client. or clientr. vars as they would then have to be loaded one login and would stress the server quite a bit. Instead, I often create a "mud" object on login like so:
(Weapon Main)
Then you can just player.mud.loadvarsfromarray(a);

I simply join the class for utility functions.

This make it really easy for having multiple character systems and such as you can just player.mud.destroy() and re instantiate it.

I've done PMUD.playeraccount.vars. Loads it up there on login. In essence, there is no real attachment between player and the pmud :D. As for the cache, I had one going on my server pretty well so I'll just use that :D

I didn't consider the dbnpc option...I actually thought it would be much more inefficient.... I shall try it and see how it goes. Zodiac does currently have alot of MUD data but I think removing all the files which have then "of arcanaia" or "flaming" would bring down it's size by like 90%.

If you do make a database npc like I suggested though, you will need to have an archetype editor on Zodiac and not allow people to directly edit the text files as editing them directly wouldn't update the entry in the database npc.