1

A SpriteKit game presents MainMenuScene then LevelSelectionScene and finally the GamePlayScene. Once the game is over, in GamePlayScene, the user is transferred back to MainMenuScene like so:

MainMenuScene *newScene = [MainMenuScene sceneWithSize:self.view.bounds.size];
[self.view presentScene:newScene transition:[SKTransition fadeWithDuration:0.5]];

It takes me to the scene but the buttons, that worked previously, don't work anymore. I press them, they seem to do their little animation as if they're being pressed but they don't present me appropriate scenes they're supposed to.

I have a very specific bundle of code activated every time a scene is about to be left and I don't actually know if it influences this whole conundrum:

-(void)willMoveFromView:(SKView *)view
{
    /* Remove anything stuck in memory. */
    [self removeAllActions];
    [self removeAllChildren];
    [self removeFromParent];
    [self.scene removeAllActions];
    [self.scene removeAllChildren];
    [self.scene removeFromParent];
    //[self.scene.view removeFromSuperview]; <--TOTALLY DESTROYS ALLS SCENES IN THE GAME. Don't use it.
}

Has any had previously working scenes presented as partially working duds?

Krekin
  • 1,516
  • 1
  • 13
  • 24
  • There is not enough here to tell you what is going on, but one thing I can tell you, is you do not want to be presenting scenes from within other scenes, You want to make sure that nothing is holding onto the old scene so that it can properly be removed from memory. You should instead setup a delegate that will notify the view when a scene is ready to be removed, and have the view present the new scene – Knight0fDragon Jan 25 '16 at 18:02
  • 1
    `willMoveFromView` is intended to add custom, not to clean content (this is automatically done). – Jean-Baptiste Yunès Jan 25 '16 at 21:23
  • 1
    @Knight0fDragon it is a very common practice to present a new scene from within a scene. With that being said I don't disagree with your approach either. I believe I have even seen Apple examples of calling a new scene from within a scene. Memory wise it isn't a concern as long as your class is constructed properly. – Skyler Lauren Jan 25 '16 at 22:56
  • You should be treating your scenes like you treat your views in your view controller, whoever the parent is should be responsible for swapping out the views not the children. It has actually fixed a number of problems that people have on here, since depending on the code, it could end up causing retain cycles. As we all know. Sprite kit just feels rushed, so we have no idea what is going on behind the scenes that could end up causing issues. With my approach, its one less way to create a retain cycle – Knight0fDragon Jan 25 '16 at 23:05
  • @Knight0fDragon if you want shoot me an email with some links where that has fixed a retain cycle, because I am failing to see how it would. If you set up your delegate wrong (i.e. not making a weak pointer) it actually would cause the problem. My comment still stands that I don't disapprove of your approach but fail to see it as a solution to retain cycles in this case. I would be more than happy to talk about it more, but back and forth in this guys question probably isn't the place. My contact info is my profile. I enjoy talking code and hope to hear from you. – Skyler Lauren Jan 25 '16 at 23:28

2 Answers2

1

From what you said looks like the button is triggering the animation but not the action, still not much information to be sure how to exactly fix it, probably the creation of the actions of the button is working. Double check if the part of the code that creates the SKActions is actually running and active.

1

So I poked around and found out the culprit is in the class I used to create buttons. It's called AGSpriteButton and I highly recommend it (You can find it on github). It has built-in SELECTORS, ACTIONS and BLOCKS functionality offered by default that is very easy to tap into. I'm not sure as to why, but SELECTORS stopped functioning correctly. I just switched to ACTIONS calling my methods & everything works perfectly.

Krekin
  • 1,516
  • 1
  • 13
  • 24