I've had the same issues with new codebases. When I'm learning the system, and really, even up to the point that I'm an expert, there is always a gate somewhere you have to decide to go through. You find a bug, or can't find where to make a change and you have to decide whether to start digging deeply into the source code, which may never give you the answer, or ask someone more senior than you. It's a tricky line to find because you don't want to be "guy who can't RTFS and always needs help" or "guy who spend 4 hours looking for bug because he didn't know that and extra CR at the end of the file kills the process."
I have no good rule for making the decision, though it gets easier to make as you learn a system. Right at the beginning it's very hard to tell, though you do learn from randomly tracing through the source, so there isn't much wasted effort there. The decision does give me some anxiety, but not much. I guess I feel sort of fatalistic about it. Since it's largely unknown where you will fall between the two extremes, you might as well make a good effort on your own, but after a short time, sod the consequences, you need to get work done, so just ask.
Generally I am rewarded (as in your case) with some nugget of crucial info that I didn't know I needed that lets me get on with my day.
Yeah, I guess some of the brutal-summary take away lesson might be:
* yes, some problems are going to suck
* rely on your friends (/coworkers), though hopefully without seeming too dependent...
Friendly fire is hard to do by accident in Starcraft. The most likely way to destroy one's own base is to manually order units to attack your own buildings one by one. One could also manually order units to attack other units one by one, but that's micromanaging one's own stupidity.
I guess the lesson learned here is to try to figure things out for yourself (best way to learn IMHO), but set a time limit or a limit on the number of attempts. (If at first you don't succeed, try again. But then stop, there's no point in being a damn fool about it.) At that point ask for help. Maybe the other person knows the problem (other knows who knows), or can spot the solution you missed, or agrees that this is a toughy.
I remember years ago I was load testing a telephony solution. The target was 2 calls per second for 48 hours. I'd set the environment up and let it rip. But the next day the system would crash. (Part of the problem was a positive feedback loop caused by an interaction between the test system and the solution.) I don't know how many times I tried to get it to work; tweaking things, lowering the call volume. After a couple of weeks a senior guy suggested starting with a much lower call volume so we at least hit the 48 hour mark.
From the way I read it, you were working with an old version with a well known bug. Does it hurt to go, "Hey, I'm working with this old version (or even if you're just starting to use a current one), is there something I should look our for?"
BTW, that cat picture, kinda freaky in a cute way that only cats can do. Too much intelligence, which I'm not sure is there or not. Those sneaky, sneaky cats. . .