Pete Dowson

Sorry, I don't recall anything about any "FT" 737, let alone VNAV. Can you be more specific? Who is "FT"? I thought the "PIC" name was from Wilco and Level D. I'm very sorry, but I have no idea what the problem is -- you don't seem to have described one. Pete

Hi Antonio, Well, I fished out my RP48 and connected it up, programmed one of the rotaries to inc/dec the 737 A/P IAS value in aircraft-specific mode, and every click did operate it. So I then also programmed the same rotary in non-aircraft-specific mode, to inc/dec the course (VOR1 OBI inc/dec). Both worked fine. When the specific aircraft was loaded the rotary adjusted the IAS on every click, and for all other aircraft it operated the course on every click. I had a look through my code too to see if there's anything there which was capable of missing the clicks in any circumstances, but really I couldn't find anything. Which leaves me in need of more information, please. I was hoping that, should this turn out to be a bug, I could fix it in the next release, but I must release 3.52 this week, preferably well before the weekend. So we have missed that one. Then I'm really a bit stuck till February. I may have a little time early in the new year, so if you could do that logging and show me the INI file details I'd still look at it. You can ZIP stuff up and send it to me at petedowson@btconnect.com. By the way, I notice in your first message here that you said: This FS module is the one which operates the GoFlight programming for the buttons et cetera. All you need to do is to make sure that the GoFlight programming for the rotaries you use in FSUIPC is cleared -- i.e. you don't want both GoFlight and FSUIPC processing the same 'clicks'. Regards, Pete

A facility to allow the older axis controls through whilst suppressing the new ones looked easy enough to do, so I've slipped it in quick before I freeze FSUIPC till February. I've sent 3.515 to you by email. Perhaps you'd like to test it for me, please? Be quick though -- I need to get version 3.52 released this week, preferably Wednesday if possible. To suppress axes without suppressing the older controls, you need to not only write to offset 310A/310B regularly, but also write "2" to the byte 3109 regularly as well -- write all three bytes at the same time, as you wish. Whilst 2^1 of 3109 is non-zero, the suppress axis bits should only operate on the new style controls. This applies only to Throttles, Aileron, Elevator and Elevator trim. Sorry, I have nothing suitable to test it properly with here. Let me know as soon as you can please. Regards, Pete

Only when FSUIPC is being used to calibrate throttles or provide mapping or reverse thrust capabilities. When the FSUIPC facilities aren't used the controls pass through unmolested in any case. I don't really understand what you are reporting, sorry. The AXIS THROTTLE(n) SET controls are those which are assignable in FS's own control assignments, for the overall throttle as well as the individual ones. These are not provided with a reverse zone in FS -- the range -16384 to +16384 give idle to full thrust. the only throttle axis controls which have a reverse range are those from FS98 days which are still coded in FS -- the four individual THROTTLEn SET controls. This is why the Page 3 calibrations in FSUIPC convert AXIS_THROTTLEn_SET controls to THROTTLE_SET controls. If also calibrates the THROTTLE(n)_SET controls unless that special option is checked -- the ERJ uses those controls. That is really the sum total of what that was about. You'll need to interpret what you see in that light. Well, I suppose there could be a way to disconnect only the new AXIS_ controls but leave the older "FS98" controls like those. I'll have a look. Would doing it via another flag bit suffice, i.e. one flag which says "don't disconnect old controls only new ones"? Regards, Pete

No need to be sorry. I'm glad it was so simple to fix! ;-) Regards, Pete

Since these are "results" from the FS simulation engine, changing them won't actually accomplish anything. This is why they get overwritten again on the next frame. So all you want to do is display fictitious values, on displays other than FS's own panels? If this is the case, what I suspect you really want is the facility to have the PM PFD display values from different offsets when, for instance pmSystems is running. Then, in pmSystems logic you can normally simply copy the FS values into the PM PFD-read offsets except when you want some fictitious values displayed. You could also program better in pmSystems the consequences of such failures. I suggest you discuss this with Enrico Schiratti in the first instance. Any method involving overwriting FS result values is just as "dirty" as what you are doing, even if it is faster, and, in my opinion, simply isn't the right solution -- unless I am misunderstanding your request. Regards Pete

The reverser on page 7 is, by default, assigned to the mixture lever. If you have no mixture axis assigned in FS, you will see only 0 there as no axis is driving it. You CAN edit the INI file and use any other (otherwise unused) axis for a reverser, but this is SEPARATE from your thrust lever. Similar considerations apply to the 4 separate reversers on page 11, except that none of those are assigned by default. If you do have axes to spare, by all means assign them in the INI file. It sounds like you simply want a reverse zone on your normal throttle axis/axes, in which case certainly calibrating them on Page 3 is fine. Note that there is no such thing as an idle "position" -- you need a small range of movement for the idle, slightly above and slightly below your detente, so that you get two different values in the FSUIPC centre calibrations boxes. Anything below those values down to the minimum (reverse) will then give you reverse. Unless there is something very badly wrong with your hardware, it just cannot "move" from where you set it in FSUIPC, so it simply sounds as if you are not calibrating it properly at all. You need 4 clicked positions -- one for max, two for idle, one for reverse. They all need to show different values in their respective boxes. The values for centre should be those read when your lever is around your detente. if they are not, then the idle won't be there. Please just follow the simple steps outlined in the documentation. They work for everyone else. Regards, Pete

You have at least two things mixed up there. This 2turning too slow" is a bit of a meaningless statement. Do you mean you cannot control the ailernos to their limit? If so, you have badly calibrated joystick axes, and you need to set all the FS sensitivities to maximum. here is no such thing as "too sensitive" overall -- if you reduce FS's sensitivity, you reduce the range. Don't do it. You can calibrate in FSUIPC and apply a slope, so you get less sensitivity in the centre but more at the extremes. This is the way most prefer it. As for the throttle, itr sounds like you have the axis reversed. Check the FS control assignment setting for it -- you can reverse it there, or in FSUIPC. Just don't reverse it in both places. Regards, Pete

Hmmmhow very strange. The code is the very same code. The table is just one table. All that happens is that the entries for buttons inapplicable to the current aircraft are reoved when the ones which are applicable are read. Were the same button numbers also programmed for non-specific use as well? Maybe it is something to do with the double check -- I could investigate that. Perhaps you could reproduce it with Button logging enabled (in FSUIPC's Logging options) and show me the log, with a little explanation about which button is which, please? The buttons sections of your INI would be needed too. Thanks, Pete

Yes, I usually do that, but I tend to add so many changes from one release to another I wanted to indicate that this was an incremental rather than 'new' version. However, considering I hope not to release another for many weeks (I am on holiday in January, then other commitments loom), maybe i ought to leave it clear and tidy as you suggest. Thanks, Pete

Sound like you have enabled the "Allow changes to FS own weather" option in the Technical options page of FSUIPC. Please see the User documentation. It is a good idea to read the descriptions of these options in the dox before enabling them, just in case you get results you weren't expecting. ;-) Regards, Pete

I'm sorry, I really have no idea. You entitle this inquiry "Joystick issue", but then talk about automatic throttle control, which surely is a software issue -- the joystick isn't used, is it? the PMDG aircraft are very complex, and I don't know how they are programmed at all. Sorry. Have you asked over at PMDG? Regards, Pete

So you have no panel on the FS PC? FSUIPC cannot handle graphics at all. Sorry. Processing AI traffic movements isn't a big job, as I said, but it would make things worse if all that had to be done by a separate PC running FS then all the AI aircraft fed through to the FS PC with the visuals -- for every movement of every aircraft there would be Network traffic and the FS visuals PC STILL has to draw them, which is most of the work. If this isn't what you were thinking of, please explain in more detail. There are ways of having two PCs on a Network both running FS -- you use WidevieW. I suppose the one with the visuals could process the AI traffic, and the other be your flying PC, with no AI traffic, using the AI traffic one for the outside view via WidevieW. I think someone has done this. It wouldn't work with any ATC program of course, but maybe it would do what you want. I still think the bottleneck will be on those visuals. It's all very well having a PC which theoretically can give you high frame rates for your user aircraft computations, but if the images can't be updated fast enough your visual frame rate is still low. I'm afraid most of this stuff is outside my area of knowledge and experience, however. You might like to discuss it with folks on a WidevieW forum, if there is one. Regards, Pete

It shouldn't "lock up" -- the SendMessageTimeout used in the code you call has a timeout 9that is why it is used). There may be several retries too, but it would probably do, say, 10 retries with a timeout of 2 seconds, so in the worst case take 20 seconds. I don't know the VB stuff, but this would be typical -- take a look. All the source is supplied, so there's really nothing hidden here, no mystery. If FS crashes or hangs the problem is usually thatnothing happens. Hence the time-out on the only part of your code which communicates with the FS process -- the SendMessageTimeout. How your program is hanging I don't know, but you should be able to find out by debugging. Regards, Pete

The problem is not so much managing the traffic, though that is certainly a workload, but managing the visuals -- I assume you want both your aircraft and the AI traffic on the same screen at the same airport? The actual processing job managing the AI traffic paths and so on is a relatively small load compared to visuals, as you could prove to yourself by getting just as many aircraft around you whilst cruising, but not near enough to see them all. There are really only three ways of improving performance at crowded, busy, airports: 1. Always make sure that the AI traffic aircraft have the fastest possible visual models. I have read that some of the add-on packages are better than others at this. 2. Reduce the traffic density a bit anyway. Using MyTraffic at the new Aerosoft EDDF I find it still pretty overcrowded with aircraft with the slider set to 70%, but the frame rates are then acceptable. Not great, but certainly okay for landing, taxiing (queuing more like! ) and takeoff. 3. Upgrade your hardware. Both the processor and video card play a part in this. One will be more of a bottleneck than the other, though it isn't easy to tell which. You can help somewhat by terminating all other programs and non-essential processes. Run FS applications on a separate PC (e.g. via WideFS). See what it is like with no panel for your aircraft, too. That eats quite a lot. There are systems which allow you to run FS with no panel and all the instrumentation on other PCs -- Project Magenta, of course, but also look at FreeFD. I have heard of others being developed too, but have no information. Regards, Pete

No -- each click here most certainly gives either a press or release, unless you turn it too fast, then you get a lesser number of "fast" button returns -- the are 4 possible button numbers on each rotary, remember. Two clockwise, fast and slow, two counter-clockwise fast and slow. You can program them all differently, or use the fast ones for "fast" controls (where they exist) or just for multiple controls (for the latter you'd need to edit the FSUIPC.INI file). It sounds like you are turning them fast and expecting each click to be recognised separately? Pete

Correct. Well noticed! However, you seem to not have noticed the explanation, which is actually in the FSUIPC user guide, thus: Nothing. You seem to be just misinterpreting what you are seeing. Regards Pete

Well, you shouldn't really need to use FSUIPC at all. If you find the window handle for the top-level window of class "FS98MAIN", then you can send the controls direct yourself, using SendMessage, or probably safer, PostMessage. You use the WM_COMMAND message for this, with wParam set to your found control number, and the parameter, if any (else 0) in the lParam. This is, in fact, all that FSUIPC would do for you in any case. The only advantage of using FSUIPC is that you would also have available to you all the extra (non-FS) controls FSUIPC has added (see list in the Advanced Users document). Yes yes. you do understand, then, that you don't need FSUIPC for this. It doesn't enter the picture, except as a means of you identifying these PMDG-special controls. Well, I wouldn't have thought so, though PMDG might not be pleased if they were thinking of making a new profitable module themselves for this. But there is likely to be quite a few folks with external hardware and PMDG aircraft who could also program in C. Try asking here, with a more direct (suggestive) subject line, and also in the FS2004 Forum. Sorry, I won't have time at all till late February, and I am expecting other work to crop up. I really cannot accept addiitonal commitments. Have you looked at the C examples of gauges in the MS SDK? You sohlud be able to adapt one. Regards, Pete

Best to scan the Announcements at the top of this Forum now and then, please. Especially notice those which have a recent revision date on them. The latest interim versions of any of my modules will be released there -- look at the very top one. The current interim version of FSUIPC is 3.514. Regards, Pete

Hi folks, I think I've cracked it. The problems occur when the winds FS wants to apply are calm -- i.e. zero knots. The application of direct wind control in FSUIPC is by modification of the existing wind vectors, first to suit the new windspeed, then (in the same frame of course) to suit the new direction. The latter re-orientation is simply done by converting wind vectors to polar, rotating them according to the difference in directions, then converting back to cartesian. All this time I've been studying this and trying to work out what I was doing wrong. the answer was -- nothing! All that part of the code was and is okay! The problems occur when the FS wind is calm. THEN I have to compute the correct vectors myself, from "basic principles". That's where I got it wrong! I have the signs wrong in my sines and cosines, or something like that. This also accounts for the discrepancy when the aircraft is on the ground. It was all my fault! What a twit! :-( As to why it is having such an effect on these upper winds (jetstream), experienced by some here, I suspect what is happening is this. The default global weather in FS has no winds. When you are en route you do, in fact, often go through patches of sky which fall outside of any weather station's zone, or, perhaps more likely, in a zone for a station whose weather has not been set. When this happens, ASV is still trying to maintain your correct upper winds through its direct Wind control option. I suspect this is what it was added for in the first place. Once the FS wind is calm, my incorrect computation of the direct wind vectors applies, and the results are .. awful. I hope this explains everything. All the tests I've carried out here now show everything to be completely consistent no matter what sort of FS winds there are, or aren't, set. So, please discard 3.513 and any earlier version 3.51x) and start using 3.514, available in the top announcement here. Best regards Pete

Hi folks, Well, I have some bad news, and some more bad news. The bad news is that the direct wind facilities used by ASV and maybe other programs only seem to work well when the winds being set this way pretty closely agree with the winds the weather system wants them to be. The way they are used for wind smoothing is usually okay because it is tending towards the way the weather system wants. But it looks like, sometimes (and I simply can't tell when), ASV is asking the direct wind system to set something rather different to the weather. I assume this is some transitional thing to do with layers and /or how FS2004 does its interpolations between weather stations. The other bad news is that THIS IS NOT NEW in version 3.51...... I've been trying to analyse what is going on by going to extremes -- perfectly calm weather set, and a program which sets direct winds of 30 knots, changing slowly all round the compass. To make things really obvious in terms of track and GS/TAS differences I'm using a Cessna cruising on A/P. Mostly, with FSUIPC 3.49, 3.50 and 3.51x the direct winds being set have the opposite effect to what you'd expect -- GS lower when it should be higher, track to the right when it should be to the left, and so on. But it isn't consistent. I am trying all sorts of code changes, but so far I've not found a solution. All I can do is try to find the least horrible method and post this as the next "general release" version of FSUIPC next week. What I don't understand is why this all started cropping up with 3.51, when as far as I can see the problems have been there for many months. Is it simply that folks are flying more in the winter months? It is very strange, expecially when, if anything, the reversal of the direct wind direction in 3.51 should have lessened the adverse effects considerably! :cry: :cry: :cry: Pete

Yes, 2DE0 and 2DE8 to be specific.

Sorry, I don't even understand the terms you are using, let alone what sort of feedback control Microsoft built into FS. I don't know anyway of altering its behaviour other than by the way you define things in the AIRCRAFT.CFG file and AIR files. FSUIPC offers an alternative way of implementing your own control. it provides all the data you need and the control. I even experimented with a bank and pitch control system based on feedback, which works quite well. I tried to extend it to speed control, but that isn't quite so good. All the details are in the FSUIPC SDK. Regards, Pete

That's probably something to do with when and where ASV decises to exercise its direct wind control. I think 3.512 is okay, but I've made one more change -- 3.513 prevents direct wind control on the ground. It is the wind reversal on the ground that I tried to fix in 3.51. I can't seem to resolve it without messing airborne winds up, so by default I'll stop the application program setting winds directly with aircraft on the ground. Look out for 3.513 in the top announcement later today, please, then do all further testing with that. Thanks! Pete

Sorry, this cannot possibly be anything to do with FSUIPC. It has nothing whatsoever to do with the focus of your screen nor the textures of your clouds. The wind changes are a problem only with 3.51. They are fixed in 3.511 and 3.512, available here, and in 3.513 which I will upload here later tonight I hope. Pete