[Release] HUD Selector v1.17

[Norby]

In HudSelector v1.4 you can set your scanner to NonLinear and UltraZoom by pressing mode key (b) as many times as needed when HUD Selector primed. Your settings are stored in your savegame.

[Norby]

HUD Selector v1.5 fixed the saving of scanner settings if the equipment is uninstalled.

[Norby]

HUD Selector v1.6 contain a workaround to keep scanner settings even if another crosshair or hud changer script reset the scanner to the default during flight.

This interesting problem is reported by ffutures here: if a script set player.ship.crosshairs = null; then the scanner's NonLinear and UltraZoom values got a reset to the default. Not so logical behaviour in my eyes but a core fix need some time to arrive into a stable release, so now the HUD Selector watch the changes in a FrameCallBack and set the scanner again if needed, which is working but cause a flash on the scanner: if the FCB in Auto Crosshairs OXP decide to reset the crosshair so change the scanner to linear then the HUD Selector detect this in the next frame and set back to nonlinear, so every object in the scanner do a flash if the current zoom is more than 1:1.

[cim]

if a script set player.ship.crosshairs = null; then the scanner's NonLinear and UltraZoom values got a reset to the default.

The way crosshair changing is implemented, the original crosshair definition isn't stored anywhere when you replace it, so putting it back to the default requires rebuilding the HUD. This was absolutely fine before 1.80 added in a whole bunch of other HUD settings which could be modified while the HUD was running...

I'll add it to the list for a fix in 1.80.1 - thanks to you and ffutures for tracking this down.

[ffutures]

if a script set player.ship.crosshairs = null; then the scanner's NonLinear and UltraZoom values got a reset to the default.

The way crosshair changing is implemented, the original crosshair definition isn't stored anywhere when you replace it, so putting it back to the default requires rebuilding the HUD. This was absolutely fine before 1.80 added in a whole bunch of other HUD settings which could be modified while the HUD was running...

I'll add it to the list for a fix in 1.80.1 - thanks to you and ffutures for tracking this down.

Thanks so much for fixing it!

[Wildeblood]

Does this problem occur each time player.ship.crosshairs is changed, or only when it's changed to "null"?
Does the Coluber HUD have its crosshairs definition in a separate file or in the HUD file?
If the answers are no and no, would moving the crosshairs from the HUD file to their own file have solved the problem without additional scripting?

Adding a frame callback to prevent other OXPs changing a setting seems highly bodgey. Will this prevent other scripts from deliberately changing the scanner settings according to context?

[Norby]

Does this problem occur each time player.ship.crosshairs is changed, or only when it's changed to "null"?

Only to null.

Does the Coluber HUD have its crosshairs definition in a separate file or in the HUD file? If the answers are no and no, would moving the crosshairs from the HUD file to their own file have solved the problem without additional scripting?

Coluber HUD is not the source of the problem so does not help if the crosshair definition separated. The problem is exists in all HUDs even if no crosshairs defined at all.

Adding a frame callback to prevent other OXPs changing a setting seems highly bodgey. Will this prevent other scripts from deliberately changing the scanner settings according to context?

This fix is made for Auto Crosshairs OXP, so if this is installed then yes, else detect only and write a warning into the log ("scanner settings is not fixed"). There is a worldScripts.hudselector.$HUDSelectorFixInEveryFrame variable for future use, if any script turn this on then will fix and take over the control of scanner settings from any other (currently nonexistent) scripts. At the moment there is a single case only when I turn this on: if both Auto Crosshairs and Telescope is installed. The reason is if the crosshairs is null and set again to null then I can not detect due to is not changed (but the HUD rebuild and reset the scanner settings), and this two OXP together do something similar, so I must force the scanner settings in every frame.
This is the best what I can do before the core will be fixed.

[ffutures]

Seems to be working well now - MANY thanks!

[Norby]

Original HUD in  v1.8 introduce many custom dials in Oolite 1.81 if [wiki]CombatMFD[/wiki] OXP is installed:

Speed value in speed bar,
Target distance, speed and fired missiles counter in top of speedbar (need CombatMFD equipment),
Compass target distance meter,
Number of damaged equipments and the name of lastly damaged below the scanner,
Player bounty and legal status below the damaged equipment,
Telescope lastly detected target over the shield bar,
Reserve fuel in ly within the fuel bar,
Distance of the nearest planetary object in the altitude bar,
Cargo and Hull (service level) bars between the status light and clock.



These are examples for HUD designers how to make HUDs with more informations for those who does not like MFDs (you can imagine without side MFDs).

[phkb]

Norby, can I make a suggestion? In each instance on "mission.runScreen" you add exitScreen:"GUI_SCREEN_INTERFACES", so the user returns to the F4 screen when the exit (which is where they would have started from). At the moment, when you exit you return to the F5 screen.

Anyway, just some suggestions to improve an already awesome addon.

[phkb]

I've been playing around with HUD's recently. I love beatnik's Coluber HUD - I like the easy to read layout, and it's style is fresh and modern. What I don't like about it is that, when docked, it's too big. A lot of the mission screens end up dropping into the HUD, which looks ugly. Really, there's only two bits of the HUD you need (well, that I need) when docked: the clock, and the number of missiles (and even the missiles are largely redudnant most of the time). Anyway, I decided to get under the hood and see what I could do about it. I created a new HUD plist file, called "coluber_hud_ch01_docked.plist", saved in the same folder as the main plist file. In this file, I only included the missile and clock elements. Then, in the script file, I changed it to look like this:

Code: Select all

this.startUp = function () {
	player.ship.hud =  this.name + ".plist";
	if (player.ship.docked == true) {
		player.ship.hud =  this.name + "_docked.plist";
	}
	var h = worldScripts.hudselector;
	if( h ) h.$HUDSelectorAddHUD("Coluber HUD CH01", this.name);
}

//=============================================================================================================
// ship interfaces
this.shipDockedWithStation = function(station) {
	player.ship.hud = this.name + "_docked.plist";
}

this.shipWillLaunchFromStation = function() {
	player.ship.hud = this.name + ".plist";
}

This seems to work fine - when I launch, I get the full HUD, and when I dock I get the minimized version.

But there's a catch - if the HUD selector is present, it reverts the HUD back to the original, full-sized version.

So (and sorry for taking so long to get here!), my question is: Is there a way to do what I'm trying to do that will still work with the HUD selector? I might be doing it all wrong! Or have I taken one to many dark-side cookies and am now on my own, and need to disable the HUD selector?

[spud42]

cookies 1 phkb 0

[Wildeblood]

Really, there's only two bits of the HUD you need (well, that I need) when docked: the clock, and the number of missiles (and even the missiles are largely redudnant most of the time).

You'll find the fuel bar helpful, too. I used to have a Docked HUDs OXP with three HUD files. One had the fuel bar, one the missile display, and the last the missile display, very faint (opacity 20% IIRC). There was nothing else on them except the clock, and in later versions the commlog position. I think it was lost in the Great Reformat, but if it turns up I'll send it to you. Anyway, becoming relevant, I used guiScreenChanged & playerBoughtEquipment, rather than shipDockedWithStation & shipWillLaunchFromStation (which were used by my main HUD), so it was immune to interference by my main HUD script. It first checked player.ship.docked (Do I really need to say that?), then the fuel and, if necessary, missile count and selected need-fuel-hud.plist, need-missiles-hud.plist or missiles-full-hud.plist (a.k.a. need nothing).

To any non-forum-members reading along, I recommend this as a "my first OXP" exercise. The script is simple, the HUD files are ridiculously simple, the result looks fairly slick, and putting it all together is just tedious enough to leave you feeling satisfied when you finish.

[cim]

So (and sorry for taking so long to get here!), my question is: Is there a way to do what I'm trying to do that will still work with the HUD selector?

1.80 lets you do this without needing Javascript at all - just edit the existing HUD definition and add alert_conditions = 14; to each element you wish to hide while docked. Then you only need one HUD plist file and HUD selector will be fine with it.

[Norby]

add exitScreen:"GUI_SCREEN_INTERFACES"

Thanks, I added in v1.9.

if the HUD selector is present, it reverts the HUD back to the original, full-sized version.

As Wildeblood said you can use the guiScreenChanged event to set back the docked variant, NumericHUD does the same.

Moreover you should define a $HUDSelectorCallBack function (see in the wiki) in your script to deactivate your event handlers otherwise if the player select another hud with hud selector then your handler will change it back.