Make units avoid a region while moving.

[Tom_Almighty1]

Guys I am making a purely open world game where you can jump in things, go into higher terrain, etc. But my problem is that I am purely using REGIONS, also as pathing blockers. I can't use the normal pathing blockers because I need to detect a unit's flying height to see if he can pass through a certain region or not. Example: A rock, if your flying height is less than 50 you cannot pass, but if above that then you can. Is it possible to let a unit AVOID a region while moving to a point? Same as how units move around of the pathing blockers to get to a point.

 

[Warseeker]

Units can go through pathing blockers if you turn off their collision. That said, you just need to detect when a unit enter that region and turn off its collision and then turn on after she leaves.

 

[IcemanBo]

What does avoiding a region mean in detail?

 

[Tom_Almighty1]

Thanks for the response guys. What I mean is that I want creeps to move around the map maybe through triggers or wander ability. I am using regions as pathing blockers since my map is complicated I am making an open world map that you can climb on rocks, go underwater, go underground, etc. My only problem here is that I cant use the destructible pathing blockers because I need to detect a unit's flying height to make the path allowable or not for a unit (ex: to pass over a rock you need to have 50 flying height or else it will bock you). I want the units to avoid these regions by going around them instead like how units detect destructible pathing blockers on their way to a destination Ex: I want a unit to move to a point but a region is in the middle of the unit and the point, I want that unit to walk towards the point but avoid stepping into the region (which is my pathing blocker), I want the unit to go around the region instead.

 

[IcemanBo]

I believe going around custom regions with custom conditions is too complex. It would mean to have a triggered pathing and waypoint system. You might need to think of a different concept. : /

 

[Cuore]

To me, what you're trying to do is basically create several different (and co-existing) pathfinding behaviours, that differ significantly from the ones that exist in the game (and stacking together in a number that might exceed the three ground-air-naval pathings of the base game).
Logically, something like this could be done by modifying the part of the engine that handles pathfinding (the "pathfinder" code if you will).
Warcraft 3 does not allow the user to modify its internal pathfinder.
I do not think that the trigger executer is powerful/fast enough to support a parallel pathfinding system created by users, which is based on custom-made regions, like the one you're theorizing.
I think you canNOT create a system like the one you're thinking in Warcraft 3. Other than surrender your ideas to the inherent limitations of the Warcraft 3 platform, you also have the choice to try and use a different platform to implement your concept.

 

[Tom_Almighty1]

I believe going around custom regions with custom conditions is too complex. It would mean to have a triggered pathing and waypoint system. You might need to think of a different concept. : /

To me, what you're trying to do is basically create several different (and co-existing) pathfinding behaviours, that differ significantly from the ones that exist in the game (and stacking together in a number that might exceed the three ground-air-naval pathings of the base game).
Logically, something like this could be done by modifying the part of the engine that handles pathfinding (the "pathfinder" code if you will).
Warcraft 3 does not allow the user to modify its internal pathfinder.
I do not think that the trigger executer is powerful/fast enough to support a parallel pathfinding system created by users, which is based on custom-made regions, like the one you're theorizing.
I think you canNOT create a system like the one you're thinking in Warcraft 3. Other than surrender your ideas to the inherent limitations of the Warcraft 3 platform, you also have the choice to try and use a different platform to implement your concept.

Ah sad. Hahah it's ok. Thanks guys! To be honest I made an unfinished map like this before, I did all the flying height triggering and pathing blockers with regions for players but my only problem was the AI. I was planning to remake it in 1.31 but it seems it would be a bad idea, so at least I didn't start the map yet hehehe thanks guys! +rep all I am not good with coding, I just use GUI mostly, sometimes a few lines of JASS so I can't code in different platforms, I tried Unity but it seems there are no tutorials for "Dummies" like me. The tutorials I've found require coding knowledge.

If only Blizzard made a game making engine similar to warcraft 3 with translated user friendly codes. Even just for low end games that would be awesome.

 

[Uncle]

Like Warseeker said, if you want the pathfinding to work there needs to be actual pathing. So for areas that are blocked off, like a wall of rocks for example, use Pathing Blockers like you normally would. Then put a region there and check if the entering unit meets the height requirements. If it does, turn off it's collision. When it leaves the region turn the collision back on.

You can also add the unit to a "Collision Checking" unit group when it enters the region. Then use a timer to periodically check if units in that group meet the height requirements in order to "fly" over the rocks. If they do, turn off their collision, if they don't, do nothing. Then when a unit leaves the region turn it's collision back on and remove it from the group, turning off the timer if the group empty.

 

[Cuore]

Like Warseeker said, if you want the pathfinding to work there needs to be actual pathing. So for areas that are blocked off, like a wall of rocks for example, use Pathing Blockers like you normally would. Then put a region there and check if the entering unit meets the height requirements. If it does, turn off it's collision. When it leaves the region turn the collision back on.

You can also add the unit to a "Collision Checking" unit group when it enters the region. Then use a timer to periodically check if units in that group meet the height requirements in order to "fly" over the rocks. If they do, turn off their collision, if they don't, do nothing. Then when a unit leaves the region turn it's collision back on and remove it from the group, turning off the timer if the group empty.

Hey uncle, let me ask a question about your proposed mechanism.

Let's imagine a rock (of height 5, for the sake of our example) equipped with pathing blockers is in the middle of a line drawn from A to B on the map.
Our desired result would be to make it so that units that fly above 5, when ordered to go from A to B, travel a path through the area occupied by the rock without issue. Units that fly at height 5 or below, as well as ground units, would have to go around the rock area delimited by the pathing blockers.

If you order a unit sitting at A to go to B, wouldn't that unit always go around the rock avoiding it, regardless of whether that unit flies above height 5?
(I'm supposing so due to there being pathing blockers in place when the movement order is issued and the path is calculated. If it is indeed so, then it's difficult that our unit ends up flying above our rock even with a system in place such as the one you were suggesting)
Thanks.

 

[Uncle]

Hey uncle, let me ask a question about your proposed mechanism.

Let's imagine a rock (of height 5, for the sake of our example) equipped with pathing blockers is in the middle of a line drawn from A to B on the map.
Our desired result would be to make it so that units that fly above 5, when ordered to go from A to B, travel a path through the area occupied by the rock without issue. Units that fly at height 5 or below, as well as ground units, would have to go around the rock area delimited by the pathing blockers.

If you order a unit sitting at A to go to B, wouldn't that unit always go around the rock avoiding it, regardless of whether that unit flies above height 5?
(I'm supposing so due to there being pathing blockers in place when the movement order is issued and the path is calculated. If it is indeed so, then it's difficult that our unit ends up flying above our rock even with a system in place such as the one you were suggesting)
Thanks.

Yeah, I realized after posting that I wasn't really providing a solution. My suggestion wouldn't fix the pathfinding.

But thinking about it some more, a possible solution does come to mind.

When you issue a non-flying unit to move somewhere on the map you compare the distance between the target point of issued order with the center of all of your rock regions. Using this method you could then find the closest rock region to the target point. From there you could create a "queue order" system or a "waypoint" system that tells the unit to first move to the rock region, and then once it reaches that destination, move to it's original destination.

You would also want to check if the distance between the unit and your original destination is closer than the distance between the unit and the chosen rock region. If it is, that would probably mean that you don't need to go over any rocks to get there, so it shouldn't run in this case.

Now this will definitely not work perfectly but it's a start.

 

[Cuore]

Basically, if I'm not misinterpreting, you'd need to devise a parallel path-finding system that takes into account your custom-made pathing regions and sets appropriate waypoints for units to actually path through them while they are on their way from A to B (if they're meant to pass through, of course).

I think the idea of setting up waypoints to redirect the correct unit through the region it's meant to traverse is very clever.
Definitely, it needs a bit of calculation done for each unit that's issued an order involving movement, in order to set up the correct waypoints.
Also, I assume there needs to be some sort of "delayed action" because when our unit reaches its first waypoint in our rock region, then and precisely then it needs to be ordered to move to the second waypoint (and the same thing will happen when the unit reaches our second waypoint at the end of the rock region, and needs to be ordered to move towards B).

I'm thinking of asking some other questions then: if we imagine that the unit is owned by a player, would the clicking of some buttons or the issuing of some other orders (i don't know, maybe some autocast spell getting cast, or some combat/aggro happening) harbor the ability to disrupt the orders that allow the unit to move through waypoints?

I'm suspecting that the calculations need to be performed for every single unit that paths through those rocks, and that if a map has more than just one rock then waypoints need to be set up for every rocky region encountered by every unit on their path (at least a couple of waypoints per rocky region, unless these have some convoluted shape). Of course all of this is done in real time, during gameplay.
In your opinion, am I wrong in suspecting that similar calculations could result in a very heavy load of work for the part of the engine that handles triggers execution?

EDIT: an additional question. Can such a system be functional while it ultimately can only rely on triggers? Can it handle the interaction with interfering orders (for example, those cited above)? How many units moving at the same time could realistically be supported?
I'm no good at estimating answers to these questions but I'm afraid that there's a high chance that the resulting system (if it can even be made to overcome possible issues like the ones I listed here above) may end up being too complex to be functional during actual gameplay.
To me, the answer ultimately has something to do with the fact that in order for you to make custom pathfinding that's functional, you'd need to interact with the existing pathfinding mechanisms, which are unfortunately inaccessible to the user (at the best of my understanding).
I'd love to read more opinions on the matter.