Pete Dowson

I haven't checked, but I don't think you get normal axis logging from axes assigned "direct" in FSUIPC. This is really why I wanted you to try the normal assignment to the FS controls. You can still do this in FSUIPC, you don't have to re-enable them in FS, and your calibrations should still apply just the same. I think there is a way to intercept and see the "direct to calibration" values, but I'd need to delve a little more into my code. [LATER] Before loading FSX, edit the FSUIPC4.INI file and add Debug=Please to the [General] section. Then, in FSX and FSUIPC Logging options, edit the "Extras" edit box to read 8. Sorry for misleading you earlier. The "direct to calibration" doesn't use FS controls, so the control event logging doesn't see them. Do you find the throttles disconnecting just by bringing them to idle, with no A/T involvement, just as Paul Smith begin_of_the_skype_highlighting end_of_the_skype_highlighting states? Regards Pete

Sorry, no. There are tens of thousands FSUIPC users. I am using it 100% There is absolutely nothing in FSUIPC with a 5 second cycle. Maybe it is a specific bug in the German version of SimConnect? You say it occurs even with FSUIPC unregistered and with no add-ons using it. In such a state it is dormant, merely posting data in its offsets when SimConnect provides new updates. The weather scanning is regular, but more like a one second interval (and that is adjustable in the INI file). The only other requests the recent versions make are for "nearest airports", but for those to occur you have to be moving over the scenery (are you?) -- and they are not regular, like every 5 seconds, but certainly could be based on speed -- and then they'd depend on SimConnect identifying the changes, not on FSUIPC requesting. The best I can do to help you nail it is to tell you how to change the weather intervals, or to stop them, and possibly to supply a version with an option to stop "nearest airport" requests. There's nothing else which is possibly going to make any different whatsoever, and I don't hold out much hope for those. The only times I've ever had a significant "stutter" at regular intervals (twice now on different systems over the 3 years of FSX), it has ALWAYS turned out to be hardware or driver-related, but hard to identify what. The last one disappeared when I updated from my Skulltrail overclocked system to my i7 overclocked system. Regards Pete

Sorry, no. There are tens of thousands FSUIPC users. I am using it 100% There is absolutely nothing in FSUIPC with a 5 second cycle. Maybe it is a specific bug in the German version of SimConnect? Regards Pete

I'm afraid that if you opt to disable your joystick controllers in FS it also turns off the mouse facilities. There's no way around that. However, in general, if using the mouse if important to you, there's usually no reason to disable controllers in FS. Just don't use FSUIPC's Axis assignments. You can still calibrate them in FSUIPC even if you assign in FS -- assignment in FSUIPC is an option, not a pre-requisite. Instructions for doing what, though? You are quoting out of context. There's a chapter on using axis assignments and a separate chapter on using FSUIPC calibrations. The former has NEVER been necessary to use the latter, and nowhere is that stated! The axis assignments facility was a relatively recent addition. The calibration facilities have existed since FS2000 days! FSUIPC is a toolkit, like the Swiss Army Knife. You select and use what you need. You don't use everything just because it is there! That makes no sense. Regards Pete

There are only two possibilities I can think of: 1. Either your PC's system date is incorrect, shoing a date BEFORE you purchased your registration key. This will make it look invalid, of course, 2. Or your registration is, in fact, invalid, generated by an illegal key generator. As I assume you wouldn't come here if you are using a legitimate key, I think the former must apply! Regards Pete

Show me a section of the Log file, from the very start. It will tell me what log options you have selected. Also please paste in your FSUIPC4.INI file so I can see what you are setting on the axes. No. Paul has also told me that the problem is nothing whatsoever to do with the AutoThrottle. He is saying that even when flying the Concorde X manually, merely reducing the throttles to idle will cause them to "disconnect". This is if FSUIPC is calibrating the throttles -- it doesn't matter where they are assigned, he says, Is this what you see too? So, something in the Concorde sees zero on a throttle axis and somehow disconnects it? Weird! I am astounded that of presumably hundreds if not thousands of users, by now, only two or three of you have such an amazingly drastic problem! Have you yet tried without the "no reverse zone" option set, or with the ThrottleN_Set option unchecked? Anyway, I've had a long discussion with Paul. Unfortunately he doesn't know anything about what the Concorde is doing internally, so I think he'll be discussing it further with the programmers. I don't really see there being any resolution without their involvement because obviously it is something quite peculiar their code is doing. If I am to help they'll have to supply me with a Concorde in any case, and I'm not going to be able to do anything now till about May 10th or later. Regards Pete

I assume you mean "WideFS", not "WideScreen"! I don't make anything called "wideScreen". That's a TV or Cinema term. Yes, that's wait it will say until it can connect to WideServer on the FS PC (For FSX WideServer is built into FSUIPC4). No, that's unlikely. What needs to happen for two programs to talk to each other over a Network is a Network connection. Do you have the PC running WideClient connected on a Network to the PC running FSX? That's the first question -- you have told me nothing at all about your PCs. If you already have a Network, is it working correctly? Can you access files on the other PC from each? If it is a working network, then the most likely problems are either they are on different WorkGroups and therefore broadcasts are not being received, or you have one or more firewalls blocking communications. Have you read any of the documentation supplied with WideFS, particularly the network configuring part following the installation instructions? Finally, FSUIPC4, WideServer and WideClient all produce Log files which will you you and I exactly what is going on. Please find those and have a look. that is what they are for. By the way, please ALWAYS state FSUIPC version numbers when you ask for help here. It is essential information. You can find the version number displayed in the FSUIPC options, on screen, or in the FSUIPC4 Log file, or by right-clicking on the DLL itself and checking Properties-Version. Regards Pete

You have an error then. There is absolutely no other explanation. You need to use a debugger and work out what you are doing wrong. Sorry, I really cannot help you debug your code, especially stuff which makes no sense to me whatsoever. I can't even see where you are calling FSUIPC_Process to call FSUIPC. If your FSUIPC_Read is the one I supply in the library, then all that does is put your request into a queue in the shared memory-mapped file area. Regards Pete

In that case it would be interesting to find out if the problem still occurs with the option unchecked. Save a copy of your FSUIPC4.INI file first, because without that option you'll need to re-calibrate. You can actually get the same effect by calibrating with a zero-sized reverse zone -- that's how it was done before I added the checkbox option. BTW there's no rush as far as I am concerned. This weekend is pretty fully occupied as it is and next week I've a lot to do before disappearing on holiday. If it needs any tweaking in my software it's probably going to have to wait a few weeks. All I'm trying to ascertain at present is what is going on. I've a feeling I'll need FSLabs to loan me a Concorde X if I'm going to solve it for them -- I don't want to buy one as I really would never fly it. Not that I'm against the Concorde, it's just that I have a very-specifically configured 737NG cockpit. Flying anything else in it is almost impossible, and flying on another PC elsewhere just isn't much fun compared with the full hardware cockpit with projected scenery experience! ;-) Regards Pete

Hmmm. The keyboard F1 to F4 are by default assigned to Throttle Idle, Throttle Decr, Throttle Incr and Throttle Full respectively. Obviously you could assign (one of) those to button(s), or even, say, 'throttle inc' to a zone on your levers, using the right-hand side of the axis assignments tab. Do you use FSUIPC's 4 throttles calibration tab for a throttle with reverse zone, and calibrated with such a zone? If you use the "no reverse zone" option, does that make a difference? And does the ThrottleN_Set option at the bottom of the calibration tab make any difference? It might be a good idea to see what the logs show when the throttles are operating normally and compare them to when they are "disconnected", and also show what happens when you issue whatever keyboard control it takes to get them connected again. It is definitely sounding more and more a bug in the Concorde X which just happens to manifest itself with the group of FS throttle controls issued by FSUIPC when compared with the normal ones. This is why a test with "no reverse zones" is important -- the controls are different. Pete

So, I'm still not sure how you ever get your throttles back. Do they stay disconnected until you reload FSX? Do you know who or what is disconnecting them? As I said, there is a facility to do this in FSUIPC, but the Concode X add-on is not using FSUIPC at all. When they are disconnected, what does the FSUIPC4 log show if you enable axis logging and move the throttles? Pete

Really? That's odd because both XP 32 and Win 7 64 do. It one of the tabs in the "USB Root Hub" device properties, in the USB section of the Device Manager. I can't believe Microsoft had this in XP and continued it in Windows 7 with a gap for Vista. You shouldn't need the filter. That's really quite a drastic smoothing and needs several prior readings to act upon. It was originally put in for some users in Indonesia and rural India where the power supplies were so erratic that the readings from the potentiometers in the axes were varying too much. I'm sure Saitek controls are good enough, and your power supply stable enough, to do without FSUIPC's filtering. Are you using 4 separate throttles and assigning them individually, or using one or two and mapping them in the calibration page? And can you explain, please, exactly what it is you meant by "re-activate autothrottle, to reactivate levers and to cut the autothrottle has new", as it still doesn't make sense to me. You appear to have missed this question in my first reply. Pete

What are you normally sending a pointer to, then? Obviously that's where your problem lies -- in your consequent interpretation of the data due to using the wrong data type. Doesn't this "Tcl" have a debugger you can use? when the fault is in your own code that's usually the best way to locate it. You should always use the correct type for the value concerned. The heading is actually an unsigned 32-bit integer, so "unsigned int" (in C) would be correct. If you are interpreting it in any other way you are going to see wrong values. It is nothing to do with how the interface works. As far as FSUIPC is concerned all the data in all the offsets is just in single bytes, and you are reading an array of bytes of the length you request. But your code MUST interpret them in the correct way for their contents. The data isn't different (there's no way it can be!), it's how you are treating it. Regards Pete

How does that happen? There are facilities in FSUIPC for applications to disconnect throttles, as well as ailerons, elevators, rudders etc, but these facilities need positive action on the application's part -- writing values to specific offsets. Before anything else, though, please make sure you are using version FSUIPC 4.60 or later. If you are not, update first then come back if you still have a problem. I cannot support any older versions for FSX. Also, in your first report in the thread you reference you describe the problem as follows: There is no other explanation in that thread and no clearer description of the problem, and I'm afraid your description is one I don't understand. Can you explain what the difference is between activating and deactivating the A/T and doing it twice, which you appear to say works? In other words, what does this mean: "re-activate autothrottle, to reactivate levers and to cut the autothrottle has new", as it doesn't make sense to me. Regards Pete

Er... yes, I think you should buy it. I really cannot be seen supporting folks who "borrow" (= steal) software! Pete

Ah, good! Hmmm. At least they do change. I'll check to see what might be wrong. Thanks! Regards Pete

Okay. That's FSUIPC4.LOG. FSUIPC4 is being loaded. That isn't the problem: These extracts from the Log show the problem. You FSX installation is a bit screwed up. Either that or you have additional or invalid copies of "simconnect.dll" installed somewhere in your system -- maybe in the Windows folder, or more likely in the FSX or FSX\Modules folder. If there are any, possibly installed incorrectly by another application, then they need removing. The best solution, however, is probably to update to the later version of FSX, the one with most of the Simconnect bugs fixed -- SP2, or, if you want to pay, FSX Acceleration. I'd recommend downloading and installing the SP2 update and getting your FSX installation up to scratch. It's included in FSX. It doesn't need updating separately. You have an out of date version of FSX in any case. If you update to FSX SP2 you will get the correct updated version of SimConnect automatically. Don't worry. Your English is excellent. You wouldn't want to see any of my French! ;-) Regards Pete

In actual fact he never answered the questions so we don't know what the cause of his problem was. Yours might be different, but the same questions apply to find out. If there's no Add-Ons menu it could mean FSUIPC isn't even getting loaded, but it could mean it is loaded but then has a problem. The difference will be whether there's a Log file or not. And if there is, that would show what is wrong. It would be called FSUIPC4.LOG and be found in the FSX Modules folder. If you have Windows set to hide real filenames from you it will probably just look like "FSUIPC4" with type "text file" or something like that. It looks okay, but you could simply delete it and re-run the FSUIPC4 installer to be sure -- there's nothing else specified to be loaded except FSUIPC4 in any case, so that would be best. Regards Pete

That's normal, should work. That's just like using FS only, but with FSUIPC tarting up the values to fit better. Sounds like there's something rather peculiar going on with the particular Airbus throttles. No idea what it could be, though. Still, as long as it now works. And at least in FSUIPC you can have different assignment methods for different aircraft. Regards Pete

Well that's just one way of assigning them, but a commonly used one because it's rather more efficient than the others. I'm glad you solved it, but I'm a bit curious. What method of assignment have you used before? Regards Pete

No, not possible, sorry. All gauges written as Gauge files are 100% dependent upon the functions provided for their display and operation inside FS. They are effectively parts of FS and cannot live without it. Regards Pete

No, not relevant. The axes aren't really "stopped". Because your input has a range of 256 the obviously all changes will be ignored with a Delta of 256. However, I thought the Delta automatically changed to 1 when RAW is selected. Isn't it doing that? Maybe I haven't done that? Regards Pete

Please download this version: http://fsuipc.simflight.com/beta/FSUIPC4605.zip Just copy the FSUIPC4.DLL inside into your FSX Modules folder. Please let me know if that helps. I've made the button and axis scanning one call to Windows -- previously it was two separate calls per cycle. I'm thinking now that possible the call for button values and the call for axis values interfere with each other when the latter is using "RAW" mode. It's probably a timing thing -- Raw mode will be bypassing a lot of stuff. Regards Pete

Before you do that, don't you think we ought to find out whether this change, in how FSUIPC4 uses Windows APIs, made the difference? Note that in FSUIPC3 I use the Windows "joy" interface for both axis and button scanning. In FSUIPC4 I used DirectInput for axis scanning and the "joy" interface for button scanning until recently -- 4.60 uses DirectInput for both. I changed because some devices gave problems when using the different interfaces. This is why I am concerned about the above change in FSUIPC. What was the previous version you used? Do you still have it? This is the note of the relevant change, taken from the FSUIPC4 History document, in the section about 4.60: If it worked okay before 4.60 then I'm concerned that the problem is related to that change. So please do NOT do anything drastic yet. Let me know which version it worked with. I'll look here to see what might be happening. Maybe I have to do something explicit in my calls to Windows to make RAW mode stay stable. The more I think about it, the more I am convinced it may be a RAW mode problem which I've overlooked in the recent changes. Regards Pete

Something is wrong with the documentation GoFlight have provided me, then. I need the logging data I asked for please. You don't need to be an expert. Simple go to the Logging tab in FSUIPC options (the one marked "Logging") and check the option on the left which talks about Buttons and Keys. Do NOT change anything else there nor press any buttons. Then go to the Buttons and Switches tab, operate all of the MESM switches TWICE, noting down what you do so I can match the log entries to your actions. Then go back and uncheck the Logging option you checked, exit from the Options and from FS, find the FSUIPC4.LOG file (in the FSX Modules folder) and show it to me -- you can cut and paste it into a message. (If you have Windows set to hide the real filenames from you, it will be the "FSUIPC4" file noted as a Text file). Thanks. Pete