[Trigger] Spawning On Cliffs

[nate1994]

• Survival Respawn 1
  • Events
    • Unit - A unit owned by Player 1 (Red) Becomes revivable
  • Conditions
    • (Player 1 (Red) slot status) Equal to Is playing
  • Actions
    • Wait 5.00 seconds
    • Unit - Create 1 Elite Sniper for Player 1 (Red) at (Random point in Map <gen>) facing Default building facing degrees
    • Camera - Pan camera for (Triggering player) to (Position of (Last created unit)) over 0.50 seconds

Map <gen> is a region over the entire map.

Sometimes the units spawn on cliffs and are unable to move until another unit kills it. How do I make it so that this doesn't happen?

I found this but I don't know how to put it in my map.

• SomeTrigger
  • Events
  • Conditions
  • Actions
    • custom script: loop
    • custom script: exitwhen IsTerrainPathableBJ(udg_location, PATHING_TYPE_WALKABILITY) == true
    • custom script: call RemoveLocation(udg_location)
    • custom script: set udg_location = GetRandomLocInRect(GetWorldBounds())
    • custom script: endloop
    • //Revive hero at location
    • custom script: call RemoveLocation(udg_location)

Would this work?

• Survival Respawn 1
  • Events
    • Unit - A unit owned by Player 1 (Red) Becomes revivable
  • Conditions
    • (Player 1 (Red) slot status) Equal to Is playing
  • Actions
    • Custom script: loop
    • Custom script: exitwhen IsTerrainPathableBJ(udg_location, PATHING_TYPE_WALKABILITY) == true
    • Custom script: call RemoveLocation(udg_location)
    • Custom script: set udg_location = GetRandomLocInRect(GetWorldBounds())
    • Custom script: endloop
    • Unit - Create 1 Elite Sniper for Player 1 (Red) at location facing Default building facing degrees
    • Custom script: call RemoveLocation(udg_location)

 

[Berb]

Looks okay. I see the problem was that you were spawning units on unwalkable terrain. What the custom script stuff you found does is repeatedly pick a random point in the map and it will stop repeating when that randomly selected point is pathable for unit walkability.

 

[spencenator]

In fact your bottom trigger would work, nate.

 

[Dr Super Good]

The bottom trigger will work in theory.

It however is bug prone and unefficent.

Problem 1 - The opperation limite WC3 has means that after so many opperations are done, the trigger will stop executing no mater where it is in its path of execution. The random nature of your algerthim means that it is possible for multiple unpathable points to be choosen in a row. Infact it is technically possible for an infinite chain of unpathable points to be selected (although this is staistically unlikly). As such the loop could be subject to the opperation limit and as such bug a respawn.

Problem 2 - Due to the reasons explained above, it is possible that a number of itterations are required. This means that the processor will be loaded with a variable load capable of hitting infinity (capped by opperation limit). As such you run the potential of a "lag" or 0 FPS burst every time you spawn a unit via it.

Although these situations are unlikly to occur, they can.

I advise using a safe spawn system where it only spawns in valid pathable areas. As the algerthim you provided will let them still be stuck in destructables (trees etc but not doodads) as well as the flaws above.

Ultimatly you could create a dynamic spawn detection system which maps out 8000 odd points on the map and check if they are pathable via tests (like sending a unit to a valid pathable location and seeing if it makes its way to there). The tests need not run at once and it could only start spawning after a minute or so.

I still advise the use of preplaces spawn areas that are known to be stick safe.

 

[Berb]

will let them still be stuck in destructables (trees etc but not doodads) as well as the flaws above.

Well, that isn't much of a problem. Just create an item and check to see whether or not the item is in the same position that you placed it. What exactly do you mean though, the processor will allocate a variable with the potential for hitting infinity? Variables are simply different sizes of memory blocks allocated for activity?

 

[Dr Super Good]

I never said that.
I said as the value choosen has a varience that is random, it could choose a chain of a million unpathable points in a row.

 

[Berb]

I said as the value choosen has a varience that is random, it could choose a chain of a million unpathable points in a row.

the processor will allocate a variable with the potential for hitting infinity

The way you phrased it really makes it sound like you were referring to something else. You're right, though, it's probably not very good to allow the possibility (however unlikely) to cause problems in-game.

It really depends on what this is intended to be used for.