Pete Dowson

It occurred to me that what you might mean by "thrust vectoring" is actually asymmetric thrust -- i.e. one engine providing more than the other? I tend to think of "thust vectoring" in terms of things like the Harrier jump jets. If you are getting asymmetric thrust with the levers set the same, you could try re-calibrating them to be a bit closer. However, you will never get two pots giving exactly the same readings all the way along, even if the ends are exactly right. So always check the readsouts for N1/N2, or EPR, or RPM, or whatever your particular aircraft measures engine performance by. There is also a Hot Key you can program (in a Registered FSUIPC) which enables a throttle sync function. This actually copies the throttle 1 input to all engines, so you are then bound to get identical performance from each, all other things being equal. If you use this just remember to toggle it off when you want to use asymmetric thrust to aid in ground steering! Regards, Pete

FSUIPC doesn't provide any such facility, but you can easily switch those off in FS9 -- try the Options-Settings-General menu entry, uncheck "Show cockpit tooltips". Regards, Pete

Download them again from http://www.schiratti.com/dowson. Naturally if you completely re-install FS and deleted the original you will lose everything you installed into it in the first place. Next time you want to do such an extreme thing, use the FS uninstall but do not delete anything it doesn't, then install again to the same place. That way all the additions will be retained. FSUIPC and WideFS are always available from the Schiratti site in any case, and 3.04 is pretty old now. Go get 3.11. I hope you saved your FSUIPC.KEY file some place safe, else you'll need to re-enter your registration details too. Regards, Pete

Sorry, no. I don't even understand the term "thrust vectoring". It sounds like you need to talk to someone who knows something about the specific aircraft model you are flying. There is no difference in PFC throttle inputs between aircraft. It's just straight forward throttle axis position converted to throttle control value. Same with all aircraft. Watch the throttle lever positions on the FS panel graphic. Regards, Pete

Why did you delete your FSUIPC.KEY file? When you upgrade from one version 3 to another you only need to pop in the new DLL. No re-registration is needed unless you delete the KEY. All you need to do now is re-enter all the details EXACTLY as originally suplied, same name, same email, same Key. Everything must be exact, character for character. Pete

Version 3.11 does this fine. Pete

I doubt if playing with that will ficx the problem. Maybe reomving or changing other modules will. The "initdelay" value simply controls how long after being loaded FSUIPC subclasses the main FS window so it can receive messages from client programs. In earlier releases this defaulted to 3 seconds, but with experiments here, on my system, I found that reducing it to 0 helped. But it only helped when I also did the same in AdvDisplay, PFC.DLL and removed Lago's ViMaCore2004.dll. Any on of those would give me the same symptoms. I think there is some timing problem, probably in DirectX9, which is affected by small changes in the order or timing in which certain calls are made. These will be all from FS itself, as none of the modules I mentioned has anything to do with graphics or DirectX. You can read a lot more about all this in other threads. I think we are all hoping MS will some time release an update for DirectX which wil fix it -- judging by results from saearching the Web it isn't confined to FS but affects a lot of DX9-based graphics games. Well, it is really up to Peter to explain that. I didn't want to do it and I do not support it, and I certainly don't appreciate it being published openly. It simply tells programs that they are running on FS2002 instead of FS2004. This will wreck the facilities in some (e.g. FSMeteo), but apparently it is needed for one of the gauges in Peter's panel which checks for FS2002 else won't work. It would be better to fix the gauge, as it is evidently checking needlessly for FS2002. Regards, Pete

I don't know Delphi -- is "single" a 16-bit unsigned integer, because if it isn't there's your first mistake? The heading at 07CC is! Then, if you divide a 16 bit value by 65536 you are bound to get a fraction and you can't hold fractions in a 16-bit integer. Try copying the value into a floating point variable before you do the conversion. If a Delphi "single" is a 32-bit "float" then you cannot read the 16-bit integer directly into that and expect it to make any sense. Floating point formats are completely different. Regards, Pete

I think the only way to tackle that would be to try to detect the window being created (probably by some message intercept) and change the size on-the-fly. However, whilst I can probably do this for any window (the "stop resizing and moving" facility is related), positively identifying the correct window may be a problem. I'll add it to my list for looking at, but it will be a couple of weeks yet - I am away from next Thursday for a week and have quite a few things to do before then. Regards, Pete

All that does is tell WideClient not to simply return to the application with whatever data it has in memory (zero) if the offsets are ones which have not yet been read from the Server. It actually makes WideClient loop, not returning for that amount of time (1000 = 1 second, the default is 500 I think) unless the data arrives. It really only affects the application initially -- with something like PM, all the components are asking for the same things over and over. Once the Server has provided them to the Client once the WaitForNewData won't apply any more -- unless you close and restart the WideClient, or unless you are getting the links reset (which would be logged at both ends as a new connection). So I really don't think you'd notice any differences unless you were having lots of resets, which is bad bad bad anyway, Regards, Pete

Thanks. That explains why I don't see it. Regards, Pete

I run PFD on a PC with three screens connected to a Parhelia. I have three copies of PFD running in that one PC - PFD/ND1, EICAS, and PFD/ND2. Up until recently it was 'only' an Athlon 700. With the PFD parameter "UseTimer=Off", as I always ran PFD before, this was a complete flop. Very very slow and jerky. I don't know what they were doing, but they certainly were not co-operating with each other. When I set "UseTimer=On" in each of the three PFD.INIs, they worked fine, but there were still occasions when one or the other would stutter or even stick for a second or two. I think that this was due to simple competition for the attention of WideClient. The 4 processes just refused to run smoothly. WideClient was happy enough, but the PFDs battled each other. When I upgraded my FS PC I had a "spare" P4 motherboard and 2.4GHz P4, so I put those into this PFD machine. This helps enormously and I now see barely a whisper of a stutter. I still have to run with "UseTimer=On" in the two PFD/ND copies, but I've reset the EICAS one to "Off". Don't ask me why these things make a difference. I'm telling you all this because I think experimentation to find a happy setup is important. BTW, I've been pressing Enrico to make me a version of PFD which will support all the instruments -- PFD/ND1, EICAS1 or 2 (switchable), and PFD/ND2, all in one window, or maybe separate windows but one process. Since they really all use the same data from WideClient, having a single process and not all that competition should make it perfectly smooth! :wink: I've a feeling that the Aerosoft control program is not such a good program for cooperating with others, or maybe it is vice versa. I actually run it on a PC on its own (well, I also run FliteMap on that, as a moving map connected to the FS PC using GPSout, so it isn't using the Network). Theoretically, the Aerosoft program should run best on the FS PC, but I had no COM ports left on that and the USB-COM port program wouldn't run on Windows XP. Now that my main FS PC is a P4 3.2GHz, one of those with two virtual processors ("hyper threading") I moved the PM MCP program to that PC, and it runs fine there. I always preferred to have the MCP right in the FS PC because it gets the best response there (naturally) -- the PM MCP acts as the 'clearing house' for many of the PM messages -- but I was never happy with the results on a lesser PC. Hope this gives you some ideas. Regards, Pete

Well of course you can use FS's own downloads for that. They're not at all as bad as they used to be in previous versions. Oh, I see. Yes, indeed that must be a consideration. Even so, assuming that your FSMeteo PC and FS PC are not so far apart, it might be worthwhile using 100mpbs between just those two. Or can't you mix things like that? I don't really know. Alternatively I suppose you could just put another Network card in each of those two and leave the 10 mbps Network in place as well. Regards, Pete

You are quite welcome to add a link to this Forum, which is really the only "website" I have. You can copy the logo and link from the FSUIPC documentation. If you mean the "dowson" page at http://www.schiratti.com/dowson, that is actually part of Mr. Schiratti's website. I don't have a logo for it, but I guess you could adapt the other one. Many sites link to that page for FSUIPC in any case, so I don't think Enrico will mind, but if you want to check you'd need to write to him at support@schiratti.com. Thanks & Regards, Pete

Ah, you mean Sascha Felix's "FlightSim Commander". Yes, I do know of that one. It does use FSUIPC. If you have a plausible reason for a lost key I expect SimMarket can find it and re-issue it for you if you ask customer services at http://www.simmarket.com. Explain it all to them. You'll have to use the same name and email address as you used the first time. FSUIPC 3.11 is now released and available on http://www.schiratti.com/dowson. Regards, Pete

As I said, even with it off the weather is dynamic. i said that in my reply, but for a longer discussion on the subject please see the notes on this in the IMPORTANT announcement above, or at the end of the FSUIPC user guide. No,no. You misunderstand. That is what you are telling FSMeteo to do. But then it feeds weather into FS as you fly. For it to inject all the weather into FS at the start then disappear is something else entirely. When I say "check the network cards" I mean swap them about, change them, replace them. You say that upgrading to 100 Mbps is not an option. I'm sorry about that, though I see 10/100 auto network cards so cheap these days, cheaper even than FSUIPC! :D In fact a decent Cat5 cable is sometimes more than the Network card! Regards, Pete

Version 3.04 is not so old, and it was also a "pay" version, but only if you want all the facilities. I don't know "Flight Command" nor, therefore, whether it even uses FSUIPC. But FlightTracker and FSMeteo work because they have access keys -- you don't need to pay for fSUIPC for those. FSNav is nothing to do with FSUIPC, it doesn't need it or use it. The short answer, really, to your question is to ALWAYS use the latest version of FSUIPC, whether you pay for the extra facilities or not. The latest version changes this weekend -- version 3.11 is just being released. Regards, Pete

Okay, thanks. It was a lucky guess, I think. Odd, though, that this potential problem has been there for years with no one complaining. Never mind. I could see what might happen, but I couldn't see it happening at all here. Must be very timing dependent. I'll probably release an update to WideFS in due course, but I am away for a week soon so I might do it when I get back. Regards, Pete

It sounds like weather dynamics rather than interpolation. I'm really rather baffled by some things that happen in FS2004's weather system. Certainly, if FSMeteo set the weather at EKYT some time before, then the weather is likely to be somewhat different when you get there. Clouds blow away, wind directions change as the air mass moves. However, if FSM has set the EKYT shortly before your arrival it should be okay. These changes seem to occur even if the Weather dynamics slider in FS is set to minimum or not (FS Meteo by defaults sets it to minimum). If it is set to give changes they occur even faster. Did you tune into and get ATIS weather reporting? As in the real world I tend to think that's the only way you can deal with the more real weather in FS2004. Well, for something as heavy as FSMeteo a 10Mbps network is really asking for trouble. There's a lot of data needed for all those weather stations it sets. But even so, FSM will always take some time. This is because, for each weather station, FSM has to send the data, then wait for FSUIPC to confirm it. FSUIPC only does this at most on each FS frame, and more likely every few frames. This is partly to avoid stopping FS whilst the weather is being set, and partly to make the data management facilities in FSUIPC more usable. When you get 50-100 weather stations being set (and in crowded parts of the world this is possible) it will take many seconds. However, FSMeteo is cunningly designed to set your nearest stations first, then it gets further and further afield. If you are preparing a flight at your departure airport it should be pretty well ready by departure time. The only alternative to this sort of approach is to do the same as FS's own downloads -- load the whole world's weather before you start, then disconnect, or just feed small updates every 15 minutes. I can provide a "bulk load" option, probably via a file, but I really don't see the point and no developer actually asked for this. Anyway, the answer is -- yes, a faster network is really needed for this sort of application, but, no, you won't necessarily get the weather being set that much faster (though you haven't actually said how long it takes). Maybe FSMeteo wouldn't do so many retries. Well, unless you stay put for a few minutes you should not expect any external weather program, designed to try to set your weather almost imperceptibly as you use the Sim, to keep up. I don't like these blocks getting lost much: 201656 GetRecv() missed block? Sequence 1258 jumped to 1260 207505 GetRecv() missed block? Sequence 1313 jumped to 1315 500461 GetRecv() missed block? Sequence 3812 jumped to 3814 506330 GetRecv() missed block? Sequence 3904 jumped to 3906 506945 GetRecv() missed block? Sequence 3913 jumped to 3915 513011 GetRecv() missed block? Sequence 3997 jumped to 3999 515256 GetRecv() missed block? Sequence 4027 jumped to 4029 519355 GetRecv() missed block? Sequence 4076 jumped to 4078 You shouldn't be losing blocks like this. If it happens regularly I'd check your network cards. Of course it might just be that the data was piling up in the Send buffers on the Server because the Client couldn't get data out fast enough. however, this doesn't seem that plausible. Regards, Pete

Are you sure Active Sky only sets global weather? I thought that was changed. Even so, I think the problem is that in FS2004 no weather stays global for very long. Once FS localises the weather FSUIPC has no control. There's an section about the problems with global weather in the IMPORTANT announcement at the top of this forum, and also at the back of the FSUIPC user guide. At present I am still considering whether to withdraw this feature for FS2004 or leave it in in the hope that it can be made effective at some stage, when perhaps more is learned of the new FS weather engine. I am, however, now very confused about what the new Active Sky actually does. I only have an earlier version which is definitely Global only (in fact it uses the old FS98 interface). I thought Damian was now using the New Weather Interface, like FSMeteo? Regards, Pete

Well, I'm running FSNav 4.6 in FS2004 and I've just searched my whole drive for an "FSUIPC.txt" file, without success. Mind you, I don't use FSNav very much, I must admit. If it isn't doing any harm I wouldn't go to great lengths to eliminate it, it is more a matter of curiousity than anything. Regards, Pete

Sorry, no I didn't -- there were two new messages, and the button gadget on the Forum takes me to the last one, it seems, not the last one I haven't read. Sorry. Really it is not very good for me, you paying such an amount direct in Euros -- the charges made by the bank are too high and the exchange rate is abysmal. If you cannot pay by SimMarket, can you say why? If you want to pay me direct I would like to know the reason as I have agreed with SimMarket primarily to save me all that sort of hassle, leaving me to program. :) If you want to discuss this further it would probably be better in private -- use the Email button. Good ! Well done. Good flying! Pete

But did nothing happen too when you did this in FSUIPC's calibration page? Or did the values shown as "IN" change? The thing that matters is the OUT value shown in FSUIPC. That should, when the axis is correctly calibrated, extend whatever range you have coming in, to all the possible ranges for that control. That is, in fact, all it does -- maps the input range, no matter what it is, to the complete output range. It really doesn't matter to it at all what the input values are. It sounds like you found the calibration more natural with the alternative input, but that may be because the left part of the BRAKES range resulted in no input values changing, though I've never seen a case like that. The only other alternative explanation I can think of is that you have enabled FSUIPC's brake calibration as well. That could make some odd things happen I should think! :? Regards, Pete

Ah .. I have that installed on one of my PCs. I'll go look, se if I have an "FSUIPC.TXT" in my Temp folder too. Thanks! Pete