without timer...

[mckill2009]

1. Is it possible NOT to use custom made timers/libraries (like TimerUtils) for storing data when using structs?...if it is please give an example...

2. What is the difference between...
- create and allocate
- public method and static method

3. Why private method cant be called by another method inside the struct?...

4. implement calling is just for modules?...

 

[Stranger]

1. Is it possible NOT to use custom made timers/libraries (like TimerUtils) for storing data when using structs?...if it is please give an example...

2. What is the difference between...
- create and allocate
- public method and static method

3. Why private method cant be called by another method inside the struct?...

4. implement calling is just for modules?...

1. TimerUtils' SetTimerData just uses a hashtable call that saves an integer to a hashtable. You don't need a timer library to attach data, but you would still want to use a timer stack and a hashtable to store data which is provided by things like TimerUtils. Whether or not you get that from a public resource or you make it yourself is up to you.

Keep in mind that you only need to attach structs to timers when a timer's interval is above .04 seconds (25 intervals per second). From person to person that number may vary, but the point of attaching structs to timers is that each spell instance needs to be smooth which depends on the timer interval. With .04 seconds per interval or lower, you can use a single timer and indexing (not necessarily structs) and still have a smooth effect.

2. Allocate gets the next index for the struct and probably sets non-static struct members to their initial value (if any). Create uses allocate by default and returns what allocate returns, but it's also used by many people as a place to set values for the struct members. You may as well use structs that extend array and merge the two together, or avoid the function call all-together if you're willing to sacrifice readability. Keep in mind that normal structs automatically generate create, destroy, allocate, deallocate, and the variables required to work as intended. Structs that extend array leave all of this up to you.

public & private have nothing to do with static. Non-static methods take an index (a specific struct instance), and static methods do not.

3. That shouldn't happen. Methods are functions, so make sure you're ordering them correctly.

4. Yes.

 

[Nestharus]

Keep in mind that you only need to attach structs to timers when a timer's interval is above .04 seconds (25 intervals per second). From person to person that number may vary, but the point of attaching structs to timers is that each spell instance needs to be smooth which depends on the timer interval. With .04 seconds per interval or lower, you can use a single timer and indexing (not necessarily structs) and still have a smooth effect.

100% untrue

TimerQueue is a perfect example.

That shouldn't happen. Methods are functions, so make sure you're ordering them correctly.

Ehm, the ordering wouldn't make it work. Methods not ordered properly turn into trigger evaluations on call and the syntax error never comes up. He is more than likely calling it incorrectly.

 

[mckill2009]

so meaning I should save thistype to a hashtable?...well, other than that is there any other way? like CreateTimer>>>TimerStart>>>GetExpiredTimer blah blah...

so allocate and create have a similar function eh?...

about that private thing, yeah maybe Im calling it wrong, gonna test it again...

 

[Stranger]

so meaning I should save thistype to a hashtable?...well, other than that is there any other way? like CreateTimer>>>TimerStart>>>GetExpiredTimer blah blah...

Yes. You're just attaching an integer so the timer knows which index to use.

As far as attaching data goes, your two options are pretty much hashtables or gamecaches, and hashtables are faster than gamecaches.

about that private thing, yeah maybe Im calling it wrong, gonna test it again...

Examples always help:

struct test
    //create method
    static method create takes nothing returns thistype
        local thistype this = thistype.allocate()
        return this
    endmethod
    //destroy method
    method destroy takes nothing returns nothing
        call this.deallocate()
        //"this" refers to the struct instance that is using destroy
    endmethod
endstruct

function randomfunc takes nothing returns nothing
    local test dat = test.create()//static method
    call dat.destroy()//normal method, needs a struct instance (in this case dat)
endfunction

/*
When compiled into jass, dat.destroy() would look like this:
call destroy(dat)

Create would be like this:
local integer dat = create()

The names of create and destroy would obviously be based on the struct name.
*/

@Nestharus

100% untrue
TimerQueue is a perfect example.
.

I'm going to take a look at TimerQueue, but I don't see how what I said is 100% untrue. In fact it seemed like common sense.

you only need to attach structs to timer when a timer's interval is above .04 seconds (25 intervals per second)

1. Why would I want to bother attaching structs to timers that execute 32 times per second when I could just use one timer. A good example could be a knockback system. Using a timer for each unit is stupid. That would be a large amount of code execution per second compared to one timer.

each spell instance needs to be smooth which depends on the timer interval

2. Pretty much the opposite of #1. Let's say that I make a spell that destroys or creates an effect every 2 seconds. Why wouldn't I want to use a single timer for each spell instance and a hashtable to attach struct data to each timer? If I use a single timer, I would need to run it at a much lower interval to create a smooth effect over a choppy one. That seems like a waste of processing time.

What exactly am I missing in all of this?

 

[Nestharus]

TimerQueue would be similar to a the typical timer struct list for 32x per second timers, except that a TimerQueue can handle larger periods w/o accuracy loss.

 

[mckill2009]

As far as attaching data goes, your two options are pretty much hashtables or gamecaches, and hashtables are faster than gamecaches.

Are you sure?...well then if you are then that solves my query...

 

[Bribe]

TimerUtils red uses GetHandleId() - 0x100000 which is the fastest timer attaching method except in super-rare cases where a timer queue gets merged. If you can manage your handle stack properly or simply pre-define enough timers, you can get away with using this approach and never have to touch hashtables.