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

Based on the contents of a couple of panel archives in the library here, you're probably looking for a file named whm-sound1.wav The xmlsound.gau listens for the afterburner events. When it detects that one of them has occurred, it plays the corresponding sound. (whm-sound1.wav, whm-sound2.wav, whm-sound3.wav, whm-sound4.wav) I don't think there is anything more to it than that. You could edit those sound files to suit your taste, of course. xml itself does not support sounds. Your only choice is some type of addon gauge or module, written in C, that will play sounds when your xml gauge says that it should. Bill's gauge uses the afterburner events as the signalling mechanism between xml and his gauge. My gauge, available here (www.douglassdawson.ca) uses xml L:VARS as the signalling mechanism. A word of warning though, beginners invariably find my gauge very hard to wrap their heads around. If you're not comfortable with xml, then you will probably have more fun flying the Canarsi approach with an engine out. Doug

Your panel is using the late Bill Morad's original xml sound gauge. It uses the afterburner events to trigger sounds. It dates back to FS2002. A quick search here, flightsim.com and at simviation.com did not turn up the original uploaded gauge. I don't know much more about it than that.

You need to #undef the macros after each sub-gauge: #define GAUGE_NAME "cpc\0" #define GAUGEHDR_VAR_NAME gaugehdr_cpc #define GAUGE_W 20 #include "flighteng\dfd_cpc.cpp" #undef GAUGE_NAME #undef GAUGEHDR_VAR_NAME #undef GAUGE_W //for completeness only, seeing as you're using the same value again

Excellent. Good to hear!

Here is the contents of my SimConnect.ini file: [simConnect] level=verbose console=0 ;RedirectStdOutToConsole=1 ;OutputDebugString=1 file=f:\fsx_SimConnect\simconnect%03u.log file_next_index=7 file_max_index=100 You will of course need to change the path to something that works on your system. The simconnect.ini file itself needs to be in My Documents\Flight Simulator X Files

The entries certainly look reasonable. If you have configured the SimConnect.ini file on the server to produce a log file, you will see at the beginning the protocols that the current instance is supporting. I imagine you will see the global protocol that you are specifying, but do check to be sure. The other thing to consider is that the settings in the SimConnect.cfg file on the client machine have to exactly match the settings in the SimConnect.xml file on the server. The SimConnect.cfg file can be located either in the application folder or in "My Documents" To be honest, I'm not sure which of those will take precedence if there is a SimConnect.cfg file in both locations - you might need to experiment a little. The program you're trying to use on the notebook should have created a SimConnect.cfg file. I would make sure the Simconnect.xml file settings on the server match those specified in the SimConnect.cfg file of the application, with the caveat that the IP address specified in both files must be that of the server, not the client. Doug

The link posted above is a good one. You most likely need to create or modify the SimConnect.xml file on the computer acting as the server (the one where FSX itself will run, presumably the desktop unit.) And I'm going to respectfully disagree with Jim. You've got to post the question where you think you're most likely to get a useful answer. Doug

I think you'll find the big users of VAS are texture and bgl files. If you're going to draw that stuff on the FS screen, then its going to end up in the FS VAS. You can certainly do all the physics in a separate application (I think somebody did that recently with a Dash 8) but it won't save you much memory.

Use the Windows API SendMessage function to send WM_CHAR or WM_KEYDOWN messages?

SimConnect.cfg can reside in either the folder with the calling application, or in 'My Documents' Have you repaired the right copy of the .cfg file? Doug