In-Development StatusDisplay - status.json / journal display and surface navigation assistant.
- Thread starter Robert Maynard
- Start date
Robert Maynard
Volunteer Moderator
You're welcome!
Do you mean two MFDs or two pairs of MFDs?
At the moment StatusDisplay only supports one pair - however it would be possible (albeit a bit time consuming) to support more. I'm not sure how more than one pair would be enumerated in terms of the USB device to which controls are assigned (when reading bindings directly from the ".binds" file).
Robert Maynard
Volunteer Moderator
Yes, two pairs of MFDs.
It's do-able.
I'll have a look at the implications.
Can you please put a copy of your control bindings file on the Discord (or copy paste it here)?
Robert Maynard
Volunteer Moderator
After a bit of rework (and some optimisation that, on reflection, was beneficial overall), I've managed to add two more MFD windows. Not sure (yet) how controls will be imported - as I don't know what the USB enumeration of more than two MFDs looks like.
Robert Maynard
Volunteer Moderator
A sneak peek at a new feature for 0.0.3.0: the trip meter....
It's session based and is part of the "INFO" panel - jump data is displayed when no body position is available.
It's session based and is part of the "INFO" panel - jump data is displayed when no body position is available.
Robert Maynard
Volunteer Moderator
Beta 0.0.3.0 released. Download link: https://cdn.discordapp.com/attachme...4/StatusDisplay_Beta_0.0.3.0_20180715-1514.7z
Change log:
1) Two more MFD displays added.
2) Trip Meter now shares the Info panel; jump information for the session is shown when no positional information is available.
To do list:
1) Improve parsing coverage of possible events listed in the Journal documentation;
2) Add defined buttons to display information read from the Journal.
3) Improve defined button display based on status.json information.
4) Add "trip reset" to Trip Meter to permit jump log to be re-initialised by the user at any time during the session.
Change log:
1) Two more MFD displays added.
2) Trip Meter now shares the Info panel; jump information for the session is shown when no positional information is available.
To do list:
1) Improve parsing coverage of possible events listed in the Journal documentation;
2) Add defined buttons to display information read from the Journal.
3) Improve defined button display based on status.json information.
4) Add "trip reset" to Trip Meter to permit jump log to be re-initialised by the user at any time during the session.
Robert Maynard
Volunteer Moderator
Not sure what you mean, however it might be possible to permit direct entry of target coordinates in either the Info or Dest panels. Radius is not shown (but is used when calculating speed relative to the surface of a body), so I'm not sure that it needs to be displayed all the time.
I've only had a quick look at the application but I say great job! I can't load it on my gaming PC since I'm in the process of building my simpit, the PC is in the basement. But I think I'm definitely buying at least 1 small monitor to use as a backing display for the MFDs. I'll already be running EDDiscovery on a dedicated side monitor for some informational windows but I don't think you can have enough information at hand.
I have a Thrustmaster Warthog and while I could get away with using shift keys to maximize the button functions, I'm a bit of a minimalist in this sense. I made custom key labels for my wireless keyboard so I'm looking forward to moving those functions to the MFDs.
I have a Thrustmaster Warthog and while I could get away with using shift keys to maximize the button functions, I'm a bit of a minimalist in this sense. I made custom key labels for my wireless keyboard so I'm looking forward to moving those functions to the MFDs.
Last edited:
Hi Robert,
I have a great headache now... Slowly I realize, that my 1366x768 19" monitor's resolution is too low to have clear readability of all the texts. My SatusDisplay windows' size are 368x368 to fit with the button-frames. With this setup, the font size is 7pt, the button size is something like 50x50 pixels.
It looks like this (cut out from SD, with EuroCaps, but the other fonts are even more harder to read at this size):
1:1 :
200% zoomed :
Maybe while making the window larger/smaller, the distortion happens during the upscale/downscale process.
As I see, theoretically 8, 9pt sized fonts would fit into this buttons.
Just created an example with Pain.net on a 61x50 sized button, how 9pt EuroCaps would look like:
Do you think it's possible to make a "Low-res Monitor Optimized" setup?
Thanks in advance!
I have a great headache now... Slowly I realize, that my 1366x768 19" monitor's resolution is too low to have clear readability of all the texts. My SatusDisplay windows' size are 368x368 to fit with the button-frames. With this setup, the font size is 7pt, the button size is something like 50x50 pixels.
It looks like this (cut out from SD, with EuroCaps, but the other fonts are even more harder to read at this size):
1:1 :
200% zoomed :
Maybe while making the window larger/smaller, the distortion happens during the upscale/downscale process.
As I see, theoretically 8, 9pt sized fonts would fit into this buttons.
Just created an example with Pain.net on a 61x50 sized button, how 9pt EuroCaps would look like:
Do you think it's possible to make a "Low-res Monitor Optimized" setup?
Thanks in advance!
Robert Maynard
Volunteer Moderator
I'll have a look at that - however, the underlying design is that each element should be capable of displaying three lines of nine characters (edges) and 3 x 10 (centre) - so the text for some may look smaller than it needs to be.
Text that exceeds the 9/10 character limit is already "shrunk to fit" on an element-by-element basis (Game Version / Build being the most notable example).
If I was to size all fonts to be as large as it can be then the effect can be quite odd when adjacent elements have quite different sizes.
One point to note, all windows are drawn at 1:1 scale - there is no scaling between drawing the window and displaying it.
Text that exceeds the 9/10 character limit is already "shrunk to fit" on an element-by-element basis (Game Version / Build being the most notable example).
If I was to size all fonts to be as large as it can be then the effect can be quite odd when adjacent elements have quite different sizes.
One point to note, all windows are drawn at 1:1 scale - there is no scaling between drawing the window and displaying it.
I see that you use the 4 corner blocks for some info, the upper left is obviously for the MFD number and the upper right must be for if you are controlling ship vs. SRV. Do the lower left and right blocks have any current function?
Robert Maynard
Volunteer Moderator
Lower left is Fire Group; lower right is GUI "mode".
Thanks, I’ve been playing with the app on my work laptop, haven’t had a chance to use it on my ED machine. I’m still building my simpit and waiting for items to arrive so I can’t play ED until finished.
Robert Maynard
Volunteer Moderator
@Brigetiol1: is this any better?
Hi,
Thank you, that is much better!
Here is my current window, you can see especially at the fuel-meter the difference:
If your magic works, you spared me some money!
I know how hard t is to fit texts into these small boxes, I've been playing with editing static background images for the MFDs since two years to find the optimal solution. And you have to fit all the keybindings in the game, plus status infos, and I had to handle only some selected ones... Hats off!
Thanks again!
Thank you, that is much better!
Here is my current window, you can see especially at the fuel-meter the difference:
If your magic works, you spared me some money
!I know how hard t is to fit texts into these small boxes, I've been playing with editing static background images for the MFDs since two years to find the optimal solution. And you have to fit all the keybindings in the game, plus status infos, and I had to handle only some selected ones... Hats off
! Thanks again!
Robert Maynard
Volunteer Moderator
I've tried a couple of approaches - and have settled on two new options:
1) Minimum characters wide and lines high, used when determining the maximum permissible font size for each element, can now be set (for each MFD individually) in the range 10 x 3 down to 5 x 1. This has no effect on elements where the actual number of characters or lines exceeds either of the selected minima. Default is unchanged from the current version.
2) The "To Edges" toggle, which removes the 1 pixel "free space" inside the dark line bounding each element. Default is "off", individual setting for each MFD.
Example with "9 x 2" and "To Edges" selected:
Beta 0.0.3.1 should be released tonight.
1) Minimum characters wide and lines high, used when determining the maximum permissible font size for each element, can now be set (for each MFD individually) in the range 10 x 3 down to 5 x 1. This has no effect on elements where the actual number of characters or lines exceeds either of the selected minima. Default is unchanged from the current version.
2) The "To Edges" toggle, which removes the 1 pixel "free space" inside the dark line bounding each element. Default is "off", individual setting for each MFD.
Example with "9 x 2" and "To Edges" selected:
Beta 0.0.3.1 should be released tonight.
Last edited: