PBEM naval issue

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

PBEM naval issue

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

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

Page: [1]

Message

<< Older Topic Newer Topic >>

PBEM naval issue - 1/14/2008 1:07:54 AM

zaquex

Posts: 368
Joined: 11/30/2007
From: Vastervik, Sweden
Status: offline

There seems to be an issue with fleets intercepts in PBEM games. I discovered this playing a PBEM game as both France and England. It is possible for the phasing player to reload and rerun its Naval phase to avoid interception. Not sure if its possible to also rerun fleet battles this way but I assume it could be. This is a major issue for PBEM game imo.

< Message edited by zaquex -- 1/14/2008 1:31:40 AM >

Post #: 1

RE: PBEM naval issue - 1/14/2008 2:39:47 AM

Monadman

Posts: 2085
Joined: 12/6/2005
From: New Hampshire
Status: offline

quote:

ORIGINAL: zaquex

There seems to be an issue with fleets intercepts in PBEM games. I discovered this playing a PBEM game as both France and England. It is possible for the phasing player to reload and rerun its Naval phase to avoid interception. Not sure if its possible to also rerun fleet battles this way but I assume it could be. This is a major issue for PBEM game imo.

Just answered this in another thread . . .

We have not implemented anything to prevent the copy-paste function from being used by those who feel compelled to replay a turn before sending it to the other members of the group.

Looking at ways to curtail this for a future patch.

Richard

_____________________________

(in reply to zaquex)

Post #: 2

RE: PBEM naval issue - 1/14/2008 3:06:17 AM

zaquex

Posts: 368
Joined: 11/30/2007
From: Vastervik, Sweden
Status: offline

Thank you

(in reply to Monadman)

Post #: 3

RE: PBEM naval issue - 1/14/2008 6:13:40 AM

dodod

Posts: 147
Joined: 12/26/2007
Status: offline

strikes me as a very big deal for navies...particularly GB...wow...this almost makes PBEM worthless.

(in reply to zaquex)

Post #: 4

RE: PBEM naval issue - 1/14/2008 7:24:15 AM

Murat

Posts: 803
Joined: 9/17/2003
From: South Carolina
Status: offline

I dunno where this came from but somewhere I thought there was a discussion about some safety code in games that would prevent this somehow?

Not a programmer but someone who was mentioned it to Marshall and he seemed to know what they were talking about.

(in reply to dodod)

Post #: 5

RE: PBEM naval issue - 1/14/2008 9:14:08 AM

zaquex

Posts: 368
Joined: 11/30/2007
From: Vastervik, Sweden
Status: offline

There is some code allegedly to stop you from loading your own battlefiles etc (havent tried), the problem here is that the interception and combat takes place in your naval turn.

(in reply to Murat)

Post #: 6

RE: PBEM naval issue - 1/14/2008 2:37:50 PM

dodod

Posts: 147
Joined: 12/26/2007
Status: offline

Imagine playing a PBEM game for 1.5 years, then someone cheats to get into London....forces an unconditional on you...

lots of time invested...all for naught...

There should at least be a way for the program to see how many times the file was loaded...such as creating a random number that would rewrite 1 of two from the prior player's file, for example; this would remain in the previous file...and at least 1 of these numbers would match when starting the file afterwards. Both numbers would be loaded on the NEXT player's file, and if at least one of these didn't match, it would mean the player re-loaded his file at least twice. Giving that information....

I think this should have been reason enough to make this TCP/IP. A game that cannot even guarantee not cheating by simply re-loading a file...that seems rather odd.

(in reply to zaquex)

Post #: 7

RE: PBEM naval issue - 1/14/2008 4:28:26 PM

Ashtar

Posts: 160
Joined: 12/6/2007
Status: offline

There is a simple way of improving anti-cheat security, that is, generating in advance all the die rolls
instead of generating them on the spot.

Suppose that the code generates 1000 d6 (that is, 1000 random numbers between 1 and 6) at setup time. They are kept secret and inscribed in the save file. Then every time you need a random number (foraging,
intercepts, battles, etc.) you pick the next in line. When the 1000 series is exausted, the game engine generates a new one and spreads to the save files via the next turn file.

This should avoid people reloading the same turn twice to get a better roll, since they would get the same one.
It is not 100% bulletproof, since if you have more then one die roll in a phase (like different foraging rolls) you can rearrange the order you are getting them to improve the more important ones. However, it is a simple measure to implement and in the worst case scenario, it makes harder to cheat and reduces benefits from it. Something which normally increases the personal thresold we have against cheating.

(in reply to dodod)

Post #: 8

RE: PBEM naval issue - 1/14/2008 4:32:54 PM

zaquex

Posts: 368
Joined: 11/30/2007
From: Vastervik, Sweden
Status: offline

quote:

ORIGINAL: dodod

There should at least be a way for the program to see how many times the file was loaded...such as creating a random number that would rewrite 1 of two from the prior player's file, for example; this would remain in the previous file...and at least 1 of these numbers would match when starting the file afterwards. Both numbers would be loaded on the NEXT player's file, and if at least one of these didn't match, it would mean the player re-loaded his file at least twice. Giving that information....

That would work for combat turns/files.

quote:

ORIGINAL: zaquex

There is some code allegedly to stop you from loading your own battlefiles etc (havent tried), the problem here is that the interception and combat takes place in your naval turn.

There is however no way I can see it work in a practical way for your main move turns, this means interceptions, trivial combat, siege, basicly anything that doesnt involve an exchange of files. Making it mandatory to exchange files for every little "event" would make an already slow and very long game a painful and tedious "never ending story".

If your computer shuts down, if your called out of the house, if someone else desperately need to use the computer, if it takes you longer time than you have to finish your turn or you just make the small mistake of not realising where your focus is when clicking the map, all these things can result in you, and legitimately so, needing to reload or alternately need to save your turn and reload it later. Everytime, there would be a small suggestion that you cheated.

I'm aware that any pbem game requires a certain amount of trust but from my experience just the suspicion of cheating is enough to ruin a game and especially for a game that takes so much time investment as this.

quote:

I think this should have been reason enough to make this TCP/IP. A game that cannot even guarantee not cheating by simply re-loading a file...that seems rather odd.

I agree this game is clearly more suited for direct play than pbem. This becomes more and more evident to me and this is far from the only reason.

(in reply to zaquex)

Post #: 9

RE: PBEM naval issue - 1/14/2008 4:46:24 PM

zaquex

Posts: 368
Joined: 11/30/2007
From: Vastervik, Sweden
Status: offline

quote:

ORIGINAL: Ashtar

There is a simple way of improving anti-cheat security, that is, generating in advance all the die rolls
instead of generating them on the spot.

Suppose that the code generates 1000 d6 (that is, 1000 random numbers between 1 and 6) at setup time. They are kept secret and inscribed in the save file. Then every time you need a random number (foraging,
intercepts, battles, etc.) you pick the next in line. When the 1000 series is exausted, the game engine generates a new one and spreads to the save files via the next turn file.

This should avoid people reloading the same turn twice to get a better roll, since they would get the same one.
It is not 100% bulletproof, since if you have more then one die roll in a phase (like different foraging rolls) you can rearrange the order you are getting them to improve the more important ones. However, it is a simple measure to implement and in the worst case scenario, it makes harder to cheat and reduces benefits from it. Something which normally increases the personal thresold we have against cheating.

At first glance it looks like a solution but...

say I start with foraging all my troops, i get the first say 10 numbers then i reload and do my stuff knowing the result of each action, this way it might even encourage cheating just becouse its so simple.

(in reply to Ashtar)

Post #: 10

RE: PBEM naval issue - 1/14/2008 6:23:52 PM

Murat

Posts: 803
Joined: 9/17/2003
From: South Carolina
Status: offline

Well the Quick Combat shares this flaw as well it seems. Has anyone done the exchanging of combat files and how does that work? Would it be better to use a non-player arbitrator to resolve combats and then send the results to the 2 battling parties and a set to the Host to import through the Third Party Combat System?

(in reply to zaquex)

Post #: 11

RE: PBEM naval issue - 1/14/2008 6:56:42 PM

Monadman

Posts: 2085
Joined: 12/6/2005
From: New Hampshire
Status: offline

For PBEM games without Quick Combat option enabled, if the playgroup wants a neutral (non-playing) arbitrator to settle all or some of their battles for them then the arbitrator will need to have the following files and player instructions in order to perform the action.

1. The attacker�s saved game files (with password) immediately after picking his chit
2. The battle file (from the attacker)
3. The defender�s saved game files (with password) and chit pick instruction
4. Instructions for casualty preferences (including pursuit) from both players
5. Reinforcement and guard commitment instructions from both players (if applicable).

I�ll write and post the detailed instructions on the procedure at a later time, but in the meantime, I�d be happy to arbitrate some battles if needed. Just PM me.

Richard

_____________________________

(in reply to Murat)

Post #: 12

RE: PBEM naval issue - 1/14/2008 8:04:05 PM

Grapeshot Bob

Posts: 642
Joined: 12/16/2007
From: Canada
Status: offline

Set up a counter so that a scenario can only be loaded once.

Player A plays his turn. A counter is set to a random number, X. X is�saved on player A's computer in a hidden file. X is also saved in the PBEM file.

Player A sends the PBEM file to Player B.

Player B loads the PBEM file. The counter on the PBEM file is set to X=X+1 once it recognizes that it has been accessed. It can not be reloaded once X=X+1. X=X+1 is also saved in a separate location in a hidden file on Player B's computer. This stops him from loading the PBEM file more than once.

Player B plays his move. The PBEM file has X=X+1 written on it. Player B protects his PBEM file by putting a temporary 1 turn only password on it.

Player B sends the PBEM file back to Player A. Player B's password prevents Player A from directly observing Player B's move.

Player A's original PBEM file is compared to Player B's PBEM file by Player A's computer. The computer itself can read the counter value. Player A's computer verifies that X=X+1 on Player B's file. Player A can not see Player B's moves directly. "X=X+1, File Authenticated" is shown to Player A.

Player A sends Player B's PBEM file to Player C�with the same X=X+1 and "X=X+1, File Authenticated".

Once Player C recieves Player B's PBEM file. Player B sends Player C the temporary password (which each player changes for each turn).

Player C loads the PBEM file.

The process repeats with each player.

GSB

< Message edited by Grapeshot Bob -- 1/14/2008 8:09:17 PM >

(in reply to Monadman)

Post #: 13

RE: PBEM naval issue - 1/14/2008 8:58:27 PM

Murat

Posts: 803
Joined: 9/17/2003
From: South Carolina
Status: offline

From what I understand the problem is that someone can copy a saved game to another folder and then can keep pasting it back into their save file over and over until they get the result that they want. Wouldn't the generated number stay the same in the other folder?

(in reply to Grapeshot Bob)

Post #: 14

RE: PBEM naval issue - 1/14/2008 9:50:04 PM

gwheelock

Posts: 563
Joined: 12/27/2007
From: Coon Rapids, Minnesota
Status: offline

quote:

ORIGINAL: Murat

From what I understand the problem is that someone can copy a saved game to another folder and then can keep pasting it back into their save file over and over until they get the result that they want. Wouldn't the generated number stay the same in the other folder?

Not if the counter is not saved IN a file.

How is this for an idea : Create a unique REGISTRY key for each game
(called a GUID by programmers) that would be generated by the
host ast part of the pbem start file. All players in a single game would have their
current play sequence (DOWN TO THE SPECIFIC INDIVIDUAL COMBAT action)
stored under this key along with their current random number seed in their registry.

If someone needed to restart a game; they could; BUT they would have to start
at EXACTLY the same combat or turn phase and with EXACTLY the same "die rolls"
(which come from that stored random number seed - computer "random" numbers are
NOT really random - they are reproducable given the same start seed)

For this to work EVERY action would have to have some sort of numeric code so that
it would be identifiable - for example in the registry there would be a guid for each pbem game (created by the host at setup - this allows players to be multiple games since their
data for each game is stored separately) :

{1E6ADC03-1A05-4df0-B627-3DAE0F6DA188} (this is what a guid looks like; guid = Globally Unique IDentifier)

under this guid would be a couple of text entries (probably encrypted) :

CurrentStep <GameName>.1807.3.2.7.447.1
CurrentSeed <GameName>.1234567890

The definition for the items in CurrentStep are :

<GameName> = Name of the current game; must match current game loaded
(since we assume the data is encrypted; any changes to the
entry via regedit or other tool will scramble this entry)

1807 = year
3 = month (March)
2 = Country (eg 1=Britain; 2=France; etc .)
7 = Land combat phase
447 = specific area
1 = field combat (2 = siege; etc)

The definition for CurrentSeed is :

<GameName> - as above
1234567890 = the actual random number seed

This registry entry would be updated after EACH combat or non-reversable action
such as a fleet movement.

If a player (for whatever reason) interrupts his turn; when the game resumes it
needs to resume at EXACTLY the point that it stopped (& with the same pattern of results).

< Message edited by gwheelock -- 1/14/2008 9:53:32 PM >

(in reply to Murat)

Post #: 15

RE: PBEM naval issue - 1/14/2008 10:24:31 PM

dodod

Posts: 147
Joined: 12/26/2007
Status: offline

there should be a way to have the multiple random generated numbers in subsequent files, and all computers, would notice if there was a deviation from the generated number order.

IE: land combat file from France (moving first) would include 1000 numbers in order (this will be downloaded on all computers). Austria does his land and land combat, uses the next 50 numbers....with a marker about how many numbers were used in that file. The other players load the file, and if the 51st number doesn't match the one that austria sent, he must have reloaded the turn.

But the registry idea above is more full proof...

(in reply to gwheelock)

Post #: 16

RE: PBEM naval issue - 1/14/2008 10:42:48 PM

gwheelock

Posts: 563
Joined: 12/27/2007
From: Coon Rapids, Minnesota
Status: offline

I just thought of a hole in my suggestion above : players could "save" starting seed settings & reload
them to other steps. I now think that the seed & current step settings need to be combined as :

CurrentStep <GameName>.1807.3.2.7.447.1.1234567890

Guy

(in reply to dodod)

Post #: 17