An official ACC release

[Marrub]

As far as I know, there are several issues with the code that GDCC generates that prevents official mainstream acceptance.

I'm sorry for making such a comment, but I think that's completely bullshit. The code GDCC-ACC generates has always, for me, been either exactly the same as ACC's or better optimized.
Those examples give the wrong impression -- mainly because half of them talk of the C front, but also because they show a definite lack of research.
As for the topic, while GDCC-ACC is a great replacement for ACC, it's not maintained by the ZDoom developers and therefore not really part of the ZDoom project.
Unless it gets some definitive official support yeah right it would definitely be fine to instead have regular ACC releases when a new GZDoom version comes about, containing an up to date zspecial.acs and zdefs.acs.

[The Zombie Killer]

Plus, one of those "examples" was also explained in the next post :v (the second one)
If anything, that one is an issue with the port, not GDCC.

[GooberMan]

I'm going to have to play the devil's advocate here.

It's common knowledge that ZDoom's ACVM is written from scratch and not derived from Raven's code. It's been this way literally since ZDoom first implemented it. If you want a replacement for ACC, the replacement absolutely needs to take this in to account.

[Gez]

Not much better in the way of alternatives, thanks to a certain dev deciding to adopt ACS as a generalized scripting language to begin with, and make it into complete, horrific insanity..

Hey it was the best thing available at the time.

(The only alternative was FraggleScript. Now FraggleScript had some advantages too -- no external compilation tool, can be used in any map format -- but ACS was still a better base to build upon.)

[Ryan Cordell]

It probably would've left everyone less frustrated to have a better system designed in advance instead of just building upon the old flaws. Though it kind of is ZDooms thing lately..

[Marrub]

I'm going to have to play the devil's advocate here.

It's common knowledge that ZDoom's ACVM is written from scratch and not derived from Raven's code. It's been this way literally since ZDoom first implemented it. If you want a replacement for ACC, the replacement absolutely needs to take this in to account.

So is Eternity Engine's, both its old and new ACS VMs, and it hasn't ever had any of the issues ZDoom's has.
But that's on the presumption that GDCC somehow does something that ZDoom doesn't like. Besides allowing delays in functions, which is not a problem (and, again, works fine in other implementations) there are no such things that it must 'account' for.
I'm sorry for taking this off topic.

[GooberMan]

So is Eternity Engine's, both its old and new ACS VMs, and it hasn't ever had any of the issues ZDoom's has.

Writing a technical spec by looking at Raven's code is still technically deriving from Raven's code.

[Gez]

So is Eternity Engine's, both its old and new ACS VMs, and it hasn't ever had any of the issues ZDoom's has.

Man, if only ZDoom could have waited for a decade while some other ports wandered over the minefield, letting it design a clean-sheet VM in full knowledge of all the quirks, bugs, and problems of previous implementations!

[Marrub]

Hah, I forget sometimes how old ZDoom is. That is quite true.

[Graf Zahl]

ZDoom's ACS VM is not the problem. That's a simple loop running over the code.

The problems came later when new features were haphazardly added without thinking too much about the implications.
Did you know, for example, that for most of the time, each time a new function got added to ACS, ACC had to be recompiled because the only way to handle a new function was a new P-Code? That was, until I decided that enough was enough and added a generic function call P-Code - after that the problems were reduced by several magnitudes.