RazTK Posted December 31, 2005 I got this error while playing Doom2 game on LAN: G_Ticker: Consistency failure (0 should be -4766) 0 Share this post Link to post
myk Posted December 31, 2005 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.) 0 Share this post Link to post
RazTK Posted December 31, 2005 Yes, I tried to record a demo, I didn't know all the players should record the game. 0 Share this post Link to post
ich666 Posted December 31, 2005 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. 0 Share this post Link to post
myk Posted December 31, 2005 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. 0 Share this post Link to post
entryway Posted January 2, 2006 ich666 said:Since Version 2.2.6.23 is a bug with DEH-files in BEX-Format.thx 0 Share this post Link to post
Andy Olivera Posted January 4, 2006 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++; } 0 Share this post Link to post
entryway Posted January 4, 2006 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 0 Share this post Link to post
Andy Olivera Posted January 4, 2006 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. 0 Share this post Link to post
entryway Posted January 4, 2006 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 0 Share this post Link to post
Andy Olivera Posted January 5, 2006 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. 0 Share this post Link to post
entryway Posted January 7, 2006 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. 0 Share this post Link to post
Grazza Posted January 8, 2006 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. 0 Share this post Link to post
Iori Branford Posted January 8, 2006 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. 0 Share this post Link to post
entryway Posted January 8, 2006 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 0 Share this post Link to post
Grazza Posted January 8, 2006 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? 0 Share this post Link to post
Iori Branford Posted January 10, 2006 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. 0 Share this post Link to post
Grazza Posted January 10, 2006 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. 0 Share this post Link to post
Belial Posted January 11, 2006 The final map of WOT Doom gives me a V_DrawMemPatch error in prboom. Doesn't happen with glboom. 0 Share this post Link to post
entryway Posted January 11, 2006 Belial said:WOT Doom givesWhere can I find it? 0 Share this post Link to post
Belial Posted January 11, 2006 http://www.doomworld.com/idgames/index.php?id=14032 0 Share this post Link to post
Grazza Posted January 11, 2006 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.) 0 Share this post Link to post
Belial Posted January 11, 2006 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'. 0 Share this post Link to post
entryway Posted January 11, 2006 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 0 Share this post Link to post
Belial Posted January 11, 2006 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. 0 Share this post Link to post
Quasar Posted January 11, 2006 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. 0 Share this post Link to post
Graf Zahl Posted January 11, 2006 But Doom really liked to do it for the most trivial reasons. Anyone remember the E3M1 crash? 0 Share this post Link to post