Graal Forums
Page 1 of 2 1 2
Show 40 post(s) from this thread on one page

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   Future Improvements (https://forums.graalonline.com/forums/forumdisplay.php?f=10)
-   -   addEventListener (https://forums.graalonline.com/forums/showthread.php?t=79598)

Robin 05-02-2008 03:53 PM
addEventListener
 
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 05-02-2008 04:41 PM
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 05-02-2008 08:22 PM
So ECMAScript standards + gs2 = :(

cbk1994 05-02-2008 10:48 PM
Like Skyld said, it can be replicated easily. However, I guess it would be nice to have.

Robin 05-02-2008 11:10 PM
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 05-02-2008 11:53 PM
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
} 

cbk1994 05-03-2008 12:13 AM
I agree with Inverness, catchevent would work fine, just needs to be "fixed".

Inverness 05-03-2008 12:15 AM
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 05-03-2008 12:16 AM
Quote:
Originally Posted by Inverness (Post 1388728)
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 05-03-2008 12:18 AM
Quote:
Originally Posted by cbkbud (Post 1388729)
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 05-03-2008 12:20 AM
Quote:
Originally Posted by Inverness (Post 1388730)
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 05-03-2008 12:25 AM
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.

Robin 05-03-2008 01:36 AM
Quote:
Originally Posted by Inverness (Post 1388725)
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 05-03-2008 01:49 AM
Quote:
Originally Posted by Robin (Post 1388739)
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 05-03-2008 02:35 AM
Quote:
Originally Posted by Inverness (Post 1388732)
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 05-03-2008 03:32 AM
Quote:
Originally Posted by cbkbud (Post 1388750)
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 05-03-2008 03:45 AM
Quote:
Originally Posted by Inverness (Post 1388769)
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.
Quote:
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 05-03-2008 03:53 AM
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 05-03-2008 08:25 AM
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.

Robin 05-03-2008 01:23 PM
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 05-03-2008 01:41 PM
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 05-03-2008 01:43 PM
!!! <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.)

cbk1994 05-03-2008 02:58 PM
Quote:
Originally Posted by zokemon (Post 1388798)
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 05-03-2008 10:29 PM
Quote:
Originally Posted by cbkbud (Post 1388824)
Agreed, also if the "on" was removed, then it would break a ton of scripts.
Quote:
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.
Quote:
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.
Quote:
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?
Quote:
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.
Quote:
Originally Posted by Robin (Post 1388774)
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.

Admins 05-03-2008 11:20 PM
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 05-03-2008 11:36 PM
PASSING OBJECTS AND FUNCTIONS AND VARIABLES BY REFERENCE WOULD BE GREATLY APPRECIATED PLEASEEEEEE.
</beg>

Inverness 05-03-2008 11:58 PM
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 05-08-2008 02:10 PM
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 05-08-2008 09:01 PM
Quote:
Originally Posted by Robin (Post 1389616)
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 05-08-2008 09:21 PM
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!

cbk1994 05-08-2008 10:09 PM
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 :)

Inverness 05-09-2008 12:12 AM
Quote:
Originally Posted by cbkbud
He's saying to fix what we have, not add something totally new.
Exactly
Quote:
Originally Posted by Robin (Post 1389647)
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.
Quote:
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.

Robin 05-09-2008 03:04 AM
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 05-09-2008 03:11 AM
Quote:
Originally Posted by Robin (Post 1389761)
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 05-09-2008 05:37 AM
Quote:
Originally Posted by Robin (Post 1389761)
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 05-09-2008 03:04 PM
Quote:
Originally Posted by Inverness (Post 1389787)
Look you're really starting to piss me off
Oh but I do love it so :P
Quote:
Originally Posted by Inverness (Post 1389787)
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 05-10-2008 12:57 AM
Quote:
Originally Posted by Robin (Post 1389816)
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.
Quote:
Originally Posted by Robin (Post 1389816)
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 05-10-2008 02:19 AM
Quote:
Originally Posted by Inverness (Post 1389924)
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?

Quote:
Originally Posted by Inverness (Post 1389924)
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?


Quote:
Originally Posted by Inverness (Post 1389924)
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.

Quote:
Originally Posted by Inverness (Post 1389924)
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.

cbk1994 05-10-2008 03:56 AM
Quote:
Originally Posted by Robin (Post 1389944)
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.
Then stop making a fuss about it.
Quote:
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);
} 
Yes, that could fit perfectly into your atan->arctan junk.
Quote:
I'd like to keep general c-like based script standards in order to encourage more players to script.
GS2 is easy enough to learn. Personally, I see addEventListener as more confusing. Plus, it's not like people go around and say "HMM I COULD LEARN GS2 BUT IT DOESNT COMPLY WITH MY ECMA**** :cry:"
Quote:
You say I do not understand consistency, when I am talking about standards. Standards are about keeping things consistent.
We have consistency. Consistency of GS2. There is no reason we need consistency for any other languages.

Actually, I will start a crusade to make GS2 compliant with my BASICStandards :rolleyes:

This way, everyone coming from BASIC would be able to script GS2 :)

Robin 05-10-2008 10:13 PM
Quote:
Originally Posted by cbkbud (Post 1389970)
Then stop making a fuss about it.
I already did.

Quote:
Originally Posted by cbkbud (Post 1389970)
Yes, that could fit perfectly into your atan->arctan junk.
arctan is not the standard name for that function, try C, C#, Java, Actionscript etc. Judging by the fact that the following is perfectly legal GScript2, Stefan has already started to implement some Actionscript:
PHP Code:
function init(obj:Object, x:Number, y:Number) {
} 
Quote:
Originally Posted by cbkbud (Post 1389970)
GS2 is easy enough to learn. Personally, I see addEventListener as more confusing. Plus, it's not like people go around and say "HMM I COULD LEARN GS2 BUT IT DOESNT COMPLY WITH MY ECMA**** :cry:"
Is it really? Then why do I continue to see some god awful scripting from otherwise talented people? If it's so easy, why don't you contribute some scripts? I haven't seen anything in the Code Gallery from you since I got here.

Plus, as I have already said, I can add my own "addEventListener" if catchevent was fixed, it does not matter to me what the function is named as long as it works

Quote:
Originally Posted by cbkbud (Post 1389970)
We have consistency. Consistency of GS2. There is no reason we need consistency for any other languages.
Obviously not considering the legal bit of Actionscript / GS2 above.

Quote:
Originally Posted by cbkbud (Post 1389970)
Actually, I will start a crusade to make GS2 compliant with my BASICStandards :rolleyes:

This way, everyone coming from BASIC would be able to script GS2 :)
BASIC has no standards, it was a Microsoft invention. ECMA is not a script on it's own. It's a set of standards, like ISO or RFC.

I was starting no crusade sir, I saw the inklings of GS2 becoming something greater than it already is and decided to try and help, and yet was bashed :)


All times are GMT +2. The time now is 06:24 AM.
Page 1 of 2 1 2
Show 40 post(s) from this thread on one page

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.