Pete Dowson

It's one of the many bus in Version 3 of P3D I think. Please report it on the L-M forum. They are trims just like the more-used elevator trim, and used to offset small irredularities and asymmetries in thrust or surface movement. They can also help in crosswind takeoffs and landings to allow less side pressure to be used on pedals and airleons. Sorry, I don't really understand the questions here. What "raw" where? Pete

Sorry, but I cannot support old versions. Please first update to a supported version -- 4.947c is the earliest supported build. Incidentally your second crash is actually in SIM1.DLL, which is the main sim engine in FS. I would check the aircraft you are using is installed correctly. The first crash, the one in FSUIPC, would be useful data for me but only with the current version, so after installing 4.947c using the Installer, please update to 4.947d. Both are available in the Download Links subforum. Pete

Right. Good. I'm glad it isn't the worry I thought it might be. Hmm. Wonder why it has to be turned off for the hotkey to work correctly. Thanks for the information. Pete

If you press F8 yourself whilst P3Dv3 has the focus, instead of going via a button press and FSUIPC, does it work? I'm just downloading that utility -- seems it is shareware and I can test it without buying it. [LATER] Okay, installed it, changed its hotkey to F8, and it works both from an FSUIPC assigned F8 keypress and from the keyboard, both in P3Dv3 Windowed Mode and in its full screen mode. So something is different, either in your P3Dv3 setup or in Windows. That's a puzzle and a difficulty, because I cannot really help without being able to have it go wrong here. Anyway, if it doesn't work either when pressing F8 on the real keyboard then it obviously isn't anything specific to the FSUIPC assignment to a button, so you have real ground for reporting it to or asking advice from Lockheed-Martin. If it works direct from the keyboard then I'm stumped, because I cannot reproduce this. FSUIPC seds the keypress in a way which is supposed to emulate the keyboard, and there is certainly not something changed in FSUIPC. Pete

To find out if the helicopter control responds to an FS control, use FSUIPC's logging. Switch FS to Windowed mode and enable Event logging and the Console log in FSUIPC's logging tab. Then operate the switch in the FS cockpit display. If this invokes a standard FS control it will be logged, by name and number. Pete

It should. This sort of thing has already been reported in another thread. It looks like P3Dv3 is doing something different, but I don't know what. FSUIPC just sends the keypress in the same way regardless of the version of FS. I've just tested it in several ways and these are my findings: A program which uses the Windows Hotkey facility to detect keypresses and use them no matter what currently has the keyboard focus still gets those keystrokes even when P3Dv3 has the focus. So P3Dv3 isn't preventing such hotkey use. A program not using the Windows Hotkey facility will only receive the keypress if it is given the keyboard focus first (such as by clicking the mouse on it). I think this is the way it has always been, at least for hotkeys and normal keyboard focus changes. I am using Win7-64, so it's not a Windows version difference! So the question arises is "what is different about the program wanting the keypress". You said Now my screenshot program is "Screenhunter" from Wisdom-soft, and I normally use Ctrl+Function keys for its various options -- Ctrl+F4 for a full screen shot. I changed its assignment to F8 to match yours, and it worked fine. So I don't understand what differences are doing this. What it your screenshot program? If it is freeware maybe I can try it and see why it is different. I'd like to report it to L-M to see if they can fix it in P3Dv3, but without knowing why it isn't working for some programs only I wouldn't expect them to be able to do much. Pete

I don't remember the exact explanation for this, but It's to do with the way USB devices work, relative to an ordinary serial port device. The COM functions were designed for normal RS232 type connections (like my PFC equipment, and USB HID support added later. FSUIPC is effectively polling continuously for data, and most ordinary serial devices supply none unless there is some. But USB returns a packet every time, whether anything's changed or not. The readlast function was added to make things more efficient, rather than processing every single frame in a loop. You'd use your changed code for normal serial port devices.otherwise you could miss stuff. Why did you change a working program in any case? Pete

Sorry, it is not that your questions are not understandable, it is that I'm having difficulty actually seeing WHAT they are. If you could ask explicit questions which I might have a chance at answering I will do, and promptly. But I see only a mass of numbers which will somehow handle your very complex needs, and I don't understand what you need from me. You seem to know a lot more about your aircraft and what it needs, and i don't understand it. As far as FSUIPC, and myself, is concerned, an analogue axis is just a way of inputting a varying value into the simulator in order to make some analogue value, like the throttle or ailerons or elevator, etc, change. The main aim is surely that, with that axis or lever, you can make an effective change from minimum value to maximum value, with the ability to set it pretty much any place in between. That's what calibration does, and it is really all it does. If you want your axis inputs to do something else other than control something smoothly between its extreme values, then maybe you need to actualy write a program to do it. You might even be able to do it with a Lua plug-in. I might be able to advise more, but I need to understand what it is you want first, but I am getting more confused the more you "explain". If you could just extract some actual questions, specific questions, out of all those nmbers and so on, then maybe we could progress. Perhaps you could actually state the question to which you need answering in order to implement this function, whatever that might be. Yes, but a log file illustrating the problem. I saw no problem in all those lines. Maybe you should have pointed the problem out? What more control possibilities could a throttle control provide more than controlling the throttle? This is simply not clear to me. I have been using FS since it first began, back in Apple I days. I've been developing drivers and software for hardware related to flight simulation for 20 years, and currently have a full 737NG cockpit and also an analogue-instrumented Piper Arrow one too. But I've never seen any need for a throttle control more complex than one which offers a proper range and the ability to provide reverse thrust where applicable. Even on an Airbus, where the throttle control tends more to select thrust modes than direct throttle control, those modes are just points or areas on the full axis range which have been determined by the add-on aircraft designer, and which can be selected by normal axis movements. Whether your control is called a "HOTAS WARTHOG" or simply a joystick, it is just another input device which is seen by FS and FSUIPC alike as one or more analogue axis inputs and a set of buttons, all of which can be programmed in either FS or FSUIPC to deal with the functions offered by the aircraft you are using. I can answer questions on all that. Nothing specific to a Warthog or any other single joystick device, because they are all treated the same in FS and FSUIPC. The only way to deal with unique idiosyncracies of a device which are not axis or button oriented would be if you have or write special drivers which bypess that type of input. But then neither FSUIPC nor FS's assignment and calibration actions are involved. I'm afraid I am out most of tomorrow, so any further replies might be delayed till Friday. Pete

Yes, but the problem here is that it doesn't just say its a HID device, but a Joystick type HID device, which surely Arduino's aren't by default? They can be used in all sorts of ways. I have one driving some indicator lights and that doesn't seem to appear as a joystick at all. I installed it's software so I could program it, of course, but it just isn't appearing as a joystick at all. Same with most GoFlight units other than yoke and throttle quadrants. Pete

If FSUIPC is not logging an error after the Run entry in the Log, then as far as it is concerned the job is done. The command has gone to Windows and success result returned. If FSIServer then doesn't start it is because it decided it shouldn't. Maybe there's a error logged by it somewhere? Why don't you try only starting it when FS is ready for it to link up? It may just be that its attempts are clashing. there's a lot going on during FS initialisation. Try putting READY, before the "C:\FS ADDONS ...". BTW I just looked at my INI file. I have this collection: [Programs] RunIF1=CLOSE,"e:\steam\steamapps\common\fsx\Flight One Software\Ultimate Traffic 2\UT2Services.exe" RunIF2=CLOSE,"E:\mcp\pfcmcp.exe" RunIF3=CLOSE,"E:\FSX\Modules\SismoAft.exe" RunIF4=CLOSE,"D:\OpusFSI\FSISERVER.EXE" RunIF5=CLOSE,"E:\ProSimMCP\prosimMCP.exe" RunIF6=CLOSE,"E:\FSX\pmsounds\pmSounds.exe" RunIF7=KILL,"C:\Program Files (x86)\HiFi\ASNext_FSX\ASNext.exe" RunIF8=CLOSE,READY,"E:\ProSimAudio\ProsimAudio.exe" These all load successfully every time. I use RunIf rather than Run to stop them trying to load if there's a copy running already. I try to make them close too when I close FS -- that works with them all except ASN which I fond I need to KILL ruthlessly! Pete

I don't understand why you are posting all this data. What am I supposed to do with it? All it shows is axis values from your axis. So what? I can do that here with any axis. It is meaningless when there's no problem, as obviously there is not. Your axis is clearly working! It only shows it is working. Why you thought you'd need to post hundreds of lines is beyond me, sorry. Do you expect me to read them all? Why? Sorry, I still don't understand what help you need. There's no question here for me to answer! Pete

I'm not sure if it would be permanent, but it's removing the joystick stuff for it from the Registry. You could try uninstalling it via the Windows Device Manager. However, I think you'd also have to find the INF file for it too, and remove that, otherwise Windows ight simply install it again next time you boot. I assume when you connected the Arduino in the first place you ran some installation program? [LATER] Searching my Windows\inf folder I see Arduino mentioned in at least 3 inf files -- oem59, oen60 and oem61. Those cover a load of different devices so I wouldn't delete or fiddle with them. I think it's a matter of trying things. I don't really know enough about this side of things I'm afraid. You might have to stick with what works after all. Pete

Aha! That explains everything! In that case you don't really want it installed as a joystick as well as operating it via Lua. When the DirectInput polling function is being used the response is also recognised by the Lua plug-in. It cannot avoid it. Actually, it might be cleaner to assign the first 32 buttons as the CVP Joystick, and discard the first 32 buttons in the Lua. i.e. still start at offset 0x3340 as before but start with i = 2 when using the results, so: -- check for changes i = 2 Yes, but to FSUIPC it is 11. FSUIPC and DirectInput and the Registry all count from 0. Windows and FS add 1. No. it is only one device. And it wasn't listed in the FSUIPC4 log file you showed earlier either. Nevertheless it got identified as such and added to the FSUIPC4 INI file as #11. I think it's all down to Registry details vs DirectInput. At least you answered the puzzle which had me Royally confused! :smile: The "Product" is read differently for the FSUIPC scanning log. Currently, as you could see earlier, it includes: 1170 Product= 001 1170 Manufacturer= Arduino 1170 Vendor=03EB, Product=2043 (Version 0.3) 1170 Serial Number= C2 This is the same as the HidScanner results (because it is basically dong the same thing). If you look at all the other devices in the scan in the log, the "correct" product name is shown. The difference is that the [JoyNames] product description is obtained from the Registry, not via DirectInput. Until I recently added the scanning code (in 4.947), FSUIPC only used the Registry, and in fact it is only there you get the Windows ID number assigned. I'm not quite sure what you'd read via DirectInput to get the same Product String ... it should be there, I would have thought ... UNLESS it is just an installation descriptor, from the .INF file which is normally needed to enter the Registry stuff. Yes, I bet that's it! Pete

You are lucky that the mouse macro facilities work on that aircraft. They only work with gauges which are written strictly in accordance with Microsoft's original C/C++ Gauge SDK -- even most of FS's default gauges aren't susceptible. And many newer add-on aircraft have gauges written in XML, and usually the only method which works with those is finding the local panel variables (L_Vars) to read and write/ The macros in the Modules folder have assigned numbers in the [Macros] part of the FSUIPC4.INI file, the one with all your settings. The numbers are then used in the button or key assignments, in the [buttons] ad [Keys] sections. So if you delete macros and create new ones which thenget allocated the old numbers, all the assignments you made will either do something different, or not do anything at all. So by all means start afresh, but you'll need to delete the Keys and Buttons assignments too. Pete

You use assignments, same as in FSX. There's a tab for axis assignments and one for Buttons & Switches. The User Guide would help you. There are Chapters on these things, pictures too! ;-) Pete

If you are building a cockpit I think the choice of the model you use is the first thing to consider. Choose one which not only provides all the systems you need, but which can also be handled by your planned hardware. Most of the more sophisticated add-on aircraft have always been far from suitable for a full cockpit implementation. For 737's there is one which actually has a "Pro" version where the individual parts can be split off from the FSX PC and moved onto other PCs in a Network, with other screens for their displays and so on. that's the iFly. The PMDG 737NGX used to be almost impossible for external handling, but it is a lot better now with the SDK providing most if not quite all of the controls needed (via custom FS control numbers), and pretty much all the readouts for displays, indicators and switch positions. Probably the main difficulty though is the CDU, which probably needs to be a separate screen on the FS PC. But I think you'll find that all the best cockpit builds use simplified FS models, with no cockpit or gauges or subsystems,. For the 737NG the model might be a stripped down version of the FSX default 738, but not always. The systems and instrumentation is then driven by a separate software package. There are a few around, but the two most well known ones are Project Magenta and Prosim737. I've used both. PM started many yeas ago, well before FSX. Prosim is more recent. I changed from PM to Prosim last year, and it is excellent. Both these packages have their own 738 model, which you use instead of any other. The packages are not cheap, but compared to the cost of building a decent cockpit they are just a fraction. My cockpit has run into 6 figures over the years (and that's in £££ not $$$)! As well as Googling those packages, you might find this website illuminating. MyCockpit Good luck! Pete

Yes, Joystick 11, assigned as T. Phew! That's almost completely full! One more device and you've reached the FSUIPC/joyGetPosEx limit of 16 distinct joysticks! (There is no such limit in DirectInput, but FSUIPC was written long before that). So it MUST be something to do with the Arduino connection -- somehow it is activating and sending some copy data when the DirectInput polling request is sent to the #11 device. It's only picked up for the virtual button offsets when the Lua program is running to actually pick up that "echoed" data. It has to be either the Arduino itself, or possibly the hub. What's the physical arrangement like between the two device? Are they sharing a pair on the PCs' motherboard, or on the same hub? I think this is the area you need to investigate. It has to be in that area. There's no other way for what you describe to happen. You could try swapping some USB connections around. I wouldn't be surprised is the association then changed to one of the others. No. HIDScanner does not get the Joystick IDs, only the HID device details. The ID is in another part of the registry. JoyIDs shows all those and allows you to change them. I thought I put a link to JoyIDs where I told you, but I was mistaken. It's actually in the FAQ subforum, in this thread: Fixing joystick connections not seen by fsuipc BTW, can you look at the HidScanner log. Are the Vendor and Product IDs definitely different between your Arduino and the PVT Joystick? I would hope so, but you never know. I've not heard of P V T before. Maybe it's Arduino based? Pete

Okay, I asked my friend, Thomas, and he immediately found what I was looking for. It was staring right at me in the FAQ subforum! :???: See here: Windows 8.1 and USB device disconnections link: http://forum.simflight.com/topic/78887-windows-81-and-usb-device-disconnections/ Pete

I don't know how what you are describing could happen. if you unplug your joystick "T", does your other USB connection still provide input? If so it is being recognised in Windows as a normal joystick device and it seems to have been assigned the same joystick ID. Please look at the FSUIP4.LOG file. If you are using FSUIPC version 4.947c or later (i.e the current release) it will log the devices it scans initially. Also download the "JoyIDs" utility (see the additional useful programs thread in the Download Links subforum). When you run that it should show the IDs assigned to each device, and allow you to change them. You could try changing the ID of one or the other. I'm actually rather mystified by the ID your 'T' device seems to respond to in any case -- 11 is higher than any such assignment I've ever seen. They tend to be assigned in order, so it implies that at some time you had 10 other installed joystick devices. Or did you omit all the others in your earlier post? Of course. You'd simply use offset 0x3344 as the base instead of 0x3340. The only thing determining the virtual button number is its offset and bit position! However, I think you should resolve the problem first, if possible. Luckily there is room in the FSUIPC implementation for 9 x 32 buttons, not just the 8 x 32 you need. However, I think going this way and ignoring the strange thing which is happening is not correct. Pete

Well, I wouldn't say no to such a system, but then I spend most of my time here and developing software, so I am not the best judge. AVSIM is actually full or more appropriate and fruitful places to post such questions. Have a look there, eg the FSX/FSX-SE Forum. Pete

If it provides assignable facilities for all of its functions, yes. But I couldn't possibly know. Some add-on aircraft have parts which can only be operated by mouse. There's a range of ways things in add-on aircraft might be controlled. Hopefully most of the common ones are controlled with standard FS controls, just like default aircraft, but many, like PMDG and Aerosoft, add-ons do their own thing completely. Then all bets are off. FSUIPC does provide a range of possibilities, but unless someone else has already done all the ground work, you'd have to find out which method does the job, for each function, yourself. The range of facilities are: --Assignment to FS controls --Assignment to custom controls (like FS ones but in a different numerical range) --Writing to "L:Vars" (local panel variables), via macros or Lua plug-ins --Creation of "mouse macros", ways of getting FSUIPC to call code directly within gauges --Using short-cut keypress assignments kindly provided by the authors of the add-on Some add-on aircraft have needed combinations of several of these approaches. Have a scan though the User Contributions subforum to see. Functions which aren't implemented in the default aircraft at all don't usually have an FS control to operate them. There's a list of controls installed in your FSUIPC Documents folder. Search for keywords there first. It's quicker. You can also enable the Event logging in the FSUIPC Logging tab to find many of the control names. If you enable the Console Log option there, and run FS in Windowed mode, you'll be able to see controls being sent as you use them. Try with default aircraft first.. I must admit, i don't think there is a control for the gear horn cutout. If it is implemented in any of the default aircraft it may be local to the gauge itself. You are using Wilco though, not PMDG? I don't list any PMDG specific "custom controls". The offset list I provide are all read-outs. None are controls. You can't write to them. All of the PMDG custom controls are listed in their own SDK and I'm sure it includes the gear horn cutout. I think FS only has 4 electrical fuel pumps -- controls "Toggle elect fuel pumpN" (N = 1 to 4). I doubt that any add-on of any note would use those though. That assumption can prove to be false in many cases, unfortunately. Many implementations seem to be mouse onl, at least in party. Some designers simply don't think about cockpit builders. You might want to look at LINDA, an add-on for FSUIPC (written by others) which can make all this stuff a lot easier, or so I'm led to believe! ;-) Pete

Well that used to work okay in Win7 and but it seems it isn't enough in Win8. I don't know about Win10, but that may be the same. I'm afraid I don't know enough about Win8 /10 to help further directly, but I think there is someething else you can do to stop joystick devices getting "turned off". Maybe a Google search will find it. It has probably been posted here somewhere, but the search for such a mention is pretty well impossibble to frame and i've not managed. No, there's absolutely no difference in this area between any of the 4 versions of FSX, and FSX-SE, or any version of FSUIPC for that matter. It's all standard Windows "DirectInput" programming, standard calls into standard software. It's something to do with Win8 /10 and I think there's a way to fix it. I just don't know what it is. I'll ask someone who I think knows about this ... Pete

The part which I quoted and said explicitly makes no sense to me! For the rest I need more information. Seems you have not read it properly, if at all. Please read my answer again. The part which made no sense to me is mentioned, all I asked was for you to clarify it. The rest is trying ot get more information. If you don't want to explain, and don't want to provide more information, there is no way at all for me to help. Can't you understand that? I do my utmost to help all who come here, but helping some folks is like trying to draw blood from a stone. Some threads are inordinately long simply because getting information from folks is sometimes extremely difficult. Hopefully you are not one of those, but there's no more information in your second post than there was in your first. :-( Pete

Yes, you've emphasised that before. But I cannot believe you are stupid because you are talking about things in your message which baffle me they are so complex. If you want to learn more about using FSUIPC first, why not start with something simpler? Good. That is standard and correct, and contradicts what you plainly said earlier, that it only had 16384 (minimum) to 0! Sorry,no. Please do NOT post pics, and there is no way I need or want to know about specific devices. FSUIPC has to cope with the same types of devices which FS itself can. It can assign and calibrate them for you in more ways than FS, but it cannot know about individual devices. If you want something completely exotic you would need to get into programming. What from? It is meaningless to me, as I said before! Why do you insist on posting a load of meaningless numbers? Pete

I think so, but only using the FS "Axis Throttle" control assignments, and with no FSUIPC calibration. Pete