Initialize modules?

[Executor]

module
   //someVars
   static boolexpr enumFunc
   static method someEnumFunc takes nothing returns false
      call KillUnit(GetFilterUnit())
      return false 
   endmethod
   static method someMethod takes nothing returns nothing
      call EnumUnitsInRange(GROUP,...,.enumFunc)
   endmethod

   moduleInitializer takes nothing returns nothing // < ===
      set .enumFunc = Condition(.someEnumFunc)
   endmoduleInitializer
endmodule

Does something like this exist? Or do I have to break the module up in [lib,module,global,lib init]?

 

[Troll-Brain]

Since Jasshelper 0.9.Z.1, private onInit methods inside a module will be executed on init once per struct implementing it. Multiple onInit methods from multiple modules can coexist with the struct's onInit method as well.

So you can use a static method called onInit in your module.
But care, a module initializer is currently done before ANY OTHER initializer, regardless any library requires (silly idea from a silly request imho).
And it's not likely to be changed since Vexorian doesn't support vJass anymore.

Which means :

library A initializer init requires B

private module m
  private static method onInit takes nothing returns nothing
    call BJDebugMsg("library A : module initializer")
  endmethod
endmodule

private struct s
   implement m
endstruct

private function init takes nothing returns nothing
   call BJDebugMsg("library A : library initializer")
endfunction

endlibrary

library B initializer init

private function init takes nothing returns nothing
   call BJDebugMsg("library B : library initializer")
endfunction

endlibrary

Will show :
"library A : module initializer"
"library B : library initializer"
"library A : library initializer"

But hopefully if you also use a module with an initializer inside the library B it will show :

"library B : module initializer"
"library A : module initializer"
"library B : library initializer"
"library A : library initializer"

So if you really want an initializer for module you may want to don't use anymore library initializer, but instead an empty struct which implement a module initializer, or eventually just implement the module initializer inside some of your already created struct, but i don't recommend that for the code maintenance and read of it.

 

[Jesus4Lyf]

But care, a module initializer is currently done before ANY OTHER initializer, regardless any library requires (silly idea from a silly request imho).

It's beyond silly. It's absurd.
In all my libraries I now have to implement their initialisation as a module.

You should not be able to initialise before a requirement has initialised, but unfortunately someone depended on this ridiculous behaviour and Vex listened. Now stuff would break if it were to change, of course.

Using a struct extending an array is a useful way of doing this without side effects.

 

[Executor]

Hm, okay, thanks. Fortunately atm my module doesn't depend on other initializers.

 

[Troll-Brain]

Here is the keyword "at the moment", but what about later ?
That's better to forget library initializers now, in order to prevent odd eventual future bugs.

 

[Jesus4Lyf]

TimerUtils suffers from this in the most grand ways.

 

[Troll-Brain]

TimerUtils suffers from this in the most grand ways.

Timers utils fails in the current version anyway, even if you forget the initializer thing.

 

[Jesus4Lyf]

Timers utils fails in the current version anyway, even if you forget the initializer thing.

Really? In what way?

 

[Troll-Brain]

At very least the blue version, didn't checked the others.

"Blue" TimerUtils DEFAULT
(When USE_HASH_TABLE is set to true)
Uses a hashtable object from wc3 patch 1.24b+ or later. These things are very fast though not as fast as just an array lookup. So it is the 'slowest'...

... But it is the safest! There are no limits to the number of timers you can have.

False.

Once you have reached the limit QUANTITY, you're fucked.
So then i would just use a faster version if i need to care about the number of timers ...

 

[Bribe]

You need that many timers? For what?

Personally, I think any good recycler should not be allocating a huge stack of live timers, rather, if the timers reach a certain point, they should be flagged to be destroyed when done. What if, at the beginning of the game, you need 100, but for the rest of the game you only need two. The other 98 are wasting RAM. That's why I implement my own recycling systems instead of use others'.

 

[Jesus4Lyf]

>There are no limits to the number of timers you can have.
Actually, I noticed that that is false as well. There is no point to the blue version of timer utils in its current state.

>You need that many timers? For what?
Irrelevant to it being wrong.

>The other 98 are wasting RAM.
No one cares about those little shreds of RAM. If it doesn't take 100 MB, it doesn't make a difference.

 

[Bribe]

My crappy little computer cares

 

[Jesus4Lyf]

My crappy little computer cares

You need to seriously re-evaluate the performance impact of having idle timers in memory. I had a 5 year old laptop which cared far more about the computing power required to destroy/create timers than about the minuscule amount of RAM required to stash them.

That is to say, destroy/create timers and monitor when they should be destroyed/created... as you suggested.

If you have any proof that having 100 timers in RAM doing nothing impacts the performance of your map (whatsoever), I'm most interested...

 

[kingkingyyk3]

Tested on 9 years old pentium 4 1.6GHz + 1GB SD RAM + sucky Intel Graphic. Same fps with 0 timers and 500 timers.

 

[Bribe]

Hmm... no wonder TimerUtils is so popular, if people can get away with that.

 

[kingkingyyk3]

If you really want to use TimerUtils, I recommend TimerUtils Purple. It has 4096 timers limitation, far more than Blue and it is faster than Blue too.

 

[Bribe]

I do not see myself importing it in the forseeable future, but thank you.

 

[Jesus4Lyf]

Tested on 9 years old pentium 4 1.6GHz + 1GB SD RAM + sucky Intel Graphic. Same fps with 0 timers and 500 timers.

Of course, this is a crappy test.

I recommend TimerUtils Purple. It has 4096 timers limitation, far more than Blue and it is faster than Blue too.

Of course, this is an unsubstantiated claim (without presenting any evidence).

Hmm... no wonder TimerUtils is so popular, if people can get away with that.

This is a mediocre conclusion. You can get away with that with hashtable attachment and any form of recycling.

The point being made is irrelevant to TU - it's that RAM consumption by recycling timers does not matter.

 

[kingkingyyk3]

Of course, this is an unsubstantiated claim (without presenting any evidence).
Tested by using Stopwatch native.

 

[Jesus4Lyf]

Of course, this is an unsubstantiated claim (without presenting any evidence).
Tested by using Stopwatch native.

Y'know.
Link to one of those.
But with something this sensitive, it needs to be run through Optimizer as well. Testing this stuff is crap.