Took me some time to find the logfile, as there is none but under “File → Log”
But File->Log looks good. However the console log shows some deprecation warnings for “HTML Imports”, but I thought this was fixed. Its late so I have a look into it tomorrow. Thanks again for your work, I already tried several days to load a complete html gauge starting from here: https://youtu.be/7jUvkljG0gg
1 Like
I really appreciate the patience. I also started at that video and have had to line all the things up to get it working, but it’s working now. I can load the G1000/G3000/G3X, the WorkingTitle mods, all of it works. There are some errors and things to go through (like triggering softkeys, and enabling fs9gps for flight planning / live map pois) but now that it’s also working at high FPS I can focus more on smoothing out all the details here, making sure all the errors and warnings and checks are in place, furthering making the data transfer efficient, and hopefully avoid all the problems. But I need help from people who have the same goal, so if you are looking to get all the gauge system in a debugger, you are in the right place and I just ask for a little patience and time while we work through the issues.
1 Like
Ok 1.0.5 is now out with fixes for everything except non-localhost networking. This includes the new much faster streaming of data. I think it can actually transmit too often and cause occasional high latency, but this is looking pretty smooth.
I noticed a few subtle ways that I was creating situations that caused problems. Switching airplanes can cause things like L:GlassCockpit_HSI_Arc to be set to 1 vs 0 which may cause failures.
It’d be best to open the variable list window and get confirmation of which variables are being loaded and changing. You should see aircraft vars changing constantly and L:GV vars changing constantly, when both SimConnect and the Bridge component are getting new data continually.
If you have problems, post (or DM me) the log from the app and the console output in Chrome. If you’re in Chrome and want to see all the loaded variables, look at SimVarBridge.AllData (which is like the variable list but for within the page).
Thinking about some of the issues with trying to use this for non-developer activities. Some work needs to be done to enable shutting down gauges within the aircraft so they don’t conflict. There’s some additional thinking needed about how to use a set of external gauges that has nothing to do with the systems in the aircraft, and shutting down the in-aircraft system. A big issue with 2D panels I have is that I need to design layouts for every plane to fly vs having layouts that fit my external screens and also have the features of the aircraft. I have spent time with SimConnect and all the glass cockpit aircraft in FS2020 and they all have nearly identical shared systems. Key extensibility points in panel.xml for EngineDisplay et al are the main thing that actually change wildly between aircraft (as opposed to whether or not deice systems are available). This approach would probably be far superior to using 2D panels.
I haven’t fiddled with the “home cockpit” switch in FS2020 because it seems to require a restart, but I wonder if the gauges do not even load (which would be curious given the wasm’s may still be required) when the internal model is turned off. EDIT: Ahah no, this is what quality=hidden is for, and the reason is because there is logic that would break the aircraft systems.
davux3 thank you so much. This is incredibly useful. It will save me hundreds of hours that would otherwise have been wasted.
1 Like
Hi,
amazing work! 1.0.5 works now. If you need any help with testing or debugging I would be happy to assist.
If I understand your long explanation post correctly the various parts works like this:
- BridgeClient assembles the VFS (plus the ExternalPackages) and acts as a webserver for the external gauges with “.\html_ui” as document_root
- Through the “ExternalPackages” overlay the external gauges are served with different files than the internal ones
- External gauges only connect via websocket to BridgeClient to request, receive and send data to the sim
What I would like to do is to set up an independent development environment with vscode and the live plugin to serve the necessary files from the vfs from a static copy. Additionally I would need to implement a websocket server that accepts connections from the external gauge and serves some static variables. With that I would be able to work on html gauges without running the sim (which is not possible at my work due to closed ports in the firewall). Especially when debugging it could be useful feed certain values (e.g. via a simple webinterface) to the gauges. This would also enable to feed the gauges from other sources like visualization of recorded flights. As I understand the BridgeClient code the websocket server would also need to read panel.cfg and panel.xml of the aircraft and provide the data to VCockpit so that the specific gauges can be loaded. Does this sound feasible or am I missing something important?
1 Like
amazing work! 1.0.5 works now.
Excellent, thank and glad it’s working!
If you need any help with testing or debugging I would be happy to assist.
Yes please. The biggest help you could be is to use the tool and confirm that it’s useful and fit for purpose, and explain which features are missing for your workflow (much like you’ve done). If you want to contribute code that’s also great.
- BridgeClient assembles the VFS (plus the ExternalPackages) and acts as a webserver for the external gauges with “.\html_ui” as document_root
Yes.
- Through the “ExternalPackages” overlay the external gauges are served with different files than the internal ones
Yes exactly, this is what enables getting anything except exactly what the VFS is in the game.
- External gauges only connect via websocket to BridgeClient to request, receive and send data to the sim
Yes. There’s /ws with A:/L: variable read/write/observe and /all_cfg which gets the panel.cfg and creates window.globalPanelData, the rest is regular files or /VFS/ which gets you files not under html_ui (like panel.xml).
What I would like to do is to set up an independent development environment with vscode and the live plugin to serve the necessary files from the vfs from a static copy. Additionally I would need to implement a websocket server that accepts connections from the external gauge and serves some static variables. With that I would be able to work on html gauges without running the sim (which is not possible at my work due to closed ports in the firewall). Especially when debugging it could be useful feed certain values (e.g. via a simple webinterface) to the gauges. This would also enable to feed the gauges from other sources like visualization of recorded flights. As I understand the BridgeClient code the websocket server would also need to read panel.cfg and panel.xml of the aircraft and provide the data to VCockpit so that the specific gauges can be loaded. Does this sound feasible or am I missing something important?
Yes this sounds good and close to in scope, although I was holding off on static data intentionally for a while. I’ve been kind of hacking things together to get all the parts working, so I don’t have a clear idea on how a panel.cfg and set of data should be provided, but this does dovetail with other scenarios as well (like using a gauge from a different plane, or testing a brand new gauge without having to modify a plane’s panel.cfg).
There’s two components in play:
- host for files
- bridge for panel.cfg, live sim data
Possibly there should be a js/npm-based host and a static data bridge. It’d be great to use react/vue and have hot reload workflows. It’s all possible, just needs some time to build it out.
Great work, davux3 and fantastic explanation of what is going on in the background of the sim. Nice, clean work!
1 Like
I have gone the C/C++ route with my flight information program and almost have it dialed in all the way. All I was needing was to have the numbers I need to see, larger. Great work again!
2 Likes
Yes, this is about where I started, I have a SimConnect C# program that arranges the 2D panels, and adds overlays not so dissimilar from yours, and then sends the images over the network to tablets which can then use touch input (apparently touch screens don’t even work properly locally, but remotely I have the benefit of controlling what gets sent to the windows and where focus goes).
Today, I’ve done some work to be able to call into each gauge loaded within the game, and issue commands and get data. This means that you can issue window location.reload() remotely, and do other things and exchange data.
This means that what can ultimately happen is this:
- Shut down the gauge in the cockpit (optionally I suppose)
- Interop with FS9GPS without worrying about ‘fighting’ with the gauge running within the sim.
Where this leaves things is a completely data driven external set of duplicate gauges. I’m keen on whether the performance here will also be superior. There is work to be done to make retrieving LVars more efficient, and hopefully increase over the current limit of 100 without adding any overhead. But once that happens, one wonders what good wasting cycles in the sim with rendering HTML/JS there is.
But even if this is wrong or irrelevant, I think this will make performance tuning gauges a lot easier as well (despite the runtime difference that are apparently relevant, i.e. fastToFixed usage).
1 Like
Well, yours is way more advanced than mine is, no doubt about that! I have had fun creating it for myself. The little project gave me a break from flying around the world so much. With over 100K miles in the TBM under my belt I needed a break. But I did have fun flying with my program today. I just need to figure out why “GPS ETA” is not matching the same value in the TBM-MFD-ETA field on the planes display. It’s always the simple things!
Carry on and great work!
2 Likes
I’ve just discovered but not verified that there is an entire second avenue into the sim, an InGamePanel can both speak to SimVars and also talk to the network!
https://forums.flightsimulator.com/t/get-or-stream-current-position/210945/4
I missed this before but it may well invalidate the approach I used above. If the sim will support upgrading to websocket this could work really well.
Hi davux3, thanks for your attention to my post. 
The API used for this solution was running on localhost, and the tablet I use for viewing my map is on the same local network than my own computer. So I just made the server available on my LAN to make things work. It wasn’t a necessity for me to reach an external host so I didn’t try with a remote URL and I can’t tell if it’s possible or not. I’d say it might be, as this just use a standard HTTP request, but I’m not sure about it.
Hi @MEB1993 thanks for the reply.
For my purposes I would also just be using a server running locally, which would then act as a relay and cache the data for the external (to the sim) clients.
I noticed the SkyVector/window template mod uses data on the internet, so that’s why I think it’s possible: GitHub - bymaximus/msfs2020-toolbar-window-template: Microsoft FlightSimulator 2020 Toolbar Extra Window Template
1 Like
My path to my community file is different from way to default “D:\GAMES\MSFS\Community” I change it in “settings.json”
Yup just make sure every \ is \\ or you’ll get an error.
Frankly, this is exactly what I was looking for to have the G3x externally without losing the controls of the aircraft when handled. Frankly I will follow this loan project because very interesting
1 Like
Once I properly updated my Steam variables to correct paths, I can now get the bridgeclient to load up.
I’m in my plane and ready to go, but the gauges don’t show up as the client says…
Log entries:
09:14:39 WEB: Server starting at http://127.0.0.1:4200/
09:14:39 WEB: HttpListener prefix: http://127.0.0.1:4200/
09:14:39 SIMCONNECT: Connecting to sim…
09:14:39 SIMCONNECT: Register data TITLE (string) None
09:14:39 SIMCONNECT: Connected to sim
09:21:26 Server request error (handed): System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at SimpleHTTPServer.Process(HttpListenerContext context)
at SimpleHTTPServer.ServerProc()
09:21:26 WEB: WS: Connected to 127.0.0.1
09:21:28 WEB: WS: Disconencted from 127.0.0.1
OK, turns out it doesn’t work with alternate liveries, only stock ones. 
I can imagine there’s a workaround for that, but this is already annoying.
So using a default livery, I got it to show up. But then I get this.
This implies the urlacl you added is incorrect. You should be able to remove the Port entry you added to confirm this, and it’ll run, or use netsh http show urlacl to ensure there isn’t a duplicate service registered.