RE: Cheating

RE: Cheating (Full Version)

All Forums >> [New Releases from Matrix Games] >> Empires in Arms the Napoleonic Wars of 1805 - 1815 >> Tech Support

Message

larrywrose -> RE: Cheating (3/11/2008 2:06:13 AM)
No system is perfect. But on the pre-generated die rolls, we are talking about 1 combat at a time, each time you create a battle file. Could you find out what the die rolls are yes. But this is of limited use. How often do you actually commit the Guard? Not nearly as often as you have basic battles. Would I perfer an automated Battle Server, yes I would love it. I just don't see it happening. Larry W. Rose

Ashtar -> RE: Cheating (3/11/2008 2:28:40 AM)
quote: ORIGINAL: bresh A preset list of dice rolls can be misused to. So you know the next roll is 6. ok, skip reinforce/guards, and keep that for the combat... And would also need new code to do battles. Regards Bresh I do not want to be harsh, but I wonder again if people bother to read post before posting themselves. If you read, you will notice there is no way of doing what you fear and no need to write a radically new code for battles: quote: 1a. Combat phase - Non trivial combat. Simple way of doing it: a) The attacker choses his chits and sends to the defender. b) The defender choses his cheats and the program generates the needed die rolls. None of them are shown (so no reload is possible), and the file is sent back to the attacker. c) Results of the first turn are shown to the attacker, he decides about guard commitment and sends back to the defender. d) The defender receives, check for first turn results and decides about guard commitment. Needed die rolls are secretly generated and stuff his sent back to attacker... Go on until the end of the combat. No way of cheating here, large battles are often the crucial and more important ones in a game and are now secured. Moreover, no more file exchanges then now are required.

Grognot -> RE: Cheating (3/11/2008 2:50:03 AM)
quote: ORIGINAL: bresh Its more reliable to me. And possibly easier to implement. A preset list of dice rolls can be misused to. So you know the next roll is 6. ok, skip reinforce/guards, and keep that for the combat... And would also need new code to do battles. Only in quick-PBEM combat, where you don't have to send files before you find out what the results are. It's the ability to take an action, observe the results, and go back in time to change your mind that's problematic. It's quite possible to have a system in which you can't skip actions in order to allocate rolls (ex. -- create a random seed when the game is created; create event strings based on the action type in a method independent of other actions; hash the event string and XOR that with the random seed), but quick combat would even let you skip the entire battle by redoing your land phase. You'd have to make it somewhat less quick, e.g. phasing player sends tamper-resistant data to server (* which presumes that phasing player has full data on opposition -- otherwise requires another exchange), battle server sends results to ALL players (encoded in file, not manually entered), game provides way to verify consistency of results with land combat PBM file.

Cunctator -> RE: Cheating (3/11/2008 8:14:54 AM)
Trust in God, but lock your car.... I think that Ashtar mode is the best method because it's the simplest to implement, while it reaches a satisfactory level of security. If a player is not able to foresee the die rolls that are hidden and pregenerated and if the defender choose his chit and then send it to the attacker, without knowing the choice of his counterpart I think that we scored a decisive point. I'm completely ignorant about software programming, but I believe that it would be very easy to add proper instructions to make it happen. Just my two cents...

bresh -> RE: Cheating (3/11/2008 12:12:46 PM)
quote: ORIGINAL: Ashtar quote: ORIGINAL: bresh A preset list of dice rolls can be misused to. So you know the next roll is 6. ok, skip reinforce/guards, and keep that for the combat... And would also need new code to do battles. Regards Bresh I do not want to be harsh, but I wonder again if people bother to read post before posting themselves. If you read, you will notice there is no way of doing what you fear and no need to write a radically new code for battles: quote: 1a. Combat phase - Non trivial combat. Simple way of doing it: a) The attacker choses his chits and sends to the defender. b) The defender choses his cheats and the program generates the needed die rolls. None of them are shown (so no reload is possible), and the file is sent back to the attacker. c) Results of the first turn are shown to the attacker, he decides about guard commitment and sends back to the defender. d) The defender receives, check for first turn results and decides about guard commitment. Needed die rolls are secretly generated and stuff his sent back to attacker... Go on until the end of the combat. No way of cheating here, large battles are often the crucial and more important ones in a game and are now secured. Moreover, no more file exchanges then now are required. Im not sure you read my post :). But sure i had read yours. And your idea is not bad. But i would prefer rolls on the host. Since yours does improve security, yet i guess could be hacked. And does need some coding, for special rolls if dicerolls would be split. To the defender/attacker. My example was just a bad one. Pre rolls could be misused by one side. While when defender/attacker let the dice be rolled at the host, this would not be an issue. Sure you need to trust your host. You would need an active host though, but then again, files send from to/from host would be simultanious from the attacker&Defender. I havent tried any combats yet in PBM, so i dont know if it shows up if your enemy tries to reinforce a phase, or commits guards, when you recieve the files, before you take casulties. Regards Bresh

Jimmer -> RE: Cheating (3/11/2008 7:57:01 PM)
By the way, if this IS a true security breach, it would be fairly easy to correct: Create a registry key that has a non-descriptive name or whose value is encrypted. This registry key contains a "heartbeat". Every so often (probably 5 or 10 seconds), the key is updated to state time checkpoints have been passed in the game. In addition, there is a matching value in the saved files for the game that is also updated at each heartbeat. NOTE: Heartbeats must occur at specific times on the clock, not "after X seconds". Otherwise, synch problems could occur. So, player opens the game files. < heartbeat > Player picks his chit. < heartbeat > Player notices his chit choice was a bad one. < heartbeat > Player shuts down the game (abnormally or not -- makes no difference) and attempts to open the game files again. Game files list three fewer heartbeats than the local registry does. Game informs the host at next contact and/or sends an immediate email to host. Host must restart game due to player attempting to cheat. Use of guillotine reinstated. You get the idea. There would be ways around this, but it would require placing a second instance of the game onto some system, and that's usually not a viable solution for most cheaters.

bresh -> RE: Cheating (3/11/2008 8:09:24 PM)
quote: ORIGINAL: Jimmer By the way, if this IS a true security breach, it would be fairly easy to correct: Create a registry key that has a non-descriptive name or whose value is encrypted. This registry key contains a "heartbeat". Every so often (probably 5 or 10 seconds), the key is updated to state how much time has passed in the game. In addition, there is a matching value in the saved files for the game that is also updated at each heartbeat. So, player opens the game files. < heartbeat > Player picks his chit. < heartbeat > Player notices his chit choice was a bad one. < heartbeat > Player shuts down the game (abnormally or not -- makes no difference) and attempts to open the game files again. Game files list three fewer heartbeats than the local registry does. Game informs the host at next contact and/or sends an immediate email to host. Host must restart game due to player attempting to cheat. Use of guillotine reinstated. You get the idea. There would be ways around this, but it would require placing a second instance of the game onto some system, and that's usually not a viable solution for most cheaters. Dont think this would work very well. Maybe you just load the battlefile, then need to talk/ask to your allies about chitchoices/guards/reinforcing etc. Its not like you know if they find it good to try reinforce you, it could be a screening corps, or there are other plans. Guard commitments are not just used to win a battles, its a good equipment to reduce the effects of pursuit. But it could be your allied guards you commit, maybe they dont want you to, maybe +1 is better than +2, sometimes. Also there is noway you can make the game generate an email which is autosend, atleast not in my network, and its not that different from normal networks. A in game message to the host might work, but again, you completely remove the effect of allied correspondace. Again I would mean battles wich involves fileexchange, dicerolls performed on host, is the best security that could be made avaible. Put you need a very active host. Regards Bresh

dauphan129 -> RE: Cheating (3/11/2008 8:53:57 PM)
Another country heard from[;)] ecn1 and I checked this cheat out before he posted it. We had a player in our game that consitantly picked the best defense and never rolled less than a five. It got us wondering [X(] For a work around until Matrix figures this out (and Marshall I have every confidence you will keep up the good work [:)] [&o]) here is what I am implementing in my game: 1) The attacker will email the defender and tell him where he is attacking. 2) The defender will make a text file and type his chit pick in. 3) The defender with password encrypt/zip the text file and email it to the attacker. 4) The attacker will start the battle and send it to the defender. 5) The defender will pick his chit and send the battle back to the attacker and include the password for the zipped file in this email. 6) Battle continues. This will allow the attacker to verify that the defender picked what they said they would. It won't help with die roll optimization but it's better than nothing...[8\|]

dodod -> RE: Cheating (3/11/2008 11:06:24 PM)
won't work, to easy to break password files...proved by another player in a game who actually asked us to send him one which he broke in about 5 seconds. what is wrong with letting the attacker open the file with the picked chit, after they have been picked, and letting the next phasing player see the prior player computer roll for both? Isn't this full proof?

bresh -> RE: Cheating (3/11/2008 11:46:17 PM)
quote: ORIGINAL: dodod won't work, to easy to break password files...proved by another player in a game who actually asked us to send him one which he broke in about 5 seconds. what is wrong with letting the attacker open the file with the picked chit, after they have been picked, and letting the next phasing player see the prior player computer roll for both? Isn't this full proof? Prior/Next phasing player could be involved in several ways himself, as in lend corps/reinforcement. Or just an ally to eighter attacker/defender or both. Would work same way as if Host rolled i guess. Offcourse if he doesnt know the rolls it might be harder. Then again im sure there would be ways to move around that to. Generate rolls send to your "ally" friend. But it be very rare you find 2 players in same game who would go to that extend i guess. Since only 1 can win. Regards Bresh

dodod -> RE: Cheating (3/11/2008 11:52:37 PM)
But if the rolls are revealed only when the rolls cannot be changed (after already in the file), then there is no extra files, and no way to cheat. I think this is the best way is larryworse's technique in the first post of this topic, where the attacker is the first to see both picked chits, and the rolls are viewed after the file is created by the opponent. Attacker picks chit, sends defender picks chit, computer rolls without showing roll, sends attacker sees chits and rolls from defender file, and takes casualties, and rolls again without seeing results sends to defender. defender removes casualties and sees roll for next round.... and so on. the rolls can be pregenerated for battle and pregenerated for POSSIBLE withdrawal, commiting of guards, and reinformcement.

Page: << < prev 1 [2]

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

0.78125