Tether v1.03

[Moderator]

Submission: Tether v1.03 Date: 1.09.2015 Status: Approved Rating: 4/5 Review Link Moderator: IcemanBo

 

[Flux]

Changelog:
v1.02 [30 August 2015]
- Fixed a bug where the Tethered Unit will immediately lose its Speed Bonus when one Tether is broken and there is still an existing one.
- Tether Break will not continue to search for triggering unit index after that index was found, meaning the looping will stop.
- Tether Periodic is de-indexed directly.

v1.01 [22 August 2015]
- Tether Ability would be replaced by Break Tether Ability when currently using Tether, thus casting two Tether is no longer achievable.
- Destroyed an unused UnitGroup at Map Initialization.
- Latching Speed now configurable.
- Added some Attachment Effects on the Target and Caster
- Lightning Effect will change appearance when about to break caused by too much distance.
- Damage and Attack Type configurable.
- Lightning Movement now has Z-offset and changes height based on the target and caster's location.

v1.00 [10 August 2015]
- Initial Release

 

[jonbon29]

Nice one dude, this is perfect for my Wisp Hero XD

 

[KILLCIDE]

Looks good Shadow may I ask why you check if TimeLeft is less than 0? It would just be better to equal it to zero because the duration would never go below it, no?

• Set TeS_TimeLeft[TeS_LoopInt] Less than or equal to 0.00

 

[Flux]

Looks good Shadow may I ask why you check if TimeLeft is less than 0? It would just be better to equal it to zero because the duration would never go below it, no?

• Set TeS_TimeLeft[TeS_LoopInt] Less than or equal to 0.00

For safety I guess, so that when I or the user change the periodic timer that will not result to exactly zero (i.e. 0.03 periodic time), then I wouldn't have to bother about calculating the exact value nearest to zero.

Another reason is if the user changed the slow duration to 2.01 with periodic timer of 0.1, the time left would never be exactly zero because it would be 0.01 then -0.09.

 

[FireTiger]

Nice. Could Be Useful.

 

[Maker]

-Break tether should be added when the ability is learned
-I'm not a fan of abilties taking up two command card slots
-Give the lightning some z offset
-The visuals could be a bit better

 

[Flux]

-Break tether should be added when the ability is learned
-I'm not a fan of abilties taking up two command card slots
-Give the lightning some z offset
-The visuals could be a bit better

- Should I use Disable Ability for Players? That will make this MPI.
- Okay then, but I guess I have to use Custom scripts which users not knowing Jass may not understand.
- Like Attachment on the caster and tethered unit?

 

[Maker]

- Should I use Disable Ability for Players? That will make this MPI.
- Okay then, but I guess I have to use Custom scripts which users not knowing Jass may not understand.
- Like Attachment on the caster and tethered unit?

-No
-Doesn't matter
-The ends of the lightning are a bit pointy, they could be masked with a special effect

 

[Flux]

-No
-Doesn't matter
-The ends of the lightning are a bit pointy, they could be masked with a special effect

- Then how can I hide the other spell? Using Engineering Upgrade Ability trick?
- Okay then.
- Okay.

 

[IcemanBo]

When activating tether you can replace the ability by "Deactivate Tether" ability.
It probably anyway would make more sense if your unit only can have one target at once, because you can't differ tethers when disabling them via ability.
And what about also adding the "Disable ability" also to the second affected unit? Might be used there, too, since they are allies anyway.

With unit groups creating there is same issue as mentioned in ground charge spell.

Directly deindex in loop when conditions are true, without doing/checking anything else then for deindex.
Also directly index when the distance is too large, so the tether would break.

Index owner of caster to reduce repetive function calls in loop.

Make damage- attacktype configurable.

If a unit is already indexed in slow system, you only might modify the level and duration if needed, but not necessarily to index it again if it's close the tether again.

The "latching speed" could be configurable.

I think there could be an effect for affected enemies, or changing vortex color temporary, just something visual.

 

[ssbbssc2]

if u create a double tether and enemy unit cross them - you will have fatal error

 

[Flux]

Ohh, double Tether was not meant to be created because the cooldown was expected to be set longer than the duration, but I will fix that such that when you cast Tether while another Tether is still on, it will break the earlier Tether.
EDIT: I just tested it and it doesn't fatal error to me
EDIT AGAIN: Double Tether can no longer be created.

 

[Flux]

Done in my file, I just need to upload it and update description
EDIT: There is still some problems so I can't upload it at the moment.

When activating tether you can replace the ability by "Deactivate Tether" ability.
It probably anyway would make more sense if your unit only can have one target at once, because you can't differ tethers when disabling them via ability.

Done, Now players can't create Double Tether.

And what about also adding the "Disable ability" also to the second affected unit? Might be used there, too, since they are allies anyway.

Nah, there is no negative effect on the tethered unit so I don't see any reason why would he break Tether. It is like giving you the option to remove a positive buff.

With unit groups creating there is same issue as mentioned in ground charge spell.

Fixed. Destroyed Te_AffectedUnits at Map Init.

Directly deindex in loop when conditions are true, without doing/checking anything else then for deindex.

I don't get what you mean..

Also directly index when the distance is too large, so the tether would break.

Why? It will only decrease code readability making the trigger too long.

Index owner of caster to reduce repetive function calls in loop.

Done, the Level of Tether was also indexed.

Make damage- attacktype configurable.

Done.

If a unit is already indexed in slow system, you only might modify the level and duration if needed, but not necessarily to index it again if it's close the tether again.

Good call!

The "latching speed" could be configurable.

Done.

I think there could be an effect for affected enemies, or changing vortex color temporary, just something visual.

I attached effect and make some few changes on the lightning link effect..

 

[IcemanBo]

EDIT: There is still some problems so I can't upload it at the moment.

Is this message still up to date?
______________________________________________

With deindexing I meant it should like this:
Loop
---- If any "Deindex condition" is true then
-------- Then
------------ Deindex
-------- Else
------------ All other actions

"Deindex condtion" might be if caster/target is dead or max distance is reached, etc.
So then nothing of the "other actions" part should run. It should just directly deindex.

Currently a unit can be targeted twice or even more by tether. If done so it will ignore all other tethers when first one gets canceled.
I mean it will be still indexed, yes, but the buff will disappear as it would be not in system anymore, which is wrong.
So it should not lose buff when still in system of an other tether, or it should be forbidden to tether a tethered unit.

In the end of loop in "Tether Break" you might throw in a

Custom script: exitwhen true

... to avoid further looping after the correct index has been found.

Visuals looks better.

 

[ssbbssc2]

Ohh, double Tether was not meant to be created because the cooldown was expected to be set longer than the duration, but I will fix that such that when you cast Tether while another Tether is still on, it will break the earlier Tether.
EDIT: I just tested it and it doesn't fatal error to me
EDIT AGAIN: Double Tether can no longer be created.

i mean, if ur caster1 will cast Thther on caster2, and caster2 will cast Tether on caster1, we will have double tether. thats what i mean. also those 2 casters will have great hp and mp regeneration boost

 

[Flux]

^ Ahh, forming double Tether like that is totally legit in my opinion. Plus, I know the almost instant regeneration caused by double Tether but in my defense, it makes sense because the shared regeneration keep stacking.

 

[troylowyee]

Add an additional spell in

HEY! It would be awesome if u add an additional spell in. Its called back off!

The guardian wisp commands enemies to get away from it, doing damage around her and knocking them back to 25 units from it. If the guardian wisp has a soul mate, an explosion originates on them in addition, dealing the same damage and slowing by 25% for 2s. If an enemy would be hit by both blasts, they will only be affected by the one originating from the wisp.

Second is a spell that buffs only the wisp and the target hero.

 

[Flux]

HEY! It would be awesome if u add an additional spell in. Its called back off!

The guardian wisp commands enemies to get away from it, doing damage around her and knocking them back to 25 units from it. If the guardian wisp has a soul mate, an explosion originates on them in addition, dealing the same damage and slowing by 25% for 2s. If an enemy would be hit by both blasts, they will only be affected by the one originating from the wisp.

Second is a spell that buffs only the wisp and the target hero.

Hmmm, I will just stick to normal Tether and kinda busy at the moment.

Spell updated to v1.02

 

[IcemanBo]

Needed:

• Also destroy group[1] onInit, not only group[0].
• Don't do visuals part and location creations in periodic loop at very top.
  Only do so, if you don't deindex. If instance will deindex it is not needed.

Optional:

• The "Or - Any Conditions" in periodic trigger is not needed, if you just switch the 'Else' and 'Then' parts.
• Using the filter in "Pick every unit and do actions" operation is very long and unreadable.
  I recommend to make your own filter for these things inside the loop in GUI.

Bug was fixed, good.

 

[Flux]

Needed:

• Also destroy group[1] onInit, not only group[0].
• Don't do visuals part and location creations in periodic loop at very top.
  Only do so, if you don't deindex. If instance will deindex it is not needed.

Optional:

• The "Or - Any Conditions" in periodic trigger is not needed, if you just switch the 'Else' and 'Then' parts.
• Using the filter in "Pick every unit and do actions" operation is very long and unreadable.
  I recommend to make your own filter for these things inside the loop in GUI.

Bug was fixed, good.

• Oh right, I missed that one. Done
• Got it. Done

• If you mean use De Morgan's Theorem to prevent using OR, then it is done
• Since, it is only optional, I will not do that part. It is because the GetEnumUnit() will be called a lot more times.

 

[IcemanBo]

Oh, when unit added once to AffectedGroup it will never come out again.
So if it's standing like 30 seconds in teather lightning it will only receivce damage once, and the slow duration will also not refresh.
This is because all actions and checks will be ignored if picked unit already is in AffectedGroup.

Have not spotted any more mentionable things but this.

If you mean use De Morgan's Theorem to prevent using OR, then it is done

Yes, you have done it correctly.

 

[Flux]

It was intentional. Once you are hit, you can never be hit by he same Tether again, else it will be too overpowered

 

[IcemanBo]

Damage:
It seems a bit strange for me that time doesn't play a role at all.
For me, it would seem ok if it would take damage after a certain timeout again. - but naja ok.

Slow:
There is a part in code that you lookup for the index and then only update the TimeLeft. (instead of indexing to slow system)
But this part will never be able to run.

 

[Flux]

Damage:
It seems a bit strange for me that time doesn't play a role at all.
For me, it would seem ok if it would take damage after a certain timeout again. - but naja ok.

Slow:
There is a part in code that you lookup for the index and then only update the TimeLeft. (instead of indexing to slow system)
But this part will never be able to run.

Well it was based on an ability in Dota and that was the mechanics of that spell ( I know, I'm not creative ).

Ahh yes, that is if you are hit by Tether while you have the Slow Buff. If that happens, the timer (or duration) will only refresh but the max index of the slow system is still the same. Thus, no unit can have more than one index in the Slow System.

 

[IcemanBo]

But the structure is like this:

If (UnitIsAffected == false) then
----
---- Unit - Damage
----
---- If UnitHasSlow == true
--------
-------- Unit - Slow_Refresh
---- Else
-------- Unit - Slow_Index
----
---- Unit - AddUnit to AffectedUnits

So once it was affected the update for slow won't be able to fire anymore.

 

[Flux]

But the structure is like this:

If (UnitIsAffected == false) then
----
---- Unit - Damage
----
---- If UnitHasSlow == true
--------
-------- Unit - Slow_Refresh
---- Else
-------- Unit - Slow_Index
----
---- Unit - AddUnit to AffectedUnits

So once it was affected the update for slow won't be able to fire anymore.

Yes, but what if there are two Tethers. Tether from 1st Wisp hits Chieftain (in the test map) at time = 1.00. Then Tether from 2nd Wisp hits Chieftain at time = 1.50. Therefore, if the configured Slow Duration is for example 5 seconds, the Slow in Chieftain will be gone at time = 6.50.

 

[IcemanBo]

Oh, man, I see now what the intention is. I have not thought you only want to refresh slow in case of a new tether. Okay, good.

 

[IcemanBo]

Tether v1.03​ Date: August 1st, 2015 Concept: 3/5 Caster uses Tether to connect with an allied unit via a lightning. Both units gain movementspeed, while the tether target also gains extra HP/MP - regeneration when the caster regenerates. When enemies come in touch with the tether lightning they will receive damage and get slowed. At last the tether ends when the distance between connected units is too large, or the turn-off ability is used. It is a good concept, but allowing multiple damage or multiple slowing would make much sense to me, when brining a new, timing criteria into calculation. Also the spell is as noted not unique, but an idea from dota. Code: 4/5 Code is written well. It is MUI and leakless. I personly like it that you used a second periodic loop for your slow system, and did not put all together in one big bunch of code. The only critique one could say is the O(n) search for deindex onBreak, but actually it's okay for me here. Visuals: 3.5/5 Used effects are fitting the theme. It is nice that the teather gets red before linked units get out of range. What is missing is a special effect at an enemy unit when touching the tether, when receiving damage/gets slowed. Conclusion: Approved Rating: 4/5

 

[Eagle XI]

I was testing this in the editor and crashed with an fatal error.
Last thing i did was bind the two wisps with each other and try damage the shamans blob with the chieftain aggroing in too.
Id like to believe it has involved something with 'Purge' of Shamans as one was playing their spell animation.

 

[Flux]

I was testing this in the editor and crashed with an fatal error.
Last thing i did was bind the two wisps with each other and try damage the shamans blob with the chieftain aggroing in too.
Id like to believe it has involved something with 'Purge' of Shamans as one was playing their spell animation.

Thanks for telling me that, I'll try to recreate that. Maybe it involves something with removing buffs.

EDIT:
Doesn't happen to me at all, I tried making my own Shaman and purging the Wisps tethered together but it just doesn't crash. Maybe the problem is in your PC, perhaps it cannot handle the stacking regeneration.