[HUD] [0001] Establish a HUD resembling the legacy stuff

[mwpowellhtx]

Basic Information

Mission version: v0.98.dev-s9 Map used: Altis

Short Issue Description

Which, we think, will also give us an opportunity to review some of the more interesting moving parts about Eden start base assets, helicopter and fixed wing quotas, enemy awareness, civilian reputation, etc.

Expected Behaviour

Present the following bits, there may be others, depending on how elaborate the refactor allows for different things:

• [ ] Sector engagements
• [x] Enemy awareness and/or aggression
• [x] Civilian reputation
• [x] Helicopter and fixed wing quotas
• [x] Current FOB and global resource summaries
• [ ] Mission objectives, timers, etc
• [ ] Alerts, targets, timers, etc
• [x] Show the HUD when no other dialogs are presented
• [x] Hide the HUD when dialogs are presented, i.e. production or logistics managers, or others, potentially

Will also need to consider proper client server events bundling the informational tuple for HUD display, of course. Events are simple, and should not be terrible to incorporate. The tricky part with that is to identify clients when the login and connect, as well as when they drop off and leave, and to publish those elements to the current set of clients.

There may be other bits we end up incorporating as well.

[mwpowellhtx]

WIth an example illustration to help jar the old memory. Not sure we will land "exactly" there for the refactor, but it offers us a clue concerning the HUD overlay elements we might expect.

[mwpowellhtx]

We think that we should maintain an array of players using the onPlayerConnected or stackable, and onPlayerDisconnected or rather stackable, events, respectively, which should subsequently inform a running heads up state machine, whose role it is to periodically gather important heads up details related to each player, and convey those via server to player events for integration into a heads up display non-modal dialog. This is a bit of a departure from modal manager dialogs, but not that much of one; in other words, the same principles of display layout apply. The only differences are the point at which players signal the state machine, etc. Additionally, we must also signal when a dialog is open or closed so that we can hide the HUD accordingly when that is the case; this may be simply done using the dialog keyword. Also, some elements will be visible when within a FOB zone, whereas others are not, or are only available when near BLUFOR or OPFOR sectors, accordingly. So, in effect, we may also stand up a client side state machine of sorts, whose role is to coordinate with the server side and the HUD display. Now that would be very interesting indeed. The display itself should be created using createDisplay rather than createDialog; however, as an overlay, we want to look into cutRsc, and we may further designate different facets of the overlay as layers.

[mwpowellhtx]

Also note 0130_core\KPLIB_titles.hpp, which contains the requisite class RscTitles {}, so we need to reconsider whether this belongs in the core module after all, or in the parent, i.e. where functions or statemachines are otherwise included, for consistency sake.

[mwpowellhtx]

Sketched out the better part of the HUD code. That includes the following modules:

• [x] 0500_hud, the core HUD API, also reflects the user interface overlay, a cutRsc based approach; really, though, cutRsc and those aspects is the only choice in the matter.
• [x] 0501_hudDispatchSM, a server side HUD dispatch state machine, including most of what we think will be the event handlers and such. The really ingenious part about this, is that we leverage a setVariable alternate syntax in order to target just one player with the HUD elements that pertain only to that player. We leverage this feature in both directions, server to client, client to server, i.e. player toggles resources views, does the same. Events have both been more or less implemented as well as state machine more or less sketched in. As it turns out, this approach is so elegant, I think it should work fantastically! In fact, it is so obvious now that I think about it, I cannot imagine I am the only one to have dreamt of it, surely I am not.
• [x] 0502_hudSM, a client side HUD statemachine, which watches for both HUD dispatched reports, as well as when dialog might be open, in which case we should hide the HUD overlay, then show once again once the dialog has been closed. Note the actual layout has not been done yet, nor have the events been implemented beyond sketching them in at the statemachine configuration level.

All pending verification, of course, from did we miss something in a function configuration, to simply syntax snafus, to logical errors and, of course, debugging. This one is pretty tricky, though, since it invovles cutRsc features. We think we may use a layered approach. At the moment there may be "two" such layers, SECTORS and FOB. We will allow for others if/when we discover them.

[mwpowellhtx]

Next will be to work on some HUD geometry, and to see about connecting some HUD dots with the status reports themselves. Should be interesting.

[mwpowellhtx]

Okay, so this one was tricky after all, but not so tricky once I worked the problem. Started off approaching with a server side HUD dispatch state machine, whose job it is to roll up player specific reports and deliver them actually on the player object itself to that specific client identifier. Works famously well!

On the client side, I started with a HUD state machine, but was getting lost in the states, transitions, conditions, and so forth. Way too heavy for what is effectively a one element state machine. Took a step back from that and instead simplified to a CBA_fnc_waitUntilAndExecute, CBA_fnc_waitAndExecute based approach.

We wait until and execute, until KPLIB_campaignRunning, before kicking off initially. We follow up with a simple wait and execute. This works very well, we reconcile HUD resources, cutting in appropriate blank or overlay resources, view data, and so on, via this approach. Also important to mention here is that we relay [player] each time. This includes the most up to date player snapshot, including variables, for the next invocation.

After that we manage our conditions for three possible outcomes. First, cut display resources out to blank. Second, cut display resources in to overlay. Third, and finally, simply refresh an existingly cut in overlay display.

[mwpowellhtx]

One other note to make, we approached this one using a "single" CT_LISTNBOX to contain the overall FOB HUD report. This is in contrast with the legacy code, which actually defined a dozen or so unique controls for each report element, twice over when you include corresponding images. Way too much effort for the desired outcome.

So we decided to simplify this significantly. Each report in the HUD allows for the report text itself, an image path, and an optional color; default color is the default color, of course, which is white.

To accomplish a shadow effect, we introduced a custom shadowColor[] attribute in the configuration of the shadow LISTNBOX class and offset by a tiny bit, while at the same time separating controlsBackground[] from controls[], i.e.

controls[] = {KPLIB_hud_lnbFob};
controlsBackground[] = {KPLIB_hud_lnbFobShadow};

This works really great as it turns out, as demonstrated:

We've verified that the color thresholds work for each of the designated report areas: civilian reputation, enemy awareness, and enemy strength, including comprehension of each of the respective ratings, maximums, ratios, percentages, etc.

Also worth noting, assets are counted with the same sort of criteria we use to sweep during FOB asset serialization. What does this mean; using the following overall criteria, asset is:

• [x] In range of a FOB
• [x] Alive
• [x] Not a starting asset, or rather, was built at a FOB
• [x] Sufficiently grounded, no momentum, in any direction
• [x] Completely disembarked, no crew
• [x] Without attachments of any sort, i.e. resource transport vehicles

We could perhaps factor the scalar rendering a tiny bit better, but we will cross T's and dot I's as we have opportunity to do so downstream from here.