Pete Dowson

No! You can install additional programs on any hard drive you like. Simply do not accept the installation path suggested by the installer. I have FS installed on my "E" drive, for example, which is a partition on my 2nd hard drive. Most of my larger scenery installs are on another drive altogether. There is no restriction on installing programs and data whilst you have space somewhere on your system. It is actually inadvisable to install larger applications on your main system drive (normally "C:") as each install tends to want to add something to the registry and sometimes some drivers and DLLs to Windows, so you always need space there. Do not just allow all FS add-ons to install themselves inside your FS folder. Regards, Pete

No. There's no point in using WideFS within one computer, because its sole function is to link FSUIPC applications to a copy of FS running on another computer. All your FSUIPC applications will see FSUIPC with FS running on the same computer in any case. What is there for WideFS to do in such a case? What are you trying to achieve? Regards Pete

Please see the sticky thread near the top of the forum READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys. Pete

Yes, a little. Probably not as much as I should. Life is too short. But I do take quite a few holidays. I'll be away again in a weeks or so. ;-) Regards, Pete

Why? That's 100 times per second! Is that the frame rate you get in FS? I think you need to be more reasonably -- most of the stuff won't even be changing every frame, let alone at two to four times the frame rate. FSUIPC is only processing things once or twice per frame at most. Oh, on WideFS? You'll only be loading the local Client then, unless you are writing stuff too frequently too -- WideServer only sends changes in any case. If you ran your program on the FS PC I think your FS frame rates might plummet. Can you tell me the actual offsets you are reading, and their size? If you are classifying them as "BOOLEAN" in your program and reading them as such, it would explain your problem because: 036C Stall warning -- is a single BYTE (char probably in VB). 036D Overspeed -- ditto 0840 Crashed -- is 2 bytes (a "short" if you like) If you are reading these as 4-byte integers (which is what a BOOLEAN probably is in VB, then you are getting unrelate values in the other three bytes! PLEASE PLEASE PLEASE always use FSUIPC's IPC read/write logging to actually CHECK what it is your program is doing!! I cannot emphasise this enough. I spent a lot of time building in all these EASY ways for you to work stuff out -- you should be using them! Please? You could even try using FSInterrogate a little more too. I see you actually mentioned it. WideClient talks to WideServer. WideServer talks to FSUIPC. There is no way WideServer can lose its connection to FSUIPC, they are both within FS. If you mean wideClient, then it never itself uses 100% of anything, but your program probably will. If you are calling it every 10 mSecs then a lot of that 100% processor time is spent switching processes back and forth. I doubt if your program is even relaxing enough to process its messages is it? If there's nothing else going on in the client (no other processes to run), then, yes, of course wideclient will soak up the spare. It's multithreaded and its background thread is constantly checking things. If your program was doing anything (which presumably it isn't because it isn't getting new data) then the two between them would use 100% unless you had somerthing else also running. FS itself consumes 100% even when doing nothing .. or 50% on a dual processor or hyperthreading system (as it only uses one "processor"). Regards, Pete

I'm afraid that all I can offer in the VB arena is whatever is contributed in the FSUIPC SDK. The simple examples there should really be enough to get any programmer going, though probably not a beginner. Interfacing to FS isn't really a good learning ground. I expect, once you get underway, if you do run into any problems and post specific questions here, someone who knows VB will pop up to help. As per the announcement or sticky above (in this Forum), you'd need to apply to me via the email address given there. But please read the Access Registration document in the FSUIPC SDK first, especially section 4 onwards. Regards, Pete

That's okay, that is my policy for inclusion in any case. My confusion arises only from the fact that it is the GAUGE(s) which are the recorded FSUIPC users, and of course I have an index of those. I just don't know the end packages they are used in! Duh! You are okay, please carry on. I was confused, is all, especially with the version 2 and password (?) reference. I suspect this user is misinterpreting something somewhere. Happy New Year & Best regards, Pete

I'm afraid this is really a matter for SB support. Are you sure you are reading this stuff in the right place? If SB3 is setting FS with different winds to those it reports then there would be a lot of folks (all SB3 users of course) with such problems. Maybe you are confusing the levels and places where winds are reported? Try checking with WeatherSet2 -- it will give all the weather details both at the aircraft and for any selected weather station. You should be able to relate what you see in FS with what is being set. All FSUIPC can do is pass on the weather requests from SB3 to FS. It is an interface program, not a weather creator. The only interference it may make on winds AT the aircraft is with the smoothing and limiting options -- check the Winds page in FSUIPC. However, if you aren't user registered none of those options will be on. Regards, Pete

You are using FS2004 update (9.1) and have downloaded and installed an older add-on, designed for the original FS2004 release, which carried an out of date version of FSUIPC. Go to http://www.schiratti.com/dowson and download FSUIPC.ZIP. Read a little of the user documentation therein. Regards, Pete

No, because FS normally does that for default aircraft. I assume this is a problem with an add-on? The secret is to calibrate the axis with an area at both extremes which is "dead" -- one at full throttle, the other at idle. Then simply park the throttle when enaging A/T. I normally park it at full on climb and reduce it to idle on cruise, ready for decent. Other things to try include the FSUIPC filter, which may help if the jitter interference is quite small, or programming a button or key to disconnect the throttles manually -- see the drop-down list of controls in FSUIPC Keys and Buttons pages. There are three -- Throttles off, throttles on and throttles toggle. Regards, Pete

Very true. It's all a bit like an arcane art to me. I experiment and when something works I stick to it! You may find it easier to recompile the library in VS2005 instead, or even just link the code directly -- the source is provided, it is yours to do with as you like. My part of FSUIPC really starts on the FS side of the interface. ;-) No doubt one day (later rather than sooner I hope) I will have to upgrade to VS2005 (if only for the 64-bit compiler), but ceretainly not yet. Regards, Pete

Hi Doug! In that case that FSUIPC is obviously legitimate, and this user's very old version of FSUIPC must have been installed by some other package, and marked read-only -- which would have prevented yours replacing it. That, or this gentleman is getting himself very confused somewhere. Thanks! Happy New Year by the way! Pete

orry, I cannot support such old versions of FSUIPC. Please update to 3.53, see http://www.schiratti.com/dowson. Regards Pete

In FS2004 FSUIPC cannot work on the turbulence, gusts or variance like that. It can only filter them out when they are being set by the weather program. The best that I could do is to stop them being set (by the weather program) when your aircraft is on the ground. But then that omission will likely be continuing until the weather program refreshes weather. Once local weather is set into FS I cannot change it, it has to be completely reset again for the relevant weather stations, and weather programs try not to do that for nearby weather stations because it causes stutters and cloud flickers. The same would apply after landing. Whatever weather was set by the time you touched down would continue. Even if I cut out turbulence et cetera after that, it is unlikely that the weather program would resend it. If it did, you'd get a stutter. The weather programs themselves could do it better, cutting out the turbulence initially whilst you are on the ground, but allowing it in any new weather being set after take off -- even then it could take a while flying till you reached the distant stations which have been so set. On approach I can't see how it could be done properly at all without introducing stutters, sorry. Maybe this is something for a future version of FS. Though by then you'd certainly need a more powerful PC in any case! ;-) Regards, Pete

I'll re-check here, but I'm pretty sure that my code is simply dividing one of the values into the other at the same time it stores them. Please check all three values in parallel. The time to station should be changing any time either or both of the others do. You can log them as they change to the FSUIPC.LOG file using the Monitoring facilities in FSUIPC -- see the Logging tab. No. Having two separate values to the same display is way outside of the scope of the program. It is out if the question at this time. Sorry. Regards, Pete

This must be because the aircraft panel gauges you are using are continuous sending controls to FS -- FS needs the very next control after the E to be the 1 or 2 keypress, but many add-ons are sending controls every few milliseconds, defeating this. The same sort of thing happens to pushback (Shift+P then 1 or 2), and to aircraft door operation (Shift+E then 1, 2, etc). FSUIPC does have an option "control acceleration fix" on its technical page which, since FSUIPC 3.45, gets around this. It works for engine selection -- there's a time limit on pressing the numbers though, defaulting to 4 seconds. There's a Hot Key provision for restoring control to all engines -- it is called "Resume all engine control" (Hot Keys tab). Not "noise" so much as other controls being sent to FS's sim engine. Well, it sounds like you were looking for the wrong thing. Read the paragraphs in the bit about "Fix control acceleration" (on the Technical tab window). Especially the NOTE about additions made back in version 3.45 of FSUIPC. Apart from the easier "switch it on" option mentioned above, you could actually program it on a keypress or button, using information gleaned from the FSUIPC advanced user's guide and the table of FSUIPC offsets found in the Programming guide (part of a separate package called the FSUIPC SDK). It would be done by using special offset writing controls added in FSUIPC for just such complex needs. But unless you are a programmer, or at least pretty computer literate, I'd stick to the easy option already mentioned if I were you. Regards, Pete

Yes, they aren't actually simulated in FS itself, that's why. You are probably looking at some add-on implementation. Regards Pete

You didn't need to do that! You could have merely re-installed and re-registered FSUIPC with your original details. Not all of the contents, I hope? You only want the FSUIPC.DLL file. The rest is documentation and additional optional utility programs. What version of FSUIPC were you using with your Elite hardware before? It is not a package I know, but apparently there were incorrect version checks in some Elite drivers. If it is an early version see if there's an update. You may need to contact Elite about it. You should of course also check that the Elite drivers are working correctly on WinXP -- again, depending how they drive their hardware they may have had to make a new version for XP. If you want me to confirm that it is the Elite drivers which have the problem, please enable IPC read and IPC write logging in the FSUIPC options (Modules menu in FS, FSUIPC, Logging tab). Run the Elite driver, see it not working, then close down FS and show me the FSUIPC.LOG file you will find in the FS Modules folder. If it is too large to display in a message, Zip it and send it to me at petedowson@btconnect.com. Regards, Pete

Mr. Schiratti doesn't frequent this Forum. Perhaps I can help. I haven't heard of "rcbco-20". What is it? It must be several years old, and intended for FS2002, not FS2004, because FSUIPC version 2 is that old and never worked with FS2004. Additionally, packages which include my FSUIPC should have applied for permission before doing so. I'm not surprised. That really is a bad package you have got hold of, then. Nothing installed that way should ever be read-only. That cannot be anything to do with FSUIPC as such. I've never used passwords. To delete a read-only file you just need to uncheck its read-only attribute in the Windows file properties (right-click on the file in Explorer and select Properties). Again, there is no such thing that I know of. This is something to do with your "Rcbco-20" package. I can only suggest you try to contact the author. It isn't a virus or worm you've installed there, I hope? It doesn't sound very healthy. Regards Pete

Hmmmthat's certainly a new one on me. I've not heard of that before. Do you often have turbulence and gusts? They don't seem to be so frequent here. This seems to be the exact reverse of what you really need! Surely, when flying close to an airport, especially on approach, you want the highest frame rates you can get -- why would you want high frame rates for easy manoevres like taxiing and low stuttery ones for challenges like landing? Regards Pete

Hmm. Someone must be rather poor at translating English into German then. ;-) 3.53 simply solved a problem with NEW registrations entered after 31st December 2006. It was merely due to the unexpected continuing development of FSUIPC 3 well beyond the two years I'd originally assumed would be needed. Certainly once FSUIPC 4 comes out, if there will ever be one (still to be determined as I explained), then NEW registrations will no longer be sold for FSUIPC 3 -- unless I cannot for any reason keep FSUIPC backward compatible with previous versions of FS. At present there is no thought of expiring existing registrations, it would only be the support and development which ceases as technology and software move on. Regards, Pete

i don't think it's possible -- I never found the place to hook for it. But the Flight file saved with Radar Contact restart information should certainly position you at the place the aircraft was when the flight was saved. That's the whole point. You should be using Radar Contact to reload the flight for you -- it will reload the flight, the weather and all of its own saved data! There's a button on its main start-up window for this. Do NOT load the Flight in FS, just tell RC to do it. Regards Pete

Okay. I've done some code already. I''m out tonight, but I'll test it a bit in the next day or so then send you a copy to try. Regards, Pete

But 4,261,696,370 is not a possible number in 32-bit signed format. It is FE045372 in hexadecimal. The top bit is set (2^31) which is the sign bit. The value is actually -33270926 in decimal. ((-33270926 / 65536) * 360) / 65536 = -2.7887368 according to my calculator. [My calculator has only 8 digits so to maintain accuracy I split the two divides as you see -- you could do the same to keep it all fitting into 32 bits. But it is best to convert to floating point in any case, keeps your fractions]. Well, if it started with a -ve number it must finish with one, else the compiler is in error. Sounds like, if you don't have a bug, Microsoft does! Regards, Pete

Really? no one has talked to me about this, yet. I believe you are the first to mention it. Well, two points of clarification there: 1. I cannot actually guarantee to provide a version of FSUIPC compatible with any new version of FS. That just isn't possible, as it may turn out that the things I do to hook into FS cannot be done with a new version. This happened with CFS3, for example. All I can do is promise to do my best. 2. Whilst I would try to make a compatible release "close to" (i.e. soon after) the release of a new version of FS, this does depend on many things -- like how much has changed, and whether I was lucky enough to be invited by MS to be part of the Beta team. If things are difficult and I am not involved before release, then there could be quite a long gap. Possibly, or quite likely, yes. You are quite a bit ahead of me really. For instance, maybe a renewal of a licence will be possible at less than a full new fee. It really depends on the amount of work involved in making the new version, if it is possible in the first place. If it is as much work as FSUIPC 3 was, then, yes, I am more likely to say that renewals will cost the same as new sales, except possibly for sales in the few weeks or months leading up to the new release. Yes. Of course, though support for older versions will dwindle -- once Version 4 is out I shall not be adding new facilities to 3, that's for sure (just as I do not support version 2). But it also depends on what exactly version 4 is. I may even split off the user-facilities parts from the application interface part -- users only pay for the former in any case. It seems reasonable, though very premature as no decisions have yet been made, nor can they be until I know more about the future. ;-) Could you tell me why? What is it that you are worried about at this point in time? Just because it is now 2006? Regards, Pete