AngelScript: The Revenge

[ZoriaRPG]

I don't read/write from ZASM bytecode at all. It's all separated. ZScript is only 32 bit integers, so this best maps to int by default. Having AS to be responsible for maintaining legacy zscript bytecode was never a goal, and I suspect never will be, but even though I'm not going to do it, maybe someone else will.

AS can work with native types easily, this includes pointers, primitives, and structs. ZScript can only handle one type: long.


You're thinking about it the wrong way:
The truth is nobody really wants (or has enough experience) to work with the ZC code because the reality of breaking computability is such a huge burden that most people are crushed by it instantly when they realize how difficult simple refactoring or other trivial things could become. In addition, we're basically running out of useful things to add to it due to complexity of working with the old systems. I'm not going to be able to get to a ZC 3.0, the best I can do is clean up some of the allegro stuff and replace it one thing at a time. You guys are pretty much the only new people who are working on ZC right now. Surely you realized by now that it's way more complicated than it needs to be, and that for all the cool stuff and good work you guys have done on 2.5x the amount of time spent for very minor improvements is sort of disproportional. If the next-gen of ZC developers want to do things differently, or even the same, then they should have that option, and I'll support them. Saffith has moved on, and the truth is I never really came back. I'm still semi-retired, and will probably stay that way for a while; I just have too many other things to do. At least Dark Dragon is currently around for the time being.

AS is something that is documented, works well, an anybody can work with without too much trouble. It's more for the future of ZC rather than the past, to put it one way. We won't even add it until 2.6 so it doesn't interfere with 2.5+.

What I read out of this, is that the plan to have this new system compile legacy scripts is dead, so, we should still be working on the ZScript parser for 2.54, 2.55. Correct?

If you truly feel that you are going to be passing the torch to us, then you might want to have a pow-wow with us and we can discuss our own goals. I wanted to work n stuff like this for 3.0, but I also wanted to do a substancial amount more, and while that may sound fantastic, the reality is that it will take time to get there. I feel that 2.54, w.55, and 2.6xc should be a slow migration away from some of the nastier elements, but not a dramatic shift.

If you get an AS implementation that we can use in one of those later shifts, fantastic. It just seems to me that we're falling back on the 'doesn't need compatibility' model, which is fine, for a wholly new ZC version.

I would frankly rather see you devote some time to the drawing stuff, and to the ffc stuff--specifically, user called ffcs--and such, sot hat we can integrate those. I would like to be able to offer something new before the Sommer, so that we attract some users to it, when they have free time, and revitalise the whole bloody thing, as the present userbase is fading away into oblivion partly from the static feeling of the programme.

I suppose the truly twisted thing, is that I'm not intimidated by the sources. I sort of feel at home, and comfortable with them, which is why every time we have a debate like this, I lose my mind.

I have no idea what your definition of 2.6 is any longer, but it is sounding more, and more, as if you mean 3.x; that is, more major changes than what we are even discussing now. Is that right?

Did you foresee two releases before this is added at all? DD was sort of going in circles with some of his planned parser changes, waiting to learn when you were planning to introduce this component, and expecting that it would be script-compatible with all present user scripts. These are the types of things that need absolute clarity.

At least you can see that we're doing something with this, and we didn;t just volunteer to work on 2.54without following through; but the continual change of plan, change of focus, and such, is also putting a pretty big burden on us, to regularly rewrite, re-merge, and changes things that we already completed. I want to solidify some plans, and I need to know if there is going to be a problem in your eyes about some of our plans, or if we should just be doing what we think is best at this stage, with some assurance that the codebase and our changes aren't going to be changed again, in a radical manner that undermines them; and that we won;t be required to rewrrite large sections for a third time, respectively.

I would have already had the merge done, if not for this; and beyond that, my own changes are so extensive, and through so many files, that handling an incremental merge is a tremendous nightmare. The fact that I am at all willing to do that should emphasise my dedication, but I have points where this diverts to bicker mode, and I just cannot care enough to do a blasted thing.

I stalled out again, because of this. I see this going back and forth, and people who are no in any way involved with the development work arguing for or against it, and I don;t feel like working on it. We need to solidify the plan for what is going in the next two releases. The modernised ZScript parser is very close to done, and we can use that. I feel that we should use that, and when you have a working parser, we can look at a way of making it work, and cross-compiling to it, or whatever we want to do.

At present, for canonical ZC, you are the only person with authority to make decisions. If you don;t want to do that, and want to work with us on deciding what belongs in it, then we need to have a discussion on that elsewhere, because I sincerely have no idea what is happening, and I'm not going to pour countless hours into this without knowing the direction. Your definition of 2.5+ is needed here, as I don;t grasp it, and you previously referred to what we were calling 3.0 as 2.6, and I am still very much against any radical engine change, or rewrite being in the 2.xx family.

I'm not willing to work with fully arbitrary version numbering. This is mad enough, without a numbering scheme with no sanity.

In the meanwhile, I need an answer from you in the npcs and items thread, and I'd like to see the script drawing integrated--and we need to discuss that in detail.

[Gleeok]

@ZoriaRPG :

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

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.

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.

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.

[SUCCESSOR]

Zoria, I love your determination and ambition, but some of your concerns are irrelevant. It doesn't matter if we say 2.6 or 3.0. It doesn't matter if this introduces a drastic change while you tinker with smaller, more useful short term contributions. Nothing about this makes your work for naught.

As a person who has long been wanting to get into contributing to ZC and long intimitaded it, I would rather spend 2 years working on a drastic change that could be a boon with trade off than working 5 years to make stable a few improvements that sounded good at the time. I'm really not interested in playing 10 thousand piece pick up sticks. If that means I have to spend more time digging through documentation and learning implementations of something more complicated then I'd rather put in that work.

[SUCCESSOR]

How about we drop referring to theoretical builds by number and give them code names like Zelda Modern for the rewrite that will never happen.

Like for the Angel script build it can be... I dunno. Xen. That sounds heavenly.

And you already use Future for your stuff.

There ZC X and ZC F

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

[Grayswandir]

Like for the Angel script build it can be... I dunno. Xen. That sounds heavenly.

And you already use Future for your stuff.

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

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