Post

Replies

Boosts

Views

Activity

Understanding an assertion failure in a crash log
Last night my iPhone game crashed while running in debug mode on my iPhone. I just plugged it into my Mac, and was able to find the ips file. The stack trace shows the function in my app where it crashed, and then a couple of frames in libswiftCore.dylib before an assertion failure. My question is - I've got absolutely no idea what the assertion failure actually was, all I have is... 0 libswiftCore.dylib 0x1921412a0 closure #1 in closure #1 in closure #1 in _assertionFailure(_:_:file:line:flags:) + 228 1 libswiftCore.dylib 0x192141178 closure #1 in closure #1 in _assertionFailure(_:_:file:line:flags:) + 327 2 libswiftCore.dylib 0x192140b4c _assertionFailure(_:_:file:line:flags:) + 183 3 MyGame.debug.dylib 0x104e52818 SentryBrain.takeTurn(actor:) + 1240 ... How do I figure out what the assertion failure was that triggered the crash? How do I figure out what line of code in takeTurn(...) triggered the failing assertion failure?
2
0
76
Jun ’25
SKNode calculateAccumulatedFrame() returns wrong frame
I'm writing a SpriteKit game in Swift that does this familiar dance in my GameScene touchesEnded(...)... let touch = touches.first!.location(in: self) let nodes = self.nodes(at: touch) ...but sometimes when the game is running, the nodes collection is empty, even though there are clearly, visibly nodes under the touch. All of the nodes I care about are children of a single SKNode, MapNode, that is one of two children of the GameScene. After a bunch of debugging, I've noticed that when this problem happens, something is causing calculateAccumulatedFrame() to return a frame that is way, way smaller than the real bounds of MapNode. When the scene begins, calculateAccumulatedFrame() is perfect, but something that happens later on breaks it. I've tried adding a node to MapNode that is the correct size to 'force' calculateAccumulatedFrame to do the right thing, but this doesn't work. Is there something obvious I am doing wrong, or some common pitfalls? Is there some way to force calculateAccumulatedFrame to return this correct size?
1
0
729
May ’24