Vampires Dawn II: Using the item "Speicherstein" triggers endless loop

[ghost]

Using the item "Speicherstein" (item which allows to save the game once) in "Vampires Dawn II" triggers an endless loop which means the save file window is always opening regardless if you save the game or exit the save file window. This happens on current master, but not on stable version 0.6.2.3 so we have a regression here.

[ghost]

One observation I made regarding this bug: As soon the save file scene is called the remaining commands of the event are not executed including unsetting the switch which triggers the event so this is the reason for the endless loop. Revised, see comment below.

[Ghabry]

Because you know programming and this is a regression: Could you try to bisect this for us?

Start it with

git bisect start
git bisect good 0.6.2
git bisect bad HEAD

Then compile it and test the build.
If it is broken:

git bisect bad

If it works:

git bisect good

Repeat until the bad commit is found and tell us the commit (takes log(n) steps because it is a binary search [always takes the commit in the middle of the remaining]).

Problem is that you must have the right liblcf version for each revision because of incompatible changes. I recommend that you clone liblcf to lib/liblcf, use CMake with -DPLAYER_BUILD_LIBLCF=ON and then reset liblcf to a revision that is close to the Player date.

[ghost]

After typing in git bisect bad I got the following output: binäre Suche: danach noch 50 Commits zum Testen übrig (ungefähr 6 Schritte) [643b83b5038a51a1aebca92534a67ad743d007d0] Merge pull request #2301 from Ghabry/inputrecv2.

I don't know if this is of any help, but the last git bisect good outputted the following: binäre Suche: danach noch 101 Commits zum Testen übrig (ungefähr 7 Schritte) [7ec99d632c0a3399d01794c48faaac71c3049198] Ineluki: Documentation

[Ghabry]

Yeah this is kinda how it works.
The ungefähr X Schritte tells you how often you must retest and bisect good/bad until it reports something like:
Der erste schlechte Commit ist

[ghost]

The search has been narrowed down to 4 commits, here is the output:
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
e38d5951af54eeff43e15d6911674e5ce8dfe1c4
6fe4dfb4ed913ceb992a1b74a3d1044f40fbf166
cff15f179e05ab661738060f5358d89bdf2500da
a9d73e18365520cbb959e43d19a95385b02eacfd
Keine binäre Suche mehr möglich!

Test results with the remaining commits:
e38d5951af54eeff43e15d6911674e5ce8dfe1c4 - Instantly crashes
6fe4dfb4ed913ceb992a1b74a3d1044f40fbf166 - Instantly crashes as well
cff15f179e05ab661738060f5358d89bdf2500da - Fails to build (tried with different liblcf revisions)
a9d73e18365520cbb959e43d19a95385b02eacfd - Has got the bug

[Ghabry]

somehow I always get an endless loop independent of the version, even in 0.6.2.3.
Can you provide me with a (working) savegame?

[ghost]

Sure, here you go: Save01.zip (Vampires Dawn II, tested with stable 0.6.2.3).

[Ghabry]

Yeah and after loading and then saving with the Speicherstein again I get an endless loop in 0.6.2.3.
Other idea: Where did you get your Vampires Dawn II version from? Could be some version mismatch.

[ghost]

I got the version from www.vampiresdawn.org. (Game version 1.27)

[Ghabry]

oh, so they updated the game (also VD1), interesting o_O

[ghost]

Did more testing and I have to revise my assumption: Calling the save game scene is not the cause for the endless loop, it is something else which blocks the execution of the remaining event commands. I have removed the event command which calls the save game scene (which makes the "Speicherstein" useless, but this is for testing purposes) and still get the endless loop.

[ghost]

Probably found the cause now: The save count isn't being incremented after saving a game. The "Speicherstein" checks if the save count has been changed. Because of this the endless loop is being triggered. It looks like it is meant to force the player to save the game so that the item isn't being wasted.

[ghost]

I'm 100% certain now that the save count not incrementing is the culprit. As mentioned above, the "Speicherstein" checks if the save count has been changed to force the player to save the game. The cause for the save count not incrementing is in scene_save.cpp: The code in line 122 increments the save count (save.system.save_count gets incremented, see lsd_reader.cpp from liblcf, line 37) but the code in line 126 resets it again (because save.system gets overwritten), which results in the save count never being incremented. And because of the save count check we have the endless loop. I don't know if I should try to fix this, as I see a high risk to break anything else by doing so.

Edit: Looks like that there is more which has to be fixed, fixing the counter being reset isn't sufficient to fix the issue.

[Ghabry]

Oh okay this was obviously not possible to find properly via a bisect because this is a bug specific to player and lcf version.
Thanks for figuring this out!

And you can query the save count? That is new to me or I forgot it 😅

[ghost]

Yes, querying the save count is indeed possible. See this code in game_interpreter.cpp. It belongs to event code 10220, Variable Operation. This means you can store the current save count in a game variable. The "Speicherstein" in "Vampires Dawn II" makes use of it.

[Ghabry]

btw this also explains why I was unable to reproduce your bisect result: I always cancelled the saving 😅 . You never said that this matters.

[ghost]

Oh, I'm sorry. I admit I found out about it later that it matters if you save or not when I checked out the event commands used in the event.