How can I improve this trigger?

[BiroN]

• HoomanUnitsRespawn
  • Events
    • Unit - A unit Dies
  • Conditions
    • (Owner of (Dying unit)) Equal to Player 2 (Blue)
  • Actions
    • Set Hooman = (Unit-type of (Dying unit))
    • Set HoomanDying = (Position of (Dying unit))
    • Wait 60.00 seconds
    • Unit - Create 1 Hooman for Player 2 (Blue) at (Center of Region 083 <gen>) facing Default building facing degrees
    • Unit - Order (Last created unit) to Attack-Move To HoomanDying

Let's say there's a long battle, and I want the number of ally units (units of player2) to remain the same; meaning that if a footman dies, another one spawns after a minute then goes to where the other footman dies and so on.

This trigger doesn't do that. It stores only 1 death location and 1 unit type. For example, a militia died, then a footman died, then a captain died, then the trigger created 3 captains and ordered them to go where the previous captain died. I think the main issue is the long wait time, but the player would be overpowered if units respawned every 2 seconds or such.

All suggestions are welcome.

EDIT: I thought about the Replace GUI, but I think it's the same issue since I'd have to use the same variable (Hooman) to replace the dying unit. I'm out of ideas.

 

[water_Knight]

Well i would take it as, Since it sets the variable every time one dies. If a new one dies the last position is overwritten so they are forced to go to the new area. I haven't touched the editor in over 2 years tho so i don't know how to change it.

Also wouldn't it be better to store the position of all units owned by Player 2 beforehand? Because with the way you have it now the units will slowly drift away from there original position.

So by that means if you store the position in a variable and the unit type and when they die then load it up that could work.

 

[BiroN]

Well i would take it as, Since it sets the variable every time one dies. If a new one dies the last position is overwritten so they are forced to go to the new area. I havent touched the editor in over 2 years tho so i don't know how to change it.

Yep, that's the problem. The Unit type and the Unit death location get overwritten. The Only other alternative that comes to my mind is to make a variable for each unit type, but that would take too long.... Also, it wouldn't solve the unit location problem.
Well, thanks for trying to help.

 

[EdgeOfChaos]

If you want to use waits, then the simple answer is locals. The more complex answer is using a unit indexer to store values in an array, and then reference them using the unit custom value.

Here's some example code of the locals method. Keep in mind this is just to give you the idea, I just wrote it in the hive workshop comment, so don't expect it to work as is.

//Do this in custom script
local real x = GetUnitX(GetDyingUnit())
local real y = GetUnitY(GetDyingUnit())
//Do this in GUI
Wait 60 seconds
Create 1 unit of type Hooman at region 18... etc
//Now in custom script again
call IssuePointOrder(bj_lastCreatedUnit,"attackmove",x,y)

The point of this is that locals will not get overwritten in the same way that globals do. You might also be able to get away with just deleting both of your globals, and just using Triggering Unit - I know that sometimes this is a MUI function.

Technically though, you're not supposed to use waits at all since they're buggy. You can do a wait-less version without vJASS timers, but you have to make up some clever way. I can't tell you how to do it since I don't know your map.

 

[Zunariel]

I would use a unit indexer which numbers every single footman from 1 to x and let's them all spawn on their very own location.

 

[Radicool]

The problem is your trigger is not MUI so it glitches if the trigger is activated more than once at a time. MUI stands for multi unit instancability, meaning an MUI trigger can work once for every unit type.

There are a few ways to make your trigger MUI. As mentioned above, you could use "locals". Another method that I use is dynamic indexing. Search for a tutorial on your preferred method within the tutorial section on the hive.

Contrary to mentioned above, waits are NOT buggy. They do work, however they are just not accurate. They can wait up to 0.40 or so seconds longer than intended. I'm sure if you Google the topic, there would be a more detailed explanation. Normally using waits causes a trigger to no longer be MUI because variables can be overwritten during the wait period.

 

[WereElf]

• HoomanUnitsRespawn
  • Events
    • Unit - A unit Dies
  • Conditions
    • (Owner of (Dying unit)) Equal to Player 2 (Blue)
  • Actions
    • Custom script: local location p = GetUnitLoc(GetTriggerUnit())
    • Custom script: local integer i = GetUnitTypeId(GetTriggerUnit())
    • Wait 60.00 seconds
    • Custom script: set udg_HoomanDying = p
    • Custom script: set udg_Hooman = i
    • Set TempPoint = (Center of Region 083 <gen>)
    • Unit - Create 1 Hooman for Player 2 (Blue) at TempPoint facing Default building facing degrees
    • Unit - Order (Last created unit) to Attack-Move To HoomanDying
    • Custom script: call RemoveLocation( udg_TempPoint )
    • Custom script: call RemoveLoaction( p )
    • Custom script: set p = null

Gosh, I haven't used 'locations' for so long
Almost forgot to null it

 

[NightStalker]

As Radicool said, you need this to be MUI bcz itll replace the previous dying unit with the new dying unit. You need to store every dying unit provided with satisfied conditions. Dont store them if they not satisfy the conditions. So it should be sth like this

• Events
  • A unit dies
• Conditions
  • Dying unit equal to Footman
  • Owner equal to Player 2
• Actions
  • Count++
  • toBeRespawnedUnit[Count] = Dying unit
  • Loc[Count] = dying unit point
  • Start spawnTimer[Count]

Im not on pc rn, and im not so pro at WE. But there should be a way to check if a timer in a timer array runs out. Then after you check it execute the rest of the work.

• Events
  • spawnTimer runs out
• Conditions
• Actions
  • Spawn Footman at etc...
  • Order Last Created Unit att. Move to Loc[you should find a way to find the index]
  • Loc[Count] = Loc[Count-1]
  • toBeReplacedUnit[Count] = toBeReplacedUnit[Count-1]
  • Count--

Something like this should work imo. There may be better approaches though.

 

[IcemanBo]

Moved to Triggers & scripts.

Looks good guys.
@Wereelf, the location is not used in the example.

 

[WereElf]

@Wereelf, the location is not used in the example.

What do you mean?
The newly created units are ordered to attack-move to the location. So it is used
However, I'll edit my earlier post to make his trigger leakless
(Didn't notice he was creating the units at center of region)

 

[IcemanBo]

Oh, right. I was looking at the other location, but which is changed now. ;D

 

[JaysProjex]

All suggestions are welcome. .

• Set Hooman = (Unit-type of (Dying unit))

I don't understand the logic behind why this is being used there are no conditions for it unless you haven't revealed all other linked triggers which we cannot fully help you without them being visible.

• Set HoomanDying = (Position of (Dying unit))

Position is set but isn't recycled therefor it leaks

• Wait 60.00 seconds

Why hasn't this generation moved on past waits yet? It should be completely avoided.

Using a wait even at 0.00 seconds will still cause a overwrite.

 

[EdgeOfChaos]

Because there is no simple way to avoid waits, especially in GUI. If you make a system that can implement an actual, glitchless wait function then I'm sure people will use it.

 

[JaysProjex]

Because there is no simple way to avoid waits, especially in GUI. If you make a system that can implement an actual, glitchless wait function then I'm sure people will use it.

Ever heard of a "Dummy unit" even days like today several gaming developers still use them, this isn't new information either.

 

[EdgeOfChaos]

Dummy units can simulate a wait in some cases, but it definitely doesn't always substitute for wait. Timers in vJASS are really the way that you get around using waits - and obviously those are not in GUI, and not easy to do in any case. Even though it's technically bad practice, using occasional waits is fine. As long as it's not in something that will break the game if someone pauses and makes it expire, or something that needs to be super precise.