Pete Dowson

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

The virtual button range can only be set by software designed to set the bits in those offsets. Any regularly recognised joystick device will be seen by FSUIPC and is assignable, but can only have the joystick numbers 0-15. These are the IDs assigned normally by Windows and found in the Registry. There's no way such a device can also appear in the virtual joystick range unless there's some driver or other software (like your Lua plug-in) actually writing to the offsets for those virtual buttons. In the case you are citing, the C.V.P. Joydtick had the ID 11. That's why you have "11=C.V.P Joystick". Because it has been assigned the letter T it will appear in the FSUIPC option tabs as Joystick T. T and 64 are absolutely distinct as far as FSUIPC are concerned. One is a DirectInput device, the other merely a set of bits in an offset. You have something else going on. There's no way anything in FSUIPC can invent an input on a regular joystick which it is reading in the usual way via DirectInput. So the CVT joystick button inputs to the PC itself are being triggered by your other device. I can't really speculate further than that. All I can say that this is all happening outside of FSUIPC, and probably outside of Windows too. It would be a driver or a hardware or a hub problem. Pete

Well, there's nothing there I can see which could possibly affect mouse operations. This worried me though: You appear to have gone through virtually all the Calibration pages clicking the "Set" button. So FSUIPC is trying to process every single analogue control which it can possibly calibrate, even though there is no way you have that many axes assigned or even installed. All of them, even the ones you are using, have default values, so even though you've done this you've not actually tried to calibrate. I suggest that, as a start, you delete all those lines above before loading FS. THEN, for the axes you do have assigned (probably aileron, elevator, rudder and throttle) go back into the Calibration tab, and calibrate them properly (there are numbered steps in the FSUIPC User Guide). [LATER] Just for clarification, assuming you have disabled controllers in P3D as you should when assigning in FSUIPC, you have these assignments: 0=0X,256,D,1,0,0,0 Ailerons (direct to FSUIPC) 1=0Y,256,F,65694,0,0,0 Elevator (via P3D) 2=0S,256,D,4,0,0,0 Throttle (direct to FSUIPC) 3=1X,256,F,66387,0,0,0 Left Brake (through P3D) 4=1Y,256,F,66388,0,0,0 Right Brake (through P3D) 5=1R,256,F,65696,0,0,0 Rudder (through P3D) Oddly you have chosen the old FS98-compatible FS controls for Elevator and Rudder, but the modern AXIS_ controls, the same ones FSX and P3D use, for the left and right brakes. Really you'd be better off being consistent. Either use "direct to FSUIPC calibration" controls for all of them, or "AXIS ..." FS controls for all of them. Pete

Where are you seeing those values, please? I don't know of any normal joystick type device which behaves like that, at least not after proper setting up in Windows. Have you checked that it is set up and calibrated in Windows? Please show me the Logfile then, so I can see. I don't know what all this stuff is below. It looks like it is out of any context. Can you explain? Then this, which is even more puzzling: This makes no sense. If the throttle is only providing positive values, as you stated above, WHY do you think you need to do more to make it give only positive values? Don't you see, you aren't making any sense? This is all to do with internal FS values, it is nothnig at all to do with joystick inputs or calibration. A normal single throttle input to FS runs from -16384 (idle) to +16383 (full thrust), so your 32% would be around -5898 from the throttle axis. That's if you assign to the normal throttle axis control, whether in FS or in FSUIPC (makes no difference). The positions of various detentes on your throttle range would have to be determined and marked after you have the main full range working. You are using an analogue input with values which change as you move the lever. You would need to find the positions which give you the values you appear to "require" (which I don't understand, incidentally).. It you want the lever to act more like a multi-way selector, without worrying about increasing or decreasing values, you can use the Right-Hand side of the axis assignment tab instead of the left. Don't assign to the normal throttle axis, but assign specific positions to "ThrottleN_Set" controls with the parameter set to the precise value you seem to think you need. The N is the engine number. The ThrottleN_Set controls do run from 0-16383, so your percentage points will be okay for such controls. Pete

Excellent! That was easy, then! ;-) Thanks for reporting back. Pete

No, sorry. I can't see any useful data from here. In your position I would be using a USB monitoring program to log the actual data being received at the PC, and trying ot work out what that looks like to the Lua HID functions, and compare the results to those logged by the Trace/Debug facility in Lua. Haven't you tried debugging the Lua using the facilities available to you? That would be the first step. If you add: Debug=Please LogExtras=x200 to the [General] section of the FSUIPC4.INI file before running FS you will get a lot more logging regarding what the HID code for Lua is doing. On the hardware/firmware side, for USB devices I use the "Device Monitoring Studio" USB package by HHD. There is a free (limited) version If you do find anything which you think may be due to something wrong in FSUIPC do let me know. I've never had any opportunity to test with anything more than PFC, GoFlight, Saitek, and Leo Bodnar boards. Never anything with 256 button capabilities! Pete

This means they are not assigned! The calibration tab (which must be what you mean by "controllers tab"), only provides calibration for axes already properly assigned to the function you want to use them for. That is performed in the axes tab (or, for anything other than the current P3Dv3) in the sim).! Of course. That's what you should have done anyway. But if, in FSX, you had the control axes assigned in FSX, not in FSUIPC, that still won't work, because P3Dv3 currently has serious faults with its assignments. PLEASE please do read the pinned thread at the top of this Forum about this very subject! Pete

Sorry, I don't know what the number associated with "Stackhash_" is intended to convey. You can of course use FSUIPC Monitoring to monitor the rudder trim value. 0C04 as type S16, or more accurately 2EC0 at type FLT64. The latter is the actual trim angle in radians. And you could try stopping whatever it is which is trying to change the rudder trim. Normally rudder trip is kept perfectly centred or neutral. Pete