ThisPOT's Teleport System V:2

[Daffa]

A big improvement is to make multiple different teleport abilities behave differently.

 

[alves]

Suggestions:

Possibly, you could add the ability to attach multiple special effects on the unit and the target point. The ability to cancel the initial cast so the casting unit doesn't gets teleported to the location.

Else, well done you killing it with the system you made there! +REP

 

[ThisPOT]

A big improvement is to make multiple different teleport abilities behave differently.

That's what I'm trying to do
If you have any suggestions on how to do that even more please let me know and I will add it asap!

New
Suggestions:

Possibly, you could add the ability to attach multiple special effects on the unit and the target point. The ability to cancel the initial cast so the casting unit doesn't gets teleported to the location.

Else, well done you killing it with the system you made there! +REP

Will do asap! These are good ideas. I will add a possibility of 2 Special Effects for caster and ground effect, and add 2 more for the moment when the teleport happens at the position of the caster and the position of the teleport.

+ the possibility of changing Cast Delay to Channeling Time if you want to (which gets interrupted by stuns or changing the order of the unit in general)


EDIT: Added everything and uploaded new version

 

[Daffa]

A way to catch state of teleportation is a further deep down the line, so player can do after-teleport and pre-teleport effects.

 

[MyPad]

This looks like an aspiring GUI version of CustomTeleport. Perhaps @Spellbound has some insights as to how this is done.

At a glance, I think this is spell-based, and not unit-based. (When spell-based, everything about the spell is the same for all units having that ability, while when unit-based, each unit stores different data about the ability).

As preview trigger is not working at the moment, I will release a review once I test this.

 

[ThisPOT]

At a glance, I think this is spell-based, and not unit-based. (When spell-based, everything about the spell is the same for all units having that ability, while when unit-based, each unit stores different data about the ability).

I didn't realize that people would need to have specific stats depending which unit casts it, but regardless, it would be a very easy fix that would just require a few filters and moving a few things around. I didn't think this was needed, but since you are asking I will fix this too !

PS: It can still be spell based.

 

[Spellbound]

This appears to be a teleport a-la Scroll of Town Portal except it only takes the caster. It seems competent in what it does but I have noticed a couple of quirks such as the teleport effect not always being centered on the object you are teleporting to. Additionally, when trying to teleport to a building when there is none will teleport on to the building closest to the target point, even if it's nowhere near it (probably further than 4000 units). I'm not sure if that's intentional or not but other types of teleport when there were none of the required objects were nearby failed to execute.

 

[ThisPOT]

It seems competent in what it does but I have noticed a couple of quirks such as the teleport effect not always being centered on the object you are teleporting to.

That is the accurate TP stat (if cast within a radius of a valid target, will teleport directly to that spot instead of the target location).

Additionally, when trying to teleport to a building when there is none will teleport on to the building closest to the target point, even if it's nowhere near it (probably further than 4000 units).

That is the grab stat (how far from cast point do we look for a target, and building was set to 99999).

I'm not sure if that's intentional or not but other types of teleport when there were none of the required objects were nearby failed to execute.

That's because every teleport in this demo is set to have different stats and thus behaves differently .

 

[MyPad]

Based on Spellbound's inputs, I had removed the system tag from the bundle, if its' alright with you. If not, feel free to add it back again.

 

[ThisPOT]

Based on Spellbound's inputs, I had removed the system tag from the bundle, if its' alright with you. If not, feel free to add it back again.

I think you're right, it's technically just a few spells.

 

[ZiBitheWand3r3r]

1.Teleport to point can bug unit by stuck on the cliffs.
2.Issuing "smart" order during channeling will not cancel teleport as it should.
3.No need to use hashtable if you're using unit indexer in my opinion.
Please rething whole teleport code. The current state of your submission is not approvable.

I'm unable to see triggers using "Preview triggers" it throws me an error: "A server error occurred. Please try again later."

 

[ThisPOT]

1.Teleport to point can bug unit by stuck on the cliffs.

I was not able to replicate this bug, are you sure? ☑Fixed

2.Issuing "smart" order during channeling will not cancel teleport as it should.

I will fix that asap! ☑Fixed

3.No need to use hashtable if you're using unit indexer in my opinion.

Hashtables take less room so I use them instead of variables when it makes sense, how would you do it? All variable arrays? ☑Fixed

Also, how do you refer to the unit in question in the hashtable without assigning them an ID?

I'm unable to see triggers using "Preview triggers" it throws me an error: "A server error occurred. Please try again later."

That's a hive error I believe.

 

[ZiBitheWand3r3r]

You can consider this 2 triggers to track "isUnitChanneling"

function Trig_Unit_StartChannel takes nothing returns boolean       
    set g_unitChanneling[GetUnitUserData(GetTriggerUnit())] = true       
    return false
endfunction
function Trig_Unit_EndChannel takes nothing returns boolean       
    set g_unitChanneling[GetUnitUserData(GetTriggerUnit())] = false       
    return false
endfunction
    set t=CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_SPELL_CHANNEL) //triggers to set boolean variable "g_unitChanneling[unit user data]"
    call TriggerAddCondition(t, Condition(function Trig_Unit_StartChannel))
    set t = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_SPELL_ENDCAST)
    call TriggerAddCondition(t, Condition(function Trig_Unit_EndChannel))

I am using dummy-blinker unit with "blink" ability to find nearest walkable location. It's not elegant solution but simple, and always works. I got item in my map named "teleportation wings" that can teleport caster to the targeted point. If you're interested you can look at the code. It is trigger action code and uses waits.

Spoiler: code

function Trig_StaffOfTeleportation_OnCast takes nothing returns nothing
    local unit u=GetTriggerUnit()
    local real x=GetUnitX(u)
    local real y=GetUnitY(u)
    local real Tx=GetSpellTargetX()
    local real Ty=GetSpellTargetY()
    local integer counter=0
    local boolean ok=true
    local boolean targetPointOk=true
    local timer t=null
    local effect eff1=null
    local unit blinker=CreateUnit(Player(PLAYER_NEUTRAL_PASSIVE), 'h00L', Tx, Ty, 0.00)
   
    if IssuePointOrder(blinker, "blink", Tx+1.00, Ty+1.00) then
    elseif IssuePointOrder(blinker, "blink", 0.00, 0.00) then
        //blink ok --> current position walkable :) --or-- //blink ok
    else  //blink failed...interrupt!
        set targetPointOk=false
    endif
   
    if targetPointOk then
        set eff1=AddSpecialEffect("Abilities\\Spells\\Human\\MassTeleport\\MassTeleportTo.mdl", x, y)
        set t=CreateTimer()
        call TimerStart(t, 4.00, false, null)
        loop
            exitwhen TimerGetRemaining(t)<=0.00
            if (not UnitAlive(u)) or (not UnitChanneling(u)) then
                call Msg(GetOwningPlayer(u), "Teleportation interrupted.")
                set ok=false
                exitwhen true
            endif
            if counter==3 then //read target coords
                set Tx=GetUnitX(blinker)
                set Ty=GetUnitY(blinker)
            endif
            set counter=counter+1
            call TriggerSleepAction(0.20)
        endloop
        call DestroyEffect(eff1)
        call DestroyTimer(t)
        set t=null
    endif
   
    if targetPointOk and ok then
        call RemoveUnit(blinker)
        call DestroyEffect(AddSpecialEffect("Abilities\\Spells\\Human\\MassTeleport\\MassTeleportCaster.mdl", x, y))
        call DestroyEffect(AddSpecialEffect("Abilities\\Spells\\Human\\MassTeleport\\MassTeleportTarget.mdl", Tx, Ty))
        call SetUnitPosition(u, Tx, Ty)
        //call MsgDev("caster succefully "+I2S(counter))
    elseif not targetPointOk then
        call Msg(GetOwningPlayer(u), "Teleportation failed.")
        call TriggerSleepAction(1.00)
        call BlzEndUnitAbilityCooldown(u, ABI_ITEM_TELEPORTATION_WINGS)
    endif
   
    call RemoveUnit(blinker)
    set blinker=null
    set eff1=null
    set u=null
endfunction

Hashtables take less room so I use them instead of variables when it makes sense, how would you do it? All variable arrays?

yeah, just use UnitUserData aka Custom Value of Unit as a parameter

I was not able to replicate this bug, are you sure?

It bugs caster after 3rd or 4th cast on the cliff.

 

[ThisPOT]

yeah, just use UnitUserData aka Custom Value of Unit as a parameter

Is this possible using only GUI? If so how would I find that Integer (I'm assuming its an Integer but I don't know).

 

[ZiBitheWand3r3r]

that's your own code:

• TPTP Target Unit
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to TPTP_Ability_Unit
  • Actions
    • ...
    • Hashtable - Save (Custom value of TPTP_TargetUnit) as 1 of (Custom value of (Triggering unit)) in TPTP_Hash

yourVariable[Custom value of Unit]
Most importand is a way, you will choose to determine walkable location at teleport target point. There is "TerrainPathability" library by Rising_Dusk, (MAX_RANGE in this lib can be greatly increased and tested if this meets your expectations)
Simple "Move unit to the location" GUI action will not guarantee that unit will land on the proper point.

 

[ThisPOT]

Gotcha, I'll fix that then as you suggested. ☑Fixed

So it's ok to just use variable arrays for everything? 5 year ago people were saying it's slow and clunky which is why I was using hashtables, I've been away a bit ^^...

 

[MyPad]

Notes:

• All of the handler triggers (TPTP Target <Object>) are similar in functionality. Why not consolidate them into a single trigger with a condition statement filtering out the usage of certain abilities?
• Unit Indexer (Bribe) should be replaced with the current Unit Event (also by Bribe), since it does the same thing, with more features, and is future-proof, as it is being actively maintained.
• Repeated function calls to (Triggering Unit) have been spotted. Assign it to a variable to optimize performance.
• Variable count should be minimized, as many of these do not need to be individualized to their own space. Use a more generic array variable in their place.
• If-then branches could be minimized with the usage of the Or logical operator, available in GUI. That being said, repeated actions can be simplified.
• Nested-ifs could be avoided for additional readability, but when it makes sense. Case in point:
  
  • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    • If - Conditions
      • (Load 2 of (Custom value of (Picked unit)) from TPTP_Hash) Equal to 1
    • Then - Actions
      • Special Effect - Create a special effect at TPTP_Point_4 using TPTP_Effect_Go_Unit
    • Else - Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • (Load 2 of (Custom value of (Picked unit)) from TPTP_Hash) Equal to 2
        • Then - Actions
          • Special Effect - Create a special effect at TPTP_Point_4 using TPTP_Effect_Go_Building
        • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • (Load 2 of (Custom value of (Picked unit)) from TPTP_Hash) Equal to 3
            • Then - Actions
              • Special Effect - Create a special effect at TPTP_Point_4 using TPTP_Effect_Go_Item
            • Else - Actions
              • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                • If - Conditions
                  • (Load 2 of (Custom value of (Picked unit)) from TPTP_Hash) Equal to 4
                • Then - Actions
                  • Special Effect - Create a special effect at TPTP_Point_4 using TPTP_Effect_Go_Point
                • Else - Actions
                  • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                    • If - Conditions
                      • (Load 2 of (Custom value of (Picked unit)) from TPTP_Hash) Equal to 5
                    • Then - Actions
                      • Special Effect - Create a special effect at TPTP_Point_4 using TPTP_Effect_Go_Destructible
                    • Else - Actions
• Unit group filtering method is not optimal.
  
  
  • Set TPTP_Group = (Units within TPTP_GrabRadius_Unit of TPTP_Point_2 matching ((((Owner of (Matching unit)) Equal to (Owner of (Triggering unit))) or (((Matching unit) belongs to an ally of (Owner of (Triggering unit))) Equal to True)) and ((((Matching unit) is A structure) Eq...
  I suggest the following link on how to optimize group filtering (readability and performance-wise): Convenient Unit Group Filtering in GUI

Suggestions:

• Upon the effect of the spell, should the (Triggering Unit) be issued to stop, the manacost is not refunded. Why not give an option to refund it?
  

Status:

• Awaiting Update

 

[ThisPOT]

All of the handler triggers (TPTP Target <Object>) are similar in functionality. Why not consolidate them into a single trigger with a condition statement filtering out the usage of certain abilities?

I'm not sure I understand, could you please explain a little more?

Unit Indexer (Bribe) should be replaced with the current Unit Event (also by Bribe), since it does the same thing, with more features, and is future-proof, as it is being actively maintained.

Awesome, I didn't know about this, will do immediately. ☑Fixed

Repeated function calls to (Triggering Unit) have been spotted. Assign it to a variable to optimize performance.

Understood, will do. ☑Fixed

Variable count should be minimized, as many of these do not need to be individualized to their own space. Use a more generic array variable in their place.

If you could elaborate on this as well pls ^^... or give an example.
Do you mean to just do like Chanelling[1] is for units, Chanelling[2] is for buildings, etc?
If so the reason I didn't do that is just to make it easier on the eyes for users to change stats, is that a bad idea?

Nested-ifs could be avoided for additional readability, but when it makes sense. Case in point:

I have a question about this one, is it best to make it run another trigger with a bunch of skip actions and no nested-ifs?

Unit group filtering method is not optimal.

• 
  Set TPTP_Group = (Units within TPTP_GrabRadius_Unit of TPTP_Point_2 matching ((((Owner of (Matching unit)) Equal to (Owner of (Triggering unit))) or (((Matching unit) belongs to an ally of (Owner of (Triggering unit))) Equal to True)) and ((((Matching unit) is A structure) Eq...

I suggest the following link on how to optimize group filtering (readability and performance-wise): Convenient Unit Group Filtering in GUI

I realize I've been doing it wrong this whole time thinking it was actually a faster method lol... Thank you for the link. ☑Fixed

Upon the effect of the spell, should the (Triggering Unit) be issued to stop, the manacost is not refunded. Why not give an option to refund it?

Good idea, I'll implement that as well! ☑Fixed



PS: I uploaded a new version, not all of the fixes are implemented as I'm waiting for you to explain a bit more the parts that I don't understand.

PPS: Added a few death booleans, a destructible grabbed kill boolean, and an acquire item interrupts teleport boolean (v 2.5), removed a useless hashtable (v 2.5b), fixed a major bug when you teleported to a flying unit above a cliff (v 2.5c)

 

[MyPad]

If you could elaborate on this as well pls ^^... or give an example.
Do you mean to just do like Chanelling[1] is for units, Chanelling[2] is for buildings, etc?
If so the reason I didn't do that is just to make it easier on the eyes for users to change stats, is that a bad idea?

What you assumed is right, you can do Channeling[1], Channeling[2], and so on.

However, certain variables which you declared are not type-generic. Examples of these are the unit group variables, since they cannot be used to express a more generic group of destructables, items, locations and so on.

I have a question about this one, is it best to make it run another trigger with a bunch of skip actions and no nested-

To my understanding of that question, no. You can do what you need to do in the trigger itself.

All of the handler triggers (TPTP Target <Object>) are similar in functionality. Why not consolidate them into a single trigger with a condition statement filtering out the usage of certain abilities?

I'm not sure I understand, could you please explain a little more?

While looking at the triggers, I found out that they are very similar, too similar in what they do. Moreover, I am saying that you can pack all of your trigger actions in one trigger.

 

[ThisPOT]

However, certain variables which you declared are not type-generic. Examples of these are the unit group variables, since they cannot be used to express a more generic group of destructables, items, locations and so on.

Ok, I understand which variables you're talking about. My worry was that the timer could run at the same time as other triggers, creating issues. Does that happen in warcraft 3? Or am I safe using the same generic variables in cast trigger and in timer triggers?

While looking at the triggers, I found out that they are very similar, too similar in what they do. Moreover, I am saying that you can pack all of your trigger actions in one trigger.

I tried consolidating them a little but the problem is that they are all slightly different, but I am sure I can pack them more. I will do that asap.

EDIT: Actually, if question 1's answer is that it's safe, I will be able to pack them way more.

 

[MyPad]

My worry was that the timer could run at the same time as other triggers, creating issues. Does that happen in warcraft 3? Or am I safe using the same generic variables in cast trigger and in timer triggers?

Everything in Warcraft 3 is sequential. That means no two actions can run at the same time, yet they can run at the same time-frame.

function b(int v) returns v
    return v*v

function a() returns v
    v = b(2)
    return v

a()

In the example above, a() is called on some piece of code. While a() is running, a value "v" is defined as the result of b(2). When calling function b(), the thread in a() is paused, and b() is run. After reaching the return point, a() continues up until its' return point, returning 4.

 

[ThisPOT]

Awesome, thank you so much for all that info. New version coming up Sunday afternoon-ish.

 

[Daffa]

If you use Hashtables, I suggest don't merge them with Unit Indexer as that makes things much more complicated for no real benefit in terms of efficiency. A good practice is to use a variable with constant integer value for key of hashtable, so you can remember which key does what.

 

[Dr Super Good]

Comments and Suggestions:

Potentially useful as a template for teleport related abilities. Includes functionality for most common teleport events such as channel interrupt or mana refund.

Overall spell and system layout could be better. Currently all variants of the teleport are coupled together and fed hard coded values. This makes it hard to customize in the case the user wants two differently configured versions of the same teleport variant or if they do not need one or more of the available variants. Maybe something could be done to allow data to be fed in from a set of arrays which number of indices used are the number of configurations, a form of data feeding.

As pointed out by MyPad there is quite a bit of code duplication. It might be possible to reduce the entire system into a single trigger with branching logic based on configuration. Would also go well with a data fed approach.​