AngelScript: The Revenge

[DarkDragon]

Almost exactly a year ago there was discussing about switching ZC to using AngelScript instead of ZScript, and it had some support at the time, and Gleeok and Saffith did quite a bit of work on incorporating AngelScript and porting over some of the engine internals... and then it was backtracked.

Gleeok in another thread posted

This would allow new systems to be created that can simply piggy-back off the old ones but also be tightly coupled with scripts that can actually rewrite built-in behaviors without having major issues or losing compatability (or creating bugs with existing quests). The new npc scripts and supporting of various global callbacks I envisioned would be a good test of that experiment before doing anything else with that. ...It's not been worked on really, but it should be. .. :/

I think I'm going to make putting in the compiler/script processor/script engine my next priority besides the few other things I have here. Even if it's not used immediately, if I can get a ZScript->angelscript conversion utility working you might take it more seriously.
and so I wanted to (re)start a discussion about AngelScript in ZC. Some points in particular I'm curious about:

1. What were the lessons learned last year during the effort to incorporate AngelScript? What are the big challenges?
2. Is it feasible to switch to AngelScript while maintaining compatibility with old quests (presumably, this would require only supporting the ZASM interpreter, and ZScript could be dropped entirely)? Or would an AngelScript-driven ZC live in its own ecosystem separate from the existing program and quests?
3. What concrete steps would need to be taken to adopt AngelScript, to minimize the time until we have a functional release candidate, if we decide to do this?

Making a plan sooner rather than later seems prudent, as it will help dictate whether effort should be put into expanding the power of ZScript, vs. working on its replacement.

[ZoriaRPG]

As I said at the time, I'll mostly be focused on ZScript in any regard. Even if you want to shift over, supporting both, for a while, seems mandatory; and I do not see the problem with crosscompiling. tuning the ZScript parser, introducing some new syntax over time, and slowly migrating would make the whole transition cleaner. I also see no issue with supporting compiling ZScript into AS> The AS model is designed to accept additional syntax types, which is why it was originally an attractive model.

The other end of the question, is that is the change better than say, just making ZScript far more robust, and implementing the types of things that we could do with AS, using the existing language.

I do not see ZScript as something separate from ZC compatibility issues. If you want to support all the qussts ever made, you need to support all the ZScript ever made with them.

Another approach, is to integrate both. I could throw together a block diagram of this, if you want. You could pretty much have a core with two lines of communication, and some interrupts, to allow parsing instructions from both AngelScript, and ZScript, into a core engine; or you could base the core engine on AngelScript entirely, and use ZScript inputs to that, as we do with the present ZC engine. That would probably be my approach to it.

I've said many times, that I do not object to AS in premise, only to the older planned implementation, which was essentially 'We don't want to spend the time to do this properly.'.

Just about everything that AS does, can be implemented in ZScript too, which could allow the user to select their preference, and cross-compile between the two, for the most part, for a while. From there, you can slowly phase out support for ZScript, if you desire; or whatever. I think I plotted out a multi-release timeline for that, and no-one ever wanted to look at it, because they didn't want to ensure that a high level of compatibility exists between old, and new scripts.

There are other options, too. Gleeok wanted to do a C# thing, and I am not a fan of this, mostly because the C# syntax is very much a Microsoft thing, and cross-platform support is--or at least was--farcical. If we wanted to do this, I would like to see the core ZC processes minimised to very basic things, and the script parser take over to handle most events. We can have that conversation separately, but right now you have a total of what, five of us involved?

I would like to focus on ZScript for the next two versions, at least, possibly integrating something new, in part, starting with the second, and slowly progress into it, if we want to do it, over the following two. (That equated to 2.55, 2.60, 2.65, and 3.0.)

I would love to be able to offer both over the long term too, but how problematic that might be, I do not know. The flip side, is that this falls into the same category as shifting to Allegro 5, or other radical changes. The present state of the engine needs encapsulation of some kind first.

Saffith was the only one who worked on shifting the engine to an AS core. There was a branch with his enemy code, where the internal enemy code was replaced with AS scripting stuff. I recall that he purged it because it was some kind of unworkable nightmare for him, at the time, but I could be mistaken. It would be nice if he documented what he tried to do, what worked, and what did not.

[DarkDragon]

The other end of the question, is that is the change better than say, just making ZScript far more robust, and implementing the types of things that we could do with AS, using the existing language.

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.


I do not see ZScript as something separate from ZC compatibility issues. If you want to support all the qussts ever made, you need to support all the ZScript ever made with them.
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?



There was a branch with his enemy code, where the internal enemy code was replaced with AS scripting stuff. I recall that he purged it because it was some kind of unworkable nightmare for him, at the time, but I could be mistaken. It would be nice if he documented what he tried to do, what worked, and what did not.
Agreed. Taking stock of past lessons is a key first step to planning for how, and if, to transition to ZScript.

[Dimentio]

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?

To please people who use both languages. I myself have not tried AngelScript, but I am to understand that there are quite a few things different with the format of AngelScript then ZScript? Muscle memory is a hard thing to rewire. Isn't AngelScript a more object-based language? Does AngelScript no longer have ints and floats be the same thing like ZScript did? It would take quite a bit to get used to.

Also, there's the fact that people would have to write 2 versions of the same script: one for Angelscript to please the current version users, and one for ZScript to please people still using 2.50.x. People still use 2.50.0, for crying out loud (http://www.purezc.net/index.php?page=comments&t=comments&id=3499). If we keep ZScript support, people don't have to write 2 versions of the same script.

Finally, think about it: ZScript? As in ZC, or ZQuest? The name just fits. :P

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

[Gleeok]

I'm against coalescing ZScript/Zasm/ and angelscript (hereby referred to as "AS") into some kind of hideous amalgamation (at least initially), mainly due to the fact that AS will have no compatibility concerns or other integration nightmares to worry about. Pounding on the keyboard with a free mind can be a powerful tool after all. :) The 18-bit "fixed" experiment that is a ZScript integer/float/bool is going the way of the dinosaurs though. If anything ever needs to interact with allegro's fixed it can be done in c++ code.

Since everyone has their own agendas for now, I think I'll just start it and see where it goes. I believe I have the most experience with AS ((I've used it for 2 projects in the past) and I don't particularly like getting into theoretical arguments so we'll just see what happens. I'm a bit rusty with AS however, so it's not like there's going to be a new script setup overnight; the bindings alone can be very time consuming. I will "play nice" with everyone and not integrate into ZC anything into the main branch, so there's no fears of extra libraries or anything that will affect what anyone else is doing, so no one has to worry about it.

The priority at first is getting all the basic stuff together and have the compiler to be separate from ZQ so that eventually scripts can be modified on-the-fly--I imagine a scripter writing a script while testing it in ZC and then just pressing 'R' and within a second it can recompile the scripts for them. We'll see how hard this is in practice. I'll have to look into how the module system in AS might work with this as well, so there's enough preliminary stuff to get out of the way before anything major.

[Gleeok]

1. What were the lessons learned last year during the effort to incorporate AngelScript? What are the big challenges?
2. Is it feasible to switch to AngelScript while maintaining compatibility with old quests (presumably, this would require only supporting the ZASM interpreter, and ZScript could be dropped entirely)? Or would an AngelScript-driven ZC live in its own ecosystem separate from the existing program and quests?
3. What concrete steps would need to be taken to adopt AngelScript, to minimize the time until we have a functional release candidate, if we decide to do this?


1) No idea. :P Although I'm in the "existing enemies should remain for compatibility reasons, and 2.6 scripted enemies get a whole new class and interface" camp, Saffith showed off a taste that you could indeed script every single enemy type ZC has directly in AS, which is pretty amazing. What I'd like to do is just make it easier to do this.
2) No idea!? :P What do you think?
3) No idea!!! :P

FWIW: There is a horizon effect at play here DD. ;)

[Tamamo]

1. What were the lessons learned last year during the effort to incorporate AngelScript? What are the big challenges?
2. Is it feasible to switch to AngelScript while maintaining compatibility with old quests (presumably, this would require only supporting the ZASM interpreter, and ZScript could be dropped entirely)? Or would an AngelScript-driven ZC live in its own ecosystem separate from the existing program and quests?
3. What concrete steps would need to be taken to adopt AngelScript, to minimize the time until we have a functional release candidate, if we decide to do this?

1. All enemies can be recreated in angelscript, but problably shouldn't be since they die after one frame for some reason.
2. Yes, as you said support the ZASM interpreter and I think we're good.
3. A detailed design doc how it's going to work would be nice. Yeah I know most you hate those.

[Saffith]

As far as I got with it, it was very easy and worked fine. There was a little issue with the wall masters - for some reason, they made Link scroll to the next screen instead of warping, but it only took a minor adjustment to fix that. Aside from that, everything continued to work perfectly, ZScript and all.

The only real problem I ever had was that it didn't work at all for Gleeok. That seemed to have something to do with how return values were handled, but we never ruled out things like compiler issues, as far as I recall. Really, the reason it was rolled back has more to do with my personal problems than anything else.

There is some question of how much overlap you want between old and new stuff. Should new things continue to be based on the same sprite class, with its fix coordinates and miscellaneous garbage? It would be feasible, and I think not even difficult, for compatibility scripts and new ones to use totally separate base classes and script engines. That's a big plus, in my view - a lot of the legacy cruft can just be moved neatly out of the way.





As for ZScript, it has a variety of issues. The number system doesn't match data types used internally, and the conversion is inefficient and produces unexpected results (2.0/3.0==0). It's difficult to add new built-in functions, and overloading them is currently impossible, as far as I can tell. But the single biggest issue is the extent to which it depends on ZC's internal behavior. In many areas, ZScript was not designed with the notion that things might change.

Consider this simple bit of code:

for(int i=0; i<176; i++) {
if(Screen->ComboT[i]==CT_WATER) {
This iterates over every combo on the screen and does something whenever it finds water, right? Wrong. It iterates over combos 0-175 and does something whever it finds a combo of type 3.

Say scrolling is implemented. Now instead of screens of 176 combos, you've got rooms with varying numbers of combos. This code doesn't necessarily cover the whole screen anymore. It will still work, but not correctly.

But that's the easy problem. Suppose the combo system changes. Instead of a limited number of well-defined combos, you can now give each combo an arbitrary set of properties. Maybe you make combo #3 a magic-reflecting, poundable hookshot trigger. The script isn't checking for anything like that; it just assumes combo #3 is water. Again, it will still work, but not correctly.

ComboF has similar issues and more. What if it becomes possible to place multiple flags on the same combo? ComboF can't handle that at all.

What about DrawZOffset? Currently, it doubles as HitZOffset. That should obviously change, but existing scripts that uses it were made with that quirk in mind. They won't work correctly without being updated.

New warp system? Warp functions break.

Quirks, bugs, and old behavior can often be imitated, but there are limits. In particular, when a feature is used in multiple different ways, they can't all work. For instance, going back to scrolling again, what happens to drawing functions? Currently, coordinates on the screen and coordinates in the world are the same. If the screen can scroll, that's no longer true. It will have to be one or the other in existing scripts, and some will break.

To some degree, these problems are inevitable, and I'm certainly not under the impression that switching to AngelScript automatically fixes everything forever. The point is that the notion that updating ZScript instead will keep existing scripts working is wrong. Many scripts will break, and it's going to be every bit as difficult and confusing for average users, if not more so. Yes, it will be easy to update these scripts most of the time, but it won't be significantly easier than converting them to AngelScript.

There's nothing AngelScript does that can't theoretically be added to ZScript. But it's a lot more work, and the benefit to users is dubious.

[ZoriaRPG]

I think we all know my views.

(1) Any implementation that does not suport taking a raw, existing zscript file, and processing it, in ZC, is out.
(2) I think that the engine needs heavy reworking before we consider changing the status quo.
(3) I do no tthink that the benefits of AS outweigh the implications of what adding it might do.
( a ) This includes the potential for an exponential number of new bugs.
( b) I do not think that the time involved* versus the benefit is a net gain.
(4) Any option that sacrifices compatibility of any sort, is to me, a bad idea. I do not mean quest binary compatibility, solely.
(5) I worry about the performance hit, which is likely to be notable.
(6) Moreover, I do not have the time to dedicate to properly learning the AS sources at present. i can work on ZC until, probably April. After that, I will likely have a six month or greater gap before I can focus on it readily, and I will be tapering off slowly toward April, as well. I expect it to take months for me to truly understand the AS underpinnings, so that's over a year before I could even know if I would want to work with it.

*I would expect to spent the time required to fully support cross-compiling with no syntax changes, and implement all of the existing features, or quirks. That kind of effort is absurd, and massive, when compared against what changing the engine gains for us. Anything short of this is just a sign that we lack the kind of dedication, or manpower, involved with the project to move it forward from its present engine condition.

This is something that we can still do, a few years down the road, if we still have an interest in it by then. With people actually working on the parser, and ZScript, most of what people want out of AS can be done with what we already have, with fewer risks, better stability, and better acceptance.

Please remember that the old 'plan' was to let us work on 2.x stuff, and make AS a 3.x thing that Gleeok and Saffith did, and that they supposedly weren't concerned with some compatibility rifts between these two branches of ZC. I have always wanted to ensure that new versions of the programme are compatible with all of the old materials, including scripts as raw files, not as assembly. I think that we have a plan now, we have focus, and we have people willing to do the work. Rocking the boat, for the fifth time, right now, is just madness.

This changed several times, with lack of communication being the underlying thorn. I'll also note, that seeing a working proof of concept is something I would need, to ultimately decide, but I'm just tired of the whole debate, and want to proceed with whatever amounts to our present, viable plan.

[Dimentio]

In my honest opinion, I don't think it's wise to go forth with switching to AngelScript in the near future. It's been 4 years since the last big ZC release, not counting bugfixes, and I think time should be devoted into getting an update with a good amount of new features within this year, instead of spending the next couple months (at least) trying to implement a new scripting language with... not all that much to gain in the short term? Longterm, sure, it'd be easier to develop for, but if we take too long to release a new update, people will start getting bored of what they have now and eventually just start moving off to other languages. ZScript might be bad for development, yes, but the last thing we need is another 8 year gap between major releases to add in a replacement coding language people have to learn all over again. Right now, I think the highest priority should be providing a decent sized update to renew interest, or at least keep it sparked. Keeping interest in the program trumps all other concerns, to me, and improving ZScript isn't impossible (Hell, look at what Zoria has been doing the past 2.5 months. Seriously, the guy is insane, props to him).

If we were to add AngelScript in the future, or at any point in time, we need at least one team working on faster 2.50 updates in the meantime, so if it takes 2 or so years to add AngelScript, people have updates to keep them interested long enough to see the big 3.0 or whichever update. We'd also need heavy communication between the two teams to add what the "filler" 2.50 updates add, so that when AngelScript is implemented, it doesn't just feel like a downgrade compared to the current version. If anything, it should be the superior version, so to get the early adopters on to start making content (and it should be superior in a way that's not significant. I highly doubt Angelscript by itself is a "significant" sign of superiority). Actually, the dev team should make quests just to go with the update, so that when people start playing it, they have content they can play immediately, that is exclusive.

Of course, that's just my opinion. I've never been involved with marketing... anything, really, so my opinion might not be worth much.

EDIT: Also, perhaps we should poll PureZC and see what they think?

[SUCCESSOR]

EDIT: Also, perhaps we should poll PureZC and see what they think?

So we can get more, "ew! change?! HSSSSSS!!!!"? Sounds great. Why not?

[Gleeok]

I've been working on the compiler/zscript converter today. Currently implementing Wait(int frames) which is a bit tricky if we want overly-generic coroutines, which I'm guessing is a no. Right now there are two problems:

1) Nested context calling. It looks like this feature is relatively new, but won't play nice with 1st class objects (eg; think ffc-ish types in ZScript). nested stack space from multiple objects that occupies the same memory sounds like a bad idea to even look into.
2) Modules: Another oldish new feature. Problem is different scripts cannot access anything outside their module unless it's a 'shared' object, which complicates everything from low-level to script level. If there's something like std.as or utility libs I don't know how this will work in practice. It seems like people will get around this by duplicating imported code so the only thing we gain is more RAM usage. :/ Not sure.

Right now I'm defaulting to "a script is it's own fully-featured script and nothing less", so don't over complicate anything right now.

Saffith : Have you messed with any of the above? Also have you written any angelscript stuff since the old repo? -Just making sure I don't duplicate anything unnecessarily.



EDIT: Also, perhaps we should poll PureZC and see what they think?

That sounds like a great idea. We all know how much purezc likes random polls! :P I assume it can either be or be by someone whom is unbiased on the matter?


[edit]
Another interesting thing. Consider the following on the same frame:



npc->Update()
{
...
waitframe();
...
}

npc collides with x.
script wants to know about it.

engine calls npc->onCollidesWithX()
{
x.HP -= 2;
this.HP += 2;
waitframes(6876);
this.HP = this.MaxHP; //invalid code path; never gets here
}


I'm assuming that the "intended behavior" is to resume the update method next frame?

[Saffith]

1) Nested context calling. It looks like this feature is relatively new, but won't play nice with 1st class objects (eg; think ffc-ish types in ZScript). nested stack space from multiple objects that occupies the same memory sounds like a bad idea to even look into.
I vaguely recall looking at that and thinking the same thing, but I don't think there's really any need for it. If you want to call a draw method or an event handler or something, you can just do it in another context.


2) Modules: Another oldish new feature. Problem is different scripts cannot access anything outside their module unless it's a 'shared' object, which complicates everything from low-level to script level. If there's something like std.as or utility libs I don't know how this will work in practice. It seems like people will get around this by duplicating imported code so the only thing we gain is more RAM usage. :/ Not sure.
Again, I don't think there's any need. I don't think there's anything that needs isolated, and there shouldn't be any harm in putting everything in the same module.


Also have you written any angelscript stuff since the old repo? -Just making sure I don't duplicate anything unnecessarily.
Nope, haven't touched it.


I'm assuming that the "intended behavior" is to resume the update method next frame?
That's a bit tricky. I was thinking event handlers shouldn't be allowed to Waitframe, since that makes things really complicated. Things like enemies that need to change behavior in response to events would either need to use update methods, like they already do, or have their Waitframes throw exceptions, which is of course a terrible way to handle it. It might also be possible to do something like a stack of AIs; when an enemy gets hit, you'd push a knockback state, then pop it when it finishes. That doesn't actually sound like a good idea to me, though.

Edit: Or make a Waitframe wrapper that returns any necessary state change info. You'd think that would be the first thing I think of. :p

[Gleeok]

Okay great. I think we're on the same page then.

[Gleeok]

There are *lots* of built-ins. I'm guessing about 100 or so can be deprecated though. Doing one section at a time hopefully wont be too bad.





namespace GlobalBindings
{
int32 Rand(int32 maxvalue);
void Quit();
void Waitframe();
void Waitdraw(); //?

// DEPRICATED ***
void Trace(int32 val);
void TraceB(bool state);
void TraceS(int32 s[]);
void TraceToBase(int32 val, int32 base, int32 mindigits);
void TraceNL();
void ClearTrace();
// DEPRICATED ***

// DEPRICATED ***
float Sin(float deg);
float Cos(float deg);
float Tan(float deg);
// DEPRICATED ***

float RadianSin(float rad);
float RadianCos(float rad);
float RadianTan(float rad);

float ArcTan(int32 x, int32 y);
float ArcSin(float x);
float ArcCos(float x);
float Max(float a, float b);
float Min(float a, float b);
int32 Pow(int32 base, int32 exp);
int32 InvPow(int32 base, int32 exp);
float Log10(float val);
float Ln(float val);
int32 Factorial(int32 val);
float Abs(float val);
float Sqrt(float val);

// DEPRICATED ***
void CopyTile(int32 srctile, int32 desttile);
void SwapTile(int32 firsttile, int32 secondtile);
void ClearTile(int32 tileref);
int32 SizeOfArray(int32 array[]);
// DEPRICATED ***
}


namespace FFCBindings
{
int32 Data;
int32 Script; // DEPRICATED ***
int32 CSet;
int32 Delay;
float X;
float Y;
float Vx;
float Vy;
float Ax;
float Ay;
bool Flags[];
int32 TileWidth;
int32 TileHeight;
int32 EffectWidth;
int32 EffectHeight;
int32 Link;
float InitD[];
float Misc[];
};


namespace LinkBindings
{
int32 X;
int32 Y;
int32 Z;
bool Invisible;
bool CollDetection;
int32 Jump;
int32 SwordJinx;
int32 ItemJinx;
int32 Drunk;
int32 Dir;
int32 HitDir;
int32 HP;
int32 MP;
int32 MaxHP;
int32 MaxMP;
int32 Action;
int32 HeldItem;
int32 LadderX;

// DEPRICATED ***
bool InputStart;
bool InputMap;
bool InputUp;
bool InputDown;
bool InputLeft;
bool InputRight;
bool InputA;
bool InputB;
bool InputL;
bool InputR;
bool InputEx1;
bool InputEx2;
bool InputEx3;
bool InputEx4;
bool InputAxisUp;
bool InputAxisDown;
bool InputAxisLeft;
bool InputAxisRight;
// DEPRICATED ***

// DEPRICATED ***
bool PressStart;
bool PressMap;
bool PressUp;
bool PressDown;
bool PressLeft;
bool PressRight;
bool PressA;
bool PressB;
bool PressL;
bool PressR;
bool PressEx1;
bool PressEx2;
bool PressEx3;
bool PressEx4;
bool PressAxisUp;
bool PressAxisDown;
bool PressAxisLeft;
bool PressAxisRight;
// DEPRICATED ***

// DEPRICATED ***
int32 InputMouseX;
int32 InputMouseY;
int32 InputMouseB;
int32 InputMouseZ;
// DEPRICATED ***

bool Item[];
int32 Equipment;
int32 Tile;
int32 Flip;
int32 HitZHeight;
int32 HitXOffset;
int32 HitYOffset;
int32 DrawXOffset;
int32 DrawYOffset;
int32 DrawZOffset;
float_or_int32 Misc[];
void Warp(int32 DMap, int32 screen);
void PitWarp(int32 DMap, int32 screen);
SelectAWeapon(int32 dir);
SelectBWeapon(int32 dir);
};


namespace Screen
{
float_or_int32 D[];
int32 Flags[];
int32 EFlags[];
int32 ComboD[];
int32 ComboC[];
int32 ComboF[];
int32 ComboI[];
int32 ComboT[];
int32 ComboS[];
int32 MovingBlockX;
int32 MovingBlockY;
int32 MovingBlockCombo;
int32 MovingBlockCSet;
int32 UnderCombo;
int32 UnderCSet;
bool State[];
int32 Door[];
int32 RoomType;
int32 RoomData;
void TriggerSecrets();
bool Lit;
int32 Wavy;
int32 Quake;
void SetSideWarp(int32 warp, int32 screen, int32 dmap, int32 type);
void SetTileWarp(int32 warp, int32 screen, int32 dmap, int32 type);
void GetSideWarpDMap(int32 warp);
void GetSideWarpScreen(int32 warp);
void GetSideWarpType(int32 warp);
void GetTileWarpDMap(int32 warp);
void GetTileWarpScreen(int32 warp);
void GetTileWarpType(int32 warp);
int32 LayerMap(int32 n);
int32 LayerScreen(int32 n);
int32 NumItems();
item LoadItem(int32 num);
item CreateItem(int32 id);
ffc LoadFFC(int32 num); // DEPRICATED ***
int32 NumNPCs();
npc LoadNPC(int32 num);
npc CreateNPC(int32 id);
int32 NumLWeapons();
lweapon LoadLWeapon(int32 num);
lweapon CreateLWeapon(int32 type);
int32 NumEWeapons();
eweapon LoadEWeapon(int32 num);
eweapon CreateEWeapon(int32 type);
bool isSolid(int32 x, int32 y);
void ClearSprites(int32 spritelist);

// DEPRICATED ***
void Rectangle(int32 layer, int32 x, int32 y, int32 x2, int32 y2, int32 color, float_or_int32 scale, int32 rx, int32 ry, int32 rangle, bool fill, int32 opacity);
void Circle(int32 layer, int32 x, int32 y, int32 radius, int32 color, float_or_int32 scale, int32 rx, int32 ry, int32 rangle, bool fill, int32 opacity);
void Arc(int32 layer, int32 x, int32 y, int32 radius, int32 startangle, int32 endangle, int32 color, float_or_int32 scale, int32 rx, int32 ry, int32 rangle, bool closed, bool fill, int32 opacity);
void Ellipse(int32 layer, int32 x, int32 y, int32 xradius, int32 yradius, int32 color, float_or_int32 scale, int32 rx, int32 ry, int32 rangle, bool fill, int32 opacity);
void Spline(int32 layer, int32 x1, int32 y1, int32 x2, int32 y2, int32 x3, int32 y3,int32 x4, int32 y4, int32 color, int32 opacity);
void Line(int32 layer, int32 x, int32 y, int32 x2, int32 y2, int32 color, float_or_int32 scale, int32 rx, int32 ry, int32 rangle, int32 opacity);
void PutPixel(int32 layer, int32 x, int32 y, int32 color, int32 rx, int32 ry, int32 rangle, int32 opacity);
void DrawTile(int32 layer, int32 x, int32 y, int32 tile, int32 blockw, int32 blockh, int32 cset, int32 xscale, int32 yscale, int32 rx, int32 ry, int32 rangle, int32 flip, bool transparency, int32 opacity);
void FastTile( int32 layer, int32 x, int32 y, int32 tile, int32 cset, int32 opacity );
void DrawCombo(int32 layer, int32 x, int32 y, int32 combo, int32 w, int32 h, int32 cset, int32 xscale, int32 yscale, int32 rx, int32 ry, int32 rangle, int32 frame, int32 flip, bool transparency, int32 opacity);
void FastCombo( int32 layer, int32 x, int32 y, int32 combo, int32 cset, int32 opacity );
// DEPRICATED ***

void Message(int32 string);

// DEPRICATED ***
void DrawCharacter(int32 layer, int32 x, int32 y, int32 font,int32 color, int32 background_color,int32 width, int32 height, int32 glyph, int32 opacity );
void DrawInteger(int32 layer, int32 x, int32 y, int32 font,int32 color, int32 background_color,int32 width, int32 height, int32 number, int32 number_decimal_places, int32 opacity);
void DrawString( int32 layer, int32 x, int32 y, int32 font,int32 color, int32 background_color,int32 format, int32 ptr[], int32 opacity );
void Quad( int32 layer, int32 x1, int32 y1, int32 x2, int32 y2, int32 x3, int32 y3, int32 x4, int32 y4,int32 w, int32 h, int32 cset, int32 flip, int32 texture, int32 render_mode);
void Triangle( int32 layer, int32 x1, int32 y1, int32 x2, int32 y2, int32 x3, int32 y3,int32 w, int32 h, int32 cset, int32 flip, int32 texture, int32 render_mode);
void Quad3D( int32 layer, int32 pos[], int32 uv[], int32 cset[], int32 size[], int32 flip, int32 texture, int32 render_mode );
void Triangle3D( int32 layer, int32 pos[], int32 uv[], int32 csets[], int32 size[], int32 flip, int32 texture, int32 render_mode );
void SetRenderTarget( int32 bitmap_id );
void DrawBitmap( int32 layer, int32 bitmap_id, int32 source_x, int32 source_y, int32 source_w, int32 source_h, int32 dest_x, int32 dest_y, int32 dest_w, int32 dest_h, float_or_int32 rotation, bool mask);
void DrawLayer(int32 layer, int32 source_map, int32 source_screen, int32 source_layer, int32 x, int32 y, float_or_int32 rotation, int32 opacity);
void DrawScreen(int32 layer, int32 map, int32 source_screen, int32 x, int32 y, float_or_int32 rotation);
// DEPRICATED ***
};


namespace ItemBindings
{
bool isValid();
int32 X;
int32 Y;
int32 Jump;
int32 DrawStyle;
int32 ID;
int32 OriginalTile;
int32 Tile;
int32 CSet;
int32 FlashCSet;
int32 NumFrames;
int32 Frame;
int32 ASpeed;
int32 Delay;
bool Flash;
int32 Flip;
int32 Pickup;
int32 Extend;
int32 TileWidth;
int32 TileHeight;
int32 HitWidth;
int32 HitHeight;
int32 HitZHeight;
int32 HitXOffset;
int32 HitYOffset;
int32 DrawXOffset;
int32 DrawYOffset;
int32 DrawZOffset;
float_or_int32 Misc[];
};

namespace WeaponBindings
{
bool isValid();
void UseSprite(int32 id);
bool Behind;
int32 ID;
int32 X;
int32 Y;
int32 Z;
int32 Jump;
int32 DrawStyle;
int32 Dir;
int32 OriginalTile;
int32 Tile;
int32 OriginalCSet;
int32 CSet;
int32 FlashCSet;
int32 NumFrames;
int32 Frame;
int32 ASpeed;
int32 Damage;
int32 Step;
int32 Angle;
bool Angular;
bool CollDetection;
int32 DeadState;
bool Flash;
int32 Flip;
int32 Extend;
int32 TileWidth;
int32 TileHeight;
int32 HitWidth;
int32 HitHeight;
int32 HitZHeight;
int32 HitXOffset;
int32 HitYOffset;
int32 DrawXOffset;
int32 DrawYOffset;
int32 DrawZOffset;
float_or_int32 Misc[];
};

namespace ItemDataBindings
{
float_or_int32 InitD[];
void GetName(int32 buffer[]);
int32 Family;
int32 Level;
int32 Power;
int32 Amount;
int32 MaxIncrement;
int32 Max;
bool Keep;
int32 Counter;
int32 UseSound;
};


namespace GameBindings
{
int32 GetCurScreen();
int32 GetCurDMapScreen();
int32 GetCurLevel();
int32 GetCurMap();
int32 GetCurDMap();
int32 DMapFlags[];
int32 DMapLevel[];
int32 DMapCompass[];
int32 DMapContinue[];
int32 DMapMIDI[];
void GetDMapName(int32 DMap, int32 buffer[]);
void GetDMapTitle(int32 DMap, int32 buffer[]);
void GetDMapIntro(int32 DMap, int32 buffer[]);
int32 DMapOffset[];
int32 DMapMap[];
int32 NumDeaths;
int32 Cheat;
int32 Time;
bool TimeValid;
bool HasPlayed;
bool Standalone;
int32 GuyCount[];
int32 ContinueDMap;
int32 ContinueScreen;
int32 LastEntranceDMap;
int32 LastEntranceScreen;
int32 Counter[];
int32 MCounter[];
int32 DCounter[];
int32 Generic[];
int32 LItems[];
int32 LKeys[];
int32 GetScreenFlags(int32 map, int32 screen, int32 flagset);
int32 GetScreenEFlags(int32 map, int32 screen, int32 flagset);
bool GetScreenState(int32 map, int32 screen, int32 flag);
void SetScreenState(int32 map, int32 screen, int32 flag, bool value);
float_or_int32 GetScreenD(int32 screen, int32 reg);
void SetScreenD(int32 screen, int32 reg, float_or_int32 value);
float_or_int32 GetDMapScreenD(int32 dmap, int32 screen, int32 reg);
void SetDMapScreenD(int32 dmap, int32 screen, int32 reg, float_or_int32 value);
itemdata LoadItemData(int32 item);
void PlaySound(int32 soundid);
void PlayMIDI(int32 MIDIid);
int32 GetMIDI();
bool PlayEnhancedMusic(int32 filename[], int32 track);
void GetDMapMusicFilename(int32 dmap, int32 buf[]);
int32 GetDMapMusicTrack(int32 dmap);
void SetDMapEnhancedMusic(int32 dmap, int32 filename[], int32 track);
int32 GetComboData(int32 map, int32 screen, int32 position);
void SetComboData(int32 map, int32 screen, int32 position, int32 value);
int32 GetComboCSet(int32 map, int32 screen, int32 position);
void SetComboCSet(int32 map, int32 screen, int32 position, int32 value);
int32 GetComboFlag(int32 map, int32 screen, int32 position);
void SetComboFlag(int32 map, int32 screen, int32 position, int32 value);
int32 GetComboType(int32 map, int32 screen, int32 position);
void SetComboType(int32 map, int32 screen, int32 position, int32 value);
int32 GetComboInherentFlag(int32 map, int32 screen, int32 position);
void SetComboInherentFlag(int32 map, int32 screen, int32 position, int32 value);
int32 GetComboSolid(int32 map, int32 screen, int32 position);
void SetComboSolid(int32 map, int32 screen, int32 position, int32 value);
int32 ComboTile(int32 combo);
void GetSaveName(int32 buffer[]);
void SetSaveName(int32 name[]);
void End();
void Save();
bool ShowSaveScreen();
void ShowSaveQuitScreen();
void GetMessage(int32 string, int32 buffer[]);
int32 GetFFCScript(int32 name[]);
bool ClickToFreezeEnabled;
};


namespace NPCBindings
{
bool isValid();
void GetName(int32 buffer[]);
int32 ID;
int32 Type;
int32 X;
int32 Y;
int32 Z;
int32 Jump;
int32 Dir;
int32 Rate;
int32 Haltrate;
int32 Homing;
int32 Hunger;
int32 Step;
bool CollDetection;
int32 ASpeed;
int32 DrawStyle;
int32 HP;
int32 Damage;
int32 WeaponDamage;
int32 Stun;
int32 OriginalTile;
int32 Tile;
int32 Weapon;
int32 ItemSet;
int32 CSet;
int32 BossPal;
int32 SFX;
int32 Extend;
int32 TileWidth;
int32 TileHeight;
int32 HitWidth;
int32 HitHeight;
int32 HitZHeight;
int32 HitXOffset;
int32 HitYOffset;
int32 DrawXOffset;
int32 DrawYOffset;
int32 DrawZOffset;
int32 Defense[];
int32 Attributes[];
int32 MiscFlags;
float_or_int32 Misc[];
void BreakShield();
};



I've put in a preprocessor which greatly simplifies the conversion layer, and can remap many things via macros. It would be a multi-pass "parser." Currently the idea is to load the script buffer, generate a list of all imported files, tag on a conversion file at the top, then process those files into memory, where a third pass can be run before finally outputting the converted scripts or sending it to the AS compiler.

Things like operators '->' to '.' etc., or different script types are trivial so I expect a > 95% initial success rate. Hopefully I can get this part finished and start looking at actual output files next week.
We'll see how well this works. O_o

[SUCCESSOR]

Things like operators '->' to '.' etc., or different script types are trivial so I expect a > 95% initial success rate. Hopefully I can get this part finished and start looking at actual output files next week.
We'll see how well this works. O_o


Does that mean in AngelScript you can just do:

example_ptr.foo = 9;

Or do you dereference it with a star and parentheses? Cuz that is more annoying than the arrow operator.

Did some google-fu. AS doesn't have pointers(?), but ...handles... I'm even more confused now.

I like AS! Let's get this going so I can get to really learning it.

[Tamamo]

I would prefer we actually use Lua this time around.
Angelscript hasn't aged well these pass years.

[DarkDragon]

What are the advantages of LUA over AS?

One concern I have with LUA (which also applies to AS): the only large project I am personally familiar with that uses LUA heavily is ToME, and it had significant performance problems (actions take place is less than real time once many scripts start acting at once). Is this a concern, or just that ToME is poorly designed?

[Gleeok]

What are the advantages of LUA over AS?

One concern I have with LUA (which also applies to AS): the only large project I am personally familiar with that uses LUA heavily is ToME, and it had significant performance problems (actions take place is less than real time once many scripts start acting at once). Is this a concern, or just that ToME is poorly designed?

LUA is used by at least hundreds of games. Unfortunately you probably won't get a list by googling for it as most of the titles are by large game studios. If ToME used AS then it would be at least as slow, if not slower, I would assume. Once the spritelist gets optimized and we avoid using the AS GC (reference types) for anything built-in or trivial it shouldn't be an issue.

Would you like to wager on an ZScript vs AS performance comparison? ;)

Also Tamano is just joking. I don't think that was serious.

[DarkDragon]

Also Tamano is just joking. I don't think that was serious.
Ok.


Would you like to wager on an ZScript vs AS performance comparison? ;)
Depends on the context. Presumably AngelScript is at least mildly optimized, in which case I would expect it to outperform ZScript handily for running equivalent code. But I am not so sure about ZScript user code+C++ internal engine vs AngelScript user code + AngelScript engine.

[Gleeok]

Yeah, an angelscript engine is probably just a horrible and slower form of a Java engine without any of the positives. That's why I'm never going to be in favor of moving c++ code to AS. In fact, I want to do the opposite: Move common usage patterns to c++! We just couldn't without adding tons of new code to the ZScript compiler.

Take the most common script ever as an example:


for(int i = 1; i <= Screen->NumEWeapons(); i++)
{
eweapon w = Screen->LoadEWeapon(i);
if(Abs(w->X-8)<someX && Abs(w->Y-8)<someY) // probably more stuff too
{
//collision or whatever
}
}

Which is horribly inefficient. Basically scripts are doing low-level stuff and I can tell you while I am able to optimize scripts to a degree most users can not.
The fact that most scripts use "ZScript engines" (ghost.zh, etc.) kind of compounds the issue.

Here's another example:



void foo(int, a, b, c, d, e, f, g){ // a is false
if(a && b && c && d && e && f && g && bar(a,b,c))
{
/....
}
}

Even though 'a' is false every other statement is evaluated and bar(...) is also called.

[DarkDragon]

Yes I'm all in favor of better built-in library support for common ZC tasks.

Short-circuit boolean operations may or may not be a good thing -- it's useful in some cases, but also one of the often-criticized features of C.

[Grayswandir]

My main concern with short circuiting is if it'll kill any existing scripts. I'd really like it to be added, but I'm pretty sure there's some script out there that does a() && b() && c() or similar.

Maybe some sort of flag at the top of the script/function/whatever?

[ZoriaRPG]

Yeah, an angelscript engine is probably just a horrible and slower form of a Java engine without any of the positives. That's why I'm never going to be in favor of moving c++ code to AS. In fact, I want to do the opposite: Move common usage patterns to c++! We just couldn't without adding tons of new code to the ZScript compiler.

Take the most common script ever as an example:


for(int i = 1; i <= Screen->NumEWeapons(); i++)
{
eweapon w = Screen->LoadEWeapon(i);
if(Abs(w->X-8)<someX && Abs(w->Y-8)<someY) // probably more stuff too
{
//collision or whatever
}
}

Which is horribly inefficient. Basically scripts are doing low-level stuff and I can tell you while I am able to optimize scripts to a degree most users can not.
The fact that most scripts use "ZScript engines" (ghost.zh, etc.) kind of compounds the issue.

Here's another example:



void foo(int, a, b, c, d, e, f, g){ // a is false
if(a && b && c && d && e && f && g && bar(a,b,c))
{
/....
}
}

Even though 'a' is false every other statement is evaluated and bar(...) is also called.

The first issue can be solved by checking collision internally, as an option, in both cases. Either way, users will want self-defined collision, and you fall back on needing to check bounding areas of objects. I don;t see the difference, save that we don;t have an internal collision call now, which we could add to give the user engine collision checking.

The second, needs a parsing correction. If a statement reaches a condition that would evaluate false, exit, but I don;t think that the risk is worth the reward at all. If we added this, it would need to be a compiler directive that is disabled by default; and I would also point out that code may expect bar() to be called in that statement, even if the conditions are false. Short-circuiting belongs in languages where it is anticipated from the onset.

If you don't favour the AS engine with the parser, than I really don;t see the point. TO me, the entire reason for even wanting this paradigm shift, was to open the engine up to more fluidic control by the scripter. This comes at a performance hit, which is why I was happy to accept it for ZC3, a rewrite, that changed the entire ZC dynamic, moved us to modern libs, added scrolling, and essentially provided an emulation layer to play classic quests. Pretty much, Solarus in ZC style, with AS, and the ability to play most, but not all, older quests.

This is why we were going to work on 2.x, while you worked on the initial set-up for something of that scope. The discussion on AS and the discussion on a modernisation rewrite, to me, are intertwined. The average user couldn't care what script engine is under the hood: They only care that the scripters supply them with free goodies. What they want, more than anything, is to make SNES style games, and they can;t, so they beg the scripters to supply them with the 'next-best-thing'.

I think this constant debate on what scripting engine to use, is just side-stepping the real issue, of how ZC needs to evolve in the next five years, to avoid being surpassed, overshadowed, and forgotten. 2.xx is a stopgap measure, toward that type of goal, and I feel as if you are spending energy trying to hammer in a new engine when the entire thing needs to be blown up and rebuild from the ground up in the near future. I just hope I'm still alive, to see it.

I'll certainly be willing to entertain whatever you create, but I think it will be offset a version or two, no-matter what. I do like the updates we've already managed to get working, and I feel that they should be deployed, and allow users to utilise them. Give them a learning curve that isn't just a cold slap in the face, and they will be more appreciative of the entire thing, and more welcoming of controversial change, in the future.

Maybe we should use the AS engine instead of cpp, and have the ZScript parser output AS instead of ZASM. ;) [/sarcasm]

[Tamamo]

Oh no I'm very serious, one project that has done incredible things with lua is Starbound which also uses JSON along with it and was created to be moddable from the bottom up. This is the sort of approach we need to take when implementing a new language, in fact I'd rather just rewrite zc from scratch. But ya'll too damn lazy for that.

[SUCCESSOR]

Oh no I'm very serious, one project that has done incredible things with lua is Starbound which also uses JSON along with it and was created to be moddable from the bottom up. This is the sort of approach we need to take when implementing a new language, in fact I'd rather just rewrite zc from scratch. But ya'll too damn lazy for that.

Lua is gross, though. What advantage would it have over AS? Atleast AS is somewhat similar to ZScript. I think that is a big factor in it being the right choice. Most people who script in ZC aren't programmers. They only learn what they need of ZScript and would probably be scared off by something so ... different.

[Grayswandir]

That's a good point. As much as I like Lua, AS is much closer to ZScript. At least as far as the average scripter is concerned.

[Tamamo]

Neither am I, and I learned lua in 5 days.

[SUCCESSOR]

Neither am I, and I learned lua in 5 days.

And you could learn AS is 5 days. :P

[ZoriaRPG]

Oh no I'm very serious, one project that has done incredible things with lua is Starbound which also uses JSON along with it and was created to be moddable from the bottom up. This is the sort of approach we need to take when implementing a new language, in fact I'd rather just rewrite zc from scratch. But ya'll too damn lazy for that.

Well, this is what I have suggested as the proper course of action, post-2.6, several times; and nobody even responds to it. :/


Lua is gross, though. What advantage would it have over AS? Atleast AS is somewhat similar to ZScript. I think that is a big factor in it being the right choice. Most people who script in ZC aren't programmers. They only learn what they need of ZScript and would probably be scared off by something so ... different.

Ah, so I'm not the only one that finds Lua to be a bit awful? Really, it's one of the main reasons that I haven't made a Solarus quest--every flipping thing is coded in Lua. You can't do a blasted thing, without coding it as a Lua block, other than place graphics, which are read form a text file listing all of them, into the Lua engine.

[SUCCESSOR]

I haven't used AS, but I like the look of it. And it weirdness, like it's handling of references, I could get used to and I understand why they are that way.

[Gleeok]

I also kind of hate Lua and Python; just can't stand them.

My personal coding style produces mainly small but easily caught (most at compile-time) and easily fixable errors that are usually obvious at a first debugging pass in the case something doesn't work. For me functional languages actually mean dysfunctional--I don't need or want dynamically typed code that just silently fails and doesn't help you where it seems to matter.

[ZoriaRPG]

I also kind of hate Lua and Python; just can't stand them.

My personal coding style produces mainly small but easily caught (most at compile-time) and easily fixable errors that are usually obvious at a first debugging pass in the case something doesn't work. For me functional languages actually mean dysfunctional--I don't need or want dynamically typed code that just silently fails and doesn't help you where it seems to matter.

I'm personally not a huge fan of forced indentation scoping. It's easy to copy/paste through some medium, lose your indentation, and be entirely #^#%ed.

This is one of the things that Ruby did right. That, and a lot of other things, but that's a topic for another day, and as I have no practical application for anything outside of cpp at present, ...

The funny thing, is that I was once accustomed to indentation coping, and now, I can't stand it, because braces do not suffer the loss of tabbing issue.

[Grayswandir]

I also kind of hate Lua and Python; just can't stand them.

My personal coding style produces mainly small but easily caught (most at compile-time) and easily fixable errors that are usually obvious at a first debugging pass in the case something doesn't work. For me functional languages actually mean dysfunctional--I don't need or want dynamically typed code that just silently fails and doesn't help you where it seems to matter.

I'm not sure why you brought up functional languages (and I wouldn't really consider python as one), and then instead complained about dynamic typing?

I generally view it as a tradeoff. I mean, it's nice being able to detect a certain class of errors ahead of time, but for most of those you'll quickly detect them during runtime. And if you're doing a big project, you shouldn't be relying on the compiler for correctness anyway. So, it's at the point where I can't clearly say that one is better than the other.

[Gleeok]

I'm not sure why you brought up functional languages (and I wouldn't really consider python as one), and then instead complained about dynamic typing?

I generally view it as a tradeoff. I mean, it's nice being able to detect a certain class of errors ahead of time, but for most of those you'll quickly detect them during runtime. And if you're doing a big project, you shouldn't be relying on the compiler for correctness anyway. So, it's at the point where I can't clearly say that one is better than the other.

Because both Python and Lua boast to be "multi-paradigm" and let you write functional code. Both Lua and Python are also dynamically-typed languages and claim to be. Not even my words, but theirs.

You missed my point. For my personal style, most of my stupid errors (bugs in dynamic languages, if you will) are caught at compile time meaning that I don't even have to run the thing to find out I messed up some parameter or whatever. Therefore, I prefer to work with statically-typed code. That's just my preference. :)

[Gleeok]

Let's talk about the AS syntax really quick.



//note: code is gibberish, it doesn't do anything.

//HANDLES
void Foo(Ref@ ref) //option A:
{
@ref = @Ref.Create(); //points to a new thingy.
ref = otherRef; // now it value copies other thingy. whoops.
}

// confused yet? ...well then:

void Foo(Ref ref) //option B:
{
ref = Ref.Create(); //points to a new thingy.
ref = otherRef; // now it POINTS to other thingy instead.
}

int e = Enum::Value;
int i = A::B::Value;
int v = this.Value;
int x = Object.Value;
Link::X = x;

..confused again?

int e = Enum.Value;
int i = A.B.Value;
int v = this.Value;
int x = Object.Value;
Link.X = x;

// Current annoyance... but unlikely as part of the ZC script API. ...idk
void Foo(const int &in a, int &out b, Object &c)
{
}

//unless we allow unsafe references only "out&" or "&inout" is really useful.


Script language reference: http://www.angelcode.com/angelscript/sdk/docs/manual/doc_script.html
Other issues?

[Dimentio]

Let's talk about the AS syntax really quick.



//note: code is gibberish, it doesn't do anything.

//HANDLES
void Foo(Ref@ ref) //option A:
{
@ref = @Ref.Create(); //points to a new thingy.
ref = otherRef; // now it value copies other thingy. whoops.
}

// confused yet? ...well then:

void Foo(Ref ref) //option B:
{
ref = Ref.Create(); //points to a new thingy.
ref = otherRef; // now it POINTS to other thingy instead.
}

int e = Enum::Value;
int i = A::B::Value;
int v = this.Value;
int x = Object.Value;
Link::X = x;

..confused again?

int e = Enum.Value;
int i = A.B.Value;
int v = this.Value;
int x = Object.Value;
Link.X = x;

// Current annoyance... but unlikely as part of the ZC script API. ...idk
void Foo(const int &in a, int &out b, Object &c)
{
}

//unless we allow unsafe references only "out&" or "&inout" is really useful.


Script language reference: http://www.angelcode.com/angelscript/sdk/docs/manual/doc_script.html
Other issues?

Looking at that syntax makes me feel like I'm looking through the source code, just to do a little scripting. I'm not entirely sure how this will help people learn the language?

[Gleeok]

Looking at that syntax makes me feel like I'm looking through the source code, just to do a little scripting. I'm not entirely sure how this will help people learn the language?

It's not. We have to set up how we want scripts to behave, and set up compiler options accordingly; perhaps even have some form of code standard. Have you ever been to an eye doctor and they asked you "A or B?" Well that's what we have to figure out. That code is purposely ugly for this purpose.

[Dimentio]

It's not. We have to set up how we want scripts to behave, and set up compiler options accordingly; perhaps even have some form of code standard. Have you ever been to an eye doctor and they asked you "A or B?" Well that's what we have to figure out. That code is purposely ugly for this purpose.

Ah. I vote on making it as close to ZScript as possible, without it's limitations.

[Tamamo]

AS has it's own limitations

[Saffith]

Well, there are limitations of the language itself and limitations of the implementation. In ZScript's case, there are plenty of each. Whatever else might be said about them, AngelScript, Lua, and Python all have a lot fewer of the former.

[ZoriaRPG]

Ah. I vote on making it as close to ZScript as possible, without it's limitations.


Actually, that syntax is like ZScript. The reason you haven;t seen some of that, is because the parser doesn't handle all of the available C syntax that it could. There has been some improvement in that area. There's very little proper C syntax that it could not handle--or really, handle without a lot of work. It could theoretically do anything that a full C parser could do. Cpp syntax is something else, as it continually morphs with each new revision. There are things that cpp allows that I didn't know about until recently, and not all compilers may support them (read, CPP11), and yet others that it does not support, but compilers may (e.g. variable array declaration, supported by gcc).

How the hell would array pointers translate? That's a fundamental question, and concern.

[Gleeok]

Ah. I vote on making it as close to ZScript as possible, without it's limitations.

Probably the best possible answer. ;) I will do that.


Sure. Right now I've got the parser and compiler working and can create and call scripts. The first test scripts should be forthcoming this week.

I'm going to experiment with the compiler options to see if I can get rid of handles or not. The docs are not clear on this. ("handles" are the Class@ c; @c = @something; Foo(@c); stuff)
[EDIT] This unfortunately produces weird compiler errors. "Normal" scripts and all engine declared things will not force scripts to use them, however if you write classes and want to communicate custom classes with each other then in those cases you will have to use them as parameters. It's likely most normal scripts won't ever need them... I think...

There's no ZC bindings for the time being until everything is tested fully, but I can put in a math library for collisions and vector math stuff. It is important to implement these c++ side to get all the performance benefits of c++ compiled code and have scripts use that directly with no intermediate layer. What I'm going for is at least a 20x performance increase over ZScript for common tasks. We'll see what happens.

[SUCCESSOR]

Probably the best possible answer. ;) I will do that.


Sure. Right now I've got the parser and compiler working and can create and call scripts. The first test scripts should be forthcoming this week.

I'm going to experiment with the compiler options to see if I can get rid of handles or not. The docs are not clear on this. ("handles" are the Class@ c; @c = @something; Foo(@c); stuff)
[EDIT] This unfortunately produces weird compiler errors. "Normal" scripts and all engine declared things will not force scripts to use them, however if you write classes and want to communicate custom classes with each other then in those cases you will have to use them as parameters. It's likely most normal scripts won't ever need them... I think...

There's no ZC bindings for the time being until everything is tested fully, but I can put in a math library for collisions and vector math stuff. It is important to implement these c++ side to get all the performance benefits of c++ compiled code and have scripts use that directly with no intermediate layer. What I'm going for is at least a 20x performance increase over ZScript for common tasks. We'll see what happens.

Why would you get rid of handles?

[Tamamo]

Gleeok, please tell me you're joking for once. I really want my callback functions this time around.

[Gleeok]

Joking you say?! I never joke. :rolleyes:


Why would you get rid of handles?

They're not needed since the compiler should be able to know all the types at compile. I remember years ago (2011?) Andreas said that for AS ver. 3.0 he wanted to revamp the language to allow this. There's a few options for this but it's not complete. There's no real reason other than simplifying the syntax for scripters to be closer to something more familiar like ZScript or CS.

[Tamamo]

Gleeok
Just cause your compiler know the types, doesn't mean it knows the scope of it's functions and such. We need function callbacks and message handlers for that sole reason. Since you seem to be so set and determine on simplifying the syntax; which is something i have been completely against since the start of this discussion. This is for several reasons. First I hate the simplification of C to ZScript, Second people need to learn to adapt. I'm not even a programmer, I'm a freaking artist and I can learn a programming language easily if I put my mind to it. Anyways will simply move on from this project. And start dedicating my fulltime to other projects. Adios Amigos

[Gleeok]

Gleeok
Just cause your compiler know the types, doesn't mean it knows the scope of it's functions and such. We need function callbacks and message handlers for that sole reason. Since you seem to be so set and determine on simplifying the syntax; which is something i have been completely against since the start of this discussion. This is for several reasons. First I hate the simplification of C to ZScript, Second people need to learn to adapt. I'm not even a programmer, I'm a freaking artist and I can learn a programming language easily if I put my mind to it. Anyways will simply move on from this project. And start dedicating my fulltime to other projects. Adios Amigos

Not sure I understand what you mean? I'm talking about the angelscrit compiler and the author of the language. I'm not talking about removing any functionality of the language. Anyways, that functionality is not complete so it's kind of moot.

Callbacks ARE being put in, that's kind of a main point.

[DarkDragon]

I think it's important to keep in mind a separation between the semantics we want, and the details of the syntax.

Moving to message handlers is a big change in semantics and it's important that we hash out the details of how we want scripts to interact with the game engine and with each other using this system.

Syntax is important, especially for easing the transition from other languages to AS, but much less urgent to argue about right now since it is easier to change (by modifying AS, or preprocessing) than core semantics.

[Gleeok]

Yep, it should be fine once I figure out how to split the dang asTT_Scope token type into forwards and backwards tokens. :/

If anyone with some 1337 c++ macro skills wants to try their hand at generating about 100x the classes that this one currently does feel free to go crazy show me up. (It only generates a 38kb script file ATM which isn't near enough for serious performance or memory allocation testing.)

https://github.com/ArmageddonGames/ZeldaClassic/blob/master/src/experimental/Scripts/TestCompileTime.h

[Tamamo]

If you remove handlers the callbacks are going to be a bitch to work with Gleeok, there I spelled it out fo you.

[Gleeok]

just popping in to say it's starting to look good. :) Not saying zc script types will be done very soon but...



If you remove handlers the callbacks are going to be a bitch to work with Gleeok, there I spelled it out fo you.
I meant the syntax, not the actual handles. That would require rewriting the entire script library; that's just crazy sauce. ;)

[Tamamo]

I meant the syntax, not the actual handles. That would require rewriting the entire script library; that's just crazy sauce. ;)

Okay first what the fuckall you talking about, zscript syntax doesn't even have function handles. Second enlighten me.

[Gleeok]

Okay first what the fuckall you talking about, zscript syntax doesn't even have function handles. Second enlighten me.

This is Angelscript not ZScript. Declaring and using "handles" means typing the "@" @at @symbols @everywhere @in @the @scripts. @The @person @who @wrote @the l@anguage @and a@ll t@he @code @had s@implifying @this @on @his @todo@ list@ for @AS 3.0. @But it @seems @it @hasn't @happened @yet.


Also, sure thing:

https://media1.britannica.com/eb-media/41/129641-004-450EA0C2.jpg

Are you enlightened now?

[Tamamo]

This is Angelscript not ZScript. Declaring and using "handles" means typing the "@" @at @symbols @everywhere @in @the @scripts. @The @person @who @wrote @the l@anguage @and a@ll t@he @code @had s@implifying @this @on @his @todo@ list@ for @AS 3.0. @But it @seems @it @hasn't @happened @yet.


Also, sure thing:

https://media1.britannica.com/eb-media/41/129641-004-450EA0C2.jpg

Are you enlightened now?

Another reason i dont like angelscript. It's implementation of callbacks and handles is just plain stupid.

[ZoriaRPG]

Another reason i dont like angelscript. It's implementation of callbacks and handles is just plain stupid.


Is it really that different to using *pointer ? I suppose you could always change the preprocessing and lexing side to use *handle?

Here's a question that has been bothering me: Is this parser that you are making still going to use the present ffscript code? If so, and it is just a drop-in replacement for flex-bison, then I would be willing to help test, and possibly work on it, but it it means rewriting ffscript, and all the functions... Hell, will it be using ri->D[] and similar? How will it change stack calls? As far as I can see, it requires rewriting the whole damned engine, which is why I'm not interested in working on it.

[Gleeok]

Is it really that different to using *pointer ? I suppose you could always change the preprocessing and lexing side to use *handle?

Here's a question that has been bothering me: Is this parser that you are making still going to use the present ffscript code? If so, and it is just a drop-in replacement for flex-bison, then I would be willing to help test, and possibly work on it, but it it means rewriting ffscript, and all the functions... Hell, will it be using ri->D[] and similar? How will it change stack calls? As far as I can see, it requires rewriting the whole damned engine, which is why I'm not interested in working on it.

Nope. 18-bit zscript fixed types are an atrocity. No more divide or multiply by 10000 stuff. There, I said it. :P
It is also not compatible with the current ZScript parser, which is actually a good thing.

Let me fill you in on what is done really quick. -(Keep in mind I did all this in one week, by myself; like I said last year: if we move away from ZScript then productivity will increase by a huge margin and people will be able to work with it much easier)

~We have a fully standards compliant c/c++ preprocessor that scripts /and engine/ may use.
~As per above, script logging, asserts, and exceptions are only compiled with the "DEBUG" flag set. This means no commenting in/out Trace(..) functions, and script errors give detailed info and even a callstack.
~The compiler/preprocessor is separate from ZQuest and ZC, (and serialization support for edit/continue is planned). This means you will be able to recompile/write/test scripts directly while you test them in ZC.
~Compilation is currently blazing fast compared to the ZScript parser: A 120 KB script file compiles and builds in 0.2 seconds and I have not even optimized anything (But if you know me you know I will!). :P
~Math library built in is already 10x the usefulness of ZScript. We have vector math and utility types that are all c++ code so scripts will be very fast as they just call directly into an c++ function. Parts of std.zh will be put in c++ as well so huge speed improvements all around are planned.
~Delegates and callbacks are basically in already (see other thread on messaging).
~No limit (currently 2048) on scripts. RAM usage seems to be very low so I don't see why not.


What's going in this week:
~Maybe DMap, Map, Screen, and Global Scripts. (Whatever I feel like basically)
~Any script can be created at any time by any other script. For example:


class ChildrenOfTheCorn
{
int Children;
int Corn;
void MakeSequel(bool blood) {...}

//stuff (like an ffc script kinda)
}

void OnSomeCallback(...) //called by the engine
{
foreach(...)
{
Script@ globalScript = zc.CreateScript(GLOBAL, "ChildrenOfTheCorn");
globalScript.Children = 212;
globalScript.Corn = lots;
globalScript.MakeSequel(true);
}
}


It's not all fun though. The bindings to existing ZScript things are going to take the longest. Although comparatively speaking each built-in function is much easier to add to AS than ZScript, they don't exist yet.

[ZoriaRPG]

Nope. 18-bit zscript fixed types are an atrocity. No more divide or multiply by 10000 stuff. There, I said it. :P
It is also not compatible with the current ZScript parser, which is actually a good thing.

Let me fill you in on what is done really quick. -(Keep in mind I did all this in one week, by myself; like I said last year: if we move away from ZScript then productivity will increase by a huge margin and people will be able to work with it much easier)

~We have a fully standards compliant c/c++ preprocessor that scripts /and engine/ may use.
~As per above, script logging, asserts, and exceptions are only compiled with the "DEBUG" flag set. This means no commenting in/out Trace(..) functions, and script errors give detailed info and even a callstack.
~The compiler/preprocessor is separate from ZQuest and ZC, (and serialization support for edit/continue is planned). This means you will be able to recompile/write/test scripts directly while you test them in ZC.
~Compilation is currently blazing fast compared to the ZScript parser: A 120 KB script file compiles and builds in 0.2 seconds and I have not even optimized anything (But if you know me you know I will!). :P
~Math library built in is already 10x the usefulness of ZScript. We have vector math and utility types that are all c++ code so scripts will be very fast as they just call directly into an c++ function. Parts of std.zh will be put in c++ as well so huge speed improvements all around are planned.
~Delegates and callbacks are basically in already (see other thread on messaging).
~No limit (currently 2048) on scripts. RAM usage seems to be very low so I don't see why not.


What's going in this week:
~Maybe DMap, Map, Screen, and Global Scripts. (Whatever I feel like basically)
~Any script can be created at any time by any other script. For example:


class ChildrenOfTheCorn
{
int Children;
int Corn;
void MakeSequel(bool blood) {...}

//stuff (like an ffc script kinda)
}

void OnSomeCallback(...) //called by the engine
{
foreach(...)
{
Script@ globalScript = zc.CreateScript(GLOBAL, "ChildrenOfTheCorn");
globalScript.Children = 212;
globalScript.Corn = lots;
globalScript.MakeSequel(true);
}
}


It's not all fun though. The bindings to existing ZScript things are going to take the longest. Although comparatively speaking each built-in function is much easier to add to AS than ZScript, they don't exist yet.

What are you planning to do to convert all of the existing types? What type are the existing int and float declarations from script code using?

You didn't ever answer my concern about zscript object, and array pointers; given that AS doesn't have pointers at all, I need to know how that syntax would cross, if at all.

Is it going to be able to utilise the ZASM labels and registers, by removing the division and multiplication factors? Are you just implementing zscript INT and FLOAT as real floating pint with four points of precision? Isn't that going to cause hell with typecasting, given that ZASM stuff expects longs and ints (and occasionally fixed values), and the ZC engine needs fixed values regularly?

I would just have added a type for fixed to it, and parsed the old scripts to that. I'm still unconvinced about compatibility here, because none of these issues have ever been addressed, so, let me know.

I would absolutely need to see how you convert ZASM functions across, and such.

[Gleeok]

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

[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/ZeldaClassic/tree/master/src/experimental/asBindings/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/ZeldaClassic/tree/master/src/experimental/asBindings/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.

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

[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

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

[ZoriaRPG]

I denoted the individual, key response points,in bold text, so that you can examine them at your leisure.


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


I don't know if you are deliberately mocking me, or if you missed my point; but I will clarify, if the latter. This concerns array pointers, not array declarations:



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


This is extremely commonplace array pointer usage. because AS doesn't have (traditional) pointers, I am concerned that this will break.

Will it? Evan effectively begged me at one point to ensure that this would never change. He and Moosh both use arrays by reference in precisely this way in almost every one of their ghost scripts. Gray, ywkls, and I all do so in our engines. It's not trivial, if it changes.


this = everything that AS already does that would need to be implemented from scratch in ZScript.



Here is what we seem to have, as a general plan, with some aspect or another complete.

Additional C Syntax : Switch-Case, Define, Enum, Structs (or something similar), potentially classes. -Grayswandir, minor contribs from me.
Sophisticated Messaging : -DarkDragon
Enhanced string and array usage : Array declaration improvements, usage of maths, and constants for array sizes. String literals (limited, but functional). -Grayswandir
Function pointers, that work similarly to handles in AS. -Grayswandir

I'm sure there are other things that these two are working on at present. I was going to add in enum and define, if Gray doesn't, and I sent him the rules that I wrote for define, and some stuff for constants and other materials. He wanted me to hold off on doing anything else, particularly adding npcdata, and other script types, until he finishes his present round of changes.

I have not focused on the parser itself of late. I mainly worked on the ZScript language, which I shall cover below.



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.


I only wish. If I could submit the changes that you will ratify, and do it in a sane manner, then keeping it up to sate in a streamlined manner would be easy-peasy.

The changes are scattered around in various ways; see the links listing the changes below. There is no way to do this that isn't gong to drive me mad, under the present accepted method. You both want to maintain a repo using pushes, instead of commits. That just isn't hot the software was designed to flipping work. I literally need to make twenty or so identical forks, apply some of the changes to each, and mind, some of these changes depend on one-another, so I need to either (submit incomplete/non-working changes), or (lump more together at one time and hear complaints about total push size)--and pray that some other change doesn't make an auto-merge impossible; and be asked to do it again???

That is absolutely ludicrous. You wonder why I'm not working on AS, and why I frankly don't want to be bothered with it? Hell, I have to merge in Dimentio's changes, too; and when I wake, and think about doing it, I get such a bad taste in my mouth between the constant complaints, and the sheer volume of merging many, many, tiny changes, that I just decide to do something else.



It's for both. Existing quests won't use it but new quests will have people switching over to AS.


(Emphasis, mine.)

Wait, what? Now we're going back again? Can we please clarify if after adding this AS parser, people will be able to flipping compile a ZScript script, without changing it? I don't care how it's compiled, just that it compiles. What you say here, implies that the change is forced on the user. Earlier you said they could use both or either. Before that, it was one or the other. Which is it, again?

What bothers me, is that even between the last few posts, or in the same post, I see wholly-contradicting points. If your AS implementation is a module, and the ZScript parser will work alongside, in parallel or otherwise, I certain have no objections at all. It is the one-or-the-other philosophy, that brings in potential problems; and aye, I have objections to it, but not merely because of any personal issue. I can easily make a custom ZC build to suit any purpose that I desire, for my own personal needs, or just modify my scripts if I wish. That is not the point; not at all.



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.


This is what happens when you let four mice out into a cage with cheese at both ends. You want us to work on this thing, we want to work on our thing, and no-one is happy. At present, I think what we want to accomplish, is to get our planned changes in and done, and get out a new version that is both more sable, and offers more to the user, before even considering any other radical changes.

For the most part, expanding the capabilities of ZScript, and adding non-scripting features so that scripting is not mandatory for various effects; and adding in other elements that are useful to scripter and non-scripter alike, have a higher priority to us than making structs, or other far more advanced concepts that AS may offer. What's the carrot here?

I'm the only one adding in actual ZScript commands. I have no problem with the system of doing this at present, and no urgent need to change it. My complaints stem from how the ZC classes are designed, not the way to implement things in the scripting language.

Dimentio wants to work on weapons, items, and strings. He hasn't shown the slightest interest in working on ZScript, AS, or the parser.

Grayswandir seems to enjoy the challenge of adding things to Flex-Bison. I don't know if this is my false perception, but he appears to get a thrill out of making new things work, that he himself added.

The only person so far that seems to care is Successor. Hell, even Tamamo is opposed to this, for no reason that i can clearly comprehend, other than to want something else that she has no specified. Should we just do a Ruby parser, and be done?

-------------------

I know that there is a long-term benefit involved, but when I say that it will be a while before I can get to it, and you flat-out threaten to quit, that just tells me that you don't give a damn. I know you are going through hell in your life. Some of the rest of us are in pretty bad spots, too. I can't just stop everything I'm doing to work on some new aspect that I don;t believe needs to be done immediately; particularly when it is too much trouble to read one of my replies, much less to read through any of the code changes, or other stuff that I've done, or other threads on matters that I feel are important.

Your time is valuable; so is mine. I can't say which is more finite, and limited. I can say that I'm getting far too old to care at times. You probably feel likewise.

-------------------



Arrays are not pointers. Again you refer to /our/ meaning this is a personal matter, not one that reflects the overall ZC community.


See above.

My reference of 'we', 'our', and such, is as a collective, referencing the totality of developers and users; in this case, the types that ZScript, and everyone using it, uses: int float, bool, npc, *weapon, ffc, itrem, itemdata. How was that coded that it wasn't clear?



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
[/quote]

Everything that I've done is out in the open for scrutiny. I don't feel the need to post every little thing, so I keep a change log, and 'update' docs that anyone may elect to read.

Source Pack (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54)
Change Log (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54/blob/master/ChangeLog.txt)
ZScript Changes (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54/blob/master/output/common/Docs/2.54_New_ZScript.txt) | (Abbreviated form.) (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54/blob/master/output/common/Docs/2.54_New_ZScript_ShortList.txt)
ZScript Syntax Changes (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54/blob/master/output/common/Docs/2.54_New_ZScript_Language.txt)
ZQuest Changes (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54/blob/master/output/common/Docs/2.54_New_ZQuest.txt)
ZStrings Changes (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54/blob/master/output/common/Docs/2.54_New_ZStrings.txt)
ZC Changes (https://github.com/ZoriaRPG/Zelda-Classic-2.future-2.54/blob/master/output/common/Docs/2.54_New_ZeldaClassic.txt)


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.



Hmm... Who, in reality, ever used ZASM? I did, a little bit. I know of what..one other user who did? I published one whopping ZASM script in the last ten years, and it does in fact, interoperate. It is designed to do precisely that, to allow 2.5 users to use a feature that was never implemented in ZScript. :p

I think you underestimate two things. One, is that the majority of ZScript users are not programmers. They manage to hack their way around, stumbling blindly at times, and they are more than happy to accept horrible, bugged results, if they work for their application. This tends to lend to laziness, and the desire not to move to anything new.

The second, is that the number of scripters out in the wild is small, and compared to the library of extant scripts, any new material is likely to me marginal, at best. This limits the resources for the user, and my considerations have the userbase in mind as a whole on this basis, not merely if something is inconvenient to a scripter. It's hard enough to explain how to import and compile a basic script to the average user. They simply are not willing to learn; and stemming from that point, they are not going to edit scripts to bring them in line with a new spec.

No, instead they will ask the scripters to do it for them, as they always do; and this time, no-one will ave any clue what to do, save for perhaps five of us. I can name only one scripter who is a programmer, can comprehend these changes, and is not in some way involved with ZC dev: MoscowModder.

(What happened to that userbase poll? It wasn't by job to run it. In fact, I stayed 20 metres away from that, to avoid any possible impression of a conflict of interest.)

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.[/QUOTE]

The problem here, is that the idea of them working, side-by-side, seems to be like a pendulum. If they do, fantastic. I couldn't ask for more, as it gives the choice of which to use, to the user, and the choice of which to expand, to the potential developer. I' am however, a bit weary of repeating that I do not have the time at present to dedicate to learning how AS works internally, en lieu of working on my present goals. I suspect that Dimentio feels likewise.

We both have very specific, and compatible, end-results in mind. There is in fact, a reason that we three, decided to work together. It's because we do not bicker about what we see as our vision for the next ZC/ZQ version. I certainly can't help with a task when the goal is as clear as mud.

The bottom line for me, is that any one of these outcomes should be true:

1. AS is not 100% compatible, but future versions will still support compiling ZScript code. We may even continue to update ZScript, and support both in parallel for a while.

2. AS is 99.9% compatible, with a very rare instance of something needing a change. Note, this does not mean changing types, or how some 'advanced' tricks' such as pointer handling are done. We still support ZScript, somehow, if it is needed, but we don;t spend much time on it.

3. AS is perfectly compatible, every single thing works, we abandon ZScript, and march merrily along.

4. AS doesn't work as planned, and we make ZScript 2.0 the next big bombshell.

The result that I won't accept--meaning, I would be 'done'--is:

D. AS isn't perfectly compatible and we kill the ability to compile ZScript code.

Does that suitably clarify my position on the matter?

If 'ya'all' want me to work on this stuff too, then please, make my job easier. Go over my proposed changes, select what you won't take from the list, let me wholly integrate the rest, and be flipping done with this hellish merging process, so that nay future revisions can be kept in sync with the main codebase. I simply cannot spend countless hours doing, and redoing this shyte.

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

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. :P

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 (http://zeldaclassic.com/wiki/index.php/Arrays_%28ZScript%29#Quirks_of_Scope).

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

[Tamamo]

ZoriaRPG please just stop, that is and has always been nothing but foolishness, it's why i stopped scripting in the first place. I just couldn't handle having to write bad code to do the shit I wanted to do.

[ZoriaRPG]

ZoriaRPG please just stop, that is and has always been nothing but foolishness, it's why i stopped scripting in the first place. I just couldn't handle having to write bad code to do the shit I wanted to do.

Hmm... You're the one who dubbed me the 'ambassador' to the ZC community. If you don't like me doing that job, shut it, and blame yourself. :D

Or perhaps both of you could knock it off.
-KA-

[Grayswandir]

I just wanted to mention that I picked up the array thing from reading through ghost.zh. So, blame Saffith. :P

Of course, seeing that ghost uses it, you'd end up breaking quite a lot of things if you don't support it.

The heart of the problem is that ZScript treats int and int[] as the same thing. You can do the same trick for the other types as well, but I don't know of anybody doing that.

If we end up compiling ZScript to AS (still not sure what the exact plan is), it shouldn't be too hard to fix. Just treat ZScript's arrays as their own "thing", separate from actual AS arrays. Just keep a table of them, and look them up anytime you do an array dereference. So, just compile them to eg. ZS_Array_Get(int id, int index) and similar instead of actual array references.

If we're having ZScript and AS side by side, it's a non-issue. If we want ZScript and AS to be able to interact with each other - well, that was gonna be a mess anyway.

Edit: relevant section of ghost.zh:
// Remember all the global variables

// Initializing the array is faster than setting it up afterward...
// but the difference is probably negligible, realistically
float tempGhostData[24] = {
Ghost_X, // 0
Ghost_Y, // 1
Ghost_Z, // 2
Ghost_Jump, // 3
Ghost_Vx, // 4
Ghost_Vy, // 5
Ghost_Ax, // 6
Ghost_Ay, // 7
__Ghost_PrevX, // 8
__Ghost_PrevY, // 9
Ghost_CSet, // 10
Ghost_Dir, // 11
Ghost_Data, // 12
Ghost_TileWidth, // 13
Ghost_TileHeight, // 14
__Ghost_Flags, // 15
__Ghost_Flags2, // 16
__Ghost_InternalFlags, // 17
__Ghost_FlashCounter, // 18
__Ghost_KnockbackCounter, // 19
Ghost_HP, // 20
__Ghost_XOffsets, // 21
__Ghost_YOffsets // 22
// 23 is for either drawingData or tempGhostAdditionalCombos;
// update DrawGhostFFCs if that changes
};
int tempGhostAdditionalCombos[21]; // Same size as __Ghost_AdditionalCombos
// Change it in the loop below, too
if(__Ghost_AdditionalCombos[0]>0)
{
for(int i=0; i<21; i++)
tempGhostAdditionalCombos[i]=__Ghost_AdditionalCombos[i];
}

// Give ghost an array pointer so its data can be found by other scripts
if(ghost->isValid())
ghost->Misc[__GHI_NPC_DATA]=0x10000|tempGhostData;

[ZoriaRPG]

I just wanted to mention that I picked up the array thing from reading through ghost.zh. So, blame Saffith. :P

Of course, seeing that ghost uses it, you'd end up breaking quite a lot of things if you don't support it.

The heart of the problem is that ZScript treats int and int[] as the same thing. You can do the same trick for the other types as well, but I don't know of anybody doing that.

If we end up compiling ZScript to AS (still not sure what the exact plan is), it shouldn't be too hard to fix. Just treat ZScript's arrays as their own "thing", separate from actual AS arrays. Just keep a table of them, and look them up anytime you do an array dereference. So, just compile them to eg. ZS_Array_Get(int id, int index) and similar instead of actual array references.


Oh, yes, you do. Have you never seen me do this with ffcs or items? I also do it with itemdata now. :/

I second this suggestion. I mentioned earlier, that we should just treat all of the ZScript types as special cases to handle them and avoid all of this incompatibility nonsense.



If we're having ZScript and AS side by side, it's a non-issue. If we want ZScript and AS to be able to interact with each other - well, that was gonna be a mess anyway.


Precisely. My second option, is parallel operation, with no direct communication. I suppose the ZScript messaging and AS messaging could be used as an interface, but if you are going to do that, you may as well implement all the types in some fashion.

So, compatibility of 40% now? Huzzah, huzzah. I often hate the accuracy of my predictions. :(

[Tamamo]

ZoriaRPG
Why don't we go for 0% compatibility and you learn to deal with it. Gleeok already pretty much decided he is not dropping support for ZScript. "since that's crazysauce"
There is therefore no reason for AS and ZScript to be compatible. Pick one or the other, or may'be both who knows.

Therefore every argument you make is invalid. Hence why I am annoyed at you.
Sorry if this makes me sound like a bitch.
Gleeok
Any chance I can convince you to ditch the AS compiler for ZScript, i would rather we play it safe and not have zscript and as interacting with one another... Too much can go wrong.

[SUCCESSOR]

the answer for the zscript thing is already "no, that's dumb". It will take significantly more work for significantly less gain. It seems obvious.

[Grayswandir]

Any chance I can convince you to ditch the AS compiler for ZScript, i would rather we play it safe and not have zscript and as interacting with one another... Too much can go wrong.
I was thinking we'd just expose the ZScript internals to AS as a custom data type or something. Nothing fancy, just let AS get/set any arbitrary ZS variable, no complicated timing or waitdraws or whatever.

In any case, whether it's added or not, I don't believe interaction between the two will affect the current part of the design at all. The decision can be safely put off until AS and ZS are working side by side in the first place.

[Dimentio]

Why don't we go for 0% compatibility and you learn to deal with it. Gleeok already pretty much decided he is not dropping support for ZScript. "since that's crazysauce"
There is therefore no reason for AS and ZScript to be compatible. Pick one or the other, or may'be both who knows.


Precisely. My second option, is parallel operation, with no direct communication. I suppose the ZScript messaging and AS messaging could be used as an interface, but if you are going to do that, you may as well implement all the types in some fashion.

I don't see what you're talking about, Tamamo :P

[Moosh]

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.
I mostly do it because my waitframe functions tend to get more and more arguments as I work on a boss. Every time the number of arguments changes I have to change every instance of those functions, so it's faster to just cram most of them in an array.

So for a boss with laser attacks I might have something like this:

int laserX[32]; //Laser X position
int laserY[32]; //Laser Y position
int laserA[32]; //Laser angle
int laserW[32]; //Laser width
int laserT[32]; //Laser timer
int vars[16] = {laserX, laserY, laserA, laserW, laserT};


void Example_Waitframe(ffc this, npc ghost, int vars){
Example_UpdateLasers(this, ghost, vars);
Ghost_Waitframe(this, ghost, true, true);
}
void Example_UpdateLasers(ffc this, npc ghost, int vars){
int laserX = vars[0];
int laserY = vars[1];
int laserA = vars[2];
int laserW = vars[3];
int laserT = vars[4];
for(int i=0; i<SizeOfArray(laserX); i++){
//pretend this is actually doing something
}
}

I see no use in doing this with global arrays so no worries there. And echoing what Grayswandir said, I learned to do this from looking at some of Saffith's scripts. I LEARNED IT FROM YOU, DAD! I LEARNED IT FROM WATCHING YOU! :P

[ZoriaRPG]

Here is my announcement: We are officially ditching both ZScript and AS for the only appropriate language:

-=SPOILER=-

End of report.

/and I used to be so damned polite./

:banghead:

[SUCCESSOR]

I mostly do it because my waitframe functions tend to get more and more arguments as I work on a boss. Every time the number of arguments changes I have to change every instance of those functions, so it's faster to just cram most of them in an array.

So for a boss with laser attacks I might have something like this:

int laserX[32]; //Laser X position
int laserY[32]; //Laser Y position
int laserA[32]; //Laser angle
int laserW[32]; //Laser width
int laserT[32]; //Laser timer
int vars[16] = {laserX, laserY, laserA, laserW, laserT};


void Example_Waitframe(ffc this, npc ghost, int vars){
Example_UpdateLasers(this, ghost, vars);
Ghost_Waitframe(this, ghost, true, true);
}
void Example_UpdateLasers(ffc this, npc ghost, int vars){
int laserX = vars[0];
int laserY = vars[1];
int laserA = vars[2];
int laserW = vars[3];
int laserT = vars[4];
for(int i=0; i<SizeOfArray(laserX); i++){
//pretend this is actually doing something
}
}

I see no use in doing this with global arrays so no worries there. And echoing what Grayswandir said, I learned to do this from looking at some of Saffith's scripts. I LEARNED IT FROM YOU, DAD! I LEARNED IT FROM WATCHING YOU! :P

O.o

You can do this?! Why do you do this? Why not just pass one big laser array?

[Grayswandir]

Right. While we're speaking of the horrors of zscript, I realized I never mentioned the latest bit I cooked up:

//////////////////////////////////////////////////////////////////
// Pointers are numbers holding a reference to a specific index of a specific
// array. This library deals with the creation and manipulation of pointers.
//
// Pointers are numbers that are split into 2 parts. The integer portion of
// the number (XXX.0000) is the pointer's index into the zscript array. The
// decimal portion of the number (000.XXXX) is the number of the zscript array
// which the pointer is pointing into.
//
// All functions, if the array number is 0, will instead treat the integer
// portion as the array number, and assume an index of 0. This lets you treat
// arrays themselves as pointers to their 0 index.


////////////////////////////////////////////////////////////////
// Creation


// This creates a pointer to a given array. If given a pointer itself, it will
// do nothing and return it instead.
int GP_Pointer(int arg) {
// If arg is a pointer, just return it.
if (10000 * (arg % 1)) {return arg;}
// Otherwise, create a new pointer to the first spot in the array.
return 0.0001 * arg;}


// This takes an array or a pointer, and returns a new pointer offset from the
// first by the given amount.
int GP_Pointer(int pointer, int offset) {
// If arg is a pointer, just add the offset to it.
if (10000 * (pointer % 1)) {return pointer + offset;}
// Otherwise, create a new pointer from the array.
return 0.0001 * pointer + offset;}


////////////////////////////////////////////////////////////////
// Manipulation

// Return the value that the pointer is pointing at, with the index offset by
// the given number.
int GP_Pointer_Get(int pointer, int offset) {
// If pointer is actually an array, just return the 0 position of that
// array.
int array = 10000 * (pointer % 1);
if (!array) {return pointer[offset];}
// Otherwise return the pointer's value. (Array lookup truncates, so we
// don't need to.)
return array[pointer + offset];}

// Set the value of a pointer, with the index offset by the given amount.
void GP_Pointer_Set(int pointer, int offset, int value) {
// If pointer is actually an array, just set the offset position of that array.
int array = 10000 * (pointer % 1);
if (!array) {pointer[offset] = value; return;}
// Otherwise, set the pointer normally. (Array lookup truncates, so we don't
// need to.)
array[pointer + offset] = value;}

It works wonderfully. The only problem is it's a tad bit slow.

[Gleeok]

Yes, this is another problem: ZScript is slow. Especially arrays. I don't want to rathole on this right now though; instead, if any of you guys want to do a performance comparison between c++, ZScript, and AS, I'll add some high precision timers and we can benchmark. We can even start a deadpool.



I see no use in doing this with global arrays so no worries there. And echoing what Grayswandir said, I learned to do this from looking at some of Saffith's scripts. I LEARNED IT FROM YOU, DAD! I LEARNED IT FROM WATCHING YOU! :P

Heh. One of the reasons why I never released the GRIKARUGUN scripts alongside the quest file was because it's like a truckload bunch of stuff you should never do. That, and it's practically incomprehensible. Bad Saffith. :P



O.o

You can do this?! Why do you do this? Why not just pass one big laser array?

Laziness. x_x

[Moosh]

O.o

You can do this?! Why do you do this? Why not just pass one big laser array?
Readability mostly. I find it easier to read when there's multiple parallel arrays than when there's one with a bunch of multiplication or an incomprehensible mess of nested setter and getter functions. I use the one big array method if I'm working with global arrays, but with FFC scripts I haven't been hurt yet by wasting a few variables.

[Tamamo]

Why are we even talking about ZScript here...
This is a discussion about the implementation of angelscript need i remind you guys about that?
If you still want to use zscript thats your business.
If you want to switch over to angelscript that's fine too.

[Dimentio]

Why are we even talking about ZScript here...
This is a discussion about angelscript need i remind you guys about that?
If you still want to use zscript thats your business.
If you want to switch over to angelscript that's fine too.

Because this is topic about Angelscript replacing ZScript. Of course there is going to be talk about ZScript.

[SUCCESSOR]

Because this is topic about Angelscript replacing ZScript. Of course there is going to be talk about ZScript.

This is a topic about implementing AngelScript. The hypothetical future of Zscript discussion is getting a little old and tiring.

[Tamamo]

This is a topic about implementing AngelScript. The hypothetical future of Zscript discussion is getting a little old and tiring.
I feel the same way you do buddy. In fact... It's time i step back in as official zc ambassador since apparently ZoriaRPG ; and i'm just going to be blunk, sucks at his job and doesn't even know what that means. It has nothing to do with the community, it has to do with keeping the develop team from falling apart.
ZoriaRPG Grayswandir Dimentio
if you have nothing else to say about the implementation of angelscript. then feel free to make another thread to discussion compatibility. It's really sad when i'm forced to put my foot down here cause you kids don't know how to stop.
When nobody wanted to go with my suggestion to implement LUA instead of AS i chose to respecte everyone elses decision. It would be nice if you would show me the same courtesy.

[Dimentio]

I feel the same way you do buddy. In fact... It's time i step back in as official zc ambassador since apparently ZoriaRPG ; and i'm just going to be blunk, sucks at his job and doesn't even know what that means. It has nothing to do with the community, it has to do with keeping the develop team from falling apart.
ZoriaRPG Grayswandir Dimentio
if you have nothing else to say about the implementation of angelscript. then feel free to make another thread to discussion compatibility. It's really sad when i'm forced to put my foot down here cause you kids don't know how to stop.
When nobody wanted to go with my suggestion to implement LUA instead of AS i chose to respecte everyone elses decision. It would be nice if you would show me the same courtesy.

Wait, who made you in charge, again? :P
.
Anyways, any discussion on Angelscript is inherently linked to ZScript discussion, so I fail to see why we need two separate topics for this (especially since I don't recall the change to Angelscript ever being... well, confirmed :P (unless that was somehow decided already and I missed it)).

[Tamamo]

especially since I don't recall the change to Angelscript ever being... well, confirmed
It was decided eons ago, by Saffith and Gleeok both . They removed it with every attention to come back to it later. >_>

[SUCCESSOR]

Children! Children...



Anyways, any discussion on Angelscript is inherently linked to ZScript discussion...

Because the discussion on Zscript hasn't been constructive. It's been mostly whining about what *might* happen with Zscript. This isn't the thread to discuss what may or may not happen with Zscript in the future. It's not constructive.

[Grayswandir]

I@ZoriaRPG (http://www.armageddongames.net/member.php?u=42228) @Grayswandir (http://www.armageddongames.net/member.php?u=42509) @Dimentio (http://www.armageddongames.net/member.php?u=61126)
if you have nothing else to say about the implementation of angelscript. then feel free to make another thread to discussion compatibility. It's really sad when i'm forced to put my foot down here cause you kids don't know how to stop.

Because the discussion on Zscript hasn't been constructive. It's been mostly whining about what *might* happen with Zscript. This isn't the thread to discuss what may or may not happen with Zscript in the future. It's not constructive.

I'm not sure why y'all decided that we can't talk about how ZScript and AS interact in this thread. The very first post asks that question:

2. Is it feasible to switch to AngelScript while maintaining compatibility with old quests (presumably, this would require only supporting the ZASM interpreter, and ZScript could be dropped entirely)? Or would an AngelScript-driven ZC live in its own ecosystem separate from the existing program and quests?
Although we could limit this thread to "the parts of implementing AS that specifically don't have anything to do with ZScript," I didn't see any indication that that was the case, and I think it would be detrimental to do so. Arbitrarily viewing the "two" problems in isolation doesn't seem productive to me.

And in my view, it's been constructive. In the last few pages, Gleeok learned about a (major?) problem with integrating ZScript and AS (whatever it is we're doing) he was otherwise unaware of.


I think the real problem with, er, being "constructive", is than nobody knows exactly what's going on. I've discussed various options with lots of people, but nowhere have I seen a decision. I think it'd be helpful if Gleeok or someone briefly described the current AS work done, and what the current plan for the finished product is, even if tentative. It's hard to discuss AS if we're not all on the same page.

[SUCCESSOR]

I'm not sure why y'all decided that we can't talk about how ZScript and AS interact in this thread. The very first post asks that question:

Although we could limit this thread to "the parts of implementing AS that specifically don't have anything to do with ZScript," I didn't see any indication that that was the case, and I think it would be detrimental to do so. Arbitrarily viewing the "two" problems in isolation doesn't seem productive to me.

And in my view, it's been constructive. In the last few pages, Gleeok learned about a (major?) problem with integrating ZScript and AS (whatever it is we're doing) he was otherwise unaware of.


I think the real problem with, er, being "constructive", is than nobody knows exactly what's going on. I've discussed various options with lots of people, but nowhere have I seen a decision. I think it'd be helpful if Gleeok or someone briefly described the current AS work done, and what the current plan for the finished product is, even if tentative. It's hard to discuss AS if we're not all on the same page.


You seem to be deliberately taking what I said out of context. Anyone with relevant points or questions on the subject of this thread are not something I would(or have) take issue with. The fact that it evolved into whining and bickering about things that have already been covered is what is getting irksome. As most certainly the portion of DD's post you quoted has been covered. Not with absolute certainty, but nothing is certain right now.

What is the MAJOR problem? The array thing? People will have to update their broken scripts that will be unsupported because of their stupid, awful code. How is that an issue? Solution: Don't code bad. (I code bad all the time but.... TRY DON'T CODE BAD!)

Gleeok has stated what he is doing. I don't think Gleeok explains things. If you want to know exactly what he is doing you will have to just jump in and try to figure it out. As I am doing. Well, I haven't actually spent very much time doing it because of school and work.

[Gleeok]

What I'm doing:

AS needs bindings to ZC stuff, because the scripts need to call things like Link.HP etc.. There are about 400 functions total. AS also needs types declared like lweapon, ect with methods for those. These won't work exactly like ZScript, since I'm optimizing for performance whenever possible.

General mechanisms for creating and calling scripts similar to ZScript so they are comparable, plus lots of messaging support.

Lexing and preprocessing scripts so they are closer to ZScript and simpler syntactically than c++.

I'm also putting in array specializations for all known types, again, for a performance boost.

The part that will take the longest is bindings to legacy ZScript functions... and I'll probably release the first AS prototype before this is even done.

...So there you go.

[Grayswandir]

You seem to be deliberately taking what I said out of context. Anyone with relevant points or questions on the subject of this thread are not something I would(or have) take issue with. The fact that it evolved into whining and bickering about things that have already been covered is what is getting irksome. As most certainly the portion of DD's post you quoted has been covered. Not with absolute certainty, but nothing is certain right now.
What exactly did I take out of context? I assure you, there were no "deliberate" misunderstandings on my part. I skimmed the thread and everything seemed (reasonably) on topic to me. (At least, it was as on topic as your constant incitement to kill ZScript or whatever.)


What is the MAJOR problem? The array thing? People will have to update their broken scripts that will be unsupported because of their stupid, awful code. How is that an issue? Solution: Don't code bad. (I code bad all the time but.... TRY DON'T CODE BAD!)Around half of all extant scripts breaking is a pretty big problem, yes. I mean, I personally don't care that much, but ZC seems to be pretty big on backward compatibility in general. And it's not "bad code". It's the best way to emulate pointers in the crappy ZScript syntax. You can work around it, yes, but for any non-trivial examples, doing so introduces so much more complexity that the "bad" syntax is more than compensated for.


Gleeok has stated what he is doing. I don't think Gleeok explains things. If you want to know exactly what he is doing you will have to just jump in and try to figure it out. As I am doing. Well, I haven't actually spent very much time doing it because of school and work.Well, certainly, he doesn't have to. I just thought that some sort of update would be useful. I still don't know what the final plan is, aside from "AS is being added." Plenty of different options have been discussed, but I haven't seen anything definite, only words along the lines of "everything will work fine."


Edit: See, that was pretty helpful. :) Thanks for the prompt response, Gleeok.

[Tamamo]

Around half of all extant scripts breaking is a pretty big problem, yes. I mean, I personally don't care that much, but ZC seems to be pretty big on backward compatibility in general. And it's not "bad code". It's the best way to emulate pointers in the crappy ZScript syntax. You can work around it, yes, but for any non-trivial examples, doing so introduces so much more complexity that the "bad" syntax is more than compensated for. .

Okay we're done it's a limitation of ZScript's syntax that we're talking about here., which someone found a way to get around. THAT is the very definition of bad programming practice. If the head developer says its bad programming practice as Gleeok already has. Then it's bad programming practice. End of discussion.
Now you and your zc.future posse can stop your flipping bickering at me and everyone else you are bickering at cause it's completely disrespectful.

Cool it, both of you.
-KA-

[SUCCESSOR]

What exactly did I take out of context? I assure you, there were no "deliberate" misunderstandings on my part. I skimmed the thread and everything seemed (reasonably) on topic to me. (At least, it was as on topic as your constant incitement to kill ZScript or whatever.)

Around half of all extant scripts breaking is a pretty big problem, yes. I mean, I personally don't care that much, but ZC seems to be pretty big on backward compatibility in general. And it's not "bad code". It's the best way to emulate pointers in the crappy ZScript syntax. You can work around it, yes, but for any non-trivial examples, doing so introduces so much more complexity that the "bad" syntax is more than compensated for.

Well, certainly, he doesn't have to. I just thought that some sort of update would be useful. I still don't know what the final plan is, aside from "AS is being added." Plenty of different options have been discussed, but I haven't seen anything definite, only words along the lines of "everything will work fine."


Edit: See, that was pretty helpful. :) Thanks for the prompt response, Gleeok.

I didn't say, DON't TALK ABOUT ZS EVARRR! I said the discussion of it's hypothetical future, as in things that aren't in anyway certain yet weren't constructive or relevant. And yes, I do support AS replacing ZS. I have used ZS for over 5 years now and I would take anything over it.

Half of all extant scripts? You got a source on that? Last I heard, Gleeok *estimated* 98% compatibility with a conversion tool and DD stated keeping the interpreter for legacy quests so, 100% compatibility. Far off from 50%. And I have never seen that array thing in a script until Moosh posted that snippet so it can't be a significant chunk of extant code. And what does it work around? What limitation is it working around that can't be done in a safer way? Moosh's example came to personal preference.

There isnt a final plan. Gleeok is working on AS. That is the only plan on the matter. Until it becomes officially a part of the codebase then Zscript is still the official coding engine. As DD said, it makes sense if AS works out for it to replace ZS.

[SUCCESSOR]

Okay we're done it's a limitation of ZScript's syntax that we're talking about here., which someone found a way to get around. THAT is the very definition of bad programming practice. If the head developer says its bad programming practice as Gleeok already has. Then it's bad programming practice. End of discussion.
Now you and your zc.future posse can stop your flipping bickering at me and everyone else you are bickering at cause it's completely disrespectful.

You are being equally disrespectful. You don't get to declare yourself right and command the discussion is terminated. This sort of post isn't helping the bickering.

Yes, my posts aren't exactly the posterchild of deescalation, but you have to read anything i write with a hint of sarcasm and a dash of levity... Or else I just sound like an asshole.

[Grayswandir]

I didn't say, DON't TALK ABOUT ZS EVARRR! I said the discussion of it's hypothetical future, as in things that aren't in anyway certain yet weren't constructive or relevant. And yes, I do support AS replacing ZS. I have used ZS for over 5 years now and I would take anything over it.
Well, that's more reasonable, I guess.


Half of all extant scripts? You got a source on that? Last I heard, Gleeok *estimated* 98% compatibility with a conversion tool and DD stated keeping the interpreter for legacy quests so, 100% compatibility. Far off from 50%. And I have never seen that array thing in a script until Moosh posted that snippet so it can't be a significant chunk of extant code. And what does it work around? What limitation is it working around that can't be done in a safer way? Moosh's example came to personal preference.
Like I said, ghost.zh uses that trick. I'd estimate that half of all scripts in use are ghost scripts. In any case, it's a big chunk of them. And I know several users who hack into their copy of the ghost library itself to fix perceived bugs, making it rather difficult for them to update to whatever new version fixes this issue. I'd estimate the workaround at around 50 lines of code.
In any case, I'd estimate that every recent moderately script heavy quest uses it somewhere or else. (Maybe not LaZ? That was mostly developed independent of everything else. I'd have to ask about that.)

As for what it's used for - like I said, it emulates pointers. So you can use it for whatever kinda thing you'd normally use pointers for. Ghost uses it to stuff 20 or so data values into a single npc->Misc slot. (That particular workaround is dynamically assigning an id in a dedicated global array. You're moving into psuedo-memory management at that point, though). I've used it for a malloc/free system, linked lists, hashmaps, etc. (Though I haven't really released anything...)

[Tamamo]

I'm not being disrespectful. And I do get to declare myself right. ummm... Yeah... Because I'm a woman, and woman are always right. :rolleyes:
As for the second part of that equation... meh I'm done with these shenanigans the zc.future posse was the primary reason I left Development in the first place. Why i even thought about joining this warzone again is beyond me, because the posse and the official devs will never get along, that's always been apparent. And nobody seems to like a bitchy japanese woman whose pmsing so fuck it.

[SUCCESSOR]

Well, that's more reasonable, I guess.


Like I said, ghost.zh uses that trick. I'd estimate that half of all scripts in use are ghost scripts. In any case, it's a big chunk of them. And I know several users who hack into their copy of the ghost library itself to fix perceived bugs, making it rather difficult for them to update to whatever new version fixes this issue. I'd estimate the workaround at around 50 lines of code.
In any case, I'd estimate that every recent moderately script heavy quest uses it somewhere or else. (Maybe not LaZ? That was mostly developed independent of everything else. I'd have to ask about that.)

As for what it's used for - like I said, it emulates pointers. So you can use it for whatever kinda thing you'd normally use pointers for. Ghost uses it to stuff 20 or so data values into a single npc->Misc slot. (That particular workaround is dynamically assigning an id in a dedicated global array. You're moving into psuedo-memory management at that point, though). I've used it for a malloc/free system, linked lists, hashmaps, etc. (Though I haven't really released anything...)

All I saw in your quote of ghost.zh code was the passing of an array pointer. Not the abuse of ZS's wonky data type.

[Grayswandir]

So passing an array pointer is fine, but putting an array pointer inside an array isn't? One level of indirection is fine, but not two?

[SUCCESSOR]

Morning eyes. I see how what he is doing is the same.

Passing an array pointer to a function is what I assume the behavior being abused was meant to support is different from creating a spaghetti bowl of arrays of pointers to arrays being passed around for the fun of it.

At least I see why saffith did it. Tell me something. If the only option is a conversion tool or even if ZS gets updated to a language with standard types, how would you support that?

It seems to me the people against replacing ZS are the ones hacking it to do things it really wasn't meant to do, things a better scripting language could easily do.

[SUCCESSOR]

I'm starting to come around. In the context of ZS, anyway. Seeing how ghost.zh used it has my gears turning on how this could be really useful.

Its like a guy playing guitar using only his thumbs, and I'm like, "so what. I can play that and not look like a potato!" And then he shreds that Vai piece from that corny 80s film and I'm like, maybe I should try that.... Potato up!

I'd still rather have a better scripting language.

[Gleeok]

So passing an array pointer is fine, but putting an array pointer inside an array isn't? One level of indirection is fine, but not two?

The way LocalRAM works is sort of guaranteeing you won't get crashes or random memory, however you should get a wall of out-of-bounds errors if you manage array lifetimes wrong. It also means arrays in ZScript are sort of stuck that way now and can't be fixed.

[ZoriaRPG]

The way LocalRAM works is sort of guaranteeing you won't get crashes or random memory, however you should get a wall of out-of-bounds errors if you manage array lifetimes wrong. It also means arrays in ZScript are sort of stuck that way now and can't be fixed.

Well, they could be 'fixed' if we truly wanted to go to the effort of adding real arrays, which AFAIK we don't. If we did, they'd just be declared with different syntax, and be true array data, but that's a lot of effort for little reward, save that strings would be real char. I wanted to do that once upon a time, but I've been convinced otherwise more recently.

It is true that if the stored pointers become invalid, the user will hit boundary walls, or other errors may occur; but that is purely user error. You can't possibly package every possible code mishap in bubble plastic to make it extra-safe from any incident.

I'll wait for a working example of your implementation before I discuss anything further on the subject, unless there are any factual, genuine concerns that now exist to discuss. I think that we covered the basics thus far, made some decisions, and have a direction. Once all of our code is in line, our ducks fall in line to be exterminated, and Venus gives Jupiter a celestial lap dance, we can have yet-another-tangent; so, a few months?

I'm frankly sick to death of this entire debate, which we could have resolved far more efficiently if everyone was on the same page from the onset. I should have been more blatant when I initially mentioned the problems that are genuine concerns. Good luck, and happy programming.