Pete Dowson

You can assign any number of axes to the same FS action or control, so there's no problems at all for assignment. For calibration, FSUIPC doesn't calibrate axes as such, but the FS controls they are assigned to. Providing your axis inputs aren't widely dissimilar this shouldn't pose any problem at all. Just be sure that the central "dead" zonew covers the little sprung-centered positions of all of them. Pete

Just to put an end to this, now I've got my flight PC back for repair, I've installed P3D 1.4 on it and used it with ActiveSky 2012 setting the weather, and in FSUIPC 4.923 monitoring both Ambient Temperature (offset 0E8C, type S16) and the TAT (offset 11D0, type S16), I see good and realistic values both on the ground and flying at altitude. To be honest, I *know* there was nothing changed between 4.92 and 4.923 which could possibly have changed this, and in fact logically there is no real way for FSUIPC to make the TAT change -- as already stated, it is computed in the innards of code far away from FSUIPC (probably in SIM1.DLL). I don't think Matthias has bothered to do any cross-checks like logging the values, and he certainly has not provided any of the information I requested, so I am closing this thread now as completed. I'm not willing to succomb to any more of his rants. Pete

I was so worried about this that I actually purchased this aircraft and installed it in FSX. I get a crash as soon as it is loaded. but I get it with both 4.92 and 4.923, and, intrerestingly, with no FSUIPC at all! The error is in MSVCR90.DLL, whch is just a run-time library for C/C++ functions, and happens shortly after "Tbmsound.dll" is loaded -- presumably the special sound module for the TBM840. I think you need to report the problem to Wilco. I could find no relationship between FSUIPC and this crash -- I suspect they are referencing an uninitialised variable (the crash is due to access violation), and with that sort of error the results vary according to whatever was left in memory by some other activity. I think only this could explain the difference you see between 4.92 and 4.923. Oh, and out of curiosity I also installed the P3D version in P3D 1.4, and get no crash with it at all, in 4.923 or 4.92. I think this pretty much proves my diagnosis. Now I have an unwanted TBM840 ... any takers? ;-) Regards Pete

Hmm. Strange. Use the logging facilities in FSUIPC to make sure it is doing the right thing. If you check against Button logging and Event logging it should show you exactly what it is doing. If you (temporarily) run P3D in Windowed mode you can also check the Console Log option and see it happen in real time. Regards Pete

I don't think it does, because it will be cached -- but I'm not sure about that. I've never delved into it really. Whenever I've changed something in a Aircraft.CFG file I've always changed aircraft and back again to make sure it reads it anew. I can't think of any reason they can't work from Lua. They certainly work even from other PCs using WideFS. Regards Pete

Not sure why FSX sees it and FSUIPC doesn't -- it is almost always the other way round. Are you using Windows 8? Because it seems that's a common problem in Win8 and Win8.1. Doesn't FSUIPC see them again when you enter the FSUIPC options? Unless you've told it not to rescan, it should pick them up again there. It rescans automatically when you unplug and plug in too. Check the properties of all the USB hub controllers listed in the Device Manager. You should make sure that Windows power management for them is turned off -- it defaults on, and devices "go to sleep". Regards Pete

I'll have to work out what is going on -- difficult without the aircraft. I need information please: 1. Your FSUIPC4.INI file 2. The FSUIPC4.LOG file 3. The crash details from the Windows event viewer log. You can paste them all into a reply here. If this data doesn't help I might need to see Wilco can provide a copy for testing here. Regards Pete

Well, maybe. But it's a bit odd -- you'd expect any application implementation of "SetWindowText" to call that API in Windows DLLs which would be common to all. Pete

The last figures were in Flight Mode, and despite the OP's preposterous accusations, that was all with P3D1.4 and FSUIPC 4.923. I've also tried injecting weather from WeatherSet2. I am not about to purchase AS licenses for this PC. The weather themes have several temperature layers and cloud and wind layers and are as typical a weather setting as you could get from Active Sky, just fewer layers. I'm going to have to ignore the OP from now on. He is still blinded by his own fury and not providing the simplest information I ask for, yet he expects me to drop everything and do exactly as he wants. Thanks as always, Herve. Pete

Okay. That's it. I've had enough of this. I spent hours last night and more time this morning and you say something ignorant like that!? You are apparently deliberately ignoring what I say, and still refuse to provide any useful information. I am not answering any more of your totally useless contributions until you at least do as I asked. I am wasting my time with you and I have far too much to do already without this nonsense. Pete

I use Weather Themes, which are simply pre-defined weather settings similar to any you can inject from an outside program. Once the weather data is actuvated inside the Sim its source it totally irrelevant. If only injecting weather into P3D makes the values returned by SimConnect go wrong, then it simply MUST be either bad weather data injected, or a bug in P3D. Don't you see that? This is why I asked, twice now, for your saved FLT + WX files, and to see your FSUIPC settings, which requests you continually ignore. No, because weather once active in FS is the same no matter whence it came. The mechanism by which it got there isn't relevant -- UNLESS it was the actual mechanism which is at fault, as I keep pointing out. Pete

It was not installed on the PC I can currently access. My main Pc went away for repair and has only just returned, 5 minutes ago. I will be spending most of the rest of today getting that set back up. For you I was up until 02:30 last night and on to it again at 09:30 this morning. I have reluctantly installed 1.4 on this PC and tested it and proved that it is okay inall the respects I can actually test. You getting angry does not change the truth, nor does it help at all. I have already explained TWICE why some changes in some places can bring out faults in others, yet you refuse point blank to even acknowledge what I am saying. I really cannot support people with that sort of attitude. If you want to get to the bottom of things I suggest you moderate your behaviour and at least read my actual words and accede to the requests for information and files. I'm not going to ask again. If you continue is such a fashion you'll be on your own. I will then assume you will stay with 4.92 and ask for no more support in the future. Pete

Okay. This morning I've gone to the trouble of reinstalling P3D 1.4 again -- something I'd hoped I'd left behind. I'm not using Active Sky, just default weather. I used FSUIPC's Monitoring facilities (on the Logging tab) to log the TAT and SAT temperatures (offsets 11D0 and 0E8C, both U16 types). On the ground I get these values: 465367 Monitor IPC:11D0 (S16) = 3858 465367 SimRead: 11D0="TOTAL AIR TEMPERATURE" FLT64: 15.0685825778 475351 Monitor IPC:0E8C (S16) = 3854 475351 SimRead: 0E8C="AMBIENT TEMPERATURE" [also 34A8] FLT64: 15.0539188814 (Note that the offset values are 256 x the temperature, to retain fractions). Climbing to 17000 feet, the values with a static aircraft (.e. in slew) stay comparable all the way, to: 495896 Monitor IPC:11D0 (S16) = -4819 495896 SimRead: 11D0="TOTAL AIR TEMPERATURE" FLT64: -18.8283806794 495896 Monitor IPC:0E8C (S16) = -4838 495896 SimRead: 0E8C="AMBIENT TEMPERATURE" [also 34A8] FLT64: -18.9006768221 Releasing the slew and flying higher I get the expected sorts of differencs, like this at 45000 feet: 962589 Monitor IPC:0E8C (S16) = -14435 962589 SimRead: 0E8C="AMBIENT TEMPERATURE" [also 34A8] FLT64: -56.3924792267 962620 Monitor IPC:11D0 (S16) = -9662 962620 SimRead: 11D0="TOTAL AIR TEMPERATURE" FLT64: -37.7458117115 So, sorry, no I cannot reproduce the problem you see. Maybe it is related to some settings you have in FSUIPC, but without seeing your INI file I really haven't the time to try every variation. Regards Pete

Thanks Herve I'll reinstall 1.4 today and take a look. Regards Pete

No, you are wrong. I understood you perfectly. But you did not read what I wrote in reply! I will repeat: This is still pointing to a bug in P3D. Maybe, because of the difference in code sizes and other memory usage actions in FSUIPC, the memory arrangement of other things in P3D is a little different, and that different causes corruption or use of different uninitialised values. This sort of thing has hasppened before, many times. Only by virtue of a different memory arrangement, as I said. It still points to P3D. I am NOT saying you are wrong in what you observe, only in your diagnosis of the cause. And I cannot try it with Active Sky at present, probably never unless ASN will do the same next week. This is why I suggested you send me the WX fies from a saved flight in which it occurs. It is NOT given by FSUIPC if you are using ActiveSky 2012 with its SimConnect interface. It is ActiveSky which sets SAT, in its METAR strings over the SimConnect interface. FSUIPC will only set these things if it is told to. Maybe you should show me your FSUIPC settings too. If you are not using any of the weather facilities in FSUIPC it NEVER writes any weather data to P3D. Pete

Aha! Now I see. Although the assignment dialogue in FSUIPC's Keys tab recognises one as "Rtn" and the other as "Enter", the code received by the routine which invokes the action is the same for both - the ASCII 13 for 'return'. This won't match the numpad 'Enter' keycode placed in the INI file, so nothing will happen if only Enter is assigned and not Rtn. If Rtn is assigned then both do the same thing. Interesting that you found this after it has been like this now for 12 years, in all versions of FSUIPC since key programming was first added! I'm left wondering if the same applies to other NumPad keys. Too late here now to experiment -- I'm off to bed! I might look at changing this. It would mean doing more code to get the extra data distinguishing the keys. However, I'm also a little worried than changing this at this stage, after 12 years, might mess up some folks' settings. Regards Pete

Sorry, there is absolutely nothing in FSUIPC which sets any weather unless you have an application which is telling it to. AND there is no way at all to set the TAT, that is a computed value. This is still pointing to a bug in P3D. Maybe, because of the difference in code sizes and other memory usage actions in FSUIPC, the memory arrangement of other things in P3D is a little different, and that different causes corruption or use of different uninitialised values. This sort of thing has hasppened before, many times. If you don't believe me, so be it. Please yourself. If you want me to look into what might be different you'll have to send me weather files (WX) which exhibit the symptom and tell me how to generate the problem. But I won't be able to spend much time on it and all I will be able to do is prove it isn't anything to do with FSUIPC. Pete

FSUIPC does not set temperature, and actually there is no way of separately setting SAT and TAT in any case! TAT is computed by the sim engine inside P3D's code. You must report the problem to Lockheed Martin, though I think they already know about it, especially with Active Sky. Try your tests without Active Sky. Pete

Ah, sorry, I did miss the point about 'Task Manager'. And this is in the "Applications" tab, which here always seems to show whatever is in the title bar of each visible application. For instance, now, because FireFox replaces its title bar text with the title of the thing you are looking at, which for me at present is this thread -- that's what Task manager shows. Not "firefox" but "Odd but harmless side effect - FSUIPC Support Pete Dowson Modules - The Simflight ..." etc etc So, i don't think it's a special quirk of FSX but a general implementation in Task Manager. The Processes tab however of course still shows the process name, FSX.EXE or FireFox.exe, etc. Regards Pete

Sorry, I can't quite get my head around that. You set it up and it works, but you can't set it up? Pete

No. it can't do that. Those will be assignments made in P3D, not in FSUIPC. Everything you do in FSUIPC is stored in the FSUIPC4.INI file, in the Modules folder. Regards Pete

Looking at your example code, I realise my first reply might not have been so helpful. You seem to be intent on using gsub. And also confusing the charact "0" with the zero value, "\0". (The ASCII character 0 is actualy hex 30, or decimal 48 -- certainly not zero). Try using find, as in: newlength = string.find(path, "\0", 1, true) then you can take the substring of length newlength-1 (really you should check that newlength is not zero first, of course -- but if it is then the entire 256 bytes are 'path' and you are stuck). Does that help? Regards Pete

By "padding" I assume you mean the characters beyond the zero string terminator? No. Those are written in C of course, and strings in C have a zero terminator. So whatever is beyond the zero is not part of the string as far as they are concerned. No, but I think 256 is either the limit, or close to the limit, for full pathnames in the Windows file syatem functions. So if you are planning to use the result for file system access you'd need to keep it down. However, if this is about genuine files and paths then the result is bound to fit, for the same reason. In Lua "strings" are really only byte arrays, so can be as long as you likeand there are no special characters -- 0 is just a null, not a terminator. So, in order to concatenate these zero-terminated strings you need to find the position of the zero and use the length to that to extract the substring for concatenation. You only need to do this for the first string of course. Regards Pete

It is not a quirk at all. When you set the title bar text, you set it all. You can read it, append your own part, and set the result, and this is what FSUIPC does for WideServer status. But when monitoring values using the FSUIPC Monitor, I need space for up to 4 values, because that's how many you can monitor. Therefore wasting space on telling you it is Microsoft Flight Simulator X as well would be silly, don't you think? What is your problem with this? Pete

Use the REV option(REV stands for "Reverse", as documented.). That's what it is for! You can reverse it in FSUIPC calibration or in FS itself if it is assigned there. Do not reverse it in both places. Pete