A different solution to VCR bug?

Istfemer · Post by **Istfemer** » Sat Oct 04, 2014 11:38 am

*DEPRECATED*

I learned not to trust VCR in this game, as Allies anyway. Recently I encountered the bad bug again and these are my findings:

This annoying non-matching VCR bug appears to be related to DISPLAY/DELAY settings you set every time you run the VCR.
You should not change the settings when VCR playback is already running. It is very convenient, yes, but it makes this bug happen.

Merely pausing during execution (by pressing Enter) by itself does not create this bug. (but see below!) Only changing settings does.
Be warned, however — game sometimes changes those settings on its own accord.
I had this unexpectedly happen to me after several pausings. At a certain point game changed Display level from None to Low.
Then the VCR went into desynch.

*DEPRECATED*

Istfemer · Post by **Istfemer** » Sat Oct 04, 2014 11:49 am

*DEPRECATED*

Right after you load a save in vcr (VCR Play Back phase has not started yet) you should pick your Display/Delay settings and stick with those throughout the whole recording. And if you want to be absolutely sure this bug does not pop up, do not pause during VCR playback.
---

Note: You probably don't have to do this if your opponent (Japanese side) has kindly provided you with a relevant REPORT.CBT file.
Just be sure not to lose that file and don't forget to replace your previous .cbt with it if you loaded some other save in between. (game generates a new .cbt file after each save load)

I'm still not sure about the deeper causes of this bug. One big possibility is that it's caused by a mismatch between the recieved (Japanese) save files and (Allied) report.cbt, as was suggested earlier by deVada.

More testing can be done on this bug if someone is still interested. It seems like not every non-matching save—report.cbt combination triggers this bug.
And the ultimate cause of it is still unknown. Something in pac.exe may be responsible for this behavior.
Btw, are there any reports of this bug occurring to a Japanese side player?

*DEPRECATED*

bradk · Post by **bradk** » Thu Oct 09, 2014 2:26 am

The reason I think report cbt doesn't do anything is if it were related to the save there would be a reporta.cbt, reportb.cbt, etc. There isn't. There's just one.

Istfemer · Post by **Istfemer** » Sat Jan 03, 2015 3:57 pm

New year — new findings. We're getting closer to figuring out the causes of this mysterious bug.

Short story:
This serious bug apparently arises from the faulty interaction between Naval-Air Action combat routine (the one responsible for ACTF/LBA-on-TF and ACTF/LBA-on-Port airstrikes) and player-initiated Display/Delay menu call.

Looooong story:
I'll post it when I manage to edit it into a readable form. [;)]

NCommander · Post by **NCommander** » Sun Jan 04, 2015 9:32 am

I do wish this classic was open source so a serious effort could be made at fixing some of the bugs

Istfemer · Post by **Istfemer** » Wed Apr 22, 2015 12:23 pm

It is a tough puzzle, this one. Still searching for the causes & the cure.

This complex bug actually isn't exclusive to VCR or even Secure PBEM. That PBEM VCR mismatch thing is a very small part of it.
The bug is global in scope and is likely multi-stage.
It's ..uh.. the seed desync between pac.exe and report.cbt and also savex.vcr + possibly other savex(.xx) files caused by a Display level change bug?

I'm now 100% sure report.cbt is somehow involved.

I'll try to write more on report.cbt, Naval-Air Action weirdness and other things later this day.

Istfemer · Post by **Istfemer** » Wed Apr 22, 2015 12:59 pm

Here's the PACWAR Turn Sequence table. It will serve as a visual aid.

Istfemer · Post by **Istfemer** » Wed Apr 22, 2015 6:35 pm

Under certain conditions changing Display level during Orders Phase changes the turn's outcome even though no other action is taken during that Orders Phase. Moreover, usually (always?) this seems to only affect the outcomes of a certain few types of battles. (like Naval-Air Action (and maybe Surface Combat too?) OR everything except Naval-Air Action (and maybe Surface Combat too?))

Why this sometimes happens and sometimes doesn't I still have no idea. I'm testing things and getting nice and predictable results and then -wham- suddenly I get an outlier. I'm trying to test further but after 1-2 confirmed strange results something goes off and -poof- outcomes suddenly become stable & predictable again.

Maybe it's the clock? [&:]

Istfemer · Post by **Istfemer** » Wed Apr 22, 2015 6:41 pm

Manual states: Human controlled HQs execute display/delay levels at whatever levels the player has selected. If an HQ is under computer/operational control, the display/delay is set to None/None. Naval combats are displayed at one level higher than what you have preset.

PACWAR manual, as often is the case, isn't particularly clear here. Which types of combat count as naval in-game?
It seems like Surface Action and Naval-Air Action are among them. Naval Bombardment isn't.

Does one level higher than what you have preset affect Display only or Delay as well? This is important to know!
I find it weird that changing Display level would throw the clock and RNG off. Maybe Delay too, is covertly involved in this? [8|]

-----------

User boba wrote this 12 years ago:

ORIGINAL: boba
In my experience difference between VCR and combat reports appears exacty in major surface and carrier engagments...

Looks like he's right.

Istfemer · Post by **Istfemer** » Wed Apr 22, 2015 9:07 pm

Changing Display level mid-Execution Phase is another way to change the turn's outcome.

Make a relatively simple test. Start the Rising Sun PBEM scenario on Both Human and Even. Decline the Historical Turn and set Display to None.
Create a TF with some Japanese carriers in it and send it to Maloelap. It should arrive in two turns. Alternatively, you can teleport your TF by using one of the many discovered tele-techniques. [:)]

#1. Stage an attack on Pearl from Maloelap. Don't forget to save your game.
End your Japanese turn, then your Allied turn (do nothing) and proceed to Execution Phase.
Run it till the end and record the casualties. (you might want record some other stuff too!)

#2. Now reload and proceed to Execution Phase once more.
Right before the attack on Pearl Harbour pause the game with F10 or Enter.
Display level will still be staying at None. And yet, the results of some of the following battles will be different.
Run it till the end and record the casualties once more. They should be different.
Which battles were different: Naval-Air Action ones OR all others except Naval-Air Action ones?

#3. Now reload the second time and proceed to Execution Phase yet again.
Right in the middle of a port attack pause the game with F10 or Enter.
You will notice that Display level has shifted to Low.
Run it till the end and record the casualties yet again. Are they the same as in the case #1? Or are they different to both #1 and #2?
I think I got the same results as in the case #1 in my most recent test.

Istfemer · Post by **Istfemer** » Wed Apr 22, 2015 9:53 pm

Report.cbt is a temporary file used by PACWAR to synchronize things between different gaming sessions, player sides and likely also VCR.
When a game is saved contents of Report.cbt are written to savex.cd. Report.cbt is copied from the last loaded savefile (savex.cd is used for this). It doesn't have to be unique for each save. Report.cbt is continuously updated during Execution Phase.
When a game is saved to disk, the contents of Report.cbt are written to savex.cd (the latter is overwritten)

savex.rd has the same size as savex.md
savex.vcr has the same size as savex

Something to ponder.
-----------

Regarding .vcr errors in general, most of them might have been caused by the actions of the Japanese players.
Specifically, by indiscriminate pausing during Execution Phase.
Both sides should refrain from this, if possible.

Another possibility here. Japanese players start the Execution Phase. Depending on which Display level they viewed it on and later also on which Display level they or the Allied players review it on VCR, the results might differ if Display levels don't match. Sometimes anyway. Hard to test that.

Istfemer · Post by **Istfemer** » Wed Apr 22, 2015 11:21 pm

The clock. Just what clock are we talking about? The one that affects RNG of course.

Speed: [50] and [75] and [100] and [125] and [150]
Outcome: [−20] and [−10] and [1] and [+10] and [+20]

[1] is the "present" outcome.
[+10] is the "future" outcome and [+20] is the "distant future" outcome
[−10] is the "past" outcome and [−20] is the "distant past" outcome

The number should always be [1]. RNG should be generating results at fixed speed. Looks like it doesn't.
Display level changes must be somehow affecting the clock. (Why not Delay? Maybe Delay is guilty too in some subtle fashion.)

It seems like under certain conditions (or maybe always, we've just never noticed it) during naval battles (subphases c, d and f. I don't know about e) game clock speeds up and makes RNG produce [+10] "future" outcomes. During (all?) other battles the game clock stays at default/is slowed down back to default value and RNG gives out correct [1] "present" outcomes.
Outcomes of all Naval-Air Action battles become "future" [+10]. (and maybe Surface Action ones do too?)
Outcomes of (all?) other battles are still regular "present" [1].

The game clock speeding up during a Naval-Air Action may be an intended behaviour and the seed mismatch that results from it may be an oversight.

It also seems like under certain other conditions the reverse situation occurs!
Outcomes of all Naval-Air Action battles are still regular "present" [1]. (and maybe Surface Action ones are too?)
Outcomes of (all?) other battles become "past" [−10].

There is a number of possibilities here. I won't be listing them all here because my head is spinning now. [:D]
My general idea here was along the lines that game clock may refuse to speed up at all but would still later slow down, now to incorrect value. And it may refuse to speed up precisely due to pausing during a Naval-Air Action.
-----------

Maybe I am imagining things. Maybe this is a wild theory but I don't know what else it could possibly be.
I wish someone with more experience in programming would chime in and clear up this one for us. I need feedback badly.

Fishbreath · Post by **Fishbreath** » Fri Apr 24, 2015 12:46 pm

A couple of times in my current game, I've realized I forgot to move a task force in an invasion force or something, I've had to replay a turn, and I've noticed that results are the same up until the new move. What that suggests to me is that the seed for the random number generator is known, and the order in which things occur is fixed. You're probably on the right track for your guess.

I suspect the following:
1. The first run of the turn-end sequence is the definitive, authoritative one—whatever happens the first time someone watches it is what happens for real.
2. Some things are simulated differently, using more or fewer random numbers, depending on the display setting.
3. Therefore, when viewing a turn replay, the sequence of random numbers gets thrown off, and everything after the display setting changes from the display setting used in #1 goes awry.

You appear to have confirmed this in post #10, by following this process:

1. Pick a save file from the middle of a game. (At game start, the random seed seems to be random itself—that's why historical first turns play out differently each time.)
2. Play out a turn, and note the results.
3. Play out a turn again, and verify that the results are same.
4. Play out the turn once more, changing the display setting at the very start of the execution phase, and see if the results are different.

If so, then the random number sequence is different at different display levels, and to get the same playback results, you should always use the same VCR playback settings as the turn was originally finished with.

Istfemer · Post by **Istfemer** » Fri Apr 24, 2015 6:33 pm

ORIGINAL: Fishbreath
If so, then the random number sequence is different at different display levels, and to get the same playback results, you should always use the same VCR playback settings as the turn was originally finished with.

I thought it was that simple but it is not.