Danukem, on 12 December 2022 - 01:04 PM, said:
I'm assuming the goal is to make Duke 3D in Raze fully scriptable using ZScript. If EDuke32 still doesn't have a usable full 3D renderer by then, there won't be any reason for people making new mods for Duke 3D to use EDuke32, except for nostalgia or if they already have a lot of time invested using EDuke32.
For big existing mods that are still in development, they will continue to use EDuke32 because the effort of porting them would be enormous. This will be difficult to explain to the average player though, and I can foresee a time when criticisms will mount for those of us who stick with EDuke32.
The goal is to make Duke 3D fully scriptable via ZScript, but I don't think this will manifest as a problem in the way you've described. At least in the Doom community, there's tonnes of modders who completely eschew GZDoom in favour of Boom compatibility, or even 1.9 compatibility. There's a tonne of newly discovered behaviours that you can do with the original Doom 1.9, such as Mikoportals which basically rely on signed integer overflow to achieve an effect.
Some do this for the challenge, some do this frankly because they don't like Graf. Not everyone here likes Graf either, and I know there's people here who have flat out not tried Raze at all, simply because Graf is the lead developer on it. Between that and the fact EDuke32 is the only engine that plays IF, which is an excellent game, I certainly don't see it going anywhere or becoming irrelevant.
Martin Howe, on 12 December 2022 - 10:28 AM, said:
Indeed; Graf & the ZDoom devs are having to cope with tons of technical debt centred around the Build engine games; if I read this correctly, it's going to be a question of stabilising the engine for regular games and maps (and some mods) before adding ways of supporting the other types of mods; I do hope that will be possible in some form eventually.
The amount of technical debt has been quite high. For Blood and SW, and even Duke since we went back to JFDuke3D, there's a lot of 90s-esque code that's required significant uplift, as well as general refactoring to support actor management using a more modern approach. We want to eliminate setups that depend in particular picnums or tile indices etc, and that's no small feat.
We think the base games are sufficiently stabilised and we're finally at the point where we feel comfortable commencing on scripted access to the games. It took a long time to get there, but it was crucial to have the foundations as we wanted, and needed them to be.