Page 1 of 9 1236 ... LastLast
Results 1 to 15 of 129

Thread: StatusDisplay - status.json display and surface navigation assistant.

  1. #1

    StatusDisplay - status.json display and surface navigation assistant.

    With the inclusion of status.json in the player journal data offered by the game in 3.0, I started development of an application to display that data and, given that positional information is included when in proximity to a landable body, allow the player to set destination latitude / longitude and calculate the range and bearing to that destination. Following success with status.json, attention has now moved to reading and displaying information from the player journal.

    Displays



    Main Overlay display

    Several optional panels, including time, raw flags; position, destination, location (a reduced combination of position and destination), trip (a trip meter showing jump related information), info (if position is known, location, if not, trip meter) and limited Journal information. All overlay panels can be toggled but one must remain. Example below shows time, position, destination, journal, location, trip and raw flags panels. This display is sized by changing its font size in the options dialog.





    MFD displays

    Up to four windows can be shown, designed to be displayed on a screen to which one or more Thrustmaster Cougar MFD controllers are attached. These windows can show up to forty individual display elements each; twenty squares (five each in four groups) at the edges and twenty elements in the centre. The outer twenty can be set to mirror bound controls by extracting relevant control bindings from the user's control bindings file. Other elements (that are not related to controls) are also included, some of which are affected by information in status.json. The destination, position, info and journal panels from the overlay can also be optionally displayed in the centre of an MFD display. Each MFD display is sized using the width and height controls in the dialog that opens when selecting the "Set" button next to the relevant MFD display toggle checkbox in the options dialog.

    The border settings for the MFD window can be individually defined - example shows 0% for both - reduces the size of the image within the window (and expands buttons to the edges) to suit individual display requirements.

    Horizontal and vertical text alignment can be specified for each group of display elements, i.e. top row, bottom row, left column, right column and centre block.




    "Tiny" overlay display

    An alternative overlay display that can show the current bearing to destination, speed over ground (SoG), range to destination, course over ground (CoG), destination and estimated time to destination (when available). This display will be hidden if no positional information is available or if the HUD is set to any other GUI focus than the standard view. This display is sized by changing its font size in the options dialog.









    When in focus, the main overlay is opaque and is reverts to a user defined opacity on loss of focus. The hue, saturation and luminosity of the overlay can also be modified.

    All options have been moved to an options dialog (accessed by right clicking on any of the displayed windows) which also incorporates the overlay window font size setting, input of body radius (needed to calculate speed-over-ground and range to target) and destination position and also checkboxes to display each MFD window (unchecked by default at this time) and buttons to open the MFD button setting dialog for each MFD. Windows are set to be always on top, so will be visible when on the same screen as the game while playing.

    New in 0.0.1.8, optional second MFD control set for use when in SRV.
    New in 0.0.1.9, ability to load current game bindings directly from Custom.3.0.binds file for each MFD separately.
    New in 0.0.2.0, ability to select one, both or neither of DEST / POSN to display in the centre of each MFD - now slightly reduced in height to leave one row of centre buttons visible when both DEST and POSN selected.
    New in 0.0.2.1, refresh rate can now be selected by user; some active MFD display elements now "pulse"; displayed time should now correct to GMT.
    New in 0.0.2.2, very limited Journal information.
    New in 0.0.2.3, a bit more Journal information and a fuel gauge.
    New in 0.0.2.4, optional Info panel in Overlay and/or MFD.
    New in 0.0.2.5, concatenation of consecutive journal entries of the same type for fuel scooping; discovery scans and ship passive scans.
    New in 0.0.2.6, refresh of MFDs now subject to change in text / colour of elements, subject to a minimum refresh rate of 1Hz.
    New in 0.0.2.9, new fonts: Droid Sans Mono; Inconsolata; SV Basic Manual. Fix to default settings. Option to select process priority added.
    New in 0.0.3.0, two more MFD displays; trip meter (shares Info panel) - shows information for jumps made in the present game session.
    New in 0.0.3.1, minimum MFD element text (chars/lines) setting; "To Edge" MFD element setting; Trip Meter zero button (in Options).
    New in 0.0.3.2, "To Edge" setting now permits MFD display element internal border to be set in the range 0 to 10; default = 1.
    New in 0.0.3.5, Location and Trip panels for Overlay and MFDs. These are individual versions of the two displays combined in the existing Info panel (which remains).
    New in 0.0.3.7, Comms display panel added. This is a large panel similar in size to the Journal panel and is available on both the main overlay and the MFD displays.

    Link to Discord server with release and direct comms: https://discord.gg/x8ZeQJC

    Direct link to 7z file containing Beta 0.0.3.8 executable: https://cdn.discordapp.com/attachmen...180816-1827.7z


    Many more defined buttons still to be added - please suggest inclusions (i.e. omissions) below.



    Using StatusDisplay:

    For options, please right click on overlay window (any StatusDisplay window really - just that the overlay window is the only one displayed by default)

    Any window can be moved by click-and-drag in the window area (other than controls).

    The "AutoLoad" option must be checked (and subsequently options saved) to enable auto-loading of user settings when starting StatusDisplay.

    Unless specifically mentioned in the change log for a Beta release the settings file (StatusDisplay.ini, in the same directory as the executable) should carry over between versions.

  2. #2
    Hi Robert,

    this is going to be a great puzzle, to rearrange my gadgets to be able to make your display work in my cockpit!

    This means many exciting DIY-hours

    Best regards!

  3. #3
    Originally Posted by Robert Maynard View Post (Source)
    With the inclusion of status.json in the player journal data offered by the game in 3.0, I've started to develop an application to display that data and, given that positional information is included when in proximity to a landable body, allow the player to set destination latitude / longitude and calculate the range and bearing to that destination.

    It's early days yet - I'll be expanding it to display the flags that are also published in status.json - both in a window and also in graphical form suitable for display on a screen behind an MFD (I use a pair of Thrustmaster Cougar MFDs as additional controllers).

    Current progress:

    1) Display of time and raw flags; position (if available, i.e. in proximity of a landable body) and destination (if set and if positional data is available).
    2) Beginnings of MFD display template - to be filled with decoded flag information, i.e. landing gear up/down, etc.

    Current game screen overlay, i.e. 1):
    https://cdn.discordapp.com/attachmen...46/unknown.png

    Current MFD display template:
    https://cdn.discordapp.com/attachmen...95/unknown.png

    When in focus, window 1 is opaque and changes to 60% opacity on loss of focus. Also on loss of focus, the buttons (not yet final) "disappear" by resizing the window. Window is set to be always on top, so will be visible when on the same screen as the game while playing.

    It's my first Windows GUI application - so everything's a learning experience....
    If you can get this working in a window I can pin inside my Rift, you will officially become "My hero". Lazy explorers (like me) need this ASAP!

  4. #4
    Some progress made with the MFD display windows (not the font or text size though) - independently resizable and they refresh every second. The diameter of the body can now be entered which allows speed over ground and range to destination to be expressed as a speed and distance rather than Arc°/hr and Arc°.

    Next on the list:

    1) font / text size;
    2) customisable "button" (i.e square next to MFD button) assignment;
    3) save / load window positions / sizes and button assignments;
    4) something to put in the middle square.

  5. #5
    This is an awesome idea!

    Any chance you could trigger the LEDs on the MFDs to indicate Hardpoints, Cargo Scoop, or Landing Gear deployed? Mass Locked?

  6. #6
    Originally Posted by AndreZero View Post (Source)
    This is an awesome idea!

    Any chance you could trigger the LEDs on the MFDs to indicate Hardpoints, Cargo Scoop, or Landing Gear deployed? Mass Locked?
    I'm not interfacing with the MFDs - just putting images on the screen behind them.

    The square next to each button changes colour - and, later, may possibly flash, depending on severity - when each flag is set.

  7. #7
    I guess I'm asking if it is possible for your application to do that as a future enhancement. I assume the data you would need are in the status.json?

  8. #8
    The data is certainly in status.json - however I'm not sure that the button backlights are individually addressable to permit single buttons lights to be changed.

  9. #9
    Hi,

    I've made some experiments with the TARGET software in the past, the button backlights can't be controlled separately, only the two small LEDs on the upper left/right. Together, that is four, so gears/scoop/hardpoints/lights (or whatever) status could be displayed with some additional plugin stuff... It was just a pain to follow the on/off statuses with VA and TARGET (however not impossible).

    Best regards!

  10. #10
    Originally Posted by Brigetiol1 View Post (Source)
    Hi,

    I've made some experiments with the TARGET software in the past, the button backlights can't be controlled separately, only the two small LEDs on the upper left/right. Together, that is four, so gears/scoop/hardpoints/lights (or whatever) status could be displayed with some additional plugin stuff... It was just a pain to follow the on/off statuses with VA and TARGET (however not impossible).

    Best regards!
    That's pretty much my understanding. You can adjust the backlighting on a per-MFD level but not per button. I was thinking about those 4 LEDs as status lights.
    I've got a proof of concept library/utility that sets the LEDs at https://github.com/AndreMessier/ThrustmasterMFDLights Just need to figure out how to link those to the statuses. I could probably get gear, hardpoints, and cargo scoop from VA but masslock would need to come from elsewhere.

  11. #11
    Originally Posted by AndreZero View Post (Source)
    That's pretty much my understanding. You can adjust the backlighting on a per-MFD level but not per button. I was thinking about those 4 LEDs as status lights.
    I've got a proof of concept library/utility that sets the LEDs at https://github.com/AndreMessier/ThrustmasterMFDLights Just need to figure out how to link those to the statuses. I could probably get gear, hardpoints, and cargo scoop from VA but masslock would need to come from elsewhere.
    Gear, hardpoints, scoop and masslock are all in status.json - in the Flags field.

  12. #12
    From the previous "to-do-list":
    Originally Posted by Robert Maynard View Post (Source)
    1) font / text size;
    2) customisable "button" (i.e square next to MFD button) assignment;
    3) save / load window positions / sizes and button assignments;
    4) something to put in the middle square.
    Item 1 is pretty much complete - with the added bonus that the main overlay window is now resizable (via a settings dialog).

  13. #13
    Originally Posted by Robert Maynard View Post (Source)
    From the previous "to-do-list":

    Item 1 is pretty much complete - with the added bonus that the main overlay window is now resizable (via a settings dialog).
    Items 2 pretty much complete and 4 started (the position and destination data from the overlay window is now in the middle of MFD0 as well (likely to be optional).

    .... just settings savings to go for first release.

  14. #14
    Great stuff, looking forward to trying this.

  15. #15
    Saving of window state (i.e. displayed or not and, in the case of the overlay, which elements are visible and for the MFDs, the size of the window (overlay window size is dictated by fontheight whereas MFD window size is user specified)) and position complete. Settings will auto-load if desired.

    Saving of MFD "button" assignment next.

Page 1 of 9 1236 ... LastLast