Pete Dowson

There's no demo. Please just read the User Guide to decide whether you want the user facilities. You can install it in any case, it will service applications without your purchase. Regards Pete

You don't need to keep downloading. Just download once, and read the installation instructions. The download contains the Installer. Run it as instructed. Don't forget to download the correct version -- FSUIPC4 for FSX. The current installer installs version 4.80. If you need any other help, please state version of FS, version of FSUIPC, and find the FSUIPC log file in the FS modules folder and show me that. If you have an installation problem show me the Install log, in the same folder. Regards Pete

Ah, sorry! I didn't notice the author was changed. No wonder I was confused -- you already solved the problem! Thanks! I take it, then, that its condition lever doesn't use an axis such as Mixxture. Regards Pete

Good, glad it was that easy. I don't actually understand how wonky signals from that switch, no matter how bad, could be interpreted as something so completely different. Weird. But I'm not a hardware desgner, only a software one. Regards Pete

You misunderstand. FSUIPC isn't "causing" any problems, it is suffering from problems on your system. There's something wrong with your Windows installation. Try running the Windows DirectX update: Microsoft DirectX download page. Maybe that will repair the error. Regards Pete

Not really. I'm lost. what am I supposed to deduce from what you posted? Does the condition lever use axis inputs or not? That's the main question, but from what you've posted I can only assume that you don't have a problem any more? That you've solved it? Pete

I think "Conditon" levers are usually controlled by the Mixture axes in FS. What have you been trying to assign? Mouse macros aren't normally applicable to axes, only to buttons and switches, and then only if the panel is made using the FS9-style Microsoft gauge SDK. You need to determine what controls the condition levers in the first place. I assume they are not programmed in that aircraft for mouse use only -- that would be very short-sighted of the developer. If there are no instructions with the aircraft telling you what to use, try enabling FSUIPC's event logging 9axis and non-axis events), then operate the levers and check the Log file to see what it used. If you put FSX into Windowed mode and enable the console log in FSUIPC's logging tab you'll be able to see the effects in real time. Regards Pete

Yes, I remember that the yoke buttons are encoded using a CH type controller, representing up to 15 different buttons by 4 bits (0-15, one reserved for "released"). That's why you can't press more than one at a time -- you only get one encoding. But the 86 xx values are axis values -- from the toe brakes, as you say. Sounds like something going wrong inside your unit. I don't even see how external wiring or anything other than something on the controller board could generate incorrect but elsewhere valid numbers. No, obviously not -- you proved that to yourself by using their test program, haven't you? It's a faulty something, but I doubt if it is as simple as the switch itself. I don't see how simple on-off actions on a switch can make the controller generate the wrong codes entirely. I'm afraid you need to contact PFC. I think I might have that somewhere around. Not realy dealt much with the PFC serial innards for a while, even though my cockpit is mostly based on that technology (the PFC 737NG, see pix on their website). It's partly new USB HID as well, so I have to run both PFCFSX.DLL and PFCHID.DLL. Regards Pete

Not sure how your post ended up with miniscule typefacing and triple spaced lines. What are you using to view and copy/paste ordinary text files? Try Notepad next time if you don't have any other ordinary text editor. The problem is there, the failure of FSUIPC to even get DirectInput open for business. It isn't going to see any possible Joystick devices. You device is correctly entered into the Registry as device ID 0, but FSUIPC cannot read it because of that serious Windows problem. I've never seen this error occur before in this context, but it does signify a Windows error I'm afraid. It is probably some sort of screw-up between the Registry and the WinSxS (side-by-side) library system. The only other times I've seen that error number (80004005) is was when folks had tried uninstalling and reinstalling FSX and getting the SimConnect stuff messed up. I suspect that some Windows 7 installation or update has gone awry in some way. Try a Windows repair, or just try to make sure your installation is fully up to date. Regards Pete

Sounds like you omitted the first line: 3=P2,2,C1005,3840 ;Using Joy15, flag 0 for tthis, not associated with a real button[/CODE] That toggles 15,0 (15 x 256 + 0 = 3840).when you press your button. The whole point of using the flag for a non-existent button is precisely to avoid that flag being toggled just because you pressed its button! Things would become somewhat unpredictable if you were toggling or switching the same flag both with the FSUIPC controls for this (1003,1004,1005) and the button itself with its automatic flag toggle action. Using the automatic toggle would work provided the button action was something innocuous. However, it is cleaner to have the button just toggle a flag independently, for testing in the other lines. The self-toggling of the button's own flag was implemented in order to allow momentary buttons to be programmed like toggle buttons -- i.e. with their own action depending on their own flag, which is toggled for the next press without another button or action being involved. It only does if the button is scanned. If it is not assigned it isn't scanned and therefore its flag won't toggle. That's why I'm using a flag for a different, unused button. Try using my earlier solution including the line you seem to have missed. It is likely to be far tidier than having to use 'n' keypresses and is much more easily transferred to other applications. BTW, I'm a little surpised that you didn't follow through on my original pointer to other thread here on a similar subject. If you had you'd have seen my solution to the problem there also involved using button 15,0. here it is again: See that line, there at the end, toggling 15,0 on the press of the relevant button in that case? It was because of the direct similarity in needs that i referred you to that thread in the first place. Regards Pete

The last in the list is also the first. HidScanner recorded it being removed and then reconnected. Look: First: Device at "\\?\hid#vid_0425&pid_69ff#6&1d133dee&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=0425, Product=69FF (Version 0.145) Manufacturer= Cockpitsonic_UK Product= Insim_8000_FF At end: 379924: Device change detected ... ***** This device has been removed: Device at "\\?\HID#VID_0425&PID_69FF#6&1d133dee&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" 386118: Device change detected ... Then: A device has been attached! Device at "\\?\HID#VID_0425&PID_69FF#6&1d133dee&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=0425, Product=69FF (Version 0.145) Manufacturer= Cockpitsonic_UK Product= Insim_8000_FF Did you remove and reconnect it? If not maybe this is one possible reason FSUIPC doesn't see it -- if it isn't connected when it scans. Otherwise it looks okay, with 48 buttons (or which FSUIPC can only see the first 32), and the maximum of 8 axes/sliders, of which FSUIPC4 should see all but FSUIPC3 only 6. Buttons range 1 -> 48 at indices 0 -> 47 Value Y at index 48, range 0 -> 1023, using 16 bits Value X at index 49, range 0 -> 1023, using 16 bits Value Rdr at index 50, range 0 -> 1023, using 16 bits Value Thr at index 51, range 0 -> 1023, using 16 bits Value Z at index 52, range 0 -> 1023, using 16 bits Value Sldr at index 53, range 0 -> 1023, using 16 bits Value V/RY at index 54, range 0 -> 1023, using 16 bits Value U/RX at index 55, range 0 -> 1023, using 16 bits Are the buttons you've connected within the first 32, do you think? Please add this to the [General] section of the FSUIPC4.INI file, then run FSX with your device properly connected. You don't need to do anything in FSX, just close it down and show me the FSUIPC4.LOG file please. Debug=Please LogExtras=x200000 Regards Pete

Yes, of course. and vice versa, 088C reflects the throttle position. That is exactly what it is for. Unless you replace the throttles gauge with your own version which does that you cannot do it, because the FS throttle position is represented by the value in 088C. that is exactly what 088C is: the throttle position! They are one and the same thing. the gauge is simply doing what it is told by its code. Why on Earth would you want FS to lie to you about its throttle position? I don't understand. Regards Pete

So why are you multiplying by some (undefined here) variables? Are the values that far out if simply calibrated by your software? For forward thrust the range of the hardware should be mapped to 0 to 16383. If the throttle lever on screen includes reverse thrust, then the lowest value depends on the aircraft config file -- a max reverse thrust is defined there. eg. 25% would equate to a minimum value of -4096. If you sent your axis values to FSUIPC for assignment and calibration, you can use the "sync pos" facilities in the calibration section to make the two equate as closely as you liked. Otherwise I assume you are trying to derive a formula for your variables f1 and f2 which is really only determinable by measurement of the output of your hardware at a number of positions. A table lookup might be more appropriate unless the output is reasonably linear or predictably logarithmic (depends on how it is built of course). The "sync pos" facilities in FSUIPC's calibration use table look up and linear interpolation between set points. Regards Pete

How do you work that out? All I'm saying is that I don't understand how what you've done works at all, and deduced that this must be because I don't know enough about your setup. How has this angered you so? I don't understand where you are coming from. But if you are going to react so, I won't bother any more. Bye. Pete

Really? I thought Wilco products were alwas fully amenable to hardware assignments. I must have thought wrong I guess. :-( You can program that to send keypresses as well as FS controls if you are using FSUIPC for it. Ah, that's what i must be thinking of. Really? You can assign them in FSUIPC once FSUIPC recognises the device, as it will do with the correct set up. Anyway, I don't have time at this very moment to develop a mouse library for Lua, but I'll put it on the list. See also the thread near here about mouse look. Regards Pete

Yes, of course, if i program it to do so. Please refer to my previous reply. It seems there's a growing list of Mouse users requesting mouse facilities. i'll put them altogether and implement somerthing when i get time to do so. Regards Pete

What other ideas do you need? You seem to have laid down the ideas you want. What's the problem? Just implement it as you state. What language are you using? You could do it all easily with a small Lua plug-in, but it sounds as if you are implementing an external program. Either would work. BUT, I'm not understanding the distinction between "visual" and actual throttle position. The visual graphic on screen? That follows the offsets you propose writing to, which are also the actual positions. Why the distinction? Regards Pete

If you use EZCA, why do you need this? And what needs a quck fix? Either way, it seems there's now a flood of mouse requests. That's a non-centering option, a complete Mouse API in Lua and now a different way of enabling mouse look. All in one day. I think I should hold off on any changes until the flood of mouse requests has dried up and then try and sort them out in one great effort. Sorry, Kosta. Doesn't look like next week after all. :sad: Pete

I've left the current mouse Look in FSUIPC4 as it is. for the functionality you want you'll have three new FSUIPC-added controls in the drop-downs: mouselook on mouselook off mouselook toggle They operate entirely independently of the FSX mouselook and so can keep track of the view position. You'd need to assign the space bar (or whatever) in FSUIPC to press=mouselook on, release=mouselook off, no repeats (though they shouldn't matter as they'd only repeat the "on" to no effect). This will be in the next FSUIPC4 incremental release, maybe over the weekend or else early next week. [LATER] Released, including middle button hold operation, today, Monday 27th Feb. FSUIPC 4.802, in the Download Links subforum. Regards Pete

Seems, then, that your rotary sends "button press" when you turn it one way, and "button up" when you turn it the other way. I've never heard of any rotary that does such a thing. All the ones i've ever heard of send alternately button down and button up, a continuous toggling. In fact unless both directions does sent a button down and button up alternating I don't see how anything can ever recognise another button down or up -- it will look stuck down one way and stuck up the othjer. You need them alternating to detect them. Sorry, but what you suggest simply doesn't make any sense at all. But that button doesn't need to toggle between those selections. All it needs to do is change the Flag which is being tested so that the rotary inputs affect either Whole or Fract parts -- the difference in what is changing in FS does not depend on the "n" or "nn" at all -- the determination whether it is Whole or Fract parts is entirely included in the controls you are making it send. else why do you think there are separate controls for Whole and Fract? If you needed to preselect which part to change, what on Earth do you think is the point of having different controls for the different parts is? It would make a nonsense of the whole thing. Many implementations using the controls you are using here have been constructed and are in use successfully every day, including in my own cockpit. I feel there is something you are completely misunderstanding, and evidently something else you not telling me. Okay, I'll leave you to it. It's just overcomplex and illogical, but evidently there are things about your hardware I don't know about. Bye Pete

I've a feeling that it's going to need a complete new facility to do it the way you want. One not using the FS "mouse look" control at all. Looking at the code I see the original reason why I made it reset to view on each mouse look operation.. Even if you disable the FSX mouse look (i.e. by disabling controllers), the control still starts by positioning the cross-hair cursor -- it puts it in the last place you left it and moves the view there. This is presumably the way you want it to work in FSUIPC. My code does not in fact even need to move the cursor and view to the reset default position (the "eyepoint"). Even if I remove that code, this action is still being done by FS as soon as it sees the Mouse Look control, and before I am able to then watch the mouse move. And, of course, because you aren't using FSX's mouse look, its remembered position remains at that default position. What I'd need to do to make it work the way you want it is either to try to hook the mouse look control BEFORE FSX sees it, or use a different FSUIPC-added control altogether. The latter might be better (as well as easier to implement), because then you can have it either way by just assigning differently. Either way I'd have to keep my own memory of where the last panned position was so I can restore it. That's the easy part. ;-) Regards Pete

Well here's what I don't understand out of what you are doing: 3=P2,2,K78,8 2,2 turns on the "n" actually depending on speed of presses/hold, toggles between n and nn - so okay * Why are you sendng 'n's in any case? The INC and DEC controls you are using determine the specific value being changed, you don't have to have focus on them. In fact the relevant gauge need not even be on screen. All you should need to do with that button it toggle a flag, i.e. 3=P2,2,C1005,3840 ;Using Joy15, flag 0 for tthis, not associated with a real button Then, all these make no sense ot me at all. 4=CP(F-2,2)0,2,C65642,0,C1003,514: conditional press on and this checks flag of 2,2 is clear. 0,2 = Nav1 Frac Dec and sets flag of 2,2 To start with the excess parameters at the end (C1003,514 etc) are ignored -- there's only one control or keypress assignable to each button in one line. you need multiple lines for multiple assignments. It's only Axes which can have up to 4 assignments in one line. Then you have a coupe acting on the Press ("P") and a couple on the Release ("U"). Why? Why not all on Press or all on release or on both? What are you trying to achieve by such differences? I think you either need: 4=CP(F-15,0)0,2,C65642,0 :Nav1 Frac Dec 5=CP(F-15,0)0,3,C65643,0 :Nav1 Frac Inc 6=CP(F+15,0)0,2,C65640,0 ;Nav1 Whole Dec 7=CP(F+15,0)0,3,C65641,0 ;Nav1 Whole Inc or, for changes on press and release (every click?) 4=CP(F-15,0)0,2,C65642,0 :Nav1 Frac Dec 5=CP(F-15,0)0,3,C65643,0 :Nav1 Frac Inc 6=CP(F+15,0)0,2,C65640,0 ;Nav1 Whole Dec 7=CP(F+15,0)0,3,C65641,0 ;Nav1 Whole Inc 8=CU(F-15,0)0,2,C65642,0 :Nav1 Frac Dec 9=CU(F-15,0)0,3,C65643,0 :Nav1 Frac Inc 10=CU(F+15,0)0,2,C65640,0 ;Nav1 Whole Dec 11=CU(F+15,0)0,3,C65641,0 ;Nav1 Whole Inc Again the confusion with the keyboard and focus. In the above the FS controls you are using are the NAV1 ones. There are NAV2 ones, and COM1 and COM2 and ADF. You don't need to mess with keypresses and focus. Regards Pete

It makes the throttle axis value offsets being read by some of these add-ons use the wrong range (-16384 to +16383 instead of 0 to +16383 as documented), as, because of some bugs, it did until a few releases ago. The problem was that the programmers used these offsets, found they were wrong (not as documented), but no one bothered to tell me until a few months ago -- at which time i promptly fixed it. Only if you use an add-on which expects those offsets to read correctly as documented. Regards Pete

You posted your support query into the User Contributions subforum. I've moved it here, to the Support Forum, for an answer. No. What would you use it for? You'd need to be able to move the mouse pointer to the correct place for a click to be of any use in any case, and where, exactly is "the right place" going to be? There is a program called "Key2Mouse" which allows you to assign mouse moves and clicks to keypresses. But really, these days, this sort of thing is not often a lot of use. What about normal FS controls or assigned keypresses in the add-on? Are these functions the ones only operated by mouse, static -- always in the exact same place on screen? If not how would it work? If so, you could use Key2Mouse. I could consider adding a mouse manipulation library to the Lua support but I would like good reasons and practical applications to make it worthwhile, and it is not easy to think of many. Regards Pete

It would centre (i.e. "start from a known position") each time you engaged a fresh "mouse look" action. How do you stop a keyboard key from repeating? I can understand with a joystick button, but not a keypress. Yes, exactly right, except I think it doesn't "pan", just resets. Mousepad? Hmm. Not used one in years! :-). They've not been needed since mice went optical. Used to be essential with mouse balls. It just restores to a known position so you can do a mouse look knowing where you are going. That's the whole point. Maybe you are 100% familiar with your cockpit and know immediately where you are looking all the time, but I find it far easier to get to look at a specific switch or dial if I start from the normal flight view. Furthermore, when flying it is quite often necessary to quickly look back ahead after making some adjustment elsewhere, so a fast way of getting the normal view and perspective is essential. I don't understand how you'd manage so well without that asction. See above. Retores? Restores from what? I'll look to see if I can add an INI option especially for you. Probably not for a few days though. I'm in the middle of a bigger problem. Regards Pete