Pete Dowson

They aren't assigned, then. The calibration tab merely intercepts the throttle controls, it doesn't handle the joystick devices a all. You have to have the throttles assigned first, either in P3D or, if you need to be able to switch them around for different aircraft, in FSUIPC. Okay, so then you should see them okay in FSUIPC calibration. I don't know what you changed, but possibly the PC saw the USB connection as new and assigned a different ID. If you are assigning in FSUIPC and not using the Joy Letters for identifying devices, then this would make all the existing assifgnments incorrect. With lettering instead FSUIPC is able to track devices if they appear to move to different Windows IDs. Why are you assigning in FSUIPC? Maybe you should show me your FSUIPC4.INI file. You can paste it here, in a message. Regards Pete

Well, you can do more than me. :-) i don't even know how to include pictures in the first place except by uploading them to some website and placing the URL into the message. Anyway, that's not really the point. I'd prefer to see the files which make the pictures show what they show. The files are more definitive. Don't try attaching text files, just copy and paste the contents. You can bracket them with the <> code parenthese if you like, makes them retain formatting better (<> button above the editing area, next to the quotes button). Regards Pete

Sorry, I don't really know what you are talking about. The offsets list in my PDFs are in herxadecimal. Don't you know what that is? I don't know VB but I think, in that language, hexadecimal numbers are denoted by that &H preceding them. I think that for unsigned numbers you should also have & at the end, otherwise &H8440, for example, becomes &HFFFF8440, which you most certainly do not want as an offset. But don't take my word for it, look it up in VB manuals. In C/C++ hexadecimal is denoted by a preceding 0x. In Assembly code it is denoted by a trailing h. I expect other languages use different conventions. You should learn the language you intend to program in before attempting to make a complex program! Regards Pete

Non-specific assignments to buttons can be overridden by profile-specific assignments, yes. Otherwise they are additive. Same for keypresses. It is only axis assignments which are completely either generic or specific -- they have to be because otherwise axes you don't use in a specific aircraft could interfere with things (axes are alwatys active, unlike buttons and keys which need user action -- i.e. pressing/releasing). Regards. Pete

I think you might have a loop because you are writing to 66C0 different values. You surely missed out actually testing the value of 66C0. You only want to do this thing when you've set 66C0 to 0 don't you? function sendmybutton(offset, val) if val == 0 then ipc.writeLvar("L:MasterCaution", 0) ipc.writeUW(0x66C0,-1) end end ipc.writeUW(0x66C0,-1) event.offset(0x66C0, "UW", "sendmybutton")[/CODE] BTW, I also think choosing -1 for "nothing" and 0 for "do something" is not good. Offsets default to 0, so why not choose 0 for "do nothing, then different non-zero values for action? Pete

Commands? The FSUIPC interface is the same no matter whcich offsets you want to handle. If by "commands" you mean "offsets", then the list is provided in documents (one for FS9 and before, one for FSUIPC4 and FSx) within the FSUIPC SDK. I'm afraid I cannot help specifically with VB.NET, but you might do well looking in the Download Links subforum, in the thread FSUIPC Client DLL for .NET - Version 2.0 . Regards Pete

It certainly sounds rather like the Registry problem a lot of Saitek users have complained about. I think you should check the Saitek support forum. If it is that then there's a registry fix for it I understand. FSUIPC cannot influence the input values, only the resulting output values. Generally you can calibrate any range of inputs, even ones which seem quite short of values, and still get the full range of output values -- but of course mapping, say, a range of 0-10 only onto the desired output of 0-16383 will make adjustment a bit, er, coarse. I hope you see what i mean -- the input range is not always so relavant providing there is one! I think you'll find it's actually a "yoke". A "yolk" is the yellow bit in an egg. In that case you really should consider assigning the axes in FS as well. You can still calibrate in FSUIPC. The only reason normally for assigning in FSUIPC is so you can have different axes assigned for different aircraft, which FS doesn't support. Most folks prefer to assign everything in FSUIPC. There's no reason not to -- FSUIPC offers more in the way of button assignments than FS itself does, including for the "hat". Well, obviously something has changed. Maybe there's been some registry corruption or an auto-update? I can't really tell you from here. If you want me to check anything further, please do not post little pictures which don't really tell me much and which are very difficult to see properly. The best thing to append (paste in actually) is your INI file, for instance. Regards Pete

Deleting assignments in FS is generally not the best thing to do. If FS decides, for any reason, that your controllers are newly connected, it will automatically make assignments. Best always to disable controllers. No deletionsd needed, just one click. The centre values are not relevant when you have "no reverse zone" checked, as you have. Without that option the -ve values give reverse thrust, and the central zone is where the idle is. With no reverse zone the whole range from minimum to maximum is for forwad thrust. There's no "centre". The values are ignored. With the values you show above, which are the default values, it is evident that you haven't actually calibrated your throttles. You should always leave a dead zone at either end -- especially for idle. Joystick devices don't always give the same values and you al;ways need to allow space for variations. Please check the User Guide. The chapter on calibration gives step-by-step instructions for proper calibration. if you don't do this it is really a waste of time using FSUIPC for those axes. Your INI settings are really no different from what would happen in FS by default. The input values or the output values? For only forward thrust (which is what you have with no reverse zone), the output values should only go from 0 to 16384. But no instantly of course. It certainly sounds like conflicting assignments to me, with one set reverse of the other. Where are you reading this? In the Axis assignments tab (as you imply by "scan")? If so, then something's wrong with the Saitek drivers or teir Registry entries. The assignment tab shows the actual input being received from the device. Regards Pete

Well, maybe not all. Some failures will have common symptoms. I think you'd need to experiment. Regards Pete

There are a number of failures you can se up, through FSUIPC offsets, including engine fire and maybe preventing landing gear action. But it will depend also on which add-on aircraft you use, or a default. FS itself doesn't simulate cabin pressurisation, so de-pressurising it isn't possible. However, you could try to work out what the results would be and try to make those things happen. Same goes for a lot of things. Pete

Why assign buttone to keyboard presses when there are perfectly good Trim Controls to assign to -- Elev trim dn and Elev trim up? All you are doing is sending keypresses to the keyboard buffer for FS to read and convert to the very controls you should use in the first place. It is never necessary or desirable to use keypresses for buttons and switches when there are the controls assignable directly. The keypress assignments part is intended for use with add-ons which don't process controls and have only key assignments instead. I think you've just missed the obvious, the assignment of buttons and switches to controls in order to control FS. There's also an example (boxed, headed Offset Increment/Decrement Controls) in the FSUIPC user guide specifically aimed as showing how to use the offset controls to assign trim inc/dec controls with precisely the amount of control you want, rather than having to accept the standard FS inc/dec amounts. Whilst elevator trim can be controlled via an axis (and many folks do), this path has to be taken very carefully, because FS uses the elevator trim for the Autopilot altitude modes, and unwanted inputs (jitter) from the axis can mess that up (though FSUIPC does have an option to disconnect the trim axis). Additionally, unless your elevator trim axis is motor driven (as in a real airliner, for example), when the A/P is diengaged it is likely that your axis trim will be in a completely different position to the current FS trim, causing stability problems as soon as you touch it. For these reasons it is often wiser, and certainly easier, to use the trim up/dn controls or the offset equivalents instead. Regards Pete

The only difference between q and r is that the new added control for switching on the console log window now returns focus to the FS window instead of leaving it with the FS window. Nothing else whatever was changed, so you must have something else going on there, some sort of corruption in FSX which only affects an area of memory changed by the slight difference in FSUIPC size. If you cannot identify the problem, I'll need more information in order to be able to help -- the Windows event log data for a start, and the FSUIPC log and ini files. For the windows event log data, please do this: START button, enter 'event log' and press Enter. The Event viewer will appear. Select 'Windows Logs' -- 'Application'. Scroll down the list to find the ! Error entry with Source = FSX. Select it, then in the pane below, select Details/Friendly View, right click in it, select 'Select All' and 'Copy'. Paste the results into a message here. Regards Pete

There's no inbuilt facility to make an assignment conditional on a button or switch or keypress. You would need to use a Lua plug-in. Something like this: if logic.And(ipc.buttons(joystick number or letter), value of button) ~= 0 then ipc.control(pan view control number, ipcPARAM) end where joystick number or letter is the number of the joystick for the button you wish to use 9or letter if you are using joy letters), value of button is the bit value for the button: 1 for button 0, 2 for button 1, 4 for button 2, .... etc (2^n), and the pan view control number , which you can look up in the List of FS controls document, is 66416. For example, if the button is joystick 3, button 7 if logic.And(ipc.buttons(3), 128) ~= 0 then ipc.control(66416, ipcPARAM) end Save this in the FS Modules folder as, say, "panning.lua", then go to the Axis assignments tab, press the "reload" button to be sure that Lua file is recognised, and assign your axis P to "Lua panning". I doubt if it will be as smooth as it should be, because of this indirection. There might be a smoother way, by having a continually running plug-in and sending it the axis values via LuaValue, but that is a bit more complicated, try the above first. Regards Pete

They are values you can add to the axis assignments lines in the INI file and they are described in the Advanced Users manual. Regards Pete

Well, you were not successful in "toggling" the virtual button bits then! Don't forget that the detection for assignment purposes relies on the button state changing from "unpressed" (0) to "pressed" (1), not vice versa. Pete

Did you not look in the NGX Offset Mapping document (in your FSUIPC Documents folder)? Just search on "Land" for instance and you'll find the FltAlt and LandAlt values. And search on "Duct" to find the DuctPressure values. I supplied the offsets list for the NGX so you could find these things yourself. Regards Pete

Yes, if you want the PTT signal to be sent across the network. Otherwise you'd need to have the PTT operated at your Client PC. Without WideFS, FSUIPC doesn't know anything about Networks. Regards Pete

I don't know offhand without loading FS and adjusting a slope to be flatter in the centre then looking at the number shown. I can only suggest that if numbers are so important to you, that you do this yourself! I don't remember numbers as I don't think they are as important as the actual effect, the performance.. Regards Pete

Why do you want them to match? Most controller axes are a bit off centre, unless they have their own digital decoders. You have to view it as a proportion of the whole range. Some controllers only vary from -8000 to +9000 ir similar, in which case 1000 out of that is a fairly significant 6% of the range. If yours gives -16000 to +16000 or similar it is only 3%. But I'd be surprised if the dead centre position was exactly 0, so it wouldn't really make snse for the zone to be symmetric about 0. The whole point of calibration is to make the control operate optimally for YOUR specific unit. The actual numbers aren't relevant, they are just the record of what it measures art the points you want to delineate. Regards Pete

Well, since you didn't reply I checked this in both FS9 and FSX and found that you are wrong. The wind smoothing operates exactly as it should all the way up to 60000 feet at least. I din't bother to try higher. To test this I had to set a Wind in the Weather menu up to that altitude, of course. Maybe you simply hasve no high altitude winds set? There's absolutely no relationship between the wind smoothing parts of fSUIPC and the altitude in any case -- the wind layering set in FS is the only altitude component. FSUIPC simply works on whatever the ambient wind is at the aircraft. Pete

What do you mean "disable" the GPS? Stop it doing what, displaying things, or directing the course? The latter is a GPS/NAV switch, for which there is an FS control.("Toggle GPS drives NAV1".). You can send controls from a Luascript if you wish -- ipc.control. Or simply assign the control to a button or keypress. Regards Pete

"Tricky"? How odd, when really that is the only way to get what you want. Adjust and test, interactively. Setting the numbers, which are really meaningless on their own, seems a rather strange way to want to proceed. Yes, you can, but I fail to see why. Those are almost exactly the default settings, showing you've not actually followed the numbered calibration steps detailed in the user guide at all. Why not at least try doing what it says first? Also, you will see, in the calibration tabs a part called "Slopes". You may well find adjusting the response curve to be a better way than simply having a wide dead zone. Regards Pete

Sorry, I can't remember what sort of numbers they are offhand. I always thought the graphical display was clearer -- a flatter centre indicates less control response in that area. Just choose a suitable curve. You can easily try them in any case -- that's what it is all about. Set something and try it. If you flatten the central area the extremes have to be steeper in order to cover the same range. The two go hand in hand. You can't have one without the other. But again, what is wrong with trying things? Regards Pete

You can have one button or switch doing many things, either by simply making the additional assignments (in the INI file), or by using macros. If you have to have an offset changing you can use any of the user offsets from 66C0 to 66FF. Have you thought of simply wiring the door lights to the door switches, using double pole switches? Regards Pete

Er, sorry. Why are you "assuming"? You showed me your ipcReady lua file. So whay are you asking me what you did? sorry, i do not know HidMacros. You need to check their documentation and support. Do what? If your second keyboard is programmed to toggle (i.e. change) bits in the Virtual Buttons offsets, as I mentioned, then they would be detected in the FSUIPC Buttons & Switches tab, as buttone 0-31 on each of 9 joysticks, 64-72. That how there are 288 "virtual" buttons available. Sorry, I don't understand. Why are you bothering at all with the INI file? You seem to be pre-occupied with it. You should be concentrating on getting HidMacros to do what you want. If you do it correctly there should be no need to edit the INI file at all. It should be easily possible, but it is to HidMacros you need to look. See how to toggle bits in an FSUIPC offset. If it can only send values to a whole byte or word or something, then you can convert that to bit toggling in the virtual buttons area, in the way that parts of the pictures you posted earlier showed. Regards Pete