Pete Dowson

You reference is the FSUIPC User Guide, in the FSUIPC Documents folder. I am not going to reproduce several chapters here. You might be out of luck. The FSL aircraft, like the PMDG ones, are advanced add-ons which do their own thing, not using FS subsystems for many things. Whether their A/P and A/T contorls use default contrrols or not I don't know. You might want to ask about that in their support forum. FSUIPC can only really make it easy to assign the FS built-in controls, though there are sometimes ways of doing more with those add-ons. Best to test what you are doing on default aircraft first though. Pete

Well, as I said, one of those isn't being used, it is? (P2,22). I'm assuming Lua file #13 is the Lua file you showed me. Also, the fact that you are toggling positions in the gauge with the two buttons which are actually doing anything suggests that the -1 and +1 values are actually telling the gauge to toggle the switch position. Why don't you have anything programmed for the 0 value? You may want to study the behaviour of that L:Var more carefullt before actually trying to work out how to program your switch. Use the Lua example provided to log the L:Var values as they change. I don't recall its name off-hand, but they are all described in the Lua document. The examples are in the ZIP file. Pete

Sorry, but I have no idea what iVap is looking for. The message is not one from FSUIPC. You need iVap support. Pete

There's no such facility in FSUIPC5. Please update your P3D4 to 4.1. Version 4.0 will not be supported in the next version of FSUIPC5. If you still get the same CTD, report it to L-M. Please now go to the thread entitled "ATC.DLL crash" Pete

No, that isn't likely, though you can suggest it to L-M, that it may be the old bug carried over from FSX. It will be a bug in P3D, maybe fixed in 4.1. Why are you still using an old version? There are many bug fixes in 4.1 as well as enhancements, and the next version of FSUIPC will not support anything earlier than 4.1 because it is using newer features. [LATER] There is in fact a thread in the private developers Forum in L-M where at least two others have reported crashes in ATC.DLL and they are providing dumps to L-M so it can be investigated. I don't think those reports are specifically related to geographical position, but you never know. It may turn out to be the same old problem. Pete

You say the three positions on your switch are all recognised as 'button numbers'? 21, 22 and 23? If so, why does the Lua only process ipcPARAM values -1 and +1? What about when it is 0? And the Lua file seems far too complicated. Why are you reading the panel switch position first? If it has three positions settable why not just set them? That would be very few lines. Perhaps, also, you should show me the assignment likes for J2, 21,22 and 23, from your FSUIPC INI file. Pete

Okay. Glad you resolved it -- though I'm not sure how the registry managed to say it was in "Program Files", nor how FSUIPC5 did in fact install correctly into Program files, as shown in your original Installer log, so: So what was actually wrong is still a complete mystery! Pete

But according to the Registry, it isn't installed in "Program files(x86)". And unless you chose that folder explicitly it certainly wouldn'ty have been installed there in any case! FSUIPC in installed in the copy of Prepar3D v4 in "Program Files" not "Program Files (x86)". THAT is where the Modules folder will be and also where you've been saying all this time you've been looking!!! If you are going to uninstall and reinstall you care far better off choosing somewhere else altogether. well away from easy of those folders. Try, for instance, C:\Prepar3D v4. Don't concern yourself with that until you have a properly installed P3D and actually know where to look for the Modules folder. Unless you find the correct folder you've got no chance. Pete

Select one of the 4 (the 4 are simply to allow multiple assignment to the same axis, which is certainly not relevant to toe brakes. Then you will have a drop-down list. Just select left brake or right brake as appropriate. You may need to reverse them too, so when you go to the Calibration tab to calibrate them, be sure to select the REV option. By the way, there are pictures in the User Guide to help you. You might also get more help, from folks better at explaining things than me, it you used a more description suject heading for your post. "FSUIPC" really says nothing useful. Almost every thread here is related to FSUIPC. Pete

Program Files(x86) is for 32-bit programs. P3D4 is 64 bit. If you let it install in its default path, then it will be Program Files, and the correct path is found in any case by the FSUIPC5 Installer: INSTALLATION FOR Prepar3D v4:AppPath="C:\Program Files\Lockheed Martin\Prepar3D v4\" Isn't that where you've been looking? You cannot change this without uninstalling P3D, and reinstalling choosing your own path. For a completely hassle-free future with FSUIPC and other apps you may want to use, it is always best to install outside of any Windows-controlled folders. I would recommend something simple, like C:\Prepar3D v4. I alway install sims on a separate drive to the System, as it expands greatly with add-on sceneries and so on. Best to keep the system disk tight and efficient. Leaving it where it is may mean, with some applications, running P3D "as administrator" too. Otherwise they may not work correctly. That shouldn't apply to recent applications designed specifically for P3D4 though. I am working on a revised FSUIPC and Installer which will install into a separate folder, probably something like C:\FSUIPC5\Modules. I'm rather worried, however, that this will adversely affect some applications which use FSUIPC and find it by knowing where P3D is situated. FSUIPC has a very long history of always being in the Modules folder withing the sim, and many applications rely on that. Pete

I don't think so, but by all means look for yourself. i attach the list i've extracted from P3D4.1 -- in ID order as well as the order supplied by index. The left most number is just the time entry (the data is from an FSUIPC5.LOG file), so ignore that. the second number is just the index -- the list as supplied is in that order. Third number is the actual control number FSUIPC5 will be using. The name of the control, which will appear in the FSUIPC5 assignments lists is followed by the description provided. That's enclosed in ' characters. This won't be the published list, of course. I'll tidy it up first. I'm also getting some errors -- 4 new COM STBY RADIO controls are rejected even though supplied in the list by P3D4! Pete Event list for P3D4.1.zip

GFDev64.DLL is only used by FSUIPC so it can read the buttons and switches directly, and also support the lua gfd library. It has nothing to do with Goflights device specific drivers. Probably nothing at all, unless you cannot assign buttons and switches in the Goflight driver to do what you want. FSUIPC offers more flexibility of assignment, to more functions and even combinations of functions. See the User guide to understand more of what FSUIPC does. But without programming, via a lua plug-in, FSUIPC does not drive displays on any Goflight devices. That's why you need the proper Goflight drivers which they should provide. Pete

Your normalize is wrong too. Headings run either 0 to 359 or, more usually 1 to 360. Using the math on the offset data you get 0-359.99999 ... It cannot be outside that range because anything like 360 or more won't fit. That's the whole idea of the units used --they use all of the 32 bits to give maximum precision for that range. The "normalize" is just taking care of the possibility that converting to magnetic instead of true takes the value outside that range. So instead of: the += 359 should be +=360 and similarly the -= 359 should be -= 360. If you want 360 instead of 0 then you need to change it more, of course. Also, you declare h as an int32 yet call it with a double as parameter. Doesn't the compiler tell you? Don't you want fractions? If not shouldn't you round it properly first -- e.g. add 0.5 before it gets converted from double to int. Otherwise for example for 23.9 you'll get 23 whereas you should have 24. Pete

The trouble with all of your assignments to doubles is that the conversion to the double is the LAST thing which is done. So in both cases double hdg1=heading*360/65536; double hdg2=mag_var*360/65536; the result of multiplying the heading by 360 is already going ot overspill the 32-bits (4 bytes) in your "int" (or only 16 bits in the case of mag_var. So you need to force the conversion earlier, by this: double hdg1=heading*360.0/65536.0; double hdg2=mag_var*360.0/65536.0; Yes, because 65536*65536 exceeds the capacity of 32 bits: 0x10000 * 0x10000 = 0x100000000 so the remaining 32 bits is zero which you are using as divisor. Pete

I've not had anyone with such problems before. This is insane! With any program you should be able to right click on it, select "run as ..." then "administator" in the choices which come up. You surely must have done that with the FSUIPC5 Installer, as instructed? Otherwise it wouldn't have even been able to create the Modules folder. Or are you saying you actually ran Explorer 'as administrator' and it still stopped you seeing folders of P3D? Normally lack of administrator privileges would stop you (or programs not running 'as administrator') changing files if the permissions aren't set correctly, but certainly not seeing the folders and their contents. Do you see other folders in P3D? If so, then Modules is just another. It is supposed to have relaxed permissions, as i explained earlier, but otherwise it is just like any other folder in P3D. It sounds like it was never created, but the install log proves it was -- and it also proves that the Installer could access the folder it created where it tells you it installed FSUIPC5 into here: C:\Program Files\Lockheed Martin\Prepar3D v4\Modules Therefore I really do think you cannot actually be looking in the correct place! Can you do a P3D directory list and show me please? You'll need to go to the bottom left on the Win10 screen, nd in the search edit entry filed (or whatever it is called), enter command /c and press Enter. That will bring up a DOS window. type C: and press Enter, then cd \Program files\Lockheed Martin\Prepar3D v4 and press Enter. This should return a prompt with that path. Now dir >c:\dir.txt and Enter. You can then exit by exit Enter There will be a file called dir.txt in c:\. Paste its contents back here please. Pete

In fact you can calibrate in FSUIPC even if you assign all your axes in the sim. The calibration facilities in FSUIPC long preceded any of the assignment facilities, so that's always been the case. The "direct to" method is simply a slightly more efficient method which bypasses the Sim altogether, and only sends the final calibrated value though. The "send to FS" method simply makes FSUIPC use the original method for calibrating FS assigned axes, interception of the control as it arrives in the sim, manipulating it, and sending it back. Pete

Same place you got the one you have! The link provided originally for authentic downloads always works and gets you a current version. For information regarding updated modules, and an alternative place to download them as well as other useful programs and interim FSUIPC updates, see the Updated Modules and other threads in the Download Links subforum above. That's my main program repository for all to access. BTW, entitling a thread by your name isn't a good idea! You should always state the subject there. When i'm here I tend to read all new posts, but when I'm away yo need a title whichwill elicit interest from folks who can also help. Pete

Hi Bob, and others interested in this. [Note that I split this subject off from the original thread as it will be of more general interest, I think, than just for the FSL A320] I've been doing tests, and I really don't think i need to make any changes. well, possibly one, a parameter default change, but I'm not keen to do that. Let me explain: The way FSUIPC works to allow steering tiller and rudder use to be gradually moved from tiller to pedals at higher ground speeds (and only whilst on the ground, of course), was and remains by having both assigned and calibrated in FSUIPC. And it sends Rudder controls for both (because the steering control is relatively new). But this only applies if the assignment for the Tiller is to the FSUIPC-added steering tiller control, not to assignments to the FS "steering set" control. The Steering set control can be assigned and calibrated and used independently from the rudder assignment and calibration. I have, however, noted one oddity with P3D4 (I'm not sure if it applies to earlier versions, but i've never noticed it). When you use the FS steering set control it won't be logged by name even if you have axis logging enabled. It still works, but it seems the default method used by FSUIPC to detect and therefore log this -- by actually requesting that events be intercepted -- does not work using the method FSUIPC sends events by default these days. (It sends them as WM_COMMANDs rather than as events direct to SimConnect. This applies to many controls, in fact, not just Steering set. Looking in the FSUIPC4 History document I see this: Axis events for axes assigned in FSUIPC4 are now, by default, sent on to FSX via the messaging system (as in FS9) rather than via priority SimConnect events. This is actually more efficient, and also avoids possible event priority problems with other add-ons wishing to receive the values. In case this does cause anything a problem, the change can be reversed by adding: EventsViaCommands=No This can be placed in the [General] section to change things by default, or in specific [JoystickCalibration] sections for specific aircraft or profile changes, or to allow it to be changed during an FS session. The Calibration entry overrides the default entry. The Events this refers to are any normal FS control assigned in the Axis Assignments tab. This was a change made in 4.595d and released in 4.60, and therefore of course brought across to P3D4. The highlit red part is important, I think, but I don't recall now which other add-ons had problems with it. I have a feeling that the layering of actions by the sim has changed in P3D4, and possibly this parameter could safely be reverted to being off (i.e "No") by default. But at this stage I daren't risk it for fear of spoiing someone's day! Anyway, in conclusion, it is already possible to solve the steering problem with the CSL A320 and any other affected add-on, by a simply change in how you assign. Pete P.S. There appears to be no "Axis Steering Set" control, only "Steering Set". Misleadingly, there is an "Axis Steering Inc Set" control, which does appear to operate as an Axis steering set control. I've no idea why the 'inc' is there! Seems named wrongly, like many of the more historical controls. P.P.S. In the next release of FSUIPC5 the assignable control lists will be derived live from P3D4.1. The release will not be suitable for 4.0 users. Doing this will allow the complete list of P3D4 controls to be assignable in FSUIPC -- there are many which have been added since i built my lists.

I don't recognise that name. Are you talking about a local panel variable (L:Var)? Have you observed it changing -1, 0, 1 when you operate the swtch on the panel? Also check the actual lights, -- look at the outside view. Quite often changing the L:Var makes the action happen, but just doesn't move the panel switch -- if that's the case, there MAY be abother variable to do that, but more likely it can only be done by mouse. I can't comment on either because you show no examples of your attempts. Mouse macros are not likely to be available if the aircraft is relatively new. They only apply to panels made to the same spec as the FS2002 panels SDK for C/C++ gauges. That used to apply to many aircraft, through FS2002 to fSX, but newer ones use different methods and/or XML. Pete

That's the reason you can't access the folders. Windows is preventing you! Are you running the Installer "as administrator". You have t, otherwise it cannot change the permissions on the Modules folder! Try running Windows Explorer "as administrator". You should then be able to see it. Then see if you can check the folder permissions. To do this (with Explorer running "as administrator"): 1. In Windows Explorer RIGHT click on the P3D modules folder, 2. Select "Properties" down at the bottom of the popup list. 3, You'll see a dialogue window called "Modules Properties". It has 5 tabs I think. 4. Select the "Security" tab. This will display a two part window. 5. Look at the list at the top. there should be an entry labelled "Everyone". Select it. 6. Then in the lower list all the first 6 entries should be ticked. 7. That's it. Just click Cancel to exit. The FSUIPC Installer tries to set user "EveryOne" with full control. That would let you look and add/change files, and it would also allow FSUIPC to run correctly even if you don't run P3D "as administrator". (You could change these permissions like that yourself, but the Installer should have done it for you anyway. So do you have a problem there too? I really couldn't work much out from your first message, it seemed to mix things up. Pete

If FSUIPC is being loaded and run, then there certainy is a "modules" folder. I suggest you shown my the FSUIPC Installer log then I can tell you exactly where it is. (In case you can't find a copy of that either, re-run the installer. it will place the log in the folder (or desktop) in which you run it as well as in the Modules folder). And remember to run the Installer as administrator (right click then run as ...). If you mean my PFCcom64.DLL, it has no installer and produces no "startup picture". You simply place the actuall DLL into the Modules folder, when you find it. A DLL cannot run on its own like a program. P3D3? But FSUIPC5 is only for P3D4. it is the 64-bit version. It can't be installed into nor run in P3D3. It isn't possible.. I thought the PFC radio console was a USB "HID" device, not an ordinary RS232 serial port device? Or did they make such what, 10--20 years ago? I know there was one in the centre console -- I have such in my PFC 737 cockpit. No, do NOT do that! If there's not one there then FSUIPC has not been installed and certainly never run. You certainly NEVER want all those. Either you use P3D4 in which case it is PFCcom64.DLL or PFChid64.DLL, or you are using FSX or P3D3, in which case it is PFCFSX.DLL or PFDhid.DLL. And I don't know a PFC.DLL. Pete

FSUIPC's tiller steering facilty has always used rudder, hence it's automatic reduction of tiller control in facour or normal rudder control as ground speed increases. The steering axis didn't exist when that was added. Well, possibly an option. Or maybe one assigns to the AXIS STEERING SET control instead of FSUIPC's own control, it could allow calibration for that as well, just ignoring the tiller/rudder link up it would normally apply. Or maybe (but a lot more work) I could add a separate FSUIPC control for "unlinked steering" ... No, i think using the FS control assignment should do. This would presumably also apply to FSUIPC4 (FSX/P3D1-3) not just FSUIPC5 (P3D4)? I'll put it on the list for looking at when I get a moment. Might not be for a few weeks yet. If I can't get to it next week it will get delayed whilst I go to Spain to visit my sone and his wife. Pete

Indeed, yes, very strange. Of course the LFS was written by a separate contrubutor. From my Lua docum,entation: "Additionally, the third-party file system library, lfs (LuaFileSystem) by the Kepler Project is also built-in. A separate document is supplied describing this library". So it was never part of the main suite of standard libraries as documented in the official Lua books. Possibly he/she did things differently. I do actually build the source into FSUIPC -- it is compiled into it. Would it be worth me taking a look? I could compare what io.open does with what lfs.dir does and maybe adjust it accordingly. What do you think? Pete P.S. I've just read the description of lfs.dir, and it it more complex than I thought. It simply returns an object and it's the object which returns the path. What paths does it iterate, all the sub-directory paths in the path you give it in lfs.dir? So it the initial overall path going to be derived there, I don't need to worry about the iterative part? Are there other lfs functions which may also be affected? Should, for instance, "currentdir" always return the Modules folder path, or the original "true" current directory you've come up against. It can't really i suppose because then chdir would be useless. Thinking along those lines perhaps it would be dangerous to change lfs.dir's behavious, in case it was deliberately changed by chdir? Looking further through it, i would say it could be a can of worms, perhaps better left untouched after all! .

Sorry, but it is outside the range of button numbers (1-32 or 0-31 in FSUIPC) which FSUIPC handles. You can program it using a Lua plug-in which reads the HID values itself, but that isn't straight-forward and requires a bit of nifty programming. Also I think LINDA can probably handle it (but I'm not sure -- best to check). Pete

I assume you must mean a keyboard key? If so, this is part of the Windows keyboard system. I don't know if it can be changed. The reason for the delay is so that key presses can be used singly when not held. If you mean button pressing, then you can change both the initial delay and the repeat rate using the "ButtonRepeat" parameter in the FSUIPC INI file. See the Advanced User's guide, page 19 or so. Why are you using offsets rather than the standard controls, BTW? Is it for a non-standard increment value? Pete