SimConnect - again?

[FlyingAxx]

I'm just struggeling with an other topic. Plan-G is is installed on a second network-pc (everything is based on Win7) and it seems the connection works - in principle. At least the log and Plan-G itself are telling me "connected". However, I cannot see any traffic including my own plane. Even if the connection is set to be locked, I'm still able to shift the map and it remains as it is. Other observations: I cannot change within Plan-G the tracking mode (locked, sync, free).

Edit: I forget to say that I'm not in my own network.

[tim arnot]

Seeing the yellow user plane is the basic test of connectivity - assuming it's enabled in Settings. If that doesn't appear after a few seconds, even it it thinks it's connected, then something's up. The user plane is refreshed typically every 3-5 seconds, and traffic every 30.

If this is not your normal LAN, then it could be an issue of firewall, antivirus etc blocking the data packets.

Usually it's optimistic about the connection - if it's not actively refused. But it'll drop back to 'disconnected' if there's no data within 30 seconds or so.

[FlyingAxx]

Seeing the yellow user plane is the basic test of connectivity - assuming it's enabled in Settings. If that doesn't appear after a few seconds, even it it thinks it's connected, then something's up. The user plane is refreshed typically every 3-5 seconds, and traffic every 30.

Yeah, and this obviously fails  >:(

If this is not your normal LAN, then it could be an issue of firewall, antivirus etc blocking the data packets.

That's unlikely in this case as far as I know - probably a matter of UAC (that's what I think as everything is installed under "C:\Program Files (x86)")

Usually it's optimistic about the connection - if it's not actively refused. But it'll drop back to 'disconnected' if there's no data within 30 seconds or so.

Hmm, I saw it a bit later in the log (I think). However there is no reaction on Plan-G's GUI. BTW, the building of the database worked and this means that the access is there -  in principle even if SimConnect seems to be a quite different animal.

Ah, there is an other observation: I tried out the SimConnect Configuration Tool and failed when trying to write the entries. Do you have any advice where to look at in this case? I think I can check any hint on Monday...

[tim arnot]

Simconnect is all async comms on the IP stack, and at my end it's all done through a 3rd party library that's kinda buggy, which is a bit unfortunate cos it's hard sometimes to tell what's going on, and very little that I can do about it.

I can do a debug build that logs all the sent messages and receive events. You could compare that to the Simconnect log from within FSX, which will at least tell us what messages get through and what don't. Won't be till the weekend though.

(Building the database is all file-based, so it has no real bearing on whether Simconnect will work.)

[FlyingAxx]

Tim, your plan sounds rather cool, however, I'll try to fix it on Monday and then I'll come back with the results.

[JoHubb]

Tim, your plan sounds rather cool, however, I'll try to fix it on Monday and then I'll come back with the results.

How did you get on?  I'm struggling to get PlanG  talking to FSX via WideFS (FSUIPC). I gave up on Simconnect a long time ago.
The LAN is running perfect. The navigation db upload worked. 

I have WideFS.dll on the server, and WideFS.exe and .ini on the client. The locations are correct but PlanG will not connect.

I must be missing something obvious. Any advice would be appreciated. Thanks,

John

[FlyingAxx]

Tim, your plan sounds rather cool, however, I'll try to fix it on Monday and then I'll come back with the results.

Well, I tried, but with no results. While comparing with my own setup at home I found out something mysterious. I expected to find the file simconnect.xml at least in a generic version in the folder "C:\Users\<name>\AppData\Roaming\Microsoft\FSX" but it wasn't there in both cases. At home I found it in a backup-folder of a previous FSX installation which had to connect to my laptop having Plan-G V2 installed. However, I have no idea which action might have triggered the building of this file as it seems to be not necessarily present in case of a pure local connection on the same computer.

My actual problematic case consists of three PCs running FSX, all having PLan-G installed, and while connected via FSHost in all installations the respective partner's planes are visible as expected. I think that FSHost works here as transmitter of the data exchange, however it should not do more than adding the other active planes to the existing virtual traffic. However, the fourth PC was intended just to show Plan-G on a 40" monitor (it's a TV screen) visible from all places while being connected to the FSX-PC that serves as host in order to make the individual switching between FSX and Plan-G obsolete.

Does it make sense to copy just a adapted version of simconnect.xml into the above mentioned folder? Unfortunately I wasn't able to test it today (I forgot the USB stick at home <grrr>).

[tim arnot]

You don't need simconnect.xml for a local connection, but I don't think having there will make much difference - the contents are all about associating a port number to a remote IP. Anything local is assumed - IIRC - to be on port 0.

i didn't get the test build finished - we had internet problems here all weekend causing no end of headaches.

I'm also adding in a cfg switch, so you can switch the verbose logging on/off as required.

[FlyingAxx]

You don't need simconnect.xml for a local connection, but I don't think having there will make much difference - the contents are all about associating a port number to a remote IP. Anything local is assumed - IIRC - to be on port 0.

i didn't get the test build finished - we had internet problems here all weekend causing no end of headaches.

I'm also adding in a cfg switch, so you can switch the verbose logging on/off as required.

Tim, when entering a port number, proposed by the SimConnect Configuration Tool, directly in the connection data of Plan-G,  it was a safe way to crash the application. I understand that the choice of Port 0 can circumvent this. What I do not understand is that the configuration tool refuses to write the file even if the target folder has been cleared for such actions. Well, it's not yours...

[Penz]

I have Plan-G working fine via SimConnect.

My SimConnect.xml looks like this:

Code Select Expand


<?xml version="1.0" encoding="Windows-1252"?>

<SimBase.Document Type="SimConnect" version="1,0">
  <Descr>SimConnect Server Configuration</Descr>
  <Filename>SimConnect.xml</Filename>
  <Disabled>False</Disabled>

  <!-- Plan-G (remote) IPv4 Server Configuration-->
  <SimConnect.Comm>
    <Disabled>False</Disabled>
    <Protocol>IPv4</Protocol>
    <Scope>global</Scope>
    <MaxClients>64</MaxClients>
    <Address>192.168.87.100</Address>
    <Port>4506</Port>
  </SimConnect.Comm>

</SimBase.Document>


192.168.87.100 is the address of the FSX/P3D PC on the local network.

I put this file in "\Users\[Myname]\Appdata\Roaming\Microsoft\FSX" and "\Users\[Myname]\Appdata\Roaming\Lockheed Martin\Prepar3D v2" on the PC running FSX and P3D.

Only thing I have done on the PC running Plan-G is to set up Plan-G to use Simconnect, with settings IPv4, IP address 192.168.87.100 and port 4506 (same as in the XML above!). I do have SimConnect (all 4 flavours) installed on that PC too though.

[FlyingAxx]

I have Plan-G working fine via SimConnect.

My SimConnect.xml looks like this:

<snip>

I put this file in "\Users\[Myname]\Appdata\Roaming\Microsoft\FSX" and "\Users\[Myname]\Appdata\Roaming\Lockheed Martin\Prepar3D v2" on the PC running FSX and P3D.

Only thing I have done on the PC running Plan-G is to set up Plan-G to use Simconnect, with settings IPv4, IP address 192.168.87.100 and port 4506 (same as in the XML above!). I do have SimConnect (all 4 flavours) installed on that PC too though.

I tried the same with a different port, however, today I'll make the next try. At the moment it seems to be a matter of user rights, but I didn't really decipher what is going on. The Log includes hints that the connection fails.

EDIT (hours later): The connection failed again. When trying to connect having named any port within Plan-G settings (in this case the same as above) I can wait for the crash. The crash is reproducible. However, it's likely a problem linked to rights even if this seems to be beyond my horizon. I can remotely access each necessary folder on the computer where FSX is installed, I can open files, but it seems that the application is blocked somehow.