Technical Conversation About Items

Discussion of MUD clients, plugins, the website, and other technical stuff.
Post Reply
User avatar
nobody
Posts: 501
Joined: Wed Jun 17, 2020 7:43 am
Contact:

Technical Conversation About Items

Post by nobody »

The TLDR is in the title, I hope for this thread to be a conversation about the technical aspect of items and how items are stored/managed with the server in hopes that anyone interested can understand why some kind of item changes and limits are necessary and offer ideas toward mitigating the issue. If you would not consider yourself a technically minded person, still please feel free to weigh in with questions and comments.

The Way Things Are
This is to the best of my understanding, and may be incorrect - I hope Rias, time permitting, will point out places I'm wrong as needed.

The items on characters who are logged in, items on the ground in farms and other places that are not the market or the bank vault (maybe inn rooms also? Would need Rias to confirm) are stored in memory, while items in the market and the vault are stored on the hard drive in a database. For the non-technical audience this is the difference between stuff in your head (if someone asks you a question, you know the answer immediately or pretty close to immediately) and stuff in your notes or reference books (if someone asks you a question, you know where to find it, but it'll take more time before you know the answer). So when you ask the game "what am I holding?" by using `hands` or "what is in the crate?" by using `l in crate` the game knows that answer immediately. Whenever anyone asks the question "what all can I buy?" by using `list recent` or `browse apparel` or `market weapons` the game responds with a pause equivalent to "uh, let me go check." Items are bigger than just the collection of their strings (short description and long description) because they also store other values. I don't know what all values are stored, but some kind of ID would be pretty normal, as well as some properties like durability that are specific to the item rather than all items of that type.

How things could work in other ways
In this section, I speculate about ways to reduce the amount of space taken up by items.

- Rias mentioned having the items in the market stored in memory instead. This would make the market faster, but it would have potential consequences elsewhere. I'm not fully aware of what those consequences are, and probably shouldn't speculate too much. My best guess is that having all the market items in memory would make market interactions much faster at the cost of making everything else a little bit slower, but I've love input from Rias here. (My guessed at concerns here are not enough memory, and higher risk of issues related to running out of memory, which can be buggy in my experience.)

- Rias also mentioned "flattening" market items and items that are components of other items (like rivets that are part of a leather backpack). If my understanding of this is correct, flattening means storing a simplified version of the item rather than the item itself (and all it's properties both visible and invisible). My non-technical analogy here is that characters in comparing a bucket of emberberries and a bucket of water would be most concerned with which one weighs more (and maybe bothered that a bucket of water would spill in their backpack), while the game treats the bucket of water as a relatively simple object compared to a bucket of emberberries (each berry is a separate item and has its own expiry date and number of bites left). Flattening would ideally condense both items so that the game can treat them the same.

- I'm curious about a kind of split where the market strings, prices, and item IDs are all saved into memory, and then list/browse/market would all be faster without the heavy weight of bringing all the items into memory. It would also allow the market database to be indexed by item IDs rather than search strings, and looking up the examine info for order only ever shows the first one, so I imagine that would be a quick query to pull the info for the first item ID in the order, and because price is already in the in-memory index, the order qty price doesn't have to query all the sub items in the database. Buy and well would be the part with the slower read from and write to hard drive though, so other next idea below.

- I'm also curious about an even higher level of abstraction, in which all items are stored (in the market and elsewhere) in a more minimal form. For example, if I put all of my anomalum chalk into one bag, instead of it remembering the number of pieces of chalk in my bag, the game just remembers the number of uses in that bag, and weight and market value are then calculated based on the uses, as is the display of how many "pieces" of chalk are in the bag, but there is only one code object in the bag for it. That's similar to how bundling works at present (I think), but the idea here is to have the base unit be "uses" rather than whole objects (what a use is will vary by item* and the conversion between uses and items would be stored as part of the item template) and apply it to everything by default**, especially in the market, so instead of having a bunch of rimeveil thread items, it always has either zero or one*** rimeveil thread objects, and when people `order qty` of these the server handles translating between uses and items. I acknowledge this one may include an unrealistic amount of work, like overhauling get/put to get 50 uses of anomalum chalk as a piece of chalk when someone uses 'get anomalum chalk'.

* Uses represent the smallest useful unit of a thing. For example, if the smallest metalworked or metalcast item from an ingot produces 20 per ingot, a use is 1/20th of an ingot... except that it is unfortunately complicated by multiple recipes, because if recipes existed that used 1/20th of an ingot, 1/8th of an ingot, and 1/3rd of an ingot, a use needs to be 1/120th of an ingot to handle all of these recipes evenly. There are mathematical functions to handle this and only needs to be set once per item template.

** Some items in the past that have evaded consideration are food because they have different expiration dates that need to be tracked. It would feel less realistic for food, but food and consignment periods could be rounded up or down to all end at the same time rather than across different times of day (I'm a fan of lumping those all into the server backup). This would probably resolve spoiled food in the market issues as well.

*** I wrote this bit before I remembered all the problematic sub-issues. Namely, consignment can have a unique price and expiry date per item that would be harder to flatten in the suggested way, but it would still be more efficient than the current system even if there were 40 different consignment prices. Other difficult edge cases include: food (mentioned above), weapons / tools / armor because of durability levels (though I believe the market is intended to buy only 100% durability objects, which should help there), customized items that have unique strings or have been dyed, etc.

Questions
I have some questions that are very obviously not need-to-know:
- What properties are stored in items?
- Are item templates being used that items inherit from? (I think this would reduce redundant info per item but I am uncertain)
- Are consignment commands optimized in any way like other market commands?
- What level of overhaul is planned? Are changes to get/put/stow/transfer likely, or will the changes focus on market and item limits?
Post Reply