Pete Dowson

Something is bottlenecking at the start. How long after FSX appears "ready to fly" are you waiting? On FSX, with both FSUIPC4 and TrackIR running, there is a lot of initialisation taking place right at the beginning. FSUIPC4 does discard the first 10 or so reading it gets, because there are a number of USB joystick drivers which appear to send spurious values initially, before they themselves are properly initialised. But at its default scan rate of 20 readings per second, that should only take half a second -- though, again, if FS is very busy just then, it could take longer. And then FSUIPC needs to see a movement on the axis before it will use it. Mid-range seems rather far, unless you are using an overlarge Delta value in your assignment? The IN and OUT numbers are shown on the yoke? It has its own display? Or do you mean in the Axis assignments option in FSUIPC, or in Calibration? Once FSUIPC is seeing and showing changing values, it is most certainly passing them on to FS. Enable Axis logging in FSUIPC's logging page and check it for yourself. Incidentally, version 4.40 was superseded by 4.50 a couple of weeks ago and is no longer supported. Regards Pete

I'm not really sure why you would interrupt an otherwise immersive flight by going into the menu system in the first place? Can you explain why this has suddenly become an issue? The way FSUIPC works has been okay for everyone, at least judging by the lack of such a request, ever since the wind smoothing was introduced back in FS2002 times I believe. Maybe before. I'm not sure I really want to mess with it at present. It does get quite complicated because it is all based on averaging over elapsed time. Some justification for change is needed at this stage, I believe. I don't understand it. Regards Pete

Because, as I said, Microsoft have to provide a basic option which covers all manner of aircraft, whereas the vendors concentrate on the one aircraft at a time. Microsoft Flight Simulator has always been so, a good basis for others to improve upon. Yes, of course they are!!! As I said. A lot of code and hard work in designing it! Yes, do as PMDG have done and write your own autopilot! The facilities are there. You can control throttle, elevator, aileron and trim. You can measure the accelerations and velocities in all directions, and the weight and balance of the aircraft. That is what the PMDG code is doing. it is reading the situation and controlling it. If you have the skills and hours to spend you can most certainly do the same. Go ahead! What specific aircraft are you thinking of tackling? You must choose, as it is not a case of "one fits all"! Regards Pete

No, it is not an FSUIPC messahge, it is an error detected by his program and the message is from his program. there is no such message from FSUIPC itself. All it means is that it isn't communicating with FSUIPC. Are you by any chance running FS "as administrator", but FSRealTime not "as administator"? Or vice versa? On Vista, if two programs are running at different privilege levels then they cannot exchange data via shared memory, so they cannot use FSUIPC interaction. They should both be run in the same way, preferably 'normally'. I know FSRealTime. I use it myself, and have done so for a long time. Please tell Joshua, the author, of what you find to fix this on your system -- I'm sure it will be because of how you are running FS9 on Vista (FS9 is not so good on Vista as it violates many Vista rules). He will need to know so as not to give incorrect advice. Regards Pete

Phew! That's expensive for a yoke! If you want more help, just be a little more specific on what you've done, where, and what the results were. Then, maybe, I can see where you are going wrong? Also, if is it new, and so expensive, shouldn't you expect some support from the makers or suppliers? Regards Pete

If the numbers it provides beyond that 1" movement either way are not changing at all, then it sounds like there is nothing that can be done software-wise. The yoke is junk and wants discarding or repairing. On the other hand, if you have not first calibrated in Windows Game controllers, and then when assigning in FS you haven't changed its sensitivity sliders and null zone sliders as advised (max and min respectively), and maybe then haven't calibrated correctly in FSUIPC -- then maybe you need to follow all the instructions again, but a little more carefully, step by step? Get them working properly in Windows first, then in FS. Try FSUIPC for the final, more accurate adjustment afterwards. FSUIPC won't work magic and make a bad setup good. Regards Pete

Sorry, I don't know any way to change that. Pete

NEVER publish you key openly as you have done. It will now have to be invalidated, although it was valid (for FSUIPC3 only). You will need to buy a new one. Pete

They don't use the FS autopilot. Full stop. They do their own control of the aircraft to accomplish the correct behaviour. There are others that do this too -- Level D with their 767, and Project Magenta on the seveal aircraft they support, though in the latter case they use a small part of the FS autopilot activity still. Quite honestly, I don't see that you have stated any "problem" as such, yet. All you have done is asserted that PMDG's autopilot is better than the default one. No one will disagree with you there. It is 100% purpose designed for its specific model of aircraft. FS's autopilot is a generic one which tries to cope with every type of aircraft thrown at it. It is a wonder it does as well as it does! Of course they have! It has cost them many thousands of man hours to get it so good! And what "error" is this? You've spent a lot of words without once being specific about what it is you are complaining. If it is the general inaccuracy or lack of versatility of the default A/P in FS, then that is very well known. That A/P is derived from the original, designed for Cessna trainers, and adapted rather hopefully to all and sundry, from lesser aircraft right up to the 747. There is no way any one A/P setup can really do justice to all those differences. As I said, it is a small wonder it copes at all. Every more sophisticated add-on which does better does so because its authors don't have to cope with such a wide range of factors. They work on dedicated code specific to that aircraft, and that's what you pay for! Regards Pete

Okay. the problem with the [ ] characters is fixed in FSUIPC versions 3.903 and 4.503, now available in the Updates Announcement above. This fix won't mend current INI files containing [] in the [Profiles ...] sections -- you'd need to changed them manually to the round parentheses, i.e. [ to ( and ] to ) in the [Profiles ...] sections, but it will stop the problem arising in future. Regards Pete

I really don't think I can help at all, I'm afraid. i haven't done or used anything with EPIC, even the USB version, for so many years now that I don't remember anything about it. Certainly DX is nothing to do with it. They are all ancient in any case. I'm not aware of any differences between whatever might be around. Sorry. I think you need to go to RR in any case. Terribly sorry. I don't even remember what a 2joy" file is I'm afraid. Good luck! Pete

What do you do wrong? How about not using the supplied reference lists of offsets for FS2004 and before, and not even noticing that some of the offsets you are using are NEW to FSX, as clearly noted by the BLUE colour in the document? Of those you list above, 1330, 126C are not supported in FS9 or before, and 1334 was only added in version 3.80 of FSUIPC. Offset 2AE0 is unknown to me in any case. What do you think is there? Please PLEASE use the reference lists I provide!! Pete

I did write! I gave explicit instructions. Here, I'll repeat them for you, but I really shouldn't need to. You should read my messages all the way through, please! :-( ===================== Change this line: ShortAircraftNameOk=No to read ShortAircraftNameOk=Substring then edit this section: [Profile.Level D 767-300] 1=Level D Simulations B767-300ER - Air New Zeland 2=Level D Simulations B767-300ER - American Airlines 3=Level D Simulations B767-300ER - Qantas Airways 4=Level D Simulations B767-300ER - British Airways 5=[DXT3] Level D Simulations B767-300ER - British Airways to read: [Profile.Level D 767-300] 1=Level D Simulations B767-300 deleting the extra lines. Then it will handle all aircraft containing "Level D Simulations B767-300" in the name. Pete

Version 3.5 is well out of date -- over three years in fact! It is totally unsupported. Offset 1334 wasn't added till version 3.80, in March 2008! You appear to be reading a later version of the Offsets list yet using a very old FSUIPC and a very old FSI file in FSInterrogate! Please do NOT ask for help here before checking you are up to date! It just wastes everyone's time. Please see the Announcements above for current version numbers. Pete

Sorry, "latest version" is meaningless. Please always state the version number. Folks have said this to me and after much wasted time I've found they were using a year-old version. by "latest" they merely meant "the latest one they'd noticed"! Anyway, looking at your INI file, I see there is a problem, here: 5=[DXT3] Level D Simulations B767-300ER - British Airways The characters [ and ] aren't allowed. i will change FSUIPC to eliminate them in the next update. But meanwhile you are not making best use of the facilities FSUIPC offers. Change this line: ShortAircraftNameOk=No to read ShortAircraftNameOk=Substring then edit this section: [Profile.Level D 767-300] 1=Level D Simulations B767-300ER - Air New Zeland 2=Level D Simulations B767-300ER - American Airlines 3=Level D Simulations B767-300ER - Qantas Airways 4=Level D Simulations B767-300ER - British Airways 5=[DXT3] Level D Simulations B767-300ER - British Airways to read: [Profile.Level D 767-300] 1=Level D Simulations B767-300 deleting the extra lines. Then it will handle all aircraft containing "Level D Simulations B767-300" in the name. I'll fix the problem with the [] characters in the next update, as I say. Regards Pete

Okay. I've added it anyway. I'd like to know what you don't understand so that when I update the documentation (it'll go into the Advanced User's guide) I can word it appropriately. Did you understand my last explanation? Was it pitched too low or is there still something missing? To try it yourself, download 4.503 (for FSX) or 3.903 (for FS9) using these links: FSX: http://fsuipc.simflight.com/beta/FSUIPC4503.zip FS9: http://fsuipc.simflight.com/beta/FSUIPC3903.zip These only contain the DLLs. Just put the relevant one into the FSX Modules folder. The multiplication and addition parameters are both individually optional, but if both given the multiplation one should be first. Multiplication is * where the number can be positive, negative and have fractional parts. Addition is +, or - for subtraction. No fractional parts. The result is always restrained to the range -16384 to +16383, so any result outside that will be left at the relevant limit. You won't see the results of this change in the Axis assignment Tab as the conversion is only done before passing it on to the FSUIPC calibration section (where you will see it), or to FS if you choose to send FS controls instead. Regards Pete

Another thing that has occurred to me which may make you not want to go down the path I am suggesting: The two pedals will obviously both still be giving values, albeit non-overlapping ones with the above-described facilities programmed as I said. The two axes will both want to move the rudder, one one way and the other the other way. FSUIPC only acts on the last change it sees, and then, with two axes acting on the same control, it arbitrates to the largest deflection. With normal rudders you effectively push one pedal away and the opposite pedal pushes back out to you. With separate pedals, as in your case, you wouldn't be able to emulate this by relaxing one foot whilst pressing with the other. You'd have to only push one pedal at a time -- your other foot removed from the other pedal. If you didn't do this, if both axes were supplying values at the same time, FSUIPC would use the last one changing to the biggest value, and that could change quite suddenly as you relaxed or pushed -- making the rudder swing violently left to right or vice versa. In fact, with your arrangement it would be best to use only one foot, to avoid this possibility, much as you would normally when driving an automatic-geared car. I suspect the same sort of compromise would have to be applied even if you were using the Logitech Profiler. I can't really see an alternative method. Regards Pete

Well it shouldn't look complex as much as feature-rich. It's like a Swiss Army Knife, a collection of many tools to solve different problems. Yes, of course it cannot create any axis parameters if there are no axes assigned. And Windows INI files don't get created empty. No. it is not, or at least certainly not put like that. FSUIPC is not aware of what a zero point means at all at this level. We are simply dealing with axis values. Meaning comes with calibration, not axis assignment. The same facility could be used to put three axes on the same control, each controlling one portion. No "centre" is understood, yet. FSUIPC would be doing exactly what I said it is doing. The multiplication factor is multiplying the number coming in from your axis and the addition factor is then being added. This is why they are called multiply (*) and add (+), because that is all they do, pure and simple. What is not to understand about that? No, I'm not really inclined to add even such simple things if it only means a lot more such support work. I have enough already. If you cannot understand this beforehand I'd advise you to find another method. I'll just try explaining it, at a very simple level, one more time, then I'm going to give up: Look, it is simple arithmetic. Take one of your axes, the one ranging -16384 (let out) to 16383 (pressed fully). That's the normal full range of a whole rudder or other control axis, but you want it to be only one half of the rudder so you can use the other axis too. So, we want it to run from 0 to 16383 instead. That is, to be zero (0) when not pressed, so it is centred, but still 16383 fully pressed. Since the RANGE you have is 32767 (16384 + 16383 = 32767, right? With me still?) and we only want half this range, so we can accommodate the other axis, we divide by 2. That's the same as multiplying by a half -- primary school arithmetic, right? Still here? In normal decimal notation a half is 0.5 (5 tenths, right?). So the parameter *0.5 says "multiply by 0.5" which, as you should now realise, if you are following me, the same as "divide by 2". Dividing the range of input values -16384 to +16383 by 2 gives you -8192 to 8191 (losing the unwanted fraction). Right? Since we want it to start at 0, not -8192, we have to ADD 8192, because: -8192 + 8192 = 0 Okay? Therefore the second parameter needed is +8192. Now see if you can work out why the other axis needs to be as I said. Let me know when you get there. If you can't, I'll give up. Regards Pete

OkayI've looked at several different methods. if i add a new facility I want it to be both flexible and efficient, and there is no way i can do both for this via a simple checkbox. So... I think the best way I can offer are two additional parameters in the axis assignments, editing them in the FSUIPC4.INI file. So, you'd assign both axes to Rudder, then, before calibrating, add these parameters to the ends of the relevant lines in the [Axes] section of the INI file: ,*,+ where is a signed integer. Then, bearing in mind our needs here: you would add these to the first: ,*0.5,+8192 which would convert the range first to 8191 to -8192 then, by addition, to 16383 to 0 and the second: ,*0.5,-8191 which would convert that range first to -8192 to 8191, then, by addition, to -16383 to 0 How does that sound? If you aren't going to be able to use this because it is too complex, I won't bother adding it, so let me know please. Note that you could adapt the RAW values too, but obviously the numbers will be different. Regards Pete

Hmm. My thoughts about Negating one of the values isn't going to work. Your results show that the Accelerator and the others are working in opposite directions to each other in any case, no the direction of change is already correct. the problem is that the ranges overlap so much. Let's see. Assuming we use the pre-calibrated values, not RAW, we have Pressed In: 16383 Let out: -16384 versus Pressed In: -16384 Let out: 16383 whilst we want the first to be 16383 to 0 and the second to be -16384 to 0 I'm not sure how best to tackle this. It needs more thought. I'll get back to you. Regards Pete

Your registration doesn't just apply to 3.85 but to any version 3.xx. The current supported version is 3.90, so you should consider updating in any case. You will need to if you want any further support. Regards Pete

You are not actually copying the DLL into the FS modules folder, then. It would overwrite the (very) old version It sounds like you let FS install into its default place in Program Files, which of course are all protected in Vista. That's quite messy. Because FS2004 is not Vista aware, and doesn't obey the rules of a Vista program, the Vista system actually keeps the folders for FS elsewhere. What you see in Explorer isn't the real Modules folder but an aliassed one. I think you can get around this by running Windows Explorer by right-clicking on it and selecting "Run As administrator", then copying the new DLL over the old one. Pete

Please give me the minimum and maximum values you see in the "IN" box on the Axis assignments tab, both with and without the "RAW" option selected, and state which are with the pedal pressed and which released, Thanks, Pete

Okay. so why the business about separation from the wheel? It will be a different axis in any case, so ignore the wheel axis? It seems a bit over the top to have to insert another controller board? Three? Ah, is this a set with clutch as well? Maybe they don't default to having two of the pedals on one axis, then? Is there any reason why the Profiler won't do the job satisfactorily for you? Not necessarily "not possible". Let's see ... in FSUIPC you can certainly assign both axes to the same Rudder control. That isn't a problem. The problem is that they will both share the same range of values -- presumably, in Raw terms, 0 to 255 or similar? And you can only calibrate them as one, so you can't get one operating the negative range and the other the positive. So, if you had a facility in the FSUIPC axis assignment, to NEGATE the values there, to give 0 to -255 (as opposed to the more usual "reverse", which would give 255 to 0), wouldn't that work for you? You would calibrate the positive side using one pedal and the negative side using the negated pedal -- both in the Rudder calibration section. I could do that quite easily if you think you could use it. I don't know where I'd fit the new checkbox needed, but i'll take a look. Meanwhile, can you see what RAW and Calibrated values you get in FSUIPC's axis assignments for the two pedals you want to use, please? Let me know so I've a good idea what I'm dealing with. Also, since you'd have to test this yourself for me, let me know if it is FSUIPC3 or FSUIPC4 which you need first. Regards Pete

As I understood only after the last message, yes. Since my PFC driver doesn't support those buttons except on the Jet Cockpit, it definitely seems as if they've wired them to the same socket as the usual AT Disconnect buttons. Codes are not single bytes. You mean 9C 00 and 9C 01 respectively I assume. This is the same code used for the AT Arm toggle switch. It is indistinguishable in the software. I thought I made myself clear in the last message, where it suddenly dawned on me, as I clearly said, that you were talking about the switches the other way around, and that, indeed, PFC had wired your switches to the reverse of what I would have expected, especially compared to the Jet cockpit, which is the only instance documented, or that I have seen, where both sets of switches are available. I am clear on this now, but it seems you are still nowhere near convinced by my explanations? I will have to tell PFC clearly that if they make such odd one-off (?) modifications without informing me, they must be prepared to support the driver nuances that arise. This has taken a lot of mine and your time needlessly. I am not amused. This is finished now. Please, if you have any more queries pursue them with PFC. Regards Pete