addEventListener

[Robin]

Like in javascript, subscribe to events using code.

PHP Code:

  function onCreated() {
    this.addEventListener("this.onWeaponfired", function() {
      player.chat = "Hi!";
    });
    showGUI();
  }
  function showGUI() {
    new GuiBitmapBorderCtrl("this.radiogui") {
      profile = GuiBitmapBorderProfile;
      canmove = false;
      canresize = false;
      height = 50;
      width = 385;
      x = screenwidth - width - 20;
      y = -50;
      visible = true;
      new GuiButtonCtrl("PlayButton") {
        x = 25;
        y = 5;
        alpha = 1;
        width = 50;
        height = 20;
        text = "Play";
      }
      new GuiButtonCtrl("MuteButton") {
        x = 25;
        y = 25;
        alpha = 1;
        width = 50;
        height = 20;
        text = "Mute";
      }
    }
    this.addEventListener("MuteButton.onMouseDown", function(MouseEvent) {
      echo(@MouseEvent.mousescreenx);
    });
  } 


etc. What say thee Stefan?

[Skyld]

Use function prototyping:

PHP Code:

MuteButton.onMouseDown = function ()
{
  //
}; 


PHP Code:

function onCreated()
{
  this.onWeaponFired = function ()
  {
    //
  }
}; 


Or even standard function definition:

PHP Code:

function MuteButton.onMouseDown()
{
  //
} 


[Robin]

So ECMAScript standards + gs2 =

[cbk1994]

Like Skyld said, it can be replicated easily. However, I guess it would be nice to have.

[Robin]

It's just that ECMAScript is a standard definition and It would be easier for new scripters to start if they didn't have to comb the wiki for information :P

[Inverness]

I've been scripting for quite awhile and I don't know what the *bleep* ECMAScript is. I doubt anyone knew to coding would either.

I even dislike the syntax of the example you provided. I think catchevent() works just fine and should be expanded to work with scripted events with a function throwevent() or so.

Script A:

PHP Code:

function doSomething() {
  //stuff
  throwevent(this.name, "DidSomething", params...);
} 


Script B:

PHP Code:

function onCreated() {
  this.catchevent("System", "DidSomething", "SystemDidSomething");
}
function onSystemDidSomething(params...) {
  //stuff
} 


[Robin]

Originally Posted by Inverness

I've been scripting for quite awhile and I don't know what the *bleep* ECMAScript is. I doubt anyone knew to coding would either.

ECMAScript is the standard that:

• JavaScript
• JScript (IE)
• JScript.NET
• ActionScript

Are based on.

Are you trying to say you've never come across any of these technologies?

That anyone knew to coding has not either?

Also @ Skyld:

function prototyping doesn't seem to work with gui events, but the rest of your examples do. Strange.

[Inverness]

Originally Posted by Robin

Are you trying to say you've never come across any of these technologies?

Heard of them, and thats it, never used them. However, that doesn't actually matter (IMO) because we could do what you're suggesting by adding a throwevent() function to work with the existing catchevent() without changing the format that its used in.

[cbk1994]

I agree with Inverness, catchevent would work fine, just needs to be "fixed".

[Inverness]

I dislike how catchevent() requires the "on" part to be specified in the event name. Events already start with "on" by default so such a thing should be assumed I believe.

[cbk1994]

Originally Posted by Inverness

I dislike how catchevent() requires the "on" part to be specified in the event name. Events already start with "on" by default so such a thing should be assumed I believe.

But if it was expanded to dynamic events, then why should we be forced to start them with on?

[Inverness]

Originally Posted by cbkbud

But if it was expanded to dynamic events, then why should we be forced to start them with on?

I'm just pointing out how at the moment you would do something like:
this.catchevent("GraalControl", "onResize", "onGraalControlResize");
instead of:
this.catchevent("GraalControl", "Resize", "GraalControlResize");

Things like scheduleevent() and trigger() always prefix the event name with "on" to show that its an event so catchevent() should reflect that Graal event function names always start with "on"

I believe that should be fixed by Stefan and he should give people a warning ahead of time so they can fix their scripts.

[cbk1994]

Originally Posted by Inverness

I'm just pointing out how at the moment you would do something like:
this.catchevent("GraalControl", "onResize", "onGraalControlResize");
instead of:
this.catchevent("GraalControl", "Resize", "GraalControlResize");

I know what you're saying, but if it was expanded to dynamic, we could just have something that watches for another thing, but the other function also does stuff. For example,

PHP Code:

function onCreated()
{
  this.catchevent( ... );
}
function messWithStuff()
{
  do something lol();
} 


While messWithStuff() is still functional, we don't need to change it's name.

[Inverness]

Blah, all events should start with "on" in all cases. Anything handling event names shouldn't need the "on" in all cases.

It sounds to me like you're being lazy. Standards are something that should be practiced in coding.

[cbk1994]

Originally Posted by Inverness

Blah, all events should start with "on" in all cases. Anything handling event names shouldn't need the "on" in all cases.

It sounds to me like you're being lazy. Standards are something that should be practiced in coding.

That's just personal preference. I think it's silly to have something like onBlowUpCar()

[Inverness]

Originally Posted by cbkbud

That's just personal preference. I think it's silly to have something like onBlowUpCar()

Its irritating me to have to explain a simple concept to you.

If you have a function blowup() that blows up the npc then have an event onBlownUp() that is thrown at the end of the function... what is wrong with that?

Its a simple concept to have all events prefixed with "on" to separate them from other normal functions because events are responding to something else and you're not normally supposed to be calling them directly. Is that so difficult to understand?

[cbk1994]

Originally Posted by Inverness

Its irritating me to have to explain a simple concept to you.

It irritates me when people have this perspective. I didn't ask for you to explain it, you chose to.

If you have a function blowup() that blows up the npc then have an event onBlownUp() that is thrown at the end of the function... what is wrong with that?

Its a simple concept to have all events prefixed with "on" to separate them from other normal functions because events are responding to something else and you're not normally supposed to be calling them directly. Is that so difficult to understand?

Okay, I see what you mean.

[Robin]

wouldn't you rather have:

PHP Code:

function onCreated() {
  someGui.addEventListener(GuiEvent.CLOSE, function() {
    event = new createEvent("nsDOMMyEvent");
    event.initEvent("nsDOMMyEvent");
    thiso.dispatchEvent(event);
  });
  this.addEventListener("nsDOMMyEvent", function() {
    player.chat = ":P";
  });
} 


I would.

[zokemon]

I usually catchevent my gui catchs with something like guiDoStuff(); (a gui header rather then an on header) as I see them as a little different. That's just my opinion though but I don't want to see that functionality removed.

[cbk1994]

Originally Posted by zokemon

I usually catchevent my gui catchs with something like guiDoStuff(); (a gui header rather then an on header) as I see them as a little different. That's just my opinion though but I don't want to see that functionality removed.

Agreed, also if the "on" was removed, then it would break a ton of scripts.

[Inverness]

Originally Posted by cbkbud

Agreed, also if the "on" was removed, then it would break a ton of scripts.

Originally Posted by Stefan

You also don't need to specify the "on" in the event name, it's actually stripping that from the event name in case you are providing it.

Originally Posted by Stefan

The only problem with catchevent() is that you cannot catch events for objects which don't have a name.

In my throwevent() example the first parameter was the object name which could be this.name or anything else. If such a thing is abusable it could be made so if you use throwevent() then the object name has to be the name of the object calling it or a string thats not an object name already.

Originally Posted by Stefan

The function for invoking/throwing events is trigger(), but it is currently restricted to avoid security problems

You should make the object and function that triggered/scheduled the event the first entry in the new callstack, just so you know what started the thread. Then the RC could just check to make sure itself or Graal started the thread and not another script.

Would that suffice?

Originally Posted by Stefan

cannot catch events for objects which don't have a name.

Make it so catchevent can take either a string object name or an object variable. Then you can do your internal stuff to keep track of the object by its pointer instead of by its name.

Originally Posted by Robin

wouldn't you rather have:

PHP Code:

function onCreated() {
  someGui.addEventListener(GuiEvent.CLOSE, function() {
    event = new createEvent("nsDOMMyEvent");
    event.initEvent("nsDOMMyEvent");
    thiso.dispatchEvent(event);
  });
  this.addEventListener("nsDOMMyEvent", function() {
    player.chat = ":P";
  });
} 


I would.

That looks ugly and confusing because you're defining functions on the fly. Lets try to keep things consistent here in GScript?

PHP Code:

//ScriptA
function onCreated() {
  this.catchevent(someGui, "CloseQuery", "SomeGuiCloseQuery");
}
function onSomeGuiCloseQuery() {
  // fancy fade-out effect
  this.throwevent(this.name, "DidGuiClose", params...);
  // throwevent() only does something if the event its throwing
  //   is being caught. Does not trigger()
}
//ScriptB
function onCreated() {
  this.catchevent(ScriptA, "DidGuiClose", "ScriptADidGuiClose");
  // should use same name if you don't give a new one
}
function onScriptADidGuiClose(params...) {
  //stuff
} 


Now that is much more like how its done already.

[Robin]

It would probably be possible to add a sort of addEventListener by using classes and mapping every event manually x-x

Would be fun though.

Plus if Gscript2 were ECMAScript COMPLIANT then I wouldn't have to port this JSON parser from C x-x

[Admins]

catchevent() is like addEventListener() except that it also allows to catch events of objects which don't exist yet. You also don't need to specify the "on" in the event name, it's actually stripping that from the event name in case you are providing it.

The only problem with catchevent() is that you cannot catch events for objects which don't have a name. It could be possible to add addEventListener() for compatibility and for closing that hole.

The function for invoking/throwing events is trigger(), but it is currently restricted to avoid security problems (e.g. a scripter from a server could open the remote control for you and click on some controls and type text and then ban someone, just as example).

[Robin]

!!! <3<3<3<3<3<3<3<3

Love.

(Translation: Yes, that'd be a remarkably good idea, and it would allow for many other things.)

[Admins]

In the latest internal Graal version all trigger()ed events are also sent to the "event listeners" when an object is triggering itself. I can check if it's possible to support the object as parameter for catchevent().

[Robin]

PASSING OBJECTS AND FUNCTIONS AND VARIABLES BY REFERENCE WOULD BE GREATLY APPRECIATED PLEASEEEEEE.
</beg>

[Inverness]

Objects and functions already are refs, and you can pass arrays by ref using link().

PHP Code:

function onCreated() {
  temp.array = {"lol", "pancake"};
  thefunc(temp.array.link());
}
function thefunc(array) {
  array[1] @= "lol";
} 


Though I think its silly that it only works for arrays and not strings or numbers.

[Robin]

Something like this would be greatly appriciated for both Clientside and Serverside:

PHP Code:

function onCreated() {
  this.addEventListener("Timeout",function() {
    sendtonc("2");
  });
  setTimer(1);
}
function onTimeout() {
  sendtonc("1");
}

// Would recieve:
// 1
// 2
// Simultaneously 


[Inverness]

Originally Posted by Robin

Something like this would be greatly appriciated for both Clientside and Serverside:

PHP Code:

function onCreated() {
  this.addEventListener("Timeout",function() {
    sendtonc("2");
  });
  setTimer(1);
}
function onTimeout() {
  sendtonc("1");
}

// Would recieve:
// 1
// 2
// Simultaneously 


So do you have a good reason why we need to add another way to do catchevent()? Cause it seems like my consistency argument is going right over your head.

The ECMAScript thing isn't a good enough reason to redo how we catch events either.

[Robin]

Because you currently can't do that with catch event.

Or can you? Are you able to hook the current onTimeout of a script and simultaneously have both an onTimeout and another event called of your choosing without putting anything in the onTimeout?

I've tried it, and it doesn't work, at least not serverside.

So you can be negative about this, or you can feel positive that you're getting your own way, albeit via a different function, rather than your seemingly beloved catchevent, which I cannot seem to get working on ANY script event OTHER than GUI events!

[Inverness]

Originally Posted by cbkbud

He's saying to fix what we have, not add something totally new.

Exactly

Originally Posted by Robin

Because you currently can't do that with catch event.

Well duh, and you can't do addeventlistener() either. Its simpler for Stefan to edit catchevent() to do what I'm saying than it is to add what you're suggesting and confuse people with having two ways of doing the same thing.

Originally Posted by cbkbud

ECMAScript Standards can wait in line. We already have a way to do this, it just needs to be fixed. No need to reinvent the wheel

I'm glad someone understands.

[cbk1994]

He's saying to fix what we have, not add something totally new.

ECMAScript Standards can wait in line. We already have a way to do this, it just needs to be fixed. No need to reinvent the wheel

[Robin]

What you don't seem to understand is that addEventListener IS the wheel Stefan reinvented by making catchEvent.

Just a... slightly square... triangular wheel that doesn't work quite right.

[cbk1994]

Originally Posted by Robin

What you don't seem to understand is that addEventListener IS the wheel Stefan reinvented by making catchEvent.

Just a... slightly square... triangular wheel that doesn't work quite right.

GS2 doesn't have to comply to any of your ECMAScript Standards.

There was no catchevent in GS1, he created catchevent in GS2. Therefore, he reinvented no wheel in Graal's scripting.

[Inverness]

Originally Posted by Robin

What you don't seem to understand is that addEventListener IS the wheel Stefan reinvented by making catchEvent.

Just a... slightly square... triangular wheel that doesn't work quite right.

Look you're really starting to piss me off (relatively) with your apparent inability to think about anything beyond what you want.

You don't seem to realize that we've been using catchevent() for years and nobody wants to have to replace all instances of it with some new function just to adhere to some standard that they probably don't care about.

[Robin]

Originally Posted by Inverness

Look you're really starting to piss me off

Oh but I do love it so :P

Originally Posted by Inverness

You don't seem to realize that we've been using catchevent() for years and nobody wants to have to replace all instances of it with some new function just to adhere to some standard that they probably don't care about.

I never said anything about replacing catchevent, that would be bad for backwards compatibility.

catchevent seems to only work for GUI / HTTPRequest objects and that seems like a very small scope.

It should be modified to work with any event, custom events included.

The beauty of addEventListener is that it's an already defined function in C-like interperated scripts and you wouldn't lose backwards compatibility by adding a new function.

[Inverness]

Originally Posted by Robin

Oh but I do love it so :P

The relatively in the parentheses means that I don't get "pissed off" as much as I get irritated.

Originally Posted by Robin

catchevent seems to only work for GUI / HTTPRequest objects and that seems like a very small scope.

It was suggested multiple times that Stefan make catchevent() work with everything and not just the engine events like it does currently.

You still don't seem to understand that we do not need addeventlistener() because rather than adding a new way to do the same thing Stefan can simply modify catchevent()

On a different subject: I don't think you have the ability to be PWA if you can't understand simple things such as consistency.

[Robin]

Originally Posted by Inverness

The relatively in the parentheses means that I don't get "pissed off" as much as I get irritated.

Pissed off does not mean irritated anymore?

Originally Posted by Inverness

It was suggested multiple times that Stefan make catchevent() work with everything and not just the engine events like it does currently.

But it has not been done, perhaps to not break backwards compatibility? Perhaps he would like to wait until the next client revision?

Originally Posted by Inverness

You still don't seem to understand that we do not need addeventlistener() because rather than adding a new way to do the same thing Stefan can simply modify catchevent()

I understand, and as the name suggests, it's a very generic function. addEventListener does not even have to be added, although it would be good.

If catchevent worked the way you and myself would like it to, I could make this:

PHP Code:

function addEventListener(obj,event,func) {
  obj.catchEvent(event,func);
} 


That way, your event would work fine, and I could keep standards. As I said in my other thread, I'd like to keep general c-like based script standards in order to encourage more players to script.

Originally Posted by Inverness

On a different subject: I don't think you have the ability to be PWA if you can't understand simple things such as consistency.

Because, my wanting to be PWA has ANYTHING to do with this thread? You're just picking bones my old friend.

You say I do not understand consistency, when I am talking about standards. Standards are about keeping things consistent.

As I have also said, if you have a problem, feel free to IM me or to email me. You will not be ignored.