Pete Dowson

It is a protocol error in an older version of RC. I'm pretty sure it is fixed now and has been for some time. I use RC and ASA for every flight and haven't seen this error for a couple of years. Mind you, I am now using FSX only, and ASA isn't using FSUIPC with FSX.. Well, sorry, I do not support old versions of FSUIPC in any case. 3.93 is the earliest supported version. When did you post on the RC Forum? I visit there regularly. [LATER] I found your post -- back at the beginning of September. none since. There were several suggestions made for you to follow. I've also checked al the references to this error on that Forum, and not one of them blames FSUIPC, so I don't know where you can get that from. It is well within the RC developer's capability to fix this once and for all, and I thought he had done so. No. Anyway, not with 3.81 for sure. The problem is that RC thinks it is not seeing a timestamp update when it is reading information about AI traffic, but in fact i think it gets out of step and has got the ocrrect timestamp but missed the one before -- but that was fixed, I thought. In any case, it shouldn't be a critical error, RC should be able to continue regardless. Having it stop on a Message Box is a bad idea, and I've told the developer this. As I say, I thought it was fixed. Please make sure you are using a supported version of FSUIPC before posting again. Thanks & Regards Pete

Very strange. Is this with the FSUIPC facility turned on or off? Have you tried it off if on or vice versa? True, as IE8 is installed here too, just never used. My FS9 test is still running -- it is now about 1 minute slow! Regards Pete

With only FS running, nothing else? I doubt if it's related just to what you are doing. Well, you can try FSRealTime. It will do the job. But there's a catch. If it ever has to correct times by more than a minute, FS will reload textures, causing a hesitation in the timeflow in any case, and a progress bar on screen. Pete

Good, because mine is pretty boring: the time in FS after 30 minutes was still correct, at least to the nearest minute (and that's without the FSUIPC option running). So it isn't a sudden Windows change in the "tick" interval. Obviously something must be happening to the mechanism FS uses to count time when IE is running. Maybe IE changes something in Windows which causes the tick interval to decrease. I haven't used IE for years. My choice is FireFox, and I was using it the whole time FS9 was running in my test 30 minutes. Anyway, on my flying PCs (this is my test and development one), I wouldn't be using anything other than FS. I don't think that's it, as I've just done that and noticed no problem in FS's clock after 30 minutes of using FireFox. Try using a different Internet browser. Maybe it's a bug only in IE8? Regards Pete

Sorry, I missed that bit. And I don't understand it. If you see the minutes and seconds keeping in line, when do they go out of line. Do you mean they only go wrong when you're not watching them? Pete

No, but doing some research on MS websites I see that most folks seem to think that the "GetTickCount" resolution, which used to be about 55 mSecs in Windows versions till Windows 98/Me, appears to by nearer 1 mSec these days, but with a possible 10% error. I can't remember exactly what the FS9 code does now, nor where to hack in to find it, but it is just possible that things have changed since the assumptions they might have made about it were true. I'm running FS9 now for 30 minutes on my Win7 64-bit system t see if that is so inaccurate. If it has changed over the years I wouldn't have noticed because (a) I don't use FS9 any more, and (b) I always have the FSUIPC sync option set. I'll check FSX as well when the 30 minutes are up. If FS9's clock is accelerating away it is possible that the FSUIPC sync facility won't cope the way it is set now. It's frequency of updates assumed a slow drift, not a runaway. However, you did say it was okay, you only seemed to be complaining about the Pause as far as I could see. Is that so or am I misinterpreting you? Regards Pete

Wow! So, FS is running about 40% faster (gaining 15 minutes in that 35 minute interval)! As far as I recall, FS9 uses the basic Windows-supplied "tick" of 55 mSecs (i.e. just over 18 ticks per second) to update its internal "real time clock". it doesn't read any real clocks, of course, because in the FS world everything is relative. Time stops, slows down, speeds up, etc, according to what the user does. So FS simply accumulates the time in increments based on these ticks (or multiples of them for 2x, 4x etc). Even though it uses a reasonably accurate floating point value for the increment, it isn't accurate enough to stop the very slow drift which the FSUIPC facility is there to correct for. So, I think something set in your system is making the Windows system ticks a lot shorter than 55 msecs. About 38 mSecs in fact. Nor I, but I now think it is your system, not in FS. Regards Pete

But when did you last set it? FS often sets the time from the Flight's being loaded (depending on options set). It also takes a while loading stuff and doing other things than actually simulating time passing. Here, if i want to fly with real time (so my real cockpit clocks show the same Zulu as on the CDU and EICAS) I have to synchronize its clock (using FSRealTime) when everything is loaded and ready to fly. After that it only goes wonky if i start using menus or pausing etc -- but then it is slow, of course, not fast. I don't believe I've ever seen Fs run noticeably fast, I seem to remember it lost time, not gained. But I might be mistaken. Of course, if you are running FS at x2 or x4 etc, its clock will be getting fast quite quickly. Maybe you have the sim rate set unknowingly? (Though that sounds unlikely, you never know! ;-) ) Regards Pete

Okaysounds good. Regards Pete

Sorry, I don't know FSMap. You'd have to ask the folks who supply it or support it. I don't know. Does FSMap use FSUIPC? If not then it won't run on a separate PC under WideFS. You need to check with FSMap support or documentation. [LATER] I've just read the Aerosoft product details for FSMap, and, yes, it should run okay with WideFS6 on FS9, but for FSX it uses SimConnect, so really you don't need WideFS at all for that -- if you have the Deluxe edition of FSX you can run SimConnect programs across your local Network. Sorry, I do not sell or supply Keys. All that is dealt with by SimMarket -- and I think it is all automated, so I think you must have ordered WideFS6 by mistake. You'll need to raise a Problem Ticket with SimMarket. (I think they have a Spanish site). Regards Pete

Really? I've never nor heard of anything like that! The only reason for the FSUIPC feature is to make up for a slow creep of FS's time over a period, where it falls further and further behind (or is it ahead? I don't remember) real time. The mechanism it uses is simply to update the seconds reading now and then so that FS updates the minutes correctly. FSUIPC3 does not touch the hours or minutes. Local time or Zulu? Where are you reading this? Don't forget the local time will update across time zones. If you do really mean the Zulu (GMT or UTC) time, then quite honestly I don't know what to advise you. I've never heard of any bug or problem in any version of FS which will cause a drift anything like that. Well, there's no code to stop it, but I had to leave my FS9 on Pause for a good 10 minutes before it did. But that would be totally wrong. If you pause FS you STOP time as far as the FS world is concerned. If I attempted to resync to the year/day/hours/minutes/seconds when you unpaused, all that time paused would appear as part of your flight time, which would certainly be wrong. And many folks fly at a different time of day in FS than the real time of day -- for instance, so that they can do daylight flying despite only being at their PCs at night. They shouldn't be deprived of the facility to keep the ELAPSED flight time correct, should they? This is what the FSUIPC facility is for. But it is exactly as it is described in the FSUIPC documentation. It uses the seconds to keep the minutes running at the correct changeover rate. But it doesn't correct minutes changed by reason of pausing or simply using a different time in FS to reality. What you probably really wanted is that FSRealTime program, which can do exactly what you want, and more -- it aalso llows for flying in non-realtime but with all parts synch'ed by providing an offset setting. Why? That is how FSUIPC keeps the FS updates in line with passing real time. It is just doing its job. It would only be doing that the once, mostly you'd see maybe a 1-3 second jump now and then, depending how much the drift is and how often FSUIPC adjusts it. Regards Pete

How strange? I never thought anyone would be so serious about time synchronisation that they'd actually spend real money on it! ;-) Maybe you could have used the free copy of FSRealTime, instead, to do that -- if it is still available. I think it still works free but with nags and ads till you buy it. Er, sorry? I don't understand. Are you seeing the FS clock update whilst FS is paused? I've just tried that and it's now been paused for several minutes and the seconds hasn't changed yet. Which surprises me actually, because there's no code explicitly in FSUIPC to avoid correcting the seconds whilst paused -- there never seemed a need, because as soon as you unpaused it would need to try and correct the value in any case. What would you expect FSUIPC to do with the clock whilst paused? And why would you need it to whatever it is you want? Obviously I am missing something here. I can explicitly check for FS paused and avoid the correction, but (a) I don't see if happening here in any case, and (b) I don't understand why it would be useful. One thing I have noted, watching it, is that it only attempts to correct every couple of minutes or so. That should be enough to keep it in sync normally, but obviously not if you pause often. I could make it do the correction more often if there's a need. It also doesn't attempt to sync if you run FS as slow or fast speeds, only at the x1 speed. Regards Pete

You have multiple assignments, then, not just the ones you just made, or you have enabled some assignments or throttle mapping also set in FSUIPC. To check the former go through all the FS assignments, for all devices. For the latter, try temporarily moving the FSUIPC INI file out of the FS Modules folder, before running FS, and see if that fixes it. If so, you've set options in FSUIPC to map throttles. Really you are better off deciding whether to use FS for all assignments or FSUIPC, and not mix them. Whichever you choose you can still always calibrate in FSUIPC if you wish -- the calibration options, on the "joysticks" tab, are independent of how you assign. In FSUIPC assignments are done in the "Axes" tab. If you do all assignments in FSUIPC, then disable the joysticks altogether in FS to avoid any unexpected clashes. All of your FSUIPC settings are saved in that one file, the INI file, in the Modules folder. Just make a copy someplace, or rename it "old FSUIPC.INI" or anything different, before loading FS. Regards Pete

No, of course not. Why not simply assign one lever to Throttle 1 and the other lever to Throttle 2? You don't need a manual to help you choose those, surely? You just see the separate throttle controls and assign accordingly. You can do it in FS or in FSUIPC, same thing. Your choice. No problem. You don't make any assignment to the generic throttle (the one just called throttle), only to the separate enfine 1 and engine 2 throttles. What is there to not understand or to read a manual for? Having trim on an analogue lever is generally a pretty bad idea unless you know exactly what you are doing. You'd certainly need to check the option to disable it when the autopilot is in use. Usually trimming is a matter of nudging up and down, to achieve stability and release elevator pressure, not setting a specific position -- especially in an aircraft like the Baron. Maybe in an airliner a trim axis would be more appropriate, but even then it can make things more difficult. Regards Pete

There is only one way to read Hot Keys and Hot Buttons through FSUIPC, and both are described in their own sections of the FSUIPC SDK's programming documentation. Regards Pete

Only if those boards looked like standard windows joysticks with up to 32 buttons each, which seems unlikely. Don't they come with any driver software for you to assign things in? I think you need to gp to Flight Deck solutions support -- they should be able to advise you as to what you need. I don't know their boards and don't have any myself. Regards Pete

Not sure how many folks who know XML well get here. It isn't often discussed here, so you may want to check in the panel and gauge building forums in Avsim or Mycockpit. And to get likely candidates to read your message, especially here, you should perhaps re-post with a more appropriate title, such as "Help with XML gauges needed" or some such. Good luck! Pete

Hmmm. I'm at a loss. This is a new problem, only time this has occurred in over three years. I'm sending some questions in Email, because it starts getting more complex now. We'll resume here when a conclusion has been reached. Pete

Unfortunately it is incomplete. Please close FS first THEN show me the complete log. Note that the most likely reason for lack of connection between FSUIPC and client programs is running FS and those programs at different privilege levels. If you run FS "as administrator" then you must run all client programs the same way. If you run FS normally, you should run the programs the same way. Windows blocks communications via data exchanges between programs at different privilege levels. It's in the name of "security". Pete

OK Pete I'll try that right now. Thanks. Another thought I had. you aren't Installing and Registering under a different Windows Log-On account to that used when running FSX, are you? I know it sounds unlikely, but it's another straw. Pete

I tested on Win7 64 and WinXP 32, not yet Vista 64. I'll try that now, though it shouldn't be any different. No no! That creates a lot of different problems if you aren't careful. The SimConnect side-by-side libraries in particular seem to get quite messed up sometimes by reinstalls. Just as an experiment, could you try deleting the FSUIPC4.DLL file again, and re-running the Installer "as administrator" and re-registering? Theoretically it shouldn't make any difference as Installers have elevated admin rights in any case. But I'm at the stage now where any straws need clutching. Regards Pete

Yes, that was an overlooked hangover from FSUIPC3 and was only spotted by a new user recently. That's why it is fixed in 4.558. I've tried registering here using your details and keys and have no problem, so I am very concerned as to what is so different on your system for this to happen. There's nothing particularly complicated, and, as I said, the code checking your registration is the same -- in fact in 4.53 the Installer calls the registration checker in FSUIPC4 to do its checking. Pete

Okay -- but it doesn't tell you to use Admin mode? It shouldn't, there's no such message there now. Hmm. That message is actually removed in 4.558, so I am at a loss. Can you show me a screen pic of that, please? Neither of those actions are a good idea. Okay, that looks good. No. I need to find out why your FSUIPC4, installed correctly, says it is unregistered when the Installer, which uses the same code, says it is registered okay. Until we solve that strange problem, which I've never seen before, there will be no future update. You didn't show me the FSUIPC4 log file. I need to see that please -- a complete one, with FSX closed. Perhaps you can look to see if there is an FSUIPC4.KEY file in the Modules folder. If so, do NOT show it here but ZIP it and send it to me at petedowson@btconnect.com, please. If you do this you might as well include the two Log files so I have it all in one place. One minor thought. Can you check that your PC's system date is correct? Regards Pete

Really? Sorry -- that's certainly not needed and never has been since Registration was done in the Installer. I did find an old message which is fixed in 4.558, but the button below is disabled and tells you to use the Installer to register. If you "got a message" and aren't just reading the top right Registration details (above the disabled button), can you show me the message please? You entered your Registration details in the Installer, when prompted, and these were accepted, or rejected? If they were rejected you have entered something incorrectly. All three parts -- name, address, and key, must be exactly right. If you entered them and they were accepted, then I know of no way they would be rejected by FSUIPC4 when you ran FSX, because they are using the same shared code for this. If this is what appears to be happening please show me the Install log and the FSUIPC4 log, both of which you'll find in the Modules folder. Nowadays you never have to run anything of mine "as administrator". Note that, until I release a new Install bundle, if you want to use an interim version (4.558, for instance) and register or re-register, you will need to delete FSUIPC4.DLL from the Modules folder, run the Installer, Register, THEN copy the 4.558 (or later) DLL into the Modules folder again. Sorry about this inconvenience. It is related to a problem with MSVCR80.DLL side-by-side versions and recent compiler updates. I am fixing it ready for the next main user release now, so it only affects interim update installations. Regards Pete

Yes, it is easy to overlook. And Win7 confuses the issue even more with its "HomeGroup" setup, which only operates between Win7 PCs. I've avoided that entirely because I've a mixture of Win7 and XP PCs on my network. I don't think it will be a Win7 thing, unless you have HomeGroup enabled and that possibly interferes. But yes, I believe you need a re-boot after changing the workgroup name before it becomes effective. Regards Pete