I have yet to see a convincing argument why item duping should be a problem.

Arguments that start "if the server crashes..." are obviously flawed:

1. The server should not crash
2. If it does, the server should not crash while in the middle of writing the data
3. If it does, the server restart script should realise this and be able to restore the data from the last known good checkpoint instead

If you only ever dump data which are in a consistent state, then your only worry should be about a failure half way through a dump. Such a dump should be able to be detected however, and ignored by the restart process. A simple approach, such as using a temporary file for the dump and only renaming it once it's completed, would suffice for me.

Even with a journalling filesystem files can still be partially written if the power fails during a write - but you should be able to detect a partially written file and disregard it.

Mark

If your trying to prevent duping, why don't you give each object a serial number when its created (at the start of the world)?

Then, if you trade, your trading goods and there serials.

If more then one item has the same serial, then bam, someone duped. (and you kill the dupe).

From,
Nice coder

Didn't UO have problems with duping because of where the borders of the servers were? If you traded with someone else standing on the other side, and I forget the catch, but the thing would be duplicated. UO had ID for items (even gold), so people exploiting this were caught. -- This is from word of mouth, so I don't really know.

Diablo was the game with the biggest problems with duplicate items, but that was probably just bad programming [lol]

Quote:

The server should not crash

Of course it shouldn't. And no game should be exploitable. And users should not pay you though PayPal, and then ask for their money back. Power should never go out; disks should never fail; lightning should never strike, and nobody should have to go to bed without dinner.

Welcome to real life :-)

Quote:

If you only ever dump data which are in a consistent state

Yes, that's the whole point of reliable, durable, sequenced transactions. I haven't said these things are impossible (in fact, we've implemented them across a large cluster and it works fine); I've only said that there have been bugs in several games where they weren't as well implemented as you'd hope. Especially if you scale by clustering server machines, transactions across multiple servers is notoriously tricky. Easiest is to put your authoritative state in a single SQL instance, and then hope you never run out of steam on that server -- that's enough scalability for current MMO shards, but not for a single world instance serving everybody.

Thank you all for the replies.

For some reason, I think I have been approaching this problem all wrong. You see, for me, looking at an Item sub system seemed like a huge daunting task. I didn't realize untill recently though how simple it really is...

I guess what tripped me up is this - Items in a MMORPG is kind of funny. Items are a rather large sub system to the engine, so I guess I was over thinking it. It's weird because other large sub systems, such as the map, NPC's, player's, etc. all kind of operate on themselves. That is, we make an object like a Player class and he is encapsulated into himself and should take care of all logic for Player's..

Items are different in the fact that they dont operate on themselves. Simply put items are just simple data structures which provide the data needed to other sub systems of the game (combat, player status, etc...). I guess im just used to calling object.Update() on all my stuff, but with Items you kind of just use them everywhere in all kinds of different places, almost randomly... the usage of Items isnt clean cut and structured like other parts of the game.. kind of weird if you think about it..

Anyway, guess I'm just rambling, hoping maybe someone will point out a mistake in what I just said [grin].

Items, as far as gameplay goes, probably have two ways of delivering data:

1) on transitions: equip, unequip, etc
2) on use: attack, defend, drink, etc

I think there should be code in the items that can affect arbitrary game state; that's the most flexible way to do it.

If you don't want to keep the equip/unequip state, you could just "invalidate" all stats for a character that equips or unequips some item, and then have a single function which calls back all equipped items for their stat modifiers etc, and re-calculates the character state.

Also, SOME items will need "update" calls, if they have time-outs on their affects. Or the items create an Affect instance, which in turn has a timeout that removes itself -- that's a reasonable way of doing it.

I didn't read the posts, but here is how we do it in EL:
Every player has various data associated with it: health, location, etc, etc, etc.
Now, you can make an array of ints, something like:

typedef struct
{
int item_id;
int quantity;
}
player_item items[MAX_ITEMS];//MAX_ITEMS=items a player can carry plus max items a player can have in storage.
Every value in that array is an index in an array of items (basically, it describes the item type).
In Eternal Lands, you can carry at most 36 items in your inventory, plus 8 items that you can wear. You can have a max of 100 items in the storage.
So how do we know if an item is carried, worn, or in the storage? Simple: the first 36 spaces in that array (0-35) are the items a player carries. The next 8 are the items the player is wearing, and the rest is for the storage.

Pros: Very fast, memory efficient, each player has it's items stored in itself, saved with the rest of the player data at exit.
Cons: Doesn't allow unique items.

That's pretty much exactly option 1 from above.

Quote:

Original post by hplus0603 That's pretty much exactly option 1 from above.

Yeah, pretty much, except that it includes additional information about whee to stoe them (in the player's data) and the fact that there are ranges in the array, which describe where an item is (carry, wear, or storage).

How do you distribute the data about inventory items to clients?

When I log in, and if I have 1,000 items in my inventory, how long does that take to send to me?