Static variables
 

Do they exist?

TStaticVar :|

Not exactly what I meant. I meant like the way the static keyword works in C functions. As you probably know, so that variables retain their values even after the function's end, but can't be accessed script-wide, just in that function.

For example:

outputs this:

C function scope static variables are pretty ****ty, at least ask for C++ static members.

Store them in a server. or a DBNPC if it's that important I guess.

Sounds like there'd need to be some kind of class implementation (which I'd love)? I'm not sure. I know little about C++ and C for that matter. What I was asking for seemed best represented by what they have in C.

Just use global or object variables.

Edit: I also have to say that I think GScript should be scrapped and replaced with Lua. GScript is too inconsistent.

You could have a DB NPC called Static Variables or something..

Then in other scripts just reference it like so:

I wasn't aware that DBNPCs were guaranteed to be accessible on clientside at all times.

I would suggest having a system weapon create a TStaticVar.

Good idea, Inverness. I've got an idea brewing which is based of what you've said.

I love you <3

Horrible idea.

Says the person who only knows GScript.

Please stop those off-topic nonsense comments.

Static function-variables are quite interesintg in C/C++ although at the end they are just global variables. So we don't necessary require them, although it's true that it's sometimes good to have some real secured placed where you know that other scripts cannot interfere (another reason for the idea of private variables).

WILL NOT HAPPEN.

Now that we've cleared that up, please move on with your life.

Quite wrong.

Also, very well said Skyld! :)

Way to latch on to Skyld's post to defend your substance-less ****posting

Well all the more reason to have private variables. I don't think actual static function variables would work to well with the way GScript is right now.

And another thought, there isn't really a way to list global variables, so it would be possible to hide some value as a global variable assuming noone else can see the script. Though I think doing that would be a bit funky.
Don't raise your voice at me young man.
Loriel put it better than I could have.

Actually you can display global variables now with /memstats full.

I didn't want discussion about lua or so because it's more philosophical, better to open a new thread for speaking about what stuff graal script should borrow from other languages or so.

Isn't LUA harder?

Note: I don't know anything about LUA, but since it's used in WoW it should be a little harder than a language for a 2D game oO
And isn't LUA only used to do visual stuff?

Ah crap, someone tell me what LUA is all about :f

no it is actually easier

Lua is a language specifically designed to be easy to pick up and to be embedded into applications. It has nothing to do with "visual stuff", but since the entire point of a programming language is to do new stuff with it, it does not have to. Blizzard did not write their 3d engine in lua, they just embedded the lua runtime into their (C++) application and defined a huge number of additional functions that lua code can use to interact with the user interface. That has obviously no effect on the language itself.

At the danger of risking Stefan's wrath: I think the lua language and compilation model is easier to understand than gs2. There are fewer concepts you need to grasp in order to reason about the behaviour of a lua program because there is plain less magic going on, and there is a small number of language features that are extremely powerful (thinking of lexical closures for all kinds of crazy functional programming things, and composing arbitrary data structures from simple tables). Of course, this might as well be a downside to the whole thing, since the parts of gs2 that are more complicated are mostly that way because Graal's game world is directly integrated with the gs2 "object space"

The thing that sold me on lua is that there is a single reference manual that explains absolutely everything that is in the language, and is relatively easy to read and comprehend.

Oh dear, there are so many more global variables than I thought. There is also alot of uknown_object. Stefan could you change it so unknown_objet is simply not added to global variables?

By the way, I've also wondered if global variables and object variables are stored using hash tables?

Lua is much much simplier than languages like Graal Script, Flash etc., and is easier to optimize. However there are few things that make it not good for our use: the syntax is very different to C/C++/Java/JavaScript/Flash/Graal Script, and of course most Graal stuff is not existing or at least not in the extend we are using them (join/leave classes, sleep/waitfor, variable scope, dynamic allocation of variables, automatic event binding etc. etc.). So it's quite interesting, but not a drop-in replacement. If we ever switch to another language or system then only for speed (e.g. a just-in-time compiler which exist for all platforms, including iphone, llvm might be the light at the end of the tunnel) or for better compatibility with code from other platforms, including Flash and Java programs.

All variables are stored in hash tables yes.
"unknown_object"s are mainly GUI objects or so which don't have a name. They still exist in the global variable space though.

I think a GScript's problem is consistency. It has alot of quirks like I dislike:

• Dynamic variables are case-sensitive, yet static variables aren't.
• Object-oriented design, yet lack of actual user-defined classes.
• A whole range of global variables and functions, yet an inability to create your own.

I think we need a GS3 which is a more refined an object-oriented version of GS2, with full support for classes and stuff like that. For example, providing a script for a weapon should involve subclassing the weapon class and overriding the event functions in the weapon class.

Can we just pretend it actually does this already?

Agreed.

Graal uses a more dynamic class system instead of a compiler-based class system, those things cannot be mixed easily. Graal demands objects to be dynamic, you can create and modify the objects at any time.

On the other side you have languages like C++ and Java which are basicly providing a class system which restricts the programming to a certain set of class functionality which are only useful at compile-time. When the program is compiled and running then the "class" system is just a chunk of memory and a list of functions attached to each object. These are quite different concepts.

See the idea of "static" variables: it is a restriction, you are basicly using global variables but when compiling the script the compiler ensures that you can only access it from a certain piece of code. The variable is however still accessible from the other code, with some tricks.

Perhaps you should use Python as a reference for how you would want to improve GScript, it has a dynamic class system where classes (types) can be created dynamically and objects can optionally have dynamic variables using a hash table. The same type objects are used for static (built-in) types as with dynamic types.

I'm a person who dislikes reinventing the wheel, which is why I always make suggestions about using Python, because I think while it make take alot of effort (binding using Boost.Python, applying security changes to Python source, converting scripts) to convert in the short term, it would be better for the longevity of Graal if you want Graal to continue for years to come.

I think the Wesnoth guys came to the conclusion that they could not safely run arbitrary python scripts in their game client because it could not be made secure.

Hm, I don't think it would be too difficult. First thing you would do to head off most problems is limit module imports to only a select amount of modules. Then implement a loop limit based on the module's __maxlooplimit__. Other stuff escapes me at the moment...

Clearly the solution is to separate scripts into headers and implementation. Then we can finally have typesafe NPCs, eleminating a whole class of possible errors. And when you make a change to your system class you have to recompile the whole server.