Pete Dowson

I don't think there are any controls or facilities outside of the overhead gauge itself for much of the overhead local functioning. If you are sticking to default aircraft in trying to implement full hardware cockpit controls I think you'll be continuously frustrated. They are not designed for it, and most of what you see is purely cosmetic. If you want decent 737 systems implemented you either need to use add-on aircraft such as the PMDG or iFly 737s, or use external systems simulations such as pmSystems from Project Magenta. Pete

That is a useful utility to experiment and see the values, but your sole reference should be the Offsets document. I suspect that is where you are going wrong! What interface are you using? Is it Paul Henty's DLL? If so you probably need help using it -- he supports it in the SubForum here so entitled. In C# is <int> an 8-bit unsigned BYTE value? Because if not there's the start of a lot of problems in the first place. Apart from 024A all those offsets are 8-bit unsigned values. And 024A is a 16-bit unsigned value (occupying 2 bytes). An "int" is usually a 32-bit signed value! (occupying 4 bytes). Where does the value 16777217 come from? What's the point of that? Byte values can't be larger than 255 in any case! Pete

Aha! I now see your problem: If you rename the main FS program then the files associated with FSUIPC must be renamed too -- the INI file and the LOG file and the KEY file. It is a VERY bad practice to rename the main FS file -- the Process name is then different, and many add-ons will be confused. Take a look in your P3D Modules folder, see how the FSUIPC4 log and INI files are named. The Key file must be similarly named. I'm afraid I cannot support installations with main process name changes. I hope simply renaming the Key file similarly will work for you, but I cannot do more. Pete

All FSUIP4 needs to be "registered" is the correct detail in the FSUIPC4.KEY file (which is a simple text file) placed in the Modules folder. Nothing else at all. You say you copied yours over from the FSX Modules folder, but evidently that's not true because the details would then appear in the log in the places highlit in the log here: Something else odd about this log. Look: That's the same date and time as the original log you posted BEFORE you say you copied FSUIPC4.KEY across. Please go and check the P3D modules folder. And please don't supply old logs dating before you changed anything! Pete

I'm afraid I've no idea what interface you are using into FS. I don't see anything there referring to any actual FSUIPC offsets. I can help you interpret offsets, but I've no idea what you are reading nor how, nor what that odd value "16777217" has to do with anything. The sim date and time offsets I would always use are the simple ones -- those from 0238 to 024A. If you need to see offsets correctly iterpreted, so that you can choose the right ones, please use FSInterrogate2, as supplied in the FSUIPC SDK. Pete

Please update to a supported version (4.929). You use it to provide parameters to those controls which use parameters, like all of those ending in "Set" which do set a value. If you don'ty understand the control you are assigning to, then either experiment with it to see what it does, or don't use it. They shouldn't be increasing by 10 when pressed singly. Are you perhaps assigning the same to both press and release? FS applies control acceleration when it sees them being used quickly. If it isn't that, maybe it's a bug in the add-on aircraft you are testing it with? and the same answers apply, though you shouldn't expect the altitude to be incrementing by 1 foot! Er, the controls listed for these things ARE the FS controls, same as assigned in FS. The CRS window is also known as the OBS or OBI. Check those controls. Same as in FS -- you start pushback and then press the 1 or 2 key. In FS the 1, 2, 3, 4 keys are assigned to "SELECT 1, 2, 3, 4.", so those are the controls you assign to. You might also get away with using 1 or 2 as the parameter for the Pushback control. I don't remember now if that works or not. For these sorts of questions, which are really about FS not FSUIPC, you can find out what things do by trying them, and you can find out what the true FS names are for controls you can already use, by mouse click or by key press, by using FSUIPC logging. Just enable Event logging n the Logging tab, then 'events' (controls being sent to FS's sim engine) are logged by both number and name. If you (temporarily) run FS in Windowed mode and enable the console log in FSUIPC's logging tab you can see the results in real time. Either it is a faulty lever or you have totally messed up the calibration. Did you actually calibrate BEFORE trying to use detentes? Why are you using detentes in any case -- does your lever have marked positions or real detentes? If not there's really no point, because you still need to guess the position to place it into. Just calibrate it like a throttle lever, etc. You oeration will be exactly the same. The detentes feature are for folks with custom made flaps levers with proper detentes. It's called the "User Guide", and the chapter on calibration has easy to follow numbered steps to good calibration. Most of your questions are really about FS not specifically FSUIPC. The controls you are concerned about are all FS controls and all FSUIPC does is expose them, using the names defined by FS in its CONTROLS.DLL module. The list is generated from FS, not predefined by me, and in fact i don't even know what they all do -- I suspect some do nothing and are just remnants from MS's earlier mistakes. Regards Pete

Yes. By ICAO of Wx Station, or by Lat/Lon. Yes. You didn't look? Wouldn't it be best addressed to them, in that case? I doubt they visit here. Pete

The key file would have been generated in the FSX Modules folder then copied over for P3D. I don't know why yours didn't get copied, but you can easily do it yourself -- just copy the FSUIPC4.KEY file from your FSX modules folder to your Prepar3D modules folder. BTW please, next time you have a problem, do not append it to a thread which is about an entirely different matter. It makes it much more awkward for others trying to search for solutions! Thank you. Pete

There are quite a lot of 32-bit floating point values in the interface, so I'm surprised that this "PYUIPC" program (which is new to me) hasn't encompassed those. The underlying Intel architecture supports both 32- and 64-bit floating point values directly, as do all of the Microsoft programming language family. Anyway, there is a 64-bit version (relating to the HSI) at offset 2F88. I guess that should be the same value if VOR1 is selected -- you may need to check offset 2FAA as well, though, for validity. If you don't need such accuracy (for instance, if it is only for display on a gauge) then the 8-bit (single byte) integer version at offset 0C48 should be used. Regards Pete

What is your question? I see none. If you need to write a program to interface to FSUIPC please download the FSUIPC SDK which contains all the information you need. Regards Pete

But what about button assignments in FSX? You say you deleted all axes, but you don't mention buttons. If you don't actually diable controllers completely in FS it will sometimes automatically reassign buttons as it sees fit, according to its references files for different devices. If that is all your FSUIPC button assignments then it mostr certainly is NOT dual assignment in FSUIPC. You must look at FS assignments, or just disable controllers in FSX! Give up if you like, but why not just remove the duplicate assignments in FS, or, better, disable controllers in FS? Pete

If the wrong axis is detected first, simply use the Ignore Axis option, and Rescan. Refer to the User Guide, page 41. It's all there -- about two paragraphs after the 2nd picture on that page! Pete

If you can assign in FSX, I don't understand what the problem is in FSUIPC's normal axis assignments tab. Can you explain please? Pete

Best then to use 0D0C for them all. Don't mix them. How are you wanting to program it? Through notmal button/switch assignment? Or via a Lua plug in? Or are you writing a program interfacing through the FSUIPC application interface? Also, please read the thread about bits and numbers in the FAQ subforum. You need to know about bits in bytes and AND and OR logical operations. Pete

If FSUIPC is not producing a run-time log, then it is not being run as that is the first thing it does. Earlier you said which is completely different to what you say now. Which is it? Pete

If buttons or switches have more than one effect it is because you have them assigned to do so. If they are not because of dual assignments in FSUIPC, then check FSX -- it is most likely that you still have them assigned there. I don't see how this is at all related to mouse macros specifically. It is just plain and simple double assignment. Regards Pete

What an odd question. I'm not sure how to answer. Is it working? if so it is there. If not we need to delve deeper. Why should that specifically have disappeared if FSX hasn't? Pete

Gradually? Pete

As Paul says, the Delta is set to 32767. The Delta is the value below which changes seen in the input will be ignored. It shouldn't normally be changed -- it's only normal purpose is to eliminate small scale jitter which has no bearing on the result but wastes a lot of processing time. Check that the input value ("In") varies correctly between some large negative number, like -16383, and a similar positive number, like +16383. If not, if the axis input changes directly between such numbers, then it is defined as a digital one, not analogue, in your driver. Pete

I'm afraid I need more information. Don't try "uploading" stuff here. All the information I'd need is textual -- just paste it into a message. Info needed: * Windows error information for the "fatal error" from the Windows event viewer. * FSUIPC4 log, as far as it went (from the FS Modules folder * List of other add-ons being used. Pete

No, sorry, I didn't know that. No, it cannot do that. Joystick scanning, like all USB stuff, allows multiple users and there's nothing FSUIPC can do, without hooking into Windows drivers, to prevent it reading axes itself. No. Best just to initially do axis assignments for your general case, in FSUIPC, non-specific, then add the Profile-specific needs afterwards. Pete

They are just text, so just paste them into a message. Note that if FSUIPC is actually generating a run-time log file (FSUIPC4.LOG), then it IS getting loaded and is running. You said: which I don't fully understand. What is "the same old routine"? I recall you saying: FSX freezes to the point that I have to cancel my FS session. How do you "cancel" it? What exactly is this "freeze"? A hang, or just a slow-down? And when, exactly, does it occur? For instqance, this suggestion of mne: should certainly have changed the timing of events. Pete

I didn't find anything much about Europe, though, which is where I fly. I used to use Jeppesen FlightMap on a PC, linked to FSUIPC's GPSout facility. Very nice, but too expensive to keep updated. I'd love to have the Jeppesen stuff on my iPad, but that's silly money, obviously aimed at airlines not to ordinary hobbyists. Regards Pete

No. It is one of the main advantages of purchasing FSUIPC. Sorry, I don't understand this question. Pete

FSUIPC uses a Windows interface for joysticks which only gives access to 32 buttons on up to 16 joysticks. This is stated clearly somewhere in the documentation. There are other ways of accessing more, but only via Lua plug-in methods. The expansion of the Windows facilities to allow up to 64 buttons per device was much later than the design of FSUIPC, and I really cannot justify the complex changes which would be needed to accommodate this in FSUIPC, not at this stage after 16 years. It would be too precarious. Sorry. Pete