Pete Dowson

What do you mean by "WideV"? I've never made anything called WideV. The only two products I know with names starting with "Wide" are my own WideFS, which you will certainly see listed in the current versions announcements above, and "WidevieW" which is a program by Luciano Napolitano. The latter is certainly available now for FS2004 -- check his website (http://www.wideview.it). Regards, Pete

Great! Thank you! Pete

That should actually be okay. You certainly wouldn't want it the other way about as that gives straight line cut-off edges to many clouds. Odd, I've made no changes at all to the way the visibility limits are applied, and in an unregistered version there will be nothing done by FSUIPC in any case, except upon external program request. Well, that's something of a minor miracle then, with no changes in any of that area of code. Truly astounding! Well, that's the main thing. It most certainly does. Maybe you have changed from Win98 to WinXP since you last tried the feature, and haven't checked the documentation? WinXP defaults to showing the windows when dragged, and that FSUIPC feature has never been able to work, on Win98 or WinXP, if that is enabled. It is nothing to do with whether it is FS2002 or FS2004. Please do check the documentation when you have an issue like that, in case it is actually mentioned. Regards, Pete

Sorry, there is no way FSUIPC, registered or unregistered, is going to do anything with graphics. I wouldn't know where to begin. You have something else going on there. [FSUIPC always gets the blame for everything, no matter how improbable :cry: ]. I've actually never heard of dark bordered clouds at all before -- the shading of the 3D clouds (at least) is excellent in FS2004. The 2D clouds should be shot though -- check your Options-Settings-Hardware-Weather options and make sure clouds are 100% 3D. Regards, Pete

Yes, of course. And much more. Get the FSUIPC SDK from and check the Programmers Guide document.Regards, Pete

It would help enormously if you could be more precise. I can't understand what changes could have caused this on your system. The only change in the programming of the RIC dials in the last months has been to take notice of the "fast" mode they supply to add/subtract 10 times the minimum increment, so in fact the reaction is faster for the faster turning rate. But that change made it faster, and was a long time ago! With FSUIPC 3.30 and PFC 1.90? There is no way programming the Heading dial to adjuust the heading through standard FS increment and decrement controls will ever be better than the direct control exercised by the default way the PFC driver handles it. For all such numerical adjustments (Heading, Course, Altitude, V/S, Speed, Mach) the PFC programming bypasses all the inefficiencies of using FS controls and actually works on the values insude FS. I spent a lot of time making that the most effective it could be. Please delete the FSUIPC programming for the knobs and retry it with PFC as it is. But please use FSUIPC 3.30. A lot has changed since FSUIPC 3.22 and I want to be sure we are talking about the same thing before I start investigating something which may not need investigating. At present, due to my eyes, I am severely limited in terms of PC work at present, so I can't afford to waste time. Sorry. If it used to work fine, and then, after a change in the software, stopped working fine, why are you now so skeptical that another change won't put it right again? That isn't logical. Regards, Pete

Thank you. The eyes are still giving me some problems. I cannot work with the PC for long periods. But they are improving slowly, and it's only just over a week since the left one was operated upon, so I am confident all will be well in a week or two. Regards, Pete

Sorry, I don't understand -- FSUIPC cannot make AFD files. I think AFCAD is actually a program, "Airport Facilities Computer Aided Design". It is freeware available on the 'net. I think you may be talking about AFD files (FS "Airport and Facilities Data"), which are, I think, produced by AFCAD, the program. The only program I know which handles AFDs as well as AFCAD is AFCAD itself. Sorry. Regards, Pete

Just to be sure, that IS with those [buttons] parameters removed, I assume? Phew! Right up to 45!? That is strange. In that case I can hardly think it's down to timings in the Windows calls I make. It must be something else going on there. I can certainly make the default 50 for Win98/98SE/Me instead of the current 25, but I think I'll try to dig deeper first, see if I can figure out what is really going on here. Thank you very much for testing. You can continue to use 3.305 without the [buttons] lines for now. The ultimate correction(s), whatever they may be, will be in the next formal release, probably 3.31, but that won't be for several weeks. Regards, Pete

Okay, it is on its way. Thanks. Ah, that spoils one theory then .... hmmm. Regards Pete

Okay, that seems to prove that the PMDG 800/900 is writing to FSUIPC someplace it shouldn't. As one final piece of evidence for me to examine and forward to PMDG, could you do one more test please? Just before switching the landing lights on to make the error occur, go into the FSUIPC options, Logging page, and enable IPC write logging. OK out, make the test (switch on landing lights), see the error occur, switch off landing lights, see the error disappear, then immediately go back into FSUIPC options and turn that option back off. (I only want it logging atound the error as otherwise there will be far too much log to wade through!). Close down FS, ZIP up the FSUIPC.LOG (yiu'll see it in the FS Modules folder) and email it to me at petedowson@btconnect.com. Thanks, Pete

Right. That's two out of three so far. It is on its way. Not sure what the question is here. Sorry. My normal bedtime is around 2 am. I went up soon after sending that last message. Regards, Pete

There's one common factor which may be important in both these systems: W98SE Do you, by any chance, have a number of USB and/or joystick devices? I'm wondering if this timing problem is down to Win98's rather half-hearted implementation of USB support. I can't seem to find operating system details for the chap with the Buttons page hang. Regards, Pete

Yes, I did say a few messages back in this thread "there was one other instance of this reported here someplace", but I thought it was reported as related to AS2004? Sorry, maybe I have mixed things up. The only reason I suggested these measures was on the off-chance that the hang was in fact a tight loop into Windows APIs which, for some reason unknown to me (still) take a helluva long time on some folks systems in some circumstances. The only reason I found out that these loops can occur was on another chap's system where he did not report this symptom, but a hang in FSUIPC's own Buttons page. This was with 3.22. After quite a lot of experiments I found the solution, and that was incorporated into 3.30. At neither time did any relationship with these other symptoms become apparent. This was just a guess on my part after some of the answers I got earlier this thread. This would have happened in your case too if the other (resolved) problem had been reported and investigated beforehand. Yes, but that's not really relevant. Yes, it is normally only a list of the assignments made. There are some optional entries, but the defaults are preferable except in exceptional circumstances (like these). Actually, I'm pretty sure the Epic part of the addition I suggested is not needed. It's something to do with the polling interval being the same as or even less than the time Windows is taking to check on button status when I poll it. 25 milliseconds is a long time, so this is strange, but that's what it looks like. Perhaps you can verify that for me? Delete the EPIC line and test again. Thanks. No, not applicable, but thanks. What's this about stuttering? The only real internal cause of stuttering I know in FS2004 is weather setting, and in particular, clouds. None are, don't worry. there are defaults for everything. That's how FSUIPC can run with no starting INI file. The difference here is a value of 25 (default now), 20 (default in 3.22) and 60 (default before 3.22). The parameter line to change that has always been available, ever since the button facilities were added. The reason for the decrease was to give better button servicing on rotary switches and the like. These side effects are completely unexpected and rather strange. Do you want a test version of FSUIPC where I avoid button polling altogether when in FS dialogues? You'd need to delete those lines in [buttons] and try to reproduce the problem. I can send it now if you can test. Regards, Pete

If you disable AdvDisp, does ATIS or whatever show in FS normally, or is that affected too? Okay, sounds like they've got an error for sure. If it is so reproducible I'm sure they should be able to locate it soon enough. I'll send a note to my contact there too. Thanks, Pete

Oh, rightwell done! Thanks for getting back to me about this. I wonder what is going on there to cause such a problem? The default button polling cycle is 25 mSecs now, in 3.30 (it was 20 in 3.22, but 60 previously). This should be easily enough time -- but it seems some systems have certain states in which it is taking all that time just to poll buttons on any joysticks connected (USB or game port), so nothing else gets done. The only other instance I had was where the buttons dialogue in FSUIPC was hanging -- this was on a system with a lot of USB connected devices (GoFlight and such). I will try to figure out a way of keeping the default cycle of 25 mSecs (which is better for faster button detection), yet still prevent this sort of hang. If I think of anything, would you mind testing a version for me if I send it by email attachment? You need to remove those [buttons] lines you added, then try to make the problem recur. Regards, Pete

Speedy reply to what? This is a reply to the first message in this thread, entitled just "Source code". Please try to keep in thread as it is otherwise very difficult to have a proper interaction. I answer almost all the messages here Source code of what? If you are talking about any of my programs, or Flight Simulator, you won't get source code. Sorry. Sorry, I've no idea how that operates. In any case, I run FS2004 on a 3.2GHz P4 with a Parhelia video card driving three monitors, and I could never possible get 60 fps in the first place, yet alone save every frame along the way. I think you will need to set more realistic targets. I fly at 18-25 fps most of the time, a bit less near heavily detailed airports. Surely that sort of frame rate is more sensible for video recording? I have no idea what you want to use this video for, but why not just fly FS normally and either film the screen, or better capture the video output? Most video cards today do have video (composite or S-video) output after all. If you want a sort of flight black-box recording, to play back in FS, then you could write a program to dump out crucial information from FS (LLAPBH -- lat,long, alt, pitch, bank, heading) at frame-rate type intervals, then write this back to FS afterwards at the same intervals. In other words, your own digital FS video. This may actually have been done by others already, so you could ask around. If you want to look at the sort of information you can read, check the Programmer's Guide in the FSUIPC SDK (http://www.schiratti.com/dowson). Regards, Pete

Sorry, I have absolutely no idea. I have no program which is in any way related to flight videos, or even graphics. I think Luciano must be mistaken. Regards, Pete

Something doesn't make sense there -- PFC.DLL depends upon FSUIPC and will not work without it! What "older combination"? You've mentioned nothing about that! All you said was you were using FSUIPC 3.22, which is out of date. You didn't even mention PFC.DLL originally. Please re-check with version 3.30 of FSUIPC. I cannot investigate any problems with older versions. Regards, Pete

There aren't any keystrokes related to whether Advdisplay's window is cleared. It sounds like something is actually writing to the AdvDisplay control offset when you operate the landing light switch. If you disable AdvDisplay, so the ATIS shows in the normal FS text display, does it still occur? If so then it may not be the FSUIPC offset but some direct action into FS. You could also test with the utility ShowText (in the AdvDisp ZIP) to see if the text clears there too -- that reads from the FSUIPC offsets. Is this only with the PMDG 800/900? If so, please report it in as much detail as you can to PMDG. I suspect it should be very easy to find and fix once they know about it. Regards, Pete

Sorry, I don't understand what you mean here. Can you explain? Certainly, all versions of FSUIPC, and FS6IPC and FS5IPC before it, going back about 10 years, have provided access for applications to induce failures, it is simply part of the interface it provides to FS. What do you mean "hidden"? It is simply a module installed in the FS Modules folder. Go take a look, in explorer. You'll see it! It is not hidden. Also, if it is installed there will be an FS Menu item for it -- Modules - FSUIPC. Check that. If it isn't version 3.30 then it is out of date. Download a new version from http://www.schiratti.com/dowson. You misunderstand. FSUIPC does nothing unless told to by an application or add-in DLL or Gauge. This is especially true if you have not registered it. It is then simply a passive interface for other programs and add-ons to use. Regards, Pete

No need for a cursor any place. It isn't used as there is no text input. Have you disabled FS's programming for the hat? You need to go into FS Options-Controls-Assignments, find where the Hat is programmed, and delete the assignment. Otherwise the two will be conflicting. Then program all 8 directions in FSUIPC. They will be numbered 32 to 39 clockwise from forward. Ugh. The keyboard facility is really only provided for support of those add-ons which need keypress combinations to work correctly. For FS there are controls for almost everything (and some added by FSUIPC). Use the FS Controls side of the dialogue, and find the View controls. There will be a lot to choose from, but this is the normal view sequence for the hat: VIEW_FORWARD VIEW_FORWARD_RIGHT VIEW_RIGHT VIEW_REAR_RIGHT VIEW_REAR VIEW_REAR_LEFT VIEW_LEFT VIEW_FORWARD_LEFT Regards, Pete

PMDG installs a DLL into the FS Modules folder, which is always running. Try removing that and re-check your frame rates without their aircraft. Check the FSUIPC Log file, as I suggested. Also make sure you are using FSUIPC version 3.30. If not, please update. Is that an external EXE or a DLL or Gauge? If the latter, then that's more activity to affect frame rates. Regards, Pete

Yes, you can set failures through WideFS and FSUIPC. I don't know of any ready-made programs offhand, but I bet there are some around. Try, for instance, the FS Instructor link on the http://www.schiratti.com/dowson page (right-hand side). That may do them. There was also this news item about a year ago: but the link it gives seems to be dead now. Do a search of likely places or ask around in more forums. Regards, Pete

No, not directly. I've no idea how they are produced. Aren't they tied to specific events? If you can cause the event, then the effect will occur I epect. Are you saying that if you could program gauges you could induce effects from them? If you can tell me how they would do that maybe I can find out how to do it too. I'm completely lost here. What "keys" are these? Not keyboard keys it seems. Is this something realted to how FX are defined? Regards, Pete