ZG862

No problem. Have you got it working now?

Just as a reminder, you need to set "console=1" in SimConnect.ini on the FSX machine. Z

Sounds like a TrackIR problem rather than SimConnect but let's see. Best way is to switch the debug logging window on (see previous posts in this section) and then look for errors at the point of failure. Z

You're welcome, Paul-Henri. Sounds like a very interesting project you have. It seems to me that as soon as one starts to experiment with non-trivial hardware, the integrated model found in FSX's architecture starts to break down a bit. In my prototype, I want the aircraft to always be where I left it (unless I explicitly choose differently from an instructor station) with systems updated to reflect such things as reduction in battery charge etc. This has necessitated playing around with the FLT files in the way I suggest above which seems to work well. My client application initialises separately from FSX, makes whatever changes I require to the file then copies it across the network to the FSX machine and after establishing a SimConnect connection (well, 3 connections actually) loads it. From what I could find out, most elements of the flight file can be changed dynamically using SimConnect functions but it just seems simpler to me to do the bulk of the work in the file. The bit I haven't yet figured out how to do is establish the simulator state programmatically, which doesn't matter so much at the moment but will become important to achieving fault tolerance. Anyway, best of luck with your project. Look forward to hearing how it progresses. Z

Hi Paul-Henri. Can I ask what you are trying to achieve? It sounds a bit like you want to be flying along then have the surface textures change instantly - which seems a little odd. Do you have something a little more cunning in mind? Also, I've never tried setting the date just before the season cut off and seeing what happens as the day changes. I suspect that FSX loads the season textures as the flight initialises and then sticks with what has been loaded, which may mean that dynamically changing in-flight is not possible. Like I said though, I've never tried it but would be interested to know the results. If it can change from day to night textures dynamically then perhaps this is the same? Cheers, Z PS/ You can certainly load a new flight programmatically if that is your issue. Ask if you need more details as I'm doing this a lot at the moment.

Not sticking it on a remote machine in this way, no. It may well be that there is a way to configure it so that it works on a remote machine but so many elements seem to be dependent on things it would access locally that I would be very surprised if it DID work just by copying the exe across. I'll defer to anyone who knows better of course, but there would seem to be far simpler ways to confirm that SimConnect is installed correctly - not least to install a mature application designed to reside remotely. If you've got Office installed, I could probably write you a few lines of VBA that would do the trick. Z

Hi Paul-Henri, The season is held (amongst other places) in the .flt file. One way to change it is to use the Windows API's WritePrivateProfileString() function to write to the "Season=" entry in the "DateTimeSeason" section before you load the flight. I have yet to try to change season once the simulation is loaded and don't know if this is even possible (I suspect not but am happy to be corrected). If you take a look in the variables section of the SDK documentation (located in the SDK folder of wherever you've installed the SDK and named "sdk overview.html") there are likely to be reference to date/time/season settings. Cheers, Z

Oh this is frustrating! I see nothing wrong with that SimConnect.xml file. I wouldn't use that port number personally but it's a trivial thing - I read somewhere that 1200 was a good starting point. So let me remind myself of the issue: When you run AI Traffic.exe on the remote machine, you get a command prompt window opening and closing, right - with no indication that it is operating? Having just tried the very same thing on my machine without FSX running on my remote server, this is exactly what I get and I KNOW SimConnect is working just fine on this machine, since I've been programming with it. I'm having another a-ha! moment (no Morten jokes please). What's to say that SimConnect is not working on your setup too? Maybe AI Traffic needs a bunch of other stuff to run... More reading required. Watch this space. Z [Edit: After a pause for reading] Hmmm. I find nothing in the help file (%SDK installation folder%\SDK\Environment Kit\Traffic Toolbox SDK\Traffic Toolbox.html) that indicates that it can/should run on a remote machine. Am I missing something? Z

Hi Ernie. Not sure the OP reported a problem seeing his ac in Plan-G; If I've understood the root issue correctly, he seemed to be unable to run AI from a remote machine and suspected SimConnect to be the culprit. I'd agree with you that the FSUIPC log seems to indicate that it is working correctly LOCALLY, although there has been nothing yet to confirm that "global" (i.e. across the network) operation is working. My strategy was to establish that the server starts normally and to see it's address/port settings in the diagnostic window and then observe the attempted connection from the remote machine. Sadly, we've failed at the 1st hurdle since the dialog window doesn't display, despite the SimConnect.ini file being apparently configured for it to do so. This suggested to me that the server is not reading the .ini file for some reason (permissions?). The other option is the log file - but the settings for this are also in the .ini file so I'm not expecting that to work either. The current line of investigating the SimConnect.XML file can show us the configured port for the global entry but I can't see how we can establish whether or not SimConnect is even starting (other than the apparent operation of Plan-G which I presume uses SimConnect through the local connection?). I suppose it should probably show up in Task Manager. Thoughts? Z

What a well constructed install log. He's good, that Pete Dowson. But alas, I don't think this sheds a great deal of further light. The references to SimConnect seem entirely normal. The installer finds the SimConnect.XML file (in which the local port is specified) in the "\Users\User\AppData\Roaming\Microsoft\FSX" folder and ascertains that there is an entry in it for the local FSUIPC to access. What is doesn't say is if the SimConnect.XML file has a "global" entry - which sets the parameters for a remote machine to access this one. Perhaps this is a good time to take a look at that SimConnect.XML file. Would you mind posting it? Also, can you confirm that you are not logging in using the Administrator account? Cheers, Z

Dunno (99% sure they can co-exist happily) - but can we have a look at the install log?

Makes sense to me - just didn't realise SimConnect could do this. Nevertheless, I'm still baffled by Fnav's issue with displaying the diagnostics window. Without this (or some debug output) I don't see how we're going to be able to work out which add-on is failing at which point. Since I've only ever experienced this functionality behaving itself as advertised, I'm struggling to come up with a theory of what may be going wrong. The previous suggestion of mine relates to an application placing the SimConnect.dll in the Global Assembly Cache resulting in all .Net applications referencing the same version. I can imagine how this could cause problems within add-ons. However, Fnav reports that he's not using SE (the culprit in the thread on FSDeveloper) so I wonder if another add-on's installer (ASN?) might do the same thing?? If I get time I'll do some reading up on the GAC... Z

Hi Ernie. <quote> I find that creating a separate SimConnect.cfg for each program [...etc] </quote> How do you programs tell SimConnect.dll which SimConnect.cfg file to use? Z

By way of an addendum I came across a thread on FSDeveloper (can't insert hyperlinks at the moment for some reason) that might indicate the cause of the problem. Have you by any chance installed the Steam Edition? It seems that it does something in its installation that forces .Net programs to use a particular version of the SimConnect dll - which may be incompatible with FSXA. Just a thought. Z

Sadly, I am too at a loss and this is beyond my experience, so I'm hoping others may chip in with ideas at this point. With regard to the AI traffic thing, the way I understand it is that the client application must refer to the SimConnect.dll library that it wishes to use. As you point out above, there may be multiple versions installed (in the WinSxS folders), each of which may communicate to FSX servers (potentially on different machines) using the parameters specified in the cfg file And yes I did mean the FSX menu. The only other thing I can think to try is setting the ini file to produce an output file - but if the console isn't displaying then I can only think that the ini file is not being read. Help! We need a grown up!