Pete Dowson

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

Not I, sorry. I tend to go backards and find older drivers if I have any nVidia driver problems here. Or, just stick to ones which seem to work well and never upgrade. I only start looking at new drivers when I upgrade PCs or video cards, which is about as often as new FS versions. Regards, Pete

Yes, I understood that. Probably because IVap is setting winds via the Direct Wind control. You still have not shown specific examples for the airborne problem you mentioned with 3.512. This is getting urgent! I must resolve it in the next few days. I cannot reproduce anything odd, when airborne, here at all. Please tell me the figures I mentioned, when airborne with 3.512. Yes, as I said, this is the problem which has always been there, and which I tried to fix in 3.51. It was this that has caused the problems here reported! It now looks to me to be unsolvable. I am currently testing a version of FSUIPC (3.513) which is the same as 3.512 except that it automatically switches off direct wind control when on the ground. Regards, Pete

Thanks. It should be the same, but I am testing a slight modification (which will be 3.513). It suppresses the direct wind control whilst you are on the ground. Since the wind direction set by direct control is 180 degrees out when on the ground, yet okay when airborne, it actually presents a bigger change or risk on takeoff, so, since I cannot fix the ground problem I will prevent it instead. There will be a parameter to undo this if needed, but I hope it won't be. I'll put 3.513 up as soon as I'm happy with it, maybe tonight. Regards, Pete

Ah, yes, in that case it certainly would indicate something odd with the pedals. Try enabling the Axis logging in FSUIPC (Logging page, one of the checkboxes on the left). Just enable it then slowly press left rudder, then disable it and view the FSUIPC LOG. See if there are any "out of order" values on the AXIS_RUDDER control. The eliminates extreme spikes, max deflection, which were actually inserted by some of the add-on aircraft in FS2002 9the 767PIC was one, I think). I never new why. I doubt if it will help here, though you can try it without harm. What may work for you is the FSUIPC Filter option, and maybe the Slope option to get a flatter area near rudder centre. For these you'd need to calibrate the rudder in FSUIPC of course. Whether it works really depends on what sort of incorrect value the rudder pedals are giving. Also check your rudder trim is centred. Not all of the aircraft have a rudder trim wheel, but find one that has and centre it there. It should stay centred for all, then, at least until you load another Flight with a different setting. Regards, Pete

Is this is a light aircraft, a prop? Maybe its some gyro effect of the way the prop is turning. This seems likely as, you say, it only affects turning left. Are you sure it isn't realistic for that aircraft? It happens when TAXIING!??? Phew. Don't know what that is. Sounds like the tyres don't have much grip!? No, nothing at all. I would check your aircraft realism settings if I were you -- in the FS Aircraft menu. Many of the effects are overdone to say the least. Try setting the sliders somewhere near the middle. That seems to give the most realistic results for most light aircraft, though it does depend a lot on the modelling. You'll find some really good professionally designed aircraft for FS are a lot better than the default ones too. Regards, Pete

I think you are still misunderstanding something. The protocol you are talking about is one used by GPS's to get more accurate positions vis differential signal analysers. Even the first lines of the place you point to shows that it isn't anything to do with the initial job of telling the GPS where it basically is: Differential corrections are are way of using multiple signals to make an original measured position even more accurate. They are used by surveyors and the like for plotting positions for building foundations and so on. Sorry, but I don't think any of this is relevant to the simple job of getting an FS position out of a PC and into a GPS, bypassing all of the GPS receiver functions. Trying to send differential correction signals to an operating GPS, to make its satellite measured position more accurate, certainly won't tell it where the FS aircraft is in the PC. Pete

It definitely sounds like a faulty video driver. Check it again when an update is available. Regards, Pete

That is only because, in general, it is more efficiebt. If you alow the system to assign them, then all the PCs periodically send out inquiries about the connections that exist. This creates more load and stuttering in FS. It really isn't related to anything in WideFS or WideFS needs at all, only FS performance. Are you using a router? Just reconfigure that too -- give it an IP address and turn off its need to search for IP addresses. Regards Pete

I think that is a specification reference for connection of external GPS aerial/receivers direct to a GPS. It relates to something called the "differential NavStar GPS service". See http://www.navcen.uscg.gov/pubs/dgps/rctm104/Default.htm I certainly don't think it is anything you can link to a PC nor drive with GSPout. Sorry. Regards, Pete

With FSUIPC 3.512 and a default Cessna, setting direct winds at varying directions, the head/tail/crosswind effects are all perfect in all my testing here. Can you please explain how you are measuring these odd things in the air? Check with the GPS, for instance. With an indicated wind (use Shift+Z) to your left the GPS TRK should read to the right of your heading, and vice versa. With a tailwind, the GS shown in the GPS should be higher than your IAS, and vice versa. All these things are true here. If they are not there please give actual examples, i.e. Wind (from Shift+Z, as MagDir / Speed -- ef 120/20 = 20 knot wind from 120 Mag) IAS from your instruments. GS and TRK from the GPS. As for the ground winds, I know they are 180 degree reversed. I am thinking of stopping the direct wind working altogether when on the ground. There's no way I can find to fix it. Regards, Pete

By "5.511" I assume you mean "3.511". Hmm. 2 out of 3 doesn't make sense. It either works or it doesn't work. By default, version 3.511 will operate exactly like 3.50 and before. How long have you been using FSUIPC and IVAO? I don't think this is new at all? I don't think the ground problem is fixable. I tried to fix it in 3.51 and it was that which caused all this. I'll see if I can do some checks here. It sounds like the IVAO software is using "direct wind control", like the option in ASVE. Does the IVAO program have an option someplace to turn that off? Not the winds, just the direct control? If so, please try that. Regards, Pete

On the ground? Or in the air? If in the air, and this is with FSUIPC 3.511 or 3.512, then that is weird, because that is just the opposite of what the others have been saying. If it is with 3.51 then change to 3.512. If with 3.512, please try 3.511. Regards, Pete

Oh, two quadrants? For the same console, or two separate consoles? If you simply mean you have two of the replaceable quadrants for the one console, then there's nothing in those to go wrong really -- they are just the levers. The console has 6 lever positions and six axes and six pots to match. If they work, they work with any quadrant. But you also said your rudders weren't working either. Are they connected via the same console? I'm afraid it still sounds like you need to talk to PFC. Pete

Something else is happening there, as FSUIPC has absolutely nothing whatsoever to do with graphics. The exchange of FSUIPC versions can only be a coincidence, or a simple change in timing of something in the graphics or in the memory arrangement. I suggest you try different video drivers or try different settings. Regards, Pete

Incidentally, you did not clarify the confusion in your earlier message, where you said on the one hand that you couldn't calibrate the throttles, and on the other that they worked fine! Which is it? I still don't understand that. And did you get the later version of PFC.DLL (1.989)? Regards, Pete

Don't enable throttle sync unless you really don't want to use the throttles independently! Have you contacted PFC? It really sounds like you have a hardware problem. Even the simple automatic calibration facility in PFC.DLL will make it very usable. You need hardware support. Pete

Version 3.511 or 3.512? Please don't test with 3.51 -- see earlier messages in this and other threads. Regards, Pete