Wormhole scanner bug?

[Cmdr James]

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

Code: Select all

#if WORMHOLE_SCANNER
- (NSString *) identFromShip:(ShipEntity*)ship
{
	assert([ship hasEquipmentItem:@"EQ_WORMHOLE_SCANNER"]);
	if ([self scanInfo] >= WH_SCANINFO_DESTINATION)
		return [NSString stringWithFormat:DESC(@"wormhole-to-@"), [UNIVERSE getSystemName:destination]];
	else
		return DESC(@"wormhole-desc");
}
#endif

I think the assert should be changed into

Code: Select all

 if (![ship hasEquipmentItem:@"EQ_WORMHOLE_SCANNER"]) return DESC(@"wormhole-desc");

what do you think?

[another_commander]

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.

[Cmdr James]

Hmmm, ok maybe it was just a coincidence that I had a crash on the assert when I was scanning a wormhole.

It did happen in witchspace but I dont think that makes any difference.

I cannot reproduce it right now, so I guess we can ignore it and Ill play some more see if I can do it again.

[another_commander]

You may want to try it with the debug console. Launch from station, type in the console:

Code: Select all

S.mainStation.launchShipWithRole("trader")

then once the trader makes the jump, target the wormhole and execute in the console:

Code: Select all

PS.setEquipmentStatus("EQ_WORMHOLE_SCANNER","EQUIPMENT_DAMAGED")

while scan is in progress.

[JensAyton]

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. :-)

[Cmdr James]

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.

[JensAyton]

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.