Pete Dowson

It will say that if any part of your entry is wrong. You are making a mistake! Maybe you are trying to use an FSUIPC3 key in FSUIPC4, or vice versa? Or you are spelling your name differently? Or your email? If all of that is 100% correct then it is certainly an invalid key. I'm afraid I cannot check for you because you are using a fake name here, and I cannot use it to look you up in SimMarket. But you can open your account in SimMarket yourself, and check the details you should be entering. Pete

I already replied to your original post, in the wrong thread, but thank you for doing it propery this time. However, I don't want to repeat my existing reply here, so please cross-refer for now. Pete

It changed MANY years ago. There has been no way to register from within FS itself for years. The version you installed last year must already have been several years old. Correct. Why? There are even pictures showing you what to do! Just run the Installer (again). When it asks you to register, enter the details. That part is IDENTICAL to the way it would have happened in the very old versions inside FS!!! And why is being 74 a problem? I am 69 and I hope to still be doing this stuff when I am 5 years older! Pete

Because mouse macros only work on gauges which have been written in C/C++ to the rules of the Microsoft Gauge SDK. Pretty much nothing Microsoft provided followed these rules. Why are you trying to use mouse macros for things for which standard FS controls are available? The three switches are operated by the "Hydraulic Switch Toggle" control with a parameter of 1 (ENG1), 2 (ENG2) and 3 (ELEC). Just assign to those controls with those parameters. To find out what controls (if any) are associated with each switch and dial in an aircraft, enable FSUIPC's event logging. It you run FSX in Windowed mode (temporarily) and enable FSUIPC's console log, you can see the results in real time. BTW, when posting a new question it would be best to do so in a thread with an appropriate title. Adding it to an existing thread simply entitled "FSUIPC" will be unlikely to get any other folks who might have a better answer rading your question. Regards Pete

Are you setting the standby then transferring it to the "use" setting, or trying to set directly? It sounds like some of the radio controls you are using are being trapped and discarded. I can't imagine why. Try enabling the Event logging in FSUIPC's logging and comparing the controls sent when you operate the radios with the mouse with those the hardware controls are sending. I've no idea yet because I still have no information on what is going on. Try the logging. If you switch FSX to Windowed mode (ALT +ENTER) you can select the console window logging in FSUIPC so you can see immediately what controls are being sent in a window to the side of FSX. Pete

If you want your program to run as a plug-in, running in-process with FSX, Lua is okay, and you can write other language DLLs whch can be called from Lua if you wish. You have to be careful though. It is very easy to crash FSX this way. No, I certainly meant the FSUIPC SDK -- why would you doubt this? It is the FSUIPC SDK which provides all the information and tools for interfacing into FSUIPC as well as the complete documentation of the offsets and so on. It is what has been used for the last 14 years by all those applications which use FSUIPC and WideFS. The Lua plug-in facilities are just a recent addition to FSUIPC's armoury of tools to allow rather more complex user configuring, or even programming, than can be achieved by editing the INI file assignments and using Macros, alone. It was never really intended for full blown applications, though a few interesting ones have grown around it, lke LINDA. Regards Pete

Sounds like it is the first time you've bothered to update your copy of FSUIPC for many years, as for years all registrations have been entered in the Installer. Please read the Installation and Registration guide included in the ZIP file. All parts - name, email and key -- must be EXACTLY correct and as originally confirmed, even if you've changed them since. If you have a valid registration and it isn't accepted you are making a mstake. Regards Pete

Sorry, no. I only support via this Forum, unless what you have is confidential for some reason. Regards Pete

As the documentation says, there are several Laries built into FSUIPC -- the default libraries are all there, plus the FS specific ones added by FSUIPC. Others you'd need to link to using the require command. No no. You are misunderstanding. Lua is a scripting language used, in this case, for plug-ins to FS. If you want to write free-standing programs using your own development environment, then you interface to FSUIPC via the methods detailed in the FSUIPC SDK. Regards Pete

Yes, certainly. As far as I know there's no specific limits for FSX. With FSUIPC assignments and button scanning only 16 joystick-type devices are handled (numbered 0 to 15), as its implementation is based on the original Windows joystick API (as used in earlier versions of FS, before DirectInput). This doesn't include Go-Flight modules which aren't part of those 16 as far as FSUIPC is concerned. Nor does it include devices connected to WideFS networked PCs, each of which can have a further 16 joystick type devices supplying button presses. There's also no imposed limit on HID devices which can be handled by Lua plug-ins using the COM library. Regards Pete

But if those radios are completely divorced from the NAV and ADF radio simulation inside FS, they won't be of any use at all. The regular FS controls will change the values FS is using to determine things like reception quality, direction, range, and radial, according to the type of transmitter. I really doubt that DA would have implemented the whole process of processing all the BGLs to locate the transmitters and their frequencies and gone on to compute all these things themselves. It would make no sense at all. Possibly you are saying that the gauges concerned, the ones with the frequencies displayed on screen, are not updated with the values currently in use by FS. If so that is a severe limitation of their implementation, because it would mean that their displays will be wrong on loading a saved Flight with different frequencies stored. However, this deficiency would not stop you using a hardware implementation of radio controls in order to change the frequencies really in use. Possibly I am minuderstanding your problem, but if so perhaps you could clarify it further? Regards Pete

Correct, as it does too in non-DWC mode. It only uses FSUIPC on FS9. Yes, when appropriate, of course. Okay. If you are happy with AS2012 smoothing, why enable FSUIPC's? This thread has been about FSUIPC's smoothing. The latter -- see below. No. With FSUIPC's smoothing disabled, it is FS which is simulating turbulence and gusts. AS2012 just provides the METARs. I thought this was clear enough from the way those options are presented in the Winds tab? Those are wind effects ADDED by FSUIPC if its Wind Smoothing is enabled. The options are part of the wind smoothing section on the tab. Without wind smoothing they are irrelevant as then FSUIPC is not providing those effects. The other facilities on the winds tab apply normally to weather set through FSUIPC-- unless the option for FSUIPC to change FS's own weather is selected (not recommended). Pete

Not very nice for cokpit builders if they don't provide some other way to control it. There are a couple of avenues to research (well three actually): 1. Enable event and axis logging in FSUIPC's logging tab, and see if sleecting the mixture positions actually sends controls to FS. If so you can assign to those. 2. Read up on the "mouse macro" facilities in FSUIPC and see if it responds to those. 3. It may be using "Local Gauge Variables" or "L:Vars". If so you can contruct macros to write to those, which may work. You can list the L:Vars using an FSUIPC-assignable control, or log them as they change by running a Lua plug-in provided in the examples Zip in your "FSUIPC Documents" folder. Well try unchecking the option in any case, to check. {LATER] I just checked on the User Contributions subforum, and I thionk you'll find a full solution for your Catalina questions there -- see the thread entitled Aerosoft Catalina commands (upd 19thDez09) Looks like guenseli solved the problem using my third suggestion above, i.e L:Vars. Regards Pete

SimCon.dll? There's no "SimCon.dll" normally. Do you mean "SimConnect.dll"? P3D by default doesn't use a SimConnect DLL but you may still have P3D 1.0-1.2 DLLs or FSX or ESP DLLs in your WinSxS folders. FSUIPC4 can use the FSX or ESP DLLs with P3D too, if you have them installed (eg from FSX's SDK) and remove the SimConnectP3D.DLL from the Modules folder.. I'm afraid I'm really at a loss as to how VoxATC can upset a standard SimConnect control like the throttles. As I said, it appears that SimConnect isn't recognbising "0" as the ID for the User Aircraft. I know VoxATC can inject its own aircraft. I wonder if it changes the User Aircraft in some way? I've a feeling you or Tegwyn will need to consult with Lockheed-Martin over this. The SimConnect log and your FSUIPC log shwing the Throttle control failures will be useful to their support. Did you use these throttles with VoxATC on FSX at all? Regards Pete

Sorry, but what do you mean by "1"? Pete

Of course, because the variable you named com1 is never assigned a value. It is, in Lua terms, 'nil' -- non-existent. Names of ports are strings, as in "com1". Evidently in looking at the documentation you did not actually refer to the com.open function itself, where the presence of the "" is clearly shown -- twice! The reason you get the error message is because you programmed it so, here: and the only possible reason I can see for FS crashing is that you are using an old and unsupported version of FSUIPC which had a bug in the ipc.exit function! That was fixed a few months ago! Please, before coming here for support, always check to see you are using the current version -- 3.999w and 4.853 are the main releases at present, with an update 4.856 also available. And please always state the actual version number in use. (See Download Links subforum for updates). Regards Pete

Yes, I think ActiveSky is able to provide more realistic weather in DWC mode. I suspect the combination of gusts and turbulence in the same wind layer isn't intentional in non-DWC modes -- it is more likely to be a result of the way FS dynamic weather interpolates and merges layers from different stations. In DWC mode there's only one set of weather -- all stations are the same. Regards Pete

Well, it is quite easy, with profiles, to assign each as you load them, but there is another way, and that is to simply find the relevant [Profile.<name>] section in the FSUIPC INI file (in the FS Modules folder), and edit the entry (or entries) below to be an abbreviation of the name which will match all of the aircraft of that type. For instance, say you had: [Profile.Prop] 1=Carenado Cessna 172 White changing ths to [Profile.Prop] 1=Cessna 172 would match all aircraft with "Cessna 172" in the name, whilst [Profile.Prop] 1=White would match all with "White" in the name. This does assume you have "ShortAircraftNameOk=Substring" set in the [General] section, but that is defaulted these days so it should be unless you've changed it. If that add-on aircraft has a mixture control not operated by the misture axis assignment then you would certainly need to do something different. But I cannot really help without knowing what it needs to select the right setting. If there are some controls or keypresses to operate then that can be done by assigning to ranges on the right-hand side of the axis assignment tab. If you've elected to have autosave enabled then it could be, though it would certainly indicate a problem with your disk system as saving files should be so fast you'd not notice, and it certainly shouldn't delay FS so much that it forces a reload -- that only happens if the time gets wildly out! I never notice saves and nor should you. Windows should be caching files and you disk system should have sufficient buffers. The saved files are not large. There's a more likely answer, and that is the clock sync option, if you've set that, on the Miscellaneous tab. I use that too and don't get any reloads, but FS will reload stuff and give a progress bar if the time sync has to change the time by a minute or more -- changing by seconds doesn't do a reload. However, your system time should not really drifting so far off the FS time as to require a minute adjustment very often, if at all, once sync is obtained. Maybe the frame rate is rather low and FS is struggling to keep up? Do you get a lot of stuttering? Regards Pete

I've added a note to the Installation Guide for now. Thank you. Pete

Oh, right. The loader is NOT automatically installed, but it is used if you've installed it manually. There are instructions in the Installation document for using it but only to get over that Simconnect problem. Agreed. It is weird, with no explanation at present. It makes little sense. Okay. Thanks. Maybe you should put a new thread for this into the User Contributions or FAQ subforum? Or I might add this warning next time I make a new full Release. Regards Pete

I've been comparing the results on wind smoothing and gusts of using different combinations of: FSUIPC's turbulence suppression and actual weather with just gusts and weather with both gusts and turbulence (a rare combination, really, as you normally get turbulence in upper layers only and gusts near the surface only). I need to explain something. With wind smoothing enabled in FSUIPC the simulation of gusts, directional variance, and turbulence, provided by FS itself is virtually eliminated. It cannot be helped -- either it smooths the winds or it doesn't. At the level it is working at it cannot distinguish between changes to wind direction and speed due to normal changes and those due to these oscillating effects. THEREFORE in order to get these effects, FSUIPC adds its own simulation. It is this simulation which is modulated via those two parameter lines I mentioned earlier. Now when either gusts or turbulence is active in the current wind, things are straight-forward. The simulation varies the wind at different speeds and over a different range accordingly. But when both are active together, it gets very very complicated. There are two different oscillations going on with different frequencies and different ranges. Here, when the wind is set with both gusts and turbulence, the turbulence is tending to override the gusts -- the winds are not varying as much as the gust range set. I think this is what you were seeing, and why inhibiting the trbulence gave you your more expected gusting range. I'm sure that the only difference between your nonDWC and your DWC weather in this regard was that the latter (more realistically in my option) did not provide winds with both effects turned on. I'm not sure I can do anything about this without risking messing the code up, but I will have a look. I don't really think there's anything else in the INI or AS settings which impinge upon all this. [LATER] Okay. Try 4.856, now up. I made the turbulence oscillate around the last computed gust value rather than the set value. The unlikely (unrealistic?) combination of gusts nd turbulence now works better. It isn't perfect, but I think perfection would be too costly in terms of both my time trying to work it out and in performance too. ;-) Regards Pete

What software are you using to drive these motorised throttles? Nothing in FSUIPC sends anything to control your motors. It'll be something your software is reading. How are the graphic throttles in P3D moving? These controls are used in FSUIPC only when the throttle offsets are written to. And for that they are used all the time, without exception. So we know they work. I think the error is referring to the ID of your aircraft, which is supposed to always be "SIMCONNECT_OBJECT_ID_USER" (defined as the value zero). If P3D's SimConnect suddenly loses the user aircraft ID, not even recognising it as zero, then it is either a bug in P3D or something in SimConnect is getting corrupted. Looking at this part: 1. It looks as if you are using an add-on aircraft. Are you sure it is 100% compatible with P3D? Can you test with the default Lear45 to check? 2. There's a period of nearly 35 minutes elapsed before these errors occurred. Were your throttles going daft all that time? If not, did you notice anything specific occur just before they did? Perhaps complex add-on scenery? The G3D errors which occur are usually due to memory corruption as far as I can tell, so this might be just another symptom of the same. You may need to enable SimConnect logging (see the FAQ subforum thread for instructions) and report all this to Lockheed-Martin so they can investigate -- but they may not want to know unless it is with supported add-ons or default stuff. Regards Pete

Why are you using the Loader in any case? It is only provided as a possible (but unproven) solution to initial loading problems due to SimConnect trust bugs. Once that unlikely problem is past it doesn't occur again in any case. And because the loader simply loads FSUIPC4.DLL after a short delay, there's nothing it can be doing to affect anything else. There's something wrong with the DA Fokker, then. A small change in the initial loading of FSUIPC cannot possibly affect anything which doesn't have something wrong with it in the first place. I suggest you refer to DA Fokker support for assistance. Regards Pete

Only the current version is supported and that's also the only one available, so that is what you must use. If there's a "bug" told to you by another website why has it not been reported here so it can be fixed? More likely you refer to a bug in the VRS addon? Pete

It's the approval system here. A post from someone new has to be approved before it is visible. This normally happens quite quickly, but not as quick as the minutes you left between postings!. Hmm. how strange. Here one such undocking has quite a serious affect -- and on a 4.8GHz overclocked i5-2500K. Maybe you have most settings down low? It may be related to Geforce drivers. They are updated freqiently - up to 306.xx now I see, My card is a GTX 580. The 8xxx series is pretty old now, isn't it? Regards Pete