[Nuke]

so the other day i stumbled onto a lua module for serial communication. ive used them before, my lua tga parser used a different module to work with binary files (this ran in the lua command line shell, not in freespace). apparently you stick a dll (or other platform specific application extension) into the working directory, then in lua you type something like

Code: [Select]

libname = require(dllname) and by some magic libname becomes a table of all the functions, variables, etc that the module has to offer. this works on almost every other lua interpreter i use. except in freespace.

someone on #scp said that this feature of lua has been disabled. i was wondering what it would take to enable it.

[Nuke]

 

because of the number of replies to my initial post (read: 0), i think i must point out the possible benefits to being able to load modules. the library i want to load would support serial communication. this would allow communication with external hardware (such as arduino, or any other mcu dev board), allowing anyone to build an interactive cockpit or (with the right motor drivers and encoders) full motion simulation. could also lead to a slew of alternative input, such as imu-based head tracking. i should point out that this is not the only library available.

i mentioned the pack library, which provides numerous functions for working with binary file data. i used this library to parse tga files, for example. one use for this library is to read certain parts of a pof file, for example (such as an in-engine pof editor). probibly not the sanest of ideas but its merely an example.

there is a whole list of libraries here, which can be used by throwing the binary into the fs2path and using require. there is certainly the possibility to get into the trouble by trying to use certain modules. there are also modules that only work on specific platforms, but it seems there are many useful modules that support all windows and *nix platforms. this would certainly be an advanced feature that is not recommended for the amateur scripter. but the package library (as its called in the manual) is part of lua and should be supported by the engine.

you could even write your own library and turn it into a precompiled module. this allows scripters to add code-level functionality without modifying the engine.

generally i think this would be a very useful thing to have.

[The E]

Sure, but this needs someone familiar with the lua implementation. Also, it would be good to know what kind of error FSO throws when trying to load a library.

[Nuke]

essentially the engine chokes on the first line in the script

Code: [Select]

rs232 = require("luars232")

and gives me this error

Code: [Select]

LUA ERROR: [string "serial-sct.tbm - On Frame"]:1: unexpected symbol near '='

------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0

Source: (null)
Short source:
Current line: 0
- Function line: 0
------------------------------------------------------------------


------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------

------------------------------------------------------------------

i tested the library in lua binaries (the ones from here) and this line loaded the library just fine, and i was able to talk to my arduino by sending bytes (the value determined the brightness of an led) to the mcu.

if i continue skip the error and continue i get this

Code: [Select]

---------------------------
Error!
---------------------------
LUA ERROR: [string "serial-sct.tbm - On Game Init"]:1: module 'luars232' not found:
no field package.preload['luars232']
no file '.\luars232.lua'
no file 'D:\FreeSpace2\lua\luars232.lua'
no file 'D:\FreeSpace2\lua\luars232\init.lua'
no file 'D:\FreeSpace2\luars232.lua'
no file 'D:\FreeSpace2\luars232\init.lua'
no file '.\luars232.dll'
no file 'D:\FreeSpace2\luars232.dll'
no file 'D:\FreeSpace2\loadall.dll'



------------------------------------------------------------------
ADE Debug:

------------------------------------------------------------------
Name: require

Name of: global

Function type: C

Defined on: -1

Upvalues: 0



Source: =[C]

Short source: [C]

Current line: -1

- Function line: 1

------------------------------------------------------------------




------------------------------------------------------------------
LUA Stack:

require

------------------------------------------------------------------


------------------------------------------------------------------


[ This info is in the clipboard so you can paste it somewhere now ]





Use Yes to break into Debugger, No to continue.

and Cancel to Quit
---------------------------
Yes   No   Cancel   
---------------------------

it could be that perhaps the engine expects the library to be in a certain place. but what i get from everyone i talk to on the scp board is that this was intentionally disabled when the scripting system was implemented (probably because it could be exploited with the correct library to gain access to the system). it could just be that my usage is all wrong too.

*edit*
on second thought it may have just been a bug on my script. apparently you need some dll files from the reference interpreter. i managed to get the library to load and printed out the variables and function names. havent managed to make it work yet. might try some other module though, serial is hard to get working when it works.

[Kopachris]

Try:

Code: [Select]

require "luars232"


[chief1983]

In the documentation, they seem to even omit the space, ie require"luars232".

[Nuke]

ive seen both variations in documentation. in fact both methods appear to work (see my edit on my previous post). i just haven't managed to get the library to work. i managed to load the rs232 library and print out the contents of the library with this:

Code: [Select]

rs232 = require"luars232"
--print out the vars and functions of the library so i can see what all it can do
ba.print("\n\nLua rs232 module:\n\n") --make it easy to find in debug spew
for k,v in pairs(rs232) do
if type(v) == "function" then
ba.print("Function: "..k.."()\n")
else
ba.print("Variable("..type(v).."): "..k.." Value: "..v.."\n")
end
end

which will cause this to be printed out in the debug spew:

Code: [Select]

Lua rs232 module:

Variable(number): RS232_ERR_FLUSH Value: 4
Variable(number): RS232_BAUD_19200 Value: 3
Variable(number): RS232_ERR_IOCTL Value: 10
Variable(number): RS232_ERR_PORT_CLOSED Value: 11
Variable(string): _VERSION Value: 1.0.0
Variable(number): RS232_ERR_CONFIG Value: 5
Variable(number): RS232_PARITY_NONE Value: 0
Variable(number): RS232_ERR_OPEN Value: 2
Variable(number): RS232_BAUD_38400 Value: 4
Function: error_tostring()
Variable(number): RS232_ERR_UNKNOWN Value: 1
Variable(number): RS232_FLOW_OFF Value: 0
Variable(number): RS232_FLOW_XON_XOFF Value: 2
Variable(number): RS232_PARITY_ODD Value: 1
Variable(number): RS232_STOP_1 Value: 0
Variable(string): _TIMESTAMP Value: Jan  6 2010 10:25:59
Variable(number): RS232_ERR_NOERROR Value: 0
Variable(number): RS232_FLOW_HW Value: 1
Variable(number): RS232_ERR_WRITE Value: 7
Variable(number): RS232_DATA_8 Value: 3
Variable(number): RS232_STOP_2 Value: 1
Variable(number): RS232_BAUD_9600 Value: 2
Variable(number): RS232_BAUD_4800 Value: 1
Variable(number): RS232_ERR_READ Value: 6
Variable(number): RS232_ERR_TIMEOUT Value: 9
Variable(string): _BUILD Value: $Id: luars232.c 13 2010-01-06 09:15:31Z sp $
Variable(string): _COPYRIGHT Value: Copyright (c) 2009 Petr Stetiar <[email protected]>, Gaben Ltd.
Function: open()
Variable(number): RS232_PARITY_EVEN Value: 2
Variable(number): RS232_BAUD_115200 Value: 6
Variable(number): RS232_DATA_5 Value: 0
Variable(number): RS232_ERR_CLOSE Value: 3
Variable(number): RS232_BAUD_2400 Value: 0
Variable(number): RS232_DATA_6 Value: 1
Variable(number): RS232_ERR_SELECT Value: 8
Variable(number): RS232_DATA_7 Value: 2
Variable(number): RS232_BAUD_57600 Value: 5

so its loading the function names and variable from somewhere. so i assume its loading the library. i cant say however that its working. im gonna try the pack library, since i can just use my tga parser script to test it. it doesnt use any low level calls, it just formats chars to specific data types and stores them in the appropriate lua type and vise versa. maybe get it to spew out an asciicat in the debug spew (or maybe i could just use gr.drawPixel())

[Kopachris]

Perhaps assigning the loaded library to a variable is the wrong thing to do.  If it is okay to do, then it probably works similarly to Python's "import ... as ...", where you have to reference it by the name you assign it to:

Code: [Select]

import struct as s

s.unpack('2fi', f.read(12))


[Nuke]

i just did what was in the library example. in lua all objects or classes are essentially tables with metatables and member functions (lua is a table oriented language). this is how modules expose their functionality to the lua interpreter, by simply providing a table containing all the functions, variables, objects, and library specific types (userdata) etc that the library has to offer. at this point im pretty sure the library has been loaded. those variables and functions had to come from somewhere, and they dont seem to crash anything when their used. but i can think of many other reasons why serial would not be working. at this point i think its a good idea to test other modules and see if any of them can be made to work.

[Kopachris]

Well, if some of the functions work when you load the module like that, then the module is most likely loaded, and I can't think of anything else.  Good luck!

[Wanderer]

Just thought to remind that there actually was a good reason - security - why lua file access (amongst other things) were limited in its FreeSpace Open implementation.

[Nuke]

im not saying that you couldn't do something really stupid by loading a module. there are some modules that can get into your system and cause all kinds of mayhem. these are mostly to be used for system management scripts for administrative purposes, but they could easily be used for exploits. needless to say, if some shady individual tells you to put a dll file into your fs2 dir, and gives you a script to run, you better think twice. on the other hand there are modules that may serve useful purposes.

[chief1983]

But imagine a user comes into the community out of the woodwork with a new mod to try out.  It has enough data to be considered a full mod, but maybe there's a script and a module tacked in that no one thinks to look at because it's buried inside a VP file, or several folders deep.  Lots of people would probably try it out, and if there was anything malicious going on, you wouldn't catch it for a while I'd bet.  So locking down the abilities of the Lua interpreter a bit is probably necessary.

[The E]

How about this then: Let us only load modules that are in FS2's root dir. I know there's a risk here, but at some point, we have to trust modders to not be assholes. (If we're really paranoid, we could pop up a warning like "Script x is trying to access module y, do you wish to continue? Yes/No/Don't ask again for this module")

[Reprobator]

Or having some kind of approved module list that the interpreter would accept to execute?
THe problem with that would be the updating thing...

[chief1983]

Actually, you don't ever have to trust modders.  You shouldn't trust anything you didn't create.  And anything you do create should still be scrutinized

I'm not saying module loading shouldn't be done, but that there are inherent risks we shouldn't just try to bypass.

[Nuke]

How about this then: Let us only load modules that are in FS2's root dir. I know there's a risk here, but at some point, we have to trust modders to not be assholes. (If we're really paranoid, we could pop up a warning like "Script x is trying to access module y, do you wish to continue? Yes/No/Don't ask again for this module")

thats the way it works anyway. though i think there are ways to change the module path (see here). you could also probably get away with sticking the module in the system dir. this is obviously not recommended, but it could be a source of an exploit. also must point out that in addition to the module dll you also need lua5.1.dll in your fs dir. so if you freespace dir starts looking like your system32 dir, id start to worry.

[WMCoolmon]

If this was intentionally disabled it was due to security concerns. I did make an effort to limit the Lua library to avoid having unrestrained access to the rest of the computer.

I would suggest a graphical prompt that says something like, "The mod you are trying to load is attempting to load a Lua library  'library_name_here' with checksum '24301401940' that isn't on the approved libraries list. Lua Libraries can contain malicious code and are able to access anything on or connected to your computer, as well as the internet. If you know this library is from a source that you trust, click 'OK'. If not, click 'Cancel'."

If the user clicks 'OK', it stores the DLL/checksum using the FS2Open registry API and doesn't prompt again the next time they try to start FS2Open.

You'd probably also need some kind of command-line utility to disable the prompt for testing a library YOU are compiling.

My preference would be to see these 'dangerous' abilities (like accessing the serial ports.....) that a mod wants to use stated up-front to the user in a list like Android uses. And have them be a part of the scripting API. But I doubt that's a fast/easy enough solution here.

Not volunteering to code either...

But yes, if there was a definite decision it was to keep the scripting system from being able to play outside its sandbox, it was for security rather than technical reasons.

[WMCoolmon]

You could probably also use the Lua interface to write to a symlink in the FS2Open directory that's pointed at a file on a memory-mapped mountpoint/drive, while an external program reads whatever the Lua script writes, parses it, and sends it to the serial port.

This could actually be faster than using a direct Lua->serial interface alone, depending on what you're doing.

[Nuke]

i think the reason the library didnt work was because of threading or timing issues. serial just wont work if the timing is bad. usually you get around the issue by running the send and receive code in another thread and only work with the buffers. but it gave every indication that the module had been loaded.

i considered using named pipes pipes, someone also suggested a tcp/ip interface. the latter would work in loopback mode to talk to software on the same machine, or could talk to devices on the network. this would also facilitate talking to external hardware (arduino users could just get an ethernet shield) and would provide some serious throughput. only real reason i was looking at serial is is its something i could do with hardware i have on hand, it would provide adequate throughput for many of the potential applications.