The Hell?

[NeuroToxin]

I love this website <3 .

Now then, emjlr3 has a good point. Its a personal preference. If they want to eliminate Key Timers 2, well thats their problem. I feel like this is like the Old USA, judging everybody. Just judging systems.

 

[Solmyr]

I think Neuro would be better equipped with a timer queue, but let's not open THAT can of worms.

You took the words right out of my mouth, kind Sir. I was just gonna suggest the very same thing.

But as per the topic (if you could call this a 'topic') - I agree with Bribe's reasoning... to a certain degree. There has to be some kind of a standard, at least when such systems are concerned. And Sevion already said everything that needed to be said.

EDIT: Yes, I know that nobody is asking for the opinion of a user with 23 posts, but I couldn't resist.

 

[Bribe]

Just because a system works does not mean that it is acceptable.

function return1 takes nothing returns integer
    return 1
endfunction
function return1copy takes nothing returns integer
    return 2 / 2
endfunction
function return1copy2 takes nothing returns integer
    return R2I(SquareRoot(1))
endfunction

The above illustrates a process to return 1. The first example is the most simply, and below it get more complex.

The idea is to not have so many copies of how to return 1, the idea is to take advantage of the best way to return 1 and ignore the rest.

Speed is not the factor in this topic even, it's just based in simplicity. If the equation can be simplified, simplify it. No reason to return the square root of 1 if you know the return value would be 1.

In such, KeyTimers2 splits the operations into a boolexpr "And" with two sub-boolexprs, destroys them instead of recycling them (see GroupUtils for how to recycle them), stores data into a timer's timeout, retrieves it via multiplication by 800 and hitching a ride on the link-list train, evaluating the relevant trigger and requiring users to call KT_GetData exactly once.

Timer32 is a simple linked-list loop and a method call, TimerUtils is a simple timer with a hashtable/GetHandleId lookup. Completely disregarding speed here and just looking into the simplicity.

So, just like "return1copy" and "return1copy2" are no longer needed, KeyTimers2 is no longer needed, and is cropped out of the acceptable standard.

 

[Nestharus]

I was going to say that the reason THW seems to be so nasty at the moment is that it's undergoing changes. These changes have been going on (slowly but surely) back when azlier was still moderating (although I could say that I was pushing him ;P). This was happening before Bribe, Bribe is just taking a lot of time to review a lot of resources (he's like the most active moderator I've seen in a long time o-o).

The qquality bar for THW resources has been increasing. As the bar increases, resources that don't meet it end up getting rejected or (quite possibly in the case of spells section) deprecated. This doesn't mean that the resources are super bad, it just means that they don't meet the level of quality expected of resources at THW anymore. Some of them don't even work ; ).

If you make a spell or system like you did 1 year ago, chances are it's not going to make it at THW anymore. If you look at some of the newer stuff (not only mine), people are really starting to up the quality. People who primarily did GUI are moving to vjass. Look at the last spells and systems contest and you'll see that the quality of resources has been increasing.

Bribe and I only stick out because we are pretty much super active ;P.


Now, I do like the point Sevion raised very much. I was actually creating a map recently and with heavily optimized systems, it still lagged. I had to get really creative with some of these systems and with the map to reduce the lag (haven't gotten it down to 0 yet). These systems by themselves wouldn't lag under extreme stress testing, but together they are lethal.

Here is an example... let's say that you have a unit indexing system like AIDS in a map. If you were to continue to create units at a pretty good rate, it wouldn't lag. Now let's say you add 16 other systems that are riddled with unit index events. Suddenly that slow and steady rate of unit creation starts to lag and freeze the map. It's not that the systems are bad, it's not that the map is bad, it's just too much. People say it doesn't happen, but it does =). Most systems, as emj pointed out, don't really matter too much. If it only contributes <.01% or something to the lag, optimizing it isn't going to make that much of a difference. As a lot of people know, periodic systems are the main killers. Other systems are damage event systems and regeneration systems.

Anyways, that's all I had to say ^)^.

edit
Also I think that KT2/KT are acceptable in some situations.

 

[Jesus4Lyf]

edit
Also I think that KT2/KT are acceptable in some situations.

You're right.

Hey, I can keep this sweet.

In the lack of a realistic speed difference between KT2 and any other timer system, and even circumstances under which KT2 is, in fact, the fastest (off memory, but it's been a while, don't quote me, yet), which Nestharus seems to get (spells being one of those, in most circumstances), I think it is worth acknowledging that since KT2 does not use handle attachment, it is backwards compatible through 1.23 and etc. IMO this is more valuable than a speed difference you will never notice... did you know maps using TU broke and maps using KT2 (mine) didn't? I can still play them on earlier versions if I wish, say at lans where people want to play old, broken maps, and don't want to switch version to play something I've made. Not joking! KT2's compatibility alone is grounds to keep it there.

In regards to Bribe's comments, hey, same old thing, right? We don't need benchmarks! If it's complicated, it must be slow!!

It took a long time before people started to respect my opinion, and I got there by carefully benchmarking my claims and giving real figures with the code I used to get them. Hell, you can see it in the KT2 thread! That's not really relevant, but my point is that if you benchmark KT2, and understand what's going on, the periodic execution will be faster than TU where it matters (low periods) and I think it's faster than T32 for one-instance-at-a-time spells (pending benchmarks on this one). Furthermore, I know for a fact that the system can be optimised by removing a variable set (Nestharus would kill me, the KT_GetData func should be two lines only, off memory), which I may even do one day, but the real fact is who cares?

Azlier, whilst you're generally right and all, I've always said TU/T32 are my recommendations, but KT2 still holds good reasoning. Compatability, and speed... it's got both.

I also agree with emjlr3.

Bribe, I think your witch hunt without benchmarks or understanding is, at this point, uncalled for.

 

[Bribe]

Jesus4Lyf, your private messaging box is apparently full, then I thought visitor messaging is the next-best way but this message is too long.

1. I only care about support for 1.26 (what's playable on battle.net). If a system compatible only with 1.26 is faster than a system that's also compatible with 1.23, then the 1.26 version is more important.

2. That said, I feel I was too extreme to disregard the entire system. What I meant was, for a period which could be replicated with Timer32, KeyTimers2 is no longer acceptable because of the speed difference.

3. The speed difference is massive. I do not rely on the benchmarks due to their errors (restarting the computer magically turns one thing faster than the other), and for this I rely on in-game performance, frames-per-second tests. I suppose I should put together a map showing one thing built with KeyTimers2 and Timer32, but I assure you there is a tremendous speed advantage of Timer32 based on my framerate. It will take me a while to put this map together because right now I have so many other things on my plate.

4. TimerUtils for 0.03125 periods is not appropriate either. That should also be running on Timer32 or a single-timer loop.

5. You said I'm wrong that stress-tests can be ruled out by looking at the code. I disagree. When you know the general weight of an operation (array, math, natives, evaluations, number of operations) you can estimate the speed difference. That's how you self-optimize your code without time-consumingly (and dangerously, in the common case there were errors in the test) relying on benchmarks to do it for you.

6. KeyTimers2 is a trigger evalution for each instance. For each instance, the op-limit is reset, the triggercondition is evaluated, and the function itself has to be searched-out. Yes you only evaluate one trigger but the game internally is evaluating it for each condition as you know based on your experience with op-limit and why evaluations are important to circumvent it.

7. KeyTimers2 does create a unique "And" handle for every instance, you built the system and you know that.

8. I think it was rude for you to quote my entire post as wrong, but I can understand your passion based on that you built the system. At the very least you can't discredit point 7, you do create a new handle for each instance and destroy it when the instance is done.

 

[Jesus4Lyf]

That's fine, I think that was a fairly mature response, so I'll cut to the chase:

Compare 500 different pieces of code (1 instance for each piece of code only) with the same period under 0.3 seconds on KT2 against TU or TU, and tell me which is fastest.
I think that it is KT2, but I could be wrong.

Of course, you will quickly notice that this test is not just arbitrary. Most of the time, spells fulfill this criteria! Which makes KT2 an excellent choice for spell writing, really.

That is, if it is the case! I haven't specifically benchmarked this stuff in a long time. But I think it is a possibility. Oh, and maybe not 500 specifically, but you get the idea!

 

[Bribe]

I think that's what Nestharus meant too when he said there are situations where KeyTimers2 is better. Then it is:

Periods with high-timeouts should use TimerUtils.
Periods with FPS timeouts should use Timer32/regular loop.
Periods with extremely low timeouts use KT2.

 

[Nestharus]

And constant periods should use a Timer Queue ;D.

 

[tooltiperror]

I think we (the not super amazing JASSers) are all still a bit fuzzy about when to use Key Timers in comparison to T32.

 

[emjlr3]

to keep things simple, and as a general rule of thumb, use the system you prefer

 

[Nestharus]

to keep things simple, and as a general rule of thumb, use the system you prefer

I think a better policy for general resources is pick the system best suited to the job ; ). That's the kind of policy THW has been following lately.

If you are writing resources for others to use, then you want your resource to be as perfect as possible ^)^. If you are just writing it for your map, then you want it to be as easy to read and maintainable as possible (to make map editing and extensions easier).

 

[emjlr3]

I think this thread contains enough flames and points of value to be considered over and done with.

If you want to discuss a specific system, do so in its TH thread. If you want to discuss THW rules and regs, do so in its suggestions forum.