Loading C library from Lua script requires Lua-devkit

[Djeez]

Hi Pete,

We talked earlier about my tcas lua script.

Now I am getting feedback from people who downloaded it that it doesn't work. I have narrowed the problems down to the fact that they do not have the Lua development environment installed (and I do). If I rename the Lua directory of C:\program files(x86)\Lua to something else, the FSUIPC log file shows the message

*** LUA Error: error loading module 'saitek' from file 'C:\FSX\modules\lua\saitek.dll': The specified module could not be found.

Same happens with the gd.dll module if that is required first.

Of course I could tell my tcas users to download and install the Lua Windows development kit, but I am sure that was not your intention when you developed Lua scripting for FSUIPC.

Do you have any suggestion what to do?

Thanks!

-Djeez.

[Pete Dowson]

*** LUA Error: error loading module 'saitek' from file 'C:\FSX\modules\lua\saitek.dll': The specified module could not be found.

Same happens with the gd.dll module if that is required first.

...

Do you have any suggestion what to do?

Yes. You should have told your users that they need to make sure they are using a recent version of FSUIPC. The use of external DLLs by Lua plug-ins was not working at all until quite recently. Please see thread

in which the problems and solutions was discussed with the author of the Saitek dll you are using.

Current interim versions 4.714 and 3.997c will work okay. Please also see these two entries in the list of notes about changes:

*. The Lua facilities for loading and running external modules have been improved and should now allow C DLL modules as well as Lua modules to run okay, if they are designed to run on the standard Lua interpreter. These fixes do need more extensive testing, but it seems the main cause of problems, the alignment of members of structures, was the culprit: All FS structures are single-byte aligned (i.e. no alignment), so FSUIPC had to be so arranged to interface to it correctly, whereas the default C alignment to by member size, up to 64-bit or 8 bytes max. FSUIPC now arranges for the Lua structures to be so aligned so that they match the assumption in the external modules.

*. DLLs which are used by Lua plug-ins can be placed in a sub-folder in the Modules folder called DLL. Previously they had to be placed in the main FS folder, or in windows or Windows System folders.

Regards

Pete

[Djeez]

Yes. You should have told your users that they need to make sure they are using a recent version of FSUIPC. The use of external DLLs by Lua plug-ins was not working at all until quite recently.

Yes, I did that, that is not the problem.

I figured it out.

The modules saitek.dll and gd.dll that are required for my Lua script depend themselves on 7 other dll's that are distributed with LuaForWindows. These have to be placed where the native loader can find them, e.g. in the FSX folder because that is the current directory of the fsx.exe process.

Maybe the easiest way for users is just to install LuaForWindows...

DLLs which are used by Lua plug-ins can be placed in a sub-folder in the Modules folder called DLL.

Are you sure about the name? In my version (4.712) it should be the Lua folder.

[Pete Dowson]

The modules saitek.dll and gd.dll that are required for my Lua script depend themselves on 7 other dll's that are distributed with LuaForWindows. These have to be placed where the native loader can find them, e.g. in the FSX folder because that is the current directory of the fsx.exe process.

They should also be okay in the FS Modules\DLL folder, because i add that to Windows search list for DLLs. This is where your Saitek and GD DLLs should go too.

Are you sure about the name? In my version (4.712) it should be the Lua folder.

The Lua folder is for non-FSUIPC-loaded Lua files, i.e. those modules loaded by "Require" but not intended for FSUIPC loading. The folder I add to the Windows DLL search list is the modules\DLL folder.

Note that the "SetDllDirectory" facility I am using only allows one such addition, else I would have added both. Each time it is used it replaces the last named one.

Also note that the earliest version of Windows which supports this function is XP + SP1.

Regards

Pete