All I know is that of all "retro" ports, Doom Retro (no pun intended) has the highest DEHackEd limits.
Excerpt from the wiki's feature list:
DeHackEd support has been extended to allow for an additional 2,910 states (numbered 1,089 to 3,999), 100 additional map objects (numbered 150 to 249) and 100 additional sprites (numbered 145 to 244)
Unless I missed something and this is not needed, could GZDoom follow suit? Or is this easier said than done or already in?
I'm not much of a DEHackEd user or modder, but I figure this would be of great use to other people :D
It'd be rather simple to add this - it doesn't even require a change to the EXE - just a ZScript file with some actor definitions and an extension to DEHSUPP.
Graf Zahl wrote:GZDoom has the full MBF working set for Dehacked. If these ports have more I have no objections adding it, but it'd only be worth something if PrBoom+ and Eternity had it, too.
Or if someone actually makes a high-profile mod (not a simple proof-of-concept testmap) making use of those.
StroggVorbis wrote:All I know is that of all "retro" ports, Doom Retro (no pun intended) has the highest DEHackEd limits.
Excerpt from the wiki's feature list:
DeHackEd support has been extended to allow for an additional 2,910 states (numbered 1,089 to 3,999), 100 additional map objects (numbered 150 to 249) and 100 additional sprites (numbered 145 to 244)
Speaking of DEHSUPP, I know it's more or less deprecated and I never really dabbled in DEHackEd, but is it possible to access Heretic, Hexen or Strife codepointers or is this mainly restricted to Doom? I know there were things like HHE and SEHackEd, which GZDoom doesn't support, but it would be cool if GZDoom's DEH could be extended to encompass all the games
Speaking of DEHSUPP, I know it's more or less deprecated and I never really dabbled in DEHackEd, but is it possible to access Heretic, Hexen or Strife codepointers or is this mainly restricted to Doom? I know there were things like HHE and SEHackEd, which GZDoom doesn't support, but it would be cool if GZDoom's DEH could be extended to encompass all the games
This is honestly where I start to ask "why bother?" - those pointers are already accessible through other features of the engine, to where I don't really understand the need for it in Dehacked if no other port - and no mods for that other port - is already doing that.
wildweasel wrote:This is honestly where I start to ask "why bother?" - those pointers are already accessible through other features of the engine, to where I don't really understand the need for it in Dehacked if no other port - and no mods for that other port - is already doing that.
I slightly disagree here; you're right that if no one else is doing it "why bother" - however, it matters more whether there are actual mods that need it, than whether any other engine does it.
GZDoom is rather unique for being a Heretic source port - it's actually one of the few compared to the mountain of Doom ports available.
Sssshhh... please do not tell anyone - but the way Dehacked it set up it can accesss all parameter less functions of the actor class as named code pointers. Obviously there is little sense in using this.
Most of the other games' functions are in subclasses that are off limits, not to mention that some do not even exist anymore and have been replaced with generic code in the actor definitions.
For the project I'm working on at the moment, I've been aiming at compatibility with GZDoom, PRBoom, Crispy, and Retro. If GZDoom were to add support for the additional states, etc then I could at least have non-replacing decorations and enemies in 3/4 of these, without having to write an additional DECORATE or ZSCRIPT lump .
I was keeping my fingers crossed for Crispy and Retro to adopt UMAPINFO at some point (mainly so I could have extra secret levels), but from what's been said in this thread that doesn't sound too likely.
Best way of pushing for change is to just make the mod. There's very little effort required on GZDooom's side.
As for the extra secret exits, I'd also advise to just make them. Let port developers take a stance of either officially rejecting or actually committing to supporting it. Shadow Hog is already working on a UMAPINFO mod for pretty much that reason.
StroggVorbis wrote:All I know is that of all "retro" ports, Doom Retro (no pun intended) has the highest DEHackEd limits.
Excerpt from the wiki's feature list:
DeHackEd support has been extended to allow for an additional 2,910 states (numbered 1,089 to 3,999), 100 additional map objects (numbered 150 to 249) and 100 additional sprites (numbered 145 to 244)
Unless I missed something and this is not needed, could GZDoom follow suit? Or is this easier said than done or already in?
I'm not much of a DEHackEd user or modder, but I figure this would be of great use to other people
I don't really see the point in a classic-style port expanding the skeletal remains of DEHACKED and breaking compatibility with the prBoom standard, where nigh-universal compatibility across ports is the sole reason for using DEHACKED in Anno Domini 2019.
But then again, I don't see the point in encrypting the user config file, and I know Doom Retro did that, at least for a time. Whatever keeps programmers busy and happy and off the streets, I suppose.
Wasn't there talk about trying to extend Boom to have a dynamic state/frame/function thing based on the script that creates states used originally in the development of Doom? I think that could be useful for like a Boom derived port. Has the Boom level features but has a more flexible enemy definition system.
There was a lot of talk but as long as nobody is taking over PrBoom development this will all end up with empty hands.
I don't want to maintain that port - doing a proof of concept feature was one thing but it's where I draw the line.
Ultimately PrBoom is something that doesn't click with me.
Since Heretic was brought up, I find it interesting how this source port stuff has affected the maps created for the games. For Doom, we have a smorgasboard of different ports, but it seems that Doomworld (i.e. the place where most of the notable mappers are) has decided that PrBoom+ is the de-facto port. Despite the fact that I'm fairly certain the vast majority of players are using GZDoom anyway, your mapset had better work in PrBoom+ if you want it to be worth something. If you insist on using GZDoom, you had better have a good reason for it. The fact that UMAPINFO was proposed in the first place just shows this point; wanna use GZDoom just to have a non-standard level progression? Better find some hacky way to do that in PrBoom+ (Deus Vult II is a ridiculous example of this, and death exits are a common example), or accept that you can't have your non-standard progression as desired. The mentality that PrBoom+ is the standard is what has driven a lot of other standards, like the 32-map progression, DEHACKED for modifying actors, lack of gameplay-affecting ACS, etc.
I legitimately believe that if UMAPINFO had been accepted into PrBoom+ proper, the 32-map standard would totally go out the window. Sadly, it seems that given the widespread backlash against your proposal, and the fact that PrBoom+ itself is basically dead, pretty much says that this will never happen. Even Shadowhog's idea I feel is ill-fated; if it uses high-tech GZDoom features, it's GZDoom exclusive, and it doesn't matter if PrBoom+/other ports supports UMAPINFO; if it doesn't use high-tech GZDoom features, then what was the point in the first place? This viscous circle pretty much guarantees that the PrBoom+ standard will never change, and given that PrBoom+ is all but dead, there is no hope of the author himself adding it in to break this circle.
By comparison, look at Heretic (or Hexen, for that matter), where GZDoom was more-or-less adapted as the standard. There, the level sets make use of lots of GZDoom's features, in small or large quantities, and no one cares. As such, since GZDoom is much more flexible, there is far less restrictions on what your "standard" Heretic map must be like. New/Modified monsters? Go nuts! Different level progression? Eat your heart out! Slopes/3D floors? By all means! Want an otherwise vanilla map that uses minor ACS scripting for gameplay? Totally fine!
As you've already mentioned, Eternity has a fantastic potential to help change this standard for Doom, if only it weren't for such a monumental PR failure. I don't even think it would need to implement shared content with GZDoom from the get-go; it already has ACS support, which by itself opens ups lots of appealing gameplay possibilities. Sadly, its awful PR, its developers not caring about that, slow development, and bizarre priorities (if I really need 100% perfect emulation of Caverns of Darkness, I can accept that I have to use the original executable), basically doom the port, as you already mentioned, which is a damn shame.
.
