Raysot

Disregard. I read the directions. 😄 I'm not sure if *anyone* can download this version. The browsers are all hard-closing the connection, saying "Virus Detected". I have all my anti-virus stuff turned off and browser safety set to "I don't care" Browsers I've tried with no success: Edge Chrome Opera Vivaldi DuckDuckGo Firefox

That was the ticket!. I didn't even know about this facility. Thanks for the info. I've tested it with my 2 A:Vars that I've been struggling with and it works like a charm. Thanks, John 😁

Greetings all, I'm hoping someone has some insight into why certain A:Vars can't be read by LUA using the FSUIPC LUA engine. Specifically, I'm trying to read the following A:Vars: CIRCUIT SWITCH ON:73 CIRCUIT ON :125 I'm using the call: RudderBoost = ipc.readLvar("CIRCUIT SWITCH ON:73") Using the SimVar Watcher tool that comes with the 2020 SDK, I can get values from that A:Var I've tried several variations, like ipc.readLVar("A:CIRCUIT SWITCH ON:73") and ipc.readLVar("A:CIRCUIT SWITCH ON,73") ...and a few other variants, all returning NIL. It's a stupid-simple script so I won't take up text real estate with the other stuff. I have had success in reading most other L:Vars and offsets, but not A:Vars Hope somebody can help!

Is there any way to make offset 0x07AB Read/Write? I'm struggling with how to set the External Power switch in the King Air. There doesn't seem to be any way to perform this operation programmatically in FS2020.

Greetings! I stumbled on this thread in my search for Arduino/P3D and now MSFS2020. I have a full-size pit using X-Plane and I need to convert 20 microcontrollers over to 2020 from X-Plane. Has the work in this thread been abandoned or is it still a work in progress? Curious in Seattle Ray S. raysot <at> comcast.net

...trying to find the "Pressure Altitude" offset. When I change the Kohlman (Baro) setting from 29.xx to 29.yy (Or some other arbitrary value) which offset do I look at to get the new pressure alt? (Or is this derived?) I can get Aircraft Altitude easy enough, but factor in millibars and I've no idea. Any help is appreciated. Ray Sotkiewicz EllieSystems.com

Does anyone know the offset for toggling the IAS/MACH display on the 737/747 autopilot? I've looked everywhere but can't seem to locate this little tidbit.

For all of you EPIC users out there... How are you handling Setting of VS? With ALT, HDG and SPD, it's easy enough to go through axis values in EPICINFO, but for VS I've always used joystick button events to Inc/Dec VS and then simply read the VS value back into EPIC to make it a psuedo-closed loop system. PM has an offset where just by talking to it, you can inc/dec VS. I was wondering if there was a similar facility now for FSX or are we still relegated to using the game controller API?

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:

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, 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.

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!

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.

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.

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"?

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

Thanks for the info, Peter. I'll drop him a line and see how he's doing. :D

I was wondering if anyone has been successful (Using C#) in writing text to offset 0x3380 for display on the windscreen... There are currently 5 overloads for FSUIPC_Write(), but none seem to favor the writing of a string() value. Any help is much appreciated. Ray