2025-07-31 02:30 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001928Spring engineGeneralpublic2010-05-18 01:19
ReporterSirMaverick 
Assigned ToKloot 
PrioritynormalSeverityminorReproducibilitysometimes
StatusresolvedResolutionfixed 
Product Version0.81.2.1 
Target VersionFixed 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.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0004917

SirMaverick (reporter)

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.

~0004918

Kloot (developer)

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.

~0004920

hoijui (reporter)

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, ...

~0004921

SirMaverick (reporter)

> 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.

~0004922

SirMaverick (reporter)

[ 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.

~0004923

Kloot (developer)

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.
+Notes

-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
+Issue History