Torus drive engages when no scanner present

[CommonSenseOTB]

I found what could be viewed as a bug in the hud.plist. In testing I left the main station with no scanner in the hud.plist and accidently engaged the torus drive while I should have been mass locked. Before I could react I was burning through the atmosphere and crashed just before I could pull up. I put the scanner back in and the problem disappeared. Wish I had an external pic just before the crash. That was kind of cool! Leave it in and we can have a scripted spectacular player crash caused by a torus drive malfunction.

[Eric Walch]

It is kind of a bug, yes. If an entity is mass_locking you, is determined within the code that draws the scanner. When that code is skipped there is no way to figure it out. The only thing you could do is always mass_locking without scanner. Somehow that even seems wise. At least I know from car driving that it is not wise to to drive at max speed when visibility is near zero...

[SandJ]

The only thing you could do is always mass_locking without scanner. Somehow that even seems wise. At least I know from car driving that it is not wise to to drive at max speed when visibility is near zero...

That way leads to Health-and-Safety-gone-mad. What if your parking sensor packs up - would you want the car to refuse to allow 2nd gear? You'll be wanting seat belts next. And those heavy double-seal airlocks.

Isn't it down to the ship's commander to decide what is best? That is, if the scanner gets jammed by solar flare, shouldn't the pilot get to choose whether to torus jump away? Or if the scanner is damaged by fire from pirates.

So it could be argue the Torus drive should not be disabled when there is no scanner.

[DaddyHoggy]

In the standard game the scanner cannot be damaged (I asked for this several years ago so that systems which suffered from solar flares could be scripted to knock out the scanner) - so this effect only occurs when you do what CommonOTB did and not put the scanner in the hud.plist...

[another_commander]

It turns out that the drawScanner: method is a pretty freaking important one. Mass locking is affected by it and possibly also other stuff. However, a missing scanner entry in hud.plist should not result in changes to game behaviour so I would definitely accept it as a bug. I had a look at it and have some code for a fix, but I am not sure if this is the best way, so I present it to you for discussion. Here is the drawDials method, after the fix:

Code: Select all

- (void) drawDials
{
	unsigned		i;
	BOOL			isScannerDrawn = NO;
	
	z1 = [[UNIVERSE gameView] display_z];
	for (i = 0; i < [dialArray count]; i++)
	{
		[self drawHUDItem:[dialArray oo_dictionaryAtIndex:i]];
		if ([[[dialArray oo_dictionaryAtIndex:i] oo_stringForKey:@"selector"] isEqualToString:@"drawScanner:"])
		{
			isScannerDrawn = YES;
		}
	}
	if (EXPECT_NOT(!isScannerDrawn))
	{
	  [self drawScanner:[NSDictionary dictionaryWithObjectsAndKeys:	@"0.0", @"alpha",
																		@"0.0", @"x",
																		@"60.0", @"y",
																		@"-1.0", @"y_origin",
																		@"72.0", @"height",
																		@"288.0", @"width",
																		nil]];
	}
}

What happens basically is that as the HUD dials are drawn, they are checked for definition and if a scanner definition is found, then everything is cool, things are as expected. If no scanner definition has been found after all dials have been drawn, then the scanner is forced-drawn using a hard coded dictionary similar to the one in the default hud.plist, but at full transparency. So, the intended (or not) absence of scanner is achieved and at the same time mass-locking behaviour doesn't go in tilt.

If this is considered a non-too-hackish solution, I can commit it anytime. It seems to be at least simple enough to not cause too much disturbance to the codebase at this time. If there are other ideas out there, I'd be happy to hear them.

[CommonSenseOTB]

As long as it has no effect on other scanners or anything else in the hud.plist and will never be visible it appears as a workable solution and mass-locks will still occur(as they should) so the game mechanics remain intact. The question I have is what else is tied into the scanner directly requiring it to be there? Maybe the long-term correct solution is to actually separate these other functions out. A big task probably but maybe worth it.

(thinks about eliminating fiery mass-lock related crashes...) I having a sad.

[Eric Walch]

If this is considered a non-too-hackish solution, I can commit it anytime. It seems to be at least simple enough to not cause too much disturbance to the codebase at this time. If there are other ideas out there, I'd be happy to hear them.

The only alternative I see is not doing this check every time at draw time, but after setting up de dials. If the scanner in not amongst the objects, add your fully transparent version.

(At least did hiding the console by "Pause -> 'o' " not influence the mass-lock in the old situation.)

[another_commander]

Both CommonSenseOTB and Eric are right. The proper fix here would probably be to separate the mass lock stuff from the scanner drawing, but I am very afraid of the consequences and possible bugs that may pop up if we attempt to do this just now. Also, the scanner identification checks are better done during initialization of the HUD dictionaries. This has been implemented in my codebase, it is definitely preferrable to doing the checks every frame and, if nobody objects, the fix in its current form will go in trunk later tonight.