Gs3

[MattKan]

Originally Posted by Jiroxys7

Also, is there any chance we would be able to have support for collapsing functions?

I fully support this.

[iAxeis]

Can't wait to start scripting GS3!!!

[Draenin]

Any chance we'll see more official documentation and tutorials posted as well for this stuff?

[Matt]

Originally Posted by Fidel Castro

Slow down guys I'm still trying to learn Gs1

I'm in the same boat

[Tim_Rocks]

Originally Posted by Fidel Castro

Slow down guys I'm still trying to learn Gs1

Life is hard.

[bloodpet]

Originally Posted by Matt

I'm in the same boat

would be pointless now to learn gs1.. just go straight to gs2 theres plenty of tutorials... a majority of scripting is just functions, syntax and some math.. xD i dont even have to memorize much if you use the forums and have somewhat of an idea what your trying to search

[maximus_asinus]

Gs2 is pointless, goku didn't even use it

[Twinny]

I'm massively in favour of strict typing but I agree with the notion that the current declarations look messy. Would prefer the much more standardised,

PHP Code:

float pi = 3.14;
baddy sterrence = new Baddy(); 


Anything new and exciting happening on the backend? Considering you're making these changes for the data types, perhaps also add the ability to use protected vars? Any form of language security would be great considering the currently open and abusable state it is in now.

Not related to language syntax but wouldn't it be amazing if you could start adding the ability to run a function on a new thread (intensive long-distance pathfinding anyone)? I hate the fact that a single intensive function (or badly written script) can bring the entire server to a halt..

PHP Code:

function pathfind(x,y,dx,dy) {};
thread pathfind = new thread(pathfind(1,1,64,64));
pathfind.setPriority(1);
pathfind.Start();

while (pathfind.isActive) {
  npc.lookVacant();
}
npc.followPath(pathfind.return); 


Ideally, you could have an event called from within the thread to let you know it's finished rather than using a loop to check but yeah!

The other added advantage would be putting core running systems on a separate, higher-priority thread so it doesn't get as interrupted during high loads.

[Loriel]

Hi I haven't logged into the game for years but I disagree with your entire post.

Originally Posted by Twinny

but I agree with the notion that the current declarations look messy. Would prefer the much more standardised,

PHP Code:

float pi = 3.14;
baddy sterrence = new Baddy(); 


I'm a fan of explicit syntax for variable declarations (like `var`) and type annotation. Just putting a few words next to each other and hoping for the best leads to a C++-style "long typedef int const unsigned volatile x;" mess, even before you get into pointers and function pointers and arrays and generics and whatever else gs3 might not get the same syntax freeform for. I mean I guess I'm not 100% married to postfix type annotations but it seems to get messy otherwise (`var(float) x`?) and there's piles of precedent for the `var:type` thing.

Also I believe parser-wise having a token like `:` that basically means "okay, there's gonna be a type here, not an expression" makes things a lot easier and cleaner, but I have no idea how that applies to gscript i particular.

Anything new and exciting happening on the backend? Considering you're making these changes for the data types, perhaps also add the ability to use protected vars? Any form of language security would be great considering the currently open and abusable state it is in now.

I'm not familiar with any programming environment where visibility modifieres like `protected` are a security feature. C++ isn't memory-safe to begin with, in Java and C# or ruby or whatever you can circumvent visibility with reflection-ish APIs, and even in type-theory-obsessed Haskell you can just define a similar-looking type without the visibility restrictions and unsafely coerce between the restricted and unrestricted types. "Security" would need to be a fairly elaborate and orthogonal concern where you think about trust boundaries and all sorts of things that ugh it looks really complicated in java let's not do that. Can't people just be nice.

I'm of course all for a cool module system that lets you expose as little as necessary of your code to code written by your presumably incompetent shithead collaborators, instead of dumping everything into a huge dynamic object graph. We're probably halfways getting there with declaring global variables. I dunno.

Not related to language syntax but wouldn't it be amazing if you could start adding the ability to run a function on a new thread (intensive long-distance pathfinding anyone)? I hate the fact that a single intensive function (or badly written script) can bring the entire server to a halt..

[...]

Ideally, you could have an event called from within the thread to let you know it's finished rather than using a loop to check but yeah!

The other added advantage would be putting core running systems on a separate, higher-priority thread so it doesn't get as interrupted during high loads.

Threads+mutable shared state is an evil combinations, the javascript folks are flipping the **** out at the prospect of doing unrestrained threads, and everybody is kinda trying to get away from that programming model towards some message-passing, share-nothing concurrency thing if they can. Python can't even thread because they figure people would just get it wrong. C++11 had to change around half the language to even have the words to specify what concurrency does.

Arguably people have run into the whole "hmmm, I need to do something computationally intensive without blocking the GUI or whatever, I guess I'm ****ed" situation before but I don't think preemptive multithreading is going to do anything but set your server on fire and confuse everyone even more.

Maybe some sort of "idle handler" that wouldn't run concurrently but between regular script events with some API that makes yielding after each iteration of your crazy pathfinding algorithm required or at least natural would work as a compromise...

[Loriel]

Also wow I realize I've been doing the exact same thing, but all gscript language discussion ever is "I just learned this other programming language, so why can't gscript do ******", it's kinda depressing.

[Loriel]

http://deploytonenyures.blogspot.com...e-members.html also this is ridiculous, don't do that.

[Twinny]

Originally Posted by Loriel

Hi I haven't logged into the game for years but I disagree with your entire post.



I'm a fan of explicit syntax for variable declarations (like `var`) and type annotation. Just putting a few words next to each other and hoping for the best leads to a C++-style "long typedef int const unsigned volatile x;" mess, even before you get into pointers and function pointers and arrays and generics and whatever else gs3 might not get the same syntax freeform for. I mean I guess I'm not 100% married to postfix type annotations but it seems to get messy otherwise (`var(float) x`?) and there's piles of precedent for the `var:type` thing.

Also I believe parser-wise having a token like `:` that basically means "okay, there's gonna be a type here, not an expression" makes things a lot easier and cleaner, but I have no idea how that applies to gscript i particular.

It really is just personal preference and thats the style I'm used to. I will use whatever comes but again, the name:type just seems weird to me.

I'm not familiar with any programming environment where visibility modifieres like `protected` are a security feature. C++ isn't memory-safe to begin with, in Java and C# or ruby or whatever you can circumvent visibility with reflection-ish APIs, and even in type-theory-obsessed Haskell you can just define a similar-looking type without the visibility restrictions and unsafely coerce between the restricted and unrestricted types. "Security" would need to be a fairly elaborate and orthogonal concern where you think about trust boundaries and all sorts of things that ugh it looks really complicated in java let's not do that. Can't people just be nice.

I'm of course all for a cool module system that lets you expose as little as necessary of your code to code written by your presumably incompetent shithead collaborators, instead of dumping everything into a huge dynamic object graph. We're probably halfways getting there with declaring global variables. I dunno.

Not so much language safety as environment safety, multiple developer safety. There are many instances where I'd like to prevent other staff members from altering certain values without needing to do some silly encryption or hide it somewhere else. Thankfully, we have no way to directly access memory

The other advantage is ensuring other developers will use your public functions rather then hack something together and have their system break when the internals of your system breaks. There are no professional teams as far as Graal is concerned so anything to bring consistency and abuse-prevention into this language would be great.

Threads+mutable shared state is an evil combinations, the javascript folks are flipping the **** out at the prospect of doing unrestrained threads, and everybody is kinda trying to get away from that programming model towards some message-passing, share-nothing concurrency thing if they can. Python can't even thread because they figure people would just get it wrong. C++11 had to change around half the language to even have the words to specify what concurrency does.

Arguably people have run into the whole "hmmm, I need to do something computationally intensive without blocking the GUI or whatever, I guess I'm ****ed" situation before but I don't think preemptive multithreading is going to do anything but set your server on fire and confuse everyone even more.

Maybe some sort of "idle handler" that wouldn't run concurrently but between regular script events with some API that makes yielding after each iteration of your crazy pathfinding algorithm required or at least natural would work as a compromise...

I had suggested a priority variable to Stefan before, just a single var in a script to tell the backend this script should run at a higher priority but that would be a lot of changes as well.

We have an opportunity (Stefan pending) to add new functionality to the language. I have nothing against completely isolated threads but i think mutable shared state would probably be easier for most devs. Perhaps all locking can be automated for the developer, giving a simpler method of using threads. Of course, this could just make things god awful and worse than when it began.

Regardless of how simple (or damn difficult) the language made it, this would be advanced scripting so only devs who knew how to do it and what gains (if any) would be available. Would love to see some experiments to see if there is any potential benefit.

[Twinny]

Stefan,

Any chance you can provide background on your particular choices?

[BlueMelon]

GS3, something new to look forward to in 'x' amount of years.

[Twinny]

Trying to use it on N-Pulse but getting the following,

GS3 strict mode is not enabled, cannot compile Twinny/GS3

Restarting NPC-Server didn't help. How can I enable this?