Hosted Project GR
- Joined
- Sep 17, 2009
- Messages
- 7,234
I created this post as some kind of mirror to a system that was already approved in the spells section for practical reasons.
As the system is clearly a system and not a spell, this might be irritating for some people. That's why I think it should be added to the JASS section of hiveworkshop.
I'm talking about this one:
http://www.hiveworkshop.com/forums/spells-569/zwiebelchens-threat-system-2-5-a-156179/
What is a threat system?
Basicly, it's a system that takes over Mob AI. The unit that dealt the most damage to the creep will be the one that gets attacked.
Although that is only half the truth, it should be enough to get the idea.
ZTS is the easiest to use and most stable threat system currently available on the web.
Requirements:
- vJass preprocessor
What is different from this to other systems:
- First of all, this system is almost (if not completely) 100% fail-safe. It does checks on killed AND removed units and clears them automaticly.
- Second, it features a unique camp squad functionality, which ensures that units that are preplaced in camps will always attack and return together. If units return, they will be rendered invulnerable until they reach their original camp position again. If they can not reach their camping position within a certain duration, they will get instantly teleported back.
Like this, there is almost no more kiting or bug-abusing possible, as it was with other systems.
- Third: It does not block other Spellcasting systems. The system will only give orders to units, if the unit either has no order (i.e. auto-engage) or an "attack" order. If you want the unit to use a spell instead of attacking, you can do so whenever you want without having to fear interference of the system.
In fact, there is a special function provided so that people can create their own Spell-AI directly in a custom trigger
- Fourth: It provides a lot of useful functions and Getters (Like ApplyHealThreat or GetCombatState), to make triggering spells even more easy.
- Fifth: It is, by far, the fastest and most flexible threat system out there. I completely remastered the system from the last version and the entire script (except for certain enumerations that can not be avoided) is now O(1) complexity.
Version history:
2.5
- Added a new boolean to the ZTS_AddThreatUnit command that determines wether the added unit shall be added to already fighting Creep Camps or only to non-fighting Creep Camps - this is interesting when you create encounters that summon units as you usually don't want those summoned units to create their own Creep Camp but want them to be added to the Boss' Creep Camp
- Fixed a small bug that sometimes caused linked Creep Camps
2.4
- Fixed a bug sometimes rendering units permanently invulnerable, when registering a unit in close range to currently retreating units
2.3
- Changed TriggerActions of dynamic triggers to TriggerConditions, to avoid nasty action leak
- Fixed GetThreatUnitAmount (did not return the correct value)
2.2b
- fixed a small logic bug with GetThreatUnitAmount and GetThreatUnitPosition
2.2
- Now uses "smart" order instead of "attack" to issue attack orders ... it turned out that the "smart" order returns false if the unit can not reach the target (for example when rooted) - weird, as it doesn't work for "attack" for some reason
- because of that, the AddRootAbility function and the Range Setter and Getters were removed, as they have become obsolete
2.1b
- fixed a small logical bug with GetCombatState sometimes returning a false positive
2.1
- rebuilt Update function to avoid some useless enumerations - depending on the number of PlayerUnits registered, the system should now be MULTIPLE TIMES faster - As a side effect, I could also remove some useless variables
2.0
- Initial release
Comments & Discussion:
Why hashtables instead of global arrays and structs?
- hashtables are not limited in terms of max size, unlike and array of structs with a unit array, which reaches the 8000 limit very fast ... this was basicly the most important point on that decision
- hashtables are more flexible and easier to use (Flush functions, etc.)
- hashtables were benchmarked to be only 60-80% slower than getting UnitUserData alone
Where is the sort function?
- version 2.0 and higher does not use sorting anymore; instead, when threat is applied to a unit, it uses an insertion method to keep the order of the list
What is new compared to pre 2.0 versions?
- Aside from the fact that the system now is a dozen times faster than before, I also improved the AI by using the "smart" instead of "attack" order. It turned out that - in a weird way - "smart" is indeed smarter than other orders, as it returns false if the unit can't reach the target (i.e. because of root)
- There is now a way to directly get an Order event by the threat system, to make creating spell-AI easier.
Does it matter how many units are registered to the system at the same time?
- In terms of speed, no; it only affects memory usage, but that should not have an impact on game performance at all, even with tousands of units registered - only the number of currently fighting units affects runtime
I still do not really understand how to use the system...
- just check the demo map and you'll get the idea
CODE:
As the code is too long, I decided to not include it in this post.
You should check the demomap anyway.
As the system is clearly a system and not a spell, this might be irritating for some people. That's why I think it should be added to the JASS section of hiveworkshop.
I'm talking about this one:
http://www.hiveworkshop.com/forums/spells-569/zwiebelchens-threat-system-2-5-a-156179/
What is a threat system?
Basicly, it's a system that takes over Mob AI. The unit that dealt the most damage to the creep will be the one that gets attacked.
Although that is only half the truth, it should be enough to get the idea.
ZTS is the easiest to use and most stable threat system currently available on the web.
Requirements:
- vJass preprocessor
What is different from this to other systems:
- First of all, this system is almost (if not completely) 100% fail-safe. It does checks on killed AND removed units and clears them automaticly.
- Second, it features a unique camp squad functionality, which ensures that units that are preplaced in camps will always attack and return together. If units return, they will be rendered invulnerable until they reach their original camp position again. If they can not reach their camping position within a certain duration, they will get instantly teleported back.
Like this, there is almost no more kiting or bug-abusing possible, as it was with other systems.
- Third: It does not block other Spellcasting systems. The system will only give orders to units, if the unit either has no order (i.e. auto-engage) or an "attack" order. If you want the unit to use a spell instead of attacking, you can do so whenever you want without having to fear interference of the system.
In fact, there is a special function provided so that people can create their own Spell-AI directly in a custom trigger
- Fourth: It provides a lot of useful functions and Getters (Like ApplyHealThreat or GetCombatState), to make triggering spells even more easy.
- Fifth: It is, by far, the fastest and most flexible threat system out there. I completely remastered the system from the last version and the entire script (except for certain enumerations that can not be avoided) is now O(1) complexity.
Version history:
2.5
- Added a new boolean to the ZTS_AddThreatUnit command that determines wether the added unit shall be added to already fighting Creep Camps or only to non-fighting Creep Camps - this is interesting when you create encounters that summon units as you usually don't want those summoned units to create their own Creep Camp but want them to be added to the Boss' Creep Camp
- Fixed a small bug that sometimes caused linked Creep Camps
2.4
- Fixed a bug sometimes rendering units permanently invulnerable, when registering a unit in close range to currently retreating units
2.3
- Changed TriggerActions of dynamic triggers to TriggerConditions, to avoid nasty action leak
- Fixed GetThreatUnitAmount (did not return the correct value)
2.2b
- fixed a small logic bug with GetThreatUnitAmount and GetThreatUnitPosition
2.2
- Now uses "smart" order instead of "attack" to issue attack orders ... it turned out that the "smart" order returns false if the unit can not reach the target (for example when rooted) - weird, as it doesn't work for "attack" for some reason
- because of that, the AddRootAbility function and the Range Setter and Getters were removed, as they have become obsolete
2.1b
- fixed a small logical bug with GetCombatState sometimes returning a false positive
2.1
- rebuilt Update function to avoid some useless enumerations - depending on the number of PlayerUnits registered, the system should now be MULTIPLE TIMES faster - As a side effect, I could also remove some useless variables
2.0
- Initial release
Comments & Discussion:
Why hashtables instead of global arrays and structs?
- hashtables are not limited in terms of max size, unlike and array of structs with a unit array, which reaches the 8000 limit very fast ... this was basicly the most important point on that decision
- hashtables are more flexible and easier to use (Flush functions, etc.)
- hashtables were benchmarked to be only 60-80% slower than getting UnitUserData alone
Where is the sort function?
- version 2.0 and higher does not use sorting anymore; instead, when threat is applied to a unit, it uses an insertion method to keep the order of the list
What is new compared to pre 2.0 versions?
- Aside from the fact that the system now is a dozen times faster than before, I also improved the AI by using the "smart" instead of "attack" order. It turned out that - in a weird way - "smart" is indeed smarter than other orders, as it returns false if the unit can't reach the target (i.e. because of root)
- There is now a way to directly get an Order event by the threat system, to make creating spell-AI easier.
Does it matter how many units are registered to the system at the same time?
- In terms of speed, no; it only affects memory usage, but that should not have an impact on game performance at all, even with tousands of units registered - only the number of currently fighting units affects runtime
I still do not really understand how to use the system...
- just check the demo map and you'll get the idea
CODE:
As the code is too long, I decided to not include it in this post.
You should check the demomap anyway.
