In-Development StatusDisplay - status.json / journal display and surface navigation assistant.

[Robert Maynard]

Images or icons are also very popular. So like here on picture for example. My first attempts

Something else to consider adding to the long term aim list. However I won't be placing any button related text / image outside the centre "square" of the MFD display.

Some progress made on settings for corner buttons (WIP settings dialog below; settings load / save already done with in-place "upgrade" of .ini file, i.e. no need to re-create):

Now started on adding a "short form" of each binding text suited to fitting in the reduced area available in the corners of the MFD. Early version of corner button text displays:

 

[Evan Kurst]

I took the decision to omit corner button setting at a very early stage in the project - mainly because each corner is a two button "button" and two options would require more text than could fit in an already very small space.

To change it now will require reworking the settings file and internal MFD button assignment structures - and work out how to display two buttons' worth of text in such a small area. However that's no reason not to consider the change.

Which bindings would you want to assign to the corner buttons? Knowing that may help with coming up with a display solution.

Hi,
at the moment one of my corner button is assigned with "Landing gear up/down".
I know that the landing gear could be activeted/de-activated with just one button but it's more about the feeling ;-)
Another corner button is assing to "up = next target / down = previous target" .

 

[Robert Maynard]

I know what you mean. I'd really like gear up and gear down to be bound either as a toggle (as it is at the moment) or as two separate bindings - same for the other "toggle to deploy/retract" bindings..

As you can see by clicking on the thumbnail of the MFD display above, I've added short forms for select next/previous target; next/previous fire group, etc. and have added the eight button display areas.

What I am now considering is, for some bindings that toggle (rather than have separate deploy/retract bindings), to merge the two button display areas in a corner if they are both set to the same button - in this way, hardpoints, landing gear and cargo scoop could be displayed "covering" both of the buttons.

Corner button merging (if both set to the same button) in action:

 

[Evan Kurst]

I know what you mean. I'd really like gear up and gear down to be bound either as a toggle (as it is at the moment) or as two separate bindings - same for the other "toggle to deploy/retract" bindings..

As you can see by clicking on the thumbnail of the MFD display above, I've added short forms for select next/previous target; next/previous fire group, etc. and have added the eight button display areas.

What I am now considering is, for some bindings that toggle (rather than have separate deploy/retract bindings), to merge the two button display areas in a corner if they are both set to the same button - in this way, hardpoints, landing gear and cargo scoop could be displayed "covering" both of the buttons.

Corner button merging (if both set to the same button) in action:
View attachment 175283

Cool !!!!
That looks really cool.

Did you see the announcement trailer for Elite Dangerous: Odyssey?

 

[Robert Maynard]

Cool !!!!
That looks really cool.

Thanks - it's one of those features that, on retrospect, makes me wonder why I didn't do it like that in the first place. Thanks for suggesting it.

Did you see the announcement trailer for Elite Dangerous: Odyssey?

I did - and it looks good. Can't wait for the Dev Diaries that were mentioned (which were great content during initial development of the game).

 

[Evan Kurst]

Just a quick question - can I support your work with a smal donation?
Your tool is just great and your are doing a lot of work.
Much appreciate!

 

[Robert Maynard]

Just a quick question - can I support your work with a smal donation?
Your tool is just great and your are doing a lot of work.
Much appreciate!

That's a kind offer - however I'm engaged in this project purely out of self interest (I wanted to put an active background behind my MFDs and it expanded from there) and would be doing it anyway.

Feedback and suggestions are the support I need most for this project.

 

[Sargonas]

Crazy idea Robert... and feel free to shoot me down if you have already investigated this and think it’s a crazy idea…

Have you looked into potentially integrating the data sources in EDDiscovery? While I know it’s just reading the same journal data you are… It has a lot more information it then compiles based on the data, and some of that may feedback nicely in to your panels, especially perhaps ones around routing and navigation?

 

[Robert Maynard]

As I've (finally) managed to download data from a secure connection this should be possible (subject to server imposed client call limits per time period).

Which information would you want to see added?

 

[Robert Maynard]

Beta 0.0.7.7 released. Download link: https://cdn.discordapp.com/attachme...0/StatusDisplay_Beta_0.0.7.7_20200617-1902.7z

Changelog:

1) Added the eight missing MFD corner buttons for assignment; should automatically migrate the .ini file to the new version.
2) If "paired" bindings are selected for one pair of corner buttons then the pair are merged for display purposes and show specific text, e.g. Cycle Next Target and Cycle Previous Target. Not all logical pairs have been included - please point out any that should be added.
3) Rework of 2D display of 3D coordinates method.
4) Added "NavRoute" event handling; new small panel showing jumps and distance remaining available.
5) Added panel that shows "ApproachSettlement" surface targets appropriate to the body that the game indicates the ship is close enough to. This will be augmented with the ability to select any of the displayed settlements as a StatusDisplay navigation surface target (which will, in turn, allow the app to display range and bearing to target information) in due course.
6) Rework of the three Galactic Track panels following 3) above.
7) Window borders have made a comeback, of a sort. Double-clicking the centre mouse button will toggle the border for any window.

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 binding file selection option for populating MFD outer buttons.

 

[shroom2021]

Is there a way to adjust the threshold for certain buttons? For example the Over-heating field. Currently it flashes when heat is above 100%, but I'd find it more useful at 90% so that I have time to get away from the heat before my internals start baking.
I'd also like to be able to adjust the low fuel threshold so that I can have a warning a little earlier when I might need to make two or more jumps to get to the nearest KGBFOAM star.

 

[Robert Maynard]

The over-heating button use the flag from status.json - the threshold is set by the game and temperature is not reported directly.

For low fuel, I can add something - however the threshold will have to be hard coded (as buttons / panels don't have individual settings).

What would you like a threshold for fuel to be?

 

[Robert Maynard]

Beta 0.0.7.8 released. Download link: https://cdn.discordapp.com/attachme...2/StatusDisplay_Beta_0.0.7.8_20200619-2203.7z

Changelog:

1) Fixed bug in multi-panel element assignment;
2) Added overwrite confirmation to load bindings - if a button is used more than once all instances after the first will require the user to decide whether to overwrite the MFD peripheral element assignment.
3) Added more detailed NavRoute panel.

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 binding file selection option for populating MFD outer buttons.

 

[shroom2021]

The over-heating button use the flag from status.json - the threshold is set by the game and temperature is not reported directly.

For low fuel, I can add something - however the threshold will have to be hard coded (as buttons / panels don't have individual settings).

What would you like a threshold for fuel to be?

I think a low fuel warning should occur around 30%. Should leave just enough for 1 or two jumps to find something

 

[gazelle]

How about if current_fuel < (max_fuel_per_jump + reservoir_tank)

 

[Robert Maynard]

I think a low fuel warning should occur around 30%. Should leave just enough for 1 or two jumps to find something

I could do that.

How about if current_fuel < (max_fuel_per_jump + reservoir_tank)

Sounds interestiong. Is there a way to determine, from the journal, what max_fuel_per_jump is?

 

[gazelle]

Sounds interestiong. Is there a way to determine, from the journal, what max_fuel_per_jump is?

The only way I can think of is the Loadout event to get the Item from the FrameShiftDrive Modules.Slot and use a table.

 

[Robert Maynard]

@shroom2021 I've mulled it over and I think that the best way to allow a user variable threshold for a low fuel warning is to implement "personalisation" settings for combo-panels. Each (now) has 248 bits of data available for settings that is not currently used. This should provide plenty of space for user defined options that affect panels in each combo-panel.

 

[shroom2021]

@shroom2021 I've mulled it over and I think that the best way to allow a user variable threshold for a low fuel warning is to implement "personalisation" settings for combo-panels. Each (now) has 248 bits of data available for settings that is not currently used. This should provide plenty of space for user defined options that affect panels in each combo-panel.

Awesome! I can't wait to update my panels with the new version

 

[Robert Maynard]

Awesome! I can't wait to update my panels with the new version

The addition may take a little time.

I'm off down a rabbit hole with modules, their weights and engineering at the moment - as I've implemented an FSD range / fuel vs. distance estimator: