Pete Dowson

Aren't there some third party programs that can do that -- set up complete weather situations based on a theme? The FS2004 "themes" are a different thing altogether. They are programmed in some new format for FS to load. I have no idea how they work at all I'm afraid. Ahthat must be one of the 3rd party programs I meant. Can't that be run from your instructor station? I don't really think FSUIPC should get involved in actually creating weather. Regards, Pete

No, not at all. I really can't see what sort of conflict there could be, to be honest. Especially when the limiting version of FSUIPC was apparently 2.8 which is over two years old! You'd think someone would have mentioned something during those two years or more, whether PSS or a user? The only description of the 'problem' I've received is the one above: "goes into a freeze thaw mode", which I don't understand and cannot visualise. Regards, Pete

There is none easily available. You'll need to work out how to do it. start by writing a Gauge. Gauges are just DLLs loaded by PANEL CFG files. Well FSUIPC is synchronised to FS's frame rate -- it needs to be because aynchronous settings can upset things. If you aren't achieving a smooth change via FSUIPC I think you need to look again at what you are doing. Attempting 50 fps is a bit ambitious in the first place -- you are allowing 20 mSecs per frame including the process swapping needed between your EXE and FS. Maybe in a Pentium 4 3.0 or better with hyperthreading you can achieve this, with many FS settings turned down, but even then I would think it doubtful. Try 25 fps, with the FS frame rate limiter set to 25 so that it doesn't do more than it has to. Regards, Pete

No, it isn't strange at all. I now see exactly what is going on. (You didn't check with FSInterrogate as I asked, did you? Then it would have been more obvious to you too :wink: ). I missed this in your last message: 26172 Write: Offset=0262, Size=0004 You are writing 4 bytes to a 2 byte field!!! Only write 1 to the 16-bit (2 byte) control value at 0262, as documented. Writing to 0264 is trapped by FSUIPC and converted to a write to 0262 in any case --- it does this because for a long time some lists showed 0264 as the control, not the indicator. Writing 1 to 0262 and 0 to 0264, as you were doing, will actually write 1 then 0 to the control, so setting the pause ON then OFF. Sorry I missed that before. I see you are also writing 4 bytes now to 0264. This will write zero to the two bytes at 0266. That could do something unexpected too. Never write to someplace you don't know unless you want surprises! There are lots of things in that program which I have no idea how to access. The author is privileged by being part of the FS team. I don't get the sort of information he gets. I you can work out how I can retireve it, I will see if I can add the correct code into FSUIPC, of course, but I think it will be a lot of work -- it took me long enough to get the information I am providing. Sorry. Regards, Pete

Sorry, I've no idea. Try it with FSInterrogate, it always works okay here. Also use the FSUIPC Monitor facility to monitor the value in 0262 in real time (eg. on screen by AdvDisplay selection in Monitor). Also check it with IPC write logging in FSUIPC, and check it with your program running locally to FS too. Regards, Pete

Sorry, but it isn't FSUIPC, and it won't be FDC either. There are several main possibilities -- video driver (ensure you have the latest non-Beta for your card), bad gauge (add-on panel/aircraft, or corruption), bad scenery (add-on or corruption) or bad sound file (or even sound driver), etc. It could even be a bad WX file (WX files are weather files associated with FLT (flight) files. Try starting off creating a complete new flight instead rather than loading an existing one, just in case. Also try different aircraft, especially the default ones, in case it is something in an add-on aircraft, panel or gauge. Generally, though, the only foolproof way I know to resolve such things is to uninstall each add-on in turn till the problem goes away, then add the others back in. However, even that doesn't always work because the add-ons don't always uninstall in a way which returns things to the way they were before. So the most definite way, assuming you have enough disk space, is to rename the FS folder, then install a fresh copy of FS. Check it out, then add one add-on at a time, checking at each step, until you regain your full system, but now working, or discover which it is that is crashing FS. Then you can either remove the old installation, or remove the discovered culprit from that copy and re-test that one. If you don't have enough disk space and no other method solves the problem, then I'm afraid a complete de-install of FS and re-install of everything would be called for. But be sure to check things out at each step. Regards, Pete

Well, my window is supposed to be also a modal window within FS. It is created within FS (my application is a module, i.e. a dll loaded by FS) and seems modal as expected (FS hangs until my window is closed). The only non-modal visible effect is that damn black screen. Ah, well that's odd then. I can't imagine why yours makes the black screen and mine doesn't. Hmmm. Pete

Ah, the black screen. That is easy to get without programming. I really don't know what sort of mess DX8/9 is in, but black screens seem to be typical. I wish I knew the answers. If you do solve them, please let us know. It is likely that the only difference between yours and FSUIPC's window is the fact that FSUIPC's is a modal dialog within FS, so most of the normal FS activities are frozen whilst it is active. I don't know that there's any way of accomplishing this from an external program. Regards, Pete

Without any doubt, choice 1 -- with one proviso. Keep the copy you wrote back and use that, don't read a new one, if the next update is within, say half a second or so (you'd need to experiment). If more than this interval occurs with no update, read a new value from FS next time. If you don't take this precaution then you may get stuttering or stuck values as you read back the previous value -- i.e. before FS has actually implemented the change FSUIPC has sent to it. This is the technique I used for the FlightLink TR-1 and KR-1 stacks (via EPIC), and I also do this in the PFC driver. Sending increments and decrements leads to overruns or overruns, it just isn't precise because of the message queuing in Windows and in FS. In FS98 there were no such problems because the actual values used by FS were those in the locations you could write to directly through FS6IPC or FSUIPC. The same was more or less true in FS2000, but it all changed drastically in FS2002 -- FSUIPC can only make the changes effective by calling procedures in FS. Sorry, but really option 1 is the only way of ensuring that. Regards, Pete

No, never as low as that. Certainly it can dip to 10-15. This is okay for airliner flying, which is all I do on that PC. I have all the weather sliders up to maximum -- no 2D clouds, I don't like them. But one big difference, possibly, is that I have no panel at all -- the 2400x600 view is full-screen scenery view only. I think that will make a lot of difference. If you are using a panel , try to find one with a good virtual cockpit (so it all runs as one 3D view) -- I think the imposition of the 2D panels has a considerable impact. I only have 1Gb main memory, but the Parhelia is the 256Mb version. Not that this should make any difference I think. I have been through the list of XP services which are running and tried to cut those down to a minimum -- anything that looked unnecessary for FS is disabled. I only use that PC for FS, so this is relatively easy -- though you can set up separate profiles which give you a choice at XP boot time if you want dual use. Also the only other process I have running with FS is the Project Magenta MCP (with no Window for it -- it runs in the background). I used to have this on a separate PC but the Hyperthreading on the P4 3.2Gb seems to allow it to run with FS with no adverse effects. Regards, Pete

No, never. You just copy the DLL into the FS Modules folder. That's it. Upgrade done! Do not delete your FSUIPC.INI or FSUIPC.KEY file or you'll need to start all over. Only do such drastic things if they really get in a mess, but even then keep a safe copy. Regards, Pete

I'd like to know that too. Even to stop the FSUIPC options dialogue flashing in FS2004 full screen mode I have to intercpet the WM_PAINT messages to FS's Window and validate them without passing them on. Try moving the FSUIPC options window and you'll see one of the horrible results. I asked the FS team why this was and they just said "blame DirectX8, it's out of our control" (FS2004 is programmed to the DX8 API). Regards, Pete

I thought FS2004 provided you that access? What else could you want? Sorry, I'm nissibg something here. Pete

That's only because they were using the FSUIPC-computed value, not the standard one than most things use. For performance reasons I didn't want really to do this on every frame, but as PC speeds have increased it is less noticeable. I don't think I've got any VSI and RPM values which are computed by FSUIPC. The mapped ones should update once per frame, same as the Altimeter readng. I can't do better than that. What actual offsets are they reading for these? BTW I have an Aerosoft GA-28 panel which looks somewhat similar to yours and I must admit that I don't notice any stutter with any of the instruments. Their altimeter in that setup uses the original method, so wasn't affected by the FS computation change -- since FS98 days the original method was to read the actual altitude, the QNH and the Kollsman setting, and compute the value to be displayed. Regards, Pete

Sounds like the GPS is doing some extrapolation, then, assuming you can't actually stop the aircraft dead in the air! :D It must be a bit puzzled when you release the pause! Regards, Pete

Yes, except for the pressure and wind smoothing options which only apply to global weather, which isn't really used in FS2004. But note also that FSMeteo does take control over some of the options. When it does so they will appear disabled in FSUIPC's options, but you should be able to alter them in FSMeteo's options. The three visibility options marked *** are otherwuse universally available. With those I managed to find a way to get around the weather setting business and tackle the actual visibility being set. I only wish I could do that with the winds, pessure and clouds too. Regards, Pete

The last version before FS9 was 2.975. Version 2.8 is VERY old. It sounds like there's a real problem with the PSS Dash 8 in that case. I can only suggest you write to the authors about this. Is it supposed to be FS9 compatible? Many previous aircraft do need updates for FS9. Sorry I am unable to help in this instance. PSS used to be quite good with their support. Have you tried them? After all, if it didn't work with any later version of FSUIPC than 2.8 is must have been reported quite a lot, and there may even be a correction available -- version 2.8 dates back to later 2001, not all that long after FS2002 came out. Regards, Pete

No, it really absolutely cannot be anything whatsoever to do with FSUIPC! In fact it sounds like the PFC driver is doing EXACTLY the right things according to the programming in the PFC driver! Please get your PFC.DLL documentation out and refer to the section entitled "Extended autopilot features (Jetliner console) OR ...". It says "On the Jetliner console the larger section below the Bendix-King style Autopilot section is totally dedicated to some more advanced autopilot and avionics functions, applicable to modern airliners. These functions are also available on the GPS and Altitude Pre-selector sections of the separate Avionics stack, the allocations being as illustrated here from the Jetliner". Look at the allocation of functions for the GPS buttons. Look at the table below showing the fubctions provided on those buttons. This is what you are seeing, isn't it? It has been like this for a couple of years. This isn't new. Either you've never pressed the buttons before, or you've always (?) overridden them with FSUIPC programming -- though that's relatively recent in fact. What has probably confused you was the bug in FSUIPC 3.2/3.201 whereby the FSUIPC programming didn't correctly override the PFC functions. That is fixed in 3.202. Please check the Release details in the announcements. Regards, Pete

Compare the Lat/Lon coordinates. The runway positions in FS are not all that accurate in many cases. Check that the map you are using in the GPS agrees with the scenery in FS. Oh, right. In that case strike the above! :) At 9600 that's probably getting close to the fastest you can get in any case. There's 74 bytes (I think) in each AV400 transmission. 9600 async allows only 960 bytes per sec max, 192 bytes in the 1/5th second you allow. At 100 msecs the blocks could start looking continuous and/or would back up in the PCs buffer. This is confirmed by our other contributor here. Regards, Pete

Yes, it does. I had to add special programming to make the repetitiion happen whilst a button is held down, but key presses repeat automatically when held down, so I don't need to do anything there. Are you now saying that you cannot make the keypress repeat when held down? I thought this was a programmable function of a Hagstrom keyboard encoder? Or is this getting all confused again? :( I've no idea, sorry. I wouldn't have thought they'd all be the same in any case. With the old Game Port type connection I think the AtoD conversion is in the Game Port itself, so all you need to do is connect a 100K pot across the appropriate connections. But the method it uses is crude and slow -- timing the discharge of a capacitor through the pot. Modern "digital" joysticks, connecting via USB, may do the same internally, but at least that saves the processor in the PC doing it. Many better quality ones probably use other methods -- proper voltage AtoD chips, or optical like the ball-free mouse. I once had a FlightLink/EPIC throttle quadrant which had plastic discs marked with fine rulings connected on the lever axes, and these went through the gap in a standard optical chip. The driver presumably counted the number of markings going past. There was some way of detecting the direction too, but I can't remember how that worked now -- probably two separate optical beams in the gap. Regards, Pete

Sorry, I've no idea. You'd think the stuff it does get would be enough? If you find out, please let me know! Regards, Pete

Yes, but some of that was to enable things to be done with buttons that otherwise could only be done with keystrokes -- the "repeat" facility in particular, which I think must be the one you are concerned with. I never needed to implement "repeat" for keyboards because they do anyway. Buttons don't. I think they will be solvable. Something to do with jitter and multiple inputs wrecking my fast/slow timing. Regards, Pete

Hi yet again, I have now asked Doyle about the TQ6 and he says that jitter can sometimes be a problem -- he is working on improvments to the firmware for this. Meanwhile, he says that it is often worse when the TQ6 is connect via a USB hub. See if you can connect that unit direct to a port on the PC. It may help. Meanwhile I am going to assume that this is the cause of the problem with the FSUIPC slow/fast detection and work out some changes for you to test for me, if that's okay? Regards, Pete

So this is not a deficiency in the encoder, just in the way you've programmed those two switches? Er, I'm still not clear. The holding down and repeating of a key would need to be in code effectively preceding FSUIPC's conversion of the keypress to an FS control. It's a really messy operation dealing with WM_KEYDOWN and WM_KEYUP messages, or discarding those it does see. For instance it would mean discarding all the WM_KEYUP messages associated with this particular key combination, thus inducing stuck keys. This is normally very bad news. Then what happens to generate the repeats? Is it the encoder that generates the repeats, like a real keyboard controller, or is it relying on some BIOS or Windows action? Without the repeats the holding down probably isn't of much use. And, most importantly, what sort of signal would there be to make it release? What if that were missed? When it did occur, they partucular KEYDOWN/KEYUPs associated with that signal would have to be discarded, and all the originally discarded KEYUPs for the original signal regenerated. Really ugh! Or are you thinking that FSUIPC should take and allow all the Key messages as normal, but from that starting signal start a sequence of controls repeating over and over till some other key sequence arrives? Or it is always the same key sequence again? That might be less dangerous, but it's still a lot of messy programming. Can't you think of a solution the other way round. Make the encoder do the hardest bit -- i.e. program those two keys to do the holding and repeating, then adapt things to still work in the case where you want simple Ons and Offs? Or am I still missing something? Regards, Pete

Hi again, I've been thinking about what might be happening, expecially if the axes has some jitter and keep sending different values. Do you think this could be the case? Do you still get the problems with the rotaries if all the axes are "parked" at full off or full on? If I can understand what is happening, maybe I can work out some way of either fixing it or at least logging some data to work it out. If I make a test version of FSUIPC with some changes, can you test them for me? Maybe you can contact me by email -- petedowson@btconnect.com -- I can't send attachments here, they are too big. Are you using WideFS by the way? Regards, Pete