Chrilith

Great, sounds good! I'll give it a try later today! Thanks Pete!

Haven't tested again yet sorry. Didn't find time today :( I'll try tomorrow when I get back from work. Thanks! Chris

My bad. I removed them to make the archives smaller. I'll send you both files.

Just sent you the lib code. I do think so, at least from 5.1.3 to 5.1.4 I was talking about artificial padding adding dummy members to the struct. Not compiler or preprocessor options. Oops, sorry. Sent again.

I'll send you the VC2010 project I used to build the Lua lib later today if you can't find it on sourceforge. I'mcurrently not at home.

I wasn't aware of this aligmnent stuff on windows. I was facing similar problems working on PalmOS. I think i do too much C# coding now. Adding padding is indeed a good idea but we also have to deal with endianess. I always have a problem to know if I need to put this extra byte before or after the struct member :), don't know why... I meant there is a Libs folder containing all required files in the VC project I sent you. Well, I'll try again Chris

Sorry if I was unclear about that. "base64.dll" is extracted for the Official Lua distribution. Indeed, this module use the dynamic library. I have put the Lua DLL in the same folder as the base64.dll module and it doesn't work either. Indeed, it should be ok since thre is no aligment consideration with Windows dev AFAIK. Looking at this low address, this sounds like a relocation problem. May be the globals are not properly relocated and so, the structure owning the function pointers isn't accessible. I'll do sometest to check this putting the structure in a function returned value instead of a global with the code from test#2. EDIT: Just tried to return the opcodes table from a function returned value and it doesn't work better. Yes, sorry again. test#1 use an official (let's call it like this) Lua module. This one is linked to the Lua DLL. The project use a static library. Weird since I use relative paths for lib/include location. Everything is in the project in the Libs folder. What I saw too. The DLL is loaded and Lua does have a pointer to it but the initialisation code failed to be called. I don't think it will be easy to debug this with base64.dll since you don't have the symbols. Using test#2 should do the trick. The function in this project is "luaopen_TestLua()". Again I'm sorry because I still unable to attach to the process because FS2004 refuse tolaunch when a debugger is running.... I do agree with that. No rush :) take your time. I'm sure I'm the only one, as least for now, to have this problem and I can deal with it for now. I can easily (I think) create my module with the Lua distro and wait for the package loading to be fixed in FSUIPC. I just hope it can be so that I don't work on that for nothing :). But anyway I'll do my best to help Thank you again Chris

The Lua lib I use is a static library and is not supposed link to any external DLL since the whole required code is, in this case, part of the module DLL itself. In my understanding, Lua is all about state and C Lua functions are just filling the lua_State structure to communicate. In the first test code, indeed, the "base64" module should try to access Lua functions to initialize itself upon Lua request with the require() call. Did you try to step into the internals of the "require" function in your Lua implementation to see where it fails and what exception is raised? Indeed, for the first test which use the "base64" module this should be a problem and the call to luaL_openlib/luaL_register will always failed. For the VC one, it should not (it uses a static library) and the call to loadlib(), in the lua script, does work and returns a valid pointer. It seems that something goes wrong later in the call to luaL_openlib/luaL_register (luaL_register internally calls luaL_openlib) which is handled by the call to testlib() in the Lua script. Unfortunately I wasn't able to find what kind of exception is raised here (access violation?). All external Lua module/extension have to call back to the Lua engine, at least once, in order to register itself and make its functions available to the Lua code. The modules you have embedded in FSUIPC are of course fully functional since there are all part of the same code and so, have access to all the needed functions. I think that "package" is the only part that may require this internal access. This includes all the functions required to initialize a module. But a module may want to call some other functions :(. About the exports I really don't know right now. Perhaps, instead of adding the Lua code in FSUIPC you can link to the Lua DLL and create external modules for "ipc" or "gfd" for instance. Hopefully this helps. I'm sorry but I believe I'm far behind you regarding Lua internals coding :). Anyway I want to help as much as possible. Let me know if you need more information. Thank you Chris

The purpose is not to complain but to find out what is wrong and fix the problem if possible :) I really think that Lua addition is a amazing new feature and really want to see it work perfectly. I'll prepare you a very quick new project so that you can debug it. Thanks!

OK, well, I did a simple test using an existing Lua module from the Lua package (base64.dll) I copied to the FS.../Modules/lua/ folder. I created a simple Lua script that I try to run from FSUIPC require("base64"); Same result! This simple script makes FS crash, so I suspect that there is a problem in the Lua implementation built-in FSUIPC since it is impossible to load an external module.

Hi Pete, Thank you very much for your answer. Unfortunately I wasn't able to make it work. I recompiled the Lua static library in Multi-Threaded Debug and Multi-threaded Debug DLL, same for my own DLL of course but no luck. I also tried the dynamic version. It always crashes when executing something from luaopen_MyLuaDLL(). If it is empty, it doesn't crash but do nothing, of course :). As soon as a code in the function is executed whether a luaL_* call or something else like the fopen() stuff, FS9 crashes. Also, I wasn't able to enter the debugger because I always have an error saying that a debugger has been detected as soon as FS is launched... Hard problem... :( All this is done using VC++ 2010.

Ok, I did configure a hot key to launch my custom Lua script and module. Here is the sample script: testlib = package.loadlib("C:\\Program Files (x86)\\Lua\\5.1\\chrilith\\Lua_SaitekLib.dll","luaopen_MyLuaDLL"); if(testlib)then testlib(); else -- Error end MyLuaDLL.HelloWorld(); Unfortunately, this code works fine using the classic Lua environement but crashes FS9. It seems to be the call to testlib() which makes it crash. The Lua_SaitekLib.dll, for testing purpose only use this simple code: #include <Windows.h> #include "lua.h" #include "lualib.h" #include "lauxlib.h" static int MyLuaDLL_HelloWorld(lua_State* L) { FILE *f; fopen_s(&f, "D:\\test.file", "w"); fwrite("test", 4, 1, f); fclose(f); return 0; } static const luaL_reg MyLuaDLLFunctions [] = { {"HelloWorld", MyLuaDLL_HelloWorld}, {NULL, NULL} }; int __declspec(dllexport) luaopen_MyLuaDLL(lua_State* L) { luaL_register(L, "MyLuaDLL", MyLuaDLLFunctions); return 1; } Pete, since you wrote some extensions to Lua to be used in FSUIPC, do you see any problem here which make my code crashes under FS but not under classic Lua env? Thanks!

OK good, now I have my registration key I'll do some test :) Thanks!

Great thank you very much!

Hello, I'd like to know how to make Lua plug-ins work. I'm building a Lua module to handle Saitek FIP but can make the provided FSUIPC+Lua examples to do or show anything on screen. Does Lua require the reigstered version to operate? (I don't see any [lua script].log file generated but lines are added to the fsuipc.ini file) Thanks! Chris

Hello, I bought FSUIPC last week but still not registration key. Perhaps I missed something about registration. I need full name, email and registration code. Where can I find this code? Thanks! Chris

OK great I'll check all this, thank you very much Pete and have a nice week-end!

Hi pete, Thank you for your reply. Indeed, fuel tanks are there starting at 0x0B74 and 0x1244 but what about TURB ENG PRIMARY NOZZLE PERCENT? According to fs2x web site, these variables seem to exist in the SIM1.DLL file, are they accessible with FSUIPC? Sorry if I ask stupid questions here but I'm quite new to FSUIPC and FS2004 programming.

Hi flyenid, Great you find your way but could you please share more specifically your experience with this device with the community? Perhaps this can be useful to others. :) I must admit that I curious about that as I'm about to return to the PZ46 to create some extra panels. Thanks

Hi everyone, Many months ago, I asked some question on the VRS forum about what variables I can read from FSUIPC to create an EFD for their amazing F-18 model using the Saitek FIP. Here was the question: And the answer from the team: Unfortunately, I wasn't able to find those variables in the documentation of FSUIPC and I finally gave up because of missing time... Now I want to go back to this project but I need your help to find the address of those variables if they exist. I just registered FSUIPC because this soft really rocks and deserve few bucks :) Thanks!