The issue for me is translating the speed/direction values from A_SpawnObject to A_SpawnItemEx, and the fact that DECORATE doesn't appear to have an equivalent to the +LOGRAV flag, dunno if that's going to end up requiring ZScript
We're still keeping Boom jank alive? Wow. (+LOGRAV was one of many properties you could set back in Boom Extended DeHackEd (BEX) in a friggin BITFIELD.)
Jank isn't too bad when it's contained in something like the DEHACKED parser where it can be safely handled during initialization and ignored afterwards.
The problem is when jank escapes the confines of containment and has to be pulled back into the core mechanics of the game.
Spoiler: JankThe whole point of a standard is to make stuff better, not keep around old stuff because we're used to it. Otherwise, we'd still use VGA! Expanding DeHackEd today is like playing your GameCube games with a GameCube, or like designing maps around (to exploit) the MBF three-key bug today. (I will never play your map ever, and will tell people not to do so)
There's two compatibility flags for this now so this one can be considered solved - thank God!
True, but you cannot expect people with deep investments into the old tech to leave it behind. Dehacked is here to stay so it gets expanded because doing so is the path of least resistance. It's not unlike the financial industry hanging on to COBOL and expanding it - migrating away would incur some high short term costs - and we all know that these always overshadow the long term ramifications.yum13241 wrote: ↑Mon Aug 26, 2024 5:23 am The whole point of a standard is to make stuff better, not keep around old stuff because we're used to it. Otherwise, we'd still use VGA! Expanding DeHackEd today is like playing your GameCube games with a GameCube, or like designing maps around (to exploit) the MBF three-key bug today. (I will never play your map ever, and will tell people not to do so)
Changing out COBOL costs money. Developing something for Doom modding doesn't, except bills you are paying anyway, unless you're that poor, in that case, Doom modding is the least of your concerns, and I hope you can get better.It's not unlike the financial industry hanging on to COBOL and expanding it - migrating away would incur some high short term costs - and we all know that these always overshadow the long term ramifications.
A DEHACKED to DECORATE converter is feasible, a COBOL to C++ converter is not.True, but you cannot expect people with deep investments into the old tech to leave it behind
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.This will be a weird statement to anyone not versed in emulation.
That, and quite frankly-- sorry Graf-- ZScript is, for whatever reason, a *nightmare* for me to navigate, even though it's just combo DEC+ACS with more functions.Rachael wrote: ↑Tue Aug 27, 2024 6:24 am I don't agree with eliminating DEHACKED entirely. I am just against expanding it. DEHACKED is a standard that was once required in order to do any custom actors at all, and it was quite novel for its use during its time. Now we have better ways to do this and everything is abstracted, so there is really no need to stick to the old ways. In fact, a standard that was created 12 years later (DECORATE) works perfectly fine. And for those who are exceptionally averse to ZDoom-related stuff for whatever reason, alternatives exist, such as EDGE's DDF or Eternity Engine's EDF.
The reason why I won't advocate for the use of ZScript is because that one goes too deep into the engine's internals, and it's far too unreasonable to expect any non-GZDoom based port to support it.
Code: Select all
void MyFunction()
{
let impdude = AwesomeImpDude(Spawn("AwesomeImpDude"));
impdude.dosomething();
}