Pete Dowson

And this has changed recently, or has it not been tested before? FSUIPC merely calls the routine inside FS which is the same one used by Ctrl+; and the menu facilities. Are you leaving enough time between the calls? i.e. is the flight fully loaded before you try again? No idea. FSUIPC can't do anything differently. You need to always tell me the Version number of FSUIPC -- if not the latest, try that, just in case (the latest is 3.829, available in the Announcements above). Also, it would be useful to see the IPC write logging -- I take it you have used the Logging to check what you are doing? [LATER] I have just tested it using FSInterrogate, with three FLT+WX combinations renamed x y and z (to make it quicker to edit the pathname in FSInterrogate). All three were loaded correctly. I continued and did the same three again, with no problems. So, it sounds like you have some problem in your program (which you should be able to diagnose with the help of Logging), or possibly some problem with FS or your Flights. But try the very latest FSUIPC first -- I was using 3.829. Regards Pete

Sorry, I do really know nothing at all about Elite. All my PFC support has been for their equipment operating with PFC's proprietary protocol, not the Elite protocol, which I've never seen. Only Elite support can help you I'm afraid. Regards Pete

No, you'd decrease the range to give a wider angle. The reason for the normally narrow angle is because during testing (and Beta testing) it was far too easy to zap the wrong aircraft, especially when trying to clear a space on the tarmac to park your vehicle. The wider angle with less range makes sense when you look at it like that. Well, 2 to 3 miles is a heck of a long way for this facility when you consider you don't even get AI aircraft drawn over 10 miles away. Surely you can leave it a lot lot later than that? at 2 to 3 miles without having a very narrow beam the ambiguity about what you may zap would be huge. Sorry, I obviously misunderstand. If there's no angles involved and the nose is irrelevant, how is this "cylinder" computed? Are you talking about using aircraft track not heading? And are you saying everything in that cylinder? Or just the nearest, like the aircraft to your left innocently on approach to a parallel runway? The geometry / trigonometry of what you ask would need figuring out. What I implemented already was straight-forward range and bearing computation. I'd have to go revise trig from my old school books to work out range from an extended centreline. I suspect I'd still want to use heading not track, though, as the former is visually discernible more readily, so the nose is still important. And is this cylinder horizontal, or tipped for a climbing or descending aircraft? The trig for anything but horizontal would be even more horrendous, but if it isn't tilted, the diameter would need to be that much greater for your approach situation. Do you have any formulae? don't forget, all I have it Lat/Lon/Alt/Heading for your aircraft and Lat/Lon/Alt for the potential targets. Consider these as X Y Z coordinates in 3D space. Now I need a formula. BTW surely only in front, though, not behind? You wouldn't know what you were zapping if you aren't looking. If it starts to look feasible I'll put it on my list, though it actually sounds more like a good application for a little add-on utility rather than something built into FSUIPC. In the current FSX version there's a facility for Lua plug-ins to FSUIPC, and this facility could most probably be programmed that way. But I've not yet considered porting it to FSUIPC3, though, because so far no one has expressed interest in the FSX version. :-( Regards Pete

It's really meant for zapping during taxiing. The zapping on final approach was a bit of an after-thought, though it works well if you leave it till the last moments. There might be a problem in a crosswind landing, with you crabbing, till you kick rudder to straighten up of course. Aren't the user-adjustable parameters already provided sufficient? Have you tried changing them? You can only alter the range, the angle alters in inverse proportion. Regards Pete

I don't know Delphi, but this looks wrong: Considering the value you are reading is a 32-bit integer (occupying 4 bytes), don't you think one byte (8 bits) is a bit small? You do seem to know it's 4 bytes long because you have that in the Read: Regards Pete

Disabling only UNC doesn't really leave it at risk provided you think twice before executing or opening any files you don't know. I think all UAC really does is ask you to confirm that you really want to do what you say you want to do -- those annoying messages asking for confirmation. It may also stop some things being done without elevated administration rights. I'm sure that if you still have Windows firewall and defender running, and a good anti-virus (like AVG free) then you'll be just as well protected against everything, except of course yourself. ;-) Regards Pete

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