Intuitive Damage Detection System

[Here-b-Trollz]

The issue with that method being that it kills copy/paste-ability. What... you want me to add the code for a damage type AND declare it in your system header? Lame :p

Also, I wonder if this is force of habit, but the nulling of your trigger is not necessary.

JASS:

library OnExtraText requires DamageSystem

//...

public function InitTrig takes nothing returns nothing
    local trigger trg = CreateTrigger()
    call TriggerAddAction(trg, function Actions)
    call TriggerAddCondition(trg, Condition(function Conditions))
    call TriggerRegisterDamageEvent(trg)
    set trg = null
endfunction
endlibrary

But you are probably right about just declaring damage types in your system. It's useful for certain reasons, and detrimental for fewer.

[Rising_Dusk]

You could actually declare them externally if you made some public variable that counts the number of damage types. The reason I didn't add such a variable is because it wouldn't be useful at all internally to the system, though I might add it for kicks. Then you could always get the "next index" without any trouble or conflicts, increment it, and declare your damage type variables anywhere you want to.

[Here-b-Trollz]

It would function essentially the same way as H2I on a new location, but I suppose it would be cleaner to use a public function (since all these 'add-ons' would be made specifically for this system anyway).

[Rising_Dusk]

Of course not, but then again the system doesn't even require either of those spells being triggered since it adjusts for the Blizzard ones anyways.

[Rising_Dusk]

Originally Posted by Litany

You can do crits with the animation (calculate whether the unit will crit in advance, add the animation tag, and then remove it after damage is dealt unless the next attack will also crit), but I don't remember if it works for evasion.

The problem with that is if you stop the attacks before they hit, the 'next attack' will always result in a crit, so it becomes predictable. I guess you could register the attack event and then recalculate the crit chance if that fires, but at this point it sounds like a system in and of itself just to trigger critical strike and like a serious pain in the ass to deal with. Sounds doable, however, which is valuable in itself.

It probably wouldn't work for evasion at all, though, unless you had a system to trigger projectiles and attacks in general. I find both of those to be quite outside of the scope of this system, but still all valid points to consider for the future.

Might be worth it to invest in a "Triggered Critical Strike System" some day. Hrm.

[grim001]

Originally Posted by Litany

Evasion has a similar hurdle in the sound of the attack hitting.

You can remove the attack sounds from every unit in the map, then trigger them when hits are successful.

I don't think a "Triggered Critical Strike System" is a good idea, proper handling of critical strike and evasion seem like two important areas for the damage detection system itself to tackle, or at least enable the user to handle.

[cohadar]

Systems that require that you do all thing custom to adjust to them can hardly be called systems.

ORBEngine is better because it does all the things mentioned here and you don't have to make all spells custom, just the ones that you want to treat specially.

[Rising_Dusk]

Originally Posted by Litany

I forget when exactly it's determined whether or not an attack is evaded, but I seem to remember it being early on.

It's right when the attack is started, since projectiles swerve to the evading unit's feet at that point if it's going to be a miss.

Originally Posted by cohadar

ORBEngine is better because it does all the things mentioned here and you don't have to make all spells custom, just the ones that you want to treat specially.

But you have to use orbs, which interfere with basic WC3 abilities like 'Lightning Attack', so my units can't shoot lightning bolts for projectiles if I use an orb system. In addition, some people may find a use for being able to use standard orb abilities, since using an orb engine they would have to make them themselves. Plus, many maps have to trigger all spells anyways for some internal reason, so in their cases there is zero reason to ever use the orb systems.

[cohadar]

Originally Posted by Rising_Dusk

But you have to use orbs, which interfere with basic WC3 abilities like 'Lightning Attack', so my units can't shoot lightning bolts for projectiles if I use an orb system. In addition, some people may find a use for being able to use standard orb abilities, since using an orb engine they would have to make them themselves. Plus, many maps have to trigger all spells anyways for some internal reason, so in their cases there is zero reason to ever use the orb systems.

No you don't have to use orb's.
Only unit that has orb-like attack needs to use orb, all other can use what ever they like.

You seem to be under the wrong impression that ORBEngine automatically gives orb attack to all units on map like some older dd systems..

And it does not stand to reason that you can be bothered to use all custom spells but be too lazy to make your own custom orb attacks....

This really is not a system but a personal approach to mapping.
One of biggest quality measures for systems is self sufficiency aka encapsulation.

[Rising_Dusk]

Originally Posted by cohadar

You seem to be under the wrong impression that ORBEngine automatically gives orb attack to all units on map like some older dd systems..

Then it doesn't detect the attack damage of all units on the map -- This system does detect the attack damage of all units on the map without any orbs at all. That in itself is a huge merit, surely you can see that.

Originally Posted by cohadar

This really is not a system but a personal approach to mapping.
One of biggest quality measures for systems is self sufficiency aka encapsulation.

Just like storage systems require users to store references to objects using a specific function call, this system requires users to deal damage to units using a specific function call. All that has changed is the application of said call, and as such your comments make little logical sense to me.

Originally Posted by cohadar

And it does not stand to reason that you can be bothered to use all custom spells but be too lazy to make your own custom orb attacks....

That is too particular-to-a-specific-map of a claim to be subjective relative to this discussion. I can think of several applications where it would be very much easier to code all of the custom spells in a map than to code all orb abilities for a map. (Tower Defenses come to mind)

[Vexorian]

Orb method: Trigger all your orbs.
This method: Trigger all your abilities.

They sort of look the same to me.

[Rising_Dusk]

Like I said, depends on the map, for some it might be less work to code abilities, for another it might be less work to code orbs. It's just in some cases maps may be using fully triggered spells anyways, whereas I can't think of an actual use for triggered orb abilities except to adjust for orb damage detect methods. That point, although valid, really doesn't have any value relative to the discussion at hand, though.

[Vexorian]

You need to trigger orbs to make them stack correctly which was about the first actual use for attack detection I had.I really think both solutions are quite demanding, hence I think I might remake the original attackdetect engine which was merely an approximation... Regarding the system itself, its implementation is not bad, but I'd like to see UnregisterDamageEvent to either become O(1) or get out of there, before I approve it. Perhaps log(n) is good enough.

[Rising_Dusk]

I need to find the index of a trigger in an array knowing nothing but the trigger itself. I can't think of any other way to do it while still taking the trigger as the only argument. I mean, I could make the RegisterDamageEvent return the index integer and then force the user to use that returned integer upon Unregistering. That kind of ebbs away from the simple syntax I was aiming for though, do you have any other ideas?

[Vexorian]

returning an index is not going to work, you would need to return a reference pointer, and probably use a linked list instead of an array.

Anyway, if the user is doing something that requires to remove the trigger, his code is already quite complicated, saving the node would be as complicated for him as saving the trigger.


You could also get rid of that function...

There should be a way to invent syntax to allow the definition of damage types in compile time without having to modify your library. A compile-time allocator for structs should help.

JASS:

struct a
endstruct

globals
    constant a A_TYPE_MYDAMAGE1 = a.create()
    constant a A_TYPE_MYDAMAGE2 = a.create()
endglobals

JASS:

globals
    constant integer A_TYPE_MYDAMAGE1 = 1
    constant integer A_TYPE_MYDAMAGE2 = 2
endglobals

edit: perhaps with something like enums, but being able to declare new values outside the library holding the enum is necessary, hmnn