PrBoom-Plus, ver. 2.5.1.4

I got this error while playing Doom2 game on LAN: G_Ticker: Consistency failure (0 should be -4766)

Share this post


Link to post

RazTK said:
G_Ticker: Consistency failure (0 should be -4766)

Don't add anything to the client command lines except -net and (if necessary) -iwad. Make sure the server and all the clients have any PWADs used in their own directory, and force the server to define the config file, which should be in the server's directory. Also, make sure there are no differences in any of the wads accessed by any of the programs, and that all the clients are of the latest version of PrBoom+.

The only time I remember getting a consistency failure yesterday was because we were using Doom2 compatibility and one client was recording while the other wasn't (thus movements are different.)

Share this post


Link to post

Yes, I tried to record a demo, I didn't know all the players should record the game.

Share this post


Link to post

Hi,

first, sorry for my bad english.

Since Version 2.2.6.23 is a bug with DEH-files in BEX-Format. The [STRING]-section from the BEX-file is misinterpret. The bug is in the source "src\d_deh.c" in function "deh_GetData". The problem is the following code:

----------- CODE -----------
if (!StrToInt(t,&val))
{
val = 0;
okrc = FALSE;
}
----------- END CODE -------

The variable "okrc" shouldn't set to false in this case.

I use always this feature for correct levelnames in the map on every PWAD.

Share this post


Link to post

A small request; an option, through a server command line switch, to turn off PrBoom+'s gamespeed change feature. It's kind of annoying to have your opponent change the game speed on you in the middle of a match. That makes the engine much less useful in a relatively competitive environment.

Share this post


Link to post
ich666 said:

Since Version 2.2.6.23 is a bug with DEH-files in BEX-Format.

thx

Share this post


Link to post

I don't know if anyone was actually looking to fix this, but I found it, anyway. The six frame jump that occures whenever the speed is changed can be fixed at lower speeds as follows...

d_client.c / NetUpdate()
while (newtics--)
{
I_StartTic();
if (maketic - gametic > BACKUPTICS/2 && realtic_clock_rate > 200) break;
else if (maketic - gametic) break;
G_BuildTiccmd(&localcmds[maketic%BACKUPTICS]);
maketic++;
}

Share this post


Link to post
Andy Olivera said:

if (maketic - gametic > BACKUPTICS/2 && realtic_clock_rate > 200) break;
else if (maketic - gametic) break;

It is not correct because in this case PRBoom will work without backuping of tics

Share this post


Link to post
entryway said:

It is not correct because in this case PRBoom will work without backuping of tics

Try setting realtic_clock_rate to 1000. It won't allow that kind of speed with BACKUPTICS disabled. Of course if being able to fast-forward isn't a requirement it won't make a difference.

Share this post


Link to post
Andy Olivera said:

Try setting realtic_clock_rate to 1000. It won't allow that kind of speed with BACKUPTICS disabled. Of course if being able to fast-forward isn't a requirement it won't make a difference.

As far as I understand it, your code will work badly on slow computers or heavy levels if I'll play with a speed by default

Share this post


Link to post
entryway said:

As far as I understand it, your code will work badly on slow computers or heavy levels

That's true, as it's essentially putting the game into "timedemo" mode(draw every frame, even if fps drops below 35), but it does fix the problem, so I figured I'd post it anyway.

Share this post


Link to post

http://www.geocities.com/e6y/doom.html
http://sourceforge.net/projects/prboom-plus/

2.2.6.25

[+] PrBoom compatibility: two new options for detection of overflow of "REJECT". It's emulated successfully if the size of overflow no more than 16 bytes. No more desync on teeth-32.wad\teeth-32.lmp.
[+] Compatibility with common mapping errors: "Linedefs w/o tags apply locally". If a linedef type that normally requires a tag (e.g. a remote door) has no tag, then if possible apply the linedef's action to the local sector. Not available for recording, playback or with demo_compatibility.
[+] Compatibility with common mapping errors: "Use passes thru all special lines". Boom's passthru flag is applied to all special lines. This makes it possible, for instance, to press switches that have been placed behind special lines such as scrolling textures. Not available for recording, playback or with demo_compatibility.
[+] Compatibility with various early Doom versions and ports (overriding autodetect, if used for playback):

Doom & Doom2, v1.666 : -complevel 1
Doom2 doom2.exe v1.9 : -complevel 2
  ;No more desync on uac_dead.wad\uac_dead.lmp.
Ultimate Doom v1.9   : -complevel 3
Final Doom doom2.exe : -complevel 4
DosDoom              : -complevel 5
TasDoom              : -complevel 6
  ;No more desync on demos from old TAS site
  ;And some of Andy Olivera's demos.
[!] Network game works again.
[!] Allowing to mouselook during recording.
[!] Interdiction of change of game speed during network game.
[!] PrBoom+ will not show the advanced statistical information (Smart Totals) in deathmatch.
[!] If file already exists, don't try to continue existing demo with demo_compatibility.
[-] Crash with zero-length sounds.
[-] Bug with DEH-files in BEX-Format (2.2.6.23)
[-] Smooth movement: elevators were not interpolated. Sector #137 @ dmdjm02.wad for example.
[-] Boom dehacked support: wrong processing of Max Health. A new compatibility option has been added so that it applies only to health potions. Highly relevant to wads such as Hacx, Wotdoom3, Anadream, and any others that change this setting.
[-] Issue with dehacked floating monsters in glboom.exe if "Smart Items Clipping" is turned on (2.2.6.20)

The updated version of usage.txt also is included.

Share this post


Link to post

Demo recorders please note: the complevels have changed!

I'll make a post about it once I have the full and correct information myself.

But this new release is great news for demo fans (and general users too, of course). It seems it will play back almost anything recorded with one of the traditional engines. The only desyncs I've found are in a handful of Dosdoom/Tasdoom demos with memory overflows (not surprising, as the emulation of overflows is specifically for Doom2.exe).

Port programmers may wish to note the amended dehacked support for Max Health, and consider if and how they wish to support the original dehacked interpretation of this feature. The Boom behaviour impacts some Doom2.exe wads, but a straight fix (without compat option) might impact wads designed to work with Boom (I say "might", because not many wads appear to use this dehacked option). Some info here.

Share this post


Link to post

Two bugs:

In fullscreen mode, both software and OpenGL, each screen flash causes a quarter-second hiccup.

MIDI music not playing, either because it was ditched in favor of MP3 support or it selects the wrong MIDI driver to use. I have SBLive Synth A, Synth B, and the Wingroove wavetable emulator, but PrBoom may be trying to use the Microsoft Wavetable Synth belonging to the onboard soundcard I'm not using.

Share this post


Link to post
Iori Branford said:

In fullscreen mode, both software and OpenGL, each screen flash causes a quarter-second hiccup.

I don't understand.

MIDI music not playing, either because it was ditched in favor of MP3 support or it selects the wrong MIDI driver to use. I have SBLive Synth A, Synth B, and the Wingroove wavetable emulator, but PrBoom may be trying to use the Microsoft Wavetable Synth belonging to the onboard soundcard I'm not using.

It is your problem or a problem of the SDL_mixer.dll
It can be necessary for you to change the Default Device for MIDI music playback in the Control Panel\Sound and Audio Devices

Share this post


Link to post

Iori: did you copy sdl.dll, sdl_mixer.dll and sdl_net.dll from the zip into the directory where you've put glboom.exe and prboom.exe?

Share this post


Link to post
entryway said:

I don't understand.

The game paused for a second whenever the screen flashed due to item pickup or damage or whatever. Never mind, it mysteriously fixed itself today.

entryway said:

It can be necessary for you to change the Default Device for MIDI music playback in the Control Panel\Sound and Audio Devices

Tried them all, same results.

Grazza said:

Iori: did you copy sdl.dll, sdl_mixer.dll and sdl_net.dll from the zip into the directory where you've put glboom.exe and prboom.exe?

They're all there and up to date.

Share this post


Link to post
Iori Branford said:

They're all there.

What I was getting at is that you might have old versions. Did you extract the ones from the zip and overwrite any older versions that were there?

As for the erratic performance, this might be because of other programs that are running at the same time. I used to find that some older versions of prboom would perform badly when Windows Explorer was running at the same time (that problem has now gone - not sure what specific change led to that). It's not inconceivable that there might be other such issues. It seems that certain pairs of programs just don't "get along" sometimes.

Share this post


Link to post

The final map of WOT Doom gives me a V_DrawMemPatch error in prboom. Doesn't happen with glboom.

Share this post


Link to post

Whereabouts? Right at the start or at some point in the map?

There is a spechits overflow in this map (heh, this wad has everything :p ), so if you have the warning turned on, it might be that popping up on screen that is causing a problem. (Though for me, it seems OK.)

Share this post


Link to post

Well apparently it's not the map that's causing the error, it happens on the intermission screen when I try to skip it or when it gets to the 'eye of the world' part.

Didn't run into the overflow. I have all relevant options set to 'yes'.

Share this post


Link to post

Try to record a demo:
prboom.exe -file Wt_main.wad Wt_sp-ft.wad -deh Wotdoom3.deh -complevel 2 -warp 7 -record bug -nomonsters
And put here the full text of error message

Share this post


Link to post

It doesn't happen on map07. It happens in the intermission text between map06 and map07. Zip contains demo and the saved game from which I recorded.

http://rapidshare.de/files/10852307/bug.zip.html

bug:

V_DrawMemPatch: Patch (317,65)-(325,72) exceeds LFBBad
V_DrawMemPatch (flags=4)

Edit: And removing the text from the deh patch stops the bug from appearing.

Share this post


Link to post

Sounds like a screen patch is just extending off the right hand side of the screen. This is not an error that prboom should exit on, however. It should be modified to either clip patches to the screen like Eternity does now, or at least simply ignore the problem by not drawing the patch.

If catching patch positioning errors during development is an issue, I suggest using #ifdef RANGECHECK blocks or writing a message to a debug log. Anything's better than kicking the user out, anyways.

Share this post


Link to post

But Doom really liked to do it for the most trivial reasons. Anyone remember the E3M1 crash?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now