Problem #1 on Steroids... (FSUIPC Registered Version)

[Raysot]

After some reading I've determined that I, too have problem #1

Some basics:

Clean install of Windows XP Pro (SP2)

Clean install of FSX

Clean install of the SimConnect.MSI and SDK

Windows Firewall Disabled

No A/V Software

No adware software

The FSUIPC install process is clean (No Errors or MessageBoxes())and it finds the FSX install without issue

Starting FSX:

The Simconnect Diagnostic window shows no abnormalities: Shows "DLL Loaded" with the correct path to ...\Modules (Although I do have to tell FSX that it's ok the Start FSUIPC upon every load)

DLL.XML is correctly modified to load the FSUIPC.DLL, so the install does find it ok and it shows as False

In FSX:

No Add-On menu. No FSUIPC connectivity (Trying to run WideClient from a remote System)

FSUIPC.Log:

********* FSUIPC4, Version 4.02 by Pete Dowson *********

User Name=""

User Addr=""

FSUIPC not user registered

WIDEFS not user registered, or expired

Running inside FSX

Module base=61000000

LogOptions=00000001

DebugStatus=0

94 System time = 21:40:53

94 FLT UNC path = "C:\Documents and Settings\Ray.MAIN\My Documents\Flight Simulator X Files\"

94 FS UNC path = "D:\Program Files\Microsoft Games\Microsoft Flight Simulator X\"

4125 Failed on SimConnect_Open, return = -2147467259. FSUIPC4 cannot operate!

FSUIPC.Ini:

[General]

History=5T1LKAWK84ESQZ9ALHBW6

TCASid=Flight

TCASrange=40

AxisCalibration=Yes

DirectAxesToCalibs=No

ShowMultilineWindow=Yes

SuppressSingleline=No

SuppressMultilineFS=No

WeatherReadSeconds=1

[WideServer]

WideFSenabled=Yes

(SimConnect does function as I am able to run remote apps and get FSX data over the network)

Might this be a port issue? I have my SimConnect.XML Port set to 1435...

My SimConnect.XML:

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

SimConnect

SimConnect.xml

False

False

Auto

All

64

1435

4096

False

Any help is appreciated.. Let me know if I need to provide more info...

Ray

[Pete Dowson]

Although I do have to tell FSX that it's ok the Start FSUIPC upon every load

This shouldn't be needed if you tell Windows to trust software specifically signed by me -- it's an option in the dropdown on the security warning. It places my certificate into the IE repostiory as a "trusted publisher".

The only other possibility is that the Manual.Load entry in the DLL.XML file is for some reason set to "True" instead of "False" -- the FSUIPC4 Installer sets it to False.

4125 Failed on SimConnect_Open, return = -2147467259. FSUIPC4 cannot operate!

In the current interim releases (we are up to 4.026 now, in the FSX downloads above) this odd error number is shown in hex too, as it seems to lok more sensible then. It is 0x80004005.

Unfortunately this does not appear to be any standard error number and I've not managed (yet) to get an answer on it from MS, but it does seem pretty certain that it is a fiewall permissions problem. I know you say you have these things turned off, but could you follow the link in the firewalls announcement above anyway, and see what MS themselves say?

Please asl report this to tell_fs@microsoft.com with as much info about your system as possible.

Thanks.

Pete

[Raysot]

Well, I can tell you from experience that the error code 0x80004005 is Microsoft's way of saying "Yeah.. there's a problem, but we don't know what it is..." It's basically a bit-bucket.

I upgraded to the latest FSUIPC today, but still same problem.

What do you mean by "ASL"?

[Pete Dowson]

Well, I can tell you from experience that the error code 0x80004005 is Microsoft's way of saying "Yeah.. there's a problem, but we don't know what it is..." It's basically a bit-bucket.

Yes, I found it. The reason I didn't recognise it is that it isn't defined in SimConnect, but in a standard WinError header file! So, yes, you are rightit simply means "an error has occurred"! How naff! :-(

The SimConnect author merely agrees that the SimConnect error reporting needs improving. He cannot say what the error is yet.

I upgraded to the latest FSUIPC today, but still same problem.

Of course. There's no way anything I can change in FSUIPC can get around the fact that SimConnect is simply refusing to connect.

What do you mean by "ASL"?

"ASL"? I don't use the expression so I don't mean anything. What does it stand for?

Looking back on your previous report, I see you've created a SimConnect.XML file for remote use of SimConnect, but in that you have not allowed the default local use. I think that is the problem. If you don't have that file (rename it for now) I think FSUIPC will work.

Seems that SimConnect assumes the local connection by default if you omit the file, but if you are explicitly listing connections you need to list the local one (on 127.0.0.1 I think) as well, else you won't get one.

Daft I know, and I only discovered that through another user recently -- there's a thread here about it somewhere.

Regards

Pete

[Raysot]

It appears I've made some progress....

If I change my SimConnect.XML file to read:

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

SimConnect

SimConnect.xml

False

False

Auto

local

64

4096

False

...where the scope is only local, the FSX Add-On menu is present and accounted for. I can even connect to FSX via WideFS from a remote client.

What I can't do (And this may be by design but I wish it wasn't) is connect WideFS AND a raw SimConnect remote application. The Raw SimConnect app sees FSX and assumes that a connection is valid, but no data is passed. (Obvously because SimConnect Scope is set to Local).

Setting SimConnect to global allows my remote SimConnect app to run, but of course there's no remote connectivity to FSUIPC and the FSX Add-On menu disappears.

[Pete Dowson]

Setting SimConnect to global allows my remote SimConnect app to run, but of course there's no remote connectivity to FSUIPC and the FSX Add-On menu disappears.

Seems you misread my last reply. I said

"Seems that SimConnect assumes the local connection by default if you omit the file, but if you are explicitly listing connections you need to list the local one (on 127.0.0.1 I think) as well, else you won't get one."

You can have multiple server ports and addresses listed. You are simply replacing one with another by only having the one entry.

There was another thread showing a working XML file. didn't you look? I'm sure this was all dealt with in the Beta newsgroups as well -- didn't I see you there? Obviously MS really needs to get the documentation sorted on this one.

Found the other thread now (searched on "XML". See this one http://forums.simflight.com/viewtopic.php?t=57373

Regards

Pete

[Raysot]

Thanks a bunch, Pete. That last link you posted did it for me. I can run both WideFS and a SimConnect app side-by-side on a remote system, as well as have access to the Add-On menu in FSX.

Thanks for helping me get this all sorted out.

[Pete Dowson]

Thanks a bunch, Pete. That last link you posted did it for me. I can run both WideFS and a SimConnect app side-by-side on a remote system, as well as have access to the Add-On menu in FSX.

I'm working on making the FSUIPC4 installer check for a Simconnect.XML file, and correcting it automatically if the "local" section is missing! ;-)

Regards

Pete

[Raysot]

Maybe this is the solution to "Known Problem #1" listed for FSUIPC... One other detail I discovered that all remote clients need to be in the same Windows Workgroup. I tried to find a reference to this in the new docs but couldn't.

I had one system that resided in a different workgroup. Although I could ping it and do every other thing imaginable with TCP/IP, WidClient just wouldn't connect until I moved that system into the same workgroup.

No reply necessary, just something that might come in handy for a FAQ blurb for us nerds that have systems everywhere.

Thanks again!

[Pete Dowson]

Maybe this is the solution to "Known Problem #1" listed for FSUIPC... One other detail I discovered that all remote clients need to be in the same Windows Workgroup. I tried to find a reference to this in the new docs but couldn't.

Erall FSUIPC clients have to be on the same PC as FS in any case, so they are in the same workgroup by definition. None of the SimConnect TCP/IP blocking problems I list in the read-me are anything to do with WideFS. Pretty much anything that blocks network traffic will obviously be a problem for stuff on networks.

I don't know much about all this "workgroup" business. I always thought ALL computers you wanted to talk to each other needed to be on the same workgroup -- else what is the point of them? All mine have always been on the same workgroup.

No reply necessary, just something that might come in handy for a FAQ blurb for us nerds that have systems everywhere.

Tell me why you'd expect separate workgroups to be able to freely exchange data please. If they can, why have separate workgroups? Maybe if I understood that I could write about it. As far as WideFS is concerned I think I assumed that if your computers could talk to each other they MUST be on the same workgroup (as well as on the same IP subnet, for TCP/IP protocols anyway).

Regards

Pete

[Raysot]

Tell me why you'd expect separate workgroups to be able to freely exchange data please. If they can, why have separate workgroups? Maybe if I understood that I could write about it. As far as WideFS is concerned I think I assumed that if your computers could talk to each other they MUST be on the same workgroup (as well as on the same IP subnet, for TCP/IP protocols anyway).

Pete, I wanted to follow up with you a little on this topic.

My network at home consists of several workgroups, but all on the same TCP/IP segment. My curiosity is up because if FSUIPC/WideFS communicate using IP packets, I don't understand the necessity to check workgroup information. I've a few webservers, each residing in a different workgroup, but I can browse them from different workgroups.

I know my network is definitely the exception. As my wife puts it, I've totally geeked out the basement with all the servers down here.

Your question about why have separate workgroups is a good one. I think it gives some sense of organization, as all of my "dedicated" sim servers are in a dedicated workgroup. I do some development work occassionally on a system in a different workgroup and it's sometimes frustrating when the underlying IP communication can't traverse workgroups.

[Pete Dowson]

My network at home consists of several workgroups, but all on the same TCP/IP segment. My curiosity is up because if FSUIPC/WideFS communicate using IP packets, I don't understand the necessity to check workgroup information. I've a few webservers, each residing in a different workgroup, but I can browse them from different workgroups.

Sorry, I'm not up on all this stuff. What is a workgroup for then?

Your question about why have separate workgroups is a good one. I think it gives some sense of organization, as all of my "dedicated" sim servers are in a dedicated workgroup.

But if the rules between workgroups are the same as within workgroups, what is the point? Isn't the same thing accomplished by just naming them sensibly. Like "FS-Left", "FS-Right", "Office-Server", "Office-Email", etc?

I do some development work occassionally on a system in a different workgroup and it's sometimes frustrating when the underlying IP communication can't traverse workgroups.

Ahso you are saying they can't, or not easily, or what? I'm confused now.

I think the main workgroup problem told to me was related to the mailslot system used by WideFS (for Win2K and WinXP systems only -- it wasn't provided before) for WideServer to broadcast its presence to Clients. But if the normal TCP, UDP or SPX protocols work across workgroups, then you could still use WideFS but you'd have to explicitly provide server and protocol details to each Client not on the same workgroup.

Isn't that how it goes, or am I still confused? Maybe I'm mixing workgroups up with the "subnet", identified by the IP Addresses masked by the Subnet mask? I have all those the same too.

Regards

Pete

[Raysot]

I see where you might be confused. If you recall back to the days of the OSI model (Let me see if I can recall myself, it's been so long)

Physical

Datalink

Network

Transport

Session

Presentation

Application

Subnets, as you are referring to are more in the Network layer and determine how many hosts you can have a on an IP subnet.

Workgroup information (And I know some network guru is going to correct me on this :-) ) is attached above the network layer and starts getting into session information, or the higher-level information in a network packet.

Basically, as long as the network routing is set up correctly, you can have systems on different IP subnets, yet members of the same workgroup.

The answer to the question "Why have different Workgroups" will vary, depending on who you talk to, but it's basically for security purposes... preventing to some degree, the passing of data from one workgroup to another unless the are permissions between workgroups to do so. Again though, this refers to "Files" and services , which rest higher up in the OSI model. IP packets don't care until the workgroup information is added to them.

[Pete Dowson]

.... though, this refers to "Files" and services , which rest higher up in the OSI model. IP packets don't care until the workgroup information is added to them.

So, WideFS should work across workgroups, except for the Mailslot Server broadcasting system I added which is, I believe, using a specific Service?

Thanks,

Pete

[Raysot]

This is where my knowledge of the underlying interprocess communications takes a nosedive.

As a typical 'user', my natural assumption would be yes, that WideFS should be able to communicate on the IP layer without regard to the upper layers of the OSI model....

...until you add the Mailslot service to the equation. After a cursory read-up on what that service is, I have to say that it looks like it would require a complete re-design of the WideFS/FSUIC communication layer. I'd be more inclined to just tell people to "...make sure all the systems are in the same workgroup" :wink:

[Pete Dowson]

...until you add the Mailslot service to the equation. After a cursory read-up on what that service is, I have to say that it looks like it would require a complete re-design of the WideFS/FSUIC communication layer.

The Mailslot use in WideFS is an addition. It isn't essential. I just wanted a way for the whole thing to work automatically, without users having to edit anything at all in any INI files. Just bung WideServer into FS, WideClient into each client, run everything and they all link automatically.

The way I found to do this was by the Server sending regular mailslot packets (once a second by default), each containing its IP address and preferred Protocol. Any unconfigured Clients read mailslots regularly, and recognise one from a Server.

That all works fine on XP and Win2K, but the service never existed in Win98 and so on. Not even NT as far as I know. So it isn't an essential part of WideFS. The original method of specifying the IP address or name of the Server in the Client INI file is still there.

So there is no need for any "re-design of the WideFS/FSUIPC communication layer" really.

I'd be more inclined to just tell people to "...make sure all the systems are in the same workgroup" :wink:

I think I may have been doing that in any case. ;-)

Best Regards

Pete