AngelScript: The Revenge

[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