Are these the same thing?

[JJhonJames]

If this

• Tiger 1
• Events
  • Event - A Generic Event Happens
• Conditions
  • Any condition is met
• Actions
  • Unit - Create 1 Unit right there
  • Set U = Last Unit
  • Unit - Move U here
  • Special Effect - Create SFX

is the same thing as doing this?

• Tiger 1
• Events
  • Event - A Generic Event Happens
• Conditions
  • Any condition is met
• Actions
  • Unit - Create 1 Unit right there
  • Set U = Last Unit
  • Trigger - Run Other Trigger

• Other Trigger
• Events
• Conditions
• Actions
  • Unit - Move U here
  • Special Effect - Create SFX

Basically, if this Trigger - Run <Another Trigger Actions> is just the same thing as a Normal Action if it was in the same Trigger.

Then why would anyone use Trigger - Run another Trigger that has no Events, why not put it all in the same Trigger?

 

[Uncle]

Do you see no use for running another trigger? Or are you confused by a specific use case of it?

Separating trigger logic is how you avoid repetition in certain cases. For example, let's say you were making a Pokemon style game where the user could catch, trade, and receive pokemon (ie: an NPC gifts it to you).

• Catch Pokemon
  • Events
    • ...
  • Conditions
    • ...
  • Actions
    • Set Variable U = (The caught pokemon)
    • Trigger - Run Add Pokemon To Party (ignoring conditions)

• Trade Pokemon
  • Events
    • ...
  • Conditions
    • ...
  • Actions
    • Set Variable U = (The traded pokemon)
    • Trigger - Run Add Pokemon To Party (ignoring conditions)

• Receive Free Pokemon
  • Events
    • ...
  • Conditions
    • ...
  • Actions
    • Set Variable U = (The received pokemon)
    • Trigger - Run Add Pokemon To Party (ignoring conditions)

• Add Pokemon To Party
  • Events
  • Conditions
  • Actions
    • -------- Handle all of the logic for adding the new pokemon to your party / pc --------
    • Unit - Move U to (Center of New_Pokemon_Region)
    • Unit Group - Add U to Owned_Pokemon_Group

^ This design allows you to separate the actual adding of a Pokemon from the many different ways that you can receive one. This is called decoupling in programming and is a good way to avoid repeating yourself. Now when you update the "Add Pokemon To Party" trigger it should continue to work with the several other triggers that rely on it. In other words, update 1 central trigger instead of updating 3+ triggers. If you fail to take advantage of this design pattern then you may end up needing to edit 100's of triggers to fix a mistake or add a new feature!

But that doesn't mean you should do this with everything. Only use it where you see a lot of dependencies and potential repetition. The moment you start repeating yourself you should be asking the question, "Should I decouple this? How can I make this scale better?". Then you should think about this method, along with Arrays, Hashtables, and other tools that can make your life easier.

 

[JJhonJames]

So you would just use it in case you have more than one Trigger that does the same thing, but instead of repeating Actions in every Trigger, you would just make one Trigger with the Actions and then every other Trigger that would do the same thing just "Trigger - Run That Trigger".

I got confused because I got a Resource from Hiveworkshop that the Dummy Creation was handled by a Trigger like that, with no Event. The casting Trigger would just "Trigger - Run the Dummy Creation". So that's why I asked, because I've never seen people actually create the Dummy Unit like that, I'm used to the basic creating a Dummy in the Casting Trigger, because you wouldn't use more than one Spell to Run that Dummy Creation Trigger, like, Ability X calling the "Trigger - Run Dummy Creation" and Ability Y calling the same "Trigger - Run Dummy Creation", otherwise you would get Variables incompatilibities, right? Because they are two different abilities? Or am I spitting the biggest stupidity ever. Consider my Triggering abilities WAYY too limited.

 

[Uncle]

So you would just use it in case you have more than one Trigger that does the same thing, but instead of repeating Actions in every Trigger, you would just make one Trigger with the Actions and then every other Trigger that would do the same thing just "Trigger - Run That Trigger".

Yes, it's to avoid creating more work for yourself. It's also a nice way to organize things. You could come back to the map after taking a 1 month break and think, where is my trigger that creates the Pokemon? If you have ONE trigger that handles that it should be much easier to find and you'll be happy that you took the time to organize things this way.

I got confused because I got a Resource from Hiveworkshop that the Dummy Creation was handled by a Trigger like that, with no Event. The casting Trigger would just "Trigger - Run the Dummy Creation". So that's why I asked, because I've never seen people actually create the Dummy Unit like that, I'm used to the basic creating a Dummy in the Casting Trigger, because you wouldn't use more than one Spell to Run that Dummy Creation Trigger, like, Ability X calling the "Trigger - Run Dummy Creation" and Ability Y calling the same "Trigger - Run Dummy Creation", otherwise you would get Variables incompatilibities, right? Because they are two different abilities?

Some people use special Dummy systems, like Dummy recyclers where they reuse the same Dummy unit over and over again instead of always Creating/Removing a new one.

I'd have to see exactly what they're doing in that resource, but it sounds like they're adding more work than necessary. You'll need to Add a different ability, set a different Owner, and set a different Expiration Timer for the Dummy unit, so running a Trigger doesn't really make sense unless it was part of some more elaborate system like I just described.

Anyway, your method of handling the Dummy stuff is very common and usually fine. But here are some things to think about:

1) Dummy units are a separate unit from the caster, meaning they fire Damage Events and receive kill credit (Killing unit) in Death Events instead of the caster. This may cause problems in your other triggers that rely on those Events.

2) Dummy units may cause issues if they expire too early, for instance a 15 second Entangling Roots might last longer than the Dummy unit's lifetime - which could cause Event Responses to fail (the source of entangling roots has been removed from the game).

3) Let's say your Hero has an Item that says "Your abilities deal 20% more damage", this likely won't work if your Dummy unit is the one dealing the damage. It'd be way more convenient if your Hero was always the source of all of it's damage or if you had a system which could "redirect" the damage that your Dummy deals in a way that treats the Hero as the one dealing it.

 

[Pyrogasm]

I'd have to see exactly what they're doing in that resource, but it sounds like they're adding more work than necessary. You'll need to Add a different ability, set a different Owner, and set a different Expiration Timer for the Dummy unit, so running a Trigger doesn't really make sense unless it was part of some more elaborate system like I just described.

Could be config variables set before running the trigger. Could also be separated to be modular, so the user can substitute any other dummy generating/recycling method without having to dig through the code to see where such things are implemented.

 

[JJhonJames]

This is the Resource.

You can see the Triggers without downloading it. "Shockwave Cast" is the one that handles this Dummy Creation. The other Triggers use this "Trigger - Run Shockwave Cast (ignoring conditions)" to create the Dummy. However, if you were to use a different Dummy for different Scaling Value, for example, you'd need to use the "Unit - Create Unit" separately in each Trigger, no?

 

[Uncle]

This is the Resource.

You can see the Triggers without downloading it. "Shockwave Cast" is the one that handles this Dummy Creation. The other Triggers use this "Trigger - Run Shockwave Cast (ignoring conditions)" to create the Dummy. However, if you were to use a different Dummy for different Scaling Value, for example, you'd need to use the "Unit - Create Unit" separately in each Trigger, no?

This is a Shockwave system which allows you to create different kinds of "Shockwave effects" -> A Missile that travels down a path for a set distance. It's using a very particular setup where the Dummy unit acts like a Missile as opposed to a hidden caster. Although, it can do both, like when using the Silence Wave example where the Dummy ALSO casts a spell if it hits an enemy.

Anyway, if you wanted to modify the scaling you could do this after running the Shockwave Cast trigger:

• Animation - Change (Last created unit)'s size to (200.00%, 200.00%, 200.00%) of its original size

Or you can add a new "setup" Variable which determines this Size during preparation and applies that Size in the Shockwave Cast trigger.

Alternatively, you can try to modify the Scale of the Special Effect which is being used as the Model for these Dummy units. Unfortunately, "attached" Special Effects won't Scale properly last I tried (a year or so ago) but maybe something changed? Changing the Size is likely better anyway...


I think the ideal system would be something like this although you'll need to put in some extra work to get it going:

Relativistic Missiles [vJASS][LUA][GUI]

Relativistic Missiles v2.8 by Chopinski Introduction First of all, Credits and thanks to BPower, Dirac, and Vexorian for their missile systems at which I based this system upon, and to AGD for the help with effect orientation methods. This is a Missile system that I put together...

www.hiveworkshop.com

Dummy units acting as Missiles is a bit obsolete now that we have Special Effect actions that can do the same.

I also think that the Shockwave system may have a slight issue when it's Dummy unit is used to cast a spell, like in the Silence Wave triggers. This is because a Dummy unit's settings are very picky, if you allow it to be movable then it likely won't cast spells "instantly" as these Movement settings are what determines that behavior. This is a very minor issue if true but I figured I'd mention it.

 

[JJhonJames]

This is a Shockwave system which allows you to create different kinds of "Shockwave effects" -> A Missile that travels down a path for a set distance. It's using a very particular setup where the Dummy unit acts like a Missile as opposed to a hidden caster. Although, it can do both, like when using the Silence Wave example where the Dummy ALSO casts a spell if it hits an enemy.

Anyway, if you wanted to modify the scaling you could do this after running the Shockwave Cast trigger:

• Animation - Change (Last created unit)'s size to (200.00%, 200.00%, 200.00%) of its original size

Or you can add a new "setup" Variable which determines this Size during preparation and applies that Size in the Shockwave Cast trigger.

Alternatively, you can try to modify the Scale of the Special Effect which is being used as the Model for these Dummy units. Unfortunately, "attached" Special Effects won't Scale properly last I tried (a year or so ago) but maybe something changed? Changing the Size is likely better anyway...


I think the ideal system would be something like this although you'll need to put in some extra work to get it going:

Relativistic Missiles [vJASS][LUA][GUI]

Relativistic Missiles v2.8 by Chopinski Introduction First of all, Credits and thanks to BPower, Dirac, and Vexorian for their missile systems at which I based this system upon, and to AGD for the help with effect orientation methods. This is a Missile system that I put together...

www.hiveworkshop.com

Dummy units acting as Missiles is a bit obsolete now that we have Special Effect actions that can do the same.

I also think that the Shockwave system may have a slight issue when it's Dummy unit is used to cast a spell, like in the Silence Wave triggers. This is because a Dummy unit's settings are very picky, if you allow it to be movable then it likely won't cast spells "instantly" as these Movement settings are what determines that behavior. This is a very minor issue if true but I figured I'd mention it.

The Animation Change Scale actually got me. This would have been the easier solution. What I did was take the "Unit - Create 1 Unit", "Set Variable Last Unit" and "Turn Collision Off" (all these from the Trigger Shockwave Cast [the one being called in Trigger - Run) and simply put it in the Config Cast (the ones with Starts the Effect of an Ability and all the config stuff, like AoE, Speed, Damage, etc). It's why I asked if these are the same thing, like, having the "SomeTrigger" actions moved to the "Trigger - Run SomeTrigger" would be the same thing.

You said about using dummies as effects being obsolete, it's because when I was a World Editor addicted, back like in 2016 when I was super active here, this was the thing. I'm so used to these.

 

[Pyrogasm]

You said about using dummies as effects being obsolete, it's because when I was a World Editor addicted, back like in 2016 when I was super active here, this was the thing. I'm so used to these.

In modern World Editor versions there are a bunch more natives to manipulate special effect colors, animations, scale, and orientation in 3D space.