PrBoom+ 2.6.66 (Jun 20, 2023)

[Ferk]

24 minutes ago, rfomin said:

I mean that UMAPINFO itself doesn't need a new complevel. We have a discussion about it on Github: https://github.com/coelckers/prboom-plus/issues/337

 

But that would be a different topic.

 

Even if it was the case that UMAPINFO doesn't need a complevel, a string of feature keywords is more flexible than a static set of integers. The reason a change in the header was needed in the first place was because bumping up the version number was causing conflicts with demos from Eternity that were already using the number.

[GoneAway]

3 hours ago, Ferk said:

The reason a change in the header was needed in the first place was because bumping up the version number was causing conflicts with demos from Eternity that were already using the number.

This isn't true. Demo headers have signatures inside them, so the version number is only one piece of a key that determines uniqueness.

[Ferk]

48 minutes ago, kraflab said:

This isn't true. Demo headers have signatures inside them, so the version number is only one piece of a key that determines uniqueness.

 

It's true. PrBoom+um bumped the number to indicate UMAPINFO suport, this made it match Eternity header too much, that's why the header was changed. Otherwise it's likely it would have remained that way.

 

And of course the version number is not the only possible way to determine uniqueness, but I didn't mean it was. You can add up to the static list of bytes and the mess of nested wrappers to check for to figure out what to load, or another way is to design a more dynamic format that's more extensible. I feel the new header was a step in the right direction, but of course it's just my opinion.

Edited October 28, 2021 by Ferk

[rfomin]

Yes, at first Graf only used the number 255 to indicate an extended header. PrBoom+UM 2.5.1.7 has been released and at least two PWADs (Fork in the Road and DBP25: Dead, But Dreaming) have demos in this format. After that, strings were added to the extended header for compatibility with Eternity. The problem with this header is that it makes any UMAPINFO demo incompatible, even if the UMAPINFO itself contains only cosmetic changes (like levelnames, music, etc.)
Personally, I dislike a dynamic list of features and prefer static complevel.

[GoneAway]

2 hours ago, Ferk said:

It's true.

No, it's not 😁

Changing the signature in the header was all that was needed. The format is completely irrelevant to that problem.

 

The format change itself only caused problems rather than solve anything, as rfomin has said.

[Ferk]

31 minutes ago, kraflab said:

No, it's not 😁

Changing the signature in the header was all that was needed. The format is completely irrelevant to that problem.

 

There are many different ways to do it, what I was explaining is the reason why a change was needed.

The fact you admit that a change "was needed" is just reafirming that it's true.

I brought it up to show how depending on a static byte that you can just bump up is not always the best solution.

Edited October 28, 2021 by Ferk

[printz]

UMAPINFO question about bossaction: the specification says as such:

 

Quote

Defines a boss death action, overriding any map default actions.

 

Does it require the dead monster to trigger a BossDeath codepointer, or does it work for any dead monsters of the given thingtype? The specification doesn't make this clear, leading to different interpretations. For example in Eternity I have an equivalent feature (levelaction) that works independently of A_BossDeath, so I'd be tempted to make it like that. Gameplay differences will ensue, especially when the mod author crafts an unusual case for BossDeath.

[JadingTsunami]

10 minutes ago, printz said:

UMAPINFO question about bossaction: the specification says as such:

 

 

Does it require the dead monster to trigger a BossDeath codepointer, or does it work for any dead monsters of the given thingtype? The specification doesn't make this clear, leading to different interpretations. For example in Eternity I have an equivalent feature (levelaction) that works independently of A_BossDeath, so I'd be tempted to make it like that. Gameplay differences will ensue, especially when the mod author crafts an unusual case for BossDeath.

 

This is a common question. Activating a BossAction requires a call to A_BossDeath. I think it could be added to the specification since it is so frequently asked.

[Shadow Hog]

I would honestly prefer it if it didn't, but all the implementations I've tested against do require A_BossAction, yeah.

[Cilian]

Hello, I have a problem with prboom+, it's a crash on startup (I_SignalHander: Exiting on signal: signal 11) when openGL renderer is used, and it specifically only crashes on startup, if I turn on openGL it doesn't crash until I exit and try to launch prboom+ again. Also it didn't crash for me before but at some point it started to. Windows 7 64-bit, I use the latest version 2.6.1um, any other details I need to add?

[JadingTsunami]

1 hour ago, Cilian said:

Hello, I have a problem with prboom+, it's a crash on startup (I_SignalHander: Exiting on signal: signal 11) when openGL renderer is used, and it specifically only crashes on startup, if I turn on openGL it doesn't crash until I exit and try to launch prboom+ again. Also it didn't crash for me before but at some point it started to. Windows 7 64-bit, I use the latest version 2.6.1um, any other details I need to add?

 

Are you loading any custom content (WAD files, DEH files, etc.)? Do you have any WADs that are loaded by default?

 

Could you paste the full output from the console where you see the signal 11?

 

If you could attach your PrBoom-Plus config file too, that might help. It should be in your user folder (probably %USERHOME% or %APPDATA%, I'm not sure -- you can put those in the Run dialog in Windows to jump to those locations).

[Cilian]

4 minutes ago, JadingTsunami said:

Are you loading any custom content (WAD files, DEH files, etc.)? Do you have any WADs that are loaded by default? 

Yes, I load doom_wide.wad (cosmetic wad that fixes classic HUD's appereance in widescreen), but trying to play without this wad doesn't stop crashing

 

4 minutes ago, JadingTsunami said:

Could you paste the full output from the console where you see the signal 11?

There are no console windows being open or anything, just a window saying the error - "I_SignalHander: Exiting on signal: signal 11" and the game's broken window.

 

While I was writing the reply I found out why it was crashing, apparently it's because of -skill command line parameter, I was trying to see if something was wrong with how ZDL was launching prboom and when I tried to set skill to default (don't ask why) it stopped crashing. Here's the config file though https://drive.google.com/file/d/130dK6J_GpCfvEjw-JL0e5VKW6KgwkSay/view?usp=sharing

[VoanHead]

Good evening, thought I let you fellas know I ran into this weird bug w/ PrB+ UM: so I was booting it up to replay UAC Ultra tonight, yeah? Once I booted it up and clicked randomly on the start screen to load up the menu it just froze. So I shut it down, and reopened it again. Repeated it about 3 times, and thought to myself "well that's funny".

 

So I decided to just open the menu w/ the esc button and scroll down w/ the mouse wheel, and you will not believe what happened: it froze again! Idk what's causing PrB+ UM to hate me for using my mouse on the menu upon booting it up, but it's just something strange I think you guys might want to look into. It works just fine once I load my save and begin playing, might I add. I'm not sure if anybody else has run into this, b/c this is a first for me that it ever happens.

[P41R47]

1 hour ago, VoanHead said:

Good evening, thought I let you fellas know I ran into this weird bug w/ PrB+ UM: so I was booting it up to replay UAC Ultra tonight, yeah? Once I booted it up and clicked randomly on the start screen to load up the menu it just froze. So I shut it down, and reopened it again. Repeated it about 3 times, and thought to myself "well that's funny".

 

So I decided to just open the menu w/ the esc button and scroll down w/ the mouse wheel, and you will not believe what happened: it froze again! Idk what's causing PrB+ UM to hate me for using my mouse on the menu upon booting it up, but it's just something strange I think you guys might want to look into. It works just fine once I load my save and begin playing, might I add. I'm not sure if anybody else has run into this, b/c this is a first for me that it ever happens.

I confirm this.
I booted PrBoom+UM as always, press esc to bring up the menu, and once i use the mouse wheel, it froze and then crashes.
It been happening to me since a while ago, but i wasn't able to determine the cause as i don't use the mouse wheel almost never.
But it seems that i move it accidentally once in a while and that causes me to experience this bug.

Edited November 4, 2021 by P41R47

[fabian]

This is fixed in GIT now, thanks!

[fabian]

15 hours ago, Cilian said:

While I was writing the reply I found out why it was crashing, apparently it's because of -skill command line parameter, I was trying to see if something was wrong with how ZDL was launching prboom and when I tried to set skill to default (don't ask why) it stopped crashing. Here's the config file though https://drive.google.com/file/d/130dK6J_GpCfvEjw-JL0e5VKW6KgwkSay/view?usp=sharing

 

I can't reproduce this from the command line with whatever value I pass to the -skill parameter.

[Never_Again]

Latest Win32 dev build, as of commit 4b0e6e4 (November 04 2021).

 

Noteworthy changes since last dev build (October 22 2021):

* UMAPINFO: fixed using_FMI reset - no more crashes at textscreens 
  (e.g. after MAP06, MAP11 or MAP20) after viewing finale picture upon finishing
  a level with UMAPINFO 'endpic' property
* fixed freezing at TITLEPIC while using mousewheel in menus

+ console output

 

prboom-plus-20211104-w32.zip (Mediafire)

prboom-plus-20211104-w32.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

 

Edited November 10, 2021 by Never_Again : replaced Filedropper link with Google Drive one

[Never_Again]

15 hours ago, Cilian said:

There are no console windows being open or anything, just a window saying the error - "I_SignalHander: Exiting on signal: signal 11" and the game's broken window.

 

Use the dev build from the previous post, it has console output.

 

15 hours ago, Cilian said:

While I was writing the reply I found out why it was crashing, apparently it's because of -skill command line parameter, I was trying to see if something was wrong with how ZDL was launching prboom and when I tried to set skill to default (don't ask why) it stopped crashing. Here's the config file though https://drive.google.com/file/d/130dK6J_GpCfvEjw-JL0e5VKW6KgwkSay/view?usp=sharing

 

24 minutes ago, fabian said:

 

I can't reproduce this from the command line with whatever value I pass to the -skill parameter.

 

Neither can I, it seems to be impossible to crash prb+ by passing an invalid value to the -skill parameter.

 

@Cilian: please try to reproduce the crash with the latest dev build. Use the same settings in ZDL that produced the crash.

If it crashes again don't close the error dialog box but copy the entire console output and post it here using the code tag (the "<>" symbol).

Examine the prboom-plus process with Process Hacker and post the complete command line (from process Properties->General tab) so that we could see what cmd-line arguments ZDL invokes prb+ with.

BTW, the config file you posted is severely truncated. Most of demo patterns are missing, which is not critical, but there may be other, non-obvious changes that might be causing the crash. To eliminate that possibility, rename the config file for the time being and let prb+ regenerate a default one.

[Cilian]

17 minutes ago, Never_Again said:

@Cilian: please try to reproduce the crash with the latest dev build. Use the same settings in ZDL that produced the crash.

If it crashes again don't close the error dialog box but copy the entire console output and post it here using the code tag (the "<>" symbol).

I tried to replicate the crash with the dev build but I could only do it in the 2.6.1um release, all I had to do is enable openGL and fullscreen from a default config.

 

21 minutes ago, Never_Again said:

Examine the prboom-plus process with Process Hacker and post the complete command line (from process Properties->General tab) so that we could see what cmd-line arguments ZDL invokes prb+ with.

The dev build starts in openGL with skill parameter just fine, should I still do it for the release version or nah?

[fabian]

1 minute ago, Cilian said:

The dev build starts in openGL with skill parameter just fine, should I still do it for the release version or nah?

 

Yes, please. There was no code change since the 2.6.1um release that would explain this.

[Cilian]

30 minutes ago, Never_Again said:

Examine the prboom-plus process with Process Hacker and post the complete command line (from process Properties->General tab) so that we could see what cmd-line arguments ZDL invokes prb+ with. 

Simply prboom-plus.exe  -skill 4 (and with ZDL "prboom-plus.exe -iwad iwads/DOOM.wad -skill 4"), without console output it seems pretty useless

[Never_Again]

To see console output of the v2.6.1um and earlier releases you need to run prb+ from a POSIX terminal. So you would need either Cygwin or MSYS2, both come with the mintty terminal installed by default. If you want to try either just to use mintty I'd say go with MSYS2, its basic install should be under 100MB.

 

Or you could try this stripped-down Cygwin mintty+bash package: mintty-3510-w32.zip. Can't guarantee that it will work on your box or on Win10 in general but at under 10MB it may be worth a try.

 

To run prb+ from mintty change to the prb+ folder first:

cd /cygdrive/<drive letter>/<path to prb+ folder>

e.g.,

cd /cygdrive/c/doom/ports/prboom-plus

then run prb+

./prboom-plus

along with any command-line parameters.

Note that running mintty.exe will open two windows - one for mintty and one for bash. You enter the commands into the bash window.

 

Edited November 10, 2021 by Never_Again : replaced Filedropper link with Google Drive one

[Blue Phoenix]

When playing Evilternity with OpenGl, Mouse Look disabled and FOV other than 90,  the sky is lowered.  the lower the FOV the lower the sky until 50 or so.

Spoiler

 

[JadingTsunami]

1 hour ago, Blue Phoenix said:

When playing Evilternity with OpenGl, Mouse Look disabled and FOV other than 90,  the sky is lowered.  the lower the FOV the lower the sky until 50 or so

 

In your PrBoom-Plus config, set gl_skymode to 3.

 

See also:

https://github.com/coelckers/prboom-plus/issues/385

 

[Spectre01]

53 minutes ago, JadingTsunami said:

In your PrBoom-Plus config, set gl_skymode to 3.

What do the gl_use_paletted_texture and gl_use_shared_texture_palette options below do? I can't seem to find any explanations, other than documentation that they were implemented.

[JadingTsunami]

3 hours ago, Spectre01 said:

What do the gl_use_paletted_texture and gl_use_shared_texture_palette options below do? I can't seem to find any explanations, other than documentation that they were implemented.

 

Those are for enabling GL extensions specific to paletted textures (the former defines a palette for each texture object and the latter is intended to enable faster palette switching). I would consider them obsolete at this point as I am not even sure any cards support this anymore.

[Never_Again]

Latest Win32 dev build, as of commit ce676fc (November 04 2021).

 

Noteworthy changes since last dev build (November 04 2021):

* fixed looping forever in G_NextWeapon()

+ console output

 

prboom-plus-20211105-w32.zip (Mediafire)

prboom-plus-20211105-w32.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

 

Edited November 10, 2021 by Never_Again : replaced Filedropper link with Google Drive one

[Bytefyre]

Hello!  On advice from Kraflab in the DSDA-Doom thread, I wanted to address an issue I found here since this is the origin port for any changes made to the UMAPINFO spec.  As I understand it, there was a change introduced to suppress the "entering level" screen when any of the "end of game" tags are present for a particular map.  However, it seems this only applies to the "levelpic" field, while a value for "enterpic" will still be displayed.  I came across this when I created a detailed UMAPINFO file for Eviternity, which uses full graphics for its level pictures rather than flats and requires the "enterpic" value for these to be displayed between maps; when ending the game in Map 30, the Map 31 graphic was displayed before the endgame story screen came up.  Has a change been made in the GitHub repo to address this yet, and if not, could one be made for a future release?  Thanks!

[JadingTsunami]

1 hour ago, Bytefyre said:

Hello!  On advice from Kraflab in the DSDA-Doom thread, I wanted to address an issue I found here since this is the origin port for any changes made to the UMAPINFO spec.  As I understand it, there was a change introduced to suppress the "entering level" screen when any of the "end of game" tags are present for a particular map.  However, it seems this only applies to the "levelpic" field, while a value for "enterpic" will still be displayed.  I came across this when I created a detailed UMAPINFO file for Eviternity, which uses full graphics for its level pictures rather than flats and requires the "enterpic" value for these to be displayed between maps; when ending the game in Map 30, the Map 31 graphic was displayed before the endgame story screen came up.  Has a change been made in the GitHub repo to address this yet, and if not, could one be made for a future release?  Thanks!

 

I filed an issue for you at the GitHub project. I am able to reproduce this issue.

[Gregor]

On that same note: the enterpic is only shown for a second on-screen before the screen melts, hardly long enough to even read the title of the map, let alone enjoy the actual graphic. In GZDoom it is considerably longer on-screen. Is there some way to extent this or this hard-coded into the port?