Pete Dowson

I've already answered this in your other identical thread! I've no idea what you mean here -- what do the ???????????? mean? Calibration is described with step by step instructions in the FSUIPC User Guide. But I strongly advise you to not even use FSUIPC until you sort your problem out. Just use FS in the usal way, make it work normally before changing to use FSUIPC. FSUIPC is not going to fix such drastic faults as you described. Pete Pete

Assuming you haven't got anything else manipulating the throttle, it soubnds very much like a faulty connection -- bad USB port or cable, or a fault in the unit itself. Sorry, I don't understand this part. If you are saying your throttle is misbehaving even with no throttle control connected, then you certainly do have something else manipulating it. Is FSUIPC relevant at all? You've not mentioned any use of FSUIPC. If I were you I'd start a process of elimination -- stop every other add-on or cpntrol you have until you find the culprit. You could also enable some of the Logging facilities in FSUIPC to see what controls are being used. Pete

What are "VC or 2D cockpit commands"? Sorry, you'll need to be more specific about what you are looking for. FSUIPC's drop-down lists all of the FS commands listed by FS in its "CONTROLS.DLL" module. Many of those can also be assigned in FS itself. FSUIPC does add some others of its own too. But I don't know what you are looking for -- most of the commands are something to do with managing and operating the cockpit. That's what it's all about, flying an aircraft from its cockpit. Regards Pete

How are they separated? I know no way. This is a question for aircraft makers and animators. (And why is it important -- aren't you inside the aircraft acctualy doing the steering?) Turn down the realism settings. The full "realistic" setting is way overdone. And it varies enormously by aircraft model. Some of the add-on aircraft are extremely good in this respect. You may actually be able to deal with it too in the AIRCRAFT.CFG file -- check aircraft design forums, eg on AVSIM. Perhaps you could tell me how to do these things? I have no control over them. Regards Pete

You might want to update to the latest version (see the Download Links subforum). When did you purchase your Registration? If it was after the 11th January 2010 then your main problem is the date set on your PC: That would make your Registration look invalid. Correct the date on your PC. Regards Pete

I didn't even know iFly ever used FSUIPC! Close FS, find the FSUIPC.LOG file in the FS Modules folder, and paste it complete here (yes, delete your email if you wish). Pete

If that's the case it would be clearer written as var = ((ipcPARAM+16384) * 100)/32768 because it is ambiguous the way you have it -- whether the multiplication is done before the division, as would probably be assumed in normal everyday notation. If you are writing "var" back as an integer it will be rounded down to the nearest integer in any case. To round up or down to the nearest, just add 0.5 first. i.e. var = 0.5 + (((ipcPARAM + 16384) * 100) / 32768) Finally, assuming ipcPARAM is running from 0 to 16384, as you are implying, to reverse it all you need to do is subtract it from 16384, so: var = 0.5 + ((((16384 - ipcPARAM) + 16384) * 100) / 32768) Pete

No, there's nothing in FSUIPC, or in any part of SimConnect, to trigger effects directly. They seem to be related to other things, so, as Gypsy Baron suggested, you'd need to try to link them somehow. Regards Pete

A trim wheel, such as that sold by Saitek, is very nice, but unless it is motorised so that when the autopilot is controlling trim the wheel can be automatically moved to its correct position, it poses difficulties unless you fly under manual control all of the time. With the autopilot operating the trim for vertical flight control modes, the wheel's position will not often match the actual trim position in FS. This doesn't matter if you don't move it, as axes are not read until moved. But as soon as you move it, the actual setting for the wheel position is immediately applied, resulting in a sudden trim change. FSUIPC does have an option to disconnect the trim axis when the autopilot is using it (see the DisconnTrimForAP option in the Advanced User's guide), but this doesn't get over the discrepancy in the position when the A/P is disconnected. Really the only satisfactory way of having a trim wheel operate through the trim axis control is to have it motorised so that is always goes to the currently set FS position when the A/P adjusts it, or when you load a new flight. An alternative, which can work but which does spoil some of the advantages of having a realistic trim wheel, is to revert it to sending elevator trim up and trim down commands to FS, instead of using the value directly as the trim vale. This effectively makes it similar to the NumPad 1 and 7 keys, or the spring-loaded two way toggle switches or levers fitted to many commercial yokes. The way to do this is to use a Lua plug in which converts the change in axis value to a trim Inc or Dec. Here's an example: function checkvalue(val) if prev ~= nil then if val > prev then ipc.control(65615) elseif val < prev then ipc.control(65607) end end prev = val end event.param("checkvalue") [/CODE] Save this as, say, "trimwheel.lua", in the Modules folder and add this to your INI file: [Auto] 1=Lua trimwheel Run FS and assign your axis, in the normal FS controls assignment on the left, to "Luavalue trimwheel". Regards Pete

Yes, you can, but it still isn't straight-forward -- there's still a Lua plug-in needed. Please see this thread from not so long ago: Covert Axis to buttons - without ranges BTW, as an addendum to my previous reply, I did of course omit to mention that FSUIPC already has the facilities built in, i.e. DisconnTrimForAP: When this option is enabled, FSUIPC disconnects the analogue elevator trim axis input to FS whenever either the FS autopilot is engaged in a vertical mode (altitude hold or glideslope acquired), or a program, gauge or module has disconnected the elevator axis via FSUIPC (offset 310A). Note that the setting can be overridden for specific aircraft which have specific FSUIPC joystick calibrations by setting this parameter differently in that [JoystickCalibration …] section. ZeroElevForAPAlt: controls the option for FSUIPC to automatically centre the elevator input each time the Autopilot altitude hold mode is changed (switched on or off, including AP engaged changes too). This option can be operated inside FS on FS2004, but if needed on earlier versions must be enabled in the INI file by setting this parameter to “Yes”. Note that the setting can be overridden for specific aircraft which have specific FSUIPC joystick calibrations by setting this parameter differently in that [JoystickCalibration …] section So that Lua plug-in wasn't needed. I clean forgot about those options -- I should have re=read the earlier part of this thread (as perhaps you should have too? ;-) ). Pete P.S. I have a feeling this question wil be appearing more and more often, so I've now pinned the answer as a thread in the FAQ subforum.

Sounds like the trim wheel is not set to do trim inc/trim dec adjustments. If it is programmed to operate the trim axis and it is NOT motor controlled, then it probably will not be in the correct position -- i.e. its position will not match the actual trim position in FS. This doesn't matter if you don't move it, as axes are not read until moved. But as soon as you move it, the actual setting for the wheel position is immediately applied, resulting in a sudden trim change. Really the only satisfactory way of having a trim wheel operate through the trim axis control is to have it motorised so that is always goes to the currently set FS position when the A/P adjusts it, or when you load a new flight. If you persist with the wheel operating the trim axis, you will be okay for purely manual flying, without using the Autopilot. You should start off each flight by adjusting the trim wheel till the trim indication in FS is centred. Then use the trim wheel for all in-flight trimming. The problems will only arise when you start using the A/P. The A/P is using the trim. Operating the trim axis whilst in A/P vertical control modes will interfere. The only way you can stop that is to disconnect the trim axis whilst the A/P is so engaged. If the axis is assigned through FSUIPC then you can disconnect it by setting bit 5 in offset 310A. That needs repeating every few seconds otherwise it is re-connected (to safeguard against crashed or hung programs causing loss of controls). So it would need a little Lua plug-in. Something like: function stoptrimaxis() if ipc.readUW(0x07BC) ~= 0 then ipc.setbitsUB(0x310a, 32) else ipc.clearbitsUB(0x310a,32) end end event.timer(5000, "stoptrimaxis") event.offset(0x07BC, "UW", "stoptrimaxis") [/CODE] Save that in the Modules folder as, say, "trimoff.lua" and add an [Auto] section to the FSUIPC4.INI file containing [Auto] 1=Lua trimoff You need to update. The currently supported version is 4.853. Pete

Well done! That looks good! And having worked that out you are now in a good position to solve any other little needs as they arise! ;-) Pete

The only problem I'm aware of with DWC mode was that, originally, because the weather in Global mode is the same the world over, any ATIS reports for destinations give you the wrong weather, the same as at your aircraft. This was fixed long ago, for ActiveSky ASE originally, by having ActiveSky provide an interface via FSX's SimConnect to let FSUIPC read the weather direct for any location. Thus, when RC asks FSUIPC for weather at a location, FSUIPC asks ActiveSky instead of FSX. This affects weather reports, and possibly the initial runway assignment and vectors when you get within 40 nm of the destination. There's also a facility in ASE and AS2012 to fix the weather withing a radius of the destination, provided you feed your Plan to AS first. I'm not sure what the radius is, maybe 50 or 60 nm, definitely more that the RC approach control area. These developments certainly helped getting weather reports correct and runway selection more reliable, but I don't think either have any bearing on performance. Furthermore both should work equally well with Prepar3D. I think the performance problems which affect external applications such as RC on approaches are down to delays whilst complex airports are drawn, and, more importantly, whilst AI traffic is handled or even generated for that airport. See if you still get the delay problems at simpler airports or with AI traffic reduced considerably. I'd really recommend running RC on a separate computer if you have an old one lying around. It not only performs better, but it provides a separate sound source so they don't mingle with the FS sounds. I use a headset for RC on a client PC. Regards Pete

Not sure what "tweak" you mean. And there should most certainly be no difference with P3D 1.4. What has DWC mode got to do with it (AS2012 defaults to that mode in any case)? I don't use P3D, but I do use RC and AS2012 with FSX. Never any delays there The only possible reason I can think of for any delay in RC being able to respond is an overloaded PC. Do you run everything all on one PC? I have RC on a Client PC. Pete

I've noticed, in the "pokeys-device-lua-script-external-dll-using-luacom" thread in User Contribution, that it succeeds using a DLL in the Lua subfolder of Modules, but it also needs the main Lua 5.1 DLL installed in the main FS folder. I assume that Lua DLLs which themselves make calls into Lua libraries will need the external Lua libraries, because there is no way back into those built into FSUIPC. It would have been nice and tidy if I could have found a way for external DLLs to use the Lua libraries built in, but there was really no way, as they'll be linking directly into Lua itself. The Lua scrpt files are okay of course because they are loaded and executed by the built-in interpreter. Pete

Hi Andy. No, I'm not ignoring you. I thought you were aiming your suggestion at the OP. I really wouldn't know why you'd get an error from having those two files there, at least not without delving deep into the original Lua interpreter code, much of which is rather obscure to my aging eyes! Regards Pete

Those are libraries implementing the memory-mapping interface into FSUIPC for applications wishing to get data into and out of FS. The Lua support has much closer in-process integration already, provided in the ipc built-in Lua library. That was the whole point of adding the Lua support in that way. If you wish to use Lua as an application programming language as opposed to a plug-in scripting system then you would need to take the source of the C-library (in the SDK) and build a DLL with the appropriate Lua hooks in it. This is not part of the plug-in system I've provided of course. If you do that you'd be interfacing into FS as a separate process, and you would not need to have spent your £35 because the interface into FS is free for non-commercial applications. You mean others using DLL libraries? Browse the User Contributions subforum for a start, or search for folks using the mentioned DLLs with FS. One's which come to mind are the OzRunways interface recentlly subject of a thread here, maybe LINDA, and the one I don't recall the name of which is using a graphics DLL to draw gauges on the Saitek modules. I'm afraid I don't have direct references to any, but a number like this have occurred over the years. Have you tried simply putting your DLL into a DLL subfolder in the Modules folder? Pete

There is a clear statement in the List of Supported Versions announcement (in the Announcements subforum) which will indicate that old versions are not supported. When you purchase as FSUIPC registration (which isn't necessary for FSXpand in any case) you purchase it for FS9 (or before) -- version 3 of FSUIPC -- or for FSX and later -- version 4 of FSUIPC. You do not purchase a specific release. That would make no sense, and you would lose support immediately the next version came out! The installer simply installs the FSUIPC module and updated documentation. It changes nothing else. If you already have a later version installed it won't change it. It's simple and foolproof. Could it be down to performance? Is the frame rate good in FS? Possibly FSXpand has some limited timeout on its requests and insufficient retries (though if it is timing out it should detect and report that, not continue and attempt to use the bad data). I suspect you will need the FSXpand support folks to look at your problem, because the error is occurring in their program, not in FSUIPC. However, do check the FSUIPC log file (in the Modules folder) in case it too is reporting problems. I can assist FSXpand in investigating the problem, but I cannot debug their code. Pete

As I said, I think DLL libraries need to be in a DLL subfolder in Modules. The Lua subfolder is for Lua libraries (i.e. libraries written in Lua). You are really getting way beyond my knowledge of Lua mechanics. I only know that a number of developments using both Lua and DLL libraries have already been constructed and working well. Recommendations or links to libraries which can be used have been provided by users. I am not one of these at all. I support Lua in FSUIPC so that these other folks, cleverer than I, can do such clever things. :sad: I think that's a bit of a nasty and cheeky comment. I provide Lua support in FSUIPC and it is being well used and is much appreciated, but I cannot support the Lua environment itself, only the code I know in FSUIPC. The package which is embedded, and which I do not know as well, is described mainly on the Lua website and in the several books published on the subject. I suggest you learn more about Lua if you aren't currently able to make it do what you want as well as others have done. Pete

No, Lua doesn't know anything about joystick numbers, which is what 102 is. Every device handled by FSUIPC's assignments needs a "joystick number" which for GF devices are artificially generated. They also get modified by WideFS client inputs which also support Go flight devices. The Lua library handles GoFlight devices more directly and uses the numbers assigned by the Windows system. I reformatted you code so you can see more clearly what is wrong: I've added comments withing. function gpsledon(132C,1) function gpsledoff(132C,0) -- This function, which is INSIDE the other functiion, has no code at all, so it does nothing! No code = do nothing!!! end event.offset(132C, "UD", "gpsledon") -- this event call is trying to call the function in which it actually resides. That function never gets called because nothing calls it! -- Additionally, as clearly documented, the offset 132C must be given as "132C" or 0x132c. gfd.SetLight(GFP8, 0, 0) -- (Model GFP8, Unit 0, Led 0) end event.offset(132C, "UD", "gpsledoff") -- 132C is wrong as stated. And the function called does nothing. gfd.ClearLight(GFP8, 0, 0) -- (Model GFP8, Unit 0, Led 0) -- this will be executed once, if the program ever compiled (which it won't). end [/CODE] It won't even load. Look in the FSUIPC log file -- you'll see the error s listed there. ALWAYS look in the Log. Of course not. 132C is not a hexadecimal number, and in any case this will execute only once when loaded then no more. What use would that be? You've evidently not looked at any examples, of which there are many.Please see the example files provided with FSUIPC, and the many User Contributions in the Sub-Forum of that name. I can answer questions and help you understand, but I am not going to write your programs for you. There's enough information available, but you seem to be ignoring it and not even referring correctly to the documentation. Sorry, Pete

Current SimMarket order numbers are 6 digits and will be 7 digits soon. I cannot go back far enough in time to get to one of the first sales of any produce SimMarket ever made, and FSUIPC wasn't sold that many years ago in any case. So I suspect you are making a mistake. Maybe you'd better give me your email address instead if you don't know the order number. Pete

If PMDG has provided controls for both you can assign both, in order, to the same button. You'd need to do this by editing the INI file, unless you'd be content to use a push button and assign the guard opening to "press" and switch operating to "release". For a toggle switch, though, you'd need both on the same "press" (and the reverse on the release). INI file button assignment formats are documented in the Advanced User's guide. You can have many actions assigned to the one button. they are executed in rder of the preceding line number (n= ...). Pete

Hmm. Interesting. But I have an iPad 3 on my Network (definitely only 2.4GHz) which I do use with other FSX programs without any similar problems. Maybe I'm just lucky. Glad you solved it though! Regards Pete

I'm not familiar with that library. Well I wouldn't have thought it was easy. You'd probably need to run FS in windowed mode, not full screen. There are quite a lot of existing FSUIPC Lua applications which are using external libraries. If they are DLLs, in older versions of FSUIPC you had to put those libraries into the main FS folder, but now they are okay in a DLL subfolder within the Modules folder. For Lua-written libraries you can put them in a Lua subfolder, or in the Modules folder. Whichever you choose you have to do a "require" call to load them. Sorry, I've no idea. You've provided no information to go on. Have you tried looking at the Log, even enabling the debug option on the Logging tab inFSUIPC? If you are not using an up to date version of FSUIPC (e.g. 4.852 fr FSX), then the first stepis to update. Regards Pete

Well, since it is a Lua plug-in operating this link, it would be the Lua debug option in the list of logging options. but please don't submit it to me. I won't know what to do with it. The Lua programming is quite complex and using components unknown to me. You need really to contact the author of the plug-in, which i see is not officially supported by the OzRunways folks. The reason I'd never heard of it seems to be that it is an X-Plane add-on, not an FSX one. I suspect it might simply be an installation error in your system (it doesn't look straightforward to set up), or a problem of performance. Have you got good frame rates in FSX? Pete