-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Lundi 11 Août 2003 08:56, Mark Wedel a écrit : > David Delbecq wrote: > > Have seen on other game a trade system, where player are both online, use > > client interface to drag and drop items the want to exchange with the > > player near him, you see what other player want to exchange. Then the > > player both click on an agree button. > > This would need server AND client changes (instead of just making some > > map) but this would make things easier to use. > > Simply add a command trade with <player> <items ids> > > then server would tell other player > > trade <player> <items> > > perhaps several commands like that will be exchanged > > as subject of trading vary. > > then there could be a command like that > > trade ok <items> > > where player send list of item he accept to receive (to prevent other > > player from removing them just after he agreed) > > Both player's client send such trade ok command to mark their agreement. > > > > and then players objects would be exchanged. > > If players get away from each other, a trade cancel command could stop > > the process (and close trading windows on client) > > trade window is obviously an interface issue - most of that code could be > done with minimal/no client changes, it'd just be clumsier to use. But an > interface would be nice (I'm personally not crazy about popups myself, but > one could perhaps do this alternately as a tab in the drop window - a trade > tab instead). > > It's really the server that would have to verify that the trade is agreed > upon. So each time the player updates what he wants to trade, it sends it > to the server. > > Whenever that list of trade items changes, any 'trade ok' status is > cleared. Thus, for example, if I have a list of items I want to trade, and > the other player has a list I want to trade for and I hit 'ok', if the > other user changes that list at all (even for the positive), the 'ok' > status I had disappears so I need to hit OK again. > what i wanted to prevent is A agree at the same time B remove an item the removal operation gets to server server notify A after, the A agreement, which arrived 0.2 sec laters, cause of network congestion comes Server thinks A is ok with new B trade while A receive now the new inventory If B agreed just after changing inventory, trade is concluded A sees, from it's client point of view: agree -> item change -> trade concluded and may have been fooled by B I understand the procedure involved is such cheating would involved time synchro but shouldn't be so difficult to implement. That's why for security i wanted to give list of items you are ok with in trading. Another way could be to create a incremental tradeID (0->250 should be enough and easy to mainupulated in command line) and say trade ok <tradeID> while changing an item would mean something like changing the tradeID by server The cycle of server could include randomness to prevent prediction for a really willing to cheat client. Anyway i agree with the fact this should be easy to manipulate by old client using text commands. What we could do is check if client accept trading interface. If not, send messages with NDI_* else send more detailed binary info as client->server command, or use also the NDI_* but add additional info like face of objects and weight. > I do recall that there is a map someone made which was a safe trade > method. A little clumsier, but perhaps more realistic (realistically, if > I'm trading several items for several items, one can't hand over the items > while at the same instance taking the other ones for anything that takes > more than one hand to hold). > The idea is don't trade with more than one person. If you try to trade with player x while he is already trading with someoneelse, you could receive a 'player is busy' message > Also, the trade could would have to verify that the two players are > adjacant. This, if one player moves away, the trade is also automatically > cancelled. > > Yeah, a must! > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/N1GZHHGOa1Q2wXwRAqJ7AKCuBRjKG4KP+KAEVZejH8OPBu0a4ACeOz3f GtbRw1N0Quxn+KL8vhHP1jQ= =dJcF -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel