Release Elite Cougar MFD Cockpit Display - game changing new companion app

I see 3 logs in the MFDCougar folder. 2 glContext and an Engine log. I see nothing that would indicate a problem in any of them. But then I may not recognize something as a problem.

I haven't been running any other apps while trying to get this working. I do normally run EliteG19s app when I am playing.
 
I see 3 logs in the MFDCougar folder. 2 glContext and an Engine log. I see nothing that would indicate a problem in any of them. But then I may not recognize something as a problem.

I haven't been running any other apps while trying to get this working. I do normally run EliteG19s app when I am playing.
There are only two things left which may impact the journal processing.
There is a registry key in current user called bionicbytes. Try and rename that and restart the app. Possible registry corruption?
The other possibility is that there’s an entry in the journal causing an exception which makes the journal processing function exit early - hence why only matrix showing. Could you try exit Elite, move all files into a temp journal folder, restart elite then start app. App can be started at any time, but the tray / START should be clicked immediately after load into solo/open has completed.
 
This has been a very troublesome program. Cool looking when it works but I have not been able to verify how useful it is in game.

I had it running many times this morning while I troubleshot my bindings problems. It was frequently slow to move beyond the matrix screens. Occasionally it would start right away, other times it would take up to minute for the proper displays to come up. The first run of the day hung up on downloading listing.csv. But started after that. Now its back to matrix screens again with a quick flash of text appearing beforehand. So fast I can't read it on the tiny display.

I never could figure out why the bindings wouldn't take. I used the quick key assign, save and go, save. It would back up my binds file but in game it didnt seem that anything had been changed in the control setting. Using Target Event Tester the MFD's were sending keys competly different from what elite was expecting to get. Elite expected L for landing gear but pushing the mfd button yielded C.

So I am tired of this for today. Totally taking up my playing time making me grumpy.
 
This has been a very troublesome program. Cool looking when it works but I have not been able to verify how useful it is in game.

I had it running many times this morning while I troubleshot my bindings problems. It was frequently slow to move beyond the matrix screens. Occasionally it would start right away, other times it would take up to minute for the proper displays to come up. The first run of the day hung up on downloading listing.csv. But started after that. Now its back to matrix screens again with a quick flash of text appearing beforehand. So fast I can't read it on the tiny display.

I never could figure out why the bindings wouldn't take. I used the quick key assign, save and go, save. It would back up my binds file but in game it didnt seem that anything had been changed in the control setting. Using Target Event Tester the MFD's were sending keys competly different from what elite was expecting to get. Elite expected L for landing gear but pushing the mfd button yielded C.

So I am tired of this for today. Totally taking up my playing time making me grumpy.
I’m sorry to hear about your problems. Let’s see if we can work through them one by one.
When the app starts it performs a few tasks. One of these is enumerate through and test every voice on your system. It will then save this as SAPI.INI. This can take 30 seconds or so.
If you copy paste this file in it will speed up future new installs because it won’t need to recreate it.
Next, the registry is read to check the schedule for EDDB download. If you find this is taking too long (slow internet) change the settings on the explorer module (or change the registry). This will save 4 minutes of startup time for a fresh install.
The flash of text is probably the message saying journal out of date - which is due to the program waiting for a new entry in the journal files.
I’ve spent much of today looking at the code for this. If your system is running in a region with daylight savings on it potentially could affect reading the journal. The next release will have some improvements in this area - debugging the journal entries. There is a setting on the commander log settings tab to enable live journal (top check box in misc section). This option shows what entry is being read from the journal. In your version it is shown if the entry was successfully processed. In the next release it will be added weather or not it is processed.
My guess is that the journal is being read but status. Json is not. It’s this file which is responsible for setting the state of the app and switching between the screens.
I have an emulator which I wrote which creates status. json and writes journal events. I use this everyday to speed up development but I’m happy to share with you if you feel it helps workout why it’s not responding.
Similarly, the web site troubleshooting page has a tool that you can download to read key presses. It works like Elite does and consumes WM key messages. It looks similar to event tester but fundamentally different technically.
The key binding end up in XML files. Check that they contain the values you expect. Once they do, then the quick key assign can merge those changes into elites bindings file. It’s important not to rebind the Controls in elite after.

It seem unfortunate that you are having all these issues together. I’ve had a few people (earlier versions) with one of these issues but never like this.
Can you tell me if your running version 1.2?
 
Last edited:
I have MFD COUGAR 1.2. We do use DST here.

I turned on Live Journal and minimized to sytem tray. Started everything in the proper order and the proper displays came up this time. I played for a few minutes dropping into USS's and then quit the game and paused MFD Cougar. There were no entries in the Live View.

I exited the program. Started and minimized again. Got into my ship and started MFD Cougar again. Matrix Screens. Dropped into USS, Jumped Systems. Exited.

No entries in live view.
 
I have MFD COUGAR 1.2. We do use DST here.

I turned on Live Journal and minimized to sytem tray. Started everything in the proper order and the proper displays came up this time. I played for a few minutes dropping into USS's and then quit the game and paused MFD Cougar. There were no entries in the Live View.

I exited the program. Started and minimized again. Got into my ship and started MFD Cougar again. Matrix Screens. Dropped into USS, Jumped Systems. Exited.

No entries in live view.
Thanks for the update.
Can you check if the time written into the journal is the same as your windows system time and the last modified time on the file. I’m trying to workout if your journal entries are written in UTC time. My code is supposed to convert journal time into local time. It assumes the journal is written with utc.
 
The journal entries seem to be written in Zulu time. I'm guessing Zulu and UTC are the same. My computer is on Pacific Daylight Time. 7 hour difference.

Edit to add:

The Last Modified time appeared to be about 4 minutes after the latest journal entry I could find, which was at or near the top of the file.
 
Last edited:
Many thanks for your reply.
I have set my timezone to + 7 hours to test the code thoroughly. The code I'm running has been refactored to make it more robust, but essentially it does the same as the previous version. I'm not seeing any issues with Elite.
The matrix rain effect is due to not receiving a journal event/ and or status.json not being decoded. I have improved the next release so that the message on the consoles will always tell you if either (or both) status.json and journal files can't be found (or are out-of-date). Additionally, the code to always add the journal events to the live view (Commander's log) has been improved.
In your version you'll need to add a debug entry to the MFDCougar.ini in addition to setting the Live View option to get the journal events added to the preview.
[debug]
JournalLines=1


The other big change for the journal reading is that previously my code always reads the bottom 50k of the journal file. This is why the order of the start up is so important - because the loadout/loadgame events could be beyond the 50k and never read. Looking back I don't know why I did that because with a couple changes to a few lines of code the journal reading is now much better and doesn't need to read only the last 50k or so. As from the next release, it will always read the journal until the end of the file (processing all the events as it does so) and then it will read just the new entries. This I feel is a much better approach.
My only concern is the UTC to local time translation (using the windows APIs) because this is the one thing which can make the system skip journal events. Today's timezone changing test has shown that it does work, even with large timezone shifts. Here in the UK we have a +1 summer time until October when the clocks go back to UTC, so I'm confident the code handles that too. With the changes to the live view, it should be easy to spot skipped events because it will add SKIPPED to the front and also it will output the journal event json before attempting to process it.

I'm going to release a new version (hopefully over the weekend) with these changes in it to hopefully improve things for you.
 
Last edited:
Thank you for looking into this so thoroughly and information provided.

I have some good news! I noticed if I left the program running long enough the MFD's would start working. I ran seven tests and found the delay was a consistent six or seven minutes each time. I was using my cell phone clock as the timer. Then I noticed that my PC system clock was ahead by about 8 minutes! I synced it and started the programs and the MFD's came up within about 20 seconds! Hooray! (and sorry, my bad)

Thank you so much for your help so far!

Now I need to troubleshoot bindings some more. I have ideas and things I need to test but I am out of PC time for today. Got other things to take care of.

Thank you!
 
Thank you for looking into this so thoroughly and information provided.

I have some good news! I noticed if I left the program running long enough the MFD's would start working. I ran seven tests and found the delay was a consistent six or seven minutes each time. I was using my cell phone clock as the timer. Then I noticed that my PC system clock was ahead by about 8 minutes! I synced it and started the programs and the MFD's came up within about 20 seconds! Hooray! (and sorry, my bad)
Yes! That would be it. Future events would implicitly skip processing; something I noticed yesterday (but dismissed as fantasy 😂 ). I've added a note in the website troubleshooting.

With the binding, check that the MFD_layout.xml contains the key sequences you expect (open in IE/Chrome). Use the key debug tool from my website to test key press events are being sent with the correct sequence. As noted on the website, not every key sequence can be interpreteed correctly.
 
Good grief. I had your keyboard debugging tool working once. The MFD's let me push buttons and I could see what they were outputting.

I shut everything down and restarted so I could note which buttons were not working in game. When I went back to trying to use the keyboard debugging tool all I get are the matrix screens. MFD's come up fine in game.

None of the Pip buttons work. They are bound to keyboard arrows. Cargo scoop is bound to Home, Lights is bound to Insert, both match MFD_layout.xml. They don't work for both ship and SRV.

Several buttons do work, such as Landing Gear, Galaxy and System Maps.

Client window matches ini.
 
When I went back to trying to use the keyboard debugging tool all I get are the matrix screens.
The key debugging tool is designed to have the same window title as elite dangerous. I do this so that cougars can find “elite dangerous client”. Elite can’t be running at the same time because it too has the same window title. The issue here is how to make the MFDs change layout so you can test the key bindings. But without elite writing to the status.json and journal the MFDs don’t switch layout.
I use my debugging tools to perform a simulation of Elite and these create the necessary journal files.
I think i need to release a consumer friendly version of these to help setup and debug key binding.

None of the Pip buttons work. They are bound to keyboard arrows. Cargo scoop is bound to Home, Lights is bound to Insert, both match MFD_layout.xml. They don't work for both ship and SRV.
Some keys just won’t work. Period. Experimentation is required. There is no explanation that make true sense. It not a cougar issue per sey. See the troubleshooting page on the website as I go into quite some detail on this. I wanted to bind the END key. Just couldn’t get Elite to receive it. I had bound 1,2,3,4 to the UI focus panels. Couldn’t send anything using 1,2,3,4 either even in combo with shift, alt or ctrl. Elite just consumed the keys as soon as anything with 1,2,3,4 was detected.
I suggest you use a different set of keys and stay away from the extended PC keys.
 
Last edited:
Released - version 1.201

I'm pleased to announce the release of version 1.201 which contains the following updates and new features:

  • New user interface added to the Orrery. Now it's much easier to select, find and identify any body in the system.
  • Orrery is customisable. Select from several backgrounds and shaders
  • Use filters to colour code Orrery system bodies according to planet class, volcanism or atmosphere (planets coloured either red, blue or green [or a combination of])
  • Improvements to journal reading and debugging.
  • MFDs display a clear message if the system clock is out of synch (prevents the journal from being fully decoded properly), or is status.json/journal files missing
  • Space radio chatter - control over volume of Morse code beeps and timing of the radio chatter
  • Updated manuals and features documentation, including a new Orrery section.

The website has been updated with a section on what to expect from the auto update mechanism.

fly safe
o7
 
Last edited:
Released - version 1.300

I'm please to announce the availability of version 1.3
This version adds native user control over the much loved Space Radio Chatter - User Interface controls for the Morse Code volume, Nasa script timings and control over the audio filters.
Also a new keyboard focus option has been added following a touch screen button press.

Fixes to the journal reading, SRV graphics, Planetary pixel shader, debug logs, AutoImport, and EDDB import.

Over the next few weeks more fixes will come to address Commodity Searching and downloading files via Internet Explorer.
 
I downloaded this software. Had issues even just getting it to run. spent 4 euro on a month sub and emailed the dev with my problem. He responded as soon as he had his morning 1,2,3 coffe tea pee etc. and assisted me as much as possible right down to looking and rewriting code.

I got it working. With his help. In my opinion it had noting to do with his code and everything with me not applying my window's updates for like 4 or 5 years.

Anyway. He told me he is looking into what he can do to remove those depencancies. in the meanwhile. after my updates. I love this app. and am gonna bombard him with ideas.

Thanks heaps for creating this. its taken my ED life to another level. even without the MFD's. touch screens work fine.

PS. (make it more touch screen freindly. let us manipulate the MFD screens more please. id use 6 i can see. 4 on a normal monitor for data output and 2 on touch screens as MFD's. you can never have enough info, like we could have one screen that just is dedicated to showing a 3d positioning system like u have done with the mfd. but always on if we want it. one that shows loadouts. one that displays the log etc.) if possible already i need to read the manual again.
 
Very brief Bug report: Ships COVAS announces that I don't have any limpet drones when in fact I do.
 
Last edited:
Very brief Bug report: Ships COVIS announces that I don't have any limpet drones when in fact I do.
We can only track the number of limpets if the information is in the journal files for that day.
Can you tell me if your session started with you already in your ship (with limpet controller) as opposed to swapping to a ship with a limpet controller.
Also, we check that there is a cargo rack with something like > 4 tons capacity.

Could you send me your journal log file for that day. It would take out all the guess work!
Many thanks for reporting the issue!

o7
 
It has done it over multiple sessions and those sessions all started with me already in the ship with a collector limpet controller.
 

Attachments

  • Journal.201007152819.01.log
    268 KB · Views: 129
Many thanks. The next version will cache the ship loadout, so that we'll have a better snapshot of the journal state and things like this should be a thing of the past...
 
Top Bottom