Sniper Sight - MilHUD integrated

[Wildeblood]

About the contraster: would it be possible to have just the contraster as a buyable "flare" equipment?

Just a thought.

Explain more. What do you mean by "flare"?

[Zireael]

Just that. You buy it (whatever we do call it) and you get the contraster in the middle of your screen/hud like in MilHUD. Makes for easier spotting of enemies.

[Wildeblood]

Yeah, it can be done, but why would you want to buy it? If you want to add just that to your HUD, just do it, you know. Making it buyable equipment is just unnecessary complication. It means one more script running at startup to change the HUD from the standard to the one you've bought.

[CommonSenseOTB]

About the contraster: would it be possible to have just the contraster as a buyable "flare" equipment?

Just a thought.

Yes, but not yet. This will be possible when the legends section of the hud.plist is modified to allow "equipment_required" for activation just as the dials section does. This will be added in 1.76 I hear.

Cool idea!

[Cmdr Wyvern]

Version 1.0 of MilHUD way back in Oolite 1.65 days featured a contraster and central dot, features that made it into various other HUDs. It was just that awesome.

I just noticed that this evening. How's it done? Obviously with a PNG overlay, but slightly more specifically, how's it done (the contraster, I know how to draw a dot)?

The contraster, like the dot, is a .png called from an entry in the 'legends' section in hud plists.
The trick is in how the contraster image is made. The image is a filled white circle with an alpha channel. I dialed the transparency of the alpha channel to 50% in GIMP, and the alpha key in it's plist entry can be used to fine tune it.
It's original purpose was, and is, to brighten up objects that fall into the sighting zone - really useful for aging eyes and aging monitors that otherwise wouldn't see those objects.

[another_commander]

What about that more serious bug discussed up there ^, is it a documented one or not? Why isn't there a big, obvious link to the bug-tracker at the top of every page?

It is not and I have just confirmed it. I believe (without having gotten down to the bottom of it yet) that the crash is due to the fact that the HUD is changed via the compassTargetChanged handler before all its elements have been parsed.

The crash is happening even if I take an exact copy of the vanilla hud.plist, copy it under the name sniper-hud.plist in the OXP's Config folder and try to use the Sniper equipment with a Nav Buoy targeted. The interesting thing is that most times it will look OK if run outside of the debugger, but gdb will always stop the program execution with a segfault at that point.

As to why there is no big obvious link etc., well, someone will have to actually go and report it in the bug tracker first. Feel free to open a Berlios account if you want and enter it in the database. The link is http://developer.berlios.de/bugs/?group_id=3577. This link is also on the sticky at the top of the Testing and Bug Reports forum, so it doesn't have to be on the top of every page.

[Capt. Murphy]

I had another CTD this afternoon - I reopened Oolite after the crash with a -nosplash flag, which on my machine brings up the window with the graphics exactly as it was when Oolite closed until the spinning cobra appears. The standard HUD was only half drawn.

[Wildeblood]

I had another CTD this afternoon - I reopened Oolite after the crash with a -nosplash flag, which on my machine brings up the window with the graphics exactly as it was when Oolite closed until the spinning cobra appears. The standard HUD was only half drawn.

Is this going to turn into the crash reporting thread? I'm not going to take the blame for all of them. I used to get frequent CTDs when I had 153 OXPs in, I always suspected Frame's Bounty Scanner was the culprit.

Where do I put this -nosplash flag Capt. Murphy mentions on a Win7 machine?

[Capt. Murphy]

http://wiki.alioth.net/index.php/Hidden ... _in_Oolite

or add -nosplash to the command line of the short-cut you use to open the game.

C:\Oolite\oolite.app\oolite.exe -nosplash

You don't need to take the blame for the crash. It's a bug in the game engine that you just happen to have discovered (we are on a beta phase after all). Another-commander is on to it - all will be well.

[another_commander]

For reference, the crash discussed earlier is now tracked as Berlios bug #18189.

[Wildeblood]

For reference, the crash discussed earlier is now tracked as Berlios bug #18189.

Thank you very much, another_commander.

[another_commander]

For further reference, bug #18189 should be resolved with r4568. Please test tomorrow's nightly builds with the equipment version of the sniper HUD.

[Capt. Murphy]

Will do...

[Capt. Murphy]

another-commander,

I'm using a slightly modified version of the equipment version with a little extra code to ensure compatibility with the Target Reticle Sensitive OXP. The code below worked in r4567 and 1.75.2

Code: Select all

this.compassTargetChanged = function(whom, mode)
	{
	if (player.ship.equipmentStatus("EQ_SNIPER_SCOPE") != "EQUIPMENT_OK")
			{return;}
	else if (mode == "COMPASS_MODE_TARGET")
			{player.ship.hud = "sniper-hud.plist";}
	else if (mode != "COMPASS_MODE_TARGET" && player.ship.hud == "sniper-hud.plist")
			{
				player.ship.hud = "hud.plist";
				if (missionVariables.reticleTargetSensitive == "TRUE")
				{
					player.ship.reticleTargetSensitive = true;
				}
			}
	}

It looks like the CTD fix in r4568 stops this working (i.e. the standard HUD again loses the reticleTargetSensitive status on switching from sniper-hud.plist), presumable because the hud redrawing is now being delayed? Can easily be rectified using a Timer to delay the missionVariable check, but that seems like a bit of a fudge.

On a positive note no CTD so far.

edit to add:

this works to maintain the reticleTargetSensitive status on r4568.

Code: Select all

this.compassTargetChanged = function(whom, mode)
	{
	if (player.ship.equipmentStatus("EQ_SNIPER_SCOPE") != "EQUIPMENT_OK")
			{return;}
	else if (mode == "COMPASS_MODE_TARGET")
			{player.ship.hud = "sniper-hud.plist";}
	else if (mode != "COMPASS_MODE_TARGET" && player.ship.hud == "sniper-hud.plist")
			{
				player.ship.hud = "hud.plist";
				if (missionVariables.reticleTargetSensitive == "TRUE")
				{
					this.reticleTargetSensitiveTimer = new Timer(this, sniper_scope_reticleTargetSensitive, 0.25);
				}
			}
	}

this.sniper_scope_reticleTargetSensitive = function()
{
 player.ship.reticleTargetSensitive = true;
}

[Wildeblood]

another-commander,

I'm using a slightly modified version of the equipment version with a little extra code to ensure compatibility with the Target Reticle Sensitive OXP...
It looks like the CTD fix in r4568 stops this working (i.e. the standard HUD again loses the reticleTargetSensitive status on switching from sniper-hud.plist), presumable because the hud redrawing is now being delayed? Can easily be rectified using a Timer to delay the missionVariable check, but that seems like a bit of a fudge.

On a positive note no CTD so far.

Wouldn't moving the check up to here (with appropriate insertion of mysterious semi-colons) suffice:

Code: Select all

this.compassTargetChanged = function(whom, mode)
	{
	if (player.ship.equipmentStatus("EQ_SNIPER_SCOPE") != "EQUIPMENT_OK")
			{return;}
	else if (mode == "COMPASS_MODE_TARGET")
			{player.ship.hud = "sniper-hud.plist";}
	else if (mode != "COMPASS_MODE_TARGET" && player.ship.hud == "sniper-hud.plist")
			{player.ship.hud = "hud.plist";}

	if (missionVariables.reticleTargetSensitive == "TRUE")
			{player.ship.reticleTargetSensitive = true;}
	}

Too, Capt. Murphy, I'll take this opportunity to say, I ignored this "issue" when you first mentioned it last week, in the sense that I did not make an "Oh no!" reply here, but I did give it a little thought. It went unnoticed by me because I set the target reticle sensitive flag directly in hud.plist, as I supposed that anyone else who customizes their HUD would do.