Raze is not dead yet...

[Kinsie]

So I'm sorry, but mods that require EDuke32 support will no longer work.

While I'm sure this was a ton of work and the codebase is less trouble to work with as a result, I have to wonder if losing the ability to run pretty much every single Duke mod made in the last ten years is worth it.

[Graf Zahl]

So what would be the point of DukeGDX then, it has even less features than Raze 0.7!
The current feature set is roughly that of RedNukem, there may be some slight discrepancies but that was the goal I was shooting for.

Some of EDule32's features will surely be re-added over time, but this break was absolutely necessary to move the port forward. All the refactoring that was done depended on a fundamental assumption of how the engine is structured, which EDuke32 could not give due to how CON scripts could access the data - the engine virtually gives a free pass to every event to do as it likes - UI events can alter game states and game state events can draw UI elements - and everything can randomly draw 3D scenes onto the screen - or call scripted cutscenes which recursively call everything again and made it entirely impossible to centralize the render loop. All this is all surely nice for a modder but not for an engine developer who gets locked into a tight framework of how things have to be done. The current menu, for example, lives outside this framework but yet had to interact with it - this caused all the issues with Ion Fury not working. So there were two choices - go back to the roots (meaning EDuke32 menu, sound system and backend) and call it a day or do a fresh start and move forward unencumbered.

This is basically the polar opposite of how GZDoom was structured with its rigid separation of game and UI code and the deliberate restrictions in the event code. All these were added to allow the backend to operate safely without user provided code getting into the way.

[SanyaWaffles]

I feel if some of the scripting features can be added back as time goes on, right? Like one of Kinsie's tutorials broke. I feel that could be easily fixed once the bugs are ironed out, right? I'm not talking about the cutscene/menu hooks, but some eduke32 CON stuff seems to be viable. Or hell, roll your own extensions.

[Graf Zahl]

Yes, sure. But remember one important thing here: As the very first thing I need to get through the EDuke 2.1 additions for map data and game properties - and this stuff was very, very ill-conceived, giving uncontrolled write access to things that should be kept out of modders' hands. Since this piece of code was one of the cornerstones of EDuke32's additions it needs to be done in a robust and forward thinking way to move on, not as the instant-gratification-screw-the-consequences thing it was done as.

[SanyaWaffles]

I understand. As long as the more useful stuff is eventually added back in, I don't mind this.

I'm hoping eventually there'll be some sort of convention for standalone TCs much like GZDoom does, but I know that's far off. Just a pipe dream on my end.

[Kinsie]

I feel if some of the scripting features can be added back as time goes on, right? Like one of Kinsie's tutorials broke. I feel that could be easily fixed once the bugs are ironed out, right? I'm not talking about the cutscene/menu hooks, but some eduke32 CON stuff seems to be viable. Or hell, roll your own extensions.

Not all of these will return for the aformentioned philosophical reasons, likely leading to frequent compatibility issues with old-but-not-DOS-old mods that leaves nobody happy. If you're going to go this clean a cut, it may well be best to just build completely new systems and/or integrate a hostile fork of ZScript to cover most of the hardcoded nonsense like weapons.

Frankly, I also have my concerns that the focus on reimplementing things piece by piece may cause GZDoom development to suffer on account of the divided attention, but given that project has more people chipping bits in, that might just be the paranoia talking.

[Cianez]

Hey Graf. Just wanted to let you know that I made the minimal HUD for Redneck Rampage on BuildGDX and that you have full permission to use it or alter it to fit your needs.

[Gammli]

I would suggest just ditching CON and introducing a new scripting syntax entirely, which is better structured and offers similar flexibility as current eduke32 CON.
The pseudo-assembly style of coding of CON is tedious to work with and not having true functions where you can pass by value or reference leads to a ton of issues when trying to write safe, readable code.
Maybe, and this is more pipedream thinking than anything else, such a new syntax could also be designed such that it can work for more than one of the supported games.

Another question is interpretation of map format, i.e. will features such as TROR, sloped sprites etc. be supported?

[SanyaWaffles]

The thing is Zscript if I remember correctly works quite differently from something like CON scripting.

I'd be in favor of ditching CON scripting in favor of somthing more favorable. Hell, I've been toying with the idea of using the build engine but CON is just way too... not my thing... to utilize it properly. That and importing assets and making different palette swap ranges is one of the reasons I keep using GZDoom. And it isn't even the fault of EDuke32 specifically, every build engine fork or flavor has it's troubles.

[Graf Zahl]

The ZScript compiler is already in the engine so once I figure out how to do it it will surely be hooked up as a CON replacement. Nevertheless, better EDuke 2.1 support is something I definitely want to have in the engine anyway, so adding its CON additions is on the table.

Regarding EDuke32 features, I just repeat myself. I have to do it carefully. Full support of all current features is not going to happen, though, but it'd be a great win already if I got support up to - say 2011 or 2014. But development has to go forward from the current state, so this cannot be instantly.

The thing is Zscript if I remember correctly works quite differently from something like CON scripting.

In a way, yes but ultimately, no. ZScript is just a class based programming language, it makes zero assumptions about the things it works on, if a Duke actor is properly defined you can attach functions to it. All that's needed then is proper mapping of the CON instructions.

I'd be in favor of ditching CON scripting in favor of somthing more favorable. Hell, I've been toying with the idea of using the build engine but CON is just way too... not my thing... to utilize it properly. That and importing assets and making different palette swap ranges is one of the reasons I keep using GZDoom. And it isn't even the fault of EDuke32 specifically, every build engine fork or flavor has it's troubles.

The fault here is actually that the map format does not abstract anything, and yes, that can make mapping very uncomfortable. Regarding palette swaps and stuff, I think it's best to just ignore it. With .def files you can easily use true color assets but it may make sense to handle this a bit more comfortably with an import folder, similar to textures/ in GZDoom to avoid writing huge text files.

[SanyaWaffles]

In a way, yes but ultimately, no. ZScript is just a class based programming language, it makes zero assumptions about the things it works on, if a Duke actor is properly defined you can attach functions to it. All that's needed then is proper mapping of the CON instructions.

So theoretically it is possible. I just need to be patient. My main thing just in theory is probably it'll handle things like states and sprites differently due to how Build doesn't have sprite names, but rather sprite numbers based on an index.

With .def files you can easily use true color assets but it may make sense to handle this a bit more comfortably with an import folder, similar to textures/ in GZDoom to avoid writing huge text files.

that last bit sounds cool. Some sort of import folder for art tiles and palette swaps would be awesome.

[Graf Zahl]

Duke's actors work VERY differently. They do not have anything resembling a state table, it's all done programmatically - you define some animation sequences separately and reference them in the code. That's also why so much code in Duke is so spaghetti-like. Since you do not have a defined state it's all done ad-hoc with state variables and endless 'if's, and since it already was a long function why not go right ahead and make actor type checks wherever they are convenient, adding more spaghetti-style to the code.

Don't ever expect this to be as comfortably moddable as Doom - the entire logic structure does not allow this. Even Blood and SW will be easier to handle than Duke, despite having all data internally defined in the code, it's in tables that are a lot closer to Doom's actor definitions.

[SanyaWaffles]

I'm actually looking to make my projects more in line to Shadow Warrior or Blood anyhow, but those probably are harder to make more generic stuff for.

I'm so used to ZScript in GZDoom where it's so easy to make something that can run without DOOM2.WAD. I've been spoiled.

[Graf Zahl]

We all have. I actually have always wondered how Duke's actors work, seeing no tables defining their state and only those weird CON scripts doing some basic state checks with its if... instructions. Only when I started analyzing the code itself I realized how shoddily slapped together it all is. And it isn't really a big surprise to see that code like this is prone to breaking.

[Phredreeke]

Regarding EDuke32 features, I just repeat myself. I have to do it carefully. Full support of all current features is not going to happen, though, but it'd be a great win already if I got support up to - say 2011 or 2014. But development has to go forward from the current state, so this cannot be instantly.

if you're implementing a subset of EDuke32 functions I'd suggest calling it something else to avoid confusion like "extended CON scripting", otherwise you'll have people asking why specific mods won't work on it I think.

Regarding palette swaps and stuff, I think it's best to just ignore it. With .def files you can easily use true color assets but it may make sense to handle this a bit more comfortably with an import folder, similar to textures/ in GZDoom to avoid writing huge text files.

Speaking of which, can we have some kind of manifest file that tells Raze what game a ZIP file is meant to be used with?