PDA

View Full Version : Gs3


Admins
04-12-2013, 03:24 PM
Hello Graalians,

We have just started the work on a new scripting project and want your ideas and feedback about it. The idea is to create new Graal Script version (GS3) which will make scripts faster and more fit for bigger projects.

The idea

We plan to introduce 'types' to Graal script. This first means some more work for scripters but it also has some dramatic advantages:
- Scripts can run faster
- More reliable because it will complain when a variable has not been declared or is used incorrectly. This is important when doing bigger projects.
- We can possibly convert the scripts to other languages (C++, Javascript etc.) so it can possibly run in a browser in the future
- Code will be more readable, you don't have to guess what kind of variables need to be passed to a function or is returned by a function

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)

Examples

Functions:
Old:

function getAddition(a, b) {
temp.result = a + b;
return temp.result;
}
New:

function getAddition(a:number, b:number):number {
var result:number = a + b;
return result;
}


Gui:
Old:

new GuiControlProfile("Games_Msg_BackProfile") {
modal = false;
}

New:

var profile:GuiControlProfile = new GuiControlProfile("Games_Msg_BackProfile");
profile.modal = false;


Type declarations:
Old:

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

New:

class Options extends TGraalVar {
var age : int;
var gender : string;
var city : string;
}
function saveOptions():void {
var options:Options = new Options();
options.age = 24;
options.gender = "female";
options.city = "Dallas";
options.savevars("options.txt", 0);
}


What is changing

- You need to declare the type of variables: var myvar: int;
Available types: string, boolean, int, number, void, type[] (for arrays), dictionary<string, int>
- Use "var" declarations instead of temp.
- You can also declare variables of a weapon or NPC at the beginning of the script using var myvar: type;
- The "with" statement is removed and the "new" statement is single-line, you need to call addcontrol() manually
- The dictionary type is needed if you want to access variables with dynamic variable name like this.mydictionary.("start" @ 1)
- Flexible number of function parameters can be done using function(first:int, ... params) (params is a dictionary)
- Global variables can only be accessed directly if you provide a global declaration or if you use findobject("objectname")
- You need to call this.myfunction() instead of myfunction()
- join() works more like an include in C++, there is no this.join anymore
- You can declare new classes (also called structures, types) inline like class MyClass extend TStaticVar; weapons are automatically extending TServerWeapon, NPCs are automatically extending TServerNPC
- The for (member: array) syntax needs to be changed to for (member in array)

Your ideas

As you can see the new Graal script is basically adding type declarations and changing a few smaller things to be more compatible with other languages. Please tell us if you like the new scripting or not, and if you have some stuff which you would like to see in the new scripting language, such as private variables or getter and setter functions. We have just started the project so everything is still possible. We can imagine there are a lot of questions regarding compatiblity and similar.

Hezzy002
04-12-2013, 03:49 PM
Why don't you use a popular scripting language like Lua, because there's a massive library of documentation and tutorials for it, and a massive group of people who actually know it already? And LuaJIT is way faster than anything you can develop in-house.

There are also dozens of things that should be a higher priority than this.

Crono
04-12-2013, 03:49 PM
will players notice a difference? do you think we'll see new features thanks to this upgrade? :}

Crow
04-12-2013, 04:24 PM
Your type syntax looks awful, I wouldn't ever want to use that. Also, one major good point about scripting languages is the lack of type definitions, at least in my opinion. Go with Hezzy's suggestions, use Lua, Python or something similar. Some types of calculations done in Lua can even be as fast as pure C code, or so I've heard.

Gos_pira
04-12-2013, 04:47 PM
The C# syntax is nice. I never liked the LUA syntax. I'm for defining variable types and have a more object oriented language though. :)

Crow
04-12-2013, 05:08 PM
The C# syntax is nice. I never liked the LUA syntax. I'm for defining variable types and have a more object oriented language though. :)

Please, Lua. Not LUA. D:

Emera
04-12-2013, 05:26 PM
I'm not learning another language when the language you have right now can more or less be edited and given just about whatever functionality you want. Why make the community learn a new syntax, especially when the scripting community on here isn't very big.

Crow
04-12-2013, 06:19 PM
Because a syntax isn't difficult to learn, especially not Lua's.

smirt362
04-12-2013, 06:31 PM
Masking support. Lets get some classic SNES effects on Graal. I still want to make some crazy stuff.

http://i.imgur.com/EB4zAQc.png

Will we also be getting a new Gani and Level editor as well?

DustyPorViva
04-12-2013, 06:51 PM
Is this really the best time to do this? Development on Graal is dwindling; there's hardly any scripters left. Do you really want to potentially isolate the few scripters left? GS2 was never documented that well, especially when new things were added. I still have to hunt around the forums looking for anything added in the last couple of years because it's not documented anywhere else. GS1 isn't properly phased out still, yet many people still use it in levels because we still don't have any updated tools. And with Testbed gone there's not even a place available to practice scripting.

edit: I guess since it isn't mandatory it isn't that bad... but I also imagine it's not going to be widely used either. Going to be honest, you're probably going to be the only person using it. I can't say I like the declaration syntax either.

scriptless
04-12-2013, 07:32 PM
First, are servers currently updated to support this?

I notice some things in the new GS3 that I catch myself trying to do in GS2.. so I am glad to see these changes.

Masking support. Lets get some classic SNES effects on Graal. I still want to make some crazy stuff.

http://i.imgur.com/EB4zAQc.png

Will we also be getting a new Gani and Level editor as well?

Oh, I would love masking support... that would be awesome..

Is this really the best time to do this? Development on Graal is dwindling; there's hardly any scripters left. Do you really want to potentially isolate the few scripters left? GS2 was never documented that well, especially when new things were added. I still have to hunt around the forums looking for anything added in the last couple of years because it's not documented anywhere else. GS1 isn't properly phased out still, yet many people still use it in levels because we still don't have any updated tools. And with Testbed gone there's not even a place available to practice scripting.

edit: I guess since it isn't mandatory it isn't that bad... but I also imagine it's not going to be widely used either. Going to be honest, you're probably going to be the only person using it. I can't say I like the declaration syntax either.

Yeah but unfortunately us Mac OS X 10.6 users have no level editor, and using macports with gonstruct seemed to get me no where at all. So I can't even develop levels right now due to the lack of tools. There really needs to be an SDK kit..

BlueMelon
04-12-2013, 07:33 PM
I develop on graal for the simplicity of the scripting language that is used...

This type of syntax would not fit well with graal scripters/developers introducing types makes it look more like you're building software. What I like about GS2 is the use of temp. this. thiso, etc.

Lua on the other hand is fast/flexible. Lua is a great language.

callimuc
04-12-2013, 08:30 PM
you should introduce it on one server which could be set up like testbed, but supported by you/graal. it also should be well documented so people could try it out and feedback could be given

scriptless
04-12-2013, 08:36 PM
I develop on graal for the simplicity of the scripting language that is used...

This type of syntax would not fit well with graal scripters/developers introducing types makes it look more like you're building software. What I like about GS2 is the use of temp. this. thiso, etc.

Lua on the other hand is fast/flexible. Lua is a great language.

Thats the only thing I do not like. I do not want to have to declare the type before assigning it. Thats what made graal so fun to develop for (for me).. But the example for how he did the GUI and assigned the modal, is exactly how my instinct tries to do.. if i assign something to an object. i want to be able to change it that way. =/

dylan
04-12-2013, 08:54 PM
Aren't you a little late on April Fools? It's the twelfth. :[

fowlplay4
04-12-2013, 08:56 PM
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.


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

MattKan
04-12-2013, 09:35 PM
Are there any benefits to adopting GS3 or is just change for the sake of change?

DustyPorViva
04-12-2013, 09:39 PM
Personally prefer the Java-style of declaring variables/types

Ditto, but I felt biased saying that since I only know Java.

scriptless
04-12-2013, 09:54 PM
Are there any benefits to adopting GS3 or is just change for the sake of change?

Yes.


dramatic advantages:
- Scripts can run faster
- More reliable because it will complain when a variable has not been declared or is used incorrectly. This is important when doing bigger projects.
- We can possibly convert the scripts to other languages (C++, Javascript etc.) so it can possibly run in a browser in the future
- Code will be more readable, you don't have to guess what kind of variables need to be passed to a function or is returned by a function

fowlplay4
04-12-2013, 10:07 PM
Are there any benefits to adopting GS3 or is just change for the sake of change?

According to Stefan: Faster, will run better on other platforms, forcing people to declare variables/types will make code more self-documenting (You can see that in the options example) and also more stricter so perhaps stuff won't break as easy.

Cubical
04-13-2013, 12:08 AM
I would also prefer something similar to java like jerrets example. But just like dusty I am biased because I frequently use java.

fowlplay4
04-13-2013, 01:14 AM
Also curious how this would look like in GS3.

Weapon: Example


function onActionServerSide() {
if (params[0] == "hello") {
player.triggerclient("weapon", this.name, "goodbye");
}
}

//#CLIENTSIDE

function onCreated() {
triggerserver("gui", this.name, "hello");
}

function onActionClientSide() {
if (params[0] == "goodbye") {
player.chat = "*fistbump*";
}
}


Also if there's no 'with' (I still think there should be) how would this work out:

Weapon: GUIExample


//#CLIENTSIDE
function onCreated() {
new GuiWindowCtrl("Example") {
profile = GuiBlueButtonProfile;
x = y = width = height = 100;
new GuiButtonCtrl("ButtonExample") {
profile = GuiBlueButtonProfile;
x = y = width = height = 10;
}
new GuiButtonCtrl("ButtonExample2") {
profile = GuiBlueButtonProfile;
x = y = width = height = 30;
}
}
}

Admins
04-13-2013, 02:26 AM
function onActionServerSide(action:string):void {
if (action == "hello")
player.triggerclient("weapon", this.name, "goodbye");
}

//#CLIENTSIDE

function onCreated():void {
triggerserver("gui", this.name, "hello");
}

function onActionClientSide(action:string) {
if (action == "goodbye")
player.chat = "*fistbump*";
}



//#CLIENTSIDE
function onCreated():void {
var window:GuiWindowCtrl = new GuiWindowCtrl("Example");
window.profile = findobject("GuiBlueButtonProfile");
window.x = window.y = window.width = window.height = 100;

var button:GuiButtonCtrl = new GuiButtonCtrl("ButtonExample");
button.profile = findobject("GuiBlueButtonProfile");
button.x = button.y = button.width = button.height = 10;
window.addcontrol(button);

button = new GuiButtonCtrl("ButtonExample2");
button.profile = findobject("GuiBlueButtonProfile");
button.x = button.y = button.width = button.height = 30;
window.addcontrol(button);
}


The idea with tools is this:
We finish the scripted level editor by combining some of the best scripted/online editors, and convert it to GS3. This can be available online and we are also able to convert it to other scripting languages to import it into other development platforms. So we can also possibly offer new offline editors in the future.

So there are several additional advantages:
Graal script will not be a black box anymore, it will possible to bring it to faster scripting engines and platforms.
It will also be more close to other scripting languages, so you your knowledge will be more interesting for "real life" purposes, and more programmers from outside of Graal could be able to script in GS3. A lot of head-aches with variable lookups and such things are gone.

For script help normally /scripthelp is working quite fine, all new functionality is automatically added to /scripthelp or to the list you get by starting Graal with the "-listscriptfunctions" command-line option. The documentation on wiki.graal.net could be reorganized a little bit after we introduce GS3, although most global functions and GUI objects will be the same.

Gos_pira
04-13-2013, 02:57 AM
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.


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

I'd personally prefer:


public class Options : TGraalVar
{
int age;
string gender;
string city;
}

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

public float addNumbers(float a, float b)
{
return a + b;
}
}

cbk1994
04-13-2013, 03:30 AM
I like the changes you're considering quite a bit, but the syntax definitely feels clunky. Is there any reason you couldn't just do C-style variable types?

Also, is it necessary to keep "function"? Why not just use the return type:


// double return value
double mean(double a, double b) {
return (a + b) / 2;
}

// no return value
void log(string message) {
echo(message);
}

// returns something, "def" is a type that can hold anything
def anything() {
def[] array = [player, this, "a"];
return array[int(random(0, array.size()))];
}


This syntax would be more comfortable for a lot of amateur and professional programmers.

devilsknite1
04-13-2013, 03:52 AM
I do not want to reject change just for doing it, but Dusty's post (http://forums.graalonline.com/forums/showpost.php?p=1716094&postcount=10) captures my thoughts practically verbatim. I don't mind a new coding language, especially if there will be visible benefits to the game, but I would really like to see thorough documentation on this if other languages like Lua will not be used. It wouldn't be wise to just release it with poor instruction on how the code functions with proper syntax and examples, very much like how GS2 was released. You should be wanting to bring in more coders, not making them know GS2, then go learn other coding fundamentals from other languages (declaring variables, when to use void, etc.), then come back to Graal and implement GS2 and guess at the structure of GS3 using a different syntax knowledge from another language, then have no idea where to proceed since there is no trace of documentation anywhere.

For script help normally /scripthelp is working quite fine, all new functionality is automatically added to /scripthelp or to the list you get by starting Graal with the "-listscriptfunctions" command-line option.

Back to the not wanting to drive coders away part... That's all fine, except if a new developer wants to jump in on GS3, it's a bit of a jumbled mess with having to know GS2, then scanning and hoping that the proper syntax with examples are listed in /scripthelp. Most of the time it's just command(int, string, string) without any guidance as to what the integer and strings are supposed to be. If that's changed it will help a lot, otherwise you're going to have a lot of wiki editing to do.

My 2 cents, but I think I will stick to GS2 unless GS3 is properly documented. Though, I will say I do think heading in this direction is a good thing. The timing is just a bit off as well as the odd/clunky syntax styles. Just rip off of another language's syntax or use an already existing language fully capable of attracting new developers *cough*Lua*cough*.

Elk
04-13-2013, 03:56 AM
So technically you can connect to PC Graal via Browser with a proper Login?

Gos_pira
04-13-2013, 04:10 AM
So technically you can connect to PC Graal via Browser with a proper Login?

I think he means that porting scripts between script engines would be easier with these changes. Unless I just misunderstood what you meant.

Gamerkid7
04-13-2013, 05:05 AM
I agree with fowlplay4 and Gos_pira. I much prefer a Java-like syntax. The type declarations of the proposed GS3 just looks clunky and is needlessly different than common languages.

One feature that I would love to see is proper closures. Anonymous functions are great but don't maintain any context. This would make utility libraries extremely versatile. For example, a remove_if() method that takes a list and predicate function:


function void removeIDs(int rem_id) {
remove_if(this.idlist, function bool (int obj_id) {
if (obj_id == rem_id)
return true;
return false;
});
UpdateDiplay();
}


Then the code for remove_if only has to be maintained in one place and it would be a lot easier to figure out what a piece of code is doing from the functions being called.

DrakilorP2P
04-13-2013, 02:41 PM
I think this looks great. I don't mind the syntax since it's basically ActionScript.
I like the types idea and I like the dictionaries since that's the only thing I ever used the dynamic variable names for anyway.
Are you going to get rid of with() completely, or just with gui objects? How can we define particle effects without typing a lot?

My feature request is some way to share code between serverside and clientside without copy-pasting, which I don't think you can do right now. Maybe the join() changes will make that possible?

fowlplay4
04-13-2013, 05:03 PM
I still don't see why there's no 'with' statement in GS3. It helps clean up code and is very useful in GUI Building and other object work.

I.e. How I've used it in GS2:


temp.window = addWindow("Example");
with (temp.window) {
this.title = "Example Window";
with (addButton(this, "Button")) {

}
with (addButton(this, "Button2")) {

}
}

function addWindow(obj_id) {
temp.window = new GuiWindowCtrl(obj_id);
return temp.window;
}

function addButton(parent, obj_id) {
temp.button = new GuiButtonCtrl(obj_id);
parent.addcontrol(temp.button);
return temp.button;
}


but I would really like to see thorough documentation on this if other languages like Lua will not be used.

Even if he implemented Lua that isn't going to change the fact he still needs to document how the language works with and manipulates the Graal engine. A lot of GS2's current function usage isn't going to change that much in GS3 by the looks of it.

Loriel
04-13-2013, 06:01 PM
I'm a bit of a PL nerd now rather than invested into a gscript codebase so I'm all for type system change for change's sake here. :)

I'm curious about first-class functions/closures, and what kind of polymorphism you're going to support. Also will there be generic user-defined types or is that only for dictionaries? Are you going for an llvm backend eventually?

Edit: Function-local type inference?

Edit: Also what happens when a gs2 script triggers a gs3 scripts and sends along arguments with the wrong types?

Loriel
04-13-2013, 06:01 PM
Also **** y'all, varname:type is the best syntax

Pandar
04-13-2013, 07:34 PM
...too easy.

Hezzy002
04-13-2013, 09:41 PM
I think you should just use LuaJIT because it's fast, commonly used (More free developers for you!!). Whatever you make will be worse in every way.

Tim_Rocks
04-14-2013, 03:45 AM
http://i46.tinypic.com/2v1noep.jpg

Draenin
04-14-2013, 06:12 AM
Hello Graalians,

We have just started the work on a new scripting project and want your ideas and feedback about it. The idea is to create new Graal Script version (GS3) which will make scripts faster and more fit for bigger projects.
http://replygif.net/i/939

This first means some more work for scriptershttp://replygif.net/i/827

Scripts can run faster
http://replygif.net/i/726

More reliable because it will complain when a variable has not been declared or is used incorrectly.http://replygif.net/i/628

We can possibly convert the scripts to other languages (C++, Javascript etc.)http://replygif.net/i/193

so it can possibly run in a browser in the futurehttp://replygif.net/i/837

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.http://replygif.net/i/280

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 codehttp://replygif.net/i/218

just add a //#GS3 line to your script to use the new syntax and semantichttp://replygif.net/i/386

everything is still possible
http://replygif.net/i/149

Fulg0reSama
04-14-2013, 07:30 AM
-Images-

This was my reaction in a nutshell minus the browser statement reaction image.

Loriel
04-14-2013, 07:57 AM
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.

Crono
04-14-2013, 02:08 PM
I dunno how offline development would even work anymore

it won't ;[

scriptless
04-14-2013, 05:47 PM
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
04-14-2013, 06:00 PM
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
04-14-2013, 06:08 PM
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
04-14-2013, 09:53 PM
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
04-14-2013, 10:19 PM
It should support basic attributes (drawunderplayer, dontblock) and joining of a class

And >8bit pngs?

Loriel
04-15-2013, 11:06 AM
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
04-15-2013, 01:04 PM
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
04-15-2013, 06:22 PM
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
04-15-2013, 09:14 PM
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
04-15-2013, 10:54 PM
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
04-16-2013, 05:25 AM
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
04-16-2013, 02:55 PM
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
04-16-2013, 03:37 PM
open source so the community can help add features :)

l o l

Fidel Castro
04-16-2013, 04:13 PM
Slow down guys I'm still trying to learn Gs1 :(

Tim_Rocks
04-16-2013, 04:55 PM
@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
04-16-2013, 06:53 PM
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
04-17-2013, 03:37 AM
Good luck on the scripting program for Graal. Nice work on the details,
Really provides help to beginner Scripters.

Hiro
04-18-2013, 01:41 AM
can u pls mak everythn ezr?

all scripts shud jus be if and then

pls

brokk
04-18-2013, 03:41 PM
Well this just made my day :D

Jiroxys7
04-19-2013, 02:19 PM
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.


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:


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
04-19-2013, 11:46 PM
Also, is there any chance we would be able to have support for collapsing functions?

I fully support this.

iAxeis
04-21-2013, 11:50 PM
Can't wait to start scripting GS3!!! :D

Draenin
04-23-2013, 06:59 AM
Any chance we'll see more official documentation and tutorials posted as well for this stuff?

Matt
04-23-2013, 07:13 AM
Slow down guys I'm still trying to learn Gs1 :(

I'm in the same boat >_<

Tim_Rocks
04-24-2013, 10:42 PM
Slow down guys I'm still trying to learn Gs1 :(

Life is hard.

bloodpet
04-27-2013, 10:06 AM
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
04-27-2013, 07:26 PM
Gs2 is pointless, goku didn't even use it

Twinny
05-08-2013, 12:20 PM
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,

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


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
05-08-2013, 11:11 PM
Hi I haven't logged into the game for years but I disagree with your entire post.

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

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
05-08-2013, 11:12 PM
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
05-08-2013, 11:26 PM
http://deploytonenyures.blogspot.com.es/2012/04/reflecting-on-private-members.html also this is ridiculous, don't do that.

Twinny
05-09-2013, 04:49 AM
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
05-09-2013, 05:03 AM
Stefan,

Any chance you can provide background on your particular choices? :)

BlueMelon
05-09-2013, 11:48 AM
GS3, something new to look forward to in 'x' amount of years.

Twinny
05-22-2013, 10:33 AM
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
05-22-2013, 01:45 PM
I also had this problem when I initially tried it.

Twinny
05-22-2013, 01:54 PM
I also had this problem when I initially tried it.

And you resolved it....how?

Cubical
05-22-2013, 03:57 PM
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
05-22-2013, 08:54 PM
Twinny it will probably take a while for it to be enabled...

Cubical
05-22-2013, 09:01 PM
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

MysticalDragon
05-22-2013, 11:38 PM
Its currently enabled on Zone Iphone but not Delteria Iphone. The reason probably is because its half done? It works in NPC Weapons but not classes.

callimuc
05-23-2013, 12:51 AM
it is also disabled on Era iPhone

BlueMelon
05-23-2013, 01:47 AM
//#GS3

function onCreated() {
echo(getAddition(1,2));
}

function getAddition(a:number, b:number):number {
var result:number = a + b;
return result;
}


Works on era, but the class example does not.

Admins
05-23-2013, 01:52 AM
We have not enabled it yet on Graal servers. Part of the syntax has already been accepted (but ignored) for a few years.

Twinny
05-23-2013, 04:22 AM
//#GS3

function onCreated() {
echo(getAddition(1,2));
}

function getAddition(a:number, b:number):number {
var result:number = a + b;
return result;
}


Works on era, but the class example does not.

Guess it's very lenient..i figured it would have kicked up a shitstorm considering you didn't specify a return type for onCreated() (i.e. void)

So how do we go about getting it enabled?

Skyld
06-03-2013, 06:23 PM
For what it's worth the V8 NPC-Server prototype that we tested was a much better idea than this. :(

Twinny
06-05-2013, 11:39 AM
For what it's worth the V8 NPC-Server prototype that we tested was a much better idea than this. :(

You should have made it work then >: (

Gunderak
06-16-2013, 07:16 AM
Just tested this on Zone, why... It didn't give any error at all.

var list:int[];
list = {1, 2, "Test"};


Also curious, why this didn't work.

//#GS3
class Person extends TStaticVar{
var nickname:string;
}
function onCreated():void{
//Create an array of type Person
var list:Person[];
//Create some Person objects.
var me:Person = new Person();
me.nickname = "Nick";
var them:Person = new Person();
them.nickname = "Someone";
//Add them to the list
list.add(me);
list.add(them);
//Echo each Person element in the list
for(var someone:Person in list){
echo("Name: "@someone.nickname);
}
}

It does nothing, no errors either.

Also will there be constructors?

Sorry for the spam, but will we be able to extend a TSocket :D?

Admins
06-16-2013, 01:54 PM
Yes arrays seem to be bugged, we will work on it.

Twinny
06-16-2013, 04:58 PM
My desires:

Constructors (being able to overload would also be awesome but perhaps taking it too far)

class Test {
var myname : string;
var myage : int;

function Test(myname: string) {
this.myname = myname;
}
//Because overloading is fun
function Test(myname : string, myage : number) {
this.myname = myname;
this.myage = myage;
}

function echoValues() : void {
printf("My name is %s and my age is %i", this.myname, (this.myage? this.myage : "Unknown"));
}
}

function onCreated() : void {
var TestObj : Test = new Test("Twinny", 25);
TestObj.echoValues();


I know getters/setters will be on the way but this just seems more natural.

I added that printf as it will fail since it's not being referenced in that class(see: extern). For this, perhaps being able to simply prepend global. to global functions would be better. On a similar note, i've not tried but i hope we could use something like super.whatever to access base class items we inherited from :o

Gunderak
06-16-2013, 11:23 PM
My desires:

Constructors (being able to overload would also be awesome but perhaps taking it too far)

class Test {
var myname : string;
var myage : int;

function Test(myname: string) {
this.myname = myname;
}
//Because overloading is fun
function Test(myname : string, myage : number) {
this.myname = myname;
this.myage = myage;
}

function echoValues() : void {
printf("My name is %s and my age is %i", this.myname, (this.myage? this.myage : "Unknown"));
}
}

function onCreated() : void {
var TestObj : Test = new Test("Twinny", 25);
TestObj.echoValues();


I know getters/setters will be on the way but this just seems more natural.

I added that printf as it will fail since it's not being referenced in that class(see: extern). For this, perhaps being able to simply prepend global. to global functions would be better. On a similar note, i've not tried but i hope we could use something like super.whatever to access base class items we inherited from :o
This.

Gunderak
06-17-2013, 07:02 AM
I still hate the whole object:type thing. Would love it if it was more like Java and C#, object something;

Julien
06-17-2013, 01:15 PM
I still hate the whole object:type thing. Would love it if it was more like Java and C#, object something;

Hello,

By essence, GScript is a scripting language. GScript is more close to JavaScript-like languages, rather than Java or C#.

This type syntax was chose among other language syntaxes, because it is commonly-used to annotate types in ECMAScript-based languages.

For example:


// ActionScript
function foo(a:int):int {...}

// TypeScript
function foo(a: number): number {...}

// UnityScript
function foo(a : int) : int {...}

// Haxe
function foo(a : Int) : Int {...}


So, when converting from GS2 syntax to GS3 syntax, you just have to add type annotations to the original syntax.


//#GS2
function foo(a) {...}

//#GS3
function foo(a : int) : int {...}


With a Java or C# syntax, this will require more semantic changes to the language, like removing the "function" keyword.
Also, you lose the ability to easily import scripts from similar languages (ActionScript, JavaScript, UnityScript, TypeScript...).


// Java or C#.
int foo(int a) {...}

Twinny
06-18-2013, 01:58 AM
Encountered some issues with inheritance,


//#GS3

class BaseClass {
var baseclassvar : number = 3;

function overwriteMe() : string {
return "You shouldn't see me without accessing baseclass";
}
}

class InheritanceTest extends BaseClass {
function overwriteMe() : string {
return "You should see me!";
}
}

function onCreated() : void {
//var BaseClassTest : BaseClass = new BaseClass();
//echo(BaseClassTest.baseclassvar);

var TestObj : InheritanceTest = new InheritanceTest();
echo(TestObj.baseclassvar);
echo(TestObj.overwriteMe());
}


would spit out,


Weapon/GUI-script Twinny/GS3-Inheritance added/updated by Twinny
Script: Couldn't create object: type BaseClass is not existing in function onCreated in script of Twinny/GS3-Inheritance
Script: Function TestObj.overwriteMe not found in function onCreated in script of Twinny/GS3-Inheritance
0


Next, uncommenting the lines resulted in,


Weapon/GUI-script Twinny/GS3-Inheritance added/updated by Twinny
Script: Couldn't create object: type BaseClass is not existing in function onCreated in script of Twinny/GS3-Inheritance
Script: Function TestObj.overwriteMe not found in function onCreated in script of Twinny/GS3-Inheritance
0
bytecode:1305: TypeError: Cannot read property 'name' of null
typeName = stub.name.extends.name;
^
Will keep running the old NPC script until server restart.



I was going to try and do a var BaseTestObj : BaseClass = TestObj; but figured it wouldn't get me too far :)

Gunderak
06-18-2013, 06:06 AM
The class should extend something , try extends TStaticVar.
It will probably make it singleton but eh as long as you only use it once.
But also GS1-3 not being a proper language, it doesn't act like proper languages.
Oddly playing around, if you create the object, the class can extend it o.0 not the actual class though?

//#GS3
class Foot extends TStaticVar{
var id:int;
}
class Toe extends Foot{
var id:int;
}
function onCreated():void{
var Foot:Foot = new Foot();
var toe : Toe = new Toe();
toe.id = 1;
echo(toe.id);
}

Twinny
06-18-2013, 10:12 AM
The class should extend something , try extends TStaticVar.
It will probably make it singleton but eh as long as you only use it once.
But also GS1-3 not being a proper language, it doesn't act like proper languages.
Oddly playing around, if you create the object, the class can extend it o.0 not the actual class though?

//#GS3
class Foot extends TStaticVar{
var id:int;
}
class Toe extends Foot{
var id:int;
}
function onCreated():void{
var Foot:Foot = new Foot();
var toe : Toe = new Toe();
toe.id = 1;
echo(toe.id);
}


And yet,


class Animal { ... }
class Cat extends Animal { ... }
class Dog extends Animal { ... }
var cat : Cat = new Cat();
var dog : Dog = new Dog();
var cat_as_animal : Animal = cat as Animal; // OK as the Cat type is a member of the Animal type.
var cat_as_cat : Cat = cat_as_animal as Cat; // OK as the Cat type is a member of the Animal type.
var cat_as_dog : Dog = cat as Dog; // KO as the Cat type is not a member of the Dog type.
var cat_as_animal_as_dog : Dog = cat_as_animal as Dog; // null as the Cat as Animal type is not a member of the Dog type.



Taken from: http://wiki.graal.net/index.php/Creation/Dev/GScript3#as_operator

It did resolve my query regarding referencing the base class..need to use 'as' operator :)

Gunderak
06-18-2013, 11:50 AM
Ahh nice :)

Gos_pira
06-18-2013, 12:05 PM
What's the point of extending if you still need to use the "as" expression? Seems rather retarded to me.

It would make sense if you used it in a foreach on an array of objects of different type.

Like:

"foreach (djur as Animal in this.Animals)"

while this.Animals contains Dog, Cat, Parrot etc.

I might just be misunderstanding something here, if so, disregard my post.

Gunderak
06-18-2013, 02:06 PM
Foreach, I did for(various item:class_type in array)

Julien
06-19-2013, 03:03 PM
Also curious, why this didn't work.

//#GS3
class Person extends TStaticVar{
var nickname:string;
}
function onCreated():void{
//Create an array of type Person
var list:Person[];
//Create some Person objects.
var me:Person = new Person();
me.nickname = "Nick";
var them:Person = new Person();
them.nickname = "Someone";
//Add them to the list
list.add(me);
list.add(them);
//Echo each Person element in the list
for(var someone:Person in list){
echo("Name: "@someone.nickname);
}
}

It does nothing, no errors either.


In the above code, the "list" variable was not initialized. The GS3 compiler currently fails to compile uninitialized variable declarations.

As a workaround, the following code should work:

//#GS3
class Person extends TStaticVar{
var nickname:string;
}
function onCreated():void{
//Create an array of type Person
var list:Person[] = {}; // Do not forget to initialize.
//Create some Person objects.
var me:Person = new Person();
me.nickname = "Nick";
var them:Person = new Person();
them.nickname = "Someone";
//Add them to the list
list.add(me);
list.add(them);
//Echo each Person element in the list
for(var someone:Person in list){
echo("Name: "@someone.nickname);
}
}

Fulg0reSama
06-20-2013, 12:07 AM
!

I am ****ing onto you Julien, we know you are one of them!
Also welcome to the community for what time you will be staying.

Crono
06-20-2013, 01:41 AM
I am ****ing onto you Julien, we know you are one of them!
Also welcome to the community for what time you will be staying.

****ing onto you?

BlueMelon
06-20-2013, 03:14 AM
He was onto me the other day, but then I lagged out

Tim_Rocks
06-21-2013, 02:00 AM
Are you guys hitting on each other o_O

Cubical
06-21-2013, 04:38 PM
So we have a few advantages:

Helps to write code which is more reliable and readable
The structure of objects can be analyzed for automatic script documentation
Dependencies can be analyzed so you can know which scripts access an object or function
We can make scripts running much faster (not right now but in the future
GraalScript3 can be converted to other languages and platforms, we are preparing something interesting for this to show in a few weeks


@Stefan While you're actively reviewing this thread can you elaborate on this and what you're preparing that's interesting?

Twinny
06-24-2013, 01:16 AM
Hey Julien/Stefan,

Any update on my class extending problem? http://forums.graalonline.com/forums/showpost.php?p=1719319&postcount=90

Also, will overloading functions be supported?

Julien
06-24-2013, 08:06 AM
Hello,

GS3 is currently emulating classes using only GS2 features.
While the GS3 syntax already support constructors, getters / setters, inheritance, classes can only be used as containers as for now.

You can only define simple classes with members initialization but functions do not work yet.

Example:

class Animal extends TStaticVar {
var name : string;
var canBreathe : boolean = true;
}

class Dog extends Animal {
var canBark : boolean = true;
}

function onCreated() : void {
var dog : Dog = new Dog();
dog.name = "Woof";
echo(dog.canBark); // 1 (true)
echo(dog.canBreathe); // 1 (true)
}

Angel_Light
07-14-2013, 02:04 PM
- We can possibly convert the scripts to other languages (C++, Javascript etc.) so it can possibly run in a browser in the future

I realize that this deals with Graal's actual source code rather graalscript, but does this means it might possible to port graal to other platforms or handhelds, ie. 3DS and Vita?

Admins
07-15-2013, 06:09 PM
We also plan to convert the engine to GS3 sometime :) We more look into targeting Javascript and C# though

Gunderak
07-17-2013, 07:34 AM
Why C#?

Julien
07-17-2013, 03:54 PM
There are several cross-platform game libraries that are based on the Mono / .NET Framework (C#):

Unity 3D (also supports JavaScript-like language)
Xamarin
MonoGame
...


Conversion from GS3 to C# would allow the Graal engine / tools / scripts to be compatible with these libraries, and possibly deploy on new platforms. :cool:

fowlplay4
07-17-2013, 05:48 PM
Conversion from GS3 to C# would allow the Graal engine / tools / scripts to be compatible with these libraries, and possibly deploy on new platforms. :cool:

and this benefits Graal and it's developers how?

callimuc
07-17-2013, 06:38 PM
and this benefits Graal and it's developers how?

more stuff to deal with, particles and FB as example

xAndrewx
07-22-2013, 07:28 PM
and this benefits Graal and it's developers how?

it will bring more players to zodiac;)

GodlyAmbitions
07-24-2013, 04:21 AM
i hope they really go for C# instead of gs3

Twinny
07-24-2013, 05:20 AM
C# will also be useful for me (as it's my language of choice atm :))

Jakov_the_Jakovasaur
02-18-2014, 06:30 PM
hello!

lets just hypothesize for one moment that i were to put my scripting abilities towards developing a playerworld which uses gs3, what alternative platforms could i then expect the playerworld to be made available on, and what time frame could i expect this to be within?

alternatively, if i were to develop a playerworld using gs2 instead, is the current pc platform even going to be supported in future?

thank you!

Tim_Rocks
02-18-2014, 08:46 PM
hello!

lets just hypothesize for one moment that i were to put my scripting abilities towards developing a playerworld which uses gs3, what alternative platforms could i then expect the playerworld to be made available on, and what time frame could i expect this to be within?

alternatively, if i were to develop a playerworld using gs2 instead, is the current pc platform even going to be supported in future?

thank you!

When Timmah from South Park can walk.

Cubical
09-03-2014, 04:14 PM
sup bros, gs4.5 comin next week

eidt: i promise

scriptless
09-04-2014, 01:53 AM
Is there any updates on this available? I really like the idea of GS3.

alskdjfhg
09-04-2014, 03:21 AM
Stefan is likely working on something in his spare time out of boredom. Maybe he'll give us back UDP as well :D

scriptless
09-04-2014, 03:28 AM
Stefan is likely working on something in his spare time out of boredom. Maybe he'll give us back UDP as well :D

Stefan isn't with Graal anymore. My question is to unixmad, wether he plans to pursue this feature with future programers that he may or may not be hiring.

Ceasar
09-07-2014, 12:34 PM
he's gaining money without having to fix anything so i doubt it, not to forget the facebook /iphone server is completely shitty compared to the pc version for whatever reason..

MysticalDragon
09-12-2014, 08:37 AM
he's gaining money without having to fix anything so i doubt it, not to forget the facebook /iphone server is completely shitty compared to the pc version for whatever reason..

Its better then iphone version? Ios graal is very smooth it just handles a bigger player base so it seems more sluggish. The facebook client however is trash.

Jakov_the_Jakovasaur
09-12-2014, 11:19 AM
Its better then iphone version? Ios graal is very smooth it just handles a bigger player base so it seems more sluggish. The facebook client however is trash.

hello!

he is probably not talking about the smoothness the platforms run with, but more likely the diluted standard of content for the associated servers (not that its easy with that many players but the point still applies)

fight4life
02-10-2016, 04:40 AM
as much as i hate to necro old threads i was just wondering if any globals are maintaining this project still?

fowlplay4
02-10-2016, 02:26 PM
no gs3 is lame

Elk
02-10-2016, 08:09 PM
#gs4

fight4life
02-11-2016, 05:56 AM
thats a shame the syntax is a nice change

Anero
02-11-2016, 12:59 PM
#gs4

This!

Crono
02-28-2016, 07:40 AM
as much as i hate to necro old threads i was just wondering if any globals are maintaining this project still?

no gs3 is lame

aw shoot :(

Inari
04-12-2016, 02:02 PM
Just let us use Lua please

PlanetOscar
04-13-2016, 07:20 AM
Lua is shet

Inari
04-13-2016, 07:31 AM
Lua is shet

It's pretty nice. Miles better than gs1/2/3 at least

Cubes
04-13-2016, 12:04 PM
i think all types should be int

Tim_Rocks
04-15-2016, 08:25 PM
i think all types should be int

this.this = this;