Pete Dowson

Okay, that is of course true of most add=on aircraft. The PMDG and Level D examples, where the autopilot is pretty much completely replaced, are in the minority. No, I most certainly do not profess any such thing! All my developments for FS, over all these years, have been to enable others, who DO know what they are doing, to develop such capabilities. I have only ever provided the access into FS, the wherewithall to link solution to simulation. And in FSX, with Simconnect taking over thsat role, I don't even do that except for backward compatibility. You obviously severely misunderstand the part my programs play in the FS world! I think your attitude is extremely poor. You misunderstand things and blame others. If you read this thread again you can see that I've only tried to explain why you see what you see. I've not told you to build anything, as you appear to be telling me! In fact I specifically said "IF" in the only place where I was pointing out that it isn't easy: "If you have the skills and hours to spend you can most certainly do the same. Evidently you haven't, and neither have I, but you should not be venting your frustration about that here. It is not appropriate. Pete

Can you elaborate, please? Be more explicit? Are you assigning keypresses to FS or FSUIPC controls, in the "Keys" tab in FSUIPC options, or are you using joystick buttons and assigning keystrokes to them, in the "buttons" tab? As well as distinguishing between these, can you also give some explicit examples, please. i cannot really help in a vacuum. i have to understand what exactly you are trying to do and what it is you get as a result. Yes, it is of simFlight, my publishers -- they own this website and run SimMarket. The "Peter L. Dowson" signature expires this August, after which the program will not work at all. None of the certificate authorities now sell certificates to individuals, only Companies, so simFlight kindly stepped in and purchased the certificate for me. I have changed this early so there is a good overlap -- hopefully not too many folks will get a sudden problem in August. Regards Pete Thanks.........Robert

I've had a look at my code. It turned out that it didn't look too hard to change all the smoothing to operate based on the "ELAPSED TIME" values which i nowadays read as a Gauge variable -- the one provided at offset 04A8. I don't think this is as accurate as the Windows timer I normally use for everything. It is probably only at most as accurate as the 55mSec (1/18th second) ticker in FS, or possibly the frame rate. I don't think it is updated more often than the frame rate in any case. This may make it a little more uneven in how it smooths the wind. The only advantage this timer does have is that it stops whilst FS in in menus, or paused, and, Ithink, runs faster or slower according to the FS Simulation Rate. So, maybe it will do the job you want of it. Try it and let me know. I'm afraid I won't have the opportunity to do any proper testing of this till next week. It is provided as a session mode, selected via an INI file [General] parameter: SmoothBySimTime=Yes (defaults to No at present -- I may change the default if the results look really good). The wind smoothing is still reset when you load a new flight, or move the aircraft location via menu, or change the weather mode (theme <-> user <-> real, etc). download http://fsuipc.simflight.com/beta/FSUIPC4504.zip now (please make sure you've installed 4.50 first, though). Let me know, please. Regards Pete

It's operating in "digital" mode, then, like the 4-way rocker on a Game Pad. It will be to do with the way the driver is configured in the registry, which derives either from its own driver, or, if using a generic driver from Microsoft, from the USB "HID" (Human interface Device) data the device itself is providing. This is certainly something you need advice from the makers about. Probably either a driver, or a registry patch (maybe via an .INF or .REG file). Regards Pete

Pretty much all the testing on the smoothing in FSUIPC4 was done with the PMDG 747X, and it has been okay now for over a year. Suddenly it is a problem? Are you sure this isn'yt something in ASA which is different from ASX? That seems to be more significant in this change of needs all of a sudden, doesn't it? Blimey! Really the facility wasn't designed to work that slowly, though of course the arithmetic will still work. At those sorts of rates you are never likely to get the predicted or stated winds, anywhere. Doesn't that cause problems with runway assignments and so on? I've always use a 1 for 1 rate with no significant problems. Pete

Can you not stop your time keeping when you see the user enter a menu. I sorry if this is a really stupid comment/question but I'm no programmer in any sense of the word, but I imagine from your response that it is a major thing I am asking for, and the last thing I want to do is create any more headaches for you Pete It may or may not be major, I've not looked at it yet. I am simply seriiously concerned about messing with it for little good reason. The earlier posting on this was actually mentioning a stupidly slow smoothing rate of some 1 degree /knot every 4 seconds. At such a rate the wind will almost never be what it should be. It's a wonder the AI traffic at airports aren't conflicting all the time with your own flights. With more sensible smoothing rates like 1 for 1, the Wind should never get that far behind what it should be that it is going to matter so much. But this was always a factor with the PMDG 747X as well, and it seemed to be all sorted, a year or two ago. Has all this new fuss come with the use of ASA in place of ASX? If so, isn't it in that direction you should be looking? That is actually pretty rare except when using a weather control program, and it is due to exactly the same bug in FSX as was in FS9. This has been going on for years and years. The smoothing is not the only need, the weather setting programs like ASX, and I presume ASA, were also changed to try to deal with it. During a flight? I never do. It definitely destroys the whole point of the realism I've strivern for. Because, presumably, the smoothing is continuing based on real time. I'll have a look when i get a moment. Maybe it can be changed to work on FS time, though that could be messy as all timing in FSUIPC, throughout, is based on the Windows "tick" time. Changing a whole section of code to work with different timers could be very error-prone. It is really this risk of introducing bugs in complex code which worries me more than the work involved. Regards Pete

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