Merry christmas and Obito

Hello guys, I hope you had a nice Christmas
Bacause work I can't finish yet NWU 1.3.9 but there is a little present: Obito.w3x (95% ready)
You can test it and see how it works to have an advantage in 1.3.9

It's open source so those who codes in w3 can see the code and tell me if something can be done in a better way. Anyways, many things in code have been done for NWU's map compatibility (for a faster and easier hero import).

This mean also someone can use it in his map, I really don't care if credit NWU.

Some Pics

5 more % for the new version

5% For Obito. New version is ~25-30%

Thats one badass model I must admit, however the spells do not realy look (as in terms of visual effects) good. Lemme give you a couple of suggestions:

1) Apply Japanese names to those spells which are:

a) Mazō no Kusari - those chains are ultimately part of Gedo Mazo's binding power
b) Uchiha Kaenjin
c) Mokuton No Yoroi - just doesn't sound right when you write it as Mokuton: Mokuton No Yoroi because it repeats the word "Mokuton" twice. I suggest just putting it as Mokuton No Yoroi would be better

2) And in terms of visual effects I suggest you change the first spell's hook effect. It does kinda look like the metal rope which the mechanical path of pain used to wield, and taking into the account the name of that spell, people will just think he actually threw a metal rope. I suggest you to change the effect to something similar like Wisp's Tether (first spell) where he establishes a blue sort of magical link. Chakra's color in the anime is kinda blue-ish, so I think it would only be suitable for Obito to have that effect

But yeah, in general its a nice build, although the push effect does seem to be kinda wierd as it doesn't quite help in getting the enemy inside the barrier, but i guess thats just situational, we'll get over it

So yeah, thanks for the update and merry christmas

-------------------------------
ps oh and yeah i do hope you're gonna change the icons because the ones you have now are just horrible !

muzk wrote:

5% For Obito. New version is ~25-30%

o fuck well obito very op :/

I hate effects because it needs search and search is time XD. Generally Natsu or Eol send me the effects links from www.hiveworkshop.com or similar sites, so I have only to code the mechanics but they are BUSY.

Push is to use after fire because it does DPS to near units.

Those are the best icons I found in Warcraft3. I wont import icons until I free space from code / models.

http://www.wowwiki.com/WC3_Icons/Icon_List

Indeed search is time but the more you search the better effects you'll have in your map which will keep up the interest in the map the only problem i have is that damned hook, it will always remind me of Pudge from Dota !!!

Anyway what if I will find something similar to what I've said in my previous post about the blue link chain for Obito? Lets say on that hiveworkship site as well? Are you willing to have a look at that?

About icons:

So what does that mean? you're gonna use standart War3 icons right now, or you'll try to reduce some space in the next version to input new icons?

--------------------------------------

PS just in case if you'll decide to go with the standart icons, have a look at this icon combo which Ive made:

Spoiler:

--------------------------------

PSS. THERE! It took me about less than 3 minutes to find something which I was thinking about regarding replacing that damned hook! Here's the link:

http://www.hiveworkshop.com/forums/spells-569/magic-hook-187979/?prev=search%3DMagic%2520chain%26r%3D20%26d%3Dlist%26page%3D3

the first #1 icon is good and the second #3rd icon good

I know, the reasons why I posted Obito are:
- xmass
- script optimization suggestions
- effects suggestions

So thankz for your feedback! By now I will use those standart icons that you suggested. I gonna try to reduce map size to put new ones.

If someone want to improve effects, just tell me a map/site where it appears =)

Nice Job!

Hey muzk, I've posted my hero idea (Ameyuri Ringo) on one of the russian mod making forums, they make spells and triggers and all that kind of thing. Anyway my question is - would you be willing to have a look and if its gonna match the map's requirements, at the char and possibly think about implementing him into the map? If they do manage to create all those 4 spells which i've listed, that woudl save you a lot of trouble and you could put some extra bits into the changelog eh?

Do you have an example?

you mean like an example of their work? Yes I suppose i can copy a couple of samples which were posted earlier on the forum.

1. Stone Skin

Spoiler:

2. Bakuhatsu Bakuenjin

Spoiler:

First spell is simple but its code is good.

I wont see the second skill because its GUI: "Type: GUI". I'm interesed only in "Type: Jass"

Okay cool i'll let them know about that

I've been looking into your code and I wanted to do some suggestions.

• First, in Chakra Chains, why moving every single dummy backwards and forward? If you create a line along time and then remove units as you move Obito, it will generate the same effect to the gamers eyes without wasting so much computer power. Look at your spell right now and if you look closely, you'll realise you can achieve the same effect without moving a single chain dummy.
  
• Another suggestion is that in AoS style maps a player can have a single hero at the same time, this means that you can make "MUI" Spells that are more simplified by using the owner's data. In NvB, I simplified many things by using arrays to keep data and use a simple "formula" for sepparating each player version of the spell. The formula is MyArray[* + id] in other words a two dimensional array: MyArray[PlayerNumber][DataNeeded]. Don't worry that arrays don't cost anything, they are just hardcoded hashtables within the game's code. The downside is that modes like WTF in DotA are not possible using this technique. (Well if you are optimizing machine heavy spells, y making wtf mode in the first place? it would lag heavily).
  
• Another thing is that using SetReal(,,,) and other repeatitive functions can be real annoying and normaly produce errors when we forget shit. It's better to trust the optimizer and add linearizeable functions, even if they look dumb. You can also use cJass and use defines, if you don't trust the optimizer.
  
• Create a nomemclature for Hashtable codes, this will allow you to avoid conflicts when you save information on a target, rather than on the caster. For this I used Hexadecimal codes in NvB. It followed a simple format: 0xHHMMSSDD HH: Hero code (limited to 255, doubt anyone ever adds more than 255 heros to a map) MM: Morph form (if needed), SS: (Spell id), DD: (Data Entry). If HH is 00 then it's a system's data and MM will be the library number and SS the scope in that library.
  
• TimerUtils is more a con than a pro, sure it avoids that you do silly things, but if you know that you that you have to pause a timer before destroying it then you don't really need it. They were designed for GameCache's era(the save timer data was way faster), now with hashtables, they are pretty pointless.
  
• Try using a variation of vJass or normal Jass like cJass or Zinc, this will really save you time at writting code (all my examples below are in cJass) and it will make your code more readable.
  

Examples:

TimerUtils cJass style

Code:

define {
    DestroyTimer(t) =
    {
        PauseTimer(t)
        Destroy##Timer(t)
    }
}
//Definition of hook in cJass. A hook, takes an existing function and replaces it for block of code.

Yamamoto's Joukaku in NvB, cJass style

Code:

    define {
        private MAI_TARGET  = 0x0B000200; //Hinata Code - No Morph - Spell 3 - Data 0
        private MAI_MANA    = 0x0B000201;
        private MAI_BUFF    = 'B02N';
        private MAI_TIME(lvl) = (lvl*0.75 + 0.25);
        private MAI_MANA_PERCENTAGE_ABSORB(lvl) = (0.01+lvl*0.01);
    }
   
    private trigger Mai;
    private bool Mai_C() { return GetSpellAbilityId() == MAI_ABIL; }
   
    private void Mai_Callback() {
        timer t        = GetExpiredTimer();
        int h          = GetHandleId(t);
        unit v          = GetUnit(h,MAI_TARGET);
        real mana;
        if (GetUnitAbilityLevel(v,MAI_BUFF) != 0) {
            mana = GetUnitState(v,UNIT_STATE_MANA) - GetReal(h,MAI_MANA);
            if (mana >= 0.0) {
                SetUnitState(v,UNIT_STATE_MANA,mana);
            }
            else {
                SetUnitState(v,UNIT_STATE_MANA,0.);
            }
        }
        else {
            FlushSubject(h);
            PauseTimer(t);
            DestroyTimer(t);
            t = null;
        }
    }
   
    private void Mai_A() {
        unit u      = GetTriggerUnit();
        unit v      = GetSpellTargetUnit();
        real lvl    = I2R(GetUnitAbilityLevel(u,MAI_ABIL));
        real time  = MAI_TIME(lvl);
        real mlps  = MAI_MANA_PERCENTAGE_ABSORB(lvl)*GetUnitState(v,UNIT_STATE_MANA)*0.25;
        timer t    = CreateTimer();
        int h      = GetHandleId(t);
        SetReal(h,MAI_MANA,mlps);
        SetUnit(h,MAI_TARGET,v);
        TimerStart(t,0.25,true,function Mai_Callback);
    }

Quote :

First, in Chakra Chains, why moving every single dummy backwards and forward? If you create a line along time and then remove units as you move Obito, it will generate the same effect to the gamers eyes without wasting so much computer power. Look at your spell right now and if you look closely, you'll realise you can achieve the same effect without moving a single chain dummy.

Just to keep the linked list in the same order of chains and to create units in the grow direction. It isn't just a line, ie, it can be a curve. Anyways, I don't like this solution, I will try other way if I have time.

Quote :

Another suggestion is that in AoS style maps a player can have a single hero at the same time, this means that you can make "MUI" Spells that are more simplified by using the owner's data. In NvB, I simplified many things by using arrays to keep data and use a simple "formula" for sepparating each player version of the spell. The formula is MyArray[* + id] in other words a two dimensional array: MyArray[PlayerNumber][DataNeeded]. Don't worry that arrays don't cost anything, they are just hardcoded hashtables within the game's code. The downside is that modes like WTF in DotA are not possible using this technique. (Well if you are optimizing machine heavy spells, y making wtf mode in the first place? it would lag heavily).

I think so. In fact, some heroes are made in that way.
Arrays hardcored hashtables? Are u talking about the concept you are using or about how it works? Because in reality hashtable are made using an array of linked lists (well it depends on how you code it, but the data is handled by a array).

Quote :

Another thing is that using SetReal(,,,) and other repeatitive functions can be real annoying and normaly produce errors when we forget shit. It's better to trust the optimizer and add linearizeable functions, even if they look dumb. You can also use cJass and use defines, if you don't trust the optimizer.

+1, I'm using others API in NWU atm.

Quote :

Create a nomemclature for Hashtable codes, this will allow you to avoid conflicts when you save information on a target, rather than on the caster. For this I used Hexadecimal codes in NvB. It followed a simple format: 0xHHMMSSDD HH: Hero code (limited to 255, doubt anyone ever adds more than 255 heros to a map) MM: Morph form (if needed), SS: (Spell id), DD: (Data Entry). If HH is 00 then it's a system's data and MM will be the library number and SS the scope in that library.

I'm using a simple nomemclature just based in a unique integer to save information on units.

Quote :

TimerUtils is more a con than a pro, sure it avoids that you do silly things, but if you know that you that you have to pause a timer before destroying it then you don't really need it. They were designed for GameCache's era(the save timer data was way faster), now with hashtables, they are pretty pointless.

TU was designed just for save struct instances in a timer and to avoid creating and destroying a handle that can be reused. I'm not using TU in NWU, but a similar snipplet based on a simple timer recycle. I used it with Obito.w3x cause I use the same function names in this "system" and it comes with the template map LOL.

Quote :

Try using a variation of vJass or normal Jass like cJass or Zinc, this will really save you time at writting code (all my examples below are in cJass) and it will make your code more readable.

This depends on you.... but rly, loved the cjass style. I haven'tt liked zinc, but cjass looks awesome!

Thankz for sharing ur comment.

muzk wrote:

Just to keep the linked list in the same order of chains and to create units in the grow direction. It isn't just a line, ie, it can be a curve. Anyways, I don't like this solution, I will try other way if I have time.

Just use an array and simulate a queue on it. It's faster saves resources, less code, easier to handle in wc3. If you want to make curvy looking effects then use Bezier Interpolation with 1 tangent (I'm only seeing curvy affects on Z axis, this done by terrain heigth :/). if you are concerned about the curvy effects it sometimes generate, then make dummy creation be relative to the last dummy you created. After you have created all of them, just go from the start to the end of the multidimensional array. Remember that a list should only be used when the amount of items have no real maximun or the maximun costs too much. Plus Linked Lists have the same limitation than arrays on size since in fact vJass just turns them into arrays with allocation handling, there are no longer ways to do dynamic memory ( before we could inject x86 code using the return bug on code types for running it)

muzk wrote:

I think so. In fact, some heroes are made in that way.
Arrays hardcored hashtables? Are u talking about the concept you are using or about how it works? Because in reality hashtable are made using an array of linked lists (well it depends on how you code it, but the data is handled by a array).

I'm talking of wc3's core code. Jass Arrays in wc3 were programmed in such way that they are actualy a big hashtable in the inside(I'm talking of how wc3 manages it, not about jass itself). This was discovered by PipeDreams back in the old wc3 days. When we were able to hijack wc3 injecting code to it... until those muttyfickers changed the compiler (damn Blizzard). Therefore, declaring an array variable costs as much as you fill it (it reallocates memory every power of 2 until it reaches the max: 8192). Pretty much the correct term is a Symbol's table with reallocateable arrays as values (if you know the basics of compilation and/or bzw. interpreting a programming language you'll understand how it works).

muzk wrote:

I'm using a simple nomemclature just based in a unique integer to save information on units.

I used to use that nomenclature until I found a lil problem on stacking custom effects on units. Let's say you have a hero that adds a effect to every unit he attacks, this effect makes it leak mana whenever he's attacked and you keep an specific amount(all this data is kept within the affected unit), and you have another hero who has a similar passive. A unit is hit by both heros, now the question is: How do you stack both effects if the data is being saved on the same unit and the data is saved on that unit? that's when classifying keys of the hash really comes into play.

muzk wrote:

TU was designed just for save struct instances in a timer and to avoid creating and destroying a handle that can be reused. I'm not using TU in NWU, but a similar snipplet based on a simple timer recycle. I used it with Obito.w3x cause I use the same function names in this "system" and it comes with the template map LOL.

Exactly, but a single SaveInt/LoadInt is more efficient than calling a jass function(I've benchmarked this before), so TU are now obsolete.

muzk wrote:

This depends on you.... but rly, loved the cjass style. I haven'tt liked zinc, but cjass looks awesome!

Thankz for sharing ur comment.

You can find cjass compiler here: cjass.xgm.ru, you can mix it with vJass if you want using it's syntax.

Glad it helped you a bit.

Hey shinigami12, are you the one who made NvB map? If yes then it lacks balance big time! Make forums like this one and ask people what can be changed!

Westfield wrote:

Hey shinigami12, are you the one who made NvB map? If yes then it lacks balance big time! Make forums like this one and ask people what can be changed!

I must agree. Howver, I didn't come here to talk about my map but as a nwu player and a fellow mapper. If you feel like suggesting for my map I invite you to go to nvbclan.freeforums.org. Sorry, if I was a bit rude, but I must stay on topic. I don't want to use these forums as a mean to publish my map. Thanks for your interest, it's deeply appreciated.

Quote :

Remember that a list should only be used when the amount of items have no real maximun or the maximun costs too much. Plus Linked Lists have the same limitation than arrays on size since in fact vJass just turns them into arrays with allocation handling, there are no longer ways to do dynamic memory ( before we could inject x86 code using the return bug on code types for running it)

Quote :

Just use an array and simulate a queue on it. It's faster saves resources, less code, easier to handle in wc3.

LinkedList insertion is O(1), the same as array.
Less code/easier depends on the implementation.

Quote :

If you want to make curvy looking effects then use Bezier Interpolation with 1 tangent (I'm only seeing curvy affects on Z axis, this done by terrain heigth :/). if you are concerned about the curvy effects it sometimes generate, then make dummy creation be relative to the last dummy you created. After you have created all of them, just go from the start to the end of the multidimensional array.

The curve effects I want depends in Obito's movement, you can move where you want after you cast the spell. In particular, you can move tangencial to chains... I don't want it looks like a "L". You can do it by moving each chain (as I did) or creating more chains from the "first" chain to obito while creating a extra chain from the last to target unit. Differences between two solutions? ... You can note that with the last solution the chain grows in both sides, I only want it to grow in one direction.

Well, finally thankz to you now I can avoid linked list in this spell (1 struct less! )

Quote :

Remember that a list should only be used when the amount of items have no real maximun or the maximun costs too much. Plus Linked Lists have the same limitation than arrays on size since in fact vJass just turns them into arrays with allocation handling, there are no longer ways to do dynamic memory ( before we could inject x86 code using the return bug on code types for running it)

Obviously I'm not using LinkedList for dynamic memory. Also, who says that they should be only used depending on the # of elements? Remember complexity and other factors :S for example, the solution model. In this case the operations I'm using are only O(c) (c = constant ~ 1). Only thing I don't like I'm using extra space in map to store a whole struct :C but I will change it

Also, remember if obito blinks away, all chains should be moved also. It don't grows.

- Chains has an "static" length. If Obito blinks away (using Yondaime Kunai for example), the all the chains should be moved also. It don't grow.
- Retraction instances:
1) Chain does reach a unit: Obito is moved to target (removing chains from the first to the last)
2) Chain doesn't reach a unit: Chains are removed from the farther (removing chains from the last to the start).

Moving chains is necesary I'm gonna use arrays for less code generation, sth like links[instance][chain#] or links[playerid][chain#] I have to add an integer pointing to the last removed chain too.

Quote :

I'm talking of wc3's core code. Jass Arrays in wc3 were programmed in such way that they are actualy a big hashtable in the inside(I'm talking of how wc3 manages it, not about jass itself). This was discovered by PipeDreams back in the old wc3 days. When we were able to hijack wc3 injecting code to it... until those muttyfickers changed the compiler (damn Blizzard). Therefore, declaring an array variable costs as much as you fill it (it reallocates memory every power of 2 until it reaches the max: 8192). Pretty much the correct term is a Symbol's table with reallocateable arrays as values (if you know the basics of compilation and/or bzw. interpreting a programming language you'll understand how it works).

All arrays? I thought they made arrays in that way when you declare an array with a lenght < 8192. So they are like lists o.o Lists grow when are full in a hardcoded factor, so they used 2 as initial array length and 2 for the grow factor. Hashtables internal array grows to avoid hash collitions, generally when the load factor grows beyond 0.7 or so

Quote :

I used to use that nomenclature until I found a lil problem on stacking custom effects on units. Let's say you have a hero that adds a effect to every unit he attacks, this effect makes it leak mana whenever he's attacked and you keep an specific amount(all this data is kept within the affected unit), and you have another hero who has a similar passive. A unit is hit by both heros, now the question is: How do you stack both effects if the data is being saved on the same unit and the data is saved on that unit? that's when classifying keys of the hash really comes into play.

I see ... I'm just using uniques Ids for each of them. ie:
skill1: id = 1 so this data has to be saved on data[unit,1]
skill2: id = 2 so this data has to be saved on data[unit,2]
...
skilln: id = n ... data[unit,n]

Quote :

Exactly, but a single SaveInt/LoadInt is more efficient than calling a jass function(I've benchmarked this before), so TU are now obsolete.

As I said before, TU were made to recycle timers and to attach structure instances to them. By Creating/Destroying timers you aren't recycling. Also, it's a bit obvious that NewTimer/ReleaseTimer are slower than CreateTimer/Destroy timer because you have to get the timer from arrays to use them. This was proved in somewhere that saving/loading data from wc3 arrays is faster than load/save data from wc3 hashtables, so taking it into account, passing data between functions with an struct still valid --> TU is not obsolete :c

Anyways, Idk / Idc if array/hashtables faster because I'm not using much structs to pass data, I only like recycling my timers .

Btw, it's proved also than using normal timer attach (ie hasthables) for low period timers is worse than using normal struct iterations (1 timer + looping trought each instance).

Quote :

You can find cjass compiler here: cjass.xgm.ru, you can mix it with vJass if you want using it's syntax.

I read from somewhere it comes with jngp :c

nvb is unbalanced fail map maker -_-

Its ok, he gave a link to the forums, i'll post a brief overview about all chars in the game soon and what can be changed

ps Shinigami12 i only shown a slight interest in the map because it has Bleach in it and at the moment its pretty much the only Bleach dota type of project which is alive, but as of now i dont play it because its imbalanced. Have a look at nwu at least or Dota. The main problem with your map is the spell's synergy and stats and perhaps a little bit of a creativity issue, but that is solvable if people will get interested in the map

muzk wrote:

Obviously I'm not using LinkedList for dynamic memory. Also, who says that they should be only used depending on the # of elements? Remember complexity and other factors :S for example, the solution model. In this case the operations I'm using are only O(c) (c = constant ~ 1). Only thing I don't like I'm using extra space in map to store a whole struct :C but I will change it

Also, remember if obito blinks away, all chains should be moved also. It don't grows.

- Chains has an "static" length. If Obito blinks away (using Yondaime Kunai for example), the all the chains should be moved also. It don't grow.
- Retraction instances:
1) Chain does reach a unit: Obito is moved to target (removing chains from the first to the last)
2) Chain doesn't reach a unit: Chains are removed from the farther (removing chains from the last to the start).

Moving chains is necesary I'm gonna use arrays for less code generation, sth like links[instance][chain#] or links[playerid][chain#] I have to add an integer pointing to the last removed chain too.


As I said before, TU were made to recycle timers and to attach structure instances to them. By Creating/Destroying timers you aren't recycling. Also, it's a bit obvious that NewTimer/ReleaseTimer are slower than CreateTimer/Destroy timer because you have to get the timer from arrays to use them. This was proved in somewhere that saving/loading data from wc3 arrays is faster than load/save data from wc3 hashtables, so taking it into account, passing data between functions with an struct still valid --> TU is not obsolete :c

Anyways, Idk / Idc if array/hashtables faster because I'm not using much structs to pass data, I only like recycling my timers .

Btw, it's proved also than using normal timer attach (ie hasthables) for low period timers is worse than using normal struct iterations (1 timer + looping trought each instance).

muzk wrote:

LinkedList insertion is O(1), the same as array.
Less code/easier depends on the implementation.

That's in theory (if this would be C, Java then it's valid), but remember that vJass is not pure and insertion costs for every node in vJass's memory allocation rutine which is a bit expensive to be honest.

muzk wrote:

The curve effects I want depends in Obito's movement, you can move where you want after you cast the spell. In particular, you can move tangencial to chains... I don't want it looks like a "L". You can do it by moving each chain (as I did) or creating more chains from the "first" chain to obito while creating a extra chain from the last to target unit. Differences between two solutions? ... You can note that with the last solution the chain grows in both sides, I only want it to grow in one direction.

Well, finally thankz to you now I can avoid linked list in this spell (1 struct less! )

Now I get what you wanted.

muzk wrote:

Obviously I'm not using LinkedList for dynamic memory. Also, who says that they should be only used depending on the # of elements? Remember complexity and other factors :S for example, the solution model. In this case the operations I'm using are only O(c) (c = constant ~ 1). Only thing I don't like I'm using extra space in map to store a whole struct :C but I will change it

Also, remember if obito blinks away, all chains should be moved also. It don't grows.

- Chains has an "static" length. If Obito blinks away (using Yondaime Kunai for example), the all the chains should be moved also. It don't grow.
- Retraction instances:
1) Chain does reach a unit: Obito is moved to target (removing chains from the first to the last)
2) Chain doesn't reach a unit: Chains are removed from the farther (removing chains from the last to the start).

Moving chains is necesary I'm gonna use arrays for less code generation, sth like links[instance][chain#] or links[playerid][chain#] I have to add an integer pointing to the last removed chain too.

Another valid reason to use the list is mid deletion, but as I see it, you are just implementing a Queue, a Queue can be simply be programmed with arrays and is faster than any application you make unless you don't know how long Queue can be.

muzk wrote:

As I said before, TU were made to recycle timers and to attach structure instances to them. By Creating/Destroying timers you aren't recycling. Also, it's a bit obvious that NewTimer/ReleaseTimer are slower than CreateTimer/Destroy timer because you have to get the timer from arrays to use them. This was proved in somewhere that saving/loading data from wc3 arrays is faster than load/save data from wc3 hashtables, so taking it into account, passing data between functions with an struct still valid --> TU is not obsolete :c

Anyways, Idk / Idc if array/hashtables faster because I'm not using much structs to pass data, I only like recycling my timers .

Quote :

wc3 arrays is faster than load/save data from wc3 hashtables,

Just calling a Jass function is slower. So it won't matter what's inside.

If you want to recycle timers. Use hookers instead, it will save you the need to care for calling the recycler:

Code:

library TimerRecicly {
    define {
        CreateTimer = CreateTimer_Hook;
        DestroyTimer(t) = DestroyTimer_Hook(t);
        private STACK_SIZE = 128;
    }
    private timer array RecycleBin;
    private int stack = 0;
    timer CreateTimer_Hook() {
        if (stack != 0) {
            stack--;
            return RecycleBin[stack];
        }
        return Create##Timer()
    }
   
    void DestroyTimer_Hook(timer t) {
        if (stack != STACK_SIZE) {
            PauseTimer(t);
            RecycleBin[stack] = t;
            stack++;
            return;
        }
        Destroy##Timer(t);
    }
}

That's it.

muzk wrote:

Btw, it's proved also than using normal timer attach (ie hasthables) for low period timers is worse than using normal struct iterations (1 timer + looping trought each instance).

that's wrong, what's prove is that it's better to attach a struct id into a timer using hashtables than attach every single value. It's a matter of comfort.

Quote :

That's in theory (if this would be C, Java then it's valid), but remember that vJass is not pure and insertion costs for every node in vJass's memory allocation rutine which is a bit expensive to be honest.

Anyways, it's gonna be constant complexity, nothing to care at all

Quote :

If you want to recycle timers. Use hookers instead, it will save you the need to care for calling the recycler:

How does hook works? (generated jass code)