PrBoom+ 2.6.66 (Jun 20, 2023)

[fabian]

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. ;)

 

[maxmanium]

5 hours ago, fabian said:

Good idea!

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

 

How had nobody thought of this yet?

 

Also, this isn't really necessary, but I thought, what about making TNTCOMP take a two-number buffer a la IDCLEV, instead of having to cycle through everything?

Edited January 26, 2021 by maxmanium

[Mr. LBN]

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 January 26, 2021 by Mr. LBN

[fabian]

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. 

[Mr. LBN]

11 minutes ago, fabian said:

Please make this file available somewhere. 

Edited my comment above with download.

[fabian]

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"!*

[Never_Again]

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.

Edited January 28, 2021 by Never_Again
typo

[Smite of Disrespect]

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

Edited January 28, 2021 by RonnieColeman

[Da Werecat]

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

Edited January 28, 2021 by Da Werecat

[Smite of Disrespect]

Can you think of one single example in which this would break demo compatibility of any existing demos?

[Da Werecat]

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

[Alper002]

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.

Edited January 28, 2021 by Alper002

[GoneAway]

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? :^)

[Smite of Disrespect]

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.

Edited January 28, 2021 by RonnieColeman

[Xaser]

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

Edited January 28, 2021 by Xaser

[Smite of Disrespect]

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

[Smite of Disrespect]

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?

Edited January 28, 2021 by RonnieColeman

[GoneAway]

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).

Edited January 28, 2021 by kraflab

[Xaser]

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

Edited January 28, 2021 by Xaser

[ChopBlock223]

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.

[fabian]

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. 

[Smite of Disrespect]

Sorry! I was basing that on the DEHEXTRA page on the DoomWiki:

[Gez]

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

[Never_Again]

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.

[Dimon12321]

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.

[Daerik]

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.

[fabian]

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. 

[Never_Again]

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.

[Macross+]

At last the build is here! thank you very much!

[maxmanium]

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