None.
:payne:
In fact, more clutter it is, less path possibilities there are D:
I believe "path" should be understood in a bit different more general way. I think this is related to the area connectivity. That way if there are no obstacles on the map the whole map is connected with a single "path". If there is one solid obstacle there are two "paths" to go around it. And so on. Probably not exactly as I've described (because then the number of paths seem to depend exponentially on number of obstacles), but something very very close to this.
To check my theory I've made a test map. The map doesn't give Nooks and Crannies error, but instead crashes my SC. If I leave about 3100 Doodads it still crashes, however 1260 Doodads it doesn't crash. If I convert doodads to terrain it still crashes.
I believe the solution to the Nooks and Crannies mystery lies somewhere around these things.
To check my theory I've made a test map. The map doesn't give Nooks and Crannies error, but instead crashes my SC. If I leave about 3100 Doodads it still crashes, however 1260 Doodads it doesn't crash. If I convert doodads to terrain it still crashes.
I believe the solution to the Nooks and Crannies mystery lies somewhere around these things.
Some.
:payne:
Anything new, farty?
None.
Could these nooks and crannies have something to do with it?
None.
*sluuuuuuuuuuuuuuuuuurp!* Melee Map Maker
Sorry for bumping this really old thread, but since it came up as an issue in the feature request list for the editor, I thought I'd share my observations here:
The reason for this error is most definitely that the BW engine does some kind buffering at game start (creating nodes for path finding on a macro scale, or something like that), as has already been specuated here:
This is in line with the following observation:
If somewhere on a map terrain is changed in a "meaningful way" (like changing the outline of unwalkable areas, changing terrain levels or placing certain doodad tiles that influence pathfinding, like bridge or ramp tiles), it can change unit pathing behaviour at any other part of the map. A typical example would be that moving a choke point around will usually result in new mining bugs (i.e. bad worker pathing from/to resources) popping up somewhere on the map. So unit pathing is provably influenced by more than just the terrain in its immediate vicinity, which strongly suggests units follow some kind of precalculated pattern.
Tscmoo has probably a pretty good idea about the exact mechanics behind it.
Post has been edited 1 time(s), last time on Apr 1 2017, 1:09 pm by Freakling.
The reason for this error is most definitely that the BW engine does some kind buffering at game start (creating nodes for path finding on a macro scale, or something like that), as has already been specuated here:
Quote from 
The Starport
The Starport[quote=name:JaFF]My friend had this problem. This error occurs when you simply have too many cramped/cluttered places on the map. It is not just one small place that causes it; you just need to break some set of rules or some test SC performs before launching the map. Tux'es pathfinding AI explanation seems to be the most logical one.
This is in line with the following observation:
If somewhere on a map terrain is changed in a "meaningful way" (like changing the outline of unwalkable areas, changing terrain levels or placing certain doodad tiles that influence pathfinding, like bridge or ramp tiles), it can change unit pathing behaviour at any other part of the map. A typical example would be that moving a choke point around will usually result in new mining bugs (i.e. bad worker pathing from/to resources) popping up somewhere on the map. So unit pathing is provably influenced by more than just the terrain in its immediate vicinity, which strongly suggests units follow some kind of precalculated pattern.
Tscmoo has probably a pretty good idea about the exact mechanics behind it.
Post has been edited 1 time(s), last time on Apr 1 2017, 1:09 pm by Freakling.
None.
I see you !
FYI: https://www.codeofhonor.com/blog/the-starcraft-path-finding-hack#comment-806548411
(Refresh twice if it doesn't jump to the comment)
(Refresh twice if it doesn't jump to the comment)
The sword and the faith
Quote from Suicidal Insanity
FYI: https://www.codeofhonor.com/blog/the-starcraft-path-finding-hack#comment-806548411
(Refresh twice if it doesn't jump to the comment)
(Refresh twice if it doesn't jump to the comment)
SEN Global Moderator and Resident Zealot
-------------------------
The sword and the faith.
Sector 12
My stream, live PC building and tech discussion.
🤙🏾
I've got a lot of experience messing around with this error. Basically Vrael's image above is right, you will see improvements if you stomp nooks like that with large patches of either pathable or unpathable terrain but not a mix of the two, some types of terrain brushes a thin pathable edge automatically which takes a lot of non-ISOM stomping to correct.
Obviously you can only afford to do that in areas outside the visible play area, or where the artificial terrain is not too visible unless the player gets really nosy.
Another thing that unintuitively helps is adding lots of flat pathable terrain around a complex nook'd area, even if there is already a good amount of pathable terrain around it, for some reason this also helps.
Check out Eternal Death to see the kind of extensive surgery you can do to keep a complex map going.
Obviously you can only afford to do that in areas outside the visible play area, or where the artificial terrain is not too visible unless the player gets really nosy.
Another thing that unintuitively helps is adding lots of flat pathable terrain around a complex nook'd area, even if there is already a good amount of pathable terrain around it, for some reason this also helps.
Check out Eternal Death to see the kind of extensive surgery you can do to keep a complex map going.
🤙🏾
*sluuuuuuuuuuuuuuuuuurp!* Melee Map Maker
Quote from Suicidal Insanity
FYI: https://www.codeofhonor.com/blog/the-starcraft-path-finding-hack#comment-806548411
(Refresh twice if it doesn't jump to the comment)
(Refresh twice if it doesn't jump to the comment)
Quote from name:Patrick Wyatt
The basics of the set of path-finding algorithms, which were authored by Brian Fitzgerald (who will consequently be able to speak with much more authority on the subject) were:
1. On map-load, split the map cells into regions which were small (say roughly 10x10 32x32 tiles on average), contiguous and didn't contain any major obstacles. Path-finding inside these areas could be done using A* with few occasions for bumping into obstacles.
2. On map-load, create a higher-level map containing region adjacency. Because the regions were irregularly shaped, this higher level map was a graph of nodes rather than a tile-map.
3. For inter-region path-finding use A* on the higher-level map so that it was not necessary to grind through *every* *single* *8x8* tile on the map -- too time-consuming.
4. As units moved, mark their locations on the individual cells they occupied. Traverse around occupied cells, with lots of special case logic for all sorts of edge cases, unit behaviors, and occupancy cases (bad vs. allied units). The special-case logic included a state machine with something on the order of 40 different states, if I recall correctly.
5. Separate pathing behavior for flying units, obviously. I plan another article on another hack used for flying units.
1. On map-load, split the map cells into regions which were small (say roughly 10x10 32x32 tiles on average), contiguous and didn't contain any major obstacles. Path-finding inside these areas could be done using A* with few occasions for bumping into obstacles.
2. On map-load, create a higher-level map containing region adjacency. Because the regions were irregularly shaped, this higher level map was a graph of nodes rather than a tile-map.
3. For inter-region path-finding use A* on the higher-level map so that it was not necessary to grind through *every* *single* *8x8* tile on the map -- too time-consuming.
4. As units moved, mark their locations on the individual cells they occupied. Traverse around occupied cells, with lots of special case logic for all sorts of edge cases, unit behaviors, and occupancy cases (bad vs. allied units). The special-case logic included a state machine with something on the order of 40 different states, if I recall correctly.
5. Separate pathing behavior for flying units, obviously. I plan another article on another hack used for flying units.
@Excalibur: They are not gonna touch the core of pathfinding, because it is the essential element of gameplay and hence balance to define Brood War. We would probably very lucky already if the most fatal fringe cases (like units-stacked-and-stuck-on terrain bugs, including the infamous "ramp vortex" [I don't really like that term, because it focuses to much on one special case]) will be resolved...
None.
[05:05 pm]
Vrael -- Its simple, just send all minerals to Vrael until you have 0 minerals then your account is gone[2024-4-14. : 9:21 pm]
O)FaRTy1billion[MM] -- there are some real members mixed in those latter pages, but the *vast* majority are spam accounts[2024-4-12. : 12:52 pm]
Oh_Man -- da real donwanoda real donwano shouted: This is the first time I've seen spam bots like this on SEN. But then again, for the last 15 years I haven't been very active.
it's pretty common[2024-4-11. : 9:53 pm]
da real donwano -- This is the first time I've seen spam bots like this on SEN. But then again, for the last 15 years I haven't been very active.