Proposals for Oolite 1.79/1.80, 2 of 5: HUD improvements

[cim]

Here's the second proposal, for general additions and adjustments to HUD functionality, based on various requests that people have made. There's a few areas (in italics) where the proposal is very definitely in draft form, but thoughts as usual are welcome on any of it, both from OXP-writing and player perspectives.

TSME: Target System Memory Expansion
STE: Scanner Targeting Enhancement
MTS: Multi-Targeting System

HUD Improvements
A set of HUD changes intended to make scripting easier and improve HUD functionality in general.

Problem
Customisation of HUDs from script is not straightforward. Use of console messages to display arbitrary text semi-persistently (as is becoming popular) is difficult to make compatible with other OXPs doing the same thing and can be inefficient. Some potentially useful functionality is missing or requires inefficient workarounds to implement.

Proposal
Add some additional features to HUDs:

• Waypoint display. Allow waypoints to be defined (player.ship.waypoints, player.ship.addWaypoint(...), etc.) and then displayed as line-drawn objects with attached names. Probably should require an ASC to be fitted. Waypoints may have orientation as well as position.
• Additional dial for currently primed equipment name, with option to make multi-line and show next/previous items too. (should we add this to the default HUD?) Probably it should be invisible if no equipment is selected.
  
  While we're here, though it's not strictly HUD-related unless we decide these need a dial too: we currently have two items which currently act a lot like primable equipment (and could be duplicated by one) but have keys reserved specially for them - the energy bomb and the {secret item}. What we could do is rename those keys to "contingency device" and "special equipment", and allow the player to select while docked via an interface screen a primable equipment item to bind to each slot (with the current devices as default; some careful work needed with the interface to not reveal the existence of the {secret item} if it's not installed). Pressing the key would then send 'N' to that equipment without affecting the Shift-N cycling setting.
• Additional dial for current ASC target beacon code. (should we add to default HUD?)
• Optional setting to display low-opacity rectangles around TSME-tracked ships if STE installed. What colours should these be?
  • Same as current STE target? (i.e. green for ship, blue for wormholes)
  • Scanner colours?
  • Different colour for missile-locks if MTS installed?
  As with reticle-sensitive, probably not enabled on the default HUD - should we provide equipment to enable this, or leave it to OXPs? Should the rectangles have ship names like the current target or just be rectangles?
• Customisation of STE label - font-scale as requested, and also allow the text to be set with a description string "[oolite_ste_displayname]\n[oolite_ste_range] ([oolite_ste_legalstatus])"
• Not sure about this one, but: is it actually right that red/yellow hostility depends on weapon range? You can get very strange effects if a ship has different weapons on different facings, as it switches between them. I'd prefer 'red' to be any normal ship that is targeting the player in a hostile way (should defence targets count? only if the ship has point defence weapons?)
• HUD Overlays - scriptable HUD text controls (see below)

Overlays
HUDs would define overlay regions like other dials. HUDs could define more than one overlay region, though they shouldn't overlap. When an overlay is not in use, it will not be drawn. Default HUD would probably add two, one on the left edge and one on the right edge, below the comm log.

Scripts could then enable and disable their own overlays (most often on events, or on primable equipment), and refresh the overlay to replace the contained text.

Enabled overlays would be put in a stack, last-enabled at the top. The overlays would then be displayed from the top down in the various overlay regions on the HUD, until all overlay regions were used. Ideally: overlays stick to their current region if possible, rather than rotating around every time a new one is added or an old one removed; and ideally: a short overlay-changing animation rather than an instant switch.

To make overlays generally usable by OXP writers, they would probably need to have a constant width and height in terms of text characters. (Suggestions for what this should be? 8-10 lines of 25-30 characters seems about right)

OXP writers can't guarantee that the overlay will be visible, as that depends on equipment activation order, etc. (And the HUD having any overlays, but they can be added...) Since they should generally be bound to equipment under player control, it's the player's job not to activate too many at once.

A very rough photoshopped example of how overlays might look in-game:

[Svengali]

The waypoint plotting and dial for currently (and next, previous) primed equipment name looks like a really nice option.

For the overlays I'd think it must be guaranteed that they are shown if a script needs to do so and they must be independent from the current used HUD.

The dial for target beacon code is not really useful in my eyes (we can define custom symbols already) and the beaconCode is not exposed anywhere else, so it can be a internal name (read meaningless for the player).

The low-opacity rectangles sounds useful, specially in the heat of a battle.

[cim]

For the overlays I'd think it must be guaranteed that they are shown if a script needs to do so and they must be independent from the current used HUD.

That would be nicer, but I can't figure out a way to do it safely. "Independent of the current HUD", given the current variety in HUDs, means that wherever they're placed they're going to overlap something important on some existing HUD. Forcing display if required gives serious problems if more than N OXPs think it's required now.

Perhaps I should call them Multi-function displays rather than overlays - that's perhaps closer to how I imagine them working.

An OXP could force display in the current model by disabling then re-enabling the overlay (which would move it to the top of the "most recently enabled" queue) but they probably shouldn't do that. If there's something which needs to be seen right now and the overlay isn't visible, a console message "Urgent: [message], please switch MFD to [setting]" could be used.

[JazHaz]

What I'd like to see is for the HUD to be aware of the screen resolution and adjust to fit automatically. Is that possible?

[cim]

What I'd like to see is for the HUD to be aware of the screen resolution and adjust to fit automatically. Is that possible?

It's aware of screen resolution and will scale to fit that, but what it's not aware of is screen ratio. It depends how far you want to go with it. If you're meaning "a HUD with an intelligent layout algorithm" so you can define regions which contain particular dials and then reflow and resize those regions dynamically as the aspect ratio changes, that sounds extremely difficult. If you just want the HUD to switch between different fixed layouts as the aspect ratio crosses particular boundaries, then you can already use JS to monitor oolite.gameSettings.gameWindow and switch between HUD plists as needed.

[CaptSolo]

Expanding from drawSurround, how about a new selector for filled shapes to add a splash of color without using hud images.

Code: Select all

{
alpha = 0.75;
selector	= "drawFilledRectangle:";
x = 0;
y = -190;
height = 80.0;
width = 200.0;
rgb_color = (0.5, 0.75, 1.0);
}

Crazy idea from this old codger

[Cody]

Crazy idea from this old codger

<this old codger smirks - doffs his sombrero>

[Switeck]

Scripts could then enable and disable their own overlays (most often on events, or on primable equipment), and refresh the overlay to replace the contained text.

Enabled overlays would be put in a stack, last-enabled at the top. The overlays would then be displayed from the top down in the various overlay regions on the HUD, until all overlay regions were used. Ideally: overlays stick to their current region if possible, rather than rotating around every time a new one is added or an old one removed; and ideally: a short overlay-changing animation rather than an instant switch.

For some weird reason this reminded me of a printer queue, with some documents waiting to be printed having higher-or-lower priority than others. Some stuff would only get "printed" if nothing else was left in the queue.

A priority level could be defined to be either urgent (such as a q-mine just dropped), important, useful-and-informative but not time-sensitive, and lastly "flavor text" that might only get displayed if nothing else is going on. I'm really at a loss as to where I'd put ship-to-ship "radio" traffic. It might depend on whether the message conveyed was "SOS!", "You need help?", "Hi, I'm bored", or "Give me all your cargo!"

[Norby]

Thank you cim, these are similar with I asked in the HUDRequest OXP.

The two configurable equipment activate button can be named as Favourite Equipment 1 and 2.

Please bind the Ctrl+these keys to usable also, like the mode button of the faveqs or 3. and 4. favourite equipment activate or both configurable.
The Ctrl+n and Ctrl+b would be useful also to extend the primed equipment with two more buttons (back and close), especially if the equipment show a list of things.

The colour of the rectangles around TSME-tracked ships maybe get scanner colours due to it is changeable from js, or make both variant selectable.

Hostility not depends on weapon range in my eyes (targeting only), but the defence target equal with the main target due to can fire anytime after the current target destroyed even if no turrets.

Overlays: yes!

The size and position is not a big problem, please leave it to fully customizable. OXPs can read the name of the current HUD from player.ship.hud and place as large overlays as can fit into the used HUD if programmed correctly. An 1x1 overlay can be useful also (status letter).
The border and background should be turn on and off (glassy) from js.

[cim]

OXPs can read the name of the current HUD from player.ship.hud and place as large overlays as can fit into the used HUD if programmed correctly.

Theoretically, yes. In practice, there are 26 released HUD OXPs (so far...) all of which have blank space in different places, plus any local modifications (most of those 26 HUDs have a license which allows derivatives or at least modification for private use). That's a lot of work to keep up with (and some of those HUDs are switching HUDs with multiple plists).

It also doesn't answer the question of what happens when two (five, ten, etc.) different OXPs want to do something at once.

So this does lose some flexibility compared with making the positioning fully scriptable, but on the other hand it makes it easier for OXP authors to use.

[Norby]

So this does lose some flexibility compared with making the positioning fully scriptable, but on the other hand it makes it easier for OXP authors to use.

Then I suggest two overlay types:

1. General overlays with fixed sizes (in x*y characters, but the font size can be auto adjusted to fit into the defined place) and strong recommendation to HUD makers to include these.

2. Custom overlays which can placed by the OXPs without HUD support also but with the risk to cover something, so the OXP maker must program it carefully.

From js can sychronize the usage between more OXPs with properties: the previous writers (name of js), contents and time elapsed since last change. Surely free if the last write is an empty string, or if a timeout specified at write and reached, otherwise these properties can help.

If can define overlay groups then can write into the first free slot in a group and lock it for a requested time or until release. At least one general overlay group needed to solve the most request on all HUD (I guess 5 overlay with 4x20chars), and the custom groups are usable to make lists with many small items.

All overlay can be subgrouped using line separation: if a general overlay defined with 6*30 chars and an OXP write 50 chars then lock 2 lines only and the next OXP will lock the 3. line when write 25 chars.

I think the short (<10char) fix locks need more support due to the medium contents can shown in the console.

I can imagine an email-like usage of a large overlay as on the screenshot in the first post, where the long messages always get short subjects, and there are two view in the same place: one show subjects only, other show the selected subject in the first line and the full message below and the view switchable by either a (ctrl-)button, a primable equipment or timers.

If a scrollbar can be implemented for the groups then can hold unlimited number of messages without fear from the small place.

Of course not all of these must be in the first version.

[Zireael]

Can we get an instruction on how to use MFD with a mod?

[cim]

player.ship.setMultiFunctionText will set a particular MFD entry to the given text, and player.ship.setMultiFunctionDisplay will bring the chosen entry up on an MFD (or the player can press ';' and ':' to display it manually on the MFD of their choice, which is often the better route).