Gibbon's Stuff

That is the goal, to more or less have a little more advanced version than the official re-release.

On other topics, RZDoom now has (in rz_umapinfo) branch, an almost fully complete UMAPINFO implementation.  I just have to implement the intertext and intermusic stuff and it'll be done.

It already has one. It isn’t very obvious but in the options there is a scale HUD. I always use 1080p and scale the hud so it is at ‘vanilla’ scale and isn’t tiny.

In HUD Options there is a ‘Stretch Fullscreen Hud’ option. That will scale it to whatever resolution you’re on.

Yeah it is a real pain in the ass. It already has MAPINFO and ZMAPINFO plus Dehacked and Decorate.. but nooo, let’s invent yet another standard.

MAPINFO would have been fine itself it’s just everyone wanted ‘yet more customisation’. Everyone who doesn’t have to code it that is.

Urgh…. Maybe it is Modders Best Friend but it is Developers Worst Enemy

Absolutely. For anyone wanting MBF21 support, I have one thing to say.

Here's a copy of K&R C Second Edition, good luck.

it is still deeply rooted in DEHACKED, which is the thing that should never existed at all. i mean, i know, why it was invented, but there is absolutely NO reason to base anything new on that totally broken foundation. DEHACKED support is a PITA, and extending DEHACKED has no sense at all.

DECORATE is established de-facto standard, and it can be easily stripped down to something like DECOLITE (DECORATE-light-version). it could also be made compatible with "bigger" DECORATE (so DECOLITE mods would Just Work on any sourceport with DECORATE support). there is simply no sane reason to design it the way MBF21 was designed, and making it incompatible with everything already existed at that time.

it also has some not-so-obvious features (again, thanks to DEHACKED legacy) which adds nothing that couldn't be done in a saner and more consistent way. and it is still limited by the same DEHACKED legacy in the same time.

basically, it will add even more unmaintainable mess on top of already unmaintainable DEHACKED mess. i myself won't go that way. also, it's not like MBF21 designers really cared about it's wide adoption, they made it for PrBoom family anyway. so let it stay where it belongs.

p.s.: the main thing is that DEHACKED and it's derivatives fits very badly to modern sourceports, while implementing DECOLITE in PrBoom family is much, much easier (and will make the code better structured and maintainable in the same time). it could be a win-win situation, but…

The thing is the older ports like Zdoom, Vavoom, Eternity and EDGE are radically different from one another and do modding stuff completely differently(DECORATE, DDF, VavoomC, EDF etc).

Most of the newer ports are all forks of the same 1 or 2 codebases (prboom or choco) and are new enough that the code hasn't changed radically between them yet. So once one of them adds a new feature, the others can pretty much copy/paste it into theirs with minimal effort. This gives the impression it's a widely-adopted "standard".

I could say the same for EDGEs DDF/RTS since there are several ports that have it implemented, and thus it is also a "standard", but that would be disingenuous on my part.

…bugs in MBF21 implementation reported up to this day. ;-)

fun fact: with DECOLITE those ports could be able to run at least BD Lite (with very small changes). and prolly many older DECORATE mods too.

I think I'm understanding it a bit better.

Please allow me to draw an analogy... the prboom (and choco) based ports are kind of like chrome and webkit. Convoluted new standards that are based atop prior poorly and hastily designed standards are fine because they have huge dev teams, market share and momentum. The rest of the dynamics such as network effects keep this entire travesty going.

I get the feeling then from the discussion here that MBF21 and prboom are kinda like this (especially with the cut-n-paste code between similar ports mentioned). Thus there's a disincentive to carefully design a "modding interface?" because one port will quickly bash on a quick-n-dirty hack that enough people will gushaw over and that port gets more users playing it, more MODS which target this awful hack and the network effect kicks in. Thus MBF21 is a symptom of this process.

Is this right?

Then I must apologize to you all for using dsda-doom. I had no idea that this port exacerbates the problem.

This also answers the question of why indeed there is no byte compiled scripting language. Something I've been wondering about. When I read the MBF21 spec I was hoping to find such a thing. I was thinking something like SectorLISP would be pretty cool to embed. But I daresay you guys actually maintaining Doom ports would know better in regards for developing a standardized scripting language.

This raises an interesting project. You guys would get together and decide on such a well designed language to embed in your respective ports. Then I and any who'd join me would release monthly WADs targeting these features.

But... it sounds corporate... so I'll just leave it as is. Would make one hell of a crusade though.