Question

I Have the following code:

-(void) changeAnimation:(NSString*)name forTime:(int) times {
 if(currentAnimation != @"attack")
 {
  id action = [CCAnimate actionWithAnimation:[self animationByName:name]];
  id repeatAction = [CCRepeat actionWithAction:action times:times];
  currentAction = [self runAction:repeatAction];
  lastANimation = currentAnimation;
  currentAnimation = name;
 }
 else if(currentAction.isDone)
 {
   //Here is where I would change the animation
   //but I commented the code for now
 }
}

So when I run this and click on the button that changes the animation to “attack” (by calling [mysprite changeAnimation:@”attack” forTime:1];), I get a EXC_BAD_ACCESS error from the “currentAction.isDone” line, the next time the function is called (the joystick will call changeAnimation to try and change the animation to “run” or “idle”, but I want the attack animation to finish first). Any thoughts on whyI get this? currentAction is declared in my class.

Edit: there is nothing in the rest of the class that interacts with currentAction, beside a getter. Its declaration is in the .h (CCAction* surrentAction). Do I need to initialize it? I thought the returned value from runAction would be sufficient? ANyways, when I run the debugger, it is not nil, and assigned to the correct action.

Thanks,

Dave

Edit:
I ended up creating a sequence when “attacking” that calls a function that changes the currentAnimation, so i avoided the issue. Still no idea what was happening.
Here’s the answer if your interested:
Other Post

Answer 1

More of the class is probably needed to really answer this properly, but the EXC_BAD_ACCESS typically happens because you’re accessing something that has been released and is no longer available in memory.

I’m guessing that somewhere in your class you’re releasing, either explicitly, or implicitly, the “currentAction” object asynchronously – and when you’re checking later, it’s done & gone and you’re hitting this crasher.

In general, keeping a state variable or two that you always have known values on is a good way to go, and for the “actions” that you’re going through, if they’re asynchronous and doing their own memory management, leave them as such and work through some state variables that you maintain and control all the memory management around. It’s a pretty reasonable pattern for asynchronous callbacks, either with the classic stuff or as you move into using blocks with iOS 4.0