Problem with fusing

[Vanderlust]

Spoiler

Looks like individual items have individual item IDs.

I tested this with differently potentialed versions of some common duped items (GE earrings, Rac mask, VSS, etc) and it let me put both items in the extractor. Not sure to conclude from that.

The item ID, if it exists, might be reset when potentialed/cubed? It can't be based on stats because people fuse similar things all the time and it can't be a hard item ID because I could not reproduce the SS above.

I don't know anyone with unpotentialed versions of those items so I didn't try to get the message from the SS.

[Shidoshi]

I tested this with differently potentialed versions of some common duped items (GE earrings, Rac mask, VSS, etc) and it let me put both items in the extractor. Not sure to conclude from that.

The item ID, if it exists, might be reset when potentialed/cubed? It can't be based on stats because people fuse similar things all the time and it can't be a hard item ID because I could not reproduce the SS above.

I don't know anyone with unpotentialed versions of those items so I didn't try to get the message from the SS.

I think it should be obvious that items with different potentials (or scrolled differently) would have different IDs. Even if they come from the same item at first.

[Vanderlust]

I think it should be obvious that items with different potentials (or scrolled differently) would have different IDs. Even if they come from the same item at first.

Well, think about the motive for having an ID. The only reason you would give unique ID's to items is to track them (I'm assuming they're not some secret, premeditated counter to duping because it hasn't been used to stop that at all). Having an ID that changes would completely defeat the purpose of an ID in the first place.

[Shidoshi]

Well, think about the motive for having an ID. The only reason you would give unique ID's to items is to track them (I'm assuming they're not some secret, premeditated counter to duping because it hasn't been used to stop that at all). Having an ID that changes would completely defeat the purpose of an ID in the first place.

I think you should refer to this thread. Specifically, Eos' posts.

[Stereo]

Well, think about the motive for having an ID. The only reason you would give unique ID's to items is to track them (I'm assuming they're not some secret, premeditated counter to duping because it hasn't been used to stop that at all). Having an ID that changes would completely defeat the purpose of an ID in the first place.

It doesn't have to change often, just when they move it between certain tables. And duping becomes impossible to detect after that point (plus fusion becomes possible). It wouldn't have to be intentional, just one of the many glitches they've had with MTS, etc. which makes it obvious there's not one global item table that the other stuff feeds off.

[Furahi]

I think it should be obvious that items with different potentials (or scrolled differently) would have different IDs. Even if they come from the same item at first.

Tested this actually and it wasn't the case. As long as the item was originally the same item it won't let you fuse it, regardless of scrolling or potential. Even innocence scrolling the item did not let me fuse it.

I'll post a screenshot later today. Cbf trying to level up my Alchemy again at 8:30 am before heading to school.

[Patt]

I'm not sure if it was posted already, but it's possible that the item IDs change after being processed through the MTS. This would explain why VSS, Gold Emeralds etc. would be able to be fused, but other duped items that weren't sold through the MTS can't be.

[Takebacker]

I'm not sure if it was posted already, but it's possible that the item IDs change after being processed through the MTS. This would explain why VSS, Gold Emeralds etc. would be able to be fused, but other duped items that weren't sold through the MTS can't be.

Maybe because the IDs have a marker that states what server it's in? And because mts changes the server the item is in the ID must change accordingly? I dunno, just a thought.

[Furahi]

Maybe because the IDs have a marker that states what server it's in? And because mts changes the server the item is in the ID must change accordingly? I dunno, just a thought.

That was one theory some of us had - changing server would change the item ID which could possibly explain the "glitch" where potentials and enhances were removed from items during world transfer.

[ShinkuDragon]

dunno if any survived, or anyone tried before (most probably not), but anyone tried to fuse a 608 clean with a 608 5x enhances?

[Furahi]

dunno if any survived, or anyone tried before (most probably not), but anyone tried to fuse a 608 clean with a 608 5x enhances?

Haven't tested that but if I can get my hands on a 207 and 166 Katara, I could give it a try.

[inemnitable]

Maybe the IDs are only unique per server. That would make it necessary for an item to be assigned a new ID when sold in MTS in order to prevent ID collisions.

[Thorr]

Honestly, I am not convinced that there is a unique ID at all. It could be something simpler such as a Time Stamp. Time stamps are very precise and don't need to be sequential. If an item has a unique ID, the growth of that ID number in a game like this would be astounding. Every item would add 1 to the ID number and the count would have to be maintained per server for all items simultaneously. That's a lot of work for the database engine. A simple Time Stamp on the item would make it mostly unique. Thus, a Duped item would have an identical time stamp as another duped item. It would then be likely to be a questionable procedure to delete items based on a Time Stamp since there can be any number of legitimate items that share the time stamp. It is particularly true when there may be certain events in the game that alter the time stamp. MTS trade may do that since it the item can change servers.

(I am using Time Stamp as an example here and not as a fact. None of us knows exactly what the item record contains and thus all of it is speculation.)

[Phoenix]

Honestly, I am not convinced that there is a unique ID at all. It could be something simpler such as a Time Stamp. Time stamps are very precise and don't need to be sequential. If an item has a unique ID, the growth of that ID number in a game like this would be astounding. Every item would add 1 to the ID number and the count would have to be maintained per server for all items simultaneously. That's a lot of work for the database engine. A simple Time Stamp on the item would make it mostly unique. Thus, a Duped item would have an identical time stamp as another duped item. It would then be likely to be a questionable procedure to delete items based on a Time Stamp since there can be any number of legitimate items that share the time stamp. It is particularly true when there may be certain events in the game that alter the time stamp. MTS trade may do that since it the item can change servers.

(I am using Time Stamp as an example here and not as a fact. None of us knows exactly what the item record contains and thus all of it is speculation.)

I would wonder if simply putting the item in Storage and taking it out wouldn't create a "new" version of the item either.

[SaptaZapta]

Honestly, I am not convinced that there is a unique ID at all. It could be something simpler such as a Time Stamp. Time stamps are very precise and don't need to be sequential. If an item has a unique ID, the growth of that ID number in a game like this would be astounding. Every item would add 1 to the ID number and the count would have to be maintained per server for all items simultaneously. That's a lot of work for the database engine. A simple Time Stamp on the item would make it mostly unique. Thus, a Duped item would have an identical time stamp as another duped item. It would then be likely to be a questionable procedure to delete items based on a Time Stamp since there can be any number of legitimate items that share the time stamp. It is particularly true when there may be certain events in the game that alter the time stamp. MTS trade may do that since it the item can change servers.

(I am using Time Stamp as an example here and not as a fact. None of us knows exactly what the item record contains and thus all of it is speculation.)

Generating unique ID's is a pretty basic function in Oracle, which provides a "sequence" entity that auto-increments every time it is fetched. I don't know whether MSSQL has a similar entity, but it's not that hard to implement one yourself.
Using time-stamps, or any non-unique "item ID" completely defeats the purpose of using the item ID to know what is in your inventory. The reason dupes don't break the game is that all items with the same ID are similar or even identical (e.g., all items with ID 123123123 are a VIP Bow). If you use timestamps or the like, you'll get weird situations like trying to equip a stack of potions.

[Thorr]

Generating unique ID's is a pretty basic function in Oracle, which provides a "sequence" entity that auto-increments every time it is fetched. I don't know whether MSSQL has a similar entity, but it's not that hard to implement one yourself.
Using time-stamps, or any non-unique "item ID" completely defeats the purpose of using the item ID to know what is in your inventory. The reason dupes don't break the game is that all items with the same ID are similar or even identical (e.g., all items with ID 123123123 are a VIP Bow). If you use timestamps or the like, you'll get weird situations like trying to equip a stack of potions.

My suggestion is that the Time Stamp is used in conjunction with other fields. We already know there is an Item ID that denotes what the item itself is (Just look at the Nebulite table). The actual game code probably handles how and what those items can and can't do. The player's inventory table itself is going to have the Item ID that references the game's item table. Then it would have a series of additional fields, naturally. There would be a stack field to show if it is stackable (like a max stack size or similar where unstackable items have a max stack of 1). It must have fields for stats since they can be different per item, and on and on.

What I am saying is that the game could use a Time Stamp field on equipment and other items in addition to the fields for identification purposes. It doesn't have to be truly unique, but it would be unique enough for Nexon's general purposes. Eos proposes a unique Item id like you mention. It's essentially a completely unique number for every single item. I believe this would be slow and cumbersome for the engine because thousands of items are created simultaneously on the server at once and it would have to keep a very, very large number. (I am not saying this isn't possible, I just think they may have avoided it because of database overhead. We have already seen inefficient DB coding in their system as it is.) Time Stamp (to the microsecond) + Item ID + Server ID would be quite unique.

@Phoenix - Storage wouldn't be a significant enough event to create a fundamental item change. An MTS Transfer would probably do it. A trade between characters would not do it. It would have to be an event significant enough to warrant considering the item to be newly created.

I suppose that PServer creators must have the database dictionary in order to run their servers. I wouldn't mind getting some questions answered from them.

Would like to say more but I am getting busy here at the office.

[SaptaZapta]

@Eos doesn't "propose" an item ID, he's looking at the leaked Brazil(?) MS server source code. He knows what MapleStory uses for item ID, unless it's been changed drastically since that version.

PServer creators can do whatever they please, they are not bound to Nexon's implementation.

As for database efficiency: a single integer unique-key is a lot easier on the engine than a key composed of at least 3 fields, as you propose. Even if it ends up being a long-long (64 bit) int. It doesn't take up any more space that way, either.

[Thorr]

@Eos doesn't "propose" an item ID, he's looking at the leaked Brazil(?) MS server source code. He knows what MapleStory uses for item ID, unless it's been changed drastically since that version.

PServer creators can do whatever they please, they are not bound to Nexon's implementation.

As for database efficiency: a single integer unique-key is a lot easier on the engine than a key composed of at least 3 fields, as you propose. Even if it ends up being a long-long (64 bit) int. It doesn't take up any more space that way, either.

Ah I see that now. I hadn't read that thread before the point where Eos talked about using a Transaction to solve the duping.

The maximum value for long-long is really high as an unsigned value. I would think it could be enough to hold the ID. My concern would be whether or not the system recycles ID numbers or if it just continually counts upward. The game is large enough to eventually hit the integer limit, particularly since we know that every mob drops a whole lot more upon being killed than what you see on the screen. I would think that a dropped item on the screen would have a unique ID until you picked it up. Then if it was a stackable item, that ID would be destroyed by virtue of it becoming part of your inventory stack. But until then, it would have to be a unique item.

My 3 field comparison was outside of the key structure. You could do that without ever needing to index it. Given that the table does have Item IDs, they must not have it as a unique key if they can be duplicated. Perhaps this is why Eos says 'They already have item IDs. They're not using them. ' Perhaps indexing was too costly and they avoided it for speed or they simply have other coding faults that could interfere.

[SaptaZapta]

Items dropped on the ground only exist in the channel server's memory, so I don't think they have persistent (i.e., database) item ID's. They only get an ID when they are picked up.

As for indexing: they use it as a key, but not as a unique key, apparently.

[Thorr]

Items dropped on the ground only exist in the channel server's memory, so I don't think they have persistent (i.e., database) item ID's. They only get an ID when they are picked up. .

That would explain Pick-Up lag since each item pickup would result in a DB write. Very interesting indeed.