Make a library required either of the two system

[Flux]

There are two TimerUtils, one is TimerUtils by Vexorian and the other is TimerUtilsEx by Magtheridon96. Now, how do I make the library required to use one of them but not both?

As of now this is what I do

optional TimerUtils
optional TimerUtilsEx
...
...
static if LIBRARY_TimerUtils then
else if LIBRARY_TimerUtilsEx then
else
     //Throw Error
    .
endif

But I think there is a better formal way to do this.

EDIT: It will automatically create error when I used NewTimerEx(someInt) so that's good and no need for the intentional error. However, I'm still interested on how to implement this correcty.

 

[Bribe]

Just pick one. The trend of using 2 different requirements is getting silly.

Also, Anitarf recently (2 or 3 years ago) updated TimerUtils to include NewTimerEx thanks to Magtheridon.

 

[Flux]

Just pick one. The trend of using 2 different requirements is getting silly.

Also, Anitarf recently (2 or 3 years ago) updated TimerUtils to include NewTimerEx thanks to Magtheridon.

It is not because of the NewTimerEx, it is because of the ReleaseTimer(return integer).

 

[Bribe]

Makes more sense to just use the longer approach since you have the same performance either way, and are cross-compatible without wasting your time writing static if's that take longer to write.

 

[Flux]

Makes more sense to just use the longer approach since you have the same performance either way, and are cross-compatible without wasting your time writing static if's that take longer to write.

Ok then, thanks Bribe!

EDIT: So to be clear, I will use GetTimerData and ReleaseTimer, but the thing is, they (TimerUtils and TimerUtilsEx) are not compatible. To be more specific, TimerUtilsEx is not backward compatible with TimerUtils meaning when I put requires TimerUtils and I used TimerUtilsEx, it will error.

 

[Bribe]

Just add this to the bottom of the script:

library_once TimerUtils requires TimerUtilsEx
endlibrary

 

[Zwiebelchen]

Don't use timer utils at all. It just adds useless weight.

Most systems are better off using just a single exclusive global timer running all their stuff.

 

[Bribe]

TimerUtils' recycling is unimportant, but unifying the data extraction from that timer is important. Preloading timers allows meticulous coders to actually use red TimerUtils, as well.

 

[Flux]

Don't use timer utils at all. It just adds useless weight.

Most systems are better off using just a single exclusive global timer running all their stuff.

If I do that, then it won't be MUI.

 

[Bribe]

You CAN use a global timer running every 0.03125 seconds, but that is so much less efficient!

 

[Zwiebelchen]

If I do that, then it won't be MUI.

Do you even know what you are talking about?

You CAN use a global timer running every 0.03125 seconds, but that is so much less efficient!

Depends on what he is trying to do. We have no idea about that.
In most cases, efficiency with timers doesn't matter, since what you actually do on the timer callback far outweights the performance drain of having the timer in most cases.

Seriously, people need to stop being obsessed about efficiency. Especially when they don't know what they are doing.

set t = NewTimer() --> set t = CreateTimer()
call SetTimerData(t, x) --> call SaveInteger(hash, GetHandleId(t), 0, x)
x = GetTimerData(t) --> x = LoadInteger(hash, GetHandleId(t), 0)

call ReleaseTimer(t) -->
     call FlushChildHashtable(hash, GetHandleId(t))
     call DestroyTimer(t)

You seriously want to tell me that all the additional overhead of TimerUtils will beat these simple natives?
And even if it does: do you really think it matters?

 

[Flux]

Do you even know what you are talking about

Be more clear next time, I didn't know you meant using 0.03125 periodic global timer. So I should use CTL?

 

[Wietlol]

If I do that, then it won't be MUI.

I think that this is not true.
MUI-ness can be achieved by many ways and TimerUtils' main goal was not improving MUI ability.

I agree that global timers do not need TimerUtils...
First of all, they wont be recycled.
Secondly, they wont need a custom data because they are global timers, you can simply make a global variable and store your data in there.

Running multiple 0.03(125)s timers is in my opinion good enough for systems and map makers.
I think performance doesnt really care whatever you choose.

Also, just pick one out of the two systems.
I would pick TimerUtils because most people use it.

 

[Flux]

^seconds late haha.
I used TimerUtils(Ex) for the attaching data, the recycling was just a bonus.

 

[Zwiebelchen]

Be more clear next time, I didn't know you meant using 0.03125 periodic global timer. So I should use CTL?

Okay, look, if you want to use a timer system for convenience, that's totally fine.
But don't use one just because you think it is mandatory or because someone told you that "this is what the big boys do".

You are still learning. I get that. And that's totally cool.
However, you shouldn't base your decisions one things you haven't fully understood yet. With insufficient information, you will make bad decisions. I recommend you read up on what MUI actually means first before going with the suggestion of whoever told you that using a timer system will make your spells automaticly MUI. Because it will not.
MUI is a concept, not a checkbox you can click just by importing a number of systems. It is a concept you need to understand completely if you want to get better at coding. No band-aid will allow you to shortcut that process.

When you are doing something, make sure you understand what you are doing. Because if you don't, you just ask for trouble further down the road.

There's plenty of tutorials here on Hive that explain what MUI is and how to make a spell or system multi-unit instancable. Give those a try, then come back and ask your question again. But chances are you will by then have realized that this question never actually was a question in the first place and that you have already solved it yourself.

 

[Flux]

I will just be direct here, at first I thought you meant using a single non-periodic timer for all timer related stuffs example:
+caster1 cast spell with 5 sec delay, global timer runs.
+after 4 sec, caster2 cast the same spell reseting the global timer to 5 sec -> non-MUI.

 

[Zwiebelchen]

I will just be direct here, at first I thought you meant using a single non-periodic timer for all timer related stuffs example:
+caster1 cast spell with 5 sec delay, global timer runs.
+after 4 sec, caster2 cast the same spell reseting the global timer to 5 sec -> non-MUI.

That would be dumb, why would I suggest that?

Besides, you can actually use one-shot timers for spells just fine. You just create and destroy them dynamically. For systems, however, that is seldom required, as you can just run off a single periodic timer and stacks.

 

[Flux]

That would be dumb, why would I suggest that?

Besides, you can actually use one-shot timers for spells just fine. You just create and destroy them dynamically. For systems, however, that is seldom required, as you can just run off a single periodic timer and stacks.

I don't know, when I read

Don't use timer utils at all. It just adds useless weight.

Most systems are better off using just a single exclusive global timer running all their stuff.

that was the first thing that came into my mind. It seems I underestimated you thinking you would give a dumb solution but you got your revenge right after suggesting to me to read MUI tutorials lol
...
...
Without TimerUtils, the trigger cannot determine which timer instance has expired, that is where NewTimerEx becomes convenient, no need to SaveInteger, etc..

 

[Wietlol]

What he means is that you index the game-time of when something would end.
Using a Linked List, you can index stuff and place something in between very easily and you should be fine to do it like that.

Anyway, when your caster1 starts the effect, the global timer runs.
When caster2 (4 seconds later) starts the effect, the global timer is still running so you store the desired endtime (current game-time + 5 seconds) in the list.
When the global timer ends (from caster1), you start it again for caster2 with (desired endtime - current game-time = ) 4 seconds.

It is a more advanced version of how to use timers and recycle them within the same system.
The point is that the advantage of using it like this isnt really big.
All you gain is less running timers in trade of a linked list.

 

[Flux]

^That was just an example and not my actual problem.

I figured out earlier he meant global perioic timer running every 1/32 sec.

 

[Wietlol]

I used your example to show that you can have things MUI with only one timer...
Anyway, to actually answer the original question, afaik this is impossible.
You can try to make a default way to do it outside of any timer system but just making them optional is the best you can do.

 

[Bribe]

I made a priority queue for using one timer per struct, even with dynamic timeouts. It could be modified to work with boolexprs instead of code so as to cover the whole map, but seriously. Look at that code. Just look at it. www.hiveworkshop.com/forums/graveyard-418/system-timer-2-a-191118/

 

[Zwiebelchen]

Without TimerUtils, the trigger cannot determine which timer instance has expired,

GetExpiredTimer() is a jass native, not a TimerUtils function.

that is where NewTimerEx becomes convenient, no need to SaveInteger, etc..

NewTimerEx() literally only saves you only one line of code. If you are too lazy to write a single SaveInteger(), then yes, I guess you should use TimerUtils.

 

[Flux]

GetExpiredTimer() is a jass native, not a TimerUtils function.


NewTimerEx() literally only saves you only one line of code. If you are too lazy to write a single SaveInteger(), then yes, I guess you should use TimerUtils.

'timer instance' not the timer itself. I meant directly getting the struct associated with the timer :
local thistype this = ReleaseTimer(GetExpiredTimer())
instead of...
local timer t=GetExpiredTimer()
local thistype this = LoadInteger(...)
...
call PauseTimer(t)
call DestroyTimer(t)

Well it is convenient for me, no need to store it to variable :TimerStart(NewTimerEx(this), .....)
instead of
local timer t = CreateTimer()
...
SaveInteger(...)
TimerStart(t,.....)

Everybody knows GetExpiedTimer() is a jass native.