- Reaction score
- 91
JASS:
elseif .stacks == 9 then
set u = null
return true
This is where you should also destroy your struct.
elseif .stacks == 9 then
set u = null
return true
Would it be feasible, or even useful, for the whole T32 system to be a textmacro in order to instantiate the system at a different loop rate? eg. [ljass]//! runtextmacro "TX"(40)[/ljass] would create a library_once named T40 and period 0.02, or [ljass]//! runtextmacro "TX"(2)[/ljass] would create a library_once named T2 and period 0.5?
It would be ironic to say the least.Would it be feasible, or even useful, for the whole T32 system to be a textmacro in order to instantiate the system at a different loop rate? eg. [ljass]//! runtextmacro "TX"(40)[/ljass] would create a library_once named T40 and period 0.02, or [ljass]//! runtextmacro "TX"(2)[/ljass] would create a library_once named T2 and period 0.5?
It would be ironic to say the least.
Possible, but what's the point?
Would it be feasible, or even useful, for the whole T32 system to be a textmacro in order to instantiate the system at a different loop rate? eg. [ljass]//! runtextmacro "TX"(40)[/ljass] would create a library_once named T40 and period 0.02, or [ljass]//! runtextmacro "TX"(2)[/ljass] would create a library_once named T2 and period 0.5?
That's what he's suggesting. A textmacro to create it. It would just mean resources could be submitted using whatever period they like, and since it uses library_once, they would not conflict. It makes sense, if there is any purpose in having multiple periods, which is what I am trying to ask...If you need to, you can always just create a separate timer, trigger, and module for it.
No. I mean, [lJASS]//! runtextmacro[/lJASS]s and [lJASS]//! import[/lJASS] still require JassHelper, but actually, that's an interesting thought. It's completely unrelated to this question, though.Are you thinking of a system to code timers in the vanilla world editor?
T32 is supposedly the most efficient timer system possible, but only works for a single period. If someone wanted to use a different period, they couldn't use T32 without modifying its setting, which would possibly mess up any other imported resources using T32. Some people (like Viikuna and myself) like periods faster than 32/sec for sliding effects; also, some periodic effects don't need to be that fast.It makes sense, if there is any purpose in having multiple periods, which is what I am trying to ask...
In these cases, the authors should write the systems to be independent of the FPS of T32 - ie. they should perform calculations based on T32_PERIOD. This allows a map author to set T32_PERIOD to whatever they wish. So a slide system built on T32 would use whatever FPS the map author wishes - indeed, if the entire map runs too slow, just make T32 fire less frequently. Unfortunate that the resource name itself has "32" in it in hindsight.
This is the real thing I'm looking for. Can you give some examples?also, some periodic effects don't need to be that fast.
Damage over time. Effects over time on units in an area. Detecting units entering an area (like auras). Checking for presence of a buff. Rapid but not OMG-FAST repeating special effects. The non-visual component of an in-a-line spell (32 enums/sec? Madness!) Very slow slides that don't need such a framerate to still look smooth, or sliding ribbon emitters (which themselves have an emission rate that is pointless to exceed). These are things that I tend to run at 0.1-0.25s.This is the real thing I'm looking for. Can you give some examples?
library foo requires TimerUtils
private struct Data
private integer tick=0
private unit killer
private method periodic takes nothing returns nothing
set this.tick=.tick+T32_PERIOD
if(tick==T32_FPS*5(then
if (UnitAlive(this.killer)) then
call KillUnit(this.killer)
call this.stopPeriodic()
endif
endif
endmethod
private static method actions takes nothing returns nothing
local thistype this=thistype.create()
set this.killer=GetKillingUnit()
call this.startPeriodic()
endmethod
private static method onInit takes nothing returns nothing
// register a death event
// register thistype.actions as a callback
endmethod
implement T32x // <--- that is what actually adds it
endstruct
endlibrary
loop
move fireball
wait(0.01)
endloop
struct Move
real dx
real dy
unit subject
private method periodic takes nothing returns nothing
call SetUnitX(subject, GetUnitX(subject) + dx)
call SetUnitY(subject, GetUnitY(subject) + dy)
endmethod
implement T32x
private static method create takes unit which, real xPerSecond, real yPerSecond returns thistype
local thistype this = thistype.allocate()
set this.dx = xPerSecond * T32_PERIOD
set this.dy = yPerSecond * T32_PERIOD
set this.subject = which
call this.startPeriodic()
return thistype
endmethod
method destroy takes nothing returns nothing
call this.stopPeriodic()
call this.deallocate()
endmethod
endstruct
local unit myFireball = // whatever, make some fireball.
local Slide s = Slide.create(myFireball, 1000, 500)
call TriggerSleepAction(2.0)
call s.destroy()
//remove fireball