Pete Dowson

Wherever you like. Give yourself more movement on the forward thrust side -- you don't need anywhere near as much movement for reverse provided it is at least consistent. Many airliners only use two reverse settings in any case. For instance, on the 737 there are three notches. The first "arms" the reverse mechanically, but leaves the thrust at idle, so you don't need that. The third is normal reverse thrust, and the second is used on the way back, when cancelling reverse, to allow the engine to re-stabilise at a low setting before mechanically closing the reverser. They don't really seem to use variable amounts of reverse -- you either need it or you don't. It's only used for a short time in any case of course. The idle zone needs to be large enough to always reliably find it -- if there is much jitter or variation in the readouts your lever gives then it will need to be wider. Things like humidity and temperature variations can affect the values being provided. You must always be able to set idle, else you will certainly have problems. Just experiment till you can get it working well in all circumstances. That's the problem with doing it with one smooth lever slot. I'd recommend making some sort of notch -- a piece of rubber or a sponge gate perhaps, glued to one or both sides of the slot, for instance. A little piece of rounded corner from a soft rubber pencil eraser might do. Oh, hi! Friend of friend! :D I imagine that the discussion was something on the above lines. The other method I had considered for one of my throttle quadrants (an old FlightLink one) was to fit a hinged metal gate across the slot, only moving it out of the way when I needed reverse. This is rather more ambitious though and permanently disfigures your controls. Regards, Pete

It's more likely to do with video drivers or some such than WideFs, which has not substantially changed for a long time. If by "lately" you mean it was okay once, you really need to track back and work out what you changed. The bad data size error is an error from a client program. But one such error will not produce stutters, it is merely a symptom of something wrong in that program. Maybe that is related to your stutters, I cannot tell. You need to ask whoever it is supports the program in question. The ReadLocal lines don't make sense -- looks like things have shifted so the offset has become the size and vice versa. Weird. But if there are commands being sent with 'bad data', then maybe this can happen, so it may all be part of the same symptom. BTW the "ReadLocal" lines should NOT actually be in the log if you are using the standard default settings! If you have changed the Logging to include such data the log file will get huge and certainly not help performance! Set the Log line to "Errors+". Regards, Pete

Sorry, I don't really understand what you are saying. If the throttle is not assigned in FS, it won't be seen in FSUIPC. FSUIPC is not a joystick driver, it is not processing joystick inputs, it is processing FS controls. You need to get the throttle working reasonably well in FS first, using standard methods. Regards, Pete

Only delete those which you are definitely re-programming in FSUIPC. Yes, they will both be trying to react otherwise. Pete

No, I don't think it was actually ever offered for download there. There may have been a link to it. In fact (I've just checked) -- there still is. It's the last link in the list of FSUIPC users at the right-hand side of the page. Anyway, glad you found it. I think the FS2004 version is payware -- the FS2002 version was free. Regards, Pete

You can make any button toggle between two actions by using a flag as a condition. It does mean editing the FSUIPC.INI file, and all the details you need are in the Advanced User's document. You need to strudy the "compound button conditions". I will go through how to do this here (I notice it isn't one of the examples in the document, so I may add it): Suppose your button is Joy 110, button 3, and a spare flag (a button on joysticks 0-15 not otherwise used) is 15, 2. Program your button with three lines in FSUIPC (the numbers on the left need to be sequential with whatever's there already, but I'll assume you have no others so will start with 1): 1=P110,3,C1005,3842 ---this says execute Control 1005 whenever your button is pressed. Control 1005 is "Button Flag Toggle". The parameter '3842' identifies the Flag -- 256 x joystick 15 + button 2. So, this flag will now alternate between being set and clear each time you press the button. 2=CP(F+15,2), ... This tells FSUIPC what to do if the button is pressed AND the flag is set. Replace thepart by the Control number and paramter for one of the actions you need. (All the PM controls are listed in the document). 3=CP(F-15,2), ... Similarly, this tells FSUIPC what to do when the button is pressed and the flag is not set. I hope this is clear enough. Regards, Pete

Sorry, you didn't say you wanted PANning actions, not directly selected views. The Pan controls are different. These are: PAN_DOWN PAN_LEFT PAN_LEFT_DOWN PAN_LEFT_UP PAN_RESET PAN_RIGHT PAN_RIGHT_DOWN PAN_RIGHT_UP PAN_TILT_LEFT PAN_TILT_RIGHT PAN_UP PAN_VIEW Of those you probably only want pan up/down and left/right, so you could save one other of the 8 directions for the 'reset' to get you looking straight again. If you keep swapping between 2D and VC cockpits (why?), and you want one mode in one and the other mode in the other then you are really better off using the FS built-in hat programming, which allows for this. Either that or investigate FSUIPC's conditional programming facilities using flags, with a spare button or keypress to swap between the two modes -- that stuff is covered in the FSUIPC Advanced User's documentation and involves editing the INI file yourself. You can't do that sort of thing via the options dialogues. Regards, Pete

Why skittish? If you make a mess or don't like the results, simply delete the Joystick calibration sections in the FSUIPC.INI before you load FS next time. Or reset all of FSUIPC's options to default by deleting the FSUIPC.INI file altogether and making it restore the defaults. What part of the documentation isn't clear, please? I spent a lot of time (and I do mean a lot) on the documentation -- much more than I am likely to spend here, so it is difficult to know how to explain things any better than I have already. I shouldn't need to do this, but here is a copy of the relevant paragraph: Isn't that clear enough? What is it there you don't understand, please? If it is merely how to calibrate the throttle, please simply follow the step-by-step calibration instructions earlier in that same section of the documentation! Regards, Pete

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