Making terrain deformations walkable

[darwin]

I have a scene in my map where you race a boat down a river. While this is happening, the terrain under the water rises, giving the illusion that the water disappears. The action is:

• Environment - Create a (tempReal2 / 1.00) second wave deformation from tidalPoint4 to tidalPoint5 with radius (tempReal / 3.00), depth -120.00, and a 12.00 second trailing delay

If the deformation catches up to the boat, the water is gone and the ship should die (I have a trigger that constantly detects pathing on the boat, and if it's not pathable to floating, the ship dies). This worked perfectly about a month ago. Since then, I've gotten a new computer and copied my data over. Suddenly, it doesn't work! Now, the boat can just sail mindlessly on the land even with no water. I tested the trigger, and the raised land is still being detected as pathable for floating units. Further, raised land is not pathable to walking units, so if I use a terrain deformation to make a crater in water (but tall enough that it sticks out of the water) land units cannot walk on it.

I can't prove it...but I swear it wasn't this way last month! I am certain the raised land killed the boats, and I'm pretty confident that units were running around on the raised land as well. I've made many changes to the map, so perhaps I switched something out. Does anyone have any idea how to affect pathing with terrain deformations, or better yet, to be able to detect whether a point is pathable to water taking into account the terrain deformations?

UPDATE: I dug up an older version of my map (it was not easy) and I discovered that it was never the pathing that killed the boats. When you raise land over water using terrain deformations, the game still treats that as water. It does change the height of the terrain though, and so the ship was dying because my triggers detected that it was going uphill (I have that in the code so that a ship cannot sail up a waterfall).

UPDATED QUESTION: I would like to raise terrain in water and make it icy so that it looks like someone froze the water. That part works. What I want next is land units to be able to fight on the ice, but not go into the water. Is there a way to manually make water in a set area walkable? I was thinking maybe something like an invisible flat bridge? I'm not very good at destructables though...and it would have to be water pathable before the event (when the watery area isn't frozen).

 

[rulerofiron99]

There's a function that lets you set terrain pathing for a 32x32 cell.

You just need to loop over the area, set to water pathing if height is below X, set to ground pathing if height is above X.

 

[darwin]

Excellent, let me work on that!

When you say 32x32 cell...does that mean I need something like this (tempPoint is the bottom left of the area I want to walk on):

• For each (Integer A) from 1 to 5, do (Actions)
  • Loop - Actions
    • Set tempPoint2 = (tempPoint offset by (32.00 x (Real((Integer A)))) towards 90.00 degrees)
    • For each (Integer B) from 1 to 50, do (Actions)
      • Loop - Actions
        • Set tempPoint3 = (tempPoint2 offset by (32.00 x (Real((Integer B)))) towards 0.00 degrees)
        • Environment - Set terrain pathing at (tempPoint3)) of type Walkability to On
        • Custom script: call RemoveLocation (udg_tempPoint3)
    • Custom script: call RemoveLocation (udg_tempPoint2)

Is the distance 32 correct?

UPDATE:

I'm still playing around with it, but it's starting to work! I don't know why, but I've never thought of using that action before. I guess I was confused by how big the "point" was, but spacing them by 32 seems to work.

 

[Dr Super Good]

Does pathing work in 32*32 units? The smallest in game pathing I know of is 64*64 "quarter tile" units. It might just be that the build grid operates in such units.

Do be aware that if a unit gets embedded inside "unpathable" areas it might get displaced (probably when it next is moved).

 

[darwin]

Does pathing work in 32*32 units? The smallest in game pathing I know of is 64*64 "quarter tile" units. It might just be that the build grid operates in such units.

Do be aware that if a unit gets embedded inside "unpathable" areas it might get displaced (probably when it next is moved).

I don't understand the grid at all, so I have no idea if the 32*32 is correct. What I do know is that I made some loops inside loops to change a large area to walkable pathing. Some points I noticed:

1. When I spaced the points 32 distance apart some units (knights) seemed to have difficulty moving around. When I made them 16 distance apart they moved fine.

2. There appears to be a limit to how many commands you can put in a trigger. When I put a For Each Integer A with 100 iterations inside a For Each Integer B with 100 iterations (producing 10,000 points of walkable terrain in one trigger) the trigger just quit part way through. To fix it, I made a periodic trigger that just did 100 points every .03 seconds and let it run for a few seconds. That has worked well.

EDIT: added triggers below to illustrate. I also wanted the area to be wider, so I made two repeating triggers, one that handles the left side of the area, one the right:

• Frost Lake pathing Redo
  • Events
    • Time - pathingTimer expires
  • Conditions
  • Actions
    • Set tempPoint = (Center of FrostBeachStartPathing <gen>)
    • Set pathingCounter = (pathingCounter + 1)
    • Set tempPoint2 = (tempPoint offset by (16.00 x (Real(pathingCounter))) towards 90.00 degrees)
    • For each (Integer B) from 1 to 100, do (Actions)
      • Loop - Actions
        • Set tempPoint3 = (tempPoint2 offset by (16.00 x (Real((Integer B)))) towards 0.00 degrees)
        • Custom script: set udg_r = GetLocationZ(udg_tempPoint3)
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • r Greater than or equal to 38.50
          • Then - Actions
            • Environment - Set terrain pathing at tempPoint3 of type Walkability to On
          • Else - Actions
        • Custom script: call RemoveLocation (udg_tempPoint3)
    • Custom script: call RemoveLocation (udg_tempPoint2)
    • Custom script: call RemoveLocation (udg_tempPoint)
    • -------- --------- --------
    • Game - Display to (All players) the text: (String(pathingCounter))
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • pathingCounter Equal to 200
      • Then - Actions
        • Trigger - Turn off (This trigger)
      • Else - Actions
        • Countdown Timer - Start pathingTimer as a One-shot timer that will expire in 0.07 seconds
        • Countdown Timer - Start pathingTimer2 as a One-shot timer that will expire in 0.03 seconds

• Frost Lake pathing Redo 2
  • Events
    • Time - pathingTimer2 expires
  • Conditions
  • Actions
    • Set tempPoint = (Center of FrostBeachStartPathing <gen>)
    • Set tempPoint2 = (tempPoint offset by (16.00 x (Real(pathingCounter))) towards 90.00 degrees)
    • For each (Integer B) from 100 to 200, do (Actions)
      • Loop - Actions
        • Set tempPoint3 = (tempPoint2 offset by (16.00 x (Real((Integer B)))) towards 0.00 degrees)
        • Custom script: set udg_r = GetLocationZ(udg_tempPoint3)
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • r Greater than or equal to 38.50
          • Then - Actions
            • Environment - Set terrain pathing at tempPoint3 of type Walkability to On
          • Else - Actions
        • Custom script: call RemoveLocation (udg_tempPoint3)
    • Custom script: call RemoveLocation (udg_tempPoint2)
    • Custom script: call RemoveLocation (udg_tempPoint)

 

[Xonok]

For clarification, the game actually uses 32x32 squares for building pathing. The easiest way to visually find out the smallest pathing square is painting a 1x1 px square in gimp and saving it as tga, then using it in a map. You'll see that it's quite small.

 

[Dr Super Good]

2. There appears to be a limit to how many commands you can put in a trigger. When I put a For Each Integer A with 100 iterations inside a For Each Integer B with 100 iterations (producing 10,000 points of walkable terrain in one trigger) the trigger just quit part way through. To fix it, I made a periodic trigger that just did 100 points every .03 seconds and let it run for a few seconds. That has worked well.

That is called the "operation limit". The idea is to stop infinite loops freezing the game. Once the operation limit is reached the trigger thread crashes. The limit is reset when ever a thread is de-scheduled (blocked such as by TriggerSleepAction).

 

[darwin]

That is called the "operation limit". The idea is to stop infinite loops freezing the game. Once the operation limit is reached the trigger thread crashes. The limit is reset when ever a thread is de-scheduled (blocked such as by TriggerSleepAction).

You impress me with your knowledge. I still remember when you informed me that keyboards can only record so many keys being held down at once... I thought it was a limit of SC2 at the time.

Do "wait" actions within a trigger reset the operation limit? Also, can splitting the computations into two triggers double the operation limit?

 

[Dr Super Good]

Do "wait" actions within a trigger reset the operation limit?

I already answered that.

The limit is reset when ever a thread is de-scheduled (blocked such as by TriggerSleepAction).

TriggerSleepAction is the native used by GUI wait. Do note that any sort of wait will deschedule the thread for a period of time of at least 0.1 seconds.

Also, can splitting the computations into two triggers double the operation limit?

Illogical question? Each thread has a separate operation limit. Spawning 2 threads which do half the work each will double the total work before the operation limit is reached. A trigger can be used to create any number of threads. A thread is created when an event fires. There is no small limit to how many active threads a trigger can have at any given time.