Timers

[x.Zeus]

How can I attach units, effects, etc on timers? Cant find func like hash in wc (bank and tabs... Oo)?

 

[Dr Super Good]

Data tables...
Be warned that they take only 1 index instead of 2.

 

[tagg1080]

How can I attach units, effects, etc on timers? Cant find func like hash in wc (bank and tabs... Oo)?

Hash tables are HUGE memory hogs.

I still don't know why people run to them...

Like Dr. said, try the data tables...

 

[Dr Super Good]

Hash tables are HUGE memory hogs.

Not really, they are very efficent at near O(1) axcess of data using a large varience index like a 32 bit value.

Where as with normal arrays you would need 4 GB of memory or more, with hashtables you could use 32 bit values as keys in as little as under 1 kilobyte of memory. Logically if you store too much the memory usage will have to increase and also the axcess speed will slow down, but they are great memory savers.

Python uses dictonaries (its hashtable native type) for all its variables.

The real problem is programmers nowdays often use hashtales where normal arrays would do fine.

 

[x.Zeus]

And how attach to 1 timer some handles... f.e I need attach 2 units...
so...

dying_unit = (Triggering unit) <Unit>
killing_unit = (Killing unit) <Unit>
eff_timer = (New timer) <Timer>
Data Table - Save eff_timer as "Recount" in the Global data table
Data Table - Save dying_unit as "Recount" in the Global data table
Data Table - Save killing_unit as "Recount" in the Global data table
Timer - Start eff_timer as a One Shot timer that will expire in 5.0 Game Time seconds

How true? And how load after?

 

[Dr Super Good]

Using database logic I guess...
You store a key to the timer. The key represents an entry in some other data storage structure which has all 3 pieces of data you wanted attached.

A simple 1 to 1 data relationship, you could even store the timer with the data so you can easilly traverse the relationship in both directions.

As for how to set this up, well as long as you remove all traces of each entry as they are done to prevent leakage, you could even use nested data tables. Data table1 stores a key to the timer. Data table2 stores the data to a key.

For example, the first instance would store 1 to the timer in data table1. In data table2 it then stores eff_timer as 1a, dying_unit as 1b and killing_unit as 1c (key + letter). As hashtables function in such a way that recycling index is not important, there is no need to recycle keys thus you can simply use key = key+1: for the next key.

This method provides infinite scalability (you could have 1 or 100 timers allocated and no extra address space would be wasted and left unused) with near constant performance demands (near O(1) from the hashtable mechanics). The problem is it is quite slow each recall however if you do it very rarely (atmost a couple times a second) it should make no difference.