PrBoom-Plus, ver. 2.5.1.4

[Revved]

Does anyone else have a problem with PrBoom not having sound in Max OS X Sierra?
Because it seems to be quite a problem with me.

[vdgg]

I fail to understand what happened to me.

I had a recorded .lmp on odessa_3

I typed by mistake

prboom-plus -ile odessa_3 -playdemo odessa3-702

The demo was played back with the correct WAD loaded, and with the music from hrmus.wad ??? What's going on?

[fabian]

By default, prboom+ uses an "extended demo format" which stores a lot of extra information, e.g. the entire command line which it then reconstructs when playing that demo.

[Memfis]

And I think incorrect parameters are simply ignored?

If you have a quite old version (3-4 years old?) there is also the following bug. If you write something like: -warp -skill 4. The "-warp" parameter will read the "4" from the next parameter and so you'll go to level 4 instead of whatever is the first in the wad. But this is unrelated I guess.

I don't know how to explain Hell Revealed music unless you have hrmus as a preloaded wad...

[Bashe]

Seems like this is the appropriate place to ask - is there a way autoload a wad dead last in the loading chain? I created a wad to autoload and change the DSSECRET sound, but as it stands, it gets loaded BEFORE prboom-plus.wad and therefore gets negated since the DSSECRET sound being replaced is in the latter wad. I could always directly modify the sound in the prboom-plus.wad, but I'd rather just have a wad autoload over instead, if that's possible.

[myk]

I think I remember having a similar issue in the past. If all else fails, you could insert the lump in the Prboom-plus wad, at least for the time being.

[Gez]

Bashe said:

Seems like this is the appropriate place to ask - is there a way autoload a wad dead last in the loading chain? I created a wad to autoload and change the DSSECRET sound, but as it stands, it gets loaded BEFORE prboom-plus.wad and therefore gets negated since the DSSECRET sound being replaced is in the latter wad. I could always directly modify the sound in the prboom-plus.wad, but I'd rather just have a wad autoload over instead, if that's possible.

Honestly that sounds like a bug in PrBoom+. The port's own resources should always be loaded first, then IWAD second, anything autoloaded after that, and stuff specifically loaded from command line last.

Any other order doesn't make sense. (I guess you could go IWAD first, then port support data second, if you want the port to override some IWAD stuff; but then you run into possible issues when you use different IWADs, such as Freedoom.)

[fabian]

Bashe said:

Seems like this is the appropriate place to ask - is there a way autoload a wad dead last in the loading chain? I created a wad to autoload and change the DSSECRET sound, but as it stands, it gets loaded BEFORE prboom-plus.wad and therefore gets negated since the DSSECRET sound being replaced is in the latter wad. I could always directly modify the sound in the prboom-plus.wad, but I'd rather just have a wad autoload over instead, if that's possible.

Could you please post your command line and the output to STDOUT so we can see which WAD is loaded in which order?

[Memfis]

[nevermind, I misread something]

[Bashe]

fabian said:

Could you please post your command line and the output to STDOUT so we can see which WAD is loaded in which order?

Sure, this is the STDOUT bit that contains the loading order information.

M_LoadDefaults: Load system defaults.
 default file: G:\Games\Alldooms\PrBoom/prboom-plus.cfg
 found G:\Games\Alldooms\PrBoom/prboom-plus.wad

PrBoom-Plus v2.5.1.4 (http://prboom-plus.sourceforge.net/)
 found G:\Games\AllDooms\iwads\doom2.wad
IWAD found: G:\Games\AllDooms\iwads\doom2.wad
PrBoom-Plus (built Jan 10 2016 17:21:21), playing: DOOM 2: Hell on Earth
PrBoom-Plus is released under the GNU General Public license v2.0.
You are welcome to redistribute it under certain conditions.
It comes with ABSOLUTELY NO WARRANTY. See the file COPYING for details.
V_Init: allocate screens.
V_InitMode: using 32 bit video mode
I_CalculateRes: trying to optimize screen pitch
 test case for pitch=7680 is processed 6048 times for 100 msec
 test case for pitch=7712 is processed 6222 times for 100 msec
 optimized screen pitch is 7712
I_InitScreenResolution: Using resolution 1920x1080
 found G:\Games\Alldooms\PrBoom/secrete.wad
 found G:\Games\Alldooms\PrBoom/prboom-plus.wad
IWAD found: G:\Games\AllDooms\iwads\doom2.wad
D_InitNetGame: Checking for network game.
W_Init: Init WADfiles.
 adding G:\Games\AllDooms\iwads\doom2.wad
 adding G:\Games\Alldooms\PrBoom/secrete.wad
 adding G:\Games\Alldooms\PrBoom/prboom-plus.wad
W_InitCache

secrete.wad, which is intended to replace the sound effect in prboom-plus.wad, is placed in the base PrBoom-plus directory, and autoloaded using the built-in preload feature under the game options. If I run secrete.wad as a PWAD, either using -file or another method, it functions properly.

[CapnClever]

According to the code in m_misc.c, prboom-plus.wad is hardcoded to be loaded last after reading in everything else from the config file:

void M_LoadDefaults (void)
{
  ...
  /* proff 2001/7/1 - added prboom.wad as last entry so it's always loaded and
     doesn't overlap with the cfg settings */
  //e6y: Check on existence of prboom.wad
  if (!(wad_files[MAXLOADFILES-1] = I_FindFile(PACKAGE_TARNAME ".wad", "")))
    I_Error("PrBoom-Plus.wad not found. Can't continue.");
}

So I'd call it a bug.

[jeff-d]

Bashe said:

M_LoadDefaults: Load system defaults.
 default file: G:\Games\Alldooms\PrBoom/prboom-plus.cfg
 found G:\Games\Alldooms\PrBoom/prboom-plus.wad

There you go Fabian, someone has mixed \ and / on the same line.

(For the rest of you this was a conversation we had on the git site for crispy doom)

[fabian]

o_O Yes, indeed.

BTW, I have submitted a patch to Andrey to fix the load order for autoloaded wads.

[VGA]

Can you also submit a patch to make the Enter key open the menu? Like in vanilla and ALL ports?

[fabian]

VGA said:

Can you also submit a patch to make the Enter key open the menu? Like in vanilla and ALL ports?

The code block that is responsible for this in G_Responder() is commented out and marked with "//e6y", so I guess that he had a specific reason to do so.

[Revenant100]

I'm not sure if this counts as a feature request or simply an option I'm missing, but is there any way to make PrBoom+ display the WAD's embedded HELP screen rather than the port's own overriding version? Many PWADs use this lump for their own credit purposes and other helpful doohickeys. An option to switch to the embedded WAD graphic lump would seem appropriate.

Also, I'm aware of at least one WAD whose sole purpose is rather unnecessarily broken by the HELP screen being overridden: DOOM-TV.WAD.

[joe-ilya]

Can I take the screenshots in any other format but BMP?

[VGA]

http://s000.tinyupload.com/index.php?file_id=06096792402934621503

This DEHACKED project makes the weapon animations smoother (adapted from perkristian's stuff improved by others etc)

It works fine in ZDoom, Eternity, Doom Retro. The Chaingun is glitched in prboom+
Maybe it has to do with the flash frames(?), I disabled those completely, though.

EDIT: I replaced the two flash frames CHGFA0 and CHGFB0 with empty image and it wasn't fixed, so maybe it doesn't have to do with those frames.

[bonnie]

Do you have a version without the chaingun in it because I need that in my prboom+ life right now

[scifista42]

The FireChaingun codepointer has special hardcoded behavior regarding flash states. Unless you are aware of this special behavior and exploit it somehow, you should use the FirePistol codepointer instead, because that one is safe.

[VGA]

scifista42 said:

The FireChaingun codepointer has special hardcoded behavior regarding flash states. Unless you are aware of this special behavior and exploit it somehow, you should use the FirePistol codepointer instead, because that one is safe.

You are correct, this is one solution, thanks.

But do you have any specific info about the specific behaviour of FireCGun? Maybe there is another workaround, too.

Also, the other source ports don't show this weirdness, hmmm.

[scifista42]

It's a vanilla thing, that's why classic source ports keep it while advanced source ports fix it, as usual (some vanilla DEHACKED mods might depend on the behavior working like it does in vanilla). Here is the respective part of the vanilla source code that's responsible for the pistol's muzzle flash behavior:

    P_SetPsprite (player,
		  ps_flash,
		  weaponinfo[player->readyweapon].flashstate);

And here is the chaingun's one:

    P_SetPsprite (player,
		  ps_flash,
		  weaponinfo[player->readyweapon].flashstate
		  + psp->state
		  - &states[S_CHAIN1] );

Where "psp->state" is the current state's number, and "&states[S_CHAIN1]" is the number of the state on which the vanilla chaingun has its first firing frame. (Actually, they aren't numbers, but plain memory addresses referring to positions in an array of states, but the effect is the same.) So, the chaingun's muzzle flash animation jumps into a state that corresponds to the current state shifted by the constant difference between the custom chaingun's muzzle flash state and the original chaingun's first firing state. In practice, it causes the muzzle flash to alternate between its frames exactly in sync with the firing animation that alternates between its own frames. Exploiting this behavior on a custom weapon would require to carefully plan the positions of states that call A_FireCGun as well as positions of the muzzle flash states as well as the position of the first muzzle flash state defined in the weapon's properties.

[vita]

Hi, I can't run 2.5.1.5.test r4498 (I want SDL2 version because SDL 1.x is obsolete and I'm not used to its mouse sensitivity, it's higher) compiled with MinGW/MSYS (i686 toolchain) for some reason. It doesn't even leave stdout.txt, just shuts down instantly.

[Bunkdoom]

Since i have not yet managed to get the most recent version of prboom+ running, is there a place where downloadable wads are sorted by engine and ...

...

I want to test some wads. Can i get more savegame slots in prboom+ ?

[scifista42]

Bunkdoom said:

Can i get more savegame slots in prboom+ ?

Each savegame is being stored in a separate file in PrBoom-plus's folder, each file named "prboom-plus-savegame*.dsg", where "*" is the number of the savegame. You can rename these files to unique names so that PrBoom-plus will no longer recognize them as its own savegames, which makes room for making new savegames in the game without overwriting the old ones. If you need to reload a savegame, find the respective file and rename it back to a format that PrBoom-plus recognizes, so that you can load it in the game.

[Bunkdoom]

scifista42 said:

Each savegame is being stored in a separate file in PrBoom-plus's folder, each file named "prboom-plus-savegame*.dsg", where "*" is the number of the savegame. You can rename these files to unique names so that PrBoom-plus will no longer recognize them as its own savegames, which makes room for making new savegames in the game without overwriting the old ones. If you need to reload a savegame, find the respective file and rename it back to a format that PrBoom-plus recognizes, so that you can load it in the game.

Thanks, mate. I will do so then.

[CapnClever]

You can also use the "-save" parameter to assign a different directory. Note that the folder won't automatically be created, so add it ahead of time. Using this method you can organize saves however you want using folder names instead of file names.

[Bunkdoom]

CapnClever said:

You can also use the "-save" parameter to assign a different directory. Note that the folder won't automatically be created, so add it ahead of time. Using this method you can organize saves however you want using folder names instead of file names.

How does that work ? In the commandline ?

[scifista42]

Yes.

[Bunkdoom]

scifista42 said:

Yes.

How would it work ?
prboom-plus -file -save ... ... freudslp.wad ?