Pete Dowson

FSUIPC doesn't do anything by itself. It is a tool, used by other programs and add-ons to access FS innards, and by users (if registered) for assigning, programming and calibrating assorted accessory devices. You might know it doesn't happen without FSUIPC, but that must be because then something using FSUIPC isn't able to do whatever it does which you don't like. If you registered FSUIPC then possibly you've set something wrongly for one of your control devices. Try deleting the FSUIPC4.INI file to remove everything you've assigned or changed. If you haven't registered FSUIPC then it does absolutely nothing not actively requested by add-ons using it. Regards Pete

There's no website related to FSUIPC which will say that FSUIPC4 will detect or install in FS2004, as it is for FSX and ESP only. The sales page on SimMarket is also very clear on that. This is really a matter for Majestic Dash 8 support. You are in the wrong place. This Forum is for support of my (Pete Dowson's) modules. FSUIPC has nothing whatsoever to do with any visual models. I'm sorry, but I cannot help you with instructions for an add-on aircraft. I don't even have the Dash 8. Regards Pete

Almost: FSUIPC4 is for FSX and ESP. FSUIPC3 is for FS2000, FS2002, FS2004, CFS1 and CFS2. Also FS98 at a pinch, but not FS95 or before! ;-) Pete

I've eliminated TrackIR5 and assorted unnecessary services running in the background. I'm downloading the latest nVidia drivers now to try -- 195.81 from guru3d.com. I think they are pretty much the same as the official 195.62. There are certainly good and bad drivers. I found lots of bad ones before I took notice of the general consensus that 182.50 were about the best for FSX. That did indeed seem to be the case for me -- until updating from the RC release of Win7 to the full user release. Strange. My guess is only that there are critical timing differences in drivers which just hit some beat frequency in other activities in FSX -- FSUIPC sometimes, other things like FS's own flight computations another. These stutters and jerks are a frequent problem with or without FSUIPC, and certainly driver changes do seem to always affect them. Without looking at my code I can't say exactly what those data blocks are for, but they are related to changes in the simulator situation -- engine, position, whatever. They aren't AI Traffic ones, nor weather, that's all I can say without checking. They are sent to FSUIPC asynchronously, just when the values change, being only requested once at FSX/FSUIPC4 initialisation. Anyway, glad you are sorted. I'm off to try the newer video drivers now ... [LATER] Well, the later drivers fixed the TrackIR problems. I was a bit concerned, though, when FSX, TrackIR and the whole PC locked up solid after only about 30 seconds of FSX flying. I powered off and on and tried again, and it didn't hang again, so I'm keeping my fingers crossed! The pauses/freezes are gone, but I still have "microstutters". Time to play with some of the settings again I thinkI don't know. Seems that FS is all about pottering about doing this, that and the other with a tiny bit of flying in between, if you're lucky! Happy Christmas, Pete Regards Pete

There's nothing in FSUIPC with any sort of time interval like that. The only regular actions carried out by FSUIPC are reading the weather data from SimConnect -- but that is much more frequent, and updating the AI traffic information, which is continuous but dependent on SimConnect's notifications. Everything else, all of the offset data obtained for other programs, is all simConnect data notification, which is completely asynchronous. I suppose it is possible for a corrupted SimConnect setup to cause it to get such things bunched up, but it seems very unlikely to me. I have a similar problem going on on one of my systems, one which was working perfectly on the Windows 7 Ultimate 64 RC release, but not now since updating to the full RTM release. I am suspecting video drivers, as the only time I've had this before was definitely down to the drivers, and was fixed by retreating to an older version. However, I'm also running TrackIR5 on that PC, and its drivers seem to have some problems now too. On my main FSX setup I'm running the same video driver, the same Win7, the same FSUIPC, and it's perfectly smooth. So hardware differences, probably some IRQ or timing differences, probably also come into it. If you really think it is 4.558, try reinstalling 4.53 to compare -- you'd need to manually delete the 4.558 version from the FSX Modules folder first, because the Installer won't replace a later version. Let me know please. Okay. Let me know about that, too, please. That can mean it is a SimConnect problem, but it is more likely just happening like that because of small timing differences having FSUIPC included causes. If I find out what is causing it on the one system it is happening on here, I'll get back to you. [LATER] I've re-checked the problem on my PC and it isn't a regular 10 secs. It varies a lot from several long jerks over a few seconds to hardly any for maybe up to 20 or 30. And it's the same with 4.53 or 4.558. I really don't think FSUIPC is the primary cause. I'm going to re-test without TrackIR5 running first, then look for a later driver (I've been using 182.50 for a long time without problems). Regards Pete

I'd need to see the FSUIPC log for that (after FS is closed), because the one you posted definitely showed that the KEY file was the problem. There aren't any, only an illegal key generator floating around. Ah, FSNavigator doesn't use FSUIPC at all in any case. Okay. Good luck, then! Regards Pete

Your registration is invalid. One of the following two circumstances apply: 1. Either or both of FSUIPC and WideFS registration keys are generated by an illegal pirate key generator, or 2. Your PC's system date is incorrect and makes the keys look invalid. Just remove the bad FSUIPC.KEY file from the FS Modules folder and you will find the programs connect without any problems. If you believe that neither of these applies (and as far as I can see there's absolutely no other explanation), please ZIP up your FSUIPC.KEY file, from the FS modules folder, and send it to me at petedowson@btconnect.com. If you had not used a false name and also erased your registered name and email in the Log you posted I could have checked for you. Pete

A separate reverser lever would be better, if you have a spare lever. It would feel rather odd, wouldn't it, pushing the throttles forward to get increasing reverse thrust? Anyway, it is no doubt possible, but you could only do that by program, or Lua plug-in, using the same technique as used for Fly-by-wire. One way is this: 1. Whilst the button is pressed, disconnect the throttle(s) altogether via offset 310A. You need to write to that offset regularly or it resets in about 10 seconds. 2. Read the throttle values from the offsets provided (332E and following) 3. Negate the values (but limit to -4096 (25% thrust) or whatever the reverse % thrust limit is for your aircraft) and write them to the throttle offsets (088C etc). You should of course take precautions, like only take note of the button (whether pressed or released) when the throttle is idle (value 0). In the Lua plug-in you could be in a continuous loop with a sleep of, say, 50 or 100 mSecs for a reasonably response. Don't forget to reconnect the throttles, via 310A, when the button is released (and the throttle is at idle again). Regards Pete

If that aircraft uses FSUIPC then it might store the values in FSUIPC private offsets. But even if they do, unless they openly publish them, there's no way to know where they are without hacking into their code. The same applies to PMDG aircraft. Level D, however, do provide an SDK for theirs. You might find folks who know more about that particular aircraft over in their support forum. [LATER] It occurred to me that the PSS757 might, just possibly, be using Local named gauge variables ("L:vars"). If so, then you might be able to read the values from them in a little Lua plug-in -- L:var access facilities are available in both FSUIPC3 and FSUIPC4 now (get the latest updates from the Updates announcement in this Forum). You can find out initially in one of two ways: 1. Assign a button or keypress to the "List local panel vars" control which you will find in the assignments drop-down now, or 2. Install the Log Lvars Lua plug-in into the FS Modules folder, and run that by assigning a button or keypress to the resulting Lua Log Lvars control. The latter has the advantage of providing an on-screen listing. If you can read the values you need this way, then the Lua plug-in can copy them to the free user Offsets (66C0-66FF) for your program to access. Regards Pete

If your code works okay with the default aircraft, then it means the add-on aircraft implements its own autopilot and therefore handles its own heading bug. Many sophisticated add-on aircraft do such things, including LevelD and PMDG aircraft. Regards Pete

Well possibly, as I see you are not the thread's originator. But if you've added to this thread you've presumably read it, else why add to it rather than start another? Whist it was originally about the 64-bit Latitude and Longitude values, Paul made the suggestion to use a 64-bit variable instead, and that applies equally to the altitude, another 64-bit fixed point number. Why wouldn't it? Pete

Obviously, all 64 bits make the one number, so no matter how many parts you divide it into, the conversion is the same! Both are therefore naturally subject to the same factor, except the fraction is divided by a further 2 to the power 32, as it is really the 32 bits to the right of the "binary point" (i.e. the division between integer and fraction). Please please do read the notes on these offsets in the documentation. It is all explained there! Or just make things much easier on yourself and use a 64-bit recipient variable in the first place, as you've already been advised! Pete

I've looked into it, and it looked easy enough. Download FSUIPC version 3.954 via the link in the Updates announcement, and see if the LVar access facilities can help. Regards Pete

Where are you assigning the quadrant levers? If you assign therm in FS or FSUIPC, you can use FSUIPC calibration. If they use some driver from Elite to inject values directly into FS, then this bypasses all the FSUIPC user facilities -- it is the same mechanism used by add-on autopilots to control FS and obviously would not be subject to FSUIPC calibrations. Regards Pete

Thanks. Actually the name is "Dowson", but just use "Pete" please. It's a unit devised by Bruce Artwick long long ago in the early days of FS, designed to represent a latitude or longitude (different units) as accurately as possible within a 32 or 64 bit fixed point number. At that time fixed point arithmetic was much much faster than floating point -- today, with the emphasis on floating point in modern processors, the reverse is probably true. Nevertheless, the units became established in all the file formats and so difficult to get out of without a clean break from the past, which never happened (well, not until now, with the closing of the MS FS team altogether). As described in the documentation, and demonstrated in the FSInterrogate utility. Did you not refer to the Programmer's guide, the one which defines all of the FSUIPC offsets, in the FSUIPC SDK? Well, I don't know C# at all I'm afraid, but it looks suspiciously like that "token" value you are reading 8 bytes (64 bits) into is only 32 bits long, unless you are using a 64-bit compiler? The large number you quote can never fit into a 32 bit value, don't you see that? I think the largest 32 bit value is around the 10 digit mark, which is what you are getting. The other 32 bits, the top end, are probably overwriting something else in your program you aren't aware of. Doesn't C# have any debugging aids? I'm sure you'd be able to see what is going on if you used them. You could also even try the tools provided for you in FSUIPC, namely the IPC read logging, to see what you are reading. Once you have the correct 64-bit fixed point number, use floating point arithmetic, as shown in the documentation, to get your degrees. Regards Pete

The question as to whether the latest version of this that or the other is being used standard. I do the same. There's no way to support folks with the extra unknowns from different versions. We have to know you are on the same version as the one being used "in house". It is also interesting, is it not, that in the main after receiving JD's response that in most if not all cases the user has not returned with either confirmatory or other reports. I suspect this indicates, maybe incorrectly to him, that the problem has been resolved. I forgive you, but that doesn't mean it is true. Because FSUIPC is at the centre of so many applications it is the target for all kinds of abuse and accusations, but that doesn't make it any more true. In this case I know what is happening and I know it is recoverable and shouldn't need a stop with an error message. I have no idea why JD hasn't done anything about it, but I cannot do anything in FSUIPC. There is no way I can solve it. If it still occurs in the current RCV4 release it remains a bug in RC. I thought JD had fixed it, but perhaps all he did was tighten up his timings a bit and managed to make it less likely, that's all. Unfortunately as far as I know he hasn't done anything with RC4 for some time as RC5 has been in the pipeline now for a couple of years. Maybe he'll let you into the Beta group and you can use that, if you have constructive things to offer and not merely criticism. Is that meant to be a cheap and nasty sarcastic snipe? It might be "only" FS to you, but it is my life and has been now for many years. I don't get around much any more. If you expect me to be able to fix other people's code you are sadly deluded. there is nothing i can do about bugs in other folks' code. I have managed to make workarounds in the past for some of FS's own deficiencies, but i'm not about to try to hack into JDs code to "patch" his. [LATER] I've asked JD, author of RC about all this, and he wants you to contact him. I've PM'd his email address. Pete

No, you don't really want to interface to WideServer -- the protocol is undocumented and very specifically aimed at the way wideClient works. I recommend you use the Lua plug-ins facility -- the Luasockets package is fully supported in the recent updates to FSUIPC (see the Updates and Other Goodies Announcement above). There is an example pair of Lua plug-ins which link two copies of FS together. I'm sure you'll find it easier to link your interface that way. Regards Pete

Same as on the keyboard in FS -- just assign a button to PROP PITCH DECR (or, for separate engines, PROP PITCH1 DECR through PROP PITCH4 DECR. You can do this in FSUIPC's assignments or FS's (The generic PROP PITCH DECR control is is normally assigned to keypress Ctrl+F2 in FS -- listed as something like "Propeller RPM decrease quickly" in FS's assignments). Actually there's no "designated keystroke" for reverse thrust either, yet everyone seems to know it is F2 ("THROTTLE DECR"). With all the three controls -- throttle, pitch, and mixture, the INCR and DECR controls simple do exactly that. So if you have forward pitch/throttle or mixture and you hit the appropriate Decrement control (F2, possibly with Ctrl and Shift as needed), it will decrease it a little. If it is already at idle/feather/cut, then reducing it further takes it into its "negative" or "reverse" zone. You can always determine the internal FS name for controls -- the ones FSUIPC uses for assignment -- by enabling Event logging in FSUIPC and pressing the appropriate button. details are logged and you can look in the FSUIPC Log file (in the Modules folder) to see what control was used. Regards Pete

Well, a bit of research beforehand would have shown you that. And you are the first person to report back that FSUIPC was a waste of money. Most users say the opposite. :-( Pete

There's no equivalent built into FS, that's why. what is the "EPR button" supposed to do? Is that the equivalent of setting "N1" on the 737 MCP? The Lvar access facilities only work with FSX and FSUIPC4. They aren't included in the FSUIPC3 version, though I'll be looking into it to see if I can implement them there too. Have you tried the mouse macro facility to see if it is amenable to that? If the relevant gauge was written using the C/C++ gauge SDK it might be. Pete

Thanks Jim! Pete

Worth trying. I've just uploaded FSUIPC 3.953 (see the Updates announcement at the top of this Forum). I've simply made the clock sync option more responsive -- i.e. it checks the seconds drift much more often. I doubt that will help if what you are getting is a sudden minutes jump, but if it really is a faster rush of seconds then it might catch it ... Regards Pete

Yes, it is, and I'm out of ideas. You might want to post that point on the FSX forum, here and in AVSIM, to see if anyone else has any ideas. Regards Pete

Because your problem is that the minutes are jumping -- FSUIPC doesn't synchronise the minutes directly. Doing so tends to cause texture reloads, as I said, and that simply is not acceptable when flying. FSUIPC does keep the time synchronised against FS's tendency to run slightly slow, and it does this, as documented, by keeping the seconds correct. That normally allows the minutes to stay correct on their own. It cannot deal with the odd 2 minute jump you are seeing, and, as I said, I don't know why you are seeing that nor how it happens. It doesn't happen here and I've not heard any one else report it. Assuming it isn't some sort of FS9 corruption, or some other Add-On you've forgotten about, then it must surely be some background process or service running in you system -- maybe something to do with virus checkers or firewalls? My FS9 test is still running and it's now lost 2 minutes (with the FSUIPC sync option off, that is). That's pretty much what I expected. Regards Pete

Not "turn FSUIPC on or off", but the option, the clock sync option, which is OFF by default! It is on the Miscellaneous tab. I thought that was what you posted here about in the first place! Pete