Incorrect LOG entry for pp gain/loss

[gwheelock]

{edited}
I need to change this - this IS a serious error :

Note - this appears to be an incorrect log entry ONLY & thus NOT should not be
considered a serious bug. Please put it on the "when I get a free - yah right - moment fix list"

France & Austria fought a battle in leopoldstadt.
Original force composition was 4 French corp (all > 20) vs 2 Austrian Insurrection corp
On round 2; Charles reinforced into the battle with 8 MORE Austrian corp for a
total of >10< Austrian corp. Austria loses the battle & thus loses 3 pp (max
pp loss).

The LOG entry claims that there is only 1 pp gain/loss (plus 1 for Nappy) not 3.

The political status chart DOES appear to correctly account for the right losses.

Program versions were France 1.02g & Austria 1.02k

[gwheelock]

The PS status chart does appear to correctly account for everything :

Austria started at ps 17
-3 for Leopoldstadt = 14
-2 for Vienna occupation = 12
-1 for losing Breisgau = 11
-1 for losing another battle in Piedmont = 10
+2 PSA (battle occured at the end of March 1806) = 12

[gwheelock]

Ok; please ignore what I posted above; this bug IS more serious AND more COMPLICATED than I thought.

here is what I belive ACTUALLY happened (Jimmer can confirm this):

Austria started the French l-c turn at PS 18.
he loses 1 for a combat in Piedmont/Turin = 17
he loses 1 for the big battle in Leopoldstadt = 16
(this should lose 3; but is incorrectly not counting successfully
reinforcing corp)
he loses 1 for France capturing Breisgau = 15
he loses 2 for having Vienna occupied =13
he gets his >4< vp for being in the PS13 zone (see the log entry in attached jpg)
he then loses 3 for his economic manipulation even though Vienna is
occupied & the log says no e-m - this puts him in the ps 10 zone
finally he gains +2 for PSA putting him into the ps 12 zone where he ends up.

What SHOULD have happened is :
he starts in the ps18
he loses 1 for Turin = 17
he loses >3< (max loss) for Leopoldstadt = 14
he loses 1 for Breisgau = 13
he loses 2 for Vienna occupation = 11
he should gain >3< VPs for being in the PS11 zone
he loses >0< because having Vienna occupied cancles his e-m
finally he gains +2 for PSA putting him in the ps13

There are TWO bugs here :

1) Reinforcing corp are not being counted in the pp gain/loss values (rules say UNSUCCESSFUL reinforceing corp are not counted; SUCCESSFUL should be)

2) Economic manipulation is being "charged" for even if it has been cancled due
to the capitol being occupied.

I think that THIS sequence finally explains all of the stuff I was seeing in the log
(a third "bug" is that we need MORE info in the log so that we can better diagnose
these kinds of errors).

Again versions are : France 1.02g; Austria 1.02k

[DCWhitworth]

ORIGINAL: gwheelock

Program versions were France 1.02g & Austria 1.02k

All players in a PBEM game should be on the same patch version otherwise you may get issues.

[Jimmer]

A couple of suggestions:
&nbsp;
First, the log is woefully inadequate for judging what has happened recently. It needs to have a LOT more detail. I suggest putting EVERYTHING into it except that which is private information.
&nbsp;
But, that will make the log grow much larger (and it's big today). So, to got with that, add an "archive" feature to the log. An annual or quarterly purging of old information, after copying it to a file.

[NeverMan]

ORIGINAL: DCWhitworth

ORIGINAL: gwheelock

Program versions were France 1.02g & Austria 1.02k

All players in a PBEM game should be on the same patch version otherwise you may get issues.

If you get errors due to being on different versions which are not in either version seperately, than that should be considered a bug in itself.

Having every game on the same version is very difficult because (due to PBEM, the games are VERY SLOW) people like to play more than one game at a time.

[gwheelock]

I have a backup of the French lc turn right at the start of the Leopoldstadt battle

along with copies of all of the "pbembattle..." files that I sent back to Austria and those

that I recieved from Austria.



Here are the French turn files; the PW is "heaven"

[gwheelock]

And here are the pbembattle files - to determine the order of the pbembattle turn files;
look at the compression files within the combined zip. The order should be :

ToAustria1 - pbembattle_CleverDevils2_Leopoldstadt0.zip - this is the initial file
sent

FromAustria1 - pbembattle_CleverDevils2_Leopoldstadt0.zip - this is his response

ToAustria2 - pbembattle_CleverDevils2_Leopoldstadt0.zip - this is my response to his response

FromAustria2 - pbembattle_CleverDevils2_Leopoldstadt0.zip - this is the response to the response to the response

etc. etc.

[MarshallEllis]

1.02k allows you to clean up the log entries. You could copy to the clipboard then delete parts (or all) of the log.
RT click on the log panel at the bottom left and you should see this.
&nbsp;
&nbsp;

[gwheelock]

Marshall; we are not saying that we need to be able to REMOVE stuff from the log (tho that
is true too).&nbsp; What we are saying is that&nbsp;MORE &nbsp;needs to be ADDED BY THE PROGRAM as turns are
processed so that we have a fully auditable trail of events.&nbsp; All pp gain losses should show both
the +/- delta AND the new location on the ps chart (ie : "Austria gains +1 for capture of Bavaria new PS zone is 27" or something).&nbsp; Combats should report : leader on each side;
number of corp involved; initial morale; inital number of troops (broken down by type : "30I; 10G 10C")
chits chosen; die rolls and modifiers&nbsp;- round-by-round
and final number of remaining morale and troops (again broken down by type).
This will let players do a full audit of combat results & determine if there are any more bugs in the
system.
&nbsp;
PS. Speaking of bugs; Austria reported a >3rd< bug connected with this.&nbsp; His economic manipulation
is locked/frozen at -3 even though (probably BECAUSE) Vienna is occuped (I suspect that somewhere
in the code is a setting for the em control that says :
&nbsp;
emcontrol.active = not capitoloccupied
&nbsp;
& you need to add&nbsp; an entry right after that that says
&nbsp;
IF capitoloccupied THEN
&nbsp;&nbsp;&nbsp;&nbsp;emcontrol.value = 0
ENDIF&nbsp;
&nbsp;

[MarshallEllis]

Oh! OK.
I thought we had decided that not ALL battle information is to be revealed for FOW?
BTW: Will look at the EM freeze issue.

[MarshallEllis]

Neverman:
&nbsp;
I understand that the different versions should work together but I'm not sure how I could do this differently since a newer version could have a map / nation / province setting fix that an older version would not have? This could handicap the older version players??? The mechanics of passing turn files, etc have not changed and the game should flow fine. You just might see different eco numbers / move issues depending on the map DB changes in the newer versions. 90% of the time this should be a non-issue. Most fixes will just touch the EXE itself. A release notes scan should help&nbsp;prevent this before you start a pbem.
&nbsp;
&nbsp;

[NeverMan]

1. Who decided to have FOW? Revealing battle info is part of EiA, I dont know if that other thing is some bad EiH hybrid or what. I really think this game would have been much easier on you guys if you had just decided to code EiA. It's difficult to ask for users help when the users aren't really aware of what is suppose to be happening. The manual, while very lengthy and descript, is not quite descript/thorough enough.

2. I'm not sure how you would do it either. This will probably get easier once more bugs are fixed but at this rate it could be awhile. I guess the "smart" choice the users would be to play with the last "official" release, but at this point in the fixes that would mean playing with an inferior patch.

[gwheelock]

ORIGINAL: Marshall Ellis

Oh! OK.
I thought we had decided that not ALL battle information is to be revealed for FOW?
BTW: Will look at the EM freeze issue.

Don't forget the other two bugs :

Not counting reinforcing corp for pp gain/loss and
Actually DOING e-m even if the capitol is occupied (Austria has confirmed that
he recieved the extra $/mp that he was manipulating for)

(Note: Fixing the em freeze may also fix the latter if it resets the control to 0 before
the econ phase)

[Jimmer]

ORIGINAL: gwheelock

here is what I belive ACTUALLY happened (Jimmer can confirm this):

Yes, this is what I saw, too.

[Jimmer]

ORIGINAL: gwheelock

Marshall; we are not saying that we need to be able to REMOVE stuff from the log (tho that
is true too).  What we are saying is that MORE  needs to be ADDED BY THE PROGRAM as turns are
processed so that we have a fully auditable trail of events. 

I agree completely, and this is exactly what I meant. (Don't take my not quoting his whole post as meaning anything; I just wanted it shorter.)

If we had the equivalent of a complete audit trail, we would most likely find many other bugs. But, right now, we have to guess at half the information. Gwheelock and I spent about a half hour on the phone trying to discern what the "actual" vs. "should have been" scenarios were. It turned out that there are some impossible positions on the PSD, and some that can only be attained by exactly one scenario, and this got us where we needed to be.

For example, in this case, we noted that the ONLY way to get to the 12 position is if one were in the 10 position just prior to the political status adjustment step. Once we saw that he was at the 10 position at that point, we eventually determined that there was only one way to get there: Through exactly two miscalculations by the program: The missing -2 PP from the main battle for not counting reinforcements, and the missing +3 PP for having economic manipulation turned on when it should not have been on.

It's hard to find logic flaws on partial information, but it CAN occasionally be done. This was one of those cases.

But, what we're saying, Marshall, is that if ALL the information were present, then we could tell at a glance what happened in the case of both errors.

[Jimmer]

ORIGINAL: Marshall Ellis

Oh! OK.
I thought we had decided that not ALL battle information is to be revealed for FOW?
BTW: Will look at the EM freeze issue.

FOW would be OK. But, there should be a master log SOMEWHERE that could be viewed that would show ALL information. This log could be checked against individual logs for errors.

In our game, I don't think anybody would much care about FOW, so having the log in the host's hands would probably work fine. I would suggest that even in games were FOW was desired, the information can be revealed some months later. At this point, ALL the information.

However, in this case, some of the information should have been open info. For instance, the fact that points were taken off due to EM when EM had been turned off due to capital occupation.

NOTE: I don't think you should correct the "not enough info" issue in the current series of patches. This should be a 1.03 or 1.04 issue. It's too risky for 1.02.

[Jimmer]

ORIGINAL: NeverMan

2. I'm not sure how you would do it either. This will probably get easier once more bugs are fixed but at this rate it could be awhile. I guess the "smart" choice the users would be to play with the last "official" release, but at this point in the fixes that would mean playing with an inferior patch.

It's worse than that: If everybody who is playing a PBEM game were all running 1.01, nobody would exist who could test the beta versions.

Marshall, to solve this, we need the ability to load a second copy of the game. But, there are a couple of potential problems with this:

First, it can't violate the license agreement to do so.

Second, there has to be discreet locations on the disk AND in the registry, such that one copy won't interfere with the other (if installed on one system). If located on two systems, beta testers would have to be made "official", so they can have two copies on two systems. Yes, I know that the copy protection against that is weak, but it doesn't matter: I don't want to be illegal or unethical.

Third (and related to #2), if one had two copies, one could much more easily cheat (by simply loading the save files on two computers -- you take it from there). So, the user's serial number AND instance would have to be loaded into saved game files and battle files. Alternately, a second (beta?) serial number should be used.

[MarshallEllis]

Hey guys:
&nbsp;
FYI...
One big difference in the log entrees in 1.02k is the fact that I totally change the way log messages are recorded and passed on to other players in PBEM. I took a long look at this code and almost EVERY diplomacy phase with diplomatic results (Spain's diplomacy) was overrunning the message buffers and I suspect 10-20% of those messages were not finding their way to the next player. This also looked like it was happening in land phases with several battles. Anyway, hope this is better now...
&nbsp;
&nbsp;

[Jimmer]

THAT should help, at least with the log part. I'll check it out.
&nbsp;
The other part (where incorrect PP are tallied) is still a bug.