[Not ZDoom] [r3765+-] New level changes maxhealth

[FDARI]

I don't know exactly what it does, but I picked up medikits up to 800 without any restriction. The restriction is there until I call teleport_newmap. On the new map, I can eat all the health.

Spoiler: Not that relevant anymore

Attached demo: Spawns some health (medikit) and gives you a moment to verify that you cannot exceed maximum by walking over them, then calls teleport_newmap and repeats the procedure. After the teleportation, you should be able to have all the health you want.

Spoiler: All the code

Code: Select all • Expand view

#library "newlevel"
#include "zcommon.acs"

global int 1:donetele;

script "newlevel" enter
{
   spawnforced("medikit", getactorx(0) + 100.0, getactory(0), getactorz(0), 0, 0);
   spawnforced("medikit", getactorx(0) - 100.0, getactory(0), getactorz(0), 0, 0);
   spawnforced("medikit", getactorx(0), 100.0 + getactory(0), getactorz(0), 0, 0);
   spawnforced("medikit", getactorx(0),-100.0 + getactory(0), getactorz(0), 0, 0);
   delay(188);
   if (donetele) terminate;
   donetele = true;
   teleport_newmap(2, 0, true);
}

EDIT: In my actual project (this is obviously just a demonstration case) I also had some issues with accuracy and stamina. I got values in the 12000 and 30000 area; they may even have been consistent. I wonder if I'm being assigned a bogus player class.

EDIT: The trigger criterium was not method of changing level (teleport_newmap) but changing level at all. It applies to the most recent revision (r3765) and probably a few revisions back.

Triggers: NEXTMAP works (no problem). MAP MAP02 works (no problem). TELEPORT_NEWMAP triggers bug. Normal level change triggers bug.
Bug details: Stamina and accuracy are not correct. The incorrect stamina permits you to grab extra health. (Stamina 38904, Accuracy 57312)

New discovery: Saving the game breaks accuracy and stamina (in the same manner as when you change levels). It may be that level change isn't the cause at all. Level change triggers autosave. It may well be saving that contains the faulty code. (You don't need to load the game to get the error; it's wrong from the moment you save)

[randi]

I cannot reproduce this problem. Are you sure there's nothing else you're loading that could be causing it?

[FDARI]

I was not loading anything extra in terms of wads; the only source of deviation I know is program version and ini-file. The executable was compiled from the latest svn at some point.
Now I have tested the release version [2.6.0] and the drd-team build r3735 in newly created folders and not managed to reproduce the issue.

Replacing the executable and pk3 from 2.6 with the same files as I built them produces the issue. So it is either very recently introduced, or that build-operation had an unreported error.

(I initially buit from svn because the version on drdteam did not support the latest mapinfo features. So I have r3749 or newer. The executable calls itself r3312.)

EDIT: Did another rebuild. It was clearly ok, but produced the same bug. I have also started a rebuild based on the very latest svn version to test that.

Finding: Bug still present in 3765. More details in updated OP.

[FDARI]

New discovery: Saving the game breaks accuracy and stamina (in the same manner as when you change levels). It may be that level change isn't the cause at all. Level change triggers autosave. It may well be saving that contains the faulty code. (You don't need to load the game to get the error; it's wrong from the moment you save)

Test procedure: Load your plainest game of Doom (I use doom2.wad). Summon 1 medikit (or more). Walk over it. Pickup fails. Save the game. Walk over it again. You got health. (Stamina-based.)

[Graf Zahl]

(I initially buit from svn because the version on drdteam did not support the latest mapinfo features. So I have r3749 or newer. The executable calls itself r3312.)

Problem found.

You have to make sure that the revision number is correct for savegame versioning. Somwhere between these 2 the saving of stamina was changed so your version creates broken saves.

[FDARI]

I am a little confused. Is the revision number not maintained as part of the project I download from svn? This isn't "my version" beyond the fact that I updated an unmodified working copy to head revision and built the executable.

Edit: Even more uncertain now that I have found svnrevision.h

Code: Select all • Expand view

// 3312
//
// This file was automatically generated by the
// updaterevision tool. Do not edit by hand.

#define SVN_REVISION_STRING "3312"
#define SVN_REVISION_NUMBER 3312

Slightly discouraging instruction there. I have not fully understood this bit, have I? No. But there are builds on drdteam now, so at least I can get what is presumably a bug-free version. Hm... Yeah, maybe my vm doesn't have the prerequisite svn-tools set up. Could be. There was a lot of back and forth at a time, when I really wanted visual c++ 2005 to run on my actual pc without crashing. I would still have enjoyed that.

Edit: Well, clearly I'm not building it right. The drdteam build is bugfree. Then the same goes for this: viewtopic.php?f=2&t=33440

[Edward-san]

Do you run 'svn update' when you update the source code? What output gives it when you run it?

[edit]The ending output should be something like:

Code: Select all • Expand view

Updated to revision 3766.

[Gez]

Before compilation, the updaterevision tool is called to (re)generate svnrevision.h. If you do not use the MSVC++ 2005 project file, make sure that whatever build environment you use does call updaterevision before compiling ZDoom.

[Graf Zahl]

... and this only works if the SVN command line tools are installed. When only using TortoiseSVN this file won't get updated.