Page 1 of 1

Dynamic HUDs quirk / StartUp

Posted: Mon Dec 13, 2010 2:20 am
by JeffBTX
There seems to be 8 downloadable HUD OXPs on the Wiki, and I believe 2 of them are Dynamic HUDs: Killer Wolf's Dynamic HUD and the most recent version(s) of MilSpec HUD. Sorry if I am incorrect about that; anyway those 2 Dynamic Huds are what I used to learn from.

They both have a certain quirk, and probably EVERY Dynamic HUD being used most likely has the same quirk... you start up in Oolite with the DEFAULT HUD, and you have to launch from the station to see the new HUD. At your first docking you will see the Dynamic HUD's "docked hud" for the first time.

Most likely everyone is basically just passing around the same Dynamic Hud script, and doing what I've done... learn by studying the work of others. This "minor issue" isn't talked about much, and just seems to be an accepted quirk. EASY to fix.

Reason (1): The scripts in these HUDs depend on changes to your Alert Condition before they will switch to anything new. When you start Oolite, you START in a docked condition. When you launch, you change to (usually) Condition Yellow. (or possibly Condition Red if there are hostiles around, or POSSIBLY Condition Green with certain OXP dockables... though I doubt it, because probably you will be mass-locked).

Reason(2): When Oolite starts, it looks for "hud.plist". Most likely (just a guess here) Oolite loads the default hud.plist from the Oolite\ ... \Resources\Config folder. THEN, if an OXP has a hud.plist file, Oolite will load it, overriding the default hud.list. OR Oolite looks for hud.plist in any OXPs first (I doubt that this is the case).

SO....

In whatever Dynamic HUD OXP your are using, make a COPY of that HUD's "docked condition" HUD. RENAME the COPY to "hud.plist", putting it into that HUD's OXP Config folder (if it isn't there already).

I did this for mine... doesn't seem to cause any problems. Flew to a Non-GalCop station to make sure (in my present installation, there are only Rock Hermits in this category). Everything worked fine.

Posted: Mon Dec 13, 2010 2:38 am
by Mauiby de Fug
Yep, I had this issue to! Or at least, it showed the default hud when Oolite starts, then when I chose "Y" to select a commander I saw the docked HUD, and then it reverted to the default HUD after the commander had loaded.

Your fix appears to work for me (I'm using MilHUD) - thanks!

Posted: Mon Dec 13, 2010 12:26 pm
by Svengali
JeffBTX wrote:
They both have a certain quirk, and probably EVERY Dynamic HUD being used most likely has the same quirk... you start up in Oolite with the DEFAULT HUD, and you have to launch from the station to see the new HUD. At your first docking you will see the Dynamic HUD's "docked hud" for the first time.
To understand what happens here it is necessary to know which event-handlers are fired under what kind of situation, specially if you want to avoid a Timer.

Code: Select all

                        app start - Jameson             |   loaded savedgame
                        new career  died  died on F5    |   loaded  died  died on F5
startUp                     Y         Y       Y         |      Y      Y       Y
guiScreenChanged            Y         Y       N         |      Y      Y       N
missionScreenOpportunity    Y         Y       Y         |      Y      Y       Y
alertConditionChanged       Y         Y       Y         |      N      Y       Y
As you can see a script has to handle different situations (and e.g. BGS does it).

Posted: Mon Dec 13, 2010 12:36 pm
by Disembodied
One quirk/minor niggle I have with dynamic HUDs is that – presumably when the HUD switch occurs – the scanner seems to lose touch with a ship that's sent a message. For example: I'm flying along, and a ship ahead of me send out a distress call. The signalling ship is marked with the usual (((*))) on the scanner. If I then bring up the comms log, and the most recent signaller is still on the scanner, the (((*))) marks are still shown. I dive in to the rescue and despatch the bad guys, causing the HUD to flick to red alert and then back again. But if I bring up the comms log again, even if the ship who signalled is still on the scanner, there are no (((*)))s displayed.

It's not a major problem – although I do sometimes want to use the (((*))) to quickly identify the ship I'm trying to help in the middle of a furball ...

Posted: Mon Dec 13, 2010 12:44 pm
by Killer Wolf
would it be possible/better to have a change put in so that the scanner displays a ship in distress as a flashing stalk, or something like that? until such time as its status changes, by death or rescue? ive had that prob too, you dive into a fight w/ several red and yellows and you lose who's in trouble fairly quickly.

Posted: Mon Dec 13, 2010 12:46 pm
by Cody
I don’t use a dynamic hud… if I did, that would definitely be a problem… in the middle of a firefight, as Disembodied says, you often need to ID the ship that sent the distress call.

Posted: Mon Dec 13, 2010 1:43 pm
by Disembodied
Killer Wolf wrote:
would it be possible/better to have a change put in so that the scanner displays a ship in distress as a flashing stalk, or something like that? until such time as its status changes, by death or rescue? ive had that prob too, you dive into a fight w/ several red and yellows and you lose who's in trouble fairly quickly.
Ooh! Neat idea! +1 from me on that. Although we'd need to think of a good colour combination: most of the good ones are taken. Maybe something like yellow/black? You don't want to get it confused with, say, an armed q-bomb ...

Posted: Mon Dec 13, 2010 2:41 pm
by Cody
+2 from me… if not a flashing trace, maybe it could keep the (((-))) marks until its status changes.