Pete Dowson

I'm definitely NOT the best person to ask about this. I had a devil of a job and only managed to share files on Vista properly by trial and error. It is a most infuriating operating system, setting traps all over the place and trying to hide things from the user. I am only using it on my main two FSX systems, and then only because I am using the 64-bit version for more memory usage (8Gb and 4Gb respectively). The first thing I did on Vista was disable UAC (User Account Control) and stuff like Windows Firewall, Windows Defender, and so on. Even doing all that wasn't easy. And I wouldn't do that sort of thing if I were using the same system for Emails and Websurfing -- these are FSX machines only1 Check using Windows Explorer. Providing you can see the folders which FSC wants to see from the client PC, using the same paths you've given FSX, and you can read and write files to it, I really think that proves you've done enough. Are you sure it isn't still the same Networking error you started here with? i.e. Error on client gethostbyname() [Error=11004] Valid name, no data record of requested type Remember? Your Server name (PILLY) is not recognised, and you had to use the IP address? How does Windows Explorer see the Server -- presumably not using that name? If you never fixed the network problem I guess that could still be the main reason for FSC's problems. Regards Pete

Yes, it does all look perfectly healthy. There's evidently something else going on with FSC. Sorry, i can't really offer any further advice on the problem. Regards Pete

Thanks, but there's important information presented at the ends of all three logs, when you've closed FS down fully. Unfortunately it looks as if you provided these from a still-running FS. Regards Pete ********* WideServer.DLL Log [version 7.30] ********* Blocksize guide = 4096 (double allowed) Date (dmy): 03/10/08, Time 08:20:13.793: Server name is PILLY-PC 15678 Initialising TCP/IP server 15678 Initialising IPX/SPX server 15678 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 15693 Failed to start IPX/SPX Server 15693 Initialising UDP/IP server 16115 Broadcasting service every 1000 mSecs 16115 Preferred protocol = TCP 24695 Incoming connection Accepted ok (skt=11796) TCP 24866 Connected to computer "PILLY2-PC" running WideClient version 6.750 (skt=11796) TCP 2429138 Error 10053: client socket disconnected at Client: removing (skt=11796) TCP 3267129 Incoming connection Accepted ok (skt=11216) TCP 3267269 Connected to computer "PILLY2-PC" running WideClient version 6.750 (skt=11216) TCP 5474574 Error 10053: client socket disconnected at Client: removing (skt=11216) TCP FSUIPC4, Version 4.30 by Pete Dowson ********* Reading options from "C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.ini" User Name="glenford gumbs" User Addr="biggest424@hotmail.com" FSUIPC4 Key is provided WideFS7 Key is provided Running inside FSX on Windows Vista (SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed DebugStatus=255 187 System time = 08:08:46 234 FLT UNC path = "\\PILLY-PC\Flight Simulator X Files\" 250 FS UNC path = "\\PILLY-PC\Microsoft Flight Simulator X\" 2044 LogOptions=00000001 2044 SimConnect_Open succeeded: waiting to check version okay 31824 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0) 31824 Initialising SimConnect data requests now 31824 FSUIPC Menu entry added 32058 C:\Users\PILLY\Desktop\Documents\Flight Simulator X Files\TKPK.FLT 32058 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\LVLD_B763\B767-300.AIR 687855 System time = 08:20:14, FSX time = 08:09:19 (12:09Z) 688261 Aircraft="Level D Simulations B767-300ER - American Airlines" 690305 Advanced Weather Interface Enabled 5928428 Sim stopped: average frame rate for last 5238 secs = 21.3 fps ********* WideClient Log [version 6.75] Class=FS98MAIN ********* Date (dmy): 03/10/08, Time 09:14:49.537: Client name is PILLY2-PC 172 Attempting to connect now 172 Trying TCP/IP addr 192.168.0.196, port 8002 ... 265 Connection made okay! 1556968 New Client Application: "FSC84" (Id=3844)

Still, if FSC complains it may not be getting the correct data. I still think it worth me looking at those logs for you. Not sure why admin rights has anything to do with it, unless this is preventing FSC accessing the folders it needs -- though you say they are shared okay. Certainly neither FSUIPC nor WideFs need any special rights except when registering. Regards Pete

Thanks for your contributions. Have you yet looked at the Lua program plug-in facilities in the latest interim updates for FSUIPC4 (see the FSX Downloads Announcement)? I know they are currently only for FSX, but I am really waiting for some feedback to see if it would be worth adding the same to FSUIPC3. So far it looks not, in fact. :-( Little apps like idenfifying the nearest or current airport by ICAO seem very suitable for a Lua implementation, and the language isn't hard I think. FSUIPC4 runs any such plug-ins multithreaded in FSX's own process, with virtually no measurable impact on a 2- or 4-core system. Best Regards Pete

Okay, good. Thanks. Actually, all of these SimConnect modes are documented as "gauge failures" so i assume all they do is stop the gauge updating, not the undelying function. I'll clarify that in my list. However, in this case the Vacuum one is definitely non-responsive (stays at 0), at least in the 738. Maybe it needs a panel with a vacuum gauge. I'll try that. Since they are gauge failures I would have expected them to simply make the knobs and display failed, with perhaps the radio still working on its unseen and unchangeable frequency. But no, both the NAV and COM failure flags seem to be non-responsive, like the vacuum. I'll update the list with this info. Thanks. On this: I don't get that happening here, at least not in the 737-800. The mag compass above the window is still operating even with the DI on the PFD failed. Possibly, these things being gauge failures, it depends on gauge implementation. If it does it is a worry that add-on panels may not obey them. I would have thought the FS core would stop sending the updates, but I really don't know. Maybe, if any panel-beaters are reading this they might comment. Anyway, on the hydraulics, FSUIPC version 4.318 is now available above, fixing 32F8 bits 0-2. Thanks & Regards Pete

I'm not sure how you are getting these values. I've just checked with FS9.1 and FSUIPC 3.829, and I get Byte 3364 = 255 in initial menu and whilst FS is initially loading Byte 3365 = 2 in initial menu but then 0 when FS starts loading textures etc etc Then, when truly ready to Fly, both bytes change to 0. I think you must have an error somewhere. The Byte at 3364 stays 0 when in Menus. But 3365 changes to 3 as soon as you press ALT and FS pauses ready to go into the Menus. The bytes 3364 and 3365 remain 0 and 3 respectively no matter what you do, until you exit the menu and FS is again ready to fly. I've been checking this with FSInterrogate. As I mentioned, a lot of things could go wrong if this wasn't working. I suggest you use FSUIPC's IPC read logging to see what it is you may be doing incorrectly. If you don't understand the logging, just show me and I'll help. Regards Pete

Castigating? Hmmm. I tried to emphatically point you to the right places. Didn't it work? Pete

Actually, please let me know about the ones which are okay too -- I'll revise the list accordingly. On this: I've found the reason the first 3 bits don't work at present (the others should be okay). I made the axis operations more efficient (responsive) by using direct access to FS, bypassing SimConnect. These failure bits operated using that mechanism to send axis values to keep the control where it was. That worked okay via SimConnect as it arrived in FS just after the intercepted control did. Now, with the higher efficiency / less latency, it gets there first!Duh! I've fixed it by Posting those particular controls via the normal Windows Messaging system. That seems to deal with it okay. This fix will be in the next increment (4.318), but I won't upload it till I've got the rest of your feedback, just in case. Regards Pete

I just checked the most recent SimConnect documentation on these -- documentation which appeared long after I'd written that part of FSUIPC. It seems that there are three failure modes which are read-only: 3BDB Avionics 0B6C and 3BDF Fuel indicators 0B72 and 3BE5 Turn coordinator although, actually, I see i hasve marked the latter two higher offsets as not writeable already. I shall revise the offsets status on the others. The others should work. Have you tried them? Regards Pete

Probably not missing anything -- the failure mode bytes are all marked in the current FSUIPC4 Offsets Status document, both reading and writing, as "validity unknown. Needs checking and feedback please". Yours is the first such check and feedback. Thanks, I'll look at them to see if it is a lack of advertised SimConnect support or something in my code. On this, however: That certainly worked once, but I see it doesn't now. I'll find out why. Thanks, Pete

That is really very very strange. I've not heard of that before. Could you possibly be having some result of power management on the USB ports? make sure all power management options for USB are turned off. Are, perhaps, your devices connected to an external powered hub instead of direct to the motherboard facilities? If so, could it be something in that? I really do think the device must look disconnected to Windows before it can change its ID. It just makes no sense whatsoever otherwise. If devices are "asleep" and get powered down, even if still connected, that might count as a fresh connection when re-awoken. But, as I've said, I've never known the IDs to change (at least with direct-connected USB sockets) except by changing the physical connections themselves. External hubs may be different. You can check IDs using the joyview program I attach now. It uses the same Windows interface as FSUIPC. Regards Pete joyview.zip

That would be normal, I think, at least if it moves more than a certain amount (allowing for some jitter and accidental small moves when pressing a yoke button). Regards Pete

Okay, I managed to reproduce the problem and fix it. There was also a related problem with Macro assignments -- these were being loaded incorrectly. Both errors arose when I inserted some new code to deal with the Lua programming plugin facilities. Thanks for your help in fixing this. Please download 4.317 now. Regards Pete

But merely switching views or running videos is not touching FSUIPC nor does it even know you are doing this. It isn't looking at INI files either until and unless you go into the Options menu. The ONLY time it reads the INI files is when it loads, when you change aircraft (whether directly or by loading a flight with a different aircraft), and when you explicitly ask it to via the Reload buttons in the Options. In order to do what you say, either the FSUIPC in-memory tables controlling the axis assignments must be getting corrupted -- but evidentally in a most peculiar way if this involves swapping -- or somehow Windows is rescanning all the hardware and re-assigning joysticks at random. I think Windows only assigns the joystick numbers on initial boot, or when you unplug and re-plug devices. Maybe that's it? Are you unplugging and re-plugging devices whilst FS is running? Even so, if you use the same USB or Game Port sockets each time, I'm pretty sure it allocates the same numbers, though maybe sometimes it doesn't. that's an area i know little about I'm afraid. Yes, as above. Not whilst they are connected and being used though. FS uses DirectInput and its assignments are based on joystick naming, manufacturer and so on, not the joystick ID which is needed in the simpler interface I use. Even then I believe FS does get mixed up if you have two or more generic unnamed joysticks, or identical ones but used for different purposes. What page? You mean here, in the Announcements? Or do you mean Enrico Schiratti's "Dowson" page? That has contained 3.82 now since mid-July. If you are getting an old version you need to refresh your IE cache. There are notes about this on that page. If that doesn't work, it's the cache on your ISP and you should complain. 3.817, the version you said you were using, would only have been available here. The current version now, here, is 3.829. Regards Pete

There is NO INSTALLATION from the wideFS ZIP file. For FSX the only things you want from the WideFS file are the documents and Wideclient.EXE, to put on your Client PC. For FSX, WideServer is built into FSUIPC4, as it clearly states in many many places. Please please read the FSUIPC User Guide, where you will find an INSTALLATION section. READ THAT. Then run the FSUIPC4 installer where, as I clearly told you, you will get registration, de-registration and checking options for both FSUIPC4 and WideFS7. You MUST have seen that before as you said you registered FSUIPC4!!! :-( There is a lot of help in the extensive documentation, which I am sure you could find if you looked! :-) Regards Pete

Unfortunately I don't think it makes any difference whether you are in-process or out, as SimConnect appears to continue to use the same asynchronous communication method. Thшы operates between SimСonnect.DLL and the main routines embedded in FSX's own modules. The only advantage of in-process operation (apart from the "hacking" opportunity it affords) is in reducing the cost of process switching. The only way to get zero latency would be to hack directly into SIM1.DLL, which is what FSUIPC3 did for FS9 and before. Even then it had to be arranged to only call certain FS routines based on FS's own timer and frame events to avoid recursive corruption in the many non-recursive routines, so it was never truly zero latency. FSUIPC3 did it as explained above. I was assured by Microsoft that SimConnect would provide everything we needed for FSX and beyond, so FSUIPC4 was written only as a compatibility layer, and uses SimConnect for 99% of its interfacing needs. Many of us were disappointed that SimConnect did not deliver exacting enough features for some types of application, such as the one you are attempting. There's quite a lot of pressure on Microsoft to do something about this in the future, if only for the commercial application via ESP. But for now I'm afraid your only recourse would be to hack into the FS code. SIM1.DLL is the main routine to attack, once you have the right IDs/hadles. It is really heavy going these days with everything now object-oriented C++ with classes within classes withinugh. Tracing pointers down through tables in the heap or only the stack is horrible. When I was younger I would take up the challenge, but no more. Sorry. Regards Pete

These facilities are not provided in FSUIPC. I did manage to hack into parts of FS9 to implement the facilities to send Controls (key events) to AI aircraft, and to delete them. These facilities are available through offsets both in FSUIPC3 and FSUIPC4. I do not know how to create AI aircraft in FS9 nor provide them with flight plans. maybe someone has hacked into it all that far, I don't know. Regards Pete

FSUIPC4 can only eliminate messages sent through FSUIPC4. It has no control over FSX's own messages, nor over other programs using SimConnect directly. Are these messages you are trying to eliminate emanating from FSUIPC applications? Regards Pete

Okay, but I needed to know thattrying to reproduce something which so far hasn't happened here, I need every clue. I'll see if I can repro it with all the information you've now given me. Thanks. Pete

Ah! The reason is staring you in the face! Even doing the Reset as you are isn't really fixing anything, but temporarily masking it. See the word "direct" against each brake? That means you have assigned the brakes so some axis or other in FSUIPC's Axis Assignments -- and not only that, but you assigned them to go direct to FSUIPC calibration (not the default method at all)! No wonder FSUIPC re-enables the calibration -- you cannot have FSUIPC scanning an axis for you and sending it to the calibration routines with them doing nothing. Even with your temporarily cancelling the calibration, you are still making FSUIPC scan two axes 20 or more times per second for no reason at all other than tyo add to the load on your PC. Maybe the two axes you have directly assigned to the brakes are not the same ones you are trying to use through FS -- hence the "going wild". Two different axes trying to do the same things! If you don't understand anything in FSUIPC it is best not to use anything in FSUIPC. (Or at least read the manual! ;-) ) Since you apparently don't know what you've done, that would be my advice, yes. Then don't mess again unless you know what you want to do. ;-) Alternatively, if this reply does jog your memory into something you forgot you did, just go and undo it. Regards Pete

Well, they would, wouldn't they. I'm afraid I don't know FS commander, but I do know a lot of folks use it quite happily over a WideFS link. Are you sure it is FSUIPC it says it cannot connect to? I think it needs directory access to FS as well, and may be having the same problem if it is using the computer name not the IP address. Have you shared the folders it needs on the FS PC, and can you access those okay on the client PC using Windows Explorer? All I can do is look at your logs (FSUIPC4.LOG, WideServer.LOG and WideClient.LOG) and tell you whether FSUIPC and WideFS are working okay. If they are, he problem is either with FSC or your network, still. I suspect the latter, because all you've done so far is worked around a problem you should never have had in the first place if the network was okay. Regards Pete

The values are totally irrelevant if the top left button in the relevant calibration section reads "Set", as that means that no calibration is being performed. Full Stop. If the section were active it would read "Reset". Values should always be present in the boxes as the defaults would be there until you calibrate. If you have a problem I think you must be seriously misinterpreting something and this is confusing you more. In the same folder as FSUIPC, the FS Modules folder. Everything to do with FSUIPC is always in the FS Modules folder. Regards Pete

Maybe a bad joystick driver -- dinput is short for "Direct Input", and is part of Windows. You could try reinstalling DirectX (update to the latest DX9 (or DX10 for Vista) release maybe? Or try uninstalling and reinstalling joysticks. Dinput can also be used for keyboard and mouse input, but i don't think FS uses it for those. Regards Pete

Having only a min and max is no good. You need a centre zone as well -- that's why there are 4 values being set, min, low centre, high centre and max. you need to follow ALL the calibration steps, not just pick out one or two. That's the whole point. Defining the centre as a zone ensures you can ALWAYS centre controls no matter how variable of "off-centre" they may be. If you don't use that feature then it's a complete waste of time using FSUIPC for calibration. Oh, you mean pages? The rudder and all the main controls are on page 1. Regards Pete