Honestly and without a joke i think it would be better to have a custom IsUnitDead function which takes an additional argument, a boolean would be enough (or maybe to be even more accurate an integer flag based on constants integers).
Something like that :
JASS:
function IsUnitDead takes unit whichUnit , boolean trulyDead returns boolean
// trulyDead = true > IsUnitDead returns true only if the unit is not under resurection process or whatever
// trulyDead = false > IsUnitDead returns true only if the unit is under resurection process or not
endfunction
The name "trulyDead" is maybe lame but hopefully you get the idea.
I personnaly think it fits better with one function and an additional argument, but that's me.
Now that i remember i'm talking to a speedfreak Mag, i suppose he won't like it, since imagine you declare a new argument each time you use the function and there is at least one if/then, it will cause your game to lag !
Seriously i talked more about a general standalone custom IsUnitDead function, not only in this library.
More timers != slower map. More timers expiring at the same time = slower map ; P. However, if you make it so that the expiration one expires first, then the application one won't run =). Also, if you make them expire at slightly different periods, then they won't expire at same time : ).
If they both expire at the same time, I'm not sure which would be faster =o.
I'd like to see you expand the documenation with an argument on what makes this resource so great.
I'd like the emphasis to be on its usefulness, not on its speed. A timer system or a timer-dependant system can brag about speed, and I admire that you have part of this resource dedicated to that, but I could program that myself. What I'd like to see is why this event detection is important, how it fits into warcraft 3 and what kinds of things would benefit from it where they couldn't benefit from it before.
On screen keyboard oh my god. Don't get me started how horrible that is. I do my best work on my charming little Asus laptop at home and the keyboard is extraordinarily ergonomic. I can't not have an ergonomic keyboard and Asus has spoiled every other keyboard for me. This Apple keyboard at work is one of the worst I've ever used.
I listed a few uses for the events in the documentation and because I'm so evil, I broke backwards compatibility by changing the names of the events:
- onInstant -> INSTANT
- onTimed -> TIMED
I'm not going to add that ;D
It's still possible while taking advantage of the TIMED event though.
That may be inefficient, but you aren't going to be doing something like that a lot of the time
I might consider adding something like this in the future, but that could make 'Heal' stacking impossible without countless 'pointer' Tables
I get the "UNIT INDEXER ERROR: ATTEMPT TO LOCK NULL INDEX" error. But it seems to work. Could i just comment this debus msg out? or even better, whats the cause?
Ok, here comes the nasty nestharus review on your resource because I felt like making you mad at me too ;p
static boolean enabled
Useful for things like prevent units from being healed for a period of time. Good job.
JASS:
* - Heal.INSTANT
* - Fires on instant heal events.
* - This would be used for systems like:
* - Texttag Displays
*
* - Heal.TIMED
* - Fires 32x a second during a timed heal.
* - This was only added for a sense of
* completeness. It may be useful.
These are useless. The only thing you need is ANY. This is useful for things like modifying a heal as well as displaying texttags. However, if you are going to do healing modifications, you should support healing types, that way the user know how to modify the heal. This would also mean that you could have 4 healing effects on a unit, meaning that you'd fire ANY for all 4 of them. You'd also want to show the texttag for the combined healing.
Look at my DamageEvent stuff in order to see how to properly implement this to support cool things.
The only way this library will ever be useful is if you code spells as a variety of effects. For example, one spell could have a healing effect + an armor boosting effect for a period of time. It'd create the healing effect using your heal system and the armor boosting effect using perhaps an incoming damage modifier.
Really, I'd almost implement a healing system by dealing damage of type HEAL or w/e that way it could run with the rest of the damage stuff. This would allow you to easily support healing types, like undead healing, which does in fact damage living targets.
I actually think that healing should only be done as damage now >.>. For example, if a unit has 33% spell resistance, they'd also resist healing spells. Having your thing not run on damage requires all of the same events to be registered for both damage and non damage types, which makes everything harder and messier to do.
So, in the end, my verdict is that this resource is not flexible enough to be a general system. If it was made to be flexible enough, then it'd be a copy of damage modifiers that just inverts the damage (-damage instead of +damage) ;\. Simpler maps would just use SetWidgetLife and advanced maps would use damage modifiers. The Heal system doesn't really fit in anywhere >.>.
Many required resources = modularity. Few required resources = lots of identical repeated code in your own resource that could otherwise be abstracted to another resource.
Modularity = less code, less work, smaller map sizes, same performance.
A resource should only do a specific task =). Anything beyond that task can be abstracted out to another resource ^_-.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
)
