Function hooking

[cbk1994]

I've brought this up a few times before, but this would be insanely useful and I think it deserves its own thread.

Function overriding would allow you to essentially overwrite default commands.

For example, if you wanted to create your own tileset layout without a custom movement system (syntax up for debate):

PHP Code:

// weapon -Tiles
//#CLIENTSIDE
function onCreated() {
  tileType = function(x, y) {
    temp.tile = this.level.tiles[x, y];

    if (tile in {1, 2, 3}) {
      return 0;
    } else if (tile in {4, 5, 6}) {
      return 1;
    } // etc
  };

  onWall = function(x, y) {
    return tileType(x, y) == 7; // just an example
  };
} 


Extending object prototypes would also be extremely useful. I think the best way to do it would be to have a class with the same name as the object type. This class would then be 'joined' to all of those objects.

A simple example:

PHP Code:

// class TGraalVar
function capitalize() {
  return this.value.substring(0, 1).upper() @ this.value.substring(1);
} 


Otherwise, you could go the JavaScript route and edit object prototypes

PHP Code:

TGraalVar.prototype.capitalize = function() {
  return this.value.substring(0, 1).upper() @ this.value.substring(1);
}; 


You could then do this:

PHP Code:

temp.str = "hello world!";
echo(str.capitalize()); // echoes "Hello world!" 


Ideally all of this would work both serverside and clientside.

I have no idea how hard this would be to implement, but if it's not too difficult, it would be a huge improvement to GScript.

[WhiteDragon]

This is normally called "function overriding".

And, it is "already possible" in GS2 in some technical sense. If you have access to a variable containing a function pointer (i.e., it was defined as an anonymous function), then you can override it.

The problem is that all the existing functions are not defined as anonymous functions.


Personally, I'd like to see the libraries be written in terms of higher order functions: e.g., onwall would accept the tiletype function as a parameter. This way you would rarely need to override things. This would be more work to do though.



As for your second point, since GS2 does have some sort of OO support, I do agree that prototypes would be a good addition.


Edit: Also, it's fairly critical that we get closure support soon (meaning that you can access variables outside the anonymous function from inside it) natively, rather than using my ugly hack for it.

[Devil_Lord2]

I think this is a good idea, working with type1 and noticing a lot of the functions didn't work I wanted to try and fix it.. never did but I figured out a better type1 template. >.>

But I also would have loved to override the movement system, which I could be confused about the exact message / statement, but from what I think I understand this is about overriding built in functions?

Anyway, I hate how moving north east and south east the player faces right; moving north west the player faces left. Why does the player face down in south west?

Again, assuming I got what WhiteDragon was saying about the libraries .. unless he didn't mean for us to see them.. I would love to see and edit the basic functions too. I was hoping I could find the tile system and see if I could edit that.. then looking at an online tile editor I was hoping I could at least organize that to be together in looks but still hold their functions ... like 0x1A0 could be next to 0x1D1 but I didn't understand the Online Tile Editor at all lol.. it didn't have any tile arrays..

Sorry if I got both comments all mixed up :x

[WhiteDragon]

Originally Posted by Devil_Lord2

Again, assuming I got what WhiteDragon was saying about the libraries .. unless he didn't mean for us to see them.. I would love to see and edit the basic functions too.

I did not mean that default functions should be overwriteable.


I meant something like onwall accepting the tiletype function as a parameter:

PHP Code:

temp.onwall = function (temp.tileType, temp.blockingTypes, temp.x, temp.y) {
  return (temp.tileType(temp.x, temp.y) in temp.blockingTypes);
} 


And likewise, other functions would accept an onwall function for their needs, which could be the one defined above, or another one.

Anyways, this would be a monumental amount of work and is just a pipedream.



Snapping back to reality, it is important for overriding, prototypes, and closures to be implemented.

I'd like to see some attention be given to these 3 things, because it would let the developers 'fix' a lot of problems with the default stuff without involving Stefan or rewriting everything from scratch.

[Devil_Lord2]

Ooh I see.. I can't say I fully understand, but I know on my pet system I have a problem making move serverside and it kinda just stops the moving script.. I suppose it is better than walking on a wall though.. I suppose I could find a way around this somehow but I am not an experienced NAT lol..

Anyway, my fault. :]

[fowlplay4]

Want this. Alternative syntax suggestion:

PHP Code:

//#CLIENTSIDE
function TGraalVar.capitalize() {
  return this.value.substring(0, 1).upper() @ this.value.substring(1);
} 


[0PiX0]

Originally Posted by cbk1994

For example, if you wanted to create your own tileset layout without a custom movement system (syntax up for debate):

If the hard-coded movement system were to use a scripted function, it would be the equivalent of using a 0.05s timeout script to check wall collisions. With a more complex custom tileset design, the custom tileType function could be slightly cpu intensive, unless you used some hackish method to streamline the function. This is just something I thought up on the spot, but I guess something like this would remove the need for conditional statements in the tileType function...

PHP Code:

//#CLIENTSIDE
function onCreated() {
  temp.watertiles    = {1,2,3};
  temp.blockingtiles = {4,5,6};

  for (temp.i: watertiles)
    (@"tiletype_"@i) = 11;

  for (temp.i: blockingtiles)
    (@"tiletype_"@i) = 22;

  tileType = function(x, y) {
    return (@"tiletype_"@this.level.tiles[x, y]);
  };

  onWall = function(x, y) { 
    return tileType(x, y) == 22;
  }; 
} 


Function overriding would be useful in some cases I guess.
I would also really like to see the prototype idea implemented.