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 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 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:
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 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.
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'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!
0
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.
0
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!
0
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.
0
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.
0
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.
0
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.
0
@Nerfpl: Go
I thought that was weird, too. Is there another reason it might think the pathing is blocked when it isn't?
0
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!