Pete Dowson

Good news! On examining my code I find that I need not actually make any further changes to FSUIPC -- the version I sent to _AK earlier for his testing should suffice. I don't actually calibrate the older FS98-type surface controls in any case, only throttles, mixtures and prop pitches. If you use the 4 throttles page for calibration (page 3), then you will need to check that option at the bottom to prevent FSUIPC applying calibrations to the FT aircraft's throttle control. Otherwise, the other change I've already done, plus the modification to the aircraft, should fix the rest. Regards, Pete

I won't have a version till tomorrow (Tuesday) and I need to close 3.52 on Wednesday, and since you would also need an update for the aircraft -- my changes are only options for aircraft to use at present -- you'd need to ask FT. I'll send _AK a version to test with his changes to the aircraft, either in the wee hours tonight or in the morning. It's then up to them on their update release strategy. I have to get FSUIPC 3.52 out on Wednesday, Thursday latest, whether it fixes things or not. If I were to make these changes user-selectable options I'm afraid it may take a lot longer (it involves changes to several modules then), and there is no way I'm going to do that a day or two before a release. Sorry. Regards Pete

Aha! The light dawns. Yes, Mr. _AK is the originator of another recent thread, resolved today -- see http://forums.simflight.com/viewtopic.php?t=47074. There was nothing in any of that exchange which linked me to an FT PIC 737 nor even VNAV. Sorry. If you read that thread you will understand that he wanted an extra feature adding to FSUIPC to suppress the newer joystick connections whilst allowing the older FS98-compatible ones to go through. Seem that they use the latter instead of direct control to FS for their A/P. If that is the "fix" then, yes, it needs FSUIPC 3.52 (hopefuly Wednesday), but also a modification to the aircraft as well. NOTE (added later) However, if this is related to FSUIPC joystick calibrations too, I would have thought that he might need another facility -- for FSUIPC to avoid calibration of the old controls too, as I had to add for the ERJ145 throttles some months ago. Regards, Pete

Right. I've managed to reproduce what I assume you are seeing -- actually a crash attributed to the visualfx.dll if you click for the "details". It is something to do with the attempts by FS to redraw the screen and remove the Menu when it is supposed to be hidden. I have tried all sorts of things, but the crash is occurring so deep in FS that I'm not getting very far. If I can fix it, I will, but meanwhile there is a workaround which seems to be okay: When you want to access FSUIPC's options, first un-hide the menu bar (right click on the outside view and uncheck Hide Menu). Then do the ALT M F or use the mouse to select the FSUIPC options. Don't try to move the options window around -- FS seems a little fragile if you do. After setting options, etc, close the options window, and, if you wish, re-hide the menu bar. Sorry about this. It's a real puzzler here and I'm trying to think of ways to zero in on the actual problem. Regards, Pete

Well, sorry, but I'm completely lost. How can I have fixed something I know nothing about? In one place the chap called Victor firmly blames FSUIPC ("If you search the forum you'll see most errors are coming from FSUIPC and noisy joysticks"), and later he says what you say above? That I've fixed it in a version due this week? I really don't understand what is being referred to here, nor why anyone is blaming FSUIPC, nor what I may or may not have done to "fix" it. Perhaps if someone who knows some of these things might actually talk to me sometimes things might make more sense? I don't mind trying to help fix things, and certainly if I'm to blame, but I cannot do anything about something I know nothing about. Very sorry. Regards, Pete

But all of the things you describe sound like it is a really bad model. Have you simply tried using the default 737 AIR and CFG files instead, just to see if the modelling is in bad need of adjustment? Does it use FSUIPC at all? If so, what for? If you think FSUIPC is involved why not simply try without it -- it isn't going to lose any settings as an experiment. Most panels only use FSUIPc for the TCAS displays in any case, and even that can be done directly with FS quite easily since MS published the traffic tools. That's a quite a bit of an exaggeration. The problem here is that I know nothing about making and tunung aircraft. Most of the parameters used for modelling an aircraft are just numbers to me, if that. You want an aircraft designer to sort your modelling out really. Regards, Pete

Okay. ThanksI've just found my old FS2000 Pro edition, and the main "patch 2" which Microsoft issued for it, and even the no-CD replacement EXE, so I'll do some testing tonight/tomorrow. I'll get back as soon as I've got anything. Pete

No. I've made no changes to anything relating to establishing an entry in the Menu nor even to the way the options window opens, so that is very odd. Can you tell me, please, what version of FSUIPC you were successfully using before? Also, when you say "latest" version, do you mean 3.51 or one of the interim versions released here since? I'll see if I can find FS2000 here to try it on. But please also tell me what operating system you are using -- Win98, WinMe, WinXP? Are you runinng anything which messaes about with Windows' appearance, like Window Blinds? Regards, Pete

Sorry, I don't recall anything about any "FT" 737, let alone VNAV. Can you be more specific? Who is "FT"? I thought the "PIC" name was from Wilco and Level D. I'm very sorry, but I have no idea what the problem is -- you don't seem to have described one. Pete

Hi Antonio, Well, I fished out my RP48 and connected it up, programmed one of the rotaries to inc/dec the 737 A/P IAS value in aircraft-specific mode, and every click did operate it. So I then also programmed the same rotary in non-aircraft-specific mode, to inc/dec the course (VOR1 OBI inc/dec). Both worked fine. When the specific aircraft was loaded the rotary adjusted the IAS on every click, and for all other aircraft it operated the course on every click. I had a look through my code too to see if there's anything there which was capable of missing the clicks in any circumstances, but really I couldn't find anything. Which leaves me in need of more information, please. I was hoping that, should this turn out to be a bug, I could fix it in the next release, but I must release 3.52 this week, preferably well before the weekend. So we have missed that one. Then I'm really a bit stuck till February. I may have a little time early in the new year, so if you could do that logging and show me the INI file details I'd still look at it. You can ZIP stuff up and send it to me at petedowson@btconnect.com. By the way, I notice in your first message here that you said: This FS module is the one which operates the GoFlight programming for the buttons et cetera. All you need to do is to make sure that the GoFlight programming for the rotaries you use in FSUIPC is cleared -- i.e. you don't want both GoFlight and FSUIPC processing the same 'clicks'. Regards, Pete

A facility to allow the older axis controls through whilst suppressing the new ones looked easy enough to do, so I've slipped it in quick before I freeze FSUIPC till February. I've sent 3.515 to you by email. Perhaps you'd like to test it for me, please? Be quick though -- I need to get version 3.52 released this week, preferably Wednesday if possible. To suppress axes without suppressing the older controls, you need to not only write to offset 310A/310B regularly, but also write "2" to the byte 3109 regularly as well -- write all three bytes at the same time, as you wish. Whilst 2^1 of 3109 is non-zero, the suppress axis bits should only operate on the new style controls. This applies only to Throttles, Aileron, Elevator and Elevator trim. Sorry, I have nothing suitable to test it properly with here. Let me know as soon as you can please. Regards, Pete

Only when FSUIPC is being used to calibrate throttles or provide mapping or reverse thrust capabilities. When the FSUIPC facilities aren't used the controls pass through unmolested in any case. I don't really understand what you are reporting, sorry. The AXIS THROTTLE(n) SET controls are those which are assignable in FS's own control assignments, for the overall throttle as well as the individual ones. These are not provided with a reverse zone in FS -- the range -16384 to +16384 give idle to full thrust. the only throttle axis controls which have a reverse range are those from FS98 days which are still coded in FS -- the four individual THROTTLEn SET controls. This is why the Page 3 calibrations in FSUIPC convert AXIS_THROTTLEn_SET controls to THROTTLE_SET controls. If also calibrates the THROTTLE(n)_SET controls unless that special option is checked -- the ERJ uses those controls. That is really the sum total of what that was about. You'll need to interpret what you see in that light. Well, I suppose there could be a way to disconnect only the new AXIS_ controls but leave the older "FS98" controls like those. I'll have a look. Would doing it via another flag bit suffice, i.e. one flag which says "don't disconnect old controls only new ones"? Regards, Pete

No need to be sorry. I'm glad it was so simple to fix! ;-) Regards, Pete

Since these are "results" from the FS simulation engine, changing them won't actually accomplish anything. This is why they get overwritten again on the next frame. So all you want to do is display fictitious values, on displays other than FS's own panels? If this is the case, what I suspect you really want is the facility to have the PM PFD display values from different offsets when, for instance pmSystems is running. Then, in pmSystems logic you can normally simply copy the FS values into the PM PFD-read offsets except when you want some fictitious values displayed. You could also program better in pmSystems the consequences of such failures. I suggest you discuss this with Enrico Schiratti in the first instance. Any method involving overwriting FS result values is just as "dirty" as what you are doing, even if it is faster, and, in my opinion, simply isn't the right solution -- unless I am misunderstanding your request. Regards Pete

The reverser on page 7 is, by default, assigned to the mixture lever. If you have no mixture axis assigned in FS, you will see only 0 there as no axis is driving it. You CAN edit the INI file and use any other (otherwise unused) axis for a reverser, but this is SEPARATE from your thrust lever. Similar considerations apply to the 4 separate reversers on page 11, except that none of those are assigned by default. If you do have axes to spare, by all means assign them in the INI file. It sounds like you simply want a reverse zone on your normal throttle axis/axes, in which case certainly calibrating them on Page 3 is fine. Note that there is no such thing as an idle "position" -- you need a small range of movement for the idle, slightly above and slightly below your detente, so that you get two different values in the FSUIPC centre calibrations boxes. Anything below those values down to the minimum (reverse) will then give you reverse. Unless there is something very badly wrong with your hardware, it just cannot "move" from where you set it in FSUIPC, so it simply sounds as if you are not calibrating it properly at all. You need 4 clicked positions -- one for max, two for idle, one for reverse. They all need to show different values in their respective boxes. The values for centre should be those read when your lever is around your detente. if they are not, then the idle won't be there. Please just follow the simple steps outlined in the documentation. They work for everyone else. Regards, Pete

You have at least two things mixed up there. This 2turning too slow" is a bit of a meaningless statement. Do you mean you cannot control the ailernos to their limit? If so, you have badly calibrated joystick axes, and you need to set all the FS sensitivities to maximum. here is no such thing as "too sensitive" overall -- if you reduce FS's sensitivity, you reduce the range. Don't do it. You can calibrate in FSUIPC and apply a slope, so you get less sensitivity in the centre but more at the extremes. This is the way most prefer it. As for the throttle, itr sounds like you have the axis reversed. Check the FS control assignment setting for it -- you can reverse it there, or in FSUIPC. Just don't reverse it in both places. Regards, Pete

Hmmmhow very strange. The code is the very same code. The table is just one table. All that happens is that the entries for buttons inapplicable to the current aircraft are reoved when the ones which are applicable are read. Were the same button numbers also programmed for non-specific use as well? Maybe it is something to do with the double check -- I could investigate that. Perhaps you could reproduce it with Button logging enabled (in FSUIPC's Logging options) and show me the log, with a little explanation about which button is which, please? The buttons sections of your INI would be needed too. Thanks, Pete

Yes, I usually do that, but I tend to add so many changes from one release to another I wanted to indicate that this was an incremental rather than 'new' version. However, considering I hope not to release another for many weeks (I am on holiday in January, then other commitments loom), maybe i ought to leave it clear and tidy as you suggest. Thanks, Pete

Sound like you have enabled the "Allow changes to FS own weather" option in the Technical options page of FSUIPC. Please see the User documentation. It is a good idea to read the descriptions of these options in the dox before enabling them, just in case you get results you weren't expecting. ;-) Regards, Pete

I'm sorry, I really have no idea. You entitle this inquiry "Joystick issue", but then talk about automatic throttle control, which surely is a software issue -- the joystick isn't used, is it? the PMDG aircraft are very complex, and I don't know how they are programmed at all. Sorry. Have you asked over at PMDG? Regards, Pete

So you have no panel on the FS PC? FSUIPC cannot handle graphics at all. Sorry. Processing AI traffic movements isn't a big job, as I said, but it would make things worse if all that had to be done by a separate PC running FS then all the AI aircraft fed through to the FS PC with the visuals -- for every movement of every aircraft there would be Network traffic and the FS visuals PC STILL has to draw them, which is most of the work. If this isn't what you were thinking of, please explain in more detail. There are ways of having two PCs on a Network both running FS -- you use WidevieW. I suppose the one with the visuals could process the AI traffic, and the other be your flying PC, with no AI traffic, using the AI traffic one for the outside view via WidevieW. I think someone has done this. It wouldn't work with any ATC program of course, but maybe it would do what you want. I still think the bottleneck will be on those visuals. It's all very well having a PC which theoretically can give you high frame rates for your user aircraft computations, but if the images can't be updated fast enough your visual frame rate is still low. I'm afraid most of this stuff is outside my area of knowledge and experience, however. You might like to discuss it with folks on a WidevieW forum, if there is one. Regards, Pete

It shouldn't "lock up" -- the SendMessageTimeout used in the code you call has a timeout 9that is why it is used). There may be several retries too, but it would probably do, say, 10 retries with a timeout of 2 seconds, so in the worst case take 20 seconds. I don't know the VB stuff, but this would be typical -- take a look. All the source is supplied, so there's really nothing hidden here, no mystery. If FS crashes or hangs the problem is usually thatnothing happens. Hence the time-out on the only part of your code which communicates with the FS process -- the SendMessageTimeout. How your program is hanging I don't know, but you should be able to find out by debugging. Regards, Pete

The problem is not so much managing the traffic, though that is certainly a workload, but managing the visuals -- I assume you want both your aircraft and the AI traffic on the same screen at the same airport? The actual processing job managing the AI traffic paths and so on is a relatively small load compared to visuals, as you could prove to yourself by getting just as many aircraft around you whilst cruising, but not near enough to see them all. There are really only three ways of improving performance at crowded, busy, airports: 1. Always make sure that the AI traffic aircraft have the fastest possible visual models. I have read that some of the add-on packages are better than others at this. 2. Reduce the traffic density a bit anyway. Using MyTraffic at the new Aerosoft EDDF I find it still pretty overcrowded with aircraft with the slider set to 70%, but the frame rates are then acceptable. Not great, but certainly okay for landing, taxiing (queuing more like! ) and takeoff. 3. Upgrade your hardware. Both the processor and video card play a part in this. One will be more of a bottleneck than the other, though it isn't easy to tell which. You can help somewhat by terminating all other programs and non-essential processes. Run FS applications on a separate PC (e.g. via WideFS). See what it is like with no panel for your aircraft, too. That eats quite a lot. There are systems which allow you to run FS with no panel and all the instrumentation on other PCs -- Project Magenta, of course, but also look at FreeFD. I have heard of others being developed too, but have no information. Regards, Pete

No -- each click here most certainly gives either a press or release, unless you turn it too fast, then you get a lesser number of "fast" button returns -- the are 4 possible button numbers on each rotary, remember. Two clockwise, fast and slow, two counter-clockwise fast and slow. You can program them all differently, or use the fast ones for "fast" controls (where they exist) or just for multiple controls (for the latter you'd need to edit the FSUIPC.INI file). It sounds like you are turning them fast and expecting each click to be recognised separately? Pete

Correct. Well noticed! However, you seem to not have noticed the explanation, which is actually in the FSUIPC user guide, thus: Nothing. You seem to be just misinterpreting what you are seeing. Regards Pete