ddawson

Dai, I gave up using PANEL_SERVICE_CONNECT_TO_WINDOW for just this reason. I usually put my SimConnect initialization and de-initialization routines in module_init and module_deinit. You could also try leaving your de-initialization routine in PANEL_SERVICE_DISCONNECT, making sure you set the value of the handle variable to zero. You would put your initialization routine in PANEL_SERVICE_PRE_UPDATE, wrapping it in an 'if' statement checking the handle variable against zero. Doug

TrafficRadar certainly requires a dll.xml entry in FSX. <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>TrafficRadar</Name> <Path>modules\TrafficRadar.dll</Path> </Launch.Addon> Doug

I (and a couple of others) have looked at this kind thing. Building an addon module for TeamSpeak that uses SimConnect to retrieve FS com frequencies is pretty straightforward. It gets slightly more interesting if you want to support the 64 bit TeamSpeak client, as SimConnect will only communicate with a 32 bit application. Therefore, your 64 bit TeamSpeak plugin needs a 32 bit helper dll to make the SimConnect connection with FS. Things get more interesting still when you consider making a "one size fits all" generic solution. Not all TeamSpeak servers have the same channel structure. Are we going to work with a fixed set of channels, or are we going to allow the user to create a new channel by switching to a currently unused com frequency? When we're handling passwords, which program is going to ask for a revised password if the stored one does not work - TeamSpeak or FSX? This could matter, depending if TS and FSX are running on the same computer, with FSX in fullscreen mode. As I don't fly online, I have no idea whether there would be an existing consensus on any of this stuff. I have no idea whether the OP went any further with his project or not (I don't recall seeing anything) but a lack of consensus on these issues may offer at least part of the reason why. Doug Dawson

Dai, I think Ed is right on this one. Attaching the VS debugger to FSX, I noted the same behaviour you describe - with the compiled dll in the archive you posted. I see that it is dependent on msvcr120d.dll, a file that wasn't on my system. installed the VS2013 runtimes and that didn't change the behaviour. When I simply recompiled the gauge with VS2012, using /MTd, the problem went away and the gauge loaded fine. Which of my gauges is giving you trouble?

I did some testing myself. I'm now pretty certain that the "FlightLoaded" event occurs before gauges start getting loaded, so we'll never trap it in a gauge. If you need to know the current flight name, use the SimConnect_RequestSystemState function.

Sorry, I just noticed this. I think you want void OnRecvEventFilename(SIMCONNECT_RECV_EVENT_FILENAME *pData, DWORD cbData) { if (pData->uEventID == FLIGHT_SAVED)strncpy(SAVED_FLIGHT,pData->szFileName,sizeof(pData->szFileName)); if (pData->uEventID == FLIGHT_LOADED)strncpy(CURRENT_FLIGHT, pData->szFileName, sizeof(pData->szFileName)); }

Dai, Call SimConnect_CallDispatch once, as soon as you call SimConnect_Open. When you are running in process (a gauge or module) you do not have to continually call it.

The FLIGHT_LOADED event is happening before you ever get to PANEL_SERVICE_PRE_UPDATE to initiate your connection to SimConnect.

Dai, You should be able to move the stuff I have in module_init and module_deinit to PANEL_SERVICE_CONNECT_TO_WINDOW and PANEL_SERVICE_DISCONNECT. I don't use PANEL_SERVICE_PRE_INSTALL for initialization stuff because it gets called when the panel window is resized or moved. When you are running SimConnect in a gauge, you only need to call SimConnect_CallDispatch once. It registers your callback function and that function gets called as needed. Don't call SimConnect_CallDispatch on each frame or update. I use the SIMCONNECT_RECV_ID_OPEN case in the callback function to set up all the information I want to sent to or receive from SimConnect.

Dai, Source code for my fuel dump gauge is here: www.douglassdawson.ca Doug Edit: I put the source code for the battery charger here: www.douglassdawson.ca/files/dsd_battery_charger_sourcecode.zip

Dai, A while ago, I put the in-process sample here: www.douglassdawson.ca/files/ESPIn-processDLLadd-on.zip I have the GDI+ sample as well, I will post it or e-mail it once I get home this evening. Doug Edit: www.douglassdawson.ca/files/ESPDrawing GaugesUsingGDI+.zip

It is possible that the sound files are embedded as resources in one or other of the dll files. If that is the case, it will not be an easy fix.

As Ray points out, the scenery in FSX (and P3D, I believe) is from 2005. The only real solution is to work with the data in the scenery files, rather than newer datasets which may contain more up to date real world information. From the point of view of the 2005 simulated world we are flying over, the "updates" in the newer datasets can only be viewed as errors, as hesynergy's experience clearly illustrates. Use of the stock GPS to verify where airports are, and how their runways are aligned, before filing a flight plan (or accepting a particular FSEconomy assignment) may result in fewer emergency landings.

Put the SimConnect.cfg file in the same folder as the ASN executable file.

UnigineSim is one part of the potential shiny new sandbox. It is not the whole sandbox. Also required are a physics engine that will determine how the planes fly, as well as ATC, AI, multi-player, etc. Doug