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

PrBoom+ 2.6.66 (Jun 20, 2023)

Recommended Posts

9 hours ago, Xaser said:

re: complevels, I feel like the biggest quality-of-life change we could make here is to give them names, so you can do like "-complevel boom" instead of the number, if you're like me and can never remember the random-ass digits. :P

 

Good idea!

https://github.com/coelckers/prboom-plus/pull/180/files

 

8 hours ago, Diabolución said:

Results match the previous ones.

 

Thank you, but this sentence alone would have sufficed. ;)

 

Share this post


Link to post

I get an exit on signal 11 when trying to use a DEHEXTRA.deh file.  I'm using frames 1089 onward (TNT1A is the NAME in the states window).  Does 2.5.1.7UM have full compatibility with DEHEXTRA or are ya'll workin' out the kinks?  I can use all the frames in MBF.bex format which goes up to 1075 without crashing, but I wondering what I've done wrong.

test.zip

Edited by Mr. LBN

Share this post


Link to post
23 minutes ago, Mr. LBN said:

I get an exit on signal 11 when trying to use a DEHEXTRA.deh file.  I'm using frames 1089 onward (TNT1A is the NAME in the states window).  Does 2.5.1.7UM have full compatibility with DEHEXTRA or are ya'll workin' out the kinks?  I can use all the frames in MBF.bex format which goes up to 1075 without crashing, but I wondering what I've done wrong.

Please make this file available somewhere. 

Share this post


Link to post
11 minutes ago, fabian said:

Please make this file available somewhere. 

Edited my comment above with download.

Share this post


Link to post
4 hours ago, Mr. LBN said:

Edited my comment above with download.

 

Hm, works for me. Are you using the official release or one of the test builds provided throughout this thread. *Do not use the "official release"!*

Share this post


Link to post

Latest Win32 dev build, as of commit b8aa0e7 (Jan 27 2021).

 

Noteworthy changes since last dev build (Jan 21 2021):

* fixed the KFA cheat string not read from .bex patches
* UMAPINFO docs updated re: "bossaction" field
* fixed a crash when running out of space while typing in a file path into the autoload
  fields (Options -> General, page 2)
* fixed the "Garbage lines at the top of weapon sprites" issue (#95)

prboom-plus-20210127-w32.zip

 

For the required DLLs get the Jan 12 release. This build includes three updated DLLs only.

Two updated TXT files are also included. See the accompanying TXT file for details.

 

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

Share this post


Link to post

Regarding Extended Dehacked:

I noticed that Crispy Doom will always read extended dehacked files completely, but PrBoom 2.5.1.7 will omit all the extra codepointers that MBF created, such as RandomJump, Spawn, PlaySound, etc., unless using c11 or default cl. PrBoom already allows sky transfers on complevel 9, and that was an MBF feature. Can we get extended dehacked working in the other complevels as well? I would like to make an extended dehacked map set for Crispy Doom, but this would render it unplayable in PrBoom cl2 and thus prevent people from using viddump

Share this post


Link to post

Sky is a cosmetic feature. Those that affect the playsim shouldn't be working in complevels they don't belong to, IMO.

Share this post


Link to post
40 minutes ago, Da Werecat said:

Wait, I forgot. MAPINFO is independent from complevels, right?

From what I understand, yes, UMAPINFO was implemented as separate from complevels, hence the effort into the demo format signature.

 

The dehacked situation is a weird case though. Nobody in their right mind plays an MBF wad with complevel 9, but adding features it doesn't have is sort of against the point of a complevel in the first place. Unless we add more complevel-agnostic stuff I don't think the abilities of each complevel's dehacked will change.

Share this post


Link to post

I don't think adding those features to other complevels is a great move. In particular, anyone playing on old versions of prboom+ will then have different results on the same complevel, and demos recorded in the new versions would no longer be compatible with the old ones - sounds like a disaster.

 

Maybe you could target woof instead of crispy if you want stuff added by mbf but still with that classic feel? :^)

Share this post


Link to post

Nah I want the freedom of extended dehacked (which Woof can't into). Re-purposing states is an organizational nightmare resulting in state 66 going to 707 going to 600 and back etc. I'll just do me and PrBoom users be damned!

I'm not convinced of demo desyncs being a problem, as that would only occur if a cl2 or cl9 map had those MBF codepointers. IMO the strongest argument against adding extended dehacked codepointers to all complevels is that it would render MBF-compatibilty completely obsolete, which I am fine with BTW as I dislike the monster infighting change.

Share this post


Link to post

I've got a thing in the works that's using UMAPINFO + EXTRADEH, and the reality is a bit fuzzy. if I run my wad in this fork* with -complevel 9, the actual EXTRADEH features (extended state + thing ranges) apparently work just fine -- it's just the MBF codepointers that are disabled (and even then, they no-op rather than throw an error or something, which is the worst way of communicating to the user they're doing something wrong).

 

For MBF codepointers at least, I wonder if we can leverage the extended demo header for this -- add a UMAPINFO flag for enabling MBF codepointers in other complevels, and write a new feature string to the header. This way, any demos that get recorded with the wad will outright refuse to run in older versions of PR+ that don't have that feature. Probably possible to do something similar with EXTRADEH, but that'll take a bit more noodling.

 

[*disclaimer: I'm not up-to-date with the latest master so no idea if there's any changes since whenever my arbitrary build was made.]

 

 

[EDIT] This proposed codepointer flag is technically port-specific, and while there technically wasn't a consensus on how to define port-specific properties in UMAPINFO, the discussion was heavily favoring just using a prefix in the property name, e.g. we'd best call it "prboom_enablembfactions" or something. Just a note in case someone gets feature-trigger-happy. :P

Share this post


Link to post
8 minutes ago, Xaser said:

if I run my wad in this fork* with -complevel 9, the actual EXTRADEH features (extended state + thing ranges) apparently work just fine -- it's just the MBF codepointers that are disabled

And you want to run it in cl9, right? That's kind of my issue; I don't want cl11 and the monster infighting change, and I feel more strongly about that than about losing the ability to play in Crispy

Share this post


Link to post

When was the last time PrBoom's default complevel was changed?
Has anyone made a -complevel 17 pwad (default compatibility AFAIK)?
Where can I read up on what was changed with default compatibilty compared to say cl9 or cl11?

Share this post


Link to post
1 hour ago, Xaser said:

For MBF codepointers at least, I wonder if we can leverage the extended demo header for this -- add a UMAPINFO flag for enabling MBF codepointers in other complevels, and write a new feature string to the header. This way, any demos that get recorded with the wad will outright refuse to run in older versions of PR+ that don't have that feature. Probably possible to do something similar with EXTRADEH, but that'll take a bit more noodling.

Does that align with the purpose of umapinfo? That's a genuine question - I don't know exactly what its scope is. I guess the header supports any named keys, so it could be entirely separate. I can't say I look fondly at a hypothetical future where people need to update the port every time they want to watch a demo for a new wad (hello gzdoom).

Share this post


Link to post

The UMAPINFO flag is more of a "best fit" than an ideal solution -- GZDoom has a "gameinfo" block where you can define properties relevant to the wad as a whole, rather than per-map. This would be a more natural fit for that, except PR+ doesn't have anything like that and UMAPINFO's the closest bit. So either we propose a new lump (heh), or we go with the pragmatic approach. ;)

 

I get your concern, but I feel like the rubicon's been crossed already, with UMAPINFO and EXTRADEH being the first two notables examples of new modding features for the port in like a decade... and they're already in. It's more a question of how to improve the support for the things that have happened, really -- that, and the paramount goal re: demos is backwards compatibility. It's kind of a minor annoyance to need to update to a new version to watch a demo, but it's far from the grievous sin of rendering old demos obsolete, which is what really sinks gzdoom's demo-ship. :P

 

[EDIT] Re-reading your post: yes, I'd propose a new key for the demo header for sure. We definitely don't want to ship an MBF-codepointer-enabling feature without that, else we'll be back in the same panic-mode waters as UMAPINFO's early arrival. :P

Share this post


Link to post

Sounds to me like a worthwhile idea to consider. I would love to be able to extend the DeHacked functionality just a little bit without having to deal with MBF's much less fun infighting.

Share this post


Link to post
13 hours ago, RonnieColeman said:

Nah I want the freedom of extended dehacked (which Woof can't into). 

Woof has all the extended extended DEHACKED states. 

Share this post


Link to post

Never assume a wiki list is entirely exhaustive. It relies on people keeping it up to date, after all.

Share this post


Link to post

Latest Win32 dev build, as of commit 76ef560 (Jan 31 2021).

 

Noteworthy changes since last dev build (Jan 27 2021):

* add support for named complevels on command line:
  -complevel 1.9      = -complevel 2
  -complevel doom2    = -complevel 2
  -complevel ultimate = -complevel 3
  -complevel udoom    = -complevel 3
  -complevel final    = -complevel 4
  -complevel tnt      = -complevel 4
  -complevel plutonia = -complevel 4
  -complevel boom     = -complevel 9
  -complevel mbf      = -complevel 11
  -complevel vanilla  = complevel autodetected according to IWAD loaded

prboom-plus-20210131-w32.zip

 

For the required DLLs get the Jan 12 release. This build includes three updated DLLs only.

See the accompanying TXT file for details.

 

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

Share this post


Link to post

That may sound odd, but why do people still take 2.5.1.5 into consideration when it comes to a port choice? 2.5.1.7 has gone beyond 1.5 and I can't think of any reason why should one choose 1.5, but not 1.7, expect for some weird mouse problems.

Share this post


Link to post
47 minutes ago, Dimon12321 said:

That may sound odd, but why do people still take 2.5.1.5 into consideration when it comes to a port choice? 2.5.1.7 has gone beyond 1.5 and I can't think of any reason why should one choose 1.5, but not 1.7, expect for some weird mouse problems.

 

Weird mouse problems are the sole reason I continue to use the fork of 2.5.1.5, in conjunction with the performance issues I experience on 2.5.1.7/dsdadoom.

Share this post


Link to post
13 hours ago, Daerik said:

Weird mouse problems are the sole reason I continue to use the fork of 2.5.1.5, in conjunction with the performance issues I experience on 2.5.1.7/dsdadoom.

Please try one of the latest test builds, a lot has happened lately in the development of the 1.7 fork. 

Share this post


Link to post

Latest Win32 dev build, as of commit 051c4a5 (Feb 5 2021).

 

Noteworthy changes since last dev build (Jan 31 2021):

* allow MBF sky transfers in all complevels
* add support for colored blood and gibs

prboom-plus-20210205-w32.zip

 

For the required DLLs get the Jan 12 release. This build includes four updated DLLs only.

See the accompanying TXT file for details.

 

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

Share this post


Link to post

Question: is there, or will there be, a way to override the colored blood for custom monsters (like the hell knight replacement in Valiant)?

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
×