Pete Dowson

Paused or not makes no difference to FSUIPC. It only requests values from SimConnect once and relies on SimConnect to deliver them when they change. Possibly FSX doesn't compute some of the values you are reading so often, or at all, when paused. However, all that would mean is that the values you receive aren't changing so often. The process of calling FSUIPC (which is via a type of "SendMessage" call) is independent of whether FS is paused or not -- FSUIPC will process the message when it receives it and return the data to you in exactly the same way no matter what state FS is in -- there's nothing in FSUIPC which cares at all whether it is paused or not. If you don't really mean "paused" but busy, as in reloading a flight or within a menu or dialogue, then that is more understandable. FS's Messages aren't being processed when it is 100% occupied doing other things, and the menus and dialogues are mostly modal. Another time when FS probably slows things down is when minimised. At least that was true with FS9, not so sure about FSX. Regards Pete

For FS9 you could do that by adjusting parameters in the PANELS.CFG. Each "window" has its own zoom, angles and so on defined. In FSX I think it is pretty much all done by "cameras" now, as defined in CAMERAS.CFG and in other such files. It isn't something I've looked into a lot, but the program I mentioned, Ecza, has a range of facilities for defining many cameras. Worth looking at I think. Regards Pete

Multiple Windows is a problem with FSX full screen mode. I think it depends upon the video card too, and maybe driver versions. Thanks. Not sure what you mean. Certainly the EZDOK program Ecza has a lot of possibility for careful making and selection of camera views. Is that what you mean? Regards Pete

How does it say that? I don't remember ever putting such a message in? If you have valid FSUIPC and WideFS keys, simply register using them. What is the problem in doing this? As long as you are using a recent version of FSUIPC (and 3.98 or 4.60 are the earliest supported versions), it will accept a different email address for FSUIPC and WideFS. Your name must be the same, however. Pete

Sorry, you are asking in the wrong place. I do development and support, but all sales and sales queries are handled by SimMarket. Raise a problem ticket there and explain the mistake. You never know, though I think it could be problematic since everything is more or less automated. Regards Pete

No, sorry. But there is a separate program which will do it. Not reliably? Hmm. Well I'm not sure that I could do it any better than they. All a program can do is read the positions as they are when you say to "save" them (or possibly automatically when you close FS -- though that's a little less reliable because by the time the program or add-in has read the positions some might have closed), and likewise restore them when requested (or, again possibly but less reliably, try to detect them when they are re-created and move them). Maybe the program you are using is trying to do it automatically? See if it has hotkeys or menu methods of saving and restoring when you say so, instead of automatically. That would be a more certain approach. Incidentally, there can be problems with window positioning if any of the screen x,y coordinates are negative. That will occur if your main Windows screen is not the top left-most in your Windows screen arrangement. I've found it always best to site the secondary screens to the right and/or below the main active Windows screen. If your arrangement is not like that, try to make it so then see if the program works more reliably. What is the name of the program, BTW? I've forgotten the one I read about. Regards Pete

Right. The log helped a bit. I think this update should do more for you: http://fsuipc.simflight.com/beta/FSUIPC4607.zip However, I'm puzzled that the MESM isn't detected in my initialisation routine: I assume you do have those three devices? The MESM should be listed too. Is the GFDev.DLL module being used the latest, or at least very recent? It seems the lack of the MESM being identified in the Log could indicate an out of date GF driver -- not the GFConfig you are using, but the GFDev.DLL. You should find that in the same folder as your GFConfig. Could you check its version, please? There's a recent one in my Updates announcement, here: Oh, also please check that you don't have this DLL in the FSX Modules -- or put the up to date one in there. Thanks & Regards Pete

Why not? There's no real difference between that and any other yoke. If it is seem by Windows as a pair of axes, so it is seen in FS, and thence in FSUIPC. Pete

Can you re-phrase this into something meaningful, please? It doesn't appear to say or ask anything at present. If you are asking if FSUIPC is compatible with the Saitek yoke, then the answer is yes, of course, as attested to by many users. Pete

Thank you (and he) very much. It is nice to see how folks resolve problems. I would try to put some sort of explanation into the WideFS documentation. Unfortunately, however, I don't really understand the explanation well enough -- except for the part where you had the fixed IP address range set differently, but wouldn't that have been obvious from the Router's own IP address, the one you need to use to configure it? I always assumed that all devices on the same LAN had to be using the same first three numbers (i.e. 192.168.1 instead of 192.168.0). The network "submask" (255.255.255.0) enforces this. For now, till I find a way of explaining all thev DNS stuff that I understand, I will refer folks with similar problems to this thread. Thanks! Pete

No problem -- I'm glad you got it sorted! Good flying! Pete

The ButtonRepeat parameters are for all buttons read by FSUIPC no matter what you program them to do. Pete

Thanks. The logs I have shows there's no difference in FSUIPC's actions. Basically, if it is calibrating, it either intercepts the throttle controls (if the FS controls are being used), or, of course, gets them directly if that method is selected, works out the correct calibrated value, and sends them to SimConnect using the normal SimConnect event system. Of course, in order to avoid a never-ending loop, it intercepts the controls at a high level, and sends them to SimConnect at a lower level -- otherwise it would receive copies of the controls it just send and end up in a tight loop. Since there's nothing different going on in FSUIPC (as really I expected -- after all, to FSUIPC, zero for "idle" is not a special value, it's just another on the spectrum of values) I won't be able to help anyone with this until FSLabs look at it. Even if they supplied me with a ConcordeX to try I'm not really willing to dive into their code to see what they are doing. There's obviously some sort of test they are doing, with action following, because the throttles work normally on the ground, and normally in the air UNTIL reduced to idle (or A/T connected then disconnected). For some reason they seem to be trapping and discarding the lower-level SimConnect events being sent, but only after one of those things occurs, and only in the air! It is so specific, and in such specific conditions, that their programmers must surely be able to determine what is going on very easily, and thence fix it. I'm copying this to Paul Smith and Lefteris. Regards Pete

As described in the FSUIPC Advanced User's guide, the "ButtonRepeat" parameter in your FSUIPC.INI [buttons] section(s), controls the button repeat rate, and also the initial delay till it starts repeating. For small increments you could when pull back intermittently which would send just one F2 each time. Alternatively (or as well), the F2 key is, by default, assigned to "Throttle Decr". FS does supply a "Throttle decr Small" which probably gives you a smaller throttle change per press. So, why not try assigning to the control rather than relying on a keystroke? Regards Pete

Okay. Download and install http://fsuipc.simflight.com/beta/FSUIPC4606.zip In this version the collection of airport data is configured off by default. I decided this because, in fact, it seems to be unreliable in any case -- SimConnect often doesn't even supply the irport under the aircraft's wheels as one of the nearest airports, so the usefulness of the facility is somewhat diminished (to say the least!). I haven't ripped out the code in case folks want to experiment, but it now has to be enabled by setting "GetNearestAirports=Yes". As I said, I don't really hold out much hope of this doing anything for you, but there's nothing left to remove. BTW. Also check you aren't getting periodic queues building up for disc access. Don't rely on the little LED telling you about its activity. Here's an extract from a reply over in an AVSIM forum thread from Kosta (whom I'm sure won't mind me quoting him): Regards Pete

Okay, try this: http://fsuipc.simflight.com/beta/FSUIPC4606.zip Now the button mapping should be something like this (all on Joystick 166): Left GND = button 0 released Left OFF = button 0 pressed Left CONT = button 1 pressed Left FLT = button 2 pressed Ignition Left = button 3 released ignition BOTH = button 3 pressed Ignition Right = button 4 pressed Right GND = button 5 released Right OFF = button 5 pressed Right CONT = button 6 pressed Right FLT = button 7 pressed Regards Pete

You can disable all FSUIPC's weather reading and setting facilities completely by setting the Weathe Interval Factor to 0. In a registered FSUIPC you can do this in the Winds tab. Alternatively, as an experiment, you could just try increasing the number (it defaults to 2) to see if that changes the frequency of your "stutters". If it does there's something wrong with SimConnect's weather reading and decoding mechanism. With an unregistered FSUIPC you'd have to edit the FSUIPC4.INI file to change the "WeatherReadFactor" in the [General] section. The only other option which might be worth inhibiting is that for collecting data from nearest airports. There isn't such an option at present, but I'll add one and let you know. I can't see how the actions of SimConnect there would cause you regular stutters, however, because if you aren't moving there wouldn't be any updates, and if you are moving the amount of data updating would depend on how fast you are moving and the density of airports in the area. With an unregistered install there really isn't anything else FSUIPC is doing that you can stop, because it is then merely receiving data from SimConnect to provide to programs like your PM, and of course dealing with requests arising from them. Regards Pete

Okay. It looks, from the log, as if FSUIPC is detecting all those correctly. Here: So "GRD" will be buttons 166,0 1 and 2 all off. "OFF" is 166,0 "CONT" is 166,1 and "FLT" is 166,2. That's all as intended, so it puzzles me when you say: because moving from CONT to FLT button 166,1 should turn off and 166,2 will turn on. And vice versa, as the log shows. GRD is button 166,0 going off, so you program that on "release" of button 0. The others can be programmed only on the press. I've found the problem with the other two switches and will fix that in the next update. Thanks, Pete

Ah, humble apologies! sorry, i didn't see that part of the filename. My eye was only drawn to the numbers at the end. Severe tunnel vision is the reason I don't get out much and why I never got my pilot's license. It's the main symptom of my increasingly severe Retinitis Pigmentosa. Less and less vision each year. I must remember to scan more! :-( Sorry if it wasn't clear, though the whole sorry episode is mixed up with different things. I'm currently doubting that any logging will tell me anything useful because it certainly looks as if the whole business is contained in Concorde X code. Okay. That's enough. I'm not coming back to this thread. I'll look at them, but if anything needs sorting out I'll do it with FSLabs. No need for us to trade insults any more. Pete

No. The problem was I was assuming you'd named the logs according to the test case! That's why I say there was no number 1, and a number 9 instead. I now see that you numbered them internally, not by using the filename. Do you see the filenames in the ZIP? That's how! As I said (appended to the above), with Filtering on I don't think these will be useful. Sorry. Pete

Not sure when I can look at this seriously -- I'm hoping the Concorde X folks will have something to say in any case, because it is obviously 100% tied up with whatever they are doing. Hopefully there will be something from them by the time I get back May 5th or later. However, some questions for you still: 1. In the ZIP there are logs numbered 2, 3, 4, 5, 6, and 9, and a ReadMe describing "test cases" 1 to 6. Is log 9 mis-named? If so it seems odd because time-stamp-wise it falls between 6 and 2, which, time-wise appears to be last. 2. Have you yet done any testing with the axes assigned to the FS controls (still with your calibration) instead of "direct to FSUIPC calibration"? This is most important as the routing of the controls then is completely different! Note that there are two different sets of FS controls you can assign to in the drop-down: AXIS THROTTLEn SET controls and THROTTLEn SET controls. It would be useful to test both -- but for the latter you MUST uncheck the "exclude ThrottleN Set" option on the 4 throttles page. I have asked for you to try the calibration without the "no reverse zone" checked, as again this makes a difference to handling. Have you done that yet? [LATER] I've just had a brief glance at a couple of the Log files. you still have Filtering on! I thought I asked you to turn that off, at least for testing? Unfortunately the logs aren't really very informative, because the Filter option stops the controls being sent by the calibration routine. Filtered controls have to handled asynchronously LATER, using a routine which samples a number of values and takes a moving average. I'd need to add completely different logging facilities to see inside that. Apart from that, the logs seem to show everything in FSUIPC working fine. Assuming the filtering is doing what it normally does, I would say that the non-operation of the throttles is being caused AFTER FSUIPC has finished with them -- back in the Concorde I presume. Anyway, please disable the Filter option before any further testing with logging. Regards Pete

Yes, you just need to watch the KEYDOWNs and KEYUPs and set flags accordingly. ALT is a little awkward as it can cause the KEYDOWN to be aa SYSKEYDOWN (or something like that). If you deal with ALT you need a little extra code. The Microsoft developer help on all that is pretty good. I'd need to look it up. I don't remember it all I'm afraid. Incidentally, if you are using FSUIPC in any case you could, instead, use FSUIPC's hot Keys facilities and let it do the trapping for you. Regards Pete

Please update to a supported version of FSUIPC4 -- i.e. 4.6 or later. Sorry, but none of my programs has anything to do with any of that. You need to talk to PM support. That's not relevant because you aren't using WideFS yet. You have no network. I think it is "FSPLANS". Yes, you must do that, when you have a Network. I suppose you could set it up ready. Win7 Help is quite good. Win7 is not so different. Do it the same way as you would in XP or Vista. Right click on the folder and follow the word "share" etc. I'm sorry, but I really cannot undertake support for PM and Windows 7 as well as my own programs, for which you have no questions in any case. On FSX WideServer is built into FSUIPC. The current supported version of FSUIPC is 4.60 or later, so, yes, currently you are not supportable. But it makes no difference to PM or a non-network in any case. Regards Pete

Sorry, I have no experience at all with either SimConnect key captures nor DirectInput. I've always simply processed the WM_KEYDOWN and WM_KEYUP messages being sent to the main FS window, which I subclass. Regards Pete

The Saitek devices use FSUIPC when run with FS9, but I don't think they do at all when used with FSX. Unless you've programmed something in it, FSUIPC won't have anything to do with whatever the knobs are doing. You need to talk to Saitek support. Sounds like their interfacing module or program is faulty. Further proof you need to talk to Saitek. Regards Pete