I have just had a crash (in trunk, OSX) which I think was caused by having the wormhole scanner damaged while having a wormhole targetted and scanned. The crash happened on the assert in WormholeEntity.m
I tried it twice by damaging the wormhole scanner via DebugConsole, once while scanning was in progress and once when the wormhole had been already scanned. In both cases I got a "Target lost" message and the game continued normally. James, is there any other way to make the bug occur?
I think that if this assert is hit, there should really not be any indication that the wormhole is recognized as a target. Without the scanner, the player should not be able to target wormholes at all.
For this sort of shouldn’t-happen-but-doesn’t-indicate-horrible-brokenness stuff, returning nil rather than asserting is more idiomatic Obj-C and has the advantage of usually not crashing. :-)
Thanks, thats what I have been doing, and it seems to be ok.
Edit, for the record, I have a background in Java, and therefor assumed that assert handling might be kind of funny and blow up when running in debug (in Java you can chose to have assert testing on or off, and asserts throw exceptions when violated), but I think I read too much into it.
C asserts call abort() (i.e., crash) by default, and do nothing if NDEBUG is defined. OpenStep NSAssert(), NSCAssert(), NSParameterAssert() etc. throw exceptions by default, and do nothing if NS_BLOCK_ASSERTIONS is defined.
The Mac project disables assertions for Deployment builds, and leaves them in for Debug and TestRelease builds. The GNUstep builds disable C assertions if build with DEPLOYMENT_RELEASE_CONFIGURATION=yes, but does nothing about OpenStep assertions at the moment.