AngelScript: The Revenge

[ZoriaRPG]

Right! This is the key question. I could focus energies on some of the changes that have been discussed on the forums and in chat (making inter-script communication easier, tracking pointers over time easier, scripting weapons and Link, etc). But if it sounds like transitioning to AngelScript makes more sense, I want to avoid introducing new features that will make cross-compilation harder.


Well, it's true that *ZASM* must be supported. But not necessarily ZScript (we guarantee that old quests will play in new versions; I agree it would be very nice if old quests can be edited in new versions too, but this is not as bedrock of a principle IMO.)

Let me ask you this: is there any reason to support ZScript, *other* than backwards compatibility of old scripts? If there were a ZScript cross-compiler, would this be sufficient? Or is there a fundamental benefit to supporting both languages?


Agreed. Taking stock of past lessons is a key first step to planning for how, and if, to transition to ZScript.

(Emphasis, mine.)

This is precisely why AS was abandoned over every other concern. The ability to download an existing script, and compile it in ZC, must be preserved, whether we change the extant script engine by adding new things to it, or change it out to something else.

Simply supporting ZASM in quests, is blatantly insufficient. I won't even contribute to a ZC version that breaks this capability. 99% of my output for ZC in the last five years, is script-based. It'd be the biggestr slap int he face, to the community, to say, we won't suppose any of that anymore, and it reduces the amount fo available resources for the questmaker to zero.

If cross-compiling is invisible, all the existing quirks are preserved, and all the extant types are preserved in identical syntax, implementing both engines at one time is not as critical. It would be nice, but not critical. If even one capability of ZScript is un-suppprtable, then we need both. Simple as that. It doesn't prevent compiling down to the same functions on both ends of things.

You saw the reaction of just changing a directive. Magnify that tenfold, for any change as radical as this. The only users interested in AS were hardcore programmers, FWIW.

I honestly can't think of any nuance of the language that is not in use.

If you want to drop ZScript entirely, and can't support its codebase, then you may as well just start from scratch with ZC, make it clean, make it new, make it Z3 scrolling banana cream pie, and enable classic quest emulation, as ZC 3.x. This was the exact plan a year and a half ago. 3.x would be wholly new, with AS, and those of us who wanted to continue developing 2.,x would do that, which is where 2,future came from, and the origin of its name.

If you want to go that route, then I'm pretty much out of it until it is reasonably put together. Building an engine from scratch on top of everything else that I'm doing just isn't feasible for me, but once the basic structure is in place, I'd be willing to work on it. Then again, you need more than two or three people for that to be a realistic venture; so you can see why this was dropped. It went in circles for a year, arguing about flipping implementation, until we resolved just to expand what we have at present, and decide on AS after we get a bunch of other stuff out of the way, and do one or two updates; then bring it back to the table.

I really don't feel like arguing for or against it again until we reach that point, and can do at least a minimalistic implementation in a cleaner engine, and see how it works.
@Dimentio : I could call it PuddingScript-Z if you want. The name isn't the issue. I agree that the only way we could do this is if existing syntax is maintained. I also have zero interest in doing it now.

TBH, it just feels as if we're all reaching here, and that we're getting very far ahead of ourselves.

I should note, that on a purely personal level, I favour a more robust ZScript implementation. As long as we're able to do this, and it seems that we arwe, with three of us willing to work on it, then the point of the AS migration--nobody wanted to work on ZScript--is less of an issue. Over time, I think we could support just about everything that AS supports, and possibly more, with a performance gain at the end of the day.

The main push for AS was additional C Syntax, and stuff like structs, that we are on the verge of adding to the existing language.

I just don't have the answers that you want, I suppose, but I don't think that what we're trying to do would make cross-compilation harder if in three to five years, we decide we want this.