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.
SanyaWaffles wrote: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.
SanyaWaffles wrote: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.