Bugs on recording and playback

From my own experiences and what I've read from others the following have been observed:

  1. Using the same recording file, the game can show two different things on two playbacks of that. Examples of divergence points include: ships not blowing up in one playback but doing so in another, ships not executing a user order in one playback but doing it in another (including: using and upgrading their abilities). This behavior even happens with single-player recordings.
  2. Whenever one of the issue from (1) manifests during the playback the game becomes prone to crashing (with a minidump), but the crash can take variable time to happen after the divergence point. Sometimes it crashes soon thereafter, but sometimes it only crashes when you try to exit the game. And sometimes it doesn't crash at all.
  3. The recordings that are most likely to cause the problems 1-2 to happen are those flagged by the dev exe on load with Assert @ D:\projects\SINS\SinsRebellion\main\CodeSource\GS/Core/GameRecordSystem.cpp(144) savedCheckSum == currentCheckSum. But I've seen issues from (1) with recordings not otherwise detected as problematic.
  4. I've confirmed with VMmap that the crashes typically observed at (2) aren't related to the Sins process running out (or even close to the limit) of its 2GB address space. It can crash during playback with well over 700MB still available in its address space and free memory fragmentation wasn't an issue either with the largest free chunk at over 300MB.

Anymore of these kind of experience anyone would like to share would probably help the devs.

11,638 views 6 replies
Reply #1 Top

The recordings that are most likely to cause the problems 1-2 to happen are those flagged by the dev exe on load with Assert @ D:\projects\SINS\SinsRebellion\main\CodeSource\GS/Core/GameRecordSystem.cpp(144) savedCheckSum == currentCheckSum.

That makes me wonder if people in different regions have different compilations of the game and if someone went bad with the latest patch in that regard....that's a far-out guess, but it did happen before and required a hotfix....

Reply #2 Top

It happens with my own recordings that I get the assertion about (failure of) "savedCheckSum == currentCheckSum" and that even with the recording and playback being made with the exact same version, 1.82.5006. So I don't think it's caused [only] by varations in exe. I think with Steam everyone gets the same binaries, by the way, there's no "regioning".


Reply #3 Top

Unless things just recently changed, Steam most certainly makes use of regions and it has brought a lot of ire from people who are region locked into localizations they don't want...

If the error comes up in SP, then no it probably is not a regions thing unless the dev.exe and the normal one don't play the same rules...that just seems really unlikely though...

This is starting to sound like Rome 2's replay issues which have gotten really ugly...

 

Reply #4 Top

As far as I know, Steam region locking isn't done by shipping different exes, but I'm hardly an expert on that. Does Sins use any form of Steam regioning? I haven't heard of Sins using regioning before this thread.

Apparently Steam regioning starts with using a different Steam appid for the game in the desired market segments (although it doesn't stop there): http://forums.steampowered.com/forums/showthread.php?t=2968078

 

Reply #5 Top

I know that your region can sometimes determine your localization...in theory, each localization could have its own .exe, if nothing else to change the strings loaded...for that reason, regions could have different .exe's...

How or if region locking affects Sins I do not know....the assert you posted just made me try to think ways there could be incompatibilities...

Reply #6 Top

It turns out Steam lists all localized versions of the game. They only list English and Japanese, so there are apparently no other localization/regionalization versions of Sins:R.