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.