 |
idSessionLocal::IsSavegameValid returns savegame_versionMismatch because RevTracker.GetHighestRevision() != RevTracker.GetLowestRevision() |
|
|
My idlib\svnversion.h contains #define SVN_WORKING_COPY_VERSION "7809:7813M" Is that correct? |
|
|
Same error when I replace "7809:7813M" with an empty string |
 |
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. |
|
|
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. |
 |
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. |
|
|
Please post the complete steps to fix this on my side Just updating svn and recompiling did nothing for me |
|
|
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 ;) ) |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 1>precompiled.cpp |
|
|
When you install TortoiseSVN, make sure to enable "install command line tools" or something like that in the installer. |
|
|
So there has been another report that definitely requires alterations to the gui: http://forums.thedarkmod.com/topic/19841-quicksave-quickload-not-working/ While I am at it, I am also adding a cvar that allows you to ignore mixed svn revisions. |
|
|
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. |
|
|
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? |
|
|
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! :-) http://wiki.thedarkmod.com/index.php?title=The_Dark_Mod_-_Compilation_Guide#Working_in_SVN For Linux you download the subversion package, which probably includes svnversion automatically. |
|
|
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: http://forums.thedarkmod.com/topic/18841-disable-svnkeywords/ 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. |
|
|
If svn version is empty string then the check always fails |
|
|
Whoa! 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. |
|
|
Good thing I turned the check for mixed revisions into a warning then. |
|
|
Important update: in svn rev 8180 I have switched from "svnversion" to "svnversion -c" and removed all mixed-revision warnings. Discussion on forums: http://forums.thedarkmod.com/topic/19841-quicksave-quickload-not-working/#entry436774 |
- Anonymous
