Possible causes:

Possible solutions:

Many says it could be due to a buffer overflow of some kind of test practiced by SC's console when starting a map. It'd calculate all the AI pathfinding and if the size of the temporary file created is too big, it gets deleted.
Moreover, since protecting maps often delete the ISOM part of maps' code, all the tiles become "extended" (rectangular) and it increases the chances of getting the error.

Post has been edited 2 time(s), last time on Jan 21 2010, 11:14 pm by payne.

rawr i think its just that scmdraft hates me

Probably something to do with isom corruption. You can probably just compress it and fix the problem.

My two theories are either that there's some buffer limit for the game's pathfinding AI that begins to fill up when complex terrain is present, or concave corner blends somehow use up some kind of buffer of their own. Worth testing if certain specific tiles cause this effect or not.

I suspect it's Blizzard's dollar-store pathfinding AI.

well... i tested this and the only way i could recreate the error is by filling the map with natural looking isom terrain everywhere and covering it with one kind of doodad converted to terrain...

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.

Laura and I did some extensive research on this due to the Station maps being so prone to the error. Wherever there is an area the players wont be using, or in non-viewable parts of the map, turn any tiles into plain walkable terrain.

Then could someone explain me how the hell CD do not get this error? We all do agree it is very cluttered. ;o

Since we do not know the criteria SC uses, we cannot answer that question. Perhaps it is cluttered in an 'acceptable' way.

CD isn't big enough... if it would use nearly 256x256 you would get the error.

That would make sense. I know from programming that some kinds of optimizations are only possible before you start some activity. Since map terrain is mostly immutable, it stands to reason it makes a good 'base' for defining an early node tree for the pathfinding AI to work off of. That node tree must be limited to a certain size in memory for Starcraft to meet its advertised system specs.
Or maybe only because the programmers were too lazy to use dynamic allocation.

Post has been edited 2 time(s), last time on Sep 16 2009, 7:47 pm by Tuxedo-Templar.

I think CD doesnt get the error because theres a variety of everything on that map, instead of just custom doodads it has real doodads and custom doodads and normal isom terrain and mud and rocky dirt and all that, theres a variety. And I forget who told me, but CD DID get the error, woodenfire just stuck the null tiles on the side. Atleast thats what i heard.

I got this error again and I tried the Null tricks. It worked, though I decided not to stop there. I've tried to replace all these null tiles by isometrical Dirt terrain... and it worked.
Also, it might help researches: when I tried to open the map in SC with a third party program (iCCup), iCCup crashed with a memory error so you guys might be right ;o

I had a giant lake in the middle of my map that wasn't really needed and decided to turn most of it into dirt and the error disappeared, for now at least. Certain types of terrains used in different amounts probably effects whether you will get the error or not. If you use 256/256 and fill up most of the map you will probably get the error like me

I actually had this error on a 128x128 map. This map, somehow, had every single isom tile converted into rec tiles. I can't remember how that happened, but many other things in that map were prone to corruption. I call it the perfect map protection.. If you edit a single trigger, the map then becomes unstable and causes SC to crash. If you edit (almost) any string, the map will become unstable. Lucky for me, this happened after I used a map protector.

Anyways, when my terrain was first converted, somehow, to pure rec tiles from a state of pure isom, I got the "nooks and crannies" error. What I did to solve this, was I re-made a large portion of the terrain back into its original isometric state, and then the error stopped appearing. I am assuming that there is a pre-test that SC runs on the terrain, a sort of scan. It checks the terrain against a set of rules, and if you fail you are shot back out to the main menu of SC. My "broken rule" was obviously corrupted terrain in some form or another.

Just thought this info might be of some use. And to clarify, my terrain was changed to rec before I used the protector. Everything else becoming corruption prone was a result of my map protector.

Post has been edited 2 time(s), last time on Sep 20 2009, 9:03 pm by CecilSunkure. Reason: Typo

Could it potentially have to do with sections of terrain like this:

Where many units will not be able to fit through but smaller ones such as zerglings can?

I say no, because I had this problem when my map was nothing but Regular Iso terrain, before I joined SEN. It was in an old map of mine that had nothing but regular iso terrain and I encountered it in several maps. My opinion, is looking back on that, I used several different levels of terrain (low, mid, high) and were mostly in-accessible to each other. These maps were all 256x256 and I noticed that Space terrain did it most often and Jungle practically never did.

Something strange about this bug...

I actually had a map with no error UNTIL i protected it. Once protected, it was unplayable due to nooks and crannies error.

So apparently CD *DID* get the error, woodenfire just stuck all that null on the map and it went away.

EDIT
Oh geez my bad... i already posted this...

I heard that copying and then pasting the terrain (removing the ISOM i guess) got rid of this error. Truth?