Pete Dowson

Okay. Thanks Jim. (I still don't know what the facility is supposed to do, BTW). Regards Pete

Yes, but that is also perfectly possible using default assignments in FS itself. The generic controls for throttle, prop pitch and mixture, operate on all engines. They always have. And those generic controls are the ones used in FSUIPC calibrations EXCEPT on the tabs which handle up to 4 separate assignments for the 4 separate engines. Furthermore, the generic controls do not have the complication of any reverse zones. The places where you calibrate up to 4 axes are really aimed at those folks who do actually have more than one control of each type. The only reason for using those otherwise is to provide the reverse zone which you don't otherwise get -- but it is still better, then, to assign to the generic controls and map to the 4 controls using the mapping facility shown there. This is, in fact, the way documented for getting reverse zones on single controls. That's normally a null CENTRAL zone, between reverse and forward. As the calibration steps clearly encourage, you should have "null" zones at minimum and maximum positions too -- and that applies to axes without "centres" too, like normal throttle assignments with no reverse zone. The reason for a "null zone" at each extreme are so that you can always reach the extremes (zero thrust is obviously most important for that) despite any minor variations in the read-outs, and so that you've always got a reliable place you can park levers with no "jitter" to interfere with autopilots and such. You are saying that with the minimum possible input of -16383, calibrated on your prop pitch, that the lever showing on the FS screen does not come fully back? If this were the case no one could use a prop pitch lever for FS at all, because they wouldn't work in FS with or without FSUIPC. So, it is hard to believe. Please tell me what the "OUT" value shows for the prop pitch when your lever is pulled right back. If calibrated properly it should be -16383. or possibly -16384. Also, is this with all variable pitch aircraft or one particular ones? You could also post your JoystickCalibration section from the FSUIPC INI file for me to look at. Don't paste the whole INI. Regards Pete

The fact that no INI or LOG file is produced indicates that FSUIPC4 isn't even getting loaded, so it certainly is the same SimConnect trust verification problem. I hope so too -- it has for others. The bug in SimConnect is a timing thing. If you have other add-ons being loaded by SimConnect, it might help to temporarily stop those loading so that SimConnect is only loading FSUIPC4. To do this you quickly you can go to the FSX CFG folder (the FSUIPC4 Install log will tell you where that is if you aren't sure), and temporarily rename the files DLL.XML and EXE.XML (the latter may not exist). Then re-run the FSUIPC4 install. It will make a DLL.XML with only it being loaded. If that gets FSUIPC4 loaded by FSX you can then close FSX and go back and restore the original XML files. You could also try downloading FSUIPC4 version 4.705 (or later, depending when you look) from the Download Links subforum and putting it into the FSX Modules folder manually. Sometimes a slightly different signature helps with the odd difference in timing. Regards Pete

I wrote a little note in the FSUIPC4 offsets status document against that, saying that Simconnect seemed to allow it to be written, but I didn't know if it changed anything. you seem to have confirmed that it doesn't. Shame. Things like this would have been added to the list of updates for SimConnect which Microsoft originally promised us .....:-( Regards Pete

What is "local suppression range"? What does it purport to do? Sorry, you need to explain. FSUIPC has no control over when weather changes in FS9. It just passes whatever Active Sky requests over. Did he explain what this facility is supposed to do? Can he reproduce your problem? Perhaps if he knows about these things and thinks there's a new problem he could talk to me about it? I'm really completely missing what this is about entirely. Sorry. Regards Pete

As posted in the other thread: There's a Windows API called "SetDLLDirectory", which adds a path to the list for DLL searching. I'll get FSUIPC to add "Modules\Lua" and "Modules\DLL" for the entire session. That should deal with it! But i'll leave this till i return from holiday, by which time hopefully the modules facility will have been well and truly tested! I might also then incorporate the LuaFileSystem (lfs) library into FSUIPC and Wideclient. It looks useful and won't add noticeably to FSUIPC's size. I'm on holiday from Wednesday evening till the first Wednesday in June. BTW, Apparently ou can also get the Modules\Lua folder searched by specifying it in the PATH environment variable. Environment settings used to be common place in DOS and early Windows days. I'm not sure how to set them in modern Windows. Regards Pete

Another user, see the thread next to this, has tested it already using the LuaFileSystem module. One thing he found, and i've verified, is that when Windows fills in the dependencies for the loaded DLL module, it looks in the PROCESS's folder, not the folder from which it is loading the DLL module itself. So if you need lua5.1.dll, for example, it needs to go into FS's root folder (or in the usual Windows folders which are searched after). After I did this "base64" didn't fail either. Mind you it didn't do anything but that's presumably because I made no calls upon it. It is a bit annoying having to put DLLs into the FS root folder but I doubt there's any way around that -- though I'm looking. [LATER] Found it! There's a Windows API called "SetDLLDirectory", which adds a path to the list for DLL searching. I'll get FSUIPC to add "Modules\Lua" and "Modules\DLL" for the entire session. That should deal with it! But i'll leave this till i return from holiday, by which time hopefully the modules facility will have been well and truly tested! I might also then incorporate the LuaFileSystem (lfs) library into FSUIPC and Wideclient. It looks useful and won't add noticeably to FSUIPC's size. Regards Pete

Great! Thanks! That's a first real test! ;-) That's odd. It should be okay next to the DLL which needs it, i.e. in the FSX/modules/lua folder. It'll be okay in FSX root, but I'll have to look to see why the LoadLibraryEx routine isn't searching the same folder as the module itself. Maybe it only looks in the current process folder (FSX.EXE) and, of course, the Windows and Windows\System folders. If so I don't think I can do much about it. It isn't really my code which controls it, and any solution I could work out (which would be quite convoluted) wouldn't apply to any lower needs in the chain -- i.e. should the module loaded want then to load another Lua library module. Regards Pete

There now. I don't know. I'll take a look. Pete

Okay, I think I've solved it. The "LoadLibraryEx" Windows API call was explicitly telling Windows to NOT load any DLLs the module needs and so not fill in any references. I don't know why. I presume this was intended to avoid the need for a "DllMain" function in the module -- but it doesn't seem to fail even if there isn't one. So I changed the LoadLibraryEx call to explicitly load dependent DLLs and fill in the references. That solved the bulk of the crash causes. The others were all due to struct member alignments being different. It works here now with "pragma pack( 8 )" settings for all Lua structs. This may only be because it is the current MSVC default alignment, so it is still an unknown for any old modules you may pick up. But FSUIPC no longer crashes FS when running either your "base64.dll" or "TestLua.dll". The base64 one complains of not being able to load a module, but it doesn't crash FS. So, I'm now going to upload, to the Download Links subforum: Version 4.705 of FSUIPC4 Version 3.995 of FSUIPC3.DLL Version 6.89 of WideClient.EXE with these changes. Hopefully they'll allow any properly written and compiled (!) DLL to be loaded as a module. Perhaps you could try a few and let me know? Regards Pete

I don't know that library, but if it is made as a C module (DLL) loaded by Lua then the answer might be available later today. Please see the thread near here entitled "Lua capabilities". I have, I think, located and fixed the problems in handling Lua C modules, though it needs some more testing. Read it to the end where I am about to post details of the solution. Regards, Pete

What is "local suppression range"? I assume it is something to do with the weather? There are no changes affecting any weather facilities in FSUIPC3 for a long long time. That's good, because you would get no support if you did. If there is a problem in 3.99 it will need to be resolved, but I cannot help without information. Have you asked ASE support? Maybe they can work out what is wrong and, if it does need something in FSUIPC, that can then be determined properly. Regards Pete

No, you purchases FSUIPC4. That covers all versions of FSUIPC4. Version 4.704 is currently the latest. Assigning a button to the "mouse look toggle" control works fine here, exactly as pressing Shift+O. Why are you even thinking of using keystrokes in FSUIPC when there's a perfectly good FS control to assign? In FSX Shift+O is assigned to one of the "Mouse view direction (on)" entries in the list, and that just sends the FS control "Mouse look toggle" which you can certainly assign in FSUIPC too. So I don't really understand what you mean when you say you've tried FS's pull down menu too -- you said Shift+O works, and that is where that keystroke is assigned. Regards Pete

Okay. I did a bit more this evening. I think there is/was a struct alignment issue, and if folks compile their own Lua modules with different settings they are quite likely to be incompatible. I've not yet worked out whether it should be 4 or 8 byte alignment. Older versions of the compiler worked on the 32-bit principle of alignment, but recent versions default to 8 (64-bit0. It makes a difference to several structs, including the state. I'm testing with 4-byte (32-bit) at present. However, the crash I'm now getting in TestLua.dll is inside luaI_openlib, called by the register call, and it happens where it calls a C library DLL API, "strchr", in the luaL_findtable function. And I'm not surprised ... ... the debug LIB you supplied, which I'm binding into your TestLua and compiling, imports a load of stuff from MSVCR100D.DLL and from KERNEL32.DLL. But the links to these are not made. Somehow Lua is managing to load the module in such a way that none of its external dependencies are being filled in! The result, obviously, a crash as it jumps into nowhere in particular! I've no idea, yet, how this is supposed to work. It seems completely daft. Note that nothing else is loading MSVCR100D.DLL either. FSX obviously predates this (it's on 80), and FSUIPC uses static versions to avoid versioning problems on different platforms. Regards Pete

Thanks. I've put the larger of the two Lua5.1.lib files into your project and compiled it with it, in Debug mode, but whilst I get the source debugging in your "TestLua.c" code, the actual crash is with a corrupted stack top pointer in the State structure, occurring someplace pretty deep inside the Lua Lib in your program as a result of the "luaL_register" call (yes, with the correct state pointer, L) -- but it isn't showing me source for some reason, so stepping through it tells me nothing. I guess the LIB has to be compiled here or else it doesn't know where the source is? It doesn't complain though. Weird. I obviously don't know enough about MS's "studio" product. I'm actually getting no where at present. I think I'll give it a rest till tomorrow at least. Aren't you able to narrow it down there? You must surely be able to attach the MSVC debugger to the running FS9 process. I've always been able to! Regards Pete

Received two ZIPs, thank you, but in the lua one the vital folders, "Bin" and "Lib\static" seem to be ... empty? There's no ready-built debug LIB for me to build with. I can build one here, but then it'll be built with my settings. Additionally, the full TestLua project doesn't actually include a compiled TestLua.DLL at all,. The TestLua\Debug folder is empty, and the TestLua\TestLua\Debug folder contain all the right stuff except the DLL. Really weird. It's as if something is removing anything which looks slightly like a program! Regards Pete

155 isn't possible, actually. It uses only values 72, 144, 216 and 252 for light, moderate, heavy, severe.. Why aren't you using logging? It is provided in FSUIPC specifically to help folks debug their programs and work out what is going on. Also if you show me the log it would make it much easier and faster for me to help you! You should also use WeatherSet2 to read the weather at the aircraft (it uses the NWI so shows all layers). The turbulence values there run 0-4 I think. I've tried setting assorted cloud turbulences in FS, but it is hard to get higher values to stick -- I think you need to get other parts of the weather set appropriately too. I think you may be seeing the result of FS's "semi-intelligent" dynamic weather system. For instance, I can't easily set a "light" value which sticks -- but it always goes directly to moderate, #2 (=144 in offset 0E88). If I set "heavy" or "severe" it sets initially, and 0E88 reports 216 or 252, but within a couple of seconds it is cleared down to 0. This is FSX -- it isn't maintaining the setting, the turbulence is stopping probably because it isn't consistent with other weather system settings. If you ask FSUIPC to monitor offset 0E88 to the log, or view the weather in WeatherSet2, you can see this. Your best bet for testing is selecting the "major thunderstorm" theme. With that you get a lower cloud layer with "severe" (#4), showing 252 in 0E88, and a higher cloud later with "moderate" (#3) showing 216 in 0E88. Pete

It's a pain. The problem I have now is that I need a debug version of the lua5.1.lib so I can trace through its copy of the same code I'm using to see where it is corrupting my data, because corrupting it it certainly is. But if I compile my own copy of the lib in debug mode it will compile with all the structs aligned with my settings, so it may then work -- but that defeats the object. So, have you got, or can you compile, a lua5.1.lib for debugging, check there that it works in a default Lua environment when bound into your test program, and then send it to me? There's another slight worry which has occurred to me. Here I have two source versions of Lua, 5.1.3 and 5.1.4. I'm pretty sure the stuff in FSUIPC is based on 5.1.4. But how will different Lua versions affect this? Can we assume they never change the structs in a way which would affect compatibility? The compile does that if the packing isn't 1. I only added padding because i must use 1. And it isn't good if it makes my Lua structs mismatch those used by external modules. Endianness really is about whether numerical values have first byte lo (lo-hi) or last (hi-lo). Intel is always lo-hi. Not sure what the worry about struct padding involves endianness. The padding is placed to ensure the next member is aligned on a boundary appropriate to its type. No, the project you sent me contained 4 files in the "TestLua" folder and a Debug subfolder containing a load of files, mostly "tlog"s whatever they are. Regards Pete

In FSUIPC4 you can get wind and cloud turbulence relevant to the aircraft altitude in the offsets I referred you to in a previous reply, i.e. Do NOT ever use FSInterrogate to find or read details of offsets. I simply cannot keep the data in that up to date. It is simply a tool for YOU to use to experiment with reading and writing offsets, and ANYONE can edit its data. The offsets I referred you to are most certainly documented in the current FSUIPC Offsets Status document, the one for FSUIPC 4.70. Maybe you are looking at an out of date copy? Regards Pete

All of the FSUIPC settings are saved in the FSUIPC4.INI file and reloaded next time you run FS. You do not have to explicitly save anything at all. It is done for you. Nothing is ever lost unless you foolishly delete the settings file. No, they are entirely independent of each other. Neither cares at all about the other. They work in different spheres in any case. Regards Pete

Same here. Now here's a definite problem. The Lua state structure is decidedly wonky, in the sense that one byte values jostle with 4 and 8 bytes values with no consideration for alignment. I always compile with 1 byte alignment (ie. no padding), and simply ensure that I put spare bytes in where I want efficient word or dword or double alignment. I must use 1 byte because FS is compiled that way -- in fact most of it's internal doubles and so on are on odd boundaries. Obviously they cared more for size than efficiency. The default MSVC alignment is different I think in different versions. The default in VC2010 seems to be 8 byte , as best as I can find out -- it doesn't make it obvious anywhere. I did actually put some spare bytes into the Lua state to get it aligned properly. But I've tried patching them out and I still get the same error with "base64.dll". But it's going to depend entirely on what options are chosen when compiling the DLL, since there are no "pragmas" to force a fixed defined alignment! So, how is it supposed to work? Something doesn't make sense! I don't have one for Lua. Attach AFTER FS is launched, as I advised. FS doesn't re-check whilst it is running. [LATER] I've tried using "pragma pack(n)" and "pragma pack(1)" bracketing all of the Lua structs in the lstate.h header, with n=8, 4, and 2, but I get exactly the same error with all. Shame. I felt sure it had to be an alignment mismatch -- I suppose it still might be if there are some more weird structs in the other headers. I'll have a quick look, but at present it seems like a pretty tough brick wall I'm banging my head against. It certainly calls the "base64.dll" exported function at the correct place and with the correct pointer to the State structure, but when it gets back into FSUIPC something is really screwed up good and proper. I was going to compare the state struct before and after -- with added code, not manually -- but first I'll move onto that test project you supplied. But I'm going to need to compile a debug version of the lib file if I'm going to find the discrepancy. Regards Pete

Okay. I'm re-reading Chapter 15 in the Lua Programming book (the one I skimmed through a few years ago), and I am starting to appreciate some of the processes needed to get this to work. From what I've read so far, it should work okay, so I'm going to persevere a bit more. Looks like i need to track it through step by step: "require" checks "package.loaded", then "findloader", and the loader. The base64.dll is actually getting loaded, so either it is failing somehow after that, when being called, or whatever it is returning (if anything) is being assumed to be something it is not. I can see that if I get the main mechanics working I shouldn't really need to have FSUIPC export anything. The user would have to use the static or dynamic Lua libraries as they wish. (Seems your base64.dll uses both, because the imports from the lua DLL do not include the vital functions needed to build the table of its module functions and exported variables -- although I suppose they can be built in ordinary C if you know the structure. Any comments so far? I'm on holiday after Wednesday, not back till early June, so I doubt i'll solve this is any short period. Regards Pete

I expect it will be similar to the other PMDG aircraft in this regard. There are no specific facilities in FSUIPC for any specific aircraft -- why should this one be an exception? The PMDG SDK would no doubt be suitable for someone to produce a comprehensive FSUIPC interface, using offsets I can assign, much as Nico Kaan wrote the FSUIPC interface for Level D using their SDK. Whether I might or might not be such a someone to do this I can't say. If I took it upon myself to use this aircraft for my cockpit, I might get interested in doing that, but since I'm using Project Magenta for all my instrumentation and systems it doesn't seem very likely. Even if I did, the problem for me is that it would set a precedent. Folks would be saying "why not the iFly 737NGX" too, and the host of other aircraft. I'd prefer third parties provided applications. My interest in the PMDG and iFly 737 efforts would be in the flight modelling and, to a lesser extent, the exteriors. I'd see in these areas whether it beats what I'm using now (which is derived from the PMDG FS9 version of the NG). Nothing of any of the cockpit stuff is used when you have a real hardware cockpit. Regards Pete

"Map modules". Sorry, what is that? "Shuts down" where and how? No displays? No messages? After how many seconds? What happened last? I need a clue really. It might just be the well known SimConnect "trust" bug. Is your FSX fully updated, to SP2 / Acceleration level? If not, that's the first thing to do, get FSX up to date. The SimConnect loader was much buggier in the earlier FSX versions. All those who've experienced this SimConnect bug, and it isn't many, have eventually overcome it by persistence -- i.e. trying again and again to load FSX. It's a timing problem in FSX's part of the SimConnect module loading and checking routine, and being a timing bug it is critical on the timing of events in your PC. It was very likely to occur in the original FSX release, and Microsoft worked on it but were never able to fully fix it (part of the problem is in Windows itself, not under the FS team's control), but by SP2 (and Acceleration) it was reduced to "very unlikely". Once it loads properly it will be okay. It's only the initial trust-checking which fails. When FSX has the correct Trust entry in its CFG file it works every time thereafter. Persistence pays. Also, you must always please state version numbers. If not at least 4.70 please update first. I can't support old versions. Regards Pete

Odd then that when I look at its imports in PE Explorer the "Base64.dll" module you supply tells me it needs Lua5.1.dll to import several functions: lua_pushlstring luaL_buffinit luaL_openlib lua_settable luaL_pushresult luaL_addlstring luaL_checklstring Admittedly these aren't the ones I was worried about. But I'm not sure what happens when the lua5.1.dll isn't available to it. Hmmm. The state structure is of course owned by FSUIPC. I added some stuff to the end but the part used as standard should be manipulatable. Yes, but not using stepping all the way. It takes ages and ages that way, the Lua stuff is so convoluted! The base64.dll you supplied (test#1) is crashing with an access violation with some daft address (0x000023E0), but the point in the code identified varies slightly. Sometimes it is inside lua_call (part of lapi.c), at the luaD_call. The lua_call came from the ll_require function. At other times it is identified actually inside the luaD_call, at the luaD_precall line. I'm checking the registers and nearby values but I can't find where this "0x000023E0" is referenced, used, or appears -- seems to be nowhere. There's a loop someplace. If I trap at the luaD_precall function I find it is executed about 14 times, from the same routines, before crashing on the 15th iteration. I've no idea what it is doing, it's either a stack corruption, or it could simply be a result of the dependence on the lua5.1.dll not being fulfilled. I don't know how Lua succeeded even in loading the DLL with such a dependency unsatisfied, but it is loaded. Sorry, you've lost me. Are you saying I should discard the precompiled base64.dll yuu supplied and do something with the project instead? At present that won't compile, because although you said it was complete in itself, it contains: #include "lua.h" #include "lualib.h" #include "lauxlib.h" and I'll need to download those originals and put them into your project for you. My versions are specific to the FSUIPC implementation (though obviously almost identical). Uh, No way. I want everything integrated. Such an implementation would best be done by a third party using the standard FSUIPC interface, just like any other application. Well, not really. I've only skimmed the surface. I don't understand much of the internals, and not even the externals about this module / package part -- you obviously know a lot more about that part than I. I've concentrated on providing tools for Lua programmers to do things in FSUIPC, not really realising that the world of external C modules would be such a problem. I'm not sure how to proceed at present. I'm not getting anywhere with base64.dll debugging so far. I'd need to understand more about what is going on, and it is horrible convoluted. It would be a lot easier to do it my way, a different way, providing an FSUIPC Lua library which allows Lua programs to register a DLL and make the calls to it under FSUIPC control, as it does for all the other libraries I've added. It would mean that C modules for use with FSUIPC would be specifically built ones, not ready made ones. Regards Pete