I'm working on a maze defense style map where it's possible to maze so much that eventually the pathing cost between two points can exceed the maximum 65536. This makes my map assume that the pathing is blocked even when it isn't, or at least shouldn't be. I'm currently using the setup where a trigger checks the pathing cost between every adjacent checkpoint each time a building is constructed and destroys / refunds the structure if the pathing cost equals 65536. Block prevention is necessary for this map, and I'd prefer if blocking were simply disallowed without it also disallowing pathing that exceeds 65536. Is there a way to make this happen, or will I have to acquire ninja coding skills / scrap the map? I'm willing to send the map to a trusted and versed galaxy editing member of the forum to look at if they think they can help. This map has been my first learning experience with the galaxy editor, so it'll likely have some leftover spaghetti. Thanks for any advice!
A 1 x 1 square can easily support a path with a bigger distance than 1, though, given the appropriate mazing. Even just crossing the square diagonally will be a greater distance than 1. So it should indeed be possible to create a valid path with pathing costs > 65536.
As on how to fix it, I have no good idea (besides the obvious ones, reduce possible mazing, reduce distance between points etc)
You could try workarounds like run a unit with a specific movespeed through the maze and let it set up marker points at its current position in set time intervals, which you can use to track the pathing cost by summarizing the costs between those markers; however, that might malfunction with sudden radical changes to the maze.
A 1 x 1 square can easily support a path with a bigger distance of 1, though, given the appropriate mazing. Even just crossing the square diagonally will be a greater distance than 1. So it should indeed be possible to create a valid path with pathing costs > 65536.
Well i wasn't sure, But anyway i think it highly unlikely he goes beyond that. You need to take into account pathing blocks themselves and minimal distance step, not to mention other stuff on map.
Well i wasn't sure, But anyway i think it highly unlikely he goes beyond that. You need to take into account pathing blocks themselves and minimal distance step, not to mention other stuff on map.
I am not sure, how unlikely it actually is. I will try to test out, how high the pathing costs can actually get for a huge maze covering the entire map ;)
@Kueken531: Go
it's should be easy to calculate, but it depends on how the function actually checks the pathing, using what radius; knowing nature SC2 the fraction is probably not that small.
In editor full square is minimal 0.25x0.25 so there's 4x4 grid per 1x1 square.
Longest possible pathing at this square would be 2,5 if outside is considered unpathable. So yea in this case its 256^2 * 2,5 = 163840.
But that's if your using blocking less than 1x1 which from what i noticed doesn't allow to place units even with 0 radius; also i doubt he's using such small blocks.
So if you'r using minimal 1x1 blocks any block will reduce total of 65536.
Anyway. If you design such test maze. Longest possible would look like
OOOBOOOBOBOBOBOBOBOBOBOBOBOOOBOO
Anything different will have smaller pathing cost.
This, or i just have bad day and it's all incorrect
@KamikazeKomics: Go
There's a lot of possible pathing blockers. Structures, maybe units.
Get to the point (in time) where your pathing cost is over 65536. Pause any changing to terrain,maze, Spawn unit and send it where you want. You can track it and it will eventually stop at point of block.
Thank you for all of your help so far. I would have replied sooner, but I work weekends, so I thank you again for your patience with me as well.
I took your advice, Nerfpl, with the exception that, rather than playing all the way through to the point of the error, I slightly modified the map for debugging purposes. I ended up recreating the maze I would have made by the time the pathing cost became too high. It actually took a few extra waves before the error came up again, so I've added more to my pre-made maze so that the error can be consistently recreated on the first wave.
For reference, this map can host up to twelve players, and the mobs are expected to travel to a waypoint near each player before heading towards a new set of waypoints, followed by the exit. The block-checking trigger occurs any time a structure is built by a player and checks every single waypoint that the mobs would have to travel between to see if the pathing cost equals 65536. If it does, the trigger destroys and refunds the building and sends a message to the player. If not, play resumes as normal.
With that covered, there were a few anomalies that occurred while testing.
1. I had my builder build a wall in a spot that shouldn't block but adds to the maze. Expectedly, the error occurred with the blocking trigger destroying and refunding my building and giving me the blocking error message. I went to another side and built a wall, and this wall built with no errors. I then went back to build a wall in the exact same spot as the first, and the blocking trigger allowed it without giving any errors. I haven't been able to recreate this exactly, but this part of the maze had two entrances and wasn't finished, so there were plenty of opportunities to get to the waypoint in the center even if I was mistaken and the first side really was walled off.
2. Thinking that maybe it was a problem with the builder's mass messing with the pathing, I used a flying builder, and this builder triggers the blocking error after building a few walls, just as the other. This builder shouldn't be able to block anything but other air units.
3. Thinking that maybe I was mistaken about whether or not the path was blocked, I built a single mazing wall out in the middle of nowhere which did not in any way contribute to the length of the maze and couldn't block anything, and it still gave the blocking error.
It seems pretty arbitrary as to when it will give the blocking error, aside from the fact that it doesn't occur until the maze gets relatively large. To my knowledge, none of the builders should be remotely blocking any paths. Even if they were capable of blocking, as I said, there were multiple entrances to the waypoint at the time the errors occurred. Furthermore, because this error doesn't occur until the maze is relatively large, I expect it has something to do with the length of the maze. If it were any other problem, I should expect to have seen this error before the maze gets large. I could be entirely wrong about that, though. This is really stumping me.
I did some more digging. For reference, my maze setup alternates the waves to go from inside to outside of the maze and back every time they head to a new waypoint.
With this test, I removed the blocking trigger, so it's possible to block and/or make the maze as large as I want in-game. I added the walls which I was previously prevented from building, and then sent the first wave through the maze. They triggered my 'unit becomes idle' trigger at player 12's waypoint (without the idle trigger, they normally head to player 6's waypoint next and do not become idle). First of all, player 12 and 6 are on the exact opposite side of the map as the walls that were previously giving me the blocking error. Secondly, they had no trouble getting between those two waypoints before, and, to my knowledge, I did not block them from getting there with the new walls. When the 'unit becomes idle' trigger occurred, which basically finds out where they should be going and sends them there again, it started them on the path again, but they took a shortcut through the middle of a chasm that should have been non-traversable (and would successfully maze them under any other circumstance). They then proceeded to go from player 6's waypoint, on the outside of the maze, to the next one (player 2) which was on the inside of the maze. 12 is also on the inside of the maze, so they should know how to get from 12 to 6 if they can get from 6 to 2.
I wasn't able to see where it was that they were supposedly being blocked because of them taking the shortcut they shouldn't have been able to take. I have work, now, but will do further testing when I get back.
I'm not entirely clear if I understand your problem, but I have some blocking checks in my map that, if the path is blocked it redirects unit waves. Because this check happens at multiple choke points along the lane the player is in, I ended up having to put a point before and after each check point that would check the pathing cost between point A and B when the unit approaches A.
to solve your problem, I'd recommend adding a point halfway through your map. check the pathing cost to that point, and then when it approaches the point, check the pathing cost to the next waypoint. this would effectively cut your pathing costs in half and avoid your main problem. If the maze is being randomly generated, I would go with what Kueken said and have a fast, invisible unit running the maze and dropping these check points along the way.
I'm more of a visual thinker so, if you post a picture of your map, I might be able to understand your issue better and give you a better suggestion.
Sure, Vortexx2010; I'm a visual learner, myself, so I completely understand. My website is down, so I'll be using a commercial imaging host. I hope it works.
Here's the birds eye view of the map sans extraneous regions, points, and doodads:
Here's the same but showing where player starting locations are and the path player 1's mobs take all the way to the exit (they alternate left and right once they reach player 1's waypoint):
Here's the map sans the extraneous, but showing where I've painted pathing (for the record, the chasm mentioned before which the mobs cut across was the one near player 6's waypoint):
I realise it's difficult to see the dark gray walls on dark gray background, so I've taken the liberty of crudely highlighting the path mobs normally take through this. It only takes a few additional walls added to the spiral at player 5's waypoint before the game believes the pathing is blocked. As you can see, I've made this exact same spiral a couple times already, at least, so I'm pretty sure I know how to make it pathable a third time.
Nerfpl, pathing paint is shown in the third and fourth images.
Thanks again for your help! I've got a few extra things I want to test, and will be posting the results when I get something.
I made a trigger which would tell me exactly which two points were giving a blocking error any time I built a structure. It turns out it was the path between player 2's waypoint and the one just south of it (12 o'clock middle), though I don't see a reason it should be considered blocked given I'm only adding to a spiral maze near player 5's waypoint.
I made a new trigger which would show the pathing cost between player 2's waypoint and 12 o'clock middle every time I built a new structure. When I added walls to the maze near player 5's waypoint, I got, in order:
Hard really to help you based on your claims.
Often people say "i do that" when they actually miss their errors and do something slightly different.
The mentioned spawn,send unit method should test if path is indeed blocked without errors. Also it will show you where the unit actually goes in case it's blocked.
Other than that you may send me map in PM, point on where and when error happens and i will most likely find the error.
I understand, and I try my best to have humility in all things, especially when it comes to computer versus user error. I won't be at all surprised if there's some glaringly obvious stupid thing I'm doing. I'll send my map over when I get back home from work. Thanks!
I appreciate everyones help with this issue, especially Nerfpl who went above and beyond. It looks as if I'll have to decrease the map size a bit, and hope that reduces the frequency of this bug occurring.
I'm working on a maze defense style map where it's possible to maze so much that eventually the pathing cost between two points can exceed the maximum 65536. This makes my map assume that the pathing is blocked even when it isn't, or at least shouldn't be. I'm currently using the setup where a trigger checks the pathing cost between every adjacent checkpoint each time a building is constructed and destroys / refunds the structure if the pathing cost equals 65536. Block prevention is necessary for this map, and I'd prefer if blocking were simply disallowed without it also disallowing pathing that exceeds 65536. Is there a way to make this happen, or will I have to acquire ninja coding skills / scrap the map? I'm willing to send the map to a trusted and versed galaxy editing member of the forum to look at if they think they can help. This map has been my first learning experience with the galaxy editor, so it'll likely have some leftover spaghetti. Thanks for any advice!
How a map 256*256 = 65536 can have bigger path than 65536?
if you exceed 65536 than it means the path is blocked at that given time
@Nerfpl: Go
I thought that was weird, too. Is there another reason it might think the pathing is blocked when it isn't?
A 1 x 1 square can easily support a path with a bigger distance than 1, though, given the appropriate mazing. Even just crossing the square diagonally will be a greater distance than 1. So it should indeed be possible to create a valid path with pathing costs > 65536.
As on how to fix it, I have no good idea (besides the obvious ones, reduce possible mazing, reduce distance between points etc)
You could try workarounds like run a unit with a specific movespeed through the maze and let it set up marker points at its current position in set time intervals, which you can use to track the pathing cost by summarizing the costs between those markers; however, that might malfunction with sudden radical changes to the maze.
Well i wasn't sure, But anyway i think it highly unlikely he goes beyond that. You need to take into account pathing blocks themselves and minimal distance step, not to mention other stuff on map.
I am not sure, how unlikely it actually is. I will try to test out, how high the pathing costs can actually get for a huge maze covering the entire map ;)
@Kueken531: Go it's should be easy to calculate, but it depends on how the function actually checks the pathing, using what radius; knowing nature SC2 the fraction is probably not that small.
In editor full square is minimal 0.25x0.25 so there's 4x4 grid per 1x1 square.
Longest possible pathing at this square would be 2,5 if outside is considered unpathable. So yea in this case its 256^2 * 2,5 = 163840.
But that's if your using blocking less than 1x1 which from what i noticed doesn't allow to place units even with 0 radius; also i doubt he's using such small blocks.
So if you'r using minimal 1x1 blocks any block will reduce total of 65536.
Anyway. If you design such test maze. Longest possible would look like
Anything different will have smaller pathing cost.
This, or i just have bad day and it's all incorrect
@KamikazeKomics: Go There's a lot of possible pathing blockers. Structures, maybe units.
Get to the point (in time) where your pathing cost is over 65536. Pause any changing to terrain,maze, Spawn unit and send it where you want. You can track it and it will eventually stop at point of block.
Thank you for all of your help so far. I would have replied sooner, but I work weekends, so I thank you again for your patience with me as well.
I took your advice, Nerfpl, with the exception that, rather than playing all the way through to the point of the error, I slightly modified the map for debugging purposes. I ended up recreating the maze I would have made by the time the pathing cost became too high. It actually took a few extra waves before the error came up again, so I've added more to my pre-made maze so that the error can be consistently recreated on the first wave.
For reference, this map can host up to twelve players, and the mobs are expected to travel to a waypoint near each player before heading towards a new set of waypoints, followed by the exit. The block-checking trigger occurs any time a structure is built by a player and checks every single waypoint that the mobs would have to travel between to see if the pathing cost equals 65536. If it does, the trigger destroys and refunds the building and sends a message to the player. If not, play resumes as normal.
With that covered, there were a few anomalies that occurred while testing.
1. I had my builder build a wall in a spot that shouldn't block but adds to the maze. Expectedly, the error occurred with the blocking trigger destroying and refunding my building and giving me the blocking error message. I went to another side and built a wall, and this wall built with no errors. I then went back to build a wall in the exact same spot as the first, and the blocking trigger allowed it without giving any errors. I haven't been able to recreate this exactly, but this part of the maze had two entrances and wasn't finished, so there were plenty of opportunities to get to the waypoint in the center even if I was mistaken and the first side really was walled off.
2. Thinking that maybe it was a problem with the builder's mass messing with the pathing, I used a flying builder, and this builder triggers the blocking error after building a few walls, just as the other. This builder shouldn't be able to block anything but other air units.
3. Thinking that maybe I was mistaken about whether or not the path was blocked, I built a single mazing wall out in the middle of nowhere which did not in any way contribute to the length of the maze and couldn't block anything, and it still gave the blocking error.
It seems pretty arbitrary as to when it will give the blocking error, aside from the fact that it doesn't occur until the maze gets relatively large. To my knowledge, none of the builders should be remotely blocking any paths. Even if they were capable of blocking, as I said, there were multiple entrances to the waypoint at the time the errors occurred. Furthermore, because this error doesn't occur until the maze is relatively large, I expect it has something to do with the length of the maze. If it were any other problem, I should expect to have seen this error before the maze gets large. I could be entirely wrong about that, though. This is really stumping me.
I did some more digging. For reference, my maze setup alternates the waves to go from inside to outside of the maze and back every time they head to a new waypoint.
With this test, I removed the blocking trigger, so it's possible to block and/or make the maze as large as I want in-game. I added the walls which I was previously prevented from building, and then sent the first wave through the maze. They triggered my 'unit becomes idle' trigger at player 12's waypoint (without the idle trigger, they normally head to player 6's waypoint next and do not become idle). First of all, player 12 and 6 are on the exact opposite side of the map as the walls that were previously giving me the blocking error. Secondly, they had no trouble getting between those two waypoints before, and, to my knowledge, I did not block them from getting there with the new walls. When the 'unit becomes idle' trigger occurred, which basically finds out where they should be going and sends them there again, it started them on the path again, but they took a shortcut through the middle of a chasm that should have been non-traversable (and would successfully maze them under any other circumstance). They then proceeded to go from player 6's waypoint, on the outside of the maze, to the next one (player 2) which was on the inside of the maze. 12 is also on the inside of the maze, so they should know how to get from 12 to 6 if they can get from 6 to 2.
I wasn't able to see where it was that they were supposedly being blocked because of them taking the shortcut they shouldn't have been able to take. I have work, now, but will do further testing when I get back.
if this chasm is static part of terrain you can simply use pathing tool in terrain module (just in case you wouldn't know).
I'm not entirely clear if I understand your problem, but I have some blocking checks in my map that, if the path is blocked it redirects unit waves. Because this check happens at multiple choke points along the lane the player is in, I ended up having to put a point before and after each check point that would check the pathing cost between point A and B when the unit approaches A.
to solve your problem, I'd recommend adding a point halfway through your map. check the pathing cost to that point, and then when it approaches the point, check the pathing cost to the next waypoint. this would effectively cut your pathing costs in half and avoid your main problem. If the maze is being randomly generated, I would go with what Kueken said and have a fast, invisible unit running the maze and dropping these check points along the way.
I'm more of a visual thinker so, if you post a picture of your map, I might be able to understand your issue better and give you a better suggestion.
Sure, Vortexx2010; I'm a visual learner, myself, so I completely understand. My website is down, so I'll be using a commercial imaging host. I hope it works.
Here's the birds eye view of the map sans extraneous regions, points, and doodads:
http://i1159.photobucket.com/albums/p632/kamikazekomics/KamikazeMapSmall.jpg
Here's the same but showing where player starting locations are and the path player 1's mobs take all the way to the exit (they alternate left and right once they reach player 1's waypoint):
http://i1159.photobucket.com/albums/p632/kamikazekomics/KamikazeMapPlayerPathSmall.jpg
Here's the map sans the extraneous, but showing where I've painted pathing (for the record, the chasm mentioned before which the mobs cut across was the one near player 6's waypoint):
http://i1159.photobucket.com/albums/p632/kamikazekomics/KamikazeMapPathingSmall.jpg
And finally, this one is the same as above but includes the pre-made maze I've been testing with:
http://i1159.photobucket.com/albums/p632/kamikazekomics/KamikazeMapPlayerPathingPathSmall.jpg
I realise it's difficult to see the dark gray walls on dark gray background, so I've taken the liberty of crudely highlighting the path mobs normally take through this. It only takes a few additional walls added to the spiral at player 5's waypoint before the game believes the pathing is blocked. As you can see, I've made this exact same spiral a couple times already, at least, so I'm pretty sure I know how to make it pathable a third time.
Nerfpl, pathing paint is shown in the third and fourth images.
Thanks again for your help! I've got a few extra things I want to test, and will be posting the results when I get something.
I made a trigger which would tell me exactly which two points were giving a blocking error any time I built a structure. It turns out it was the path between player 2's waypoint and the one just south of it (12 o'clock middle), though I don't see a reason it should be considered blocked given I'm only adding to a spiral maze near player 5's waypoint.
I made a new trigger which would show the pathing cost between player 2's waypoint and 12 o'clock middle every time I built a new structure. When I added walls to the maze near player 5's waypoint, I got, in order:
475
474
65536
I don't think I can make any sense of this.
Hard really to help you based on your claims.
Often people say "i do that" when they actually miss their errors and do something slightly different.
The mentioned spawn,send unit method should test if path is indeed blocked without errors. Also it will show you where the unit actually goes in case it's blocked.
Other than that you may send me map in PM, point on where and when error happens and i will most likely find the error.
I understand, and I try my best to have humility in all things, especially when it comes to computer versus user error. I won't be at all surprised if there's some glaringly obvious stupid thing I'm doing. I'll send my map over when I get back home from work. Thanks!
It appears the pathing cost function have issues with small spaces. (<1) This Behaviors is tied to route finding.
If function returns 65536 then unit sent from/to this point will be stuck trying to take shortcut thru wall even when the 'normal' route is open.
Anyway I consider this to be core bug.
Small theory on why it blocks the maze even with openings >1 wide. (potentially caused by rectangle blocks structure)
Curses, foiled again!
I appreciate everyones help with this issue, especially Nerfpl who went above and beyond. It looks as if I'll have to decrease the map size a bit, and hope that reduces the frequency of this bug occurring.