Pete Dowson

That's a sign either of very bad equipment, or more likely multiple conflicting assignments. You could also try just using FS9 assignments first, because if you can't get that far there's really no point going further. The User Manual for FSUIPC is always the best place. Try that. Additionally you should be using the currently supported version of FSUIPC for FS9 -- 3.999z8. Regards Pete

Well, to start with you have conflicting assignments: [Axes.Twin engine piston aircraft] 0=0X,256,D,7,0,0,0 Left brake 1=0Y,256,D,8,0,0,0 right brake 2=0Z,256,D,14,0,0,0 Mixture 2 3=0R,256,F,65696,0,0,0 Rudder Set 4=1X,33,F,65695,0,0,0 Aileron Set 5=1Y,1,F,65694,0,0,0 Elevator Set 6=1Z,256,D,4,0,0,0 Throttle 7=1U,256,D,5,0,0,0 Prop Pitch 8=1V,256,D,6,0,0,0 Mixture 9=1P,0,F,66416,0,0,0 Pan view 10=2X,256,F,65820,0,0,0 Throttle1 Set 11=2Y,256,F,65821,0,0,0 Throttle 2 Set 12=2Z,256,D,17,0,0,0 Proppitch1 13=2R,256,F,65764,0,0,0 Axis Rudder Set 14=3X,256,F,65924,0,0,0 PropPitch2 Set 15=3Y,256,F,65919,0,0,0 Mixture1 Set 16=3Z,1,D,14,0,0,0 Mixture 2 You have 4 Mixture assignments -- a generic one controlling all engines, two direct ones for engine 2 and an indirect one (i.e. FS control) for engine 1. So both mixture settings will be affected by 2 axes each! Similarly for PropPitch and Throttle. Also worrying are two different assignment methods for Rudder. That would give problems too. When you say "the mixture goes from -16380 to 0 and no further" that makes no sense in any case. Where are you seeing this, in assignments or in calibration? I think before you go any further you need to sort out the mish mash of axis assignments. Maybe delete them all and start again, mught be easier that way. Pete

Reverse is just coded as negative thrust settings, so is controlled by Throttle controls. Pete

Not so strange if the cause is in the hardware or USB drivers someplace. When you say you see it in FSUIPC, do you mean the Axis assignments tab, or in the Calibration? If in the axis assignments, then the cause has to be low level -- hardware or drivers. Since you've eliminated the problem with the pedals themselves then it must be further towards the PC. If you are using a USB hub, try plugging them into a PC USB socket directly. Either way, the fact that it seems okay for some time then starts playing up suggests something to to with temperature or voltage. Whether that's down to the supply voltage, the power supply on the PC, or motherboard problems would be difficvult to determine. If the symptoms are not seen in the assignments tab but only in the calibration tab then it is interference from other assignments or other applications. But then it's odd that it takes time to develop. Pete

I don't have any PMDG aircraft, but there's been a lot written about solutions. Do a bit of research here or over in PMDG's own forum. I can't really help directly except to explain anything about FSUIPC you don't understand. I'm sure most PMDG users have sorted the throttles out, though some say you can't calibrate in FSUIPC, some say you can but you need to set "UseAxisControlsForNRZ=Yes" in the FSUIPC4.INI file. You do, of course, need to set the No Reverse Zone option in the calibration page. Assuming there's nothing wrong with your hardware, jumping axes are a pretty sure sign of conflicting assignments. You've probably got axes assigned in both FS and FSUIPC. Choose one or the other. I think you simply assign the buttons to "throttle decr", repeating. That's the same as using the F2 key, but there are separate throttle controls - throttle1_decr, etc. "My program" is not specifically made for either axes or buttons, and especially not for a "potmeter"!! For button controlled flaps just use flaps inc and flaps dec controls, same as on the keyboard. Real easy. No one's ever had trouble with that before. Using an axis for flaps is normally only done by cockpit builders, because you need notches. With FSUIIPC you can assign to a vast range of controls. Why aren't you even looking at the Buttons and Switches tab? Not everything is an axis ("potmeter")! Pete

Oops! I wonder how that file dropped out? It certainly used to be there. I've put it back again now. Please re-download the Lua package from the Lua thread in the Download Links subforum. Pete

Not sure why it upsets PMDG aircraft to modify the slope if you calibrate. Are you saying you don't calibrate the brakes? Have you tried assigning "direct to FSUIPC calibration" instead of to the FS axes? Otherwise the only thing you can do really is to fiddle with the original axis value using the adding/multiplying factors you can apply in the [Axes] section of the INI file -- see the Advanced Users manual. You can't really set a null zone that way, though, and if you divide the axis value then you may not be able to reach max braking. Pete

Assign the axis to both left and right brakes instead of only one. In FSUIPC you can assign any axis to up to 4 actions. The results of multiple assignments for one axis are indistinguishable to anything else from results from separate axes. Pete

Key press repeats are controlled by either the keyboard BIOS or low level parts of Windows and the rate is pre-set there. Key presses sent artificially by another program are not processed like that, they go nowhere near any hardware driver. The only way you'd get repeated actions is if the software detecting the keypress did its own repetition until it sees the KEY UP event. All that is happening with your keypress is that it is being converted by FS default assignments into the same controls you could have assigned directly. It saves you nothing at all, but bypasses the repeat facilities built into FSUIPC. If I tried to implement keypress repeat it would still act at the same rate as the control/button repeat. The proper way to deal with this is to adjust the repeat rate. I've investigated this after I mentioned the PollInterval parameter earlier, and see that it currently isn't adjustable using that facility, but is currently fixed at 100 mSecs (giving a rate of a bit over 10 repeats per second. If you wish I can make that parameter user-definable, like the poll interval. This is easy enough for me to do -- it's just that no one has needed or asked for such before. If I do it I'll pobably make it an [Axes] section parameter, so it can be different for different profiles, and it will be expressed, like the ButtonRepeat parameter, in terms of repeats per second (default 10). I'll only do this for FSUIPC4 (i.e. for FSX and P3D). Look out for version 4.921 later today. The parameter will be called RangeRepeatRate with a default of 10. Note that the actual repeat rates will general be a little different, depending on FS loading because all this is in the same thread as the main FS simulations. But setting sy 20 will be twice as fast as setting 10. The range will be 1 - 100. Regards Pete

No offence. Sorry if you thought so from my joking reply (couldn't resist referring to Linda as a "she" for obvious reasons ;-) ). And, yes, of course Linda and FSUIPC are "connected" in that it (she) uses FSUIPC for everything. It's just that I have not been at all involved in Linda's development and nor am I a Linda user, so I'm unable to help. I just seem to recall that Linda deals with buttons and switches and not so much, if at all, with axes. but I can't give a definitive answer, hence my referring you to the right place for such questions.. Okay? There are a great many applications out there using FSUIPC and I cannot profess to know about all of them. Sorry. Pete

Two points: 3.92 is a very old FS9 version of FSUIPC, so I assume you mean 4.92. Second, the elevator control doesn't operate the rudder in any case. If you mean the elevator in both cases then you need to either look at your calibration or the state of your hardware. There's no delays biuilt into FSUIPC, it simply passes the stuff on. But if you have "Filtering" enabled in the calibration tabs, uncheck it -- it is rarely necessary and can produce a very slight hesitation (usually unnoticeable). But that would be all the time, not just in one instance. Oh, also, if it only occurs with the T7 it may be a bug in that aircraft. ALWAYS test using default aircraft. Complex add-on aircraft do their own thing, nothing to do with FSUIPC. Regards Pete

Okay. This is the CH device: and of those entries, these appear to be the 6 axes: Value R/RZ at index 0, range 0 -> 255, using 8 bits Value V/RY at index 1, range 0 -> 255, using 8 bits Value U/RX at index 2, range 0 -> 255, using 8 bits Value Z at index 3, range 0 -> 255, using 8 bits Value Y at index 4, range 0 -> 255, using 8 bits Value X at index 5, range 0 -> 255, using 8 bits which are the standard X Y Z R U V axes recognised by FS and by FSUIPC. So it is a puzzle. I'm afraid I've no idea why neither see all 6 axes. Try uninstalling the device (in the Windows device manager) then re-booting Windows and plugging it in afresh. If that doesn't help I think you need CH support. But first you could ask over in http://www.ch-hangar.com/ Pete

Sorry, I've no idea how to do that. I know you can close runways, but ensuring a different distribution between them is not possible as far as I know. No way via offsets. I've not seen a way to influence runway selection in Traffic Toolbox. The ATC part of FS is a different module altogether from the traffic side. And AISeparation can only send commands to AI traffic to slew them or maybe pause them and steer them. Maybe it does it by moving them over to a different approach path. You can send FS controls to AI traffic via offsets. AIseparation and AIsmooth do that. Sorry, I've no idea. Maybe one day some one will hack into the ATC module of FS and work it out. I'm getting too old. My hacking days are over I'm afraid. Regards Pete

No, sorry, I don't know of any way except by ensuring there's enough wind to guarantee a specific direction of approach and that it is set long enough beforehand for the AI traffic to change pattern. Pete

The Logo and Cabin linghts are bits 8 and 9, so in the high byte of the 16-bit word. Check that you are writing 0 to the Unsigned Word (UW) not just the one byte. Otherwise it sounds like a bug in P3D or in the add-on aircraft you are using. Pete

The repeat rate might be controllable by the PollInterval parameter, but I'm not sure without delving into the code, for which I've not got time at present. This parameter is decribed in the Advanced User's guide. Have you tried the same but using "Pan View" instead, with the angle as the paratemter (0 up, 90 right, 180 down and 270 left)? BTW the mouse look option in FSUIPC allows you to pan with the mouse using the centre button rather than having to also hold the space bar down. Pete

Doesn't sound like anything whatsoever to do with FSUIPC. And what are all these Modules you needed to Register? What asked you to do that? Do you mean add on gauges and DLLs? If so you don't mean "register" but just permission to run -- if so then it sounds like your FSX.CFG file was inaccessible or corrupted. Pete

Sorry, I don't know Linda, but i doubt whether she cares one way or the other. There's a Linda support forum isn't there? ... Yes http://forum.avsim.net/forum/429-linda-support/ Pete

Don't forget you can use the Trace/Log option on the logging page to do line-by-line tracking. It also logs each time the event check occurs. You'd need to reload the plug-in after enablng the logging. Pete

You can cancel anywhere. It won't affect the current execution, only the next time that event would have occurred. Pete

Yes, but that's the same with any solution. Inputs from axes are only ever processed when the values change. Here the panning extends as far as needed, but then the joystick I've got has many positions therefore many changes in value. You might be able to get more for yours by changing the Delta value in the axis assignments -- reduce it. The number there says "ignore changes less than this". For your application you don't really want that too high. Of course it has to go through the positions between left and right or vice versa. I thought that was the whole point. Moving the stick left pans left whilst you are moving it, but releasing it leaves the view where it was. EXACTLY as you asked for! Therefore to pan back towards the centre you move the stick the other way. You should be able to stop it anywhere on release doing that. Naturally to get all the way from left to right or vice versa it has to go through the centre. It is now sounding like you failed to explain whast you really wanted. I'm sorry, but I now don't have time to do any more on this. I thought I'd implemented EXACTLY what you specified, and that's the way it works here. You now seem to have changed your mind. :sad: Pete

You can delete the first 4 lines too as they are not used without the calibration part. It works fine here. Since you used a new name, did you also change the INI (the [Auto] section) to get the new file loaded? If it isn't actually running it can't do anything! The PAN VIEW control isn't an axis control and doesn't have calibration or slopes. It's the same control used by hats. And in any case, as I said earlier, the FSUIPC calibration and slope facilities cannot work when the control is sent this way! Please reread the text accompanying the previous example. I think you missed some of it! Pete

Better using the logging in the PFCHid.INI file. See the PFCHid documentation. There's a number of options listed there, in the bit under [Debug]. You can even send the log, real-time, to a console window on screen. Pete

If you need to reach both extremes of the panning then you really do have to use the numbers as they aree (calibrated to -16383 and +16383, the extremes). If you are happy having less angle You have two ways to do that. Either divide the final "sendthis" value being sent by some number, eg. 2 would halve the angle and the sensitivity, thus: ipc.control(..., sendthis/2) Or add the divisor into the FSUIPC INI axis assignment (adding ,*0.5 at the end). However this way might mess the calibration numbers up (if you are having the Lua plug-in calibrating). In FSUIPC calibration you get less sensitivity in the centre parts without satisfying the angle by flattening the curve, but to do that in the Lua would require a bunch of new code and slow it down more. After I posted the solution above I did think of another way to do this, using PAN VIEW, just like a Hat. Here: max = 16380 topcentre = 512 bottomcentre = -512 min = -16380 prev = 0 absprev = 0 function panning(val) if val > topcentre then val = ((val - topcentre) * 16383) / (max - topcentre) elseif val < bottomcentre then val = (((val - min) * 16383) / (bottomcentre - min)) - 16383 else val = 0 end if val == 0 then return end sendit = false absval = val if val < 0 then absval = -val end if absval < absprev then if (val < 0 and prev > 0) or (val > 0 and prev < 0) then sendit = true end else sendit = true end if sendit then if val < 0 then sendthis = 90 -- Right pan else sendthis = 270 -- Left pan end ipc.control(66416, sendthis) -- Pan View prev = val absprev = absval end end event.param("panning") This solution appears smoother to me, but I don't know about sensitivity. Try it. Again, the calibration either needs numbers inserted or removed altogether as explained before. The Pan View control pans left with value 270 and right with value 90. To do the vertical panning change those numbers to 0 and 180. Have fun! Pete

Okay. Here it is, but I don't think you'll like it too much as there's so much code interpretation to be done that it may be too jerky for you: -- put calibration values here max = 16380 topcentre = 512 bottomcentre = -512 min = -16380 prev = 0 absprev = 0 function panning(val) -- Delete from here if calibration not needed if val > topcentre then val = ((val - topcentre) * 16383) / (max - topcentre) elseif val < bottomcentre then val = (((val - min) * 16383) / (bottomcentre - min)) - 16383 else val = 0 end -- End part to be optionally deleted if val == 0 then return end sendit = false absval = val if val < 0 then absval = -val end if absval < absprev then if (val < 0 and prev > 0) or (val > 0 and prev < 0) then sendthis = prev + val sendit = true end else sendthis = val sendit = true end if sendit then ipc.control(66504, sendthis) --Axis pan heading (use Axis Pan Pitch for other axis) prev = val absprev = absval end end event.param("panning") This is for heading pan. Note that because the sending of axis controls from Lua bypasses FSUIPC calibration you need to calibrate IN FSUIPC first, then put the 4 values you get into those top 4 lines, as shown (those are just defaults). If you don't do this it'll be very wonky! Then reset the FSUIPC calibration so it does nothing. NB if your axes are perfect -- i.e. max = 16384 and min = -16384, or close, and centre is ALWAYS 0, then delete the calibration part above and the line calling it. That might then just make it smooth enough, though I still have doubts. The pitch one would be the same but with the Axis an Pitch control number in the ipc.control you see. You'd need to save this as, say, panhdg.lua, into the Modules folder, similarly the pitch one, say as panpch.lua. Add [Auto] 1=Lua panhdg 2=Lua panpch to the FSUIPC INI file, the rerun FS and assign the heading axis to Luavalue panhdg and the pitch axis to Luavalue panpch. Personally I think you might want to consider getting a normal hat control. Regards Pete