AngelScript: The Revenge

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;}

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.

Moosh wrote:
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

SUCCESSOR wrote:O.o

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

Laziness. x_x

SUCCESSOR wrote:O.o

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

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.

Tamamo wrote: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.

Dimentio wrote: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.

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

Tamamo wrote:I feel the same way you do buddy. In fact... It's time i step back in as official zc ambassador since apparently [MENTION=42228]ZoriaRPG[/MENTION] ; 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.
[MENTION=42228]ZoriaRPG[/MENTION] [MENTION=42509]Grayswandir[/MENTION] [MENTION=61126]Dimentio[/MENTION]
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)).

especially since I don't recall the change to Angelscript ever being... well, confirmed

Children! Children...

Dimentio wrote:
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.

Tamamo wrote:I@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.

SUCCESSOR wrote: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:

DarkDragon wrote: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?

And in my view, it's been constructive. In the last few pages, [MENTION=42714]Gleeok[/MENTION] 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 [MENTION=42714]Gleeok[/MENTION] 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.

Grayswandir wrote: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, [MENTION=42714]Gleeok[/MENTION] 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 [MENTION=42714]Gleeok[/MENTION] 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.

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.

SUCCESSOR wrote: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.

SUCCESSOR wrote: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!)

SUCCESSOR wrote: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.

Edit: See, that was pretty helpful. 😊 Thanks for the prompt response, [MENTION=42714]Gleeok[/MENTION].

Grayswandir wrote: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 [MENTION=42714]Gleeok[/MENTION] 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-

Grayswandir wrote: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, [MENTION=42714]Gleeok[/MENTION].

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.

Tamamo wrote: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 [MENTION=42714]Gleeok[/MENTION] 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.

SUCCESSOR wrote: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.

SUCCESSOR wrote: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.

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

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

Grayswandir wrote: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.

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?

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.

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.

Grayswandir wrote: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.

Gleeok wrote: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.