emailking

Took all day, but I just installed hundreds of windows updates and something did it because it works now. So I'm good.

Ok I tried it. It made no difference. I get the exact same error message. (I guess all that what I did really proves is that whatever is going wrong, it goes wrong after fluidsynth loads.) Any ideas?

Hi, entryway. Thanks for responding to my post. I tried the version you just posted. Unfortunately, it did not work. I got the same error message. Here is a screenshot of the error message: http://oi49.tinypic.com/ekpxxt.jpg I think it may have something to do with libfluidsynth.dll. If I delete all of the other DLLs and leave libfluidsynth.dll, I get the same error message. But if I delete libfluidsynth.dll, it jsut says that it couldn't find libfluidsynth.dll. I have also tried versions 2.5.1.0, 2.5.1.1, 2.5.1.3, and 2.5.1.4 test. All of them get the exact same error message that is in the screenshot above. 2.5.0.8 is the most recent version that runs.

I can't get this to run on a windox xp laptop I just bought. (includes both glboom-plus and prboom-plus) 2.5.1.0, 2.5.1.1, 2.5.1.3, and 2.5.1.4 test do not launch. Not even the launcher will run. I just get an error that the application failed to initialize and then a memory address. Going back, 2.5.0.8 is the first version that launches, and it appears to work properly. All versions of prboom-plus launch and run on my old win xp machine (that is much slower and has a small screen so I don't want to use it). Any ideas? I'm hoping there's a solution because I bought this laptop specifically to watch doom demos. I went with xp because in the last few months, prboom-plus kept giving a blue screen of death randomly on my windows 7 machine, forcing me to do a lengthy system restore to get the machine working again. I finally wiped the machine and tried running with it bare (no programs installed, no windows updates, etc.) and I had the same problem. I figured it must be a machine specific problem since no one else seems to have this issue. So I decided just to buy a win xp machine for doom, since it was cheap and I figured that would have no problems.

The way it reads, there is certainly nothing to imply that any monster must be dead at the exit. However the way it reads is apparently not what the writer of those words meant by them, nor is it the way most people have played max/fast/tyson. With the exception of certain difficult/impossible to reach monsters, all monsters (save lost souls) that are present at the beginning of the level must be dead at the end.

Thank you for the responses. To be honest, I don't really understand the explanation. Is what you're saying that the game state is updated 35 times a second, but the hud is calculated 1000 times a second (including every 0.01 seconds), and so there is a remainder problem...because 35 does not divide evenly into 100? I can see how that would make a mismatch. I still don't understand why the display time at the exit can be different from one run to the next, when using the prboom-plus executable. Why is that not repeatable? Ok separate question. I used the launcher to set the registry to call glboom-plus and use -auto when I double click a demo. If I double click a demo that's in my doom directory, it uses timidity like I want it to. But if I double click a demo in a zip file, it doesn't use timidity and I have to suffer the pause every time the music loops. I assume it has something to do with the active directory. Is there a way I can fix this? Many thanks.

I noticed something odd when I played blob1024's max run of map 22 of community chest 3. He hit the exit at 3:50.97, but the final time came up as 3:51 on the stats screen. I was able to reproduce this repeatedly. I had been using glboom-plus. Then I tried with prboom-plus, and the results became even more bizarre. Half the time he hits the exit at 3:50.97 and half the time at 3:51.00. It is seemingly random which number it is. Regardless, the time on the stats screen is always 3:51. I tried to replicate this 50/50 behavior in glboom-plus but couldn't. When I use glboom-plus, he *always* hits the exist at 3:50.97 (stats screen always says 3:51 though) and never at 3:51.00. Here are the exact command lines I was using to test. glboom-plus -file cchest3.wad -playdemo cch3-22-3-51 -skipsec -12 prboom-plus -file cchest3.wad -playdemo cch3-22-3-51 -skipsec -12 Is there an explanation for this? Here is the link to the post with the demo: http://www.doomworld.com/vb/showthread.php?postid=962071#post962071

Apologies for the possibly dumb question, but is the music supposed to change from map01's music to map31's music when you cross the farthestmost set of columns? Because that happens to me every time.

Our cc2_m24fs have the same size but are actually different binary files according to winmerge. I do not desynch when I use yours. I don't know how I have the "wrong" fix wad (which does fix the door that won't open) but apparently there's a secret door that won't open in mine but does in yours. I said it desynched at 29:45 because I thought a Mancubus was out of place and caused the obvious desynching 20 sec later, but apparently you just missed it. ;) But anyway, problem solved. Thanks! :)

The HMP one desyncs for me too. (Haven't figured out where, bu 40 seconds before it's supposed to be over the marine is wandering aimlessly near the start.) We match on cchest2.wad. What's the bytage on your fix wad? Maybe that's different somehow. I have 2406553. I only used the 2505 executable but the next thing I'll try will be a clean install from the zip in a separate directory. Maybe some other DLL is the problem.

Thank you for the demos. This is my favorite cc map. Does the uv demo desync for you when you play it back? For me it desynchs around 29:45. Here's the command line I used: glboom-plus -iwad doom2.wad -file cchest2.wad cc2_m24f.wad -playdemo c224-uv I checked and it does detect complevel 9. I'm using the test version of prboom+. I also tried with 2.5.0.5 which the text says you recorded with. Same deal. Forcing complevel 9 doesn't change anything. Did I miss something?

So it's a COLORMAP then? I wonder why the author did that.

It can't be that because if I go to level 2 (just the normal Underhalls) and use invuln there it looks *very* different from what I get if I use invuln on level 2 with just the iwad and no longdays loaded. Here are pics showing the difference. normal: http://i50.tinypic.com/142fx2t.jpg longdays loaded: http://i46.tinypic.com/20glfh0.jpg

Excuse the ignorance here, but I was wondering why does the invulnerability look so different on this wad (longdays)? Like...it looks more as though everything turned black and white, whereas with invulnerability it normally looks like light and dark reverse.

Got it. Thanks.