Pete Dowson

I understood that part. It was all your other statements that confused the issue. Here: I'll number them for you: 1. The rudder beddles do not respon on some occations and move just a liiiiiiiiiiiiiiittle bit on other occasions. I did the calibrating 3 times for rudder beddle selection to calibration. Not sure what to do. So, I am to understand you calibrated 3 times (why?) but you are not happy with the results. 2. It works when I use FSX for the rudder peddles So, if you ASSIGN in FSX instead of ASSIGNING them in FSUIPC? But if you had the calibration still set in FSUIPC they will still be calibrated the same. So what do you really mean here? 3. BUT the some times work or some times dont like when I use them through FSUIPC. So this is repeating part of number 1? By "when I use them through FSUIPC" are you talking about ASSIGNMENT or CALIBRATION? Because they are two separate things. FSUIPC's calibration works no matter where or how you assign them! 4. The difference it when they do work they have a FULL rang of motion. When they work with assignment in FSX or assigtnment in FSUIPC? The calibration is the same. 5. I dont want to do that because I am getting the joystick dropping off the face of the planet problem with Windows 8. You don't wnat to do what? Have a FULL range of motion, or have them assigned in FSUIPC, or have them assigned in FSX? I don't know what parts refer to what. Do you see the confusion. You jumbled everything up and I cannot make out what refers to what! And you must always be clear about ASSIGNMENT and CALIBRATION. Well there's one problem. 4.80 is not supported. You must be on 4.90 or later! The second is that there are no assignments, not buttons nor axes, nor any calibrations whatsoever shown in your INI file as posted. You are effectively not using FSUIPC at all according to that. Did you only post a small part of it or what? Additionally you did not answer these points: For conflicting axes, check if using FSUIPC for assignment that you have either disabled controllers in FSX, or certainly unassigned all the axes you are assigning in FSUIPC. Best to disable them -- do this to test in any case. If you want a double-check, enable Axis logging in FSUIPC's logging tab and view the log entries as you move the pedals. If you run FSX in Windowed mode and enable FSUIPC's Console logging you can see this as it happens, on the screen. Please first update FSUIPC. Then either use FSX for all assignments or DISABLE controllers n FSX and use FSUIPC. THEN follow the dicumented and numbered steps for calibration in FSUIPC. See the Usere Guide. If you do this properly and your rudder pedals still give problems, I think you might consider returning them to Saitek. Regards Pete

Maybe the name by which the aircraft is known has changed. If you have "ShortAircraftNameOk=Substring" set in the [General] section of the INI, then just shorten the name to some part which will match all versions you wish in that profile. Do this in the [Profile.<profilename] section which lists the aircraft assigned to that profile. Otherwise, yes, each time you have a new aircraft or fly a new livery, you need to ad it to the existing profile explicitly, or, if you wish, create a new one if things will be different. If you still think something is wrong, please explain in detail and show me the actual INI file so it illustrates your points. All I can do is assure you that nothing has been changed in some time in the Profiles area -- review the list of changes in the History document and you will be able to locate the last relevant change. And in 4.90 the ONLY change was the removal of the signature. That was the only reason for its release. Regards Pete

I think you both do not understand the flexibility of the facilities you are presented with. Please refer to my earlier reply which crossed with your new post. Pete

By "nothing work", what do you mean? If you've not assigned anything, what do you expect to work? Please clarify. You give no details for your report to be useful. I think you misunderstand. Whilst Axis assignments are specific only (i.e no default axis assignments can also apply to a specific selection), generic Button and Key assignments apply unless actually overridden by specific assignments. If you think about it this makes sense. You don't want unwanted axis assignments affecting the wrong aircraft, but buttons and keys don't do anything unless actually pressed or switched. By having both available you can do most of the more general assignments for everything and have specific differences for different aircraft. The manual does explain this -- perhaps you've not read enough of it? In Button and Key assignments tabs you can switch between the Generic and the Specific by toggling that checkbox off and on. try it! You don't understand this either? Does no one read the documentation? :sad: There's been no change in this area for many many years. Regards Pete

Yes, though I've not heard of an aircraft caled BOB! ;-) Pete

Sorry, I am getting muddled here. Which part of all that refers to assignment in FSUIPC, and which to assignment in FSX? Perhaps you could separate those out for me. I ask this because both FSUIPC and FSX read joysticks in EXACTLY the same way. As for erratic movement, assuming you've really calibrated them correctly, then either you have dual conflicting assignments, or a faulty device, cable, USB port or driver. For calibration checking please show me your FSUIPC4.INI file which you can find in the FSX Modules folder. You can paste it into a message here. For conflicting axes, check if using FSUIPC for assignment that you have either disabled controllers in FSX, or certainly unassigned all the axes you are assigning in FSUIPC. Best to disable them -- do this to test in any case. If you want a double-check, enable Axis logging in FSUIPC's logging tab and view the log entries as you move the pedals. If you run FSX in Windowed mode and enable FSUIPC's Console logging you can see this as it happens, on the screen. Regards Pete

Well, the only real difference is that in the original you had almost every axis calibrated by default, for all aircraft. You never did profile-specific calibration. You did things like selecting slopes, reverse options (for brakes, spoiler and flaps) and no reverse zones for throttles. This is shown by these entries: Elevator=-16384,-512,512,16192 SlopeElevator=4 Rudder=-16384,64,64,16383 LeftBrake=-16384,16383/16 RightBrake=-16383,16384/16 Throttle1=-16384,-512,512,16128/32 Throttle2=-16380,-512,512,16380/32 SlopeThrottle2=8 Spoilers=-16380,16380/16 Flaps=-16384,16128/16 SlopeRudder=8 SlopeLeftBrake=4 SlopeRightBrake=4 SlopeThrottle1=1[/CODE] You evidently didn't bother much with the real job there, though, that of actually calibrating the levers, because most of those numbers are the default values which are not all that likely to suit any specific hardware. In the new INI you have assigned axes from the Airbus, all to standard FS axis controls, and have actually calibrated the aileron and elevator: [CODE]Aileron=-16159,0,0,16288 Elevator=-16287,0,0,16320[/CODE] Again for all aircraft. So, there's rerally nothing to indicate how you got what you said happening at all. It still makes no sense. Not only that, but no one else has reported anything similar. If Aerosoft do provide me with a copy of the Airbus I'll try something like your two INI files here, but I suspect it must have been some odd sort of glitch on your specific system. Regards Pete

Seems that the software you are using does the conversion of the data from bit numbers to values to be logically OR'd or ANDed. Perhaps you should actually refer to the documentation for that software when you want to use it? I can only tell you what the actual interface into FSUIPC needs to see. Bits are numbered 0 - 7 in each byte, the values are 2^0 to 2^7 (^ means "to the power of" so that 2^4 = 2 x 2 x 2 x 2 = 16). The advantage of using Values, as per the actual FSUIPC interface, is that more than one bit can be changed at a time. For instance, the offset containing the FSX light switches is a 16 bit word using 10 separate bits for lights, so they can be controlled individually or all at once, or in clusters, etc. Pete

I know it isn't very often you'd need to -- only in an emergency or bad situation you shouldn't have got into in the first place. But if the aircraft is designed with such deflections allowed, they are like that for a reason. It would really be better to correct the design if it is wrong (the parameters I mentioned) than limit your control. Yes, and that is exactly what the slope facilities are provided for, to give more precise control in the normal range of use but without preventing full deflections in the rare times they might be actually needed. Anyway, you now have ways of doing what you want to do, so it's your choice. ;-) Regards Pete

Sorry, I'm the wrong person to ask. Try the PMDG NGX forums. I don't use PMDG aircraft. Maybe you have to experiment. There must be a way. Maybe they use 1 for inc, 2 for dec, or 0 for dec, or maybe there's a different event for decrementing Maybe they handle it like the mouse left and right button methods on the virtual cockpit -- see if the Mouse values listed somewhere in their SDK work. I've no idea and cannot try it for you! Pete

The NGX is an all-encompassing self-contained sim, with excellent cockpit graphics. It does not suit real hardware. The aircraft I use has NO panels whatsoever, no virtual panel, no 2D panel. It doesn't need one because I have real instruments. There are 8 screens in a real 737 cockpit -- admittedly I have only 7 because there's no room for the lower centre DU (I can show its content on the Upper DU) -- how would I drive those from the NGX? It isn't on! Even with the SDK allowing mapping of outputs and controls (events) allowing most inputs, it wouldn't be possible to drive the PFD, ND, EICAS and CDU screens properly from their software. If PMDG had done as iFly have done and produced a cockpit builders version with all those modules separate from FSX then it would have actually been possible, and might then have been more acceptable. However, bear in mind I started this cockpit business a long time ago, and have until recently used Project Magenta throughout (I now use a mixture of PM and TSR software, plus my own). PMDG NGX and iFly NG are very recent by comparison. Regards Pete

Thanks. Got them. I'll do the comparison later today. Pete

I understand that. I only meant as a test, because both FSX and FSUIPC use the same method to read joystick axes, and if the Aircraft is able to stop one it should also stop the other. So my question becomes: WHAT exactly did you have in your original INI file which prevented FSUIPC reading axes for this one aircraft? That makes no sense. Can you please show me the original, and the one you've now set, so I can see the difference? There is nothing I know of in FSUIPC which will stop it seeing axes for assignment. And looking at that Aerosoft Forum thread it seems no one else has any difficulty seeing the axes in the Axis Assignments tab, excepting when using the CH Control Manager, as stated here: However, deleting all your settings and letting FSUIPC create a new default INI (something you said you didn't want to do) wouldn't change that. So I need to know, what DID change what you got? AFTER assignment it is a different matter. Aircraft coding can prevent axes assigned to FS controls from being seen in Calibration. But that is not what you reported. No thank you. I don't think that's relevant. The point is I know of nothing which would stop FSUIPC seeing an axis only in one aircraft, and certainly nothing in the INI file. I get the feeling you are mixing up what you see in the Axis Assignments tab and what you see in the Joystick Calibrations tab. With the latter there are several ways that the INI might stop the values coming through, depending on the aircraft. Regards Pete

I don't know VB.NET I'm afraid,so for definitive answers I'll have to leave that to Paul, but it seems there are some odditities here. The most striking one seems to be that you define FuelLeftTankLevel as inmteger but assign to it a double. Does VB.NET do a conversion for you automatically, truncating the floating point value to an integer. The other things which seem odd are: a ) the derivation of LeftTankLevel from the ratio multiplied by 128 * 65535 when it is defined as a * 128 * 65536. Why 65535 instead? b ) if you fix that, the result you then have in LeftTankLevel is the value you need. Why are you then doing that / 128 / 65535 * 100 business? You already converted it into the correct units in the line before. Please try using FSInterrogate so you can see what the values actually look like and how they are derived. Use a calculator to see what you'd get. In the above case, for the FSX 738, value for 50 gallons would work like this: LeftTankLevel = (50 / 1288) * 128 * 65536 = 325644 That's the Integer value which would need to be written. But your further conversion does this: LeftTankLevelPercentage = 325644 / 128 / 65536 * 100 = 3 (as an integer). The value 3 there amounts to 0.0000004 % full, or 0.0004606 Gallons, which will certainly read out as 0. You'd be able to spot this sort of error using FSInterrogate to check and compare. I know FS uses the term "percentage" incorrectly. Almost every tme it really means "ratio", so 100% full = 1, and in units of 128 * 65536 that it would be, well 128 * 65536. Regards Pete

Thanks for te confirmation. I'll change the Download Links entry now ... Pete

I found this on the Aerosoft forum for the AirbusXExtened: fsuipc-axis-assignment-instructions/ so it seems it SHOULD work okay. I really don't know what is going on with your installation. BTW the forum title is Aerosoft Airbus X A320/321 (formerly Airbus X Extended) so does this mean the "Extended" is out of date? Pete

It's ready. But before I upload it to Download Links, please test it for me and let me know. FSUIPC4902.zip Pete

I don't see why that would help. Sounds like they just want you to lose settings which they want to bypass. If you wanted to try it, just make a safe copy of the INI first. You won't lose anything then. You do realise that you can make generic assignments (i.e. non-aircraft specific or not in a specific Profile) which will then be applied to any aircraft without its own specific assignments. Don't you? Try that. You didn't answer my question about assigning in FSX itself. BTW I'm getting Aerosoft to authorise a copy of the aircraft for me to check out here. But I don't know when I'll be able to get to it -- sometime next week I expect. Pete

I don't see any reason not to. I'll have the update to 4.902 available in an hour or two. You'll just need to download it from Download Links and copy the DLL (only) into the Modules folder. Regards Pete

Very strange. Okay, I'll code around it ... Pete

Well, that's very odd. FSUIPC calls the Windows DirectInput functions directly to read them. It sounds like there's some code in that Aircraft which actively prevents that! Can they be assigned in FSX tself at all when that aircraft is loaded, because FSUIPC and FSX do the same thing here. Sorry, but this looks like it is a question for the Airbus X support forum, or suppliers. I've not heard about this from any other Airbus X users though. Is it specific to the 'Extended" version, I wonder? Pete

Correct. Never send REG files in any case, because if double clicked they amend the Registry!! The point I need to know is whether there is anything at all within that KEY. It sounds like there isn't, else presumably it would be in the file, but please can you actually verify that by LOOKING at it. i.e. Will it expand to anything lower? Are there any data entries on the right for that key? If there's only the key you went to and nothing else it evidently serves no purpose whatsoever, so I don't know why it is there. However, I can take steps to deal with it. I just need to know. Pete

Sorry, you misunderstand. There appears to be a key for it entitled: [HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_0000&PID_0111] because that's the one you sent me. but the key is normally there for a reason -- because there's ddata or sub-keys associated with it. The file you provided ONLY contained the Key, as above, which we knew in any case as that was what you looked for. I need to know what that key contains. If it contains nothing at all, if it is jusr a waste of Registry space, please say so. It just seems unlikely (along with that VID or 0). Pete

Unfortunately that doesn't tell me the answers. It seems to be a glorified keyboard only. Since you use it and have presumably programmed it, you must know? I do really need the whole of that Registry entry for it. Pete

There was only the one line, the key I asked you to look at, in that file! There should (must as far as Iknew) be entries below it. For example, here's the RegEdit export file for just one of my devices: Pete