Pete Dowson

WideFS6 is for FS9 and before. You purchased the wrong product! Pete

Aren't both of your messages asking the same question? FSUIPC doesn't care or know about the make of a joystick type device. If it is recognised by Windows as a joystick, you can assign in FSUIPC or FS. If not, you need its driver. Pete

1. What's "all sorted"? There are no previous messages in this thread!! 2. That link doesn't seem to work in any case! Pete

There's absolutely no difference. You are therefore making a mistake. All three parts of the Registration must be exactly correct. If you still have your FSX installation you can use the FSUIPC4.KEY file from its Modules folder. Pete

I never understood why this might be the case, because FSUIPC reads the joystick devices in exactly the same way as FS. Hmm. Sounds like the sorts of problem many folks complain about with Windows 8. Maybe Win10 will fix it. I'm sticking with Win 7 for sure! Sorry, I can't help really. As I said, I don't even understand how using FSUIPC can help with such problems in the first place. Pete

Sorry, there's really no way that is possible. Please read up about the FSX-SE Terrain crash problem which is by now pretty well known, and by all reports may well actually be partially solved by the latest FSUIPC's "G3D crash" fix. Pete

DO NOT mix range options with axis assignments! You'll just get a mess! FSUIPC's calibration will handle the OFF/ARM settings if you assign to spoilers. If you really do want to use the ranges instead then do NOT assign to the axis on the left as well. But it's a complicated way of doing something made easy by calibration. Pete

No idea at all, I'm afraid. But all the answers will be in the FSUIPC4 Install log, which is why it is produced. You'll find it is the P3D Modules folder. Please paste it complete into a message here. You can use the <> button above the edit area to enclose it neatly. Pete

This information is already exported in the Runways.XML file. Please use that. Pete

Something very fishy there: FSUIPC4 version 0.0.0.0, and "unloaded"? And the offset 5a0ca070 is impossible too -- that says the error occurred at byte 1,510,776,944 from the start of the FSUIPC module! Is there an FSUIPC4.LOG file at all? Maybe that will help. And when you say "started getting ..." do you mean it's been okay then something changed? Pete

I didn't know PMDG had implemented a similar data export facility for the 777. I don't have the aircraft and therefore not the SDK either, so at present I am unable to implement anything similar I'm afraid. No one has mentioned this before either. Pete

Well, it might be possible with a lot more hacking into FS code (which I did try in the past, but gave up), but in my opinion it is simply not worth it because the default ATC is so dreadful, especially for us non-North American fliers. Pete

Yes. You can assign both axes to Rudder, but manipulate the values being received to get 0 to -16383 on one an 0 to +16383 on the other. You do that by first assigning as usual in FSUIPC, but then edit the entries for the assignment, in the FSUIPC4.INI file, as described in the section "Additional parameters to scale input axis values", on page 44 of the FSUIPC4 Advanced User's guide. Pete

Version 3.999z8 dates back to September 2013, over 16 months ago! Aren't you updating a bit late? Updating versions by simply running the installer never changes any of your settings, which are all retained in the FSUIPC.INI file in the FS Modules folder. There's a limit of 127 macros which can be listed in the dropdown. You cannot assign to any beyond that. Check the list in the INI file. That sounds like a matter for iFly support. Pete

The changes seen from the rotary cannot be made faster other than by turning the rotary faster. Increasing the poll rate will merely make the program look for changes more often. If your rotary can provide more than 50 changes every second I would be very surprised indeed -- 50 is your current poll rate. But by all means experiment. Whether the turn rate is regarded as "fast" or "slow" depends only on the "FastTimeLimit". If you set that to 10 as you suggest then you would have to turn it fast enough to get 100 pulses every second to get the fast indication, otherwise it would only be slow (> 10 miliseconds). If you want a slower speed (a possible speed!) you need to increase the time not decrease it! I think maybe you are thinking this program is for something completely different from what it is intended to do? Pete

I can't tell from such a partial log! Please always paste in the oomplete log! Pete

Sorry, I don't understand "reading to DEL", and there's no INN file associated with FSUIPC. The configuration settings file is an INI file. Please post new questions to the main support forum, to add to a different thread in a subforum. Thanks. Pete

Oh, right. I would never have thought of that! I shall try to remember it! Pete

No. I don't know anything thast can read and interpret the default ATC. I don't think anyone would want to go to the trouble in any case as it is very unrealistic. There are better options. Check out Radar Contact, Proflight Emulator (PFE), VoxATC, and ProATC-X. Pete

Last reply till 28th -- just on my way to Sri Lanka. How are you starting that DynamicFriction? If you start it with "LuaDebug ..." then it does the same as using the Debug/Trace Lua option. "STOP" on the Logging tab only affects the main internal logging options. Pete

What subforum? Who says that? There are several subforums in most forums -- see the list at the top of this one. They include Announcements FAQ - answers to Frequently Asked questions Download Links - latest versions of all my programs and other goodies here User Contributions - lots of useful stuff there But if you have a problem with FSUIPC or WideFS then you are in the right place here. But you need to give more information. "Waiting for clients" is normal for the Server when it is waiting for connections, and "Waiting for connection" is normal for the client when it is waiting for FS. Have you referred to the WideFS user guide? Try looking at the section about configuring your network. There are logs produced both by the server ("WideServer.log" in the FS Modules folder) and client ("WideClient.log" in the WideClient folder on the client PC). Those will help reveal any problems in connecting. I'm afraid this is my last posting here until I return on February 28th. Off on holiday in the morning. It might be a good idea to post details of your problems, with the contents of the log files pasted in, in a new thread with an appropriate title, because no one else is going to look at one called "lost key". If you make the title explicit then maybe someone else will be able to help you whilst I'm away. Pete

FSUIPC always makes a log! If any Lua contains bad lines the Lua will terminate and FSUIPC log will show the Error! Have you never looked in the FS Modules folder. Look now. See the FSUIPC4.LOG file? For line-by-line logging of the Lua plug in you just set the option for this in FSUIPC's logging tab. This must be done BEFORE starting the Lua, so either restart it afterwards with an assignment to a key or button, or restart FS after setting the option. The Lua program cannot control how fast you turn the rotary!!! I don't understand "making the encoder turns very slow in the same speed". By all means experiment. Are you saying you get results, but just not differnt ones for fast and slow? I thought you said itjust didn't work at all? Pete

Sorry, I've no idea. Have you tried logging? Did you look at the FSUIPC log to see if there were any errors? Does it actually get the device? What did you edit apart from the Vendor and Product names? Is that Lua otherwise the very latest one, installed by a current version of FSUIPC4? Pete

Right. The load problem is definitely not FSUIPC4, it is the SimConnect bug, which Microsoft knew about but couldn't find a full fix. It was much much worse in the original FSX RTM version. They applied a fix in SP1 which helped in 99% of cases but didn't clear it up completely. It is a timing problem between different threads and they never found a way to isolate it. I can say this for sure because that offset, 0x0001DBB5, is the entry point to FSUIPC4 from SimConnect, a function called "DLLStart". It is the call from SimConnect to that entry point which is causing the crash, probably because the DLL has been loaded once, checked by the Windows "Trust" system (which SimConnect always uses even though the prompts which occur in FSX were removed in P3D), and probably then unloaded and is being reloaded as the time another thread in SimConnect tries to call it. So, I can't actually do anything about it in my code as it doesn't get that far. Pete

The FSUIPC error log actually shows a successful load, starting at 235 System time = 11/02/2015 20:03:51 and being normally terminated, with P3D closure (not crash) a couple of minutes later! 92719 System time = 11/02/2015 20:05:24, Simulator time = 15:56:57 (19:56Z) 92719 *** FSUIPC log file being closed Minimum frame rate was 41.3 fps, Maximum was 46.8 fps Minimum available memory recorded was 2147Mb Average frame rate for running time of 12 secs = 44.7 fps Memory managed: 9 Allocs, 9 Freed ********* FSUIPC Log file closed *********** The crash data from Windows doesn't relate to that successful load and is later: Date: 11/02/2015 20:38:54 But since no log is produced it suggests FSUIPC was either not loaded, or barely so (the Log is started pretty much iimmediately FSUIPC receives the startup call).. )However, at least this time you provided the main information needed, the offset: Faulting module name: FSUIPC4.dll, version: 4.9.3.9, time stamp: 0x54d9e947 Exception code: 0xc0000005 Fault offset: 0x0001dbb5 I'll have a quick look to see if that tells me anything, but meanwhile you need to determine what the difference is between the successful load and the subsequent unsuccessful one. Maybe something is left set strangely? Maybe it only works correctly on a clean PC boot? Unfortunately I'm away from this evening for over two weeks, so it is doubtful I can solve it beforehand. There are (so far) no other similar reports and judging by the AVSIM P3D forum there are quite a few folks using it. I have it installed and working fine on two different systems, but I don't have Windows 8 or Windows 10 so I'm a bit concerned that maybe your Pre-Release operating system is involved.(as I see mgh suggests). BTW I see that FSUIPC regards Windows 10 as just another version of Windows 8. not that it will make any difference -- FSUIPC assumes Microsoft keep Windows backward compatible. However, I'd like it to be logged correctly, so can you tell me what the full version number is of that Windows build? Is it another 6.n increment or have they moved on to 7 or more? Pete