Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
shotgunmasacre2

Help with prboom 2.3.1

Recommended Posts

Well, i want to watch demos in prboom ver. 2.3.1, but when I try to drag a wad( such as av) I get this notice that says that it cant locate an iwad, even though I dumped a copy of doom2's iwad in it. The collectors edition of doom works for all my other exe.'s (zdoom, legacy) but I cant get it to work with this version of prboom.

Share this post


Link to post

Plz dont use 2.3.1, use 2.2.6, because a) it works better, and b) most people are more knowledgeable about 2.2.6.

Also, drag + drop is, in my experience, a rather poor way of loading wads. Just use the command line.

Share this post


Link to post

Note that prboom-plus fixes a number of bugs in prboom and adds new features (including new complevels and overflow emulation), meaning amongst other things that it will play back a number of demos that the regular prboom will not.

But 2.3.1 should be just as good as the regular 2.2.6 for watching demos (though not as good as -plus). It sounds from what you say like you just need to make sure you really have copied your iwads to wherever you've put prboom 2.3.1, or else to specify an iwad (including the path) in your command line.

The big problem with 2.3.1 from a demo viewpoint is that it doesn't let you record. :/

Share this post


Link to post

So what you are telling me is that I should use prboom plus? Alright, I will give it a shot. The only problem I have is that boom doesnt support mouselook so I want to record demos on it but I would like there to be mouselook. That is why i play all of my wads on zdoom( but I dont jump to cheat ;)), although I dont know how to record a demo on zdoom.

Share this post


Link to post

Basically yes. It can do everything the regular 2.2.6 can (except, as I understand, compile outside Windows), but with fixes and extra options.

Prboom-plus has mouselook as an option if you use its OpenGL version (i.e. glboom.exe rather than prboom.exe). You can use this when recording, without loss of compatibility. (Though if you release a demo where you have used mlook, it would make sense to mention this in the txt, as it does mean that you have been able to see things that you wouldn't otherwise have been able to.)

Note that in order to record, you'll have to use a command line (or batch file) - dragging and dropping is (generally) fine for playing or watching, but can't provide the exe with all the info it needs to start a recording.

Share this post


Link to post

Alright, so it has mouselook. But when I use mouselook I have autorun enabled, and I cant seem to find it. It may seem stupid to ask you this, but where can I find the option to autorun all the time.

Share this post


Link to post

Press Caps Lock. Once you have done this, it is saved in the cfg file, so autorun will be automatically set the next time you start the program.

Alternatively, open up glboom.cfg in Notepad, find the line that says "autorun", change the value to 1, and save.

To change the key bindings in-game, go to: Options - Set Up - Key Bindings

Many of the new options can be set in: Options - Set Up - Status Bar/HUD (screens 2, 3 and 4 - use the arrow keys to navigate between them)

Share this post


Link to post

I'm pretty sure even Proff has abandoned the experimental (2.3.x/2.4.0) branch. This is from his svn repository changelog

r1325 | proff_fs | 2006-01-23 14:29:13 +0000 (Mon, 23 Jan 2006) | 1 line
Changed paths:
   A /trunk/prboom2 (from /branches/prboom_stable_2_2:1324)

Latest stable 2.2.x version as new trunk.
and
r1323 | proff_fs | 2006-01-23 14:26:06 +0000 (Mon, 23 Jan 2006) | 1 line
Changed paths:
   A /branches/historical/aborted-prboom-24 (from /trunk/prboom2:1322)
   D /trunk/prboom2

Moved trunk into historical.
That's basically saying the stable branch is back to being the main one, and the experimental branch is now called "historical/aborted-prboom-24" - I think the intention is pretty clear.

Share this post


Link to post

I wonder why they add those mysterious notes that with any luck some other coder or fan will find by chance, yet leave that dead version on the front of the project page without any explanations and on the download page as if it were useful (eventually causing confusion for users, especially new ones.) I thought proff had quit PrBoom's development, anyway.

Share this post


Link to post

From: Florian Schulze
To: Andrey Budko
Date: 11.02.2006 16:19
Subject: PrBoom+
I would like to work with you on integrating the fixes you made in PrBoom+ into PrBoom. I only want to leave out the "cheating" stuff, at least for now. I created a branch for PrBoom+ in our repository to make the merging easier. Colins and my plan is to get out a fixed 2.2.7 and work on a new 2.4 line. PrBoom 2.4 will be started from 2.2.x and all the really good stuff from 2.3 will be added, like better demo compatibility, better build system, the new software renderer, the dynamic OpenGL loading, but not fragglescript, the console and some other stuff. We want to add that stuff gradually. 2.3 had too many changes and has too many bugs, that's why we want to combine the best of both worlds.

I've sent a patch to Florian Schulze. It contains following bugfixes:

2.2.6.26
[-] PrBoom bug: bug in MBF compatibility mode (version number written wrongly in lmp header when recording).
[-] PrBoom bug: translucency via dehacked/bex doesn't work.
[-] PrBoom bug: DEH files preloaded in wrong order.
[-] PrBoom bug: "Tagged doors don't trigger special lighting" handled wrongly.
[-] prboom-server bug: -1 => 255 instead of maxcompat

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.
[-] Crash with zero-length sounds.
[-] 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.

2.2.6.24
[-] Translucency won't change until you restart the engine.

2.2.6.23
[+] Dehacked support: Monsters infight.

2.2.6.22
[+] PrBoom compatibility: two new options for spechit overflow detection. It detects desyncs like compet-n\hr.wad\hr18*.lmp, all strain.wad\map07 demos etc.
[-] PrBoom dehacked support: wrong processing of Bits parameter if its value is equal to zero. No more desync on HACX demos.
// [-] PrBoom compatibility: PRBoom doesn't spawn the boom-specific "specials" in demo_compatibility mode now (generalized scrollers, sector effects). No more desync on umbrella.wad\um3nm152.lmp.
[-] PrBoom compatibility: MF_JUSTHIT fix. No more desync on Sam Woodman's HMP Max demos (HX17-459.LMP etc).
[-] PrBoom: fix for turn-snapping bug on fullscreen in software mode. "..\Advanced HUD settings\Movements\Fix Turn-Snapping issue"
[-] PrBoom: deathmatch starts as unknown things with a complevel of 0, 1, 2 or 3.
[-] GlBoom: problems with transfering not flipped sky texture (line type 271) to tagged sectors. On war_3.wad\map14 for example.

Share this post


Link to post

That's good news.

I would have thought that this was a very critical bug to fix in the official branch (perhaps the most important of all from a recording viewpoint):

2.2.6.11
[-] PRBoom issues: prboom uses monster_avoid_hazards setting from the cfg file when you are using -complevel 0 or -complevel 1. If you have this option set to 1 in your cfg, then you are at risk of getting desyncs in demos that feature crushers. (Dashiva)

And these would certainly be nice (and in keeping with the changes from newer versions that you list as being included in the patch):

2.2.6.20
[+] GLBoom: "Smart Items Clipping" setting.

2.2.6.19
[+] Support up to 65536 sidedefs instead of 32768.

2.2.6.9
[-] Bugs in the new algorithm of middle textures drawing.

2.2.6.8
[-] GLBoom bug: wrong display of a middle texture if it exceeds the boundaries of its floor and ceiling.

Share this post


Link to post

entryway, didn't you ever also fix the bug where all the players appear green in MultiPlayer? (Unless that's somehow a side effect of another bug fixed.)

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
×