- Joined
- Mar 27, 2012
- Messages
- 3,232
This post will be hard to understand for most people. I'm aware of it and can't change that.
I've so far mainly used lfh's damage detection. As such, I will use it as a reference. I believe I've found a way to fix a crucial issue with how it works.
The current design allows setting handlers to damage events in general, which always run after the fact. This is fine for GUI resources as an event, but breaks down in any attempts to make more complex systems.
To support recursion, it has a special function to be used inside events. There are some cases though where it can not be known whether a damage event is currently running. For instance, consider a custom buff system. Within that system some buff deals damage upon being removed. Among the ways to remove buffs are at least those two: A spell that clears buffs and a basic attack modifier. In this case it's impossible to know which function to use.
The solution is to not consider triggered damage after the fact. This brings up a problem - How to make sure that custom system variables are passed correctly to the handler? For instance, if I want to tag damage events with tags such as "DoT" and "AoE", I'd have to have a way to apply them on a specific damage event. If the damage simply waited until a current event stopped running, things would break once again.
The solution is to have the damage handler run instantly. However, this could break the previously running event. As such, the solution is impossible with the current design.
What to do though? Index the events and provide a function that allows creating and running a damage handler instantly, even if it can't be applied right away. This can potentially create a problem once again - Tags such as DoT and AoE have to be set every single time, even if they are not used. This necessitates having some more complex kind of handling. That is, damage events have to be extendable in the way that upon creating a new damage event, the data from its previous(expired) state is flushed. There's an inherent lack of knowledge from the system's perspective, because stuff like this has to be extendable.
This can be achieved in 2 ways - methods that can be registered or a hashtable. The upside of using methods is that it can potentially be very fast. The upside of a hashtable is that hashtable values can be flushed without any regard for how many there are or what they contain.
I consider the hashtable approach much more extendable, despite possibly being slower.
With a complex system like I'm proposing there come 3 possible use-cases that are hard to appease.
1. A vJASS poweruser who wants full control over how stuff works.
2. A person that understand very little beyond GUI and just wants some basic damage modification functionality.
3. A mix of the above, who wants the system to be melee-friendly, while still providing the customization of #1 as an optional feature.
I believe all those can be supported within the same system without excessive setup.
The architecture of the system would be as follows:
*All units are automatically set up to detect damage received, like in all DD systems. The damage events are indexed in a hashtable to provide support for multi-instancing.
*All damage is indexed in the same way, with non-triggered damage being passed to the damage handler when it appears.
*Triggered damage is called through a special function in order to separate it from any melee-friendly stuff. However the damage goes through the same handler, with merely a single flag set to determine that it's triggered.
*Damage event instances can be created, handled and applied at different times. The reason for this is to allow adding tags or other data to triggered damage events before the fact.
Non-triggered damage is handled in one piece.
Key differences to lfh's system(the one I've used the most):
*Damage events are indexed, granting support for multi-instancing that doesn't fully exist in his system.
*Dealing triggered damage can be optionally spread into multiple functions in order to attach data before the handler runs.
*All damage events can be handled instantly without breaking recursion. Damage can be applied at a later time if any problems are found with applying it instantly.
*The minimum amount of configuration remains the same, but with added optional functionality and fixing multi-instancing.
I've so far mainly used lfh's damage detection. As such, I will use it as a reference. I believe I've found a way to fix a crucial issue with how it works.
The current design allows setting handlers to damage events in general, which always run after the fact. This is fine for GUI resources as an event, but breaks down in any attempts to make more complex systems.
To support recursion, it has a special function to be used inside events. There are some cases though where it can not be known whether a damage event is currently running. For instance, consider a custom buff system. Within that system some buff deals damage upon being removed. Among the ways to remove buffs are at least those two: A spell that clears buffs and a basic attack modifier. In this case it's impossible to know which function to use.
The solution is to not consider triggered damage after the fact. This brings up a problem - How to make sure that custom system variables are passed correctly to the handler? For instance, if I want to tag damage events with tags such as "DoT" and "AoE", I'd have to have a way to apply them on a specific damage event. If the damage simply waited until a current event stopped running, things would break once again.
The solution is to have the damage handler run instantly. However, this could break the previously running event. As such, the solution is impossible with the current design.
What to do though? Index the events and provide a function that allows creating and running a damage handler instantly, even if it can't be applied right away. This can potentially create a problem once again - Tags such as DoT and AoE have to be set every single time, even if they are not used. This necessitates having some more complex kind of handling. That is, damage events have to be extendable in the way that upon creating a new damage event, the data from its previous(expired) state is flushed. There's an inherent lack of knowledge from the system's perspective, because stuff like this has to be extendable.
This can be achieved in 2 ways - methods that can be registered or a hashtable. The upside of using methods is that it can potentially be very fast. The upside of a hashtable is that hashtable values can be flushed without any regard for how many there are or what they contain.
I consider the hashtable approach much more extendable, despite possibly being slower.
With a complex system like I'm proposing there come 3 possible use-cases that are hard to appease.
1. A vJASS poweruser who wants full control over how stuff works.
2. A person that understand very little beyond GUI and just wants some basic damage modification functionality.
3. A mix of the above, who wants the system to be melee-friendly, while still providing the customization of #1 as an optional feature.
I believe all those can be supported within the same system without excessive setup.
The architecture of the system would be as follows:
*All units are automatically set up to detect damage received, like in all DD systems. The damage events are indexed in a hashtable to provide support for multi-instancing.
*All damage is indexed in the same way, with non-triggered damage being passed to the damage handler when it appears.
*Triggered damage is called through a special function in order to separate it from any melee-friendly stuff. However the damage goes through the same handler, with merely a single flag set to determine that it's triggered.
*Damage event instances can be created, handled and applied at different times. The reason for this is to allow adding tags or other data to triggered damage events before the fact.
Non-triggered damage is handled in one piece.
Key differences to lfh's system(the one I've used the most):
*Damage events are indexed, granting support for multi-instancing that doesn't fully exist in his system.
*Dealing triggered damage can be optionally spread into multiple functions in order to attach data before the handler runs.
*All damage events can be handled instantly without breaking recursion. Damage can be applied at a later time if any problems are found with applying it instantly.
*The minimum amount of configuration remains the same, but with added optional functionality and fixing multi-instancing.
