I think it's important to point out that Legacy of Rust is planned to use more ID24 features in the future, so just because the features are not in the spec now doesn't mean they won't be important.
At this point, GZDoom's biggest draw is the smoother input and expanded modding capabilities. And the ID24 spec will also be important by virtue that the new Doom has a community mod upload that other players of the game can download mods from. No matter what form it takes, ID24 is here to stay. If you want something in the spec to change you had best speak up now before it gets finalized. (Not to me, not in this thread, but to the maintainers of the current version of Doom)
Speaking for myself, I really wish they hadn't expanded DEHACKED. It would have been better to adopt ZDoom 2.7.0's DECORATE (whatever version before ZDoom picked up anonymous functions) or Eternity's EDF or Edge's DDF. Or even just make a new standard entirely for implementing actors from scratch. I don't like expanding DEHACKED at all - it's something that should have been abandoned and forgotten about the moment the original Linux Doom source code was released. There are viable and robust ways to define a complete actor without using DEHACKED and it's a shame that so many people seem to be stuck on old ways like it's a divine temple of some sort. That isn't how it has to be and 3 importantly historical ports have proven quite well that a more self-contained and newer standard works, and works well.
The linedefs though - I have no issue with expanding those.
My other concern about ID24 still being a moving target still stands. Once the standard solidifies (i.e. a spec v1.0 is released), I'll start working on it. Until then, not a line of code is going towards supporting it.
Graf Zahl wrote: ↑Wed Aug 14, 2024 9:24 am
I think the spec is way too complicated for what it tries to achieve. They should have kept it simple like what I did long ago for ZDoom's intermission scripts.
The main problem here is that the spec is extremely verbose and not particularly straightforward to implement.
I think this is less of a problem if the goals of each provision are clearly laid out with the intentions and maybe even optionally a few ideas of how they could be implemented. It's more of a problem when things are way too open ended and left to interpretation - because no cohesive standard will ever come out of that. No two people ever think exactly alike and that is most certainly true of any two developers.