Obligatory Legacy of Rust/ Nightdive Doom Port thread

[yum13241]

ZScript is a lot more readable than DECORATE/DEHACKED hacks, for sure.

[Xterra]

...
...It's just a matter of working with it enough that it becomes native to your workflow.
...

Oh, for sure. I know ZSC's basically modded and expanded DEC, which itself is remarkably C++-like.
I think my main hangup is that autistic urge to stick with what works, and...for me, DEC works. It's what I'm used to. And, for the most part, I've avoided ZScript because, while yes, it's heavier on features and capabilities (and nicely synergizes with existing DEC), it still feels alien and unfamiliar, and for someone on the spectrum that can very well be a dealbreaker.

Basically, I ain't complaining that it exists. It's a good thing. Me finding it a nightmare to work with is a ME problem, not a ZSC problem. ZSC covers the gaps, but DEC still works, it's still there, and it's what I'm used to. It's also why I'm averse to ACS; if I can do something in DEC I'll do it in DEC. Like, I've coded up gun reloads that didn't use a lick of ACS (where most that I've seen tend to prefer it).

I will say that anonymous functions in DEC were a wonderful addition, and very much bridge a major capability gap.

[yum13241]

I will say that anonymous functions in DEC were a wonderful addition, and very much bridge a major capability gap.

Which no one ever uses, because Zandro's DECORATE does not support them, and if your DECORATE only runs in GZDoom, you may as well run it through that one DEC -> ZSC converter.

ZScript is actually quite easy to work with once you know its idiosyncrasies as a result of Doom cruft from iD, and if you take baby steps. Don't make your first ZScript project a Brutal Doom: ZScript edition-type mod..

[Phredreeke]

What I meant is that even that old Wii lying around in your grandma's basement is probably a better way to play your old GameCube games, just like how literally any source port in existence will be better for playing Doom than your grandpa's 386.

The GameCube is considered to have better video quality than the Wii, also the latter is incompatible with the broadband adapter for the six or so games that used it.

I really don't get the connection you're trying to make between vintage hardware and ID24. I don't think running ID24 WADs in DOS was ever a design goal.

(Almost) no one plays DOOM.EXE on period-accurate hardware, and even less as their main way of playing. Just like how no-one uses MBF.EXE anymore, which is why no one bothers to check for the 3 key bug.

There's clearly a lot of baggage that exists within Doom modding standards, let's eliminate some.

You're forgetting that there's still a desire for players to be able to play legacy content.

[yum13241]

The GameCube is considered to have better video quality than the Wii, also the latter is incompatible with the broadband adapter for the six or so games that used it.

Yes, but that doesn't mean that the Wii's picture quality can't be fixed. And no game using the broadband adapter is completely functional anymore anyway (and for Mario Kart Double Dash, that dream 32 player setup is fucking expensive.)

I really don't get the connection you're trying to make between vintage hardware and ID24. I don't think running ID24 WADs in DOS was ever a design goal.

The idea is that ID24 is expanding on vintage technology which needed to die in Boom, just how like expanding VGA to run at 8K 60Hz would be stupid. VGA died and DEHACKED needed to die in Boom. (I don't hate the DEHACKED author, if anything DEHACKED was ahead of its time)

You're forgetting that there's still a desire for players to be able to play legacy content.

No I'm not, what I'm saying is that there's no reason to keep around bugs and other jank that isn't needed by legacy content. It's dumb to keep the 3-key bug around for example, since no one designs their maps to abuse it. And for the demos that use it to exploit maps, fuck them. Just like how expanding DEHACKED is stupid in the age of DECORATE (even though it's considered dead by us GZDoom modders.) At the end of the day DEHACKED is not a modder friendly format, and wasn't intended to be. We just pushed the format too far, and if you think other wise, go on idgames and download DHE31, then run it in DOSBOX, set it up, and make us something valuable.

[Phredreeke]

Yeah but what does DOS Doom on 90s PC hardware have to do with it?

Keep in mind Gooberman had to do his own implementation of Boom and MBF from documentation due to licensing issues. Is there any DECORATE implementation that's not similarly license encumbered? If not it makes sense to build upon DEHACKED which they had to implement anyway due to a desire to support legacy content.

(Where does the 3 key bug come up anyway? Is it mentioned in the ID24 spec? I don't remember but I've only skimmed through it)

[yum13241]

If not it makes sense to build upon DEHACKED which they had to implement anyway due to a desire to support legacy content.

You can support DEHACKED without needing to expand it.

You're intentionally misconstruing my argument (read: strawmanning is bad).

Keep in mind Gooberman had to do his own implementation of Boom and MBF from documentation due to licensing issues

What does that have to do with what I said? I said expanding DEHACKED is bad, clean-rooming DEHACKED is another topic.

Where does the 3 key bug come up anyway?

Look up MBF on the Doom Wiki. It's not mentioned in the ID24 spec but if MBF is clean-roomed then there's probably a handful of wads out there that rely on it, and should be erased from existence. Since this is legacy content, it makes sense to support it, according to you.

Is there any DECORATE implementation that's not similarly license encumbered

DECORATE is relatively simple to parse. Reverse-engineering un-named bitfield upon un-named bitfield, not so much.

[Graf Zahl]

Look up MBF on the Doom Wiki. It's not mentioned in the ID24 spec but if MBF is clean-roomed then there's probably a handful of wads out there that rely on it, and should be erased from existence. Since this is legacy content, it makes sense to support it, according to you.

Of course it makes sense to support it. Do we want Doom to become like Apple where 5 year old stuff stops working on a regular basis?

[yum13241]

You forgot to move the cursor out of the quote field.

The idea is that it only makes sense to expand DEHACKED to the point of where its already used. DEHACKED shouldn't be expanded anymore, but the previous expansions can stay. Why people are obsessed with DEHACKED when we could make a better format is beyond me.

[Phredreeke]

Supporting legacy content was one of the design goals, else it wouldn't have made any sense to reimplement Boom and MBF. This also means supporting DEHACKED.

Whether DECORATE is easy to figure out is irrelevant, id/NightDive can't use existing code if it's GPL, meaning they would have to reimplement it similarly to Boom/MBF. In that case I expect them to take the path of least resistance (expanding DEHACKED to do the things they want) instead.

Why people are obsessed with DEHACKED when we could make a better format is beyond me.

It's the common denominator.

[yum13241]

It's the common denominator.

So was S-Video. It died because we needed more. No one bothered to even try expanding S-Video, even if it was possible.

I expect them to take the path of least resistance

Or they could make their own thing, lol. DEHACKED can have some weird, undocumented behavior that DECORATE just doesn't have.

[Gez]

This whole tangent is pointless. Ranting about DEHACKED will not move things ahead. Ranting about "demos that exploit the map" and other such nonsense is entirely off-topic.

[AliciaPendragon]

At the very least, outdated as ID24 seems to be (if what I am reading from this is correct as admittibly the techno babble goes over my head)

Will at least the animated skyboxes, custom intermission screens and additional weapon slots of ID24 be added to GZDoom proper?

[Rachael]

It's the common denominator.

This argument makes no sense.

I will agree that DEHACKED should be supported, and am glad it is, I don't think it needs to be expanded.

As yum said - DECORATE is relatively simple to parse. Even EDF's analogue of it is quite similar.

Is there any DECORATE implementation that's not similarly license encumbered? If not it makes sense to build upon DEHACKED which they had to implement anyway due to a desire to support legacy content.

Is there any DEHACKED implementation (prior to this) that is not license encumbered? That's not the point. Parsers are easy as cake to write. Getting the exact specs for DECORATE - might take a little research - but certainly not impossible.

You're missing the entire point anyhow. Negative indices? Reserved indices? What the hell?! - If you're going to go that far you might as well go with named stuff at this point. And hell - even named DEHACKED objects and ID's would certainly be better than reserved or negative numbers. It's filling a desperate need by kicking the can down the road, and that will only cause problems later on. It's almost inevitable - if they ever do expand the game again they almost certainly will need to go the route of introducing named references at some point. At least with DECORATE objects can be completely self-contained until it is parsed and at that point the game engine itself can handle adding the sprites to the sprites table, the states to the state table, and the sounds to the sound table - all with the potential for infinite (read: not limited) expansion and a whole universe of names (and "reserved" prefixes) to go with them.

I really don't think it's unreasonable to want them to go with an easy standard that more easily allows for *them* to mod their own game. Because that's really essentially what they're doing, at this point. So instead of going the easy route with the engine which makes things harder on them and harder on the community, it would make much more logical sense to adopt some standards that have already been established and are known to work - and more importantly - remove the limits imposed by DEHACKED (and its needless constant re-expansion).

[yum13241]

There's a JSON parser in GZDoom, so it could be parsed and then just used, since the features are basically already there.

outdated as ID24 seems to be

It's outdatedness stems from what got us to Doom modding: DEHACKED. The problem is people keep expanding it to the point where it can do stuff other lumps like DECORATE could do before I was even born.

Hell, let's make DECOHACK its own lump that doesn't need to compile, then free it of all the DEHACKED-ism's* that hold it back. Then you basically have DECORATE.

*I mean, let's add unlimited things, states, sprites, allow adding new things WITHOUT DoomEdNum's or other garbage numerical ID systems, I don't care if it goes up to 2^8192, it's not unlimited, then you would have a new problem: numbers are too long to type. Also, you'd get anonymous functions which are basically spammed TNT1 A 0 in DECORATE, but spammed for you, then you'd have stuff like A_FireProjectile and A_MissileAttack, all those generic attack functions and stuff.

And I agree with Rachael, and I feel Phredreek is arguing in bad faith.

Getting the exact specs for DECORATE - might take a little research - but certainly not impossible.

Certainly easier than trying to replicate all of DEHACKED's/Boom's/MBF's jank without looking at its code and lighting your pants on fire.