Pete Dowson

Sorry, that was a typo. not ival, just val. but it is wrong in any case. The val inside the parentheses is not needed, it is not in the syntax. Do you mean the VALUE of an LVar? I am pretty sure they are all Double floats, so you'd need to use ipc.writeDBL(0x66C0, val). However, if an integer value is sufficent for your needs, the corrected version I provided should work. Of course it depends on what the program which is reading it needs. Do you know that? Just writing to a user offset does nothing unless something is reading it. What now is there not to understand about writing to offsets? Pete

So, you shouls see it then in the Calibrations tab. FSUIPC actually intercepts the same control from P3D no matter whether you assign the FS control in P3D or in FSUIPC. It does exactly the same in both cases. With add-ons I can understand some of them not liking ax axis fed back into the Sim at a different (lower) Simconnect priority level. FSUIPC has to do that, otherwise it would end up in an infinite loop. PMDG Boeings certainly can have problems with that on throttles because they read the axis at one level at the same time as FSUIPC feeds as another. The two values may well be different (due to calibration and slopes). But it doesn't actually NOT work. And certainly rudders, ailerons, elevators, toe brakes, etc, are okay on pretty much all default and add-on aircraft. What about throttles, elevator, ailerons? Check with logging . Exable axis logging and see the controls actually being sent to the Sim. They'll show in the log no matter where you assign or whether you use calibration or not. I really have no other ideas. There are many users with those controls and no problems -- it is usually throttles which give problems with Saitek. You could of course try the usual remedy with most things wrong with Saitek -- uninstall their software altogether. Then go to the Windows Device Manager, find the rudder device, right-click and uninstall, being sure to check to delete drivers too. That should correct any Registry problems. Then re-boot. Pete

Okay. That actually works the same as if you assign in P3d. 1. Where, in the Assignment tab or in the Calibration tab, or both? 2. Does this apply to both Direct FSUIPC assignment AND FS control assignment, or only the latter? 3. Which FS rudder control do you assign to: "Axis rudder set" or "Rudder set"? 4. Does this apply to all aircraft -- default included -- or only add-on aircraft? 5. Check your rudder trim: an extreme setting for that will nullify rudder inputs in P3D. You can zero it by assigning a button or key to "Rudder Trim Set" with a parameter of 0. 6. Try also just assigning the rudder in P3D -- not as a possible solution necessarily, just to check. Pete

You mean assigning in P3D? FSUIPC's calibration is available no matter where you assign. I've no idea. You give no details for me to even guess. Pete

Oh, I thought they were included with the 2.0.2 release. That's a pity. I had the same problem. The code is dense and sparsely commented. Very complicated with its extensive use of stacks. I wonder what happened to the link posted originally. Perhaps I should have downloaded then and hosted it here, but you don't really expect links to stop working. Maybe you can persuade one of those who did manage to get it to supply it. I could then host it here. Try posting an appeal if you can't PM an existing user. Pete

Please try PFChid64_5128_TEST.zip. I'm worried that I'm messing up the other macro forms and can't test here without the hardware. So, if this version works with your existing macro needs, could you possibly also test the encoder forms with + - < >, with and without the encoder number (1,2, etc) and the simpler button or switch form like landing gear with + and -? Also, I noticed that the form with /1 to /4 appended to denote different switch positions isn't actually documented for some reason. At least I couldn't find it. Could you tell me where you learned this from please? Pete

Google search for "LuaSocket" finds it immediately. Did you try? e.g. http://w3.impa.br/~diego/software/luasocket/ Pete

You could write a little Lua plug-in to do that easily enough, similar to the little one I'll be including in the next Lua package release:which I think will also do the job without the extreme of Zapping: This is AIFreezer.lua (it was posted in an earlier message here): -- NOTE: For use with FSUIPC 5 only -- This small plug in, which should be pre-loaded: for example, by adding -- [Auto] -- 1=Lua AIfreezer -- to your FSUIPC5.INI file. -- It freezes taxi-out AI traffic when you lower your gear, -- and releases them when you touch down. -- For aircraft with non-retractable gear, it checks the state of -- the Flaps instead, expecting full flaps for landing. (amend where -- noted for other flap settings). function GroundCheck(off, val) if ipc.val ~= 0 then ipc.control(1149) -- Freeze AI off if user landed ipc.log("AI taxiout traffic released") end end function GearCheck(off, val) if val >= 16383 and ipc.readUW(0x0366) == 0 then ipc.control(1150) -- Freeze AI on if gear just lowered (whilst in the air) ipc.log("AI taxiout traffic frozen") end end function FlapsCheck(off, val) -- See if gear is fixed first: if ipc.readUB(0x060C) == 0 then if val >= 16383 and ipc.readUW(0x0366) == 0 then ipc.control(1150) -- Freeze AI on if now full flaps set when in the air ipc.log("AI taxiout traffic frozen") end end end event.offset(0x0366, "UW", "GroundCheck") event.offset(0x0BE8, "UD", "GearCheck") event.offset(0x0BDC, "UD", "FlapsCheck") Pete

It'd be safe, yes. Those which aren't used aren't used. Which aren't applicable anyway? Pete

But it is listed in the Contents of the User Guide, which is near the beginning, page 2 or so!!! Pete

I'm sorry, i simply do not know the correct parameter to use for the PMDG controls for the PMDG aircraft -- the PMDG SDK you have is more than I have. If there's not enough there perhaps someone on the PMDG support forum can help? I would have thought clockwise would be right click and anti-clockwise left click, but as I don't have any PMDG aircraft I don't know. Do you? Pete

Well, you've assigned "direct to calibration", but they haven't actually done any proper calibration. for Throttel1 you have this calibration: Throttle1=-16383,-16383,-16383,16383/32 which is really the default for a no-reverse-zne throttle. Follow the steps to proper calibration in the chapter on this in the user guide. You have no calibration for Throttle2. You may also need to check the "REV" option. some throttle levers have max towards you instead of away. Check that. Full forward should be showing something over 16,000. If it goes negative when pushing away from you, you need "REV". You do also have axies assigned for one specific 73: [Profile.737 Oct 2018] 1=Boeing 737-8CTNGX WestJet Winglets For that one aircraft you seem to have assigned your throttles to the FS axis controls. But no specific calibrations, so the generic calibrations apply and so my earlier comments on that also apply. Pete

I don't think that can be set. you'd need to set a suitable date -- day number and year, offsets 023E, 0240. Pete

Well, at least you've now got the correct IDs in the INI: [JoyNames]AutoAssignLetters=No0=X56 H.O.T.A.S. Stick0.GUID={9FF0B3C0-C406-11E8-8008-444553540000}1=X56 H.O.T.A.S. Throttle1.GUID={9FE62C70-C406-11E8-8005-444553540000} though whether these match any of the THREE joystick assignments (0, 1 and 2) you have in the INI file is for you to check What about my other requests and suggestions? I can't proceed on this alone. Pete

Sorry, you'll need to clarify that. FSUIPC will most certainly accapt such a parameter, though it will be displayed in decimal next time you look. The decimal for x20000000 is 536870912. FSUIPC normally displays parameters in decimal because normally that mode of expression is more relevant. Just not in this case. Sorry, but I don't understand this part at all. What context are we in? what are you doing? Pete

Buy one in SimMarket. The link is in the documentation. Pete

You can copy over the Modules folder to each installation. Pete

What version of FSUIPC and FS? What did you assign to in order to make it turn clockwise? If you want it to rurn the other way using the PMDG controls it will be by a different parameter, a mouse code. See: Pete

In FSUIPC Logging, use the option to log buttons and keys. See if the keypress is detected and how it is interpreted. FSUIPC doesn't forget assignments, but something else may be taking over the DEL key -- you could try a different keypress or even a buttom. The other thing, don't forfet the traffic deletion only works for an aI aircraft withing a certainly difstance and a narrow angle from your own aircraft's heading (or, rather, where the nose is pointing). Pete

What software drives the displays? FSUIPC is only normally used for the inputs. Are you using plug-ins for the displays? Beta? I assume you mean "Interim", as Betas go to a very limited group. And VRi support hasn't changed at all in any version of FSUIPC5. I have no VRi hardware to develop or test with in any case. You could log VRi Com exchanges. To do this, add the following to the [General] section of the FSUIP5.INI file: Debug=Please LogExtras=x4 Pete

Just purchasing and installing FSUIPC5 cannot stop anything working. It doesn't do anything unless you ask it to. Surely you are talking about assignments in FSUIPC, only? Can you tell me what you want to assign in FSUIPC in the first plaace. The usual reason is so that you can have different assignments for different aircraft types. The other is to assign to axes and controls not available in the Sim directly. More things: First please delete this section from your INI file: [JoyNames] AutoAssignLetters=No 7=X56 H.O.T.A.S. Throttle 7.GUID={9FE62C70-C406-11E8-8005-444553540000} 0=X56 H.O.T.A.S. Stick 0.GUID={9FF0B3C0-C406-11E8-8008-444553540000} Not only does this contain a wrong GUID, it had Joystick IDs 0 and 7, whilst all your assignments in the file are to 0, 1, and 2. (i.e three devices, not 2, and certainly no 7)! So, are you using an INI file from a different or earlier installation or PC? You should really be using Joy Letters, so that multiple devices remain correctly assigned if reconnected or you do reinstalls. Otherwise you will probably need to check and edit the [joynames] section each time. When you uninstalled the Saitek software, and the devices, did you go to the Windows Device Manager, find the devices, right-click, select uninstall, and then also the option to remove drivers? All that is needed to correct the mess that Saitek installers seem to often perpetrate. Then re-boot and re-test: but take care that the joystick IDs (0, 1, 2) match those you have assignments for. If not you can either use that JoyIDs program to change them, or get FSUIPC to do it by editing the [JoyNames] section when restarting P3D. And don't forget to enable the Joy Letters facility (see chapter in the User Guide). If there is still a problem I'll need more detailed logging. Please anyway turn off all the logging options in the FSUIPC Logging tab-- the ones you've set just make the log file very large to no purpose. I only need the first few sections. For the extra logging I need add these lines to the [General] section of the INI file before starting P3D: Debug=Please LogExtras=x200000 Pete

FSUIPC doesn't intercept this control. it was new and never added to FSUIPC's intercept list. FSUIPC's steering has always been by its own Tiller assignment. The sim control is "Steering set", not "Axis steering set". but it is not a calibrated axis in FSUIPC. The "Steering Tiller" axis is in the drop-down when "Direct to FSUIPC calibration" is chosen. This allows Rudder effect to be increased with ground speed whilst steering effectiveness decreases. Pete

Sorry, what logging? Ah, are you saying something logs entries only when you use "ipc.setowndisplay" or, also at other times? I don't know what is creating those entries, nor what they refer to. FSUIPC certainly doesn't touch flight files, and in any case only ever uses Windows "Private Profile" functions to amend INI and CFG files, I don't know any way it is possibly to have more that one entry in any section with the same keyword. Using the same keyword replaces its previous entries -- there;s no other way to do that. Writing null removed the keyword entry. Whatever is writing those is not using those Windows functions. Also, in all my experience, special windows entries at the end of a saved flight file are created when the FLT is saved and reflect the state of that window at that time. If they are accumulating in an existing file whilst the sim is running then something else is doing it. I don't thiink either SimConnect or FSUIPC is at all involved in this. The keycodes must surely be all the same. Any differences are only in the shift codes available. There are actually errors there -- only pointed out to me very recently. I've corrected the document here ready for the next update. Here is the corrected section: The shifts value is a combination (add them) of the following values, as needed: 1 Shift 2 Control 4 Tab 8 not used 16 Alt (take care with this one—it invokes the Menu) 32 Windows key (left or right) 64 Apps Menu key (the application key, to the right of the right Windows key) NOTE that this is different to previously documented shifts – the earlier list was in error, having ‘Tab’ at value 8 and a second ‘Alt’ at value 4 These are the same as those listed in the Advanced guide for [Buttons] programming, but different to those for the Lua library event.key function and those listed in the Advanced guide for [Keys] assignment recording (the ALT and TAB being interchanged). All this is most unfortunate -- they are "historical", and originally based on Windows shift codes in the KEYDOWN/KEYUP messages. When I discovered these differences (long ago) it was far too late to change them. Pete

There are no errors shown in the logs. Of course you've not supplied the WideServer.log, which is the other end of the communications. See if that shows any errors. But I think you need to post on the ProSim forum, because the reason for these freezes must surely be found within that project. Why not check it all out with ProSim on the P3D4 PC? For me, the main Prosim EXE doesn't seem to impinge at all on P3D4 performance, and most of ProSim's actions are more efficient with the closer relationship. I used to run it on a Client (that was ProSim V1, not the current v2), but found it much smoother on the same PC as the sim. Now the MCP part is integrated it is more important, so the A/P control is more precise. ProSim's communication with the displays and so on are via its own network code, not via WideFS. Pete

The user offsets 66C0-66FF are just bytes . You can use them for any format data you wish.! UD will use 4 bytes (for example 66C0-66C3) to store a 32-bit integer. You could use all 64 bytes to store a string, or an array of 8 64-bit dpouble floating point numbers, etc etc. It is up to you! Incidentally, you appear to be getting the wrong idea here: ival = ipc.readLvar("L:Board",val) ipc.writeUD(0x66C0) I think you must mean val = ipc.readLvar("L:Board") ipc.writeUD(0x66C0, val) Please do refer to the Lua library document for the correct syntax. Pete