[Release] HUD Selector v1.17

[Diziet Sma]

I had to go back and re-read your posts to be sure I understood what you were getting at, but I think I have it now..

Do you mean, when you want to switch HUDs, find a system selling the HUD Selector, buy it for the nominal fee.. launch, choose the HUD you want from those available, leave it set to that HUD and dock, at which point the HUD Selector is uninstalled, leaving your ship set to your new HUD?


Yeah, I could go for that approach.


I could also see an alternate point of view, whereby you could purchase HUD "software", enabling your ship to display the information in the HUD in new ways, and it is also possible to purchase Selector software, which lets you freely pick from amongst the HUDs you've bought, or the in-built "default HUD" the ship came with, any time you wish.

In other words, HUDs could become buyable equipment. That surely has the most potential as a "money sink".. some of 'em could be quite expensive. Though, as "software", they should not be damageable in combat, short of total ship destruction, as is the case with HUDs now.

[mossfoot]

We're already down that path with the Combat MFD aren't we?

[Norby]

I am sorry for the wrong parenthesis, my copy&paste mistake.

F4 selection will be soon, although I think more easy to compare HUDs during flight.

Here is a preview of original and small HUDs with 6 MFDs:

[mossfoot]

Possible bug - when flying I had the HUD selector on, and when I used other functions other than window view (like F5 and so on) when I came back it would always go to the Numeric HUD (which I was testing out). Anyone have a problem like that?

I have Milspec4000 on there as an OXP, so maybe that's running interference?

[Norby]

Possible bug - when flying I had the HUD selector on, and when I used other functions other than window view (like F5 and so on) when I came back it would always go to the Numeric HUD

Yes, thanks, fixed, together with your another request for MFDs in side views.

[mossfoot]

I wonder if the HUD selector needs to be listed as a prerequisite for the various HUDs? Even if I chose the CombatHudWS as the only HUD on my add-ons, I still get the default HUD (and therefore can't switch unless I have HUD Selector also installed)

On a side note: the MFDs don't seem to consistently stay active. I have to re-activate them whenever I load up my game.

[Neelix]

I wonder if the HUD selector needs to be listed as a prerequisite for the various HUDs? Even if I chose the CombatHudWS as the only HUD on my add-ons, I still get the default HUD (and therefore can't switch unless I have HUD Selector also installed)

On a side note: the MFDs don't seem to consistently stay active. I have to re-activate them whenever I load up my game.

CombatHUD-WS works fine for me and I don't have HUD selector installed.

Ideally you would only *need* HUD Selector if you are running multiple HUDs. I don't think it should be needed if you just want to stick with the one.

- Neelix

[Diziet Sma]

Ideally you would only *need* HUD Selector if you are running multiple HUDs. I don't think it should be needed if you just want to stick with the one.

The only problem with that is, in order to work correctly with the HUD Selector, a HUD needs slight alterations from a standard HUD. After which, it will no longer work as a standalone HUD.

[cim]

The only problem with that is, in order to work correctly with the HUD Selector, a HUD needs slight alterations from a standard HUD. After which, it will no longer work as a standalone HUD.

Maybe the HUD script needs a bit more modification:
1) In 'startUp', check if HUD selector is installed. If it is, register with it, and stop.
2) Otherwise, change player.ship.hud to the HUD name.

[spara]

The only problem with that is, in order to work correctly with the HUD Selector, a HUD needs slight alterations from a standard HUD. After which, it will no longer work as a standalone HUD.

Maybe the HUD script needs a bit more modification:
1) In 'startUp', check if HUD selector is installed. If it is, register with it, and stop.
2) Otherwise, change player.ship.hud to the HUD name.

You also want to do this when a new ship is bought. It won't catch the possibe HUD change when the player ship is changed by an oxp though.

[Smivs]

...in order to work correctly with the HUD Selector, a HUD needs slight alterations from a standard HUD. After which, it will no longer work as a standalone HUD.

Which is why CombatHUD and Smart HUD have not been adapted.

[Diziet Sma]

The only problem with that is, in order to work correctly with the HUD Selector, a HUD needs slight alterations from a standard HUD. After which, it will no longer work as a standalone HUD.

Maybe the HUD script needs a bit more modification:
1) In 'startUp', check if HUD selector is installed. If it is, register with it, and stop.
2) Otherwise, change player.ship.hud to the HUD name.

Then HUD Selector will need some changes as well, I'd say.

Currently, the setup is such that instead of simply having a hud.plist, the hud.plist file needs a unique filename, such as CompactHUD.plist, along with a worldscript as follows:

Code: Select all

this.name = "CompactHUD";
  this.startUp = function () {
    player.ship.hud =  this.name + ".plist";
    var w = worldScripts.hudselector;
    if( w ) w.$HUDSelectorAddHUD("CompactHUD", this.name);
  }

Essentially, what Norby has implemented is along the lines of what you wrote here:

To make HUD OXPs non-conflicting, start by changing them to define oxpprefix-hud.plist rather than hud.plist. Then, write a HUD manager OXP which creates an F4 HUD Selector interface. The HUD OXPs register themselves with the HUD manager OXP (and require the HUD manager OXP in their manifests, of course); the HUD manager OXP then sets player.ship.hud as chosen by the player in the interface (either on select, or stored in a mission variable for reload).

The HUD OXPs could then even optionally sell their HUDs as ship upgrades, and only register themselves with the manager once the equipment is bought (set the equipment to be invisible, transferable between ships, and non-damageable).

If a method could be found that still permitted HUDs to be installed as a standalone item, that would certainly be preferable.

[spara]

I'm still a little uncomfortable with the equipment solution as neat as it is. Game wise I think the best solution would be just an F4-interface. It would fit in nicely with 'name your ship' and other possible customizations. The case of seeing what you get could be solved with suitable images used as a mission screen background.

And this way oxp hud makers could put a price tag to their huds if they desire by making an equipment as cim suggested.

[Norby]

I wonder if the HUD selector needs to be listed as a prerequisite for the various HUDs? Even if I chose the CombatHudWS as the only HUD on my add-ons, I still get the default HUD (and therefore can't switch unless I have HUD Selector also installed)

No need to be listed as required. When I installed CombatHudWS only with HUD Selector OXZ and I was not used the equipment then the CombatHud shown as expected so I do not know how you can get the default hud.

If you use the HUD Selector equipment then you can switch back to the original and small huds, then the CombatHudWS will coming as next under the "Default" name (mean an unsupported HUD which take over the default position).

On a side note: the MFDs don't seem to consistently stay active. I have to re-activate them whenever I load up my game.

As I wrote currently there is no support in core to bring back your MFD settings (in any HUD), but if you would like to get it then you can ask the core developers (mainly cim ) to make the necessary js interfaces, then I can make support in js which save and reactivate MFDs after load game.

There is another problem: if you switch to a HUD which is not define enough MFDs then you must turn on the remaining ones again. For example in NumericHUD you have 16 but in CombatHUD only 2, so you will lose the settings of others in a full round switch of HUDs. I can not solve this at my side, it must be supported by the core or add more MFDs into the HUDs by authors.

If a method could be found that still permitted HUDs to be installed as a standalone item, that would certainly be preferable.

I do not understand your problem. I use the initialization method what cim suggested and you quoted and this is working standalone also.

Which is why CombatHUD and Smart HUD have not been adapted.

You can do it safely: your HUD will work without HUD Selector, so I recommend to adapt your HUDs.
Moreover if somebody install both "old-style-hud.plist-using" and "selfhud.plist-initialized-in-startUp" HUDs then the second will win the race.

I'm still a little uncomfortable with the equipment solution

There are two cases imho:
1. If you imagine the HUD contain hardware elements which need to be replaced in a dock then the F4-only solution is real.
2. If the whole HUD is created by a software in a screen then the pilot should be able to change it during flight and in F4 also.

I vote for the software and there is always an option to do not buy the equipment if you do not like.

[Neelix]

I'm still a little uncomfortable with the equipment solution

There are two cases imho:
1. If you imagine the HUD contain hardware elements which need to be replaced in a dock then the F4-only solution is real.
2. If the whole HUD is created by a software in a screen then the pilot should be able to change it during flight and in F4 also.

I vote for the software and there is always an option to do not buy the equipment if you do not like.

I would argue that in some cases that depends on the HUD. FighterHUD for example (and the variations of it that Cody uses) is very clearly a hardware installation.

- Neelix