System [ZTS] - Zwiebelchens Threat System

[Sevion]

No.

 

[Zwiebelchen]

Either take the version I uploaded on wc3c that uses AutoIndex (and use table AutoIndex) or rewrite your functions that use the custom user data. You should never use UnitUserData yourself anyways, since any indexing systems greatly improve the way you can work with units.

 

[Nerzhul]

So?I have to remake everything that use custom values?:banghead:

 

[Zwiebelchen]

I would recommend so. Monopolizing on UnitUserData is stupid.


BTW: Any chance of approval?

 

[Steel]

I can't recall this right now or test it at the moment but I'm pretty sure you can create a texttag for a single player using GetLocalPlayer. This would be a great way to denote how a player has threat. You could adopt the style WoW uses, yellow means you're close to pulling agro and red means you have agro.

Thoughts?

 

[Zwiebelchen]

I can't recall this right now or test it at the moment but I'm pretty sure you can create a texttag for a single player using GetLocalPlayer. This would be a great way to denote how a player has threat. You could adopt the style WoW uses, yellow means you're close to pulling agro and red means you have agro.

Thoughts?

Yeah, actually, this is quite easy to do.
All you need is to use GetThreatUnitAmount() and divide it through GetThreatSlotAmount() of position 1. There you have your percentage of threat.

 

[Zwiebelchen]

Updated the system to version 1.1, with two new features.

 

[Zwiebelchen]

Sorry for triple post; but isn't it time to approve this?

 

[soul_reaper]

Maybe a floating text or something of that king for displaying threats ?

 

[Zwiebelchen]

Can be achieved easily - the functions for that are there. I think there is no reason for me to hardcode it into the system. People want to customize their interface to their wishes, so I don't want to interfere in that.
The system provides all neccesary functions and handles all the calculations and tables. What the user wants to get out of it is, in my oppinion, not part of the system anymore.


UPDATE! v. 1.2 now available!

I made a terrible mistake in the initial code ... the remove unit checkers were NOT running properly. Instead, the dead checkers took over the processing. This made it look like the removal checkers were working, but they did not. This was due to some blizz fuck-ups with global variables not returning null if the unit was removed (the variable keeps reference even to removed units and thus, the variable is not null after removal).
Then I upgraded to a safer dead-checker, not using GetUnitState anymore.
I also fixed a bug where it was possible to apply threat to units that were returning to their camp positions.
HealUnitsOnReturn now also sets the units mana to 100%.
There was a mistake with the description ... fixed that too. (It said you need to set GuardDistance to something low ... instead, you have to set it to something higher than ReturnRange!)

The bugs with version 1.1 and 1.0 are a serious issue! Please do not use these versions anymore!

 

[Zwiebelchen]

Version 1.3 now available!

- Uses SortUtils now
- Uses AutoIndex now
- changed almost all unnecessary O(n) operations to O(1) operations
- Uses a different removal-detection method now
- overall improvements to the code

 

[Zwiebelchen]

So what about the approval process?

 

[Zwiebelchen]

Alright, I give up. Let this go to waste ...

 

[Zwiebelchen]

Updated to version 2.0!

 

[Accname]

its quite nice, cannot tell about the code because i mainly code in GUI.
however i wont use this system because of the following article:

- 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.

[Return together]
how does your system know which units belong to which camp group? if i place goblins and spiders close to each other in a wood but i dont want goblins and spiders to attack and return together because...well that would be awkward, would it be possible?
would it be possible as well to have wandering creeps around with this system?

[Rendered Invulnerable]
i dont like the idea of invulnerable creeps running around my map. lets imagine the case player one attacks the creeps and lures them out of their camp, he gets killed and the creeps returned rendered invulnerable.
Player 2 wouldnt be able to attack the creeps not until they reached their camp? this seems quite weird and annoying to me, sorry but i dislike it though i see the idea behind it.

[Teleported back]
teleported back?! lol thats pretty awkward, sorry. i understand what you wanna do with it but i just cant take the fact that my creeps will teleport around the world after a battle. i think it would be pretty annoying to rogues or ninja characters who are trying to trap them if they just teleport back.

[bug-abusing]
hm i dunno any other system so i dont know what bugs you are talking about but testing your map i saw some bugs myself. i fought a melee enemy which targeted a footman. i used ensnare with the bowmans and casted holy light with the arch mage. the enemy was now just spinning around not doing anything anymore because it tried to attack the arch mage at any cost.
i havent tried but i guess same would happen if i had alot of units standing around my arch mage and blocking that creep off.
and about kiting, well i think that might not be considered a "cheat" or "abuse" but rather a tactic of weaker fighters such as rogues or mages which will get killed by all those dmg dealing creeps if they come at once.

 

[Zwiebelchen]

Updated to Version 2.1

- removed some useless enumerations in Update function and replaced it by using events ... the system should now be multiple times faster than before

[Return together]
how does your system know which units belong to which camp group? if i place goblins and spiders close to each other in a wood but i dont want goblins and spiders to attack and return together because...well that would be awkward, would it be possible?

Well, it checks for HelpRange only. You could always add a race check to the Filter function to acchieve that.

would it be possible as well to have wandering creeps around with this system?

You can always check for the combat state of the wandering unit, and if it is false, periodically RemoveThreatUnit, followed by AddThreatUnit.

[Rendered Invulnerable]
i dont like the idea of invulnerable creeps running around my map. lets imagine the case player one attacks the creeps and lures them out of their camp, he gets killed and the creeps returned rendered invulnerable.
Player 2 wouldnt be able to attack the creeps not until they reached their camp? this seems quite weird and annoying to me, sorry but i dislike it though i see the idea behind it.

Well, actually, this is how it should be. If you want a fair game with no kiting possible, it has to be like that.
But obviously, if this is an important matter for you, you can not use this system.

[Teleported back]
teleported back?! lol thats pretty awkward, sorry. i understand what you wanna do with it but i just cant take the fact that my creeps will teleport around the world after a battle. i think it would be pretty annoying to rogues or ninja characters who are trying to trap them if they just teleport back.

This is why there is a counter for the teleporting issue. It's just to prevent players from blocking the way to the camp position or abusing root abilitys and stuns to split the groups.

[bug-abusing]
hm i dunno any other system so i dont know what bugs you are talking about but testing your map i saw some bugs myself. i fought a melee enemy which targeted a footman. i used ensnare with the bowmans and casted holy light with the arch mage. the enemy was now just spinning around not doing anything anymore because it tried to attack the arch mage at any cost.

This was due to a bug. It should be fixed with 2.1.

i havent tried but i guess same would happen if i had alot of units standing around my arch mage and blocking that creep off.

Unfortunately, there is no way to prevent that, as there is no way to find out wether the unit can actually reach the target or not.

and about kiting, well i think that might not be considered a "cheat" or "abuse" but rather a tactic of weaker fighters such as rogues or mages which will get killed by all those dmg dealing creeps if they come at once.

I guess we have a different definition of kiting. The system does not prevent "fire and run" in any way, it just orders the camp units to retreat always together, to prevent players from splitting the group by using snares, stunes, etc.
This is what I mean with kiting.


To make it short: I tried to adapt the way World of Warcraft handles threat (and for this case, it works perfectly fine). If you don't like this system, then you do not have to use it. On a huge and complicated system like this, customization is always limited.

 

[Accname]

well i would say we understand the same thing with kiting but it seems to me as if i see it as a tactical move and you as cheating.

an assassin like character has to split the enemy group to kill them one by one because he would die if they all attack him together. that would be nearly impossible in your game.
it would be impossible for 2 players to trap creeps by having a tank luring them and a rogue placing traps behind them when they come back to their camp site.
it would be impossible to chase the creeps after they won a battle against an other player (when they are now returning back to their camp)

please dont misunderstand me, i dont say your system is bad. It is as close to WoW as it could be but that doesnt mean the way WoW is doing it is good.
and you havent asked whether the community wants to use this system but for feedback which i gave.

 

[Zwiebelchen]

I'm fine with that and I understand what you mean, but, as I said, it's almost impossible to make a system like that customizable for every user, so I can not change about that stuff anymore.


EDIT:
New version 2.1b
--> fixed a small bug with GetCombatState sometimes returning a false positive

EDIT 2:
New version 2.2!
--> removed all functions related to rooting, as I found a more elegant way to deal with that

 

[Tukki]

Pretty solid system!

I've encountered a bug, though
I'm using version 2.2

The following function doesn't return the player unit's aggro, it actually returns 0.0 no matter how I use it.

public function GetThreatUnitAmount takes unit npc, unit pu returns real
    if GetUnitTypeId(npc) == 0 or IsUnitType(npc, UNIT_TYPE_DEAD) or GetUnitTypeId(pu) == 0 or IsUnitType(pu, UNIT_TYPE_DEAD) then //units dead or null
        return 0.
    elseif not HaveSavedInteger(NPClist, GetHandleId(npc), 0) and HaveSavedHandle(PUlist, GetHandleId(pu), 0) then //units not added
        return 0.
    elseif HaveSavedInteger(PUlist, GetHandleId(pu), GetHandleId(npc)) then
        return LoadReal(NPClist, GetHandleId(npc), Pos2Key(LoadInteger(PUlist, GetHandleId(pu), GetHandleId(npc))))
    endif
    return 0.
endfunction

However, if I use GetThreatUnitPosition and GetThreatSlotUnit, it returns the correct amount. I.e:

/* This return the correct value: */ 
BJDebugMsg(R2S(ZTS_GetThreatSlotAmount(target,ZTS_GetThreatUnitPosition(target,attacker))));

/* This returns the incorrect value: */
BJDebugMsg(R2S(ZTS_GetThreatUnitAmount(target,attacker)));

 

[Zwiebelchen]

Thanks for reporting that. There is a logic bug inside this function. It should be like this:

    elseif not (HaveSavedInteger(NPClist, GetHandleId(npc), 0) and HaveSavedHandle(PUlist, GetHandleId(pu), 0)) then //units not added
        return 0.

Update! Version 2.2b now available!