Thread: [Discussion] Multiplayer features in Essentials
View Single Post
  #28    
Old February 28th, 2013 (05:21 AM). Edited February 28th, 2013 by Luka S.J..
Luka S.J.'s Avatar
Luka S.J. Luka S.J. is offline
@LukaSJ0
 
Join Date: Dec 2008
Location: Croatia
Age: 21
Gender: Male
Nature: Adamant
Posts: 806
Quote originally posted by zingzags:
For those who do not know what I am talking about, it is possible for a hacker to find how pokemon are being sent or added from the server, so what they can do is that once they find the packet, they can manipulate it to there needs. So lets say I want to pull up a pikachu from the db one time, the hacker records the packet and when the hacker wants to do it a second time, they can change it to what ever pokemon they want. They can also change the stats and etc.
What would be the point of that? I mean the point of hacking the transferred packets. If some "hackers" already know what they are doing, and want to edit the game, they can simply do it by decompiling the RGSSAD file, and edit the project itself. There is no point in adding in extra security measures, if the game itself can be opened and edited anyway. For the online security to make sense, the RMXP project itself first needs to be locked so it cannot be decompiled with readily available tools.

EDIT: I was once toying around with the idea of creating a PokeSav for Essentials. That wouldn't be complicated to do at all. So with respect to the hacking of obtaining "illegal" Pokemon, you can easily do it by external means (editing the game itself, or editing the save file).

Quote originally posted by Maruno:
You're a brave man. Making the scripts communicate whether Tri-Attack will poison, burn or paralyse the opponent (for example) would be quite a task - there are so many randomness-based effects that would need to be standardised between the two players.

Hmm, perhaps setting the RNG seed of both players to the same value would help? Theoretically that would make the battle at both ends play out identically given the same inputs, and all you'd need to transmit is the information of which action is taken each round.

Okay, you're not so brave. :D It actually sounds manageable now.
I was thinking along the lines of: The player who handed out the battle request would be considered the "host player". The two players select their moves, and so the information about both the moves gets sent to the "host player", and the entire outcome of that round gets calculated and decided locally in the "host player's" game. The game then simply sends the results of the round to the opposing player, and the game visually represents what is going on. Having it localised at one end, rather than putting the pieces together at both ends, could eliminate possible syncing errors.
__________________
Reply With Quote