AngelScript: The Revenge

[SUCCESSOR]

I'm fond of "heaven" and "hell" for the two of them. :)

Hahaha, that would bee good if they wouldn't both end up being ZC H. People love their shorthand.

[ZoriaRPG]

Hahaha, that would bee good if they wouldn't both end up being ZC H. People love their shorthand.

ZC Underworld, Purgatory?

Hades also begins with an H.

ZoriaRPG, here is my current understanding of the plan: we will keep supporting ZScript for the foreseeable future. Part of this support will include the changes that we have discussed together, such as moving ZScript to a message-based system, and using this message system to allow scripting of enemies, weapons, etc.

Gleeok is working on an AngelScript engine, and ultimately it makes sense to use AngelScript as the main ZC scripting language, since it is a fully-featured and supported language, rather than hack away at ZScript on our own. But we will not suddenly drop ZScript support, and indeed if all goes according to plan, you will be able to slot in either ZScript or AngelScript handlers for the messages emitted by the game engine, so that you can seamlessly transition from ZScript to AngelScript as you become more comfortable with the latter.

This is solid, and reasonable. I can work with that. It also allows us to revisit, and reconsider points that are raised along the way.

@ZoriaRPG :

First off: 2.6, 3.0 whatever. Point being that it is a greater major version than 2.5+.

That clarifies it a bit. We did in fact, have an outline for 2.6, specific, which is why this is so bloody confusing.

I purposely put the AS stuff right out there so everyone could see the current status of it. This is here to support legacy scripts in the future: https://github.com/ArmageddonGames/Z...indings/Legacy It's a lot of work, and you can see that I've already started it.

As I said before ZScript bytecode is not compatible with AS and I don't want to even try to do that. If someone else wants to then feel free to go crazy. I have no idea how this would even work realistically.

DarkDragon asked how long it would take to get something working to support messaging, general scripting, using it, etc.; I said about 10%(something like that) of the total time it would take with ZScript. This may sound strange, but you have to factor in testing, maintenance, features, useability, scalability, debugging, and future features as well. If this is stable for future ZC devs, it's just a win across the board. Keep in mind that jman, Joe123, _L_, Saffith, and myself worked with ZScript code after DD left. That's a lot of people over years of time with little improvements. Long story short is that every one of us probably cringe when someone mentioned a possible bug in ZScript. -Like I said, I'd like the next gen to be happier than we were. But if anyone wants to add messaging, structs, overloads, polymorphism, or whatever else to ZScript then you don't need my approval, you just have to be willing to maintain it for years to come.

Well, as far as I'm aware, the three of us specifically volunteered to maintain this jank. Whether or not everyone maintains their commitment, i can;t say, nor can I predict what I will eat ton the morrow, but I certainly hope that everyone lives up to their word. We do want to work towards a 3.x, eventually. I put quite literally, everything in my life on ice for Dec-January working on this.

I'm also more petrified of engine bugs, than zscript bugs. Once I complete the third merge, I need to see if a few things persist. One of the main issues, is that there are arbitrary hardoced values in places with no explanations for them, so we are essentially required to experiment and see if a change to any of these effects something else.

ZScript->AS conversion is planned in the form of a tool (built-in or whatever else). It cannot be 100% (unless someone wants to modify the ZC AST to output and prettify scripts, which sounds insane), but I think 99% is good enough. Users will simply have to hand modify some of their scripts that use ints and floats interchangeably that are incorrect for their type, and arrays for strings would probably need to be changed to actual strings. Most scripts are likely trivial, but the more complex the script the more crazy this becomes to automate.

I suspect that we could either handle the conversions internally at some future point, or allow using either parsing engine in parallel. It should be possible to maintain internal ZASM calls either way.

I would just cast all ZScript ints to float, or use a special type to handle both. Arrays and strings are another issue, and converting them internally is going to be a burden for the future. Breaking int/float, and arrays, would pretty ,much kill 95% of the present codebase, so we would be required to convert these things.

Honestly, a simple parsing token would be used as a flag on legacy scripts to handle these events.

If anyone wants to suggest a way to do this better, and actually do it, then let me know and I'll help with that instead if possible, otherwise I don't have a perfect solution.

I think it's too early in the game to get any ol us to implement something in the AS engine that would be ideal. A year from now, that may be an entirely different matter, which is why rushing through this now, might not me ideal. In ten months, I may be able to sit down and work on it with you, I don't know if you would want to do that, but for the sake of the future, comment the hell out of this work, so that if we need to go through and rework any components, we can, should you decide to be done, before we get to it.

[Gleeok]

If y'all want to duplicate this in ZScript anyway then what's the point? We'd just expend multiple resources to do the same thing that are incompatible with each other and still have to be maintained separately. Okay fine; now it's my turn to ask:

How long is this going to take to complete and how many people are going to work on it?

I think it's too early in the game to get any ol us to implement something in the AS engine that would be ideal. A year from now, that may be an entirely different matter, which is why rushing through this now, might not me ideal. In ten months, I may be able to sit down and work on it with you, I don't know if you would want to do that, but for the sake of the future, comment the hell out of this work, so that if we need to go through and rework any components, we can, should you decide to be done, before we get to it.

A year? No way. The whole rationale of switching to AS is that it's fast. If this takes a year then I'm out right now. Period.

[ZoriaRPG]

If y'all want to duplicate this in ZScript anyway then what's the point? We'd just expend multiple resources to do the same thing that are incompatible with each other and still have to be maintained separately. Okay fine; now it's my turn to ask:

(Emphasis, mine)

How long is this going to take to complete and how many people are going to work on it?

Clarify 'this' in the above statement, and I can give you a concise answer.

If I wasn't required to make a wholly separate branch per small set of changes, this would be done. Now. As things stand, I now need to go back in, and restart the last merge. Then I need to wait for discussion, and approval, n things that I already know work. Then repeat, for about 100 submissions. I would love to be able to submit changes in sets and get it done quickly, but clearly that isn;t how all of you want to proceed.

This is the problem when I am months ahead on engine changes, before any implementation of the git repo occurs. What do you want me to do?

As things stand, my latest push wasn't able to be automerged because of other changes in the main repo, that occurred between my last push, and the latest one.

A year? No way. The whole rationale of switching to AS is that it's fast. If this takes a year then I'm out right now. Period.

Well, let's count who we have that is even remotely interested in this, and is working on the source. Then, what are our priorities, and what is our release schedule? I was going to do one release every six months. I wanted to have 2.54 out by now, and every time I feel that we are close, we end up in a month-long debate about something.

Are you construing my input as an active developer, in that it is directly meaningful; or am I just throwing opinions to the wind, and waiting for your approval? I thought it was the latter.

I would like to wrap up the stuff that I have working for 2.54, minus one or two things that you won;t approve, unless you approve of how I would change them, integrate it, do some bug testing and bug eradication, and out out a Gamma, That would allow me to focus on this kind of topic, and devote mental energy to it, while doing minor 2l.55 improvements, so that we can get it working for the enxt release. Going in circles like this, means that my work is focused elsewhere. I also think that the drawing stuff has higher priority, because while this is a nice thing to consider, if it isn't going to compile scripts with array and string usage, then it isn't going to compile very much at all.

I have no idea what you want to be doing. I know that I will be doing this for the foreseeable future, at least a few years. That gives me the luxury to plan ahead, and not rush headlong into this change; and it means that I can plan out a series of rewrites to coincide with it. I thought that you were going to make it into a module that can be used with the current implementation, anyway?

I wish you would come over and have a skype discussion with us even once a week, to plan out this kind of thing. We resolve things much more readily that way.

As far as ratrionale, I disagree. The rationalle for shifting to AS is that it would allow things that we cannot do at present, and that it is more optimised with relation to script compiling, and user handling of script content. I do not want to rush it into production.

What I would like to see is array conversion, array pointer handling, and a method of typecasting all ZScript values to any single type. If it can;t do that, then it is a second language, tacked onto ZC. That means that at some point, we will stop adding to ZScript, but still include its parser and ZASM; and all new content will be via AS, and its parser. I don;t like that option, over properly implementing a cross-compiler, or interpreter.

If it was for a ZC version in which we were not concerned with full legacy support, then it wouldn't matter. In that, I want to do massive engine changes and improvements.

What we could do, is simultaneously develop 2.xx and 3.xx. I don't mind that option,particularly if Successor wants to work on rewrites; but I'm not some teenager who can skim this material, pick up in it in a heartbeat, and do something with it. I'm an old codger who takes his time doing everything.

Let's face it... This project is severely understaffed, and no level of re-factoring will change that unless ZC somehow becomes massively more popular. It;s been open for over a year, and you still have precisely the number of new people on board that you did, before you released 2.50.x. I was about ready to just say 'the hell with it', and again resume my plans just to work on the fork, because I'm a bit sick of the arguments.

I can't routinely debate these things, and I need to get the merging done, and get a version in Gamma. I want to get the drawing stuff in it, and I want to get most of our new features in it as well. Link.cpp needs a lot of work for 2.55 that will need to wait, and clearly isn't going into 2.54, because I can;t get anyone else to work on it with me. That seems more important than changing the script engine, at least, to me.

There is still a huge issue with diagonal movement, the user can;t set Link;s hitbox and hit offsets, link's weapons are stuck in limbo, and lots of other stuff needs work, as a priority; ass do weapons, and items.

I want to get a flag editor into 2.55 or 2.6. Bearing all of this to mind, you want me to overview, learn, and master AS not as a user, but as a developer, in a few weeks, or months.

What can I do to please you here? I don;t see this parser as such a high priority, given its low compatibility. If it is a self-contained module that is ready to use, I can integrate it whenever I want, and start putting out 3.x alphas for people to examine. As things stand, I can;t put my own approval on it, particularly wit/h what you outlined earlier. The fact that int 1.5 weill become 1.0 in this engine would break most of the scripts ever made, even without respect to arrays.

This is both because the parser was never configured to truncate those values, or return errors if the wrong type was used, and because users and developers alike advised that int and float were identical, and it didn't matter which was used. I'm not joking about when i say that the vast majority of scripts would not compile without being able to cross both of these into a new type, or crossing them both to float. Almost no script that I, Moosh, Evan, Grayswandir, Dimentio, and who knows else has made, would work if arrays and strings need to be redone.

Most of our stuff relies on how array pointers work. Perhaps if AS can't support them, then it is just the wrong choice for a replacement language. Perhaps we should contact Andreas and see if he is willing to discuss how to make our bizarre types work with a conversion of some kind.

But above all else, I would ask: Who else, developing ZC right now is going to work on this? I know in advance that Dimentio is not. He objects to the whole idea. I can't speak for the others, but if it means taking time away from what we are already doing for ZScript, then I can't justify it. I'm not looking for a quick way out of ZScript. I was only interested in AS because of what it offered to enhance our present scripting capabilities, but if it means rewriting everything, then it's just not practical.

How often have we had that debate; and have people said that it would be almost perfectly compatible; then find some way to justify that some grievous lack of compatibility is worthwhile? If it truly cannot be made to be compatible, then just forget it and work on something else.

[Gleeok]

Clarify 'this' in the above statement, and I can give you a concise answer.

this = everything that AS already does that would need to be implemented from scratch in ZScript.

Well, let's count who we have that is even remotely interested in this, and is working on the source. Then, what are our priorities, and what is our release schedule? I was going to do one release every six months. I wanted to have 2.54 out by now, and every time I feel that we are close, we end up in a month-long debate about something.

Are you construing my input as an active developer, in that it is directly meaningful; or am I just throwing opinions to the wind, and waiting for your approval? I thought it was the latter.

It's not me who's arguing with you about /your/ new features, it's the other way around. I try not to interfere with what you want to do at all, but you have to realize that when all the active ZC devs tell you some very small feature is a bad idea and we won't take it it's probably a valid point. I think some of the things you added are pretty cool and hopefully you can streamline the keeping up-to-date with the zc repo to make it easier. I'm the type that likes new stuff. It's unfortunate that I started on ZC when it was such a mess with getting 2.5 done and I couldn't do anything major with it.

What I would like to see is array conversion, array pointer handling, and a method of typecasting all ZScript values to any single type. If it can;t do that, then it is a second language, tacked onto ZC. That means that at some point, we will stop adding to ZScript, but still include its parser and ZASM; and all new content will be via AS, and its parser. I don;t like that option, over properly implementing a cross-compiler, or interpreter.

If it was for a ZC version in which we were not concerned with full legacy support, then it wouldn't matter. In that, I want to do massive engine changes and improvements.

What we could do, is simultaneously develop 2.xx and 3.xx. I don't mind that option,particularly if Successor wants to work on rewrites; but I'm not some teenager who can skim this material, pick up in it in a heartbeat, and do something with it. I'm an old codger who takes his time doing everything.

It's for both. Existing quests won't use it but new quests will have people switching over to AS.

Let's face it... This project is severely understaffed, and no level of re-factoring will change that unless ZC somehow becomes massively more popular. It;s been open for over a year, and you still have precisely the number of new people on board that you did, before you released 2.50.x. I was about ready to just say 'the hell with it', and again resume my plans just to work on the fork, because I'm a bit sick of the arguments.

This is why we don't need people working on incompatible things when we can work on the same thing and get it done faster.
Again, I'm not the one arguing.

I can't routinely debate these things, and I need to get the merging done, and get a version in Gamma. I want to get the drawing stuff in it, and I want to get most of our new features in it as well. Link.cpp needs a lot of work for 2.55 that will need to wait, and clearly isn't going into 2.54, because I can;t get anyone else to work on it with me. That seems more important than changing the script engine, at least, to me.

Link.cpp sucks, but the enemies are needing a rewrite right after the the next (maybe 2 or 3) 2.5+ release. Totally different discussion though.

Most of our stuff relies on how array pointers work. Perhaps if AS can't support them, then it is just the wrong choice for a replacement language. Perhaps we should contact Andreas and see if he is willing to discuss how to make our bizarre types work with a conversion of some kind.

Arrays are not pointers. Again you refer to /our/ meaning this is a personal matter, not one that reflects the overall ZC community.

But above all else, I would ask: Who else, developing ZC right now is going to work on this? I know in advance that Dimentio is not. He objects to the whole idea. I can't speak for the others, but if it means taking time away from what we are already doing for ZScript, then I can't justify it. I'm not looking for a quick way out of ZScript. I was only interested in AS because of what it offered to enhance our present scripting capabilities, but if it means rewriting everything, then it's just not practical.

How often have we had that debate; and have people said that it would be almost perfectly compatible; then find some way to justify that some grievous lack of compatibility is worthwhile? If it truly cannot be made to be compatible, then just forget it and work on something else.

What /are/ you doing for ZScript? How am I supposed to know that? Where is the code that does it, or, the spec that defines it? Don't get mad at me for being in the dark here... O_o

[ZoriaRPG]

I denoted the individual, key response points,in bold text, so that you can examine them at your leisure.

@ZoriaRPG

I get what you are saying, but I don't have time right now to go over all of that. I wish you would post smaller chunks of text when there is only a few key points relevant. :/

1) You are making a huge deal about arrays for no good reason. Here is a ZScript array:

 int a[] = {1, 2, 3};
//or
int a[3];

Here is an AS array:

 int[] a = {1, 2, 3};
//or
int[] a(3);
//or
int[] a; a.Resize(3); //etc..
Array<int> = {1, 2, 3};
Array<ffc> f;
Array<MyClass@> ae;
eweapon[] aew;
//etc....

Oh my god! They are so different I don't know what to do!?

I don't know if you are deliberately mocking me, or if you missed my point; but I will clarify, if the latter. This concerns array pointers, not array declarations:

int foo[32];
int arr[16];
arr[0] = foo; //pointer for foo is stored in arr[0];

int ptr = arr[0];
pr[20] = 5; //foor[20] = 5

This is extremely commonplace array pointer usage. because AS doesn't have (traditional) pointers, I am concerned that this will break.

Will it? Evan effectively begged me at one point to ensure that this would never change. He and Moosh both use arrays by reference in precisely this way in almost every one of their ghost scripts. Gray, ywkls, and I all do so in our engines. It's not trivial, if it changes.

this = everything that AS already does that would need to be implemented from scratch in ZScript.

Here is what we seem to have, as a general plan, with some aspect or another complete.

Additional C Syntax : Switch-Case, Define, Enum, Structs (or something similar), potentially classes. -Grayswandir, minor contribs from me.
Sophisticated Messaging : -DarkDragon
Enhanced string and array usage : Array declaration improvements, usage of maths, and constants for array sizes. String literals (limited, but functional). -Grayswandir
Function pointers, that work similarly to handles in AS. -Grayswandir

I'm sure there are other things that these two are working on at present. I was going to add in enum and define, if Gray doesn't, and I sent him the rules that I wrote for define, and some stuff for constants and other materials. He wanted me to hold off on doing anything else, particularly adding npcdata, and other script types, until he finishes his present round of changes.

I have not focused on the parser itself of late. I mainly worked on the ZScript language, which I shall cover below.

It's not me who's arguing with you about /your/ new features, it's the other way around. I try not to interfere with what you want to do at all, but you have to realize that when all the active ZC devs tell you some very small feature is a bad idea and we won't take it it's probably a valid point. I think some of the things you added are pretty cool and hopefully you can streamline the keeping up-to-date with the zc repo to make it easier. I'm the type that likes new stuff. It's unfortunate that I started on ZC when it was such a mess with getting 2.5 done and I couldn't do anything major with it.

I only wish. If I could submit the changes that you will ratify, and do it in a sane manner, then keeping it up to sate in a streamlined manner would be easy-peasy.

The changes are scattered around in various ways; see the links listing the changes below. There is no way to do this that isn't gong to drive me mad, under the present accepted method. You both want to maintain a repo using pushes, instead of commits. That just isn't hot the software was designed to flipping work. I literally need to make twenty or so identical forks, apply some of the changes to each, and mind, some of these changes depend on one-another, so I need to either (submit incomplete/non-working changes), or (lump more together at one time and hear complaints about total push size)--and pray that some other change doesn't make an auto-merge impossible; and be asked to do it again???

That is absolutely ludicrous. You wonder why I'm not working on AS, and why I frankly don't want to be bothered with it? Hell, I have to merge in Dimentio's changes, too; and when I wake, and think about doing it, I get such a bad taste in my mouth between the constant complaints, and the sheer volume of merging many, many, tiny changes, that I just decide to do something else.

It's for both. Existing quests won't use it but new quests will have people switching over to AS.

(Emphasis, mine.)

Wait, what? Now we're going back again? Can we please clarify if after adding this AS parser, people will be able to flipping compile a ZScript script, without changing it? I don't care how it's compiled, just that it compiles. What you say here, implies that the change is forced on the user. Earlier you said they could use both or either. Before that, it was one or the other. Which is it, again?

What bothers me, is that even between the last few posts, or in the same post, I see wholly-contradicting points. If your AS implementation is a module, and the ZScript parser will work alongside, in parallel or otherwise, I certain have no objections at all. It is the one-or-the-other philosophy, that brings in potential problems; and aye, I have objections to it, but not merely because of any personal issue. I can easily make a custom ZC build to suit any purpose that I desire, for my own personal needs, or just modify my scripts if I wish. That is not the point; not at all.

This is why we don't need people working on incompatible things when we can work on the same thing and get it done faster.

Again, I'm not the one arguing.

This is what happens when you let four mice out into a cage with cheese at both ends. You want us to work on this thing, we want to work on our thing, and no-one is happy. At present, I think what we want to accomplish, is to get our planned changes in and done, and get out a new version that is both more sable, and offers more to the user, before even considering any other radical changes.

For the most part, expanding the capabilities of ZScript, and adding non-scripting features so that scripting is not mandatory for various effects; and adding in other elements that are useful to scripter and non-scripter alike, have a higher priority to us than making structs, or other far more advanced concepts that AS may offer. What's the carrot here?

I'm the only one adding in actual ZScript commands. I have no problem with the system of doing this at present, and no urgent need to change it. My complaints stem from how the ZC classes are designed, not the way to implement things in the scripting language.

Dimentio wants to work on weapons, items, and strings. He hasn't shown the slightest interest in working on ZScript, AS, or the parser.

Grayswandir seems to enjoy the challenge of adding things to Flex-Bison. I don't know if this is my false perception, but he appears to get a thrill out of making new things work, that he himself added.

The only person so far that seems to care is Successor. Hell, even Tamamo is opposed to this, for no reason that i can clearly comprehend, other than to want something else that she has no specified. Should we just do a Ruby parser, and be done?

-------------------

I know that there is a long-term benefit involved, but when I say that it will be a while before I can get to it, and you flat-out threaten to quit, that just tells me that you don't give a damn. I know you are going through hell in your life. Some of the rest of us are in pretty bad spots, too. I can't just stop everything I'm doing to work on some new aspect that I don;t believe needs to be done immediately; particularly when it is too much trouble to read one of my replies, much less to read through any of the code changes, or other stuff that I've done, or other threads on matters that I feel are important.

Your time is valuable; so is mine. I can't say which is more finite, and limited. I can say that I'm getting far too old to care at times. You probably feel likewise.

-------------------

Arrays are not pointers. Again you refer to /our/ meaning this is a personal matter, not one that reflects the overall ZC community.

See above.

My reference of 'we', 'our', and such, is as a collective, referencing the totality of developers and users; in this case, the types that ZScript, and everyone using it, uses: int float, bool, npc, *weapon, ffc, itrem, itemdata. How was that coded that it wasn't clear?

What /are/ you doing for ZScript? How am I supposed to know that? Where is the code that does it, or, the spec that defines it? Don't get mad at me for being in the dark here... O_o

[/quote]

Everything that I've done is out in the open for scrutiny. I don't feel the need to post every little thing, so I keep a change log, and 'update' docs that anyone may elect to read.

Source Pack
Change Log
ZScript Changes | (Abbreviated form.)
ZScript Syntax Changes
ZQuest Changes
ZStrings Changes
ZC Changes

ZoriaRPG, the major premise in your post appears to be that if ZC does not support old ZScripts integrating flawlessly with new features, then everybody will refuse to adapt and the change is not worth doing.

I think this position is more conservative than the historical evidence has borne out. Nobody cares nowadays, for instance, that ZAsm is completely incompatible with ZScript and that you cannot easily write ZAsm scripts that interoperate with ZScript. Similarly, if some new hotness like scriptable enemies and weapons works only with AS, I think scripters would learn AS a lot quicker and adapt a lot faster than you give them credit for.

Hmm... Who, in reality, ever used ZASM? I did, a little bit. I know of what..one other user who did? I published one whopping ZASM script in the last ten years, and it does in fact, interoperate. It is designed to do precisely that, to allow 2.5 users to use a feature that was never implemented in ZScript. :p

I think you underestimate two things. One, is that the majority of ZScript users are not programmers. They manage to hack their way around, stumbling blindly at times, and they are more than happy to accept horrible, bugged results, if they work for their application. This tends to lend to laziness, and the desire not to move to anything new.

The second, is that the number of scripters out in the wild is small, and compared to the library of extant scripts, any new material is likely to me marginal, at best. This limits the resources for the user, and my considerations have the userbase in mind as a whole on this basis, not merely if something is inconvenient to a scripter. It's hard enough to explain how to import and compile a basic script to the average user. They simply are not willing to learn; and stemming from that point, they are not going to edit scripts to bring them in line with a new spec.

No, instead they will ask the scripters to do it for them, as they always do; and this time, no-one will ave any clue what to do, save for perhaps five of us. I can name only one scripter who is a programmer, can comprehend these changes, and is not in some way involved with ZC dev: MoscowModder.

(What happened to that userbase poll? It wasn't by job to run it. In fact, I stayed 20 metres away from that, to avoid any possible impression of a conflict of interest.)

All that said, nobody here is ruling out a 100% working cross compiler, or fully functioning messaging system that supports ZScript and AS side by side. These are separate questions from the main topic here, which is brainstorming a messaging/callback system, a change that will help tremendously in making enemy and weapon scripting tractable, no matter what language the scripts use.

You are right that working simultaneously on AS and ZScript messaging is a spreading-out of scarce resources, but if you and Dimentio care passionately about maintaining compatibility of ZScript, perhaps you can help out with this task. As far as I know nobody (including Gleeok) objects to ZScropt and AS working side by side for the time being.[/QUOTE]

The problem here, is that the idea of them working, side-by-side, seems to be like a pendulum. If they do, fantastic. I couldn't ask for more, as it gives the choice of which to use, to the user, and the choice of which to expand, to the potential developer. I' am however, a bit weary of repeating that I do not have the time at present to dedicate to learning how AS works internally, en lieu of working on my present goals. I suspect that @Dimentio feels likewise.

We both have very specific, and compatible, end-results in mind. There is in fact, a reason that we three, decided to work together. It's because we do not bicker about what we see as our vision for the next ZC/ZQ version. I certainly can't help with a task when the goal is as clear as mud.

The bottom line for me, is that any one of these outcomes should be true:

1. AS is not 100% compatible, but future versions will still support compiling ZScript code. We may even continue to update ZScript, and support both in parallel for a while.

2. AS is 99.9% compatible, with a very rare instance of something needing a change. Note, this does not mean changing types, or how some 'advanced' tricks' such as pointer handling are done. We still support ZScript, somehow, if it is needed, but we don;t spend much time on it.

3. AS is perfectly compatible, every single thing works, we abandon ZScript, and march merrily along.

4. AS doesn't work as planned, and we make ZScript 2.0 the next big bombshell.

The result that I won't accept--meaning, I would be 'done'--is:

D. AS isn't perfectly compatible and we kill the ability to compile ZScript code.

Does that suitably clarify my position on the matter?

If 'ya'all' want me to work on this stuff too, then please, make my job easier. Go over my proposed changes, select what you won't take from the list, let me wholly integrate the rest, and be flipping done with this hellish merging process, so that nay future revisions can be kept in sync with the main codebase. I simply cannot spend countless hours doing, and redoing this shyte.