AngelScript: The Revenge

[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.

[DarkDragon]

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.

[SUCCESSOR]

I was wondering about why we would develop zscript into a message based language if we were implementing AS

Let me collect some points

Reasons for implementing AS:

Its fast
- it gives us the changes we want in a faction of the time it would take to do the same in zscript with a more robust end result

AS is better
- angelscript is a fully developed, tried and true which will outperform zscript. Zscript was hacked together from some DIY kit and ZC s main devs from the last few years were loathe to touch it.

Reason against AS or doing AS/ZS parallel:

Some users might have to deal with a change

Masochism

[Gleeok]

@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!?

2) int a = 0.5; This will end everything and the sees will boil! ...No. This is caught at compile time. No debugging required, just change the stuff to other stuff when the compiler tells you you fucked it up. ...or... just don't convert it to AS and keep using ZScript. Old quests will still work. ZScript will still work. I've said this enough already.

I know that your scripts are hacks built around the fact that ZScript is very limited in features. Surely you also must recognize that your scripts are by far the most 'out there' and are not a good sample of normal scripts. I'm sorry that migrating your stuff over to AS is by far the absolute worst case scenario, but for most people it's nowhere near as bad. So just keep using ZScript if you want.

I've used angelscript for two side projects over the last 6 years. It works great. The only people not in favor of improved fully-featured script support for future versions seem to be you and Dimentio. If you can explain that without strictly /personal/ reasons or motives and why it is not good for future ZC users then I'm all ears. If you can't then, well, we're just going to have to bring back General Bitching.

[DarkDragon]

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.

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.

[Gleeok]

First thing is first.

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

Are people actually doing this? There's so many things wrong with this I can't even fathom. AS will not and should not support this.

[ZoriaRPG]

First thing is first.

Are people actually doing this? There's so many things wrong with this I can't even fathom. AS will not and should not support this.

Absolutely. Here is the common way that is is used for ghost scripts:

ffc script ghostffc{
    void run(){
        int arr[32];
        ///
        function(this,ghost,arr);
    }
    void function(ffc this, npc ghost, int ptr){
        this->X = ptr[3]; //etc
    }
}

Literally 'every script' that Moosh and Evan have made, does this; in their own words. Evan's statement when I discussed it with him, over a year ago, was something like this:

'Please tell me that this will never change. Everything I do relies on that.'

This is also how many scripters commonly use arrays in scripts, for engines, and otherwise. It is why I brought up array pointers, multiple times. I don't even know of a way to pass arrays in Zscript, otherwise. You need to store pointers for local arrays, to allow other external scripts to access them. Hell, I do it in ffc scripts, by storing the pointer for the ffc's local array in a Misc[] index, then referencing it with external functions. This is because scripts are not handled like classes, and their local variables/arrays can't be accessed with scope resolution; and of course because array pointers aren't handled as in C.

Quite a lot of that is due to the limited size of the Zscript stack, but that doesn't solve the issue of compatibility. No simple change of types, or preprocessor warning, is going to fix this.

If AS supports scope resolution to do that, that's fine; but in order to preserve the extant scripts, if the AS parser can't handle this, then the ZScript parser will need to be maintained in parallel, somehow.

Do you see my reason for concern? I can say with surety, that over 30% of the scripters still around do this stuff, and that half or more of the ZScript Skype members do it routinely. Every ghost script that I have seen from Moosh and Evan does something along these lines. They expect that a pointer can b e passed as an integer; plain and simple. 95% of what all of us do, would break, without this.

I'll even go so far as to note that I recorded a stream explaining how this works for a user, last week. He needed to be able to reference an array local to an ffc with external function calls, so I showed him how to do it, along with a series of warnings. If you want to view that stream, I will upload it. The point is that is is common enough that scripters teach it to one-another, and to new scripters, as the 'standard method' of doing this.

I'll add as an anecdote, that I'm stunned that you aren't aware that ZScript users have been doing this for years. I learnt this technique from Evan, Moosh, and Gray. It explains why you dinna' sense my level of dread when discussing this earlier, why you didn't know why I was mentioning pointers, and some other key factors that I have tried to bring up, only to be met with silence, or seem'd disregard.

[Gleeok]

They only do it because you have to use hacks to get around the limitations in ZScript. ...But at least tell people that they should not do this with global arrays, or, at least no global array should be used to propagate this behavior from local arrays.

In AS no hack is required; you can pass arrays from anything to anything else if you want so long as it is type-checked. You can even get member variables declared in one script by another script. Heck, you can even have 100 global scripts communicate with each other and destroy/create each other. These are all built-in, and very simple to use script-side and c++ side. That is why I say we'll be saving years of dev time.

But AS compatibility just dropped to no higher than 98% now.

In the future just post the thing that is relevant so there's no confusion. I've never seen anyone do this, and it technically should be a compiler error, although it's a little late for that.

[ZoriaRPG]

They only do it because you have to use hacks to get around the limitations in ZScript. ...But at least tell people that they should not do this with global arrays, or, at least no global array should be used to propagate this behavior from local arrays.

In AS no hack is required; you can pass arrays from anything to anything else if you want so long as it is type-checked. You can even get member variables declared in one script by another script. Heck, you can even have 100 global scripts communicate with each other and destroy/create each other. These are all built-in, and very simple to use script-side and c++ side. That is why I say we'll be saving years of dev time.

But AS compatibility just dropped to no higher than 98% now.

In the future just post the thing that is relevant so there's no confusion. I've never seen anyone do this, and it technically should be a compiler error, although it's a little late for that.

(Emphasis, mine.)

A little late for this now, too. I do warn that they need to refresh pointers, and that it can be dangerous (because you may be using the wrong data later), but even I need to do this, but I don;t need the data to persist between saves when I do. I do it because I store all of my global values in one array, and I use indices for pointers. I also use this a great deal for string pointers, to make them available between scripts, externally. That's another area where this is often applied.

Sure, it won't matter for new scripts, but I'm still waiting for absolute clarity on if compiling old scripts via the ZScript parser will be maintained in your plan here. That alone will resolve most user issues, point blank. If they can still use all of their old stuff as-is, and they have the option to convert it to use new features, that would be ideal. I don't have a problem committing to support both languages, if you don;t have a problem allowing me to support both languages.

Hell, I even added a way to get other-typed pointers to my fork. I need to be able to do that, to reference them externally. That's because there is no way to make a global typed array. Even DD admitted that with the stuff that we do, global special type arrays are pretty much needed for ZScript. Not to force pointers to persist, but to store them globally per-session, and to be able to store and reconstruct special-typed data. That is what type->GetPointer() does, as I had mentioned earlier.

Now you know why that sort of thing is so useful to us. Some of my magic is simply impossible without it. That equally applies to everyone else. You should look at Moosh and Evan;s scripts at some point though, and see how common this is. Lejes also used it, as i recall, and I'm fairly certain that it is as common as dirt. Is it because it is a hack required to do something? Certainly. Is that actually bad? I think it;s arguable. You can pass arrays by reference in C/Cpp, which is the equivalent of this.

I'm not sure precisely how AS does it, but clearly it has to allow passing arrays and strings by reference and using them in functions and elsewhere without worrying about scope issues like this.

Take a look at when I documented this on the Wiki. You might want to read some of this stuff, at some point; you know? (That is my comment, at the end of the page, too.)

I should further note that this is similarly used for psuedo-2D arrays, and for mass string handling, and en-queueing.

int string1[]="foo";
int string2[]="bar";
int string3[]="rats";
int string4[]="meatballs";

int strings={string1,string2,string3,string4};
//Draw strings to the screen in a for loops using the 'strings' array, one at a time, adjusting their positions.

That is how every quest that has scripted credits rolls, scrolling text, or otherwise handles this. make the strings, and store their pointers in an array, so that you can iterate them with drawstring using a for loop (using their pointers).

int subscreen[265];
int positions[16];
int items[16];

//etc

subscreen[0] = positions; 
subscreen[1] = items;
//etc

//iterate subscreen[] and do all events from the iteration, because ZScript doesn't have real 2D or 3D arrays. Huzzah

I am not joking when I say it is used EVERYWHERE, by EVERYONE. I know for a fact that Lejes and MoscowModder did both of the above things. This is how I was taught] to do it. Hell, does Tango.zh do it for scrolling strings? Probably not, but everyone else that does scrolling text, or wants to manipulate many strings does it.

I was taught the '2D array' thing by MoscowModder, and people often (poorly) explain it as 'storing one array within another', which it does not do. I always clarify that you are merely storing the pointer. @Grayswandir also teaches it to everyone, as do I. It is a staple of ZScript. :p