Author Topic: Question About Hooking Module Events  (Read 386 times)

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Question About Hooking Module Events
« on: August 14, 2012, 03:53:04 am »


               Currently I have a lot of module event scripts running as hook scripts from the main module events using ExecuteScript("script_name", GetModule()) to call the hook script. As far as overhead is concerned would it be better for load times if I integrated the scripts into one event? Or does it not matter? 
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Question About Hooking Module Events
« Reply #1 on: August 14, 2012, 05:10:03 am »


               I suspect the additional overhead of the ExecuteScript call is negligible.

Two minor points things:
(1) I think it is more efficient to call GetModule() once and assign it to an object variable, than to call it many times. Its minor, but you were asking about overhead...
(2) I believe ExecuteScript pauses all other execution until it is complete. Or at least pauses the current script execution until it is complete.

And two more that are more interesting:
(3) Depending on the particular scripts you are running from the main hook, you can likely find common ground between them, and increase both efficiency and effectiveness by rewriting them all to work together, share data etc... in a single script.
(4) Parceling out code into different executable chunks protects you from having too many "labels" (meaning two many identified variables, constants, function names etc....) all in one script which is not a small consideration if you are not using Virusman's and Skywing's hacks to the toolset and compiler.
               
               

               
            

Legacy_Lightfoot8

  • Hero Member
  • *****
  • Posts: 4797
  • Karma: +0/-0
Question About Hooking Module Events
« Reply #2 on: August 14, 2012, 06:57:41 am »


               

henesua wrote...

I suspect the additional overhead of the ExecuteScript call is negligible.

There is more overhead then one would originaly think.  But I also do not think it is enough to worry too much about.

Two minor points things:
(1) I think it is more efficient to call GetModule() once and assign it to an object variable, than to call it many times. Its minor, but you were asking about overhead...

I myself do not know which one would be faster,  It is nip-tuck on this one.  Since it sounds like the script is already running on the module OBJECT_SELF would be the fastest. 

  
(2) I believe ExecuteScript pauses all other execution until it is complete. Or at least pauses the current script execution until it is complete.


i would not really call this a pause,  Anymore then I would concider calling a function as pausing the script.  After all that is really all a script is, a special function that has a little more setup code to it.   Right,  
void main() {}
is really nothing more then a header for a void returning function called main. 
 
ExecuteScript ( sName, oObject) ;
Can hypothetically be looked at as running the main function in another NameSpace.  imagine 'void main' as having a prameter of OBJECT_SELF.  ie.  void main ( object OBJECT_SELF) {  //Code block}  

you could then  hypothetically look at:
  
ExecuteScript ( "MyScript" , GetModule()) ;

being the same thing as:
 
MyScript.main(GetModule()); 

Where MyScript is the NameSpace that the Function 'main' is in and passing the module for OBJECT_SELF. 
   

And two more that are more interesting:
(3) Depending on the particular scripts you are running from the main hook, you can likely find common ground between them, and increase both efficiency and effectiveness by rewriting them all to work together, share data etc... in a single script.
(4) Parceling out code into different executable chunks protects you from having too many "labels" (meaning two many identified variables, constants, function names etc....) all in one script which is not a small consideration if you are not using Virusman's and Skywing's hacks to the toolset and compiler.


Both  points are excellent.

...

@Pstemarie: If your hooked scripts need to change the object they are running on. I would just leave them as scripts.   If they are called by more then one script, I would still most likely leave them as scripts. 
ahh, I really see no problem with leaving them as hooked scripts.  

However if you did want to add all of the code into a single script, it does not really take any complex  rewriting/ merging of the code.   All you need to do is give the main function a new name,  Then either Paste the function in the original script or just #include it.   You can then just use a standard function call instead of the ExecuteScript.
               
               

               


                     Modifié par Lightfoot8, 14 août 2012 - 06:04 .
                     
                  


            

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Question About Hooking Module Events
« Reply #3 on: August 14, 2012, 09:46:57 am »


               

Lightfoot8 wrote...

@Pstemarie: If your hooked scripts need to change the object they are running on. I would just leave them as scripts.   If they are called by more then one script, I would still most likely leave them as scripts. 
ahh, I really see no problem with leaving them as hooked scripts.  

However if you did want to add all of the code into a single script, it does not really take any complex  rewriting/ merging of the code.   All you need to do is give the main function a new name,  Then either Paste the function in the original script or just #include it.   You can then just use a standard function call instead of the ExecuteScript.


I like the idea of merging them as custom functions - didn't think of that. Basically what I'm currently looking at is this scenario for a lot of the Module Event scripts...

1. They all execute with the module as the caller (i.e. OBJECT_SELF). I don't know why I used GetModule() in the ExcecuteScript call - just sloppiness on my part (which I'll fix).

2. Several scripts call ExecuteScript just to run three or four lines of code to execute the parameters for one of the subsystems imported into the module (such as Killer Death System, Traporrium, etc.). Some scripts do this more than once, depending upon how many subsystems are hooked into it.

3. The naming convention for the module events is a disaster - especially the hook parts, making it hard to find things at times if something needs tweaking.

I guess with those points in mind it probably would be best to merge everything into one clean set of code...