View Issue Details

IDProjectCategoryView StatusLast Update
0001928Spring engineGeneralpublic2010-05-18 01:19
ReporterSirMaverick Assigned ToKloot  
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
Product Version0.81.2.1 
Fixed in Version0.81.0.0+git 
Summary0001928: Sync error in frame 1
DescriptionIn BA games (as spec or player) I sometimes (~5-10% of games) desync in frame 1. I'm always the only one at that time. (It seems I'm always playing same game - no mass idle units etc.)

Replaying with sync debug doesn't show any differences in traces.

Does not happen in CA.
TagsNo tags attached.
Attached Files
demos1.tar.bz2 (Attachment missing)
demos2.tar.bz2 (Attachment missing)
Checked infolog.txt for Errors

Activities

SirMaverick

2010-05-16 17:06

reporter   ~0004917

Uploaded 9 demos where this happens.

Might this be cause by using -DMARCH_FLAG="k8"?

Most (not all) players are using stock cmake-mingw32 compiled versions.

Kloot

2010-05-16 19:20

developer   ~0004918

A desync right on frame 1 can be caused by:

  * wrong script.txt parameters generated by lobby client (these get written to the demo, so they would show up when comparing to replays from other people)
  * wrong base content or local mod archive changes (in both cases any decent lobby client should already flag you as desynced)
  * non-standard compilation flags, etc.

hoijui

2010-05-17 17:27

reporter   ~0004920

spring has to be compiled with SSE1 support, but NOT with SSE2, 3, 4, ...
if it is not that, it is still very very likely that it is the march flag.
if not that, then maybe compiler version or other custom compile options, ...

SirMaverick

2010-05-17 22:57

reporter   ~0004921

> wrong script.txt parameters generated by lobby client (these get written to the demo, so they would show up when comparing to replays from other people)
Autohost game, isn't script.txt received from server? It's same in demo files (could compare to other player).

> * wrong base content or local mod archive changes (in both cases any decent lobby client should already flag you as desynced)
I was never desync in lobby.

> * non-standard compilation flags, etc.
> spring has to be compiled with SSE1 support, but NOT with SSE2, 3, 4, ...
What can/does enable other sse versions?

> if it is not that, it is still very very likely that it is the march flag.
happens even without -DMARCH_FLAG="k8"

> if not that, then maybe compiler version or other custom compile options, ...
Only other flags used are -DCMAKE_BUILD_TYPE, -DAI_EXCLUDE_REGEX, -DCMAKE_INSTALL_PREFIX.

SirMaverick

2010-05-17 23:04

reporter   ~0004922

[ 0] Error opening maps/paths/CenterrockV12.4144068072.pe.zip
[ 0] Analyzing map accessibility [8]
[ 0] Block offset: 0 of 16384 (size 8)
[...]
[ 0] Path cost: 16000 of 16384 (size 8)
[ 0] Writing path data file...
[ 0] Reading estimate path costs
[ 0] Error opening maps/paths/CenterrockV12.4144068096.pe2.zip
[ 0] Analyzing map accessibility [32]
[ 0] Block offset: 0 of 1024 (size 32)
[ 0] Block offset: 1000 of 1024 (size 32)
[ 0] Path cost: 0 of 1024 (size 32)
[ 0] Path cost: 1000 of 1024 (size 32)
[ 0] Writing path data file...
[ 0] Pathing data checksum: 00000000

Looks like the problem was that the paths directory was not writable. In this case the checksum is 0 what cased the desync. This is reproduceable.
There is no desync when it is writable.

Kloot

2010-05-17 23:27

developer   ~0004923

Yes, the path checksum is just the crc of the path zipfile. I'll change it so that sending a checksum of 0 (in case of a non-writable directory) will not be seen as a desync.

Issue History

Date Modified Username Field Change
2010-05-16 16:56 SirMaverick New Issue
2010-05-16 16:58 SirMaverick File Added: demos1.tar.bz2
2010-05-16 16:59 SirMaverick File Added: demos2.tar.bz2
2010-05-16 17:06 SirMaverick Note Added: 0004917
2010-05-16 19:20 Kloot Note Added: 0004918
2010-05-17 17:27 hoijui Note Added: 0004920
2010-05-17 17:27 hoijui Status new => resolved
2010-05-17 17:27 hoijui Resolution open => won't fix
2010-05-17 17:27 hoijui Assigned To => hoijui
2010-05-17 22:57 SirMaverick Note Added: 0004921
2010-05-17 22:57 SirMaverick Status resolved => assigned
2010-05-17 22:57 SirMaverick Resolution won't fix => reopened
2010-05-17 23:04 SirMaverick Note Added: 0004922
2010-05-17 23:19 Kloot Assigned To hoijui => Kloot
2010-05-17 23:27 Kloot Note Added: 0004923
2010-05-18 01:19 Kloot Status assigned => resolved
2010-05-18 01:19 Kloot Fixed in Version => 0.81.0.0+git
2010-05-18 01:19 Kloot Resolution reopened => fixed