Charms and craftsmen.

[OberonMiM]

They can track charges on items

They could use a modified charge field to hold a players ID instead

they already have the technology

[Aranar]

"They can track charges on items

They could use a modified charge field to hold a players ID instead

they already have the technology"

It's not a technology issue It's a feasibility issue.

[Kieroth_whiteleaf]

Item changes work because if you have item #12345 it does a lookup when you load the game to see if #12345 has changed.

Item database changes would STILL be needed to the same extent that I said earlier because if you have an item #12345 made by player #11111 then SOMEHOW the system has to track where you got it from, and that tracking information would most logically be stored with the item in the database. No matter what it would have to be tracked in the database somewhere since that's basically all the game is - a collection of databases.

There are two possible ways to implement:

1. Every single individual item that goes into play (Rusty_longsword555) has information on who created it (NPC_Drop). Every item that every single player has would have to have individual records.

2. Every item createable item would require separate entries in the database, although not individual instances of said item. (Rusty_longsword dropped by an NPC)

Either way, index fields alone would take up enormous amounts of data. The reason you can get away with it in a "small" game like DaoC is because there's MANY less servers and MANY less players. If they had 30 servers with 8 slots for each of their 400,000 players, they'd be lagging like hell.

I'd also be willing to guess that because of the smaller player base they probably don't have as many items either, so that would cut down the multiples significantly.

And as I said earlier, storage space isn't really the issue at all - hard drives are cheap - it's the processor cycles required to pull the data FROM the database. Keeping in mind that with 100,000 users simultaneously on there's a lot of info being pulled. Think about how slow these message boards can be at times when there's high usage, there's only a hair over 5,000 users total on this forum and I'd bet no more than 1,000 ever on concurrently. Because PhPBB stores WAY less information than EQ (duh) it's actually a reasonable comparison - there's not THAT much data on this board storage-wise, but it munches the processor trying to access it that heavily. EQ does the same thing on a MUCH larger scale.

[Laeelin]

That is, everywhere that there is a link to the item itself, would be a link to the "creator"... A piece of Fine Plate is still a piece of fine plate, regardless of the creator,

If they do that I want them to change the right click on all tradeskill items..

adding the line:

Created by: soandso

Laeelin

[Aranar]

"Either way, index fields alone would take up enormous amounts of data. The reason you can get away with it in a "small" game like DaoC is because there's MANY less servers and MANY less players. If they had 30 servers with 8 slots for each of their 400,000 players, they'd be lagging like hell. "

I think you underestimate the size of DAoC, but that's a minor consideration.

In reality, you could store the creation information in the database with the item and thus have a database that includes all that, just having each instance of the item point back at it's "base" item, but that enlarges the database and thus "search" cycles. The catch is, you can circumvent this by keeping this data only on the player in the inventory and armor slots, thus the only time that information would need to be accessed is if an item looked for the tag, or the player inspected it. This reduces you to the 282 or whatever potential search areas instead of millions or billions we talked about earlier per search, which is a trivial volume. This also means your item database only needs to contain 1 instance of each item for the stats, again saving time and speed.

Aranar

*EDIT* PS: I just want to note I'm not trying to argue per se, so take what I say with a grain of salt in that regard, just explaining how I would go about it if I were actually writing this at work.

[Eumerin]

"The catch is, you can circumvent this by keeping this data only on the player in the inventory and armor slots, thus the only time that information would need to be accessed is if an item looked for the tag, or the player inspected it."

This gets back to what I mentioned earlier. You can assign dye to a slot because it stays in the same slot, and never gets transferred. Items don't work that way. I might have a fine plate bracer forged by Bob the Smith in that slot right now, but when I go on a raid, I decide I want to put in a blue diamond vellium jewelry piece instead. If the "created by" tag is attached to the inventory slot, then suddenly my jewelry is created by Bob the Smith.
Then there's the whole issue of trading items. If my fine plate is made by Bob the Smith, and I give it to someone else, the creator tag needs to be attached to the item, not the player.

[KyrosKrane]

There are two possible ways to implement:

1. Every single individual item that goes into play (Rusty_longsword555) has information on who created it (NPC_Drop). Every item that every single player has would have to have individual records.

2. Every item createable item would require separate entries in the database, although not individual instances of said item. (Rusty_longsword dropped by an NPC)

Actually, there's at least one other way to do this without the exponential growth -- attach the maker tag to the SLOT data, and pass that around.

Background info for the uninitiated. There are two tables (lists of data) that we're discussing here: the item master and the item instance tables. The item master table defines the properties of an item -- for example, the item master table says that a Fine Steel Breastplate weight this many stones and fits in the chest slot. All the info you currently see by right-clicking an item is stored in the item master table.

The item instance table holds information on each "instance" of an item. If you and I both own a Fine Steel Breastplate, then we have two separate instances of one item from the master. (That is, your breastplate is statistically identical to mine, but we each have our own breastplate.)

So far, the proposals have suggested adding a "maker" tag to either the master table (which would result in exponential growth of the master table size) or the instance table (which would result in linear growth for the instance table size). Both these options would create a HUGE increase in disk space, as discussed above. Larger data files means slower search times, which in turn means slower response time for end users (players like you and me).

I see an alternate proposal, however, that could get around this quandary: Attach a "maker" tag to the slot an item goes in, and copy the information for that around. So there would be no changes at all to the master or instance tables. The table that holds inventory info for each player (including equipped, inventory, bank, trade window, cursor, etc.) would get one additional field called "maker" for each slot. Each time an item is moved from one slot to another, the maker information is swapped along with the item ID.

Assuming that a player ID is 24 bits (3 bytes, allowing for up to 16 million or so characters), and counting the following slots:

30 inventory slots, including charm
16 bank slots
8 PC trade slots
4 NPC trade slots
4 (?) cursor slots -- there can be more than one item here, but I don't think you can have more than that.

That makes 62 assorted slots, for an extra size of 186 bytes per toon.

Going with 400,000 accounts with an average of 5 characters per account (for a total of two million characters), this results in an increased size of about 354 MB -- yes, MEGAbytes, not gigabytes. I'd say that's a healthy savings, no? File growth would be linear based on how many new characters are created, and the number of items that exist in the game would have no impact on file size increases for the maker tag.

A null value could indicate an unknown maker, which would be the case for pretty much all items that currently exist in the game. If player ID's are unique across all servers, then it would even be possible to find out that your breastplate was made by KyrosKrane of Veeshan, not Kyroskrane of Terris-Thule or whatever.

Thoughts?

Edit

That will teach me to not read ahead. My proposal is basically the same thing Aranor suggested, but spelled out a bit more. Yes, it's the same principle as armor dyes. However, when you swap items around, the dye value isn't moved out. In our case, you'd need to swap maker values whenever an item is moved to a new slot.

[ialaman]

Another "crafted by" idea....

The item instance table holds information on each "instance" of an item. If you and I both own a Fine Steel Breastplate, then we have two separate instances of one item from the master. (That is, your breastplate is statistically identical to mine, but we each have our own breastplate.)

Do we know that to be the case? Scrap that whole (rather phenominally huge) instance table (after all, what you're suggesting sounds like it would have information on every item on every character) and work with more links. Links are far smaller than keeping a copy of excess information when you can go without it.

Currently the items are pretty simple. There's 3 base types

Single item, Stackable item, Charged item. Just a couple bits there for the item flag, and then some more for the number in the stack or number of charges left. (use the same field for both actually, ever notice no charged item has more than 20 charges?)

Adding a "maker" slot would be more storage, though rather than store the character's name, though, simply store the character number. (would be far easier to store than a dynamic name) However, that doesn't remedy the problem with characters getting deleted... Can't win 'em all though.

[Kieroth_whiteleaf]

Hmm..

If the slot info could work like that (sorry to Aranon, I didn't quite see where you were coming from before Kyros' post) that would make some sense... Seems kinda an ass-backwards way to do the data storage, but I'd agree that it would be MUCH less system intensive and I can't think of any reason it wouldn't work. It'd definitely add to processing time, but not in the huge chunks that I was talking about earlier.. Depending on how efficient the database servers are it'd be negligible.

Nice thought guys..

SFG

[KyrosKrane]

Re: Another "crafted by" idea....

Do we know that to be the case? Scrap that whole (rather phenominally huge) instance table (after all, what you're suggesting sounds like it would have information on every item on every character) and work with more links. Links are far smaller than keeping a copy of excess information when you can go without it.

Initially, I had the same thought as you. Why do we need an item instance table at all when we already have the inventory table holding info on all players? Then I hit the same snag you did: different item types. You have the ones you mentioned (single, stackable, and charged) plus at least one other type: container. Each of these types has special properties that need to be stored, like number of charges or number of slots. Since things like charges vary per instance of an item, you need to track that carefully -- e.g., all 10-dose Blood of the Wolf potions have the same master ID, but if you and I each own one, yours could have 10 charges and mine could have only one left.

This actually leads to a slight problem with stackable items. Let's say I make a particular arrow, and my name is attached to it. I sell a stack of these arrow to Player_01. He goes shoots off five of the arrows, then buys five more from a different maker. These promptly get stacked with the ones he bought from me. Whose name is now on the maker tag for this stack?

A variant of this problem can be seen in the game today with charged items. Let's say I have a 10-dose Blood of the Wolf (BotW) potion with one charge left. I sell it to a vendor. Then you come along and accidentally sell your fully-charged 10-dose BotW potion to the same vendor. If you buy your potion back, you get one with only one charge -- the "charge" information for the item the vendor has was set when I sold my almost-empty potion, and when you sold yours, the charge information was overwritten by my pre-exisiting item on the vendor.

This can only happen with stackable items that can be made by multiple people. Off the top of my head, this would apply to almost all baked and brewed items, and all fletched arrows.

My guess is that in this case, the name of the most recent "maker" should override the old value.

Single item, Stackable item, Charged item. Just a couple bits there for the item flag, and then some more for the number in the stack or number of charges left. (use the same field for both actually, ever notice no charged item has more than 20 charges?)

From a design perspective, this is highly ill-advised. It's very confusing when one data field is used for fundamentally different types of data, depending on the type of the record. It's efficient, sure, but it can lead to mistakes down the road, or mistakes with older code that misinterprets a value in that field.

Adding a "maker" slot would be more storage, though rather than store the character's name, though, simply store the character number. (would be far easier to store than a dynamic name) However, that doesn't remedy the problem with characters getting deleted... Can't win 'em all though.

This is understood -- you'd never store a player name and an item name. You'd store a link back to the master item record (or the instance record, as the case may be) and a link to the player record. Typically this is through player and item ID numbers, but it can vary depending on the database.

As to characters getting deleted, the point is moot. I've heard stories of people who closed their accounts, then came back months or years later and were able to get their accounts restored. This suggests that player data is never really deleted (though it could be moved to backups or offline storage of some sort).

At any rate, for the item maker slots, you can do a simple update that changes all items with a "maker" tag set to a deleted character to "unknown" -- the same value that would apply to most dropped items, and pretty much every tradeskilled item that exists in the game now.

[Kradlum]

Re: Another "crafted by" idea....

Let's say I have a 10-dose Blood of the Wolf (BotW) potion with one charge left. I sell it to a vendor. Then you come along and accidentally sell your fully-charged 10-dose BotW potion to the same vendor. If you buy your potion back, you get one with only one charge -- the "charge" information for the item the vendor has was set when I sold my almost-empty potion, and when you sold yours, the charge information was overwritten by my pre-exisiting item on the vendor.

I don't know if this is relevant to the current discussion, but my understanding of chargeable items was that if you sold a 10 dose potion with 1 charge left to a vendor and then bought it back, then the potion would have all 10 charges. I have never tried it, just what I have been told. This means that NPC's have a different instance table to players, since it does not seem to track the number of charges.

I think anything that is player made, sold to a vendor, then vendor bought should lose its maker's tag anyway. The player buying from the vendor has no idea who the maker is anyway. This would simplify things a bit.

[Aandaie]

Eumerin hits it on the head.

Its back RP storyline junk, as in a armor craftsman would be Rowyl of "Rowyls blah" druid armor, etc.

I think even that was backstory, though, there have been no charms having to do with any armor sets yet (especially not anything outside of LOY) I wish they would add more of the dang things and have them dropping in other existing additions.

[KyrosKrane]

Re: Another "crafted by" idea....

my understanding of chargeable items was that if you sold a 10 dose potion with 1 charge left to a vendor and then bought it back, then the potion would have all 10 charges.

Almost but not quite. The trick is to sell a full potion with ten charges to a vendor, then sell the depleted items you want to "recharge." When you buy them back, they will have all ten charges -- because the first item sold (the one that defines the inventory item on the vendor) had all ten charges.

I think anything that is player made, sold to a vendor, then vendor bought should lose its maker's tag anyway. The player buying from the vendor has no idea who the maker is anyway. This would simplify things a bit.

It would indeed simplify things greatly, as you no longer need to modify the code for vendor slots. However, removing maker tags from items sold to vendors rather defeats the purpose of that tag. If I find an item made by Person_1 on a vendor, I may want to contact that maker and see if he'll make me more -- that's the major selling point (pun intended) of maker tags, beyond sheer pride in one's work.

< think think think .... somewhat later >

Upon reflection, it may actually not simplify things all that much. If they use object oriented techniques, then every slot in the game (whether in inventory, bank, merchant, loot, or wherever) is based on a master slot class (a set of code that defines what a slot is and what it can do). If this is the case, then the dyes are in fact not associated with slots as we are thinking of them -- the dye values you choose are not stored with an inventory slot. Rather, they're stored elsewhere, and the slot itself remains unchanged. ... Come to think of it, this is rather academic, as we're discussing how the game should be changed anyway, not whether it has already been changed!

[Kradlum]

However, removing maker tags from items sold to vendors rather defeats the purpose of that tag

Well, yes and no. In real life I have a friend who works with leather. If I buy a belt directly from him, then I know he made it. However, he and other craftsmen sell stock to the local craft store, they make belts to the same pattern so the store can stock a particular line. If I buy it from the store, I don't know which of the craftsmen made it.

In the game, this is the difference between buying direct from the maker, or buying something the maker has sold to the vendor.

I've been skilling up on shadowscream bracers, and selling them direct to the vendor. If I sell 20 to a vendor, only one appears in the vendor's merchandise slot. If the vendor had to display 1 shadowscream bracer for each person that had made one in their inventory, it would make merchant mining a lot more painful.

[Lonzrick]

Wow...nice to see my little idea has sparked such discussion.

For me, though, the point of a "Crafted by:" tag on an item wasn't a pride-issue (although there's nothing wrong with that), nor a "who made that so I can get one" issue (although there's even LESS wrong with that!)

Instead the idea was that by doing this, Sony could then implement the "Drop Once" type of items. Once crafted, as long as the item is in the inventory of the person who made it, it can be transferred to someone else. Once transferred, the "owner" and "Crafted by:" no longer match, then it's a regular No-Drop item.

I suggest this because I was particularly peeved by the developments as PoP was released and evolved. Planar Armors! Planar Smithing! Oh boy! So I started to really focus on smithing. Except I soon found out that any Joe who collects the items for the armor can pop it into a forge (or give it to NPC) and get that armor with No Smithing Experience Necessary! (No Fail Combine) Grrr.

Then they instituted the Ethereal Ring mess, in which you cannot even *attempt* a combine until a certain skill level. They could combine all those ideas thusly:

The item to be made is no-fail at 250, but also requires a minimum of 250 to make it. The adventurer gathers the components and then locates a 250 Blacksmith, negotiates a price, and hands the goods over. The smith crafts the item which is now tagged "Created by:" and is (at the moment) Drop-Once. He hands it to the customer. The item becomes No-Drop (if it should be so).

The Adventurer has his uber-item. The Smith made a commission and had a REASON for putting up with the hell of getting to 250. And the item has "Crafted by:" on it so that other players know who to contact when they want their item made. Crafting serves a purpose other than mindless timesink.

Tada!