Gs3

[scriptless]

Originally Posted by Crono

it won't ;[

Yeah it wouldn't. A lot of things are now being done on serverside. For example if you tried taking GK offline, it would not work since most of it is serverside script and we do not have a NPC Server to use in combination to the level editor.

[DustyPorViva]

Originally Posted by Loriel

I dunno how offline development would even work anymore with half your systems running on the server. It'd be great to be able to deploy completely isolated dev environments loclly so you could use stuff like decentralized source control without bending over backwards, and it's not like in tyool 2013 the npcserver is such a trade secret that it can't be integrated into the client. Lots of multiplayer games with a singleplayer mode basically ship the game mechanics if not the networking bits of their server in the client. shrug.

Just being able to do clientside would be good enough, in my opinion.

[xXziroXx]

Originally Posted by DustyPorViva

Just being able to do clientside would be good enough, in my opinion.

Agreed. Scripting offline is mostly for newer developers attempting to learn the language, and I don't think most of us would've been here today if we didn't have access too it way back.

[Admins]

We more think of making a better tool for level editing. It should support basic attributes (drawunderplayer, dontblock) and joining of a class, but scripting should be done on server-side, possibly via web-based tools.

[DustyPorViva]

Originally Posted by Stefan

It should support basic attributes (drawunderplayer, dontblock) and joining of a class

And >8bit pngs?

[Loriel]

Originally Posted by Stefan

We more think of making a better tool for level editing. It should support basic attributes (drawunderplayer, dontblock) and joining of a class, but scripting should be done on server-side, possibly via web-based tools.

So more like a list of attributes rather than a scripting language?

If you're gonna release a web-based editor so we can stop feeling bad whenever gonstruct doesn't work, that'd be great, anyway~

[scriptless]

Originally Posted by Loriel

So more like a list of attributes rather than a scripting language?

If you're gonna release a web-based editor so we can stop feeling bad whenever gonstruct doesn't work, that'd be great, anyway~

I would take a web-based editor any day.. I do not under any circumstances like, or use the online editor. First of all that requires a $100 downpayment, or access to a friends server. Who then likely steals all your content anyways.

I was toying around with making a HTML 5 version of a level editor because quite honestly, being a mac user and after recent discussion on mac ports and gonstruct.. its obviously not gonna install for me and all hope is lost.

[Rave_J]

i would liek to c a web based level editor or keep it a separate program that connects online to script but if its a online editor i would fully stop making levels

[xAndrewx]

A lot of people are assuming that GS3 is a HUGE change compared to GS2- however, it will be the same as GS2; you'll just need to predefine variables and learn the syntax.

The functions (i.e. drawunderplayer; dontblock; ) won't be changing as far as I understand?

[figured]

sounds interesting but if at all possible can this work on all the platforms? windows, mac, and linux? that would greatly be appreciated.. and extend the community of developers :0 which would greatly help produce quality servers in the long run.

[Tim_Rocks]

This sounds really exciting actually; And if this is web-browser based developing tools, then all you'd need is a compatible browser. With that being said, please use Google Chrome

[BlueMelon]

Stefan, make the web dev tools open source so the community can help add features

@Tim, HTML5 is supported almost everywhere now (assuming that's what he'll use :x)

[Loriel]

Originally Posted by BlueMelon

open source so the community can help add features

l o l

[Fidel Castro]

Slow down guys I'm still trying to learn Gs1

[Tim_Rocks]

Originally Posted by BlueMelon

@Tim, HTML5 is supported almost everywhere now (assuming that's what he'll use :x)

There's still slight computability issues that he'll have to account for when testing on IE, Safari, Chrome, Opera, and Fire Fox. That's what I was getting at.

[Crow]

Originally Posted by Tim_Rocks

There's still slight computability issues that he'll have to account for when testing on IE, Safari, Chrome, Opera, and Fire Fox. That's what I was getting at.

There are compatibility issues on all browsers, as not a single browser has implemented every HTML5 standard yet. However, Chrome, Opera and IE should have implemented most of it by now.

[Tekoukiol]

Good luck on the scripting program for Graal. Nice work on the details,
Really provides help to beginner Scripters.

[Hiro]

can u pls mak everythn ezr?

all scripts shud jus be if and then

pls

[brokk]

Well this just made my day

[Jiroxys7]

Originally Posted by fowlplay4

Personally prefer the Java-style of declaring variables/types than your current GS3 way, no need to carry over how we currently use temp to GS3 as it just adds unnecessary code.

type variable;

Being able to create global functions would be cool too, I imagine GS3 would be more flexible in some way that we can modify built-in functions?

I.e.

PHP Code:

class Options extends TGraalVar { 
  int age;
  string gender;
  string city;
}

function void saveOptions() { 
  Options options = new Options(); 
  options.age = 24; 
  options.gender = "female"; 
  options.city = "Dallas"; 
  options.savevars("options.txt", 0); 
}

function number addNumbers(number a, number b) {
  return a + b;
} 


This is shockingly similar to how C# works, too. I would not mind this one bit.

Also, is there any chance we would be able to have support for collapsing functions? For example, if you were to collapse FP4's example, in Visual Studio it would look something like:

PHP Code:

class Options extends TGraalVar[...]
function void saveOptions()[...]
function number addNumbers(number a, number b)[...] 


I've found this this makes it much, much easier to navigate large scripts that contain dozens of functions. I understand this isn't related to the actual language as much as it is a change to the code viewer, but it would be very nice to have nonetheless.

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

[Cubical]

I also had this problem when I initially tried it.

[Twinny]

Originally Posted by Cubical

I also had this problem when I initially tried it.

And you resolved it....how?

[Cubical]

I never tried again because I stopped developing and playing for the most part due to the lag not only on the classic servers but on my UC playerworld.

[BlueMelon]

Twinny it will probably take a while for it to be enabled...

[Cubical]

Originally Posted by Stefan

The progress

We are already working on a converter which helps to convert scripts from GS2 to GS3. So a lot of work will be lifted from the programmer, and you can also use this tool for testing how the new scripting will look like.
Additional following things can be important to know:
- existing scripts will still run, we don't force the new syntax and semantic, but it can be interesting for server-side logic and also new client-side code
- just add a //#GS3 line to your script to use the new syntax and semantic
- some syntax of the new Graal script is already supported but currently ignored (like var statements)

That is implying that it is already enabled