View Issue Details

IDProjectCategoryView StatusLast Update
0004964The Dark ModSaving/Loadingpublic04.04.2020 10:21
Reporterduzenko Assigned ToSTiFU  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.08Fixed in VersionTDM 2.08 
Summary0004964: Version check fails
DescriptionI get what looks like an error message without a reason
Steps To ReproduceStart Swing, quick save and reload
TagsNo tags attached.


child of 0004531 resolvedSTiFU Warn player in GUI about loading incompatible savegame 




17.01.2019 15:01


Untitled2.jpg (295,517 bytes)


17.01.2019 15:17

developer   ~0011392

idSessionLocal::IsSavegameValid returns savegame_versionMismatch because
RevTracker.GetHighestRevision() != RevTracker.GetLowestRevision()


17.01.2019 15:19

developer   ~0011393

My idlib\svnversion.h contains
#define SVN_WORKING_COPY_VERSION "7809:7813M"
Is that correct?


17.01.2019 15:25

developer   ~0011394

Same error when I replace "7809:7813M" with an empty string


17.01.2019 15:36

developer   ~0011396

Last edited: 17.01.2019 15:56

View 2 revisions

This behavior is by design. Your SVN working copy is not completely updated. Just update, recompile and you should be fine.

Only if HighestRevision == LowestRevision == SaveGameRevision, it is guaranteed that the savegame is compatible.



17.01.2019 15:37

developer   ~0011397

If you want, we could add a cvar to be less restrictive about the version check for development purposes. Or just remove the requirement HighestRevision == LowestRevision because, after all, a release candidate will always fulfill this requirement.


17.01.2019 16:59

administrator   ~0011399

Last edited: 17.01.2019 17:00

View 2 revisions

Players will never have mixed revision.

Developers... well, I guess developers are used to ignoring savegame revision check. Just click force-load and close issue =)

P.S. And yes, better update your working copy completely.



18.01.2019 12:41

developer   ~0011404

Please post the complete steps to fix this on my side
Just updating svn and recompiling did nothing for me


18.01.2019 12:53

developer   ~0011405

Last edited: 18.01.2019 12:54

View 2 revisions

When you're fully updated
  RevTracker.GetHighestRevision() == RevTracker.GetLowestRevision()
should be fulfilled, unless I understood the underlying mechanics incorrectly. I suppose now, that you fully updated, the savegame is outdated. To verify this, check which revision the savegame was created with from the console output and fully update/revert your working copy to exactly that revision.

However, I now realized that we'd actually also also have to ensure that
  RevTracker.GetHighestRevision() == RevTracker.GetLowestRevision()
when writing a savegame to have 100% savegame compatibility. Instead of that, the savegame header could also be extended to carry the LowestRevision, but I wouldn't want to mess with the header format. I'll just leave it as it is, though, so that this doesn't cause any further headaches. After all, as stgatilov said, the above requirement can only break for devs and we know what we're doing. (most of the time ;) )



18.01.2019 14:13

administrator   ~0011408

Last edited: 18.01.2019 14:13

View 3 revisions

I think the following steps could help:
1) Make sure all parts of your working copy are on the same url+revision of svn. You can go through directories and run svnversion in each directory to find where the wrong revision is checked out.
2) Build new version.
3) Load the savegame and click "force" if the message pops up.
4) Save the game, overwriting that save.
With the newly generated save, you won't have the dialog.



19.01.2019 07:47

developer   ~0011422

If we find that this issue frequently bothers us, we can remove the lowest==highest test for us devs. Up until then, I will suspend this issue, as there is nothing to do.


19.01.2019 08:40

developer   ~0011424

Last edited: 19.01.2019 08:42

View 2 revisions

Sorry, this is still broken for me
I followed the steps from 0011408 on my home PC and SVN_WORKING_COPY_VERSION is still empty string.
This causes the default values in RevisionTracker::_highestRevision/_lowestRevision in runtime, and I need to click the damn button on every quick load.



19.01.2019 08:44

developer   ~0011425

Here's my idlib build log (first few lines)

1>------ Rebuild All started: Project: idLib, Configuration: Release x64 ------
1>Insert SVN revision number into svnversion.h
1>'svnversion' is not recognized as an internal or external command,
1>operable program or batch file.
1>Inserted SVN revision number into svnversion.h


19.01.2019 09:29

administrator   ~0011430

Last edited: 19.01.2019 09:30

View 2 revisions

When you install TortoiseSVN, make sure to enable "install command line tools" or something like that in the installer.



20.01.2019 08:21

developer   ~0011442

So there has been another report that definitely requires alterations to the gui:

While I am at it, I am also adding a cvar that allows you to ignore mixed svn revisions.


20.01.2019 09:22

developer   ~0011443

I have not added another cvar, as stgatilov requested on the forums.

Now, there will generally only be a warning when you're running mixed revisions and the savegame revision will only be compared against the highest revision.


21.01.2019 07:58

developer   ~0011460

Are you sure that having or not having the TortoiseSVN CT during build should affect the load/save operation in runtime?

Do we have that on the Compilation Wiki page?

Is that true for both Linux and Windows?


21.01.2019 08:03

developer   ~0011461

Last edited: 21.01.2019 08:04

View 2 revisions

We must have some form of version checking with savegames and we always had. The only thing I enabled were the gui messages, whereas before, you would just be droped to the beginning of the level rather than actually loading the saved game.

The wiki also states that you need the command line tools and when I noticed that you missed those, I even edited the wiki to make that line bold! :-)

For Linux you download the subversion package, which probably includes svnversion automatically.



21.01.2019 12:52

administrator   ~0011463

The SVN check has been here from the very beginning (at least in 2011 it was here).

It was originally using svn:keywords to automatically embed SVN revision string into every file in the whole source code repository. I removed the svn:keywords things and replaced it with svnversion prebuild step:
Now programmers have to install command line tools (or svnversion on Linux). This command the official part of subversion, I suppose.

If any developer fails to install svnversion, then TDM will simply produce savegames with -1 or 0 revision for him, and the whole revision check will not work. He can still play and do everything, just this check is bugged.


21.01.2019 19:50

developer   ~0011465

If svn version is empty string then the check always fails


22.01.2019 05:45

administrator   ~0011466

Caught with mixed revision myself in beta build.
It is actually very easy to get. You get mixed revision if you forget to update after a commit.


22.01.2019 05:57

developer   ~0011467

Good thing I turned the check for mixed revisions into a warning then.


16.04.2019 17:03

administrator   ~0011745

Important update: in svn rev 8180 I have switched from "svnversion" to "svnversion -c" and removed all mixed-revision warnings.

Discussion on forums:

Issue History

Date Modified Username Field Change
17.01.2019 15:00 duzenko New Issue
17.01.2019 15:01 duzenko File Added: Untitled2.jpg
17.01.2019 15:14 duzenko Relationship added child of 0004531
17.01.2019 15:17 duzenko Note Added: 0011392
17.01.2019 15:19 duzenko Note Added: 0011393
17.01.2019 15:25 duzenko Note Added: 0011394
17.01.2019 15:36 STiFU Note Added: 0011396
17.01.2019 15:37 STiFU Note Added: 0011397
17.01.2019 15:56 STiFU Note Edited: 0011396 View Revisions
17.01.2019 16:59 stgatilov Note Added: 0011399
17.01.2019 17:00 stgatilov Note Edited: 0011399 View Revisions
18.01.2019 12:41 duzenko Note Added: 0011404
18.01.2019 12:53 STiFU Note Added: 0011405
18.01.2019 12:54 STiFU Note Edited: 0011405 View Revisions
18.01.2019 14:13 stgatilov Note Added: 0011408
18.01.2019 14:13 stgatilov Note Edited: 0011408 View Revisions
18.01.2019 14:13 stgatilov Note Edited: 0011408 View Revisions
19.01.2019 07:47 STiFU Note Added: 0011422
19.01.2019 07:48 STiFU Assigned To => STiFU
19.01.2019 07:48 STiFU Status new => suspended
19.01.2019 07:48 STiFU Resolution open => no change required
19.01.2019 08:40 duzenko Note Added: 0011424
19.01.2019 08:42 duzenko Note Edited: 0011424 View Revisions
19.01.2019 08:44 duzenko Note Added: 0011425
19.01.2019 09:29 stgatilov Note Added: 0011430
19.01.2019 09:30 stgatilov Note Edited: 0011430 View Revisions
20.01.2019 08:21 STiFU Note Added: 0011442
20.01.2019 08:21 STiFU Status suspended => assigned
20.01.2019 08:21 STiFU Resolution no change required => open
20.01.2019 09:22 STiFU Note Added: 0011443
20.01.2019 09:22 STiFU Status assigned => feedback
20.01.2019 09:22 STiFU Resolution open => fixed
20.01.2019 09:22 STiFU Status feedback => resolved
21.01.2019 07:58 duzenko Note Added: 0011460
21.01.2019 08:03 STiFU Note Added: 0011461
21.01.2019 08:04 STiFU Note Edited: 0011461 View Revisions
21.01.2019 12:52 stgatilov Note Added: 0011463
21.01.2019 19:50 duzenko Note Added: 0011465
22.01.2019 05:45 stgatilov Note Added: 0011466
22.01.2019 05:57 STiFU Note Added: 0011467
16.04.2019 17:03 stgatilov Note Added: 0011745
09.03.2020 11:22 stgatilov Target Version => TDM 2.08
04.04.2020 10:21 STiFU Fixed in Version => TDM 2.08