Is this viable to load on login?
 

I have an item by itself being load which has the unique ID of the item and I also have a bunch of clientr.item.itemname.data.etc vars that are holding the data. Would this be viable to load on each login? Keep in mind this is just one item. Any help, suggestions would be appreciated. I want to keep it like this if at all possible. It would make everything easier for me to expand later on without having just one really long string with no apparent order. I will do it the other way if needed.

I don't see why not, but you could always do some testing.

Generate a bunch of dummy items/data and then test out loading them on login.

Well from what I have heard if the account file gets too big it will not read properly.

Use an SQL Database to create items and store specific data for them. The SQL Explorer tool is probably the best option for doing so.

I don't know about stuff not loading if you have too many variables, but it's generally a bad idea to store that kind of information on player accounts.

The item information is stored in a SQL database and cached into a DBNPC. The unique item information in the array is pulled directly from the SQL database. All this is done on login and if a specific items information is updated it will update it on all the online players.

Problem?

Unless you want players to be able to customize items or weapons, this is a perfectly good way of storing this information. It can significantly reduce the amount of data being loaded by the server at any given time.

If you consider the fact that players could have hundreds of things stored on their account at any given time, and that those things might have up to ten or more variables associated with them, the numbers add up fast. And loading all of those things every time a player logs in doesn't make things any better.

it's not getting stored, I'm just trying to figure out if it's fine to store that many. imagine that times like 600 for those items hording people

Exactly. Now imagine all that being loaded every time someone logs in. :megaeek:


Just create items in a database and then generate an Item ID via script that makes the item 'unique.'

That way you can change the basic variables of the item globally, while still giving players the benefit of possibly customizing their stuff.

I'm already doing that by having a table for the base stats of everything then another table solely for stats that would be unique to one weapon, the initial question wasn't where i planned on storing my player/item data it was just if having that many flags in a players account file will cause any issues.

If I was going to make a simple item system, this is how I would structure it:

1. I would have one database table to store item information (call it ITEMS_INFO) with columns such as:

   UID, NAME, TYPE, DESCRIPTION, GANI, REAL_NAME, ...

   This table would have one row for every item on your server.
   
   
2. I would have another table to store player possessions (call it PLAYER_ITEMS) with the columns:
   

   ACCOUNT, ITEMSINFO_UID, QUANTITY

   
   
3. I would also maintain a cache of each player's item info in clientr.vars. I would update the entire cache on login, and also individual items as they are bought/sold/dropped/whatever.

A simple way to load all of a player's items in a single query (such as when they login) would look something like:

NPC Code:

---

select PLAYER_ITEMS.QUANTITY, ITEMS_INFO.* from PLAYER_ITEMS

  left join ITEMS_INFO on PLAYER_ITEMS.ITEMSINFO_UID = ITEMS_INFO.UID

  where PLAYER_ITEMS.ACCOUNT = 'salesman'

---

You could then loop through the result of this query to update the player's clientr.var cache. If a player has 600 items, you'd only have a single SQLite query and a loop that iterates 600 times when they log on.

There's also really no need to cache the SQLite databases in DBNPCs. From my personal experience, it is much faster to just stick with SQLite.

You shouldn't have an issue with too many clientr.vars (Era does something similar). Just remember to only store information that you will actually use...such as the information that will be displayed in an inventory or on the player's HUD.

The issue is that those flags will have to be loaded every time a player logs in. If you have a lot of players and a lot of flags on those players, it can greatly increase a server's average workload.

Whether or not it can cause issues for a player's account, I'm not entirely sure. I suspect the answer to that would be yes, but I can't say for certain because I've never tried to see if I can crash a player's account by overloading it with variables. :p

Unless the server is getting 100 logins/ms or something ridiculous, retrieving some data from a database and setting some clientr.variables won't be that big of a deal.

I'd imagine it'd be better to store it in a DB NPC as it would keep it in the memory.

Retrieving data from a database is what I'm advocating here. Storing all of that information in clientr.variables is not.

You could always test it out. Create a table with several thousand rows. Create a DBNPC with the same data. Measure how long it takes to retrieve information from both of them.

If the information is going to be accessed frequently on the clientside, you don't really have any other options. Although, I'd recommend caching anything that doesn't need to be secure in client.vars as opposed to clientr.vars. For example, the item's icon file name or a description about the item for displaying in the inventory.

Why client vars? The client doesn't need to change them and I don't think you're gaining anything by doing that.

I currently do a hybrid of the above on Zodiac. I cache all item data in the SQL DB as it's needed and use a time-stamp and only update the information when it needs to be.

I get pretty much the same performance as loading it directly from a Cache DB every-time with significantly less memory usage.

If I wanted to put a new system in I would go with salesman's initial suggestion though. clientr variables would merely act as a 'cached' reflection of your database. Just make sure your DB is indexed properly.

Really though just put something basic together the item system is probably the easiest system to put together.

I like putting the data in an array and write accessors to make sense of the data in your script. I.e.

clientr.itemdata.id = {name, type, value};

Sure you do.

Information like what you just listed ("the item's icon file name or a description about the item for displaying in the inventory") can be stored more conveniently in database tables as well, and you can read from those tables just as easily as you can read them from player accounts.

Variables which are subject to change and specifically relevant to player accounts should be kept on players, and everything else should be stored in a database.

Why send 100's of unneeded server request when you can just make 1 and store it?

Also is the general consensus that I should kick the ItemCache in the DBNPC to the curb and solely rely on querying the SQL database?

If all items are going to have the same variables like above, just store them in one flag as an array? Then, rather than loading 14 flags per item, you load 1 per item with all 14 flags in the array.

readability

Readability is not an issue here; instead you should abstract away the variable names in favor of scripter-friendly functions like player.getItemProperty(itemid, property). This has the added benefit of allowing you to easily change how you store this data in the future.

Did you even read my proposed general solution? The information would be stored in database tables. But whenever serverside information is going to be needed constantly by the client, it is not viable to repeatedly request that information from the server. Instead, you should cache the information in clientr.variables which are in sync with the server.

Yeah, I don't know what I was saying. I was thinking that there was a difference in how they are synchronized (client requiring less overhead), but I was getting mixed up with something else. There could be, but not in the way that I was thinking.

plz 4give

This.

I am still very opposed to storing actual item data on clients, one way or the other. Fills up attributes with useless garbage that only have to be sent to clients once per session and stored in a weapon NPC.

I don't know if reading this script will help you at all, since it's not commented, but this is exactly how temporary data like descriptions etc. is handled on Maloria.

Yup. Did you even read mine? ;)

Yeah, but when you cache that information, you don't need to have clientr.variables for every little piece of information on every weapon or item. Only pieces of information which can be manipulated by the player's actions. A simple query is enough to fetch all the information associated with a record you've created in a database table, and that's way easier than trying to fetch those pieces of information one-by-one.

The only advantage I see of caching them in a weapon NPC as opposed to storing them in clientr. variables is it takes up less VISIBLE space. Yet if you want to be able to quickly refer to these item flags without checking the Database, you will have them visibly in the flags. GK have over 500 flags as previously stated, and they're running just fine.

Therefore I see no true "better" way, and it's down to a matter of personal preference.

Heck, if you're storing them in clientr. you don't even need to triggerClient; you can just write them then and there to be available Clientside.

I've spent a lot of time developing on "big" servers, namely Maloria and Zodiac. Along with Kingdoms Debug, they all had one thing in common: player flags was filled with garbage, which made looking through them more annoying than it should be. This was especially annoying on Zodiac.

clientr. flags trigger to the client automatically, you know. I recall Stefan posting something about updating clientr. flags frequently wasn't very optimal. I can't remember the exact details.

Correct. And requesting them from an SQLite DB does not. (Although as you'll notice in my post, this wasn't even a main point. It was simply a whimsical).

Equally, if you are updating clientr. vars a lot it won't be optimal, but you're not in this case, are you. You're caching the data to be Read at a later date, and as such there does not seem to be any benefit for either of the two methods.

So like I said: personal preference.

:confused:

Not really sure what you're trying to say with this.

I'm saying that you can fetch information more efficiently by just running a query for a single record, pulling all the associated information from that record's row.

So if you want to load information for a 'Wooden Sword,' you just run a query for a record with that name entered under the 'itemname' column, and then load other information from that record's row, like the 'itemthumbnail' and 'itemtype' and so forth.

The advantage of this is that instead of having to store all of this data on a player's account, the only information you'd really need to read from the account is what the player currently has equipped. It's the only thing that the client needs to read from a player because it's under a player's direct control.

You do realise you're both debating the same thing?

Salesman never suggested querying more than a single record for a single entity; Unless of course you have a viable reason such as an inventory and you do not wish to wait for an item description to load every time you hover over an item for a description. In which case, store it in clientr. flags or cache it in a weapon, but there's no benefit of one over the other.