rtrapasso -> RE: Jap Player running turn multiple times (6/24/2008 3:13:50 PM)
|
quote:
ORIGINAL: Jim D Burns quote:
ORIGINAL: rtrapasso No - because then the ALLIED player could manipulate things... and the sync problem would be worse because if it automatically executed the turn on finalization, there would be no possibility for a reboot before running the results. If there were some sort of tournament/serious problem or suspicion of cheating, the obvious solution would be for a third party to run the turn. This has happened on occasion. Umm, how exactly can the allied player manipulate anything if he’s not allowed to see the results until he gets the turn back from Japan? I mean what’s the point, he can’t know the results until he gets his next turn, so why would he re-run turns? I’ve never read or heard of anyone suspecting someone of cheating on the forums, but the topic of this thread is about the ability of Japan to re-run turns and *see* the results. If this is occurring, it’s a simple matter for Japan to re-download a turn and run it over and over until he gets a result he likes. The solution I mentioned could work for either side, simply delay the reports and replay for the side that executes the turn, so they can’t see the results before their opponent does. That would end any re-running of turns if it is in fact occurring. But it makes sense to have it occur after the allied side, so Japan can watch the last turns results before plotting his move. Why this would be a problem for anyone, leaves me a bit baffled. Jim The way you suggested: i.e. - the game to automatically generate the results as soon as the Allied player finalizes the turn - would necessarily result in the Allied player seeing the results soon as the game ran them after he clicked "finalalize". If the results were not to his liking, he could take a pre-finalized save, redo some stuff, and rerun the turn... if the "result" file was shipped off to Japan first, the method would be identical to what we have now (i.e. - once an Allied player finalizes a turn, he can no longer manipulate it... but the Japanese player can be manipulating how the EXE file generates the final result.)* The Japanese player can NOT just redownload the turn, and run it again to get different results - it requires manipulation to get different results... sometimes the manipulation will not be a deliberate thing (i.e. - forgetting to reboot), but it is possible that it is in some instances. That's when sometimes a third party is called in to resolve a problem... The best technical method to fix this is to (1) fix Windows memory problems (good luck); or (2) somehow (when a turn is run) to get WITP to clean out every bit of memory that could effect things in the replay as well as to "bulletproof" other things that can cause SYNC error (i.e. - to somehow stop instances where ESC can affect the results.) Efforts are ongoing, but slow... EDIT: What i think you are suggesting is that a "result" be generated that the Allied player can not see... this is EXACTLY what the game does now, however, at some point an animation is generated (the "Replay") - it is at this point that system is open to manipulation. It might be possible to input that actual results to the finalized Allied turn, but since no reboot is possible before this is done without adding several more steps to the process, it would cause more problems. A possible solution would be: a) Allied player finalizes turn. b) This generates an "interim" file. (this is what the Allied player currently ships to Japan for processing). Let's call it WITPX000.pws NEW: c) Allied player reboots.* (EDIT: *Note - if this step is left out, you again have potential for SYNC bug - i.e. - animations would not match the results.) NEW: d) Allied player reloads the interim file which generates the starting setup for the Japanese player, but is unable to see the results. Let's call this file WITP000. e. Allied player ships turn (WITP000) to Japan. f. Japanese player uses this to generate an Animation file, (shipped back to Allied player) - file WITP001.PWS g. Japan uses the WITP000 file to make his moves... Of course, this would require a rewrite of the code... and i don't think this is going to happen. REEDIT: The problem arises because of the SYNC bug, which (a) shouldn't happen, b) wasn't anticipated, and has the potential to be abused. Adding 2 more steps to the solution would probably also generate new unanticipated problems, and could make things worse.
|
|
|
|