PrBoom-Plus, ver. 2.5.1.4

[Ribbiks]

TimeOfDeath said:

Were you able to exit map40 and get an intermission screen and go to map41? What about after beating map30 and it goes to the monster types screen?

yah, it works perfectly, provided you have the CWILVxx lumps that are needed (cwilv39 and cwilv40, in the 40-->41 case) :). after beating map30 it still goes to the ending screen, so I guess in that sense you couldn't really make a contiguous 100-map megawad or whatever.

the reason I was thinking about it was for SF3 where there's potentially >35 maps and some of them are very "secret map" material, so it would've been nice to have more 31+ mapslots.

if this gets implemented I'll make a one-man hundred-map megawad, promise :D

[Rayziik]

Could you potentially make it so that a secret exit switch triggered on MAP30 will transport the player to MAP33 or whichever slot desired? I could see that as a way to bypass the cast sequence at the end.

[Revved]

Ok, so I just upgraded my Max OS X Sierra and for some reason I can't get the sound to work.
Looking at the console, I get this error:
I_InitSound: couldn't open audio with desired format (Failed to start CoreAudio: AudioUnitSetProperty (kAudioUnitProperty_SetInputCallback)))
Anyone wanna help me out on this?

[vita]

I'm trying to compile 2.5.1.4 with MSYS (Windows 7 32-bit), but I get this in stdout.txt:

Spoiler

M_LoadDefaults: Load system defaults.
 default file: D:\DIR\Programs\MinGW\prboom-plus-2.5.1.4-src\build/prboom-plus.cfg
 found D:\DIR\Programs\MinGW\prboom-plus-2.5.1.4-src\build/prboom-plus.wad

PrBoom-Plus v2.5.1.4 (http://prboom-plus.sourceforge.net/)
 found D:/DIR/DOOM/WADs/doom2.wad
IWAD found: D:/DIR/DOOM/WADs/doom2.wad
PrBoom-Plus (built Oct 30 2016 12:49:08), 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 8 bit video mode
I_CalculateRes: trying to optimize screen pitch
 test case for pitch=640 is processed 14189 times for 100 msec
 test case for pitch=672 is processed 23214 times for 100 msec
 optimized screen pitch is 672
I_InitScreenResolution: Using resolution 640x480
 found D:\DIR\Programs\MinGW\prboom-plus-2.5.1.4-src\build/prboom-plus.wad
D_InitNetGame: Checking for network game.
W_Init: Init WADfiles.
 adding D:/DIR/DOOM/WADs/doom2.wad
 adding D:\DIR\Programs\MinGW\prboom-plus-2.5.1.4-src\build/prboom-plus.wad
W_InitCache

M_Init: Init miscellaneous info.
SetRatio: width/height parameters 640x480
SetRatio: storage aspect ratio 4:3
SetRatio: assuming square pixels
SetRatio: display aspect ratio 4:3
SetRatio: gl_ratio 1.600000
SetRatio: multiplier 1/1
R_Init: Init DOOM refresh daemon - 
R_LoadTrigTables: Endianness...ok.
R_InitData: Textures Flats Sprites 
R_Init: R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables R_InitPatches 
P_Init: Init Playloop state.
R_TextureNumForName: The file D:/DIR/DOOM/WADs/doom2.wad seems to be incompatible with "DOOM 2: Hell on Earth".
R_TextureNumForName: AV3 not found

What should I do to get rid of this problem? My doom2.wad is correct.

[fabian]

Which toolchain do you use, i686 or x86_64?

Also, which command line did you use to start the game?

[vita]

fabian: I use i686-pc-mingw32 toolchain. I used "prboom-plus -iwad doom2" to start the game (obviously, I've also set DOOMWADDIR env. variable to D:/DIR/DOOM/WADs).

[Danfun64]

has your doom2.wad been modified in any way...or has it not been modified enough (patched to 1.9)?

You might want to check if your doom2.wad matches the details of 1.9 of this using this. If it doesn't match 1.9 but matches one of the other versions, you should upgrade to 1.9 using one of the patches from here.

edit: fixed incomplete link formatting.

[vita]

Danfun64: it hasn't, I use original 1.9.

Edit: prboom-plus complains about AV3 lump if I use tnt, plutonia or doomu, too.

[fabian]

Do you build the released source code or a SVN checkout? I'll try to reproduce your issue during this week.

[vita]

I downloaded the source from here.

[fabian]

I can confirm the issue you experience. It happens. because the animdef_t struct isn't properly packed. This has been fixed in SVN r4492, so you might want to backport this. Alterantively, change the definition of PACKEDATTR to "__attribute__((packed,gcc_struct))", i.e. add the "gcc_struct" part. This should fix your build.

[vita]

Works just fine now, thanks!

[VGA]

https://www.doomworld.com/vb/wads-mods/84984-ludicrium-on-idgames-so-i-tried-to-create-some-slaughter-maps/

Why does MAP05 of that crash when the Pain Elemental tries to shoot? The error is something like PlaySoundAtVolume : Bad sfx #0

There is some DEHACKED fuckery that makes the PE spawn other PEs and stuff like that, so that's the root of the problem I guess.

It works on ZDoom.

[scifista42]

The problem is that the monster has Attack Sound set to "-" (no sound), which (in case of Lost Soul and/or PE attacks) crashes even the vanilla engine.

[VGA]

scifista42 said:

The problem is that the monster has Attack Sound set to "-" (no sound), which (in case of Lost Soul and/or PE attacks) crashes even the vanilla engine.

Well, it doesn't crash ZDoom, Doom Retro or Eternity, so I hope the crash gets fixed in prboom+

[fabian]

This even crashes MBF. The fix is trivial, though: Return gracefully from S_StartSound() if (sfx_id == sfx_None).

[VGA]

Why are you saying that this "even" crashes vanilla and "even" crashes MBF? These are buggy as fuck and ancient lmao

Does this crash even DosDoom? I didn't try :D

[scifista42]

VGA said:

Why are you saying that this "even" crashes vanilla and "even" crashes MBF?

To let you know that this bug isn't specific to PrBoom-plus only.

[vita]

In vanilla with Doom mouse spinner you can't get S50 while turning if you press turn180 key, you'd get something like this (looking at the demo in XDRE):
tic 20: MF50 SL50
tic 21: MF50 SR50 (turn180 pressed)
tic 22: MF50 SL50.

In PrBoom-Plus, you can:
tic 20: MF50 SL50
tic 21: MF50 SL50 TR128
tic 22: MF50 SL50.

[DOOMGABR[RU]]

Help me with this stupid error please. PrBoom 2.1.1, Software Rendering, Win10Pro x64
Error appears in my wad (download: https://www.mediafire.com/?0pb6do92zzzl2sb). Please reply without slang. I'm using Google Translate.

[vita]

No error for me in 2.5.1.4 or latest 2.5.1.5.test.

Spoiler

Нет ошибки в 2.5.1.4 или 2.5.1.5.test.

Edit: well, I didn't know where's the error

[DOOMGABR[RU]]

38_ViTa_38 said:

No error for me in 2.5.1.4 or latest 2.5.1.5.test.

Spoiler

Нет ошибки в 2.5.1.4 или 2.5.1.5.test.

I found problem. Proplem in sky image (it was in *.png format) :D

[Quagsire]

I got an error:

I_SignalHandler: Exiting on signal: signal 11

[scifista42]

Which wad did you play and when exactly did the error occur?

[Quagsire]

scifista42 said:

Which wad did you play and when exactly did the error occur?

It happened in vanilla Doom (without wads or mods) but I got it fixed by updating.

[BigDickBzzrak]

I've been hacking around with DeHackEd recently, and one of those hacks made PrBoom+ crash.
So, paste this in a BEX file (plain DEH might work, too):

Spoiler

Patch File for DeHackEd v3.0
# Created with WhackEd4 1.1.2 BETA
# Note: Use the pound sign ('#') to start comment lines.

Doom version = 21
Patch format = 6


Thing 35 (Plasma projectile)
Initial frame = 99
Alert sound = 16
Death frame = 0

Frame 174
Sprite number = 28

Frame 175
Sprite number = 28

Frame 176
Sprite number = 28

Frame 177
Sprite number = 28

Frame 178
Sprite number = 28

Frame 179
Sprite number = 28

Frame 180
Sprite number = 28

Frame 181
Sprite number = 28

Frame 182
Sprite number = 28

Frame 183
Sprite number = 28

Frame 184
Sprite number = 28

Frame 185
Sprite number = 28

Frame 186
Sprite number = 28

Frame 187
Sprite number = 28

Frame 188
Sprite number = 28

Frame 189
Sprite number = 28

Frame 190
Sprite number = 28

Frame 191
Sprite number = 28

Frame 192
Sprite number = 28

Frame 193
Sprite number = 28

Frame 194
Sprite number = 28

Frame 195
Sprite number = 28

Frame 196
Sprite number = 28

Frame 197
Sprite number = 28

Frame 198
Sprite number = 28

Frame 199
Sprite number = 28

Frame 200
Sprite number = 28

Frame 201
Sprite number = 28

Frame 202
Sprite number = 28

Frame 203
Sprite number = 28

Frame 204
Sprite number = 28

Frame 205
Sprite number = 28

Frame 206
Sprite number = 28

Weapon 5 (Plasma rifle)
Firing frame = 0

[CODEPTR]
FRAME 185 = CyberAttack

Afterwards, load up the patch with doom.wad and enter E1M1 or whatever you prefer. Give yourself the plasma rifle, approach a zombieman, fire... PrB+ should freeze and crash after a few seconds with the message:
"Z_Malloc: Failure trying to allocate 939524096 bytes"
The number might vary for you, but for me it was always around 9 GB.
I'm using 2.5.1.4, unfortunately I can't check the test versions right now.


The patch works good in Crispy Doom.

Any ideas what could it be?

[scifista42]

The FirePlasma codepointer has unusual hardcoded behavior regarding the muzzle flash animation:

//
// A_FirePlasma
//
void
A_FirePlasma
( player_t*	player,
  pspdef_t*	psp ) 
{
    player->ammo[weaponinfo[player->readyweapon].ammo]--;

    P_SetPsprite (player,
		  ps_flash,
		  weaponinfo[player->readyweapon].flashstate+(P_Random ()&1) );

    P_SpawnPlayerMissile (player->mo, MT_PLASMA);
}

It always goes to the muzzle flash state or the state immediately following it, randomly. So, if you set the muzzle flash state to 0, the muzzle flash animation will randomly go either to state 0 or to state 1, the latter of which is most likely unintended in your case.

[Quagsire]

PrBoom+ coding is strange.

[scifista42]

This was actually a vanilla Doom code.

EDIT: In fact, here is the respective code from PrBoom-plus 2.5.1.4:

//
// A_FirePlasma
//

void A_FirePlasma(player_t *player, pspdef_t *psp)
{
  CHECK_WEAPON_CODEPOINTER("A_FirePlasma", player);

  player->ammo[weaponinfo[player->readyweapon].ammo]--;

  A_FireSomething(player,P_Random(pr_plasma)&1);              // phares
  P_SpawnPlayerMissile(player->mo, MT_PLASMA);
}

It looks like it could work better than the vanilla code, yet doesn't really.

// Weapons now recoil, amount depending on the weapon.              // phares
//                                                                  //   |
// The P_SetPsprite call in each of the weapon firing routines      //   V
// was moved here so the recoil could be synched with the
// muzzle flash, rather than the pressing of the trigger.
// The BFG delay caused this to be necessary.

static void A_FireSomething(player_t* player,int adder)
{
  P_SetPsprite(player, ps_flash,
               weaponinfo[player->readyweapon].flashstate+adder);

  // killough 3/27/98: prevent recoil in no-clipping mode
  if (!(player->mo->flags & MF_NOCLIP))
    if (!compatibility && weapon_recoil)
      P_Thrust(player,
               ANG180+player->mo->angle,                          //   ^
               2048*recoil_values[player->readyweapon]);          //   |
}                                                                 // phares

Same problem as with the vanilla code.

EDIT2: Although, state 1 should actually go to state 0 immediately, so maybe this is not the real problem after all. (I mean, it is a problem, but not the one causing the crash in this case.)

[VGA]

If you give your plasma projectile a Death State of 101 (instead of 0) I think it doesn't crash. Also, it fixes the sprite problem that was there.