[taylor]

Originally posted by Nuke
also would there be a way to implement custom keyboard comands via scripting that would actually appear in the control config.

I would think that'd be a pretty bad idea given the possible platform and i18n issues.  If it were thought out pretty well then perhaps a similar idea could be implemented, but without it being restricted to particular configs.

[mikhael]

There's an easy way to take care of that, taylor, but its a touch bloaty (not Offce XP bloaty).Just slightly bloaty. the SDL documentation has a lead.

[WMCoolmon]

#1 on the to-do list is pretty much done.

Just need to set it up for special functions.

[Nuke]

just use something like the imulse system that quake had. you had several impulses that could be referanced in quake c and bound to controls in the quake config files. set up the config screen to read a table that lists custom controls and a bitflag which is stored as a global integer. then simply provide that integer to the scripting system.

[WMCoolmon]

OK, I've done something insanely evil.

I've abstracted Python and Lua to the point that either can be used. At the same time, if both are compiled in.

Separate libraries/functions/objects would be needed for both, since they each call functions and object methods directly.

Usage:

Code: [Select]

$Script: [
--Lua goes here
]

$Script: {
#Python goes here
}

$Script: #Python goes here




Edit: Yes, you should be able to link the SEXP system in as well.

[Nuke]

damn, the rest of the devs are gonna flame you for that. i dont mind cause i really want scripting  

is there an exe available?
also can you add the variables that the lead indicator operates on for testing, i want to try to make that k-12 radar sight i always wanted

[taylor]

Originally posted by mikhael
There's an easy way to take care of that, taylor, but its a touch bloaty (not Offce XP bloaty).Just slightly bloaty. the SDL documentation has a lead.

But you may be assuming that the current key reading code is sane.  Some of it is strangely hardcoded to deal with mission issues and the freaky way that languages are delt with.  I'd feel better about it if we were just using SDL but we don't under Windows yet and it will be a while before we do.

But even using SDL there are a couple of places where the platform dictates several things (there is a small German fix that is done under Linux but not under OS X since it's not needed there).    It took several weeks for me to coerce the German keyboard layout to work 100% thoughout the code.  Don't really want to go through that again on a larger scale.

Maybe when all of that code is cleaned up it would be easier to do, but for now everything works and changing it would mean a rewrite.  That's not to say that Nuke's question can't be revisited again when the code makes better sense, but for now it's not really an acceptable option.

[WMCoolmon]

OK, a more complete to-do list:

• Fix special operators for objects (eg "+" "[]" "<=" and such)
• Provide functions with the script_state class to get and set global variables
• Figure out how to do temporary objects/variables
• Reintegrate LuaJIT into the project (I've been using stock LUA in case of bugs with LuaJIT)
• Figure out how handle return values (Edit: In a multi-scripting friendly way, I have a simple function that handles pretty much all data types for Lua)
• Clean up the code
• Add comments to the code
• Integrate what's done on Python into the new system.

That's all for Lua, save the last one. I don't plan on working more on the Python stuff except to get what's already in there working again.

return values
What's interesting about Lua is that it allows multiple return values for functions. Barring the obvious mathematical impossibility it's quite nifty.

However, it does mean that whenever you want to return a value you must explicitly say "return value"; in Python, you could actually do it implicitly via a variable; hence the bracketed and non-bracketed Python.

It does raise an interesting conundrum of how to handle it though. Disallow more than one return value? Or leave it optional.

And automatically toss in the "return" value for Lua, and make that the default scripting language used w/o brackets, or leave it explicitly defined?

Here's an example of what I mean..

Here's now:

Code: [Select]

$Ship: GTF Ares
$Shield strength: [return 2 * 25] ;;Lua

$Shield strength: [
somevar = 2 * 25     ;;<-- this is also valid Lua here
return somevar       ;;<--
]

$Shield strength: {} ;;Python; impossible to return anything here, I believe, so shield strength would always be 0
$Shield strength: 2 * 25 ;;Python again.

Or I could make it like this:

Code: [Select]

$Ship: GTF Ares
$Shield strength: [return 2 * 25] ;;Lua

$Shield strength: [
somevar = 2 * 25     ;;<-- this is also valid Lua here
return somevar       ;;<--
]

$Shield strength: {} ;;Python; impossible to return anything here, I believe
$Shield strength: 2 * 25 ;;Lua again, with "return" manually added in automatically

[mikhael]

bloody firefox crashed and I lost my response. Here's the shorter version.

taylor: The only part of FS2 that I ever made a stab at working on was the input code. I laughed, I cried, I screamed in fear. I've been so traumatized I never went back. I also recommended ripping the whole thing out and starting over with something agnostic. I was making absolutely no assumptions. Second, I wasn't actually suggesting using SDL, I was just pointing out that in the docs they describe an agnostic interface, which, of coure, is unnecessary if you ever do go to SDL (which I think would be nice, but again, not what I was advocating).

WMCoolmon: make those global variables/constants accessible in an a global array (dictionary would be even better if lua supports that, python does). That way all you need is introspection to find out what global variables there are without having to hardcode accessors/mutators for all of them.

[WMCoolmon]

I was planning on just providing get() and set() functions, if that's possible, that would use the scripting system's environment. to store the values.

[taylor]

Originally posted by mikhael
taylor: The only part of FS2 that I ever made a stab at working on was the input code. I laughed, I cried, I screamed in fear. I've been so traumatized I never went back. I also recommended ripping the whole thing out and starting over with something agnostic. I was making absolutely no assumptions. Second, I wasn't actually suggesting using SDL, I was just pointing out that in the docs they describe an agnostic interface, which, of coure, is unnecessary if you ever do go to SDL (which I think would be nice, but again, not what I was advocating).

Some of if is being rewritten but not enough in my opinion (I'm doing the rewrite).  We are going to go with SDL on all platforms eventually and when that happens it will be cleaned up and work a bit better.

Wasn't aware of an agnostic interface idea in the SDL docs.  That's certainly something I'd like to take a look at.  Got a link to it, or just which section it's in?

[mikhael]

I can't find it now. It might have  been a user addition that's been purged since. When I just did a quick run through a moment ago its not there. IIRC it was just a matter of ignoring keycaps and reading scancodes and taking the local system's standard codepage to report back what that specific system thought a scancode really meant. There was some discussion in the addenda between other users who had success, and others who had trouble (said discussion probably being why it got purged out).

[WMCoolmon]

Meh! (Re-rails thread)

Now that I have this committed to CVS...all this is in C, so if you're just interested in scripting with Lua, ignore this and see my recent build.

Note that while I'm keeping Python in for now, I'll end up removing all support for it if noone expresses interest in coding for it after awhile.

Scripting extension how-to for Lua in fs2_open
Right now scripting is very easy to do, but also somewhat limited. I haven't added a function to let you get the result of evaluating an expression; but you can provide functions and objects.

First of all, find the "Housekeeping" line. You will not need to change anything below that.

The important structs

Code: [Select]

script_lua_lib_list - An array of libraries
     script_lua_func_list - An array of library functions.
     script_lua_obj_list - An array of objects provided by a library
          script_lua_obj_func_list - An array of object methods.


Important defines
LUA_NEW_OBJ() - Creates a new object in Lua and returns a pointer to it.
LUA_UDATA() - Used with script_parse_args to check an object's type and store it to a pointer
LUA_RETURN_OBJECT - Return this when you've created an object with LUA_NEW_OBJ that you want to return.

Important functions
script_parse_args - Parses args provided to a function, using a format list that specifies the destination arguments.
b - boolean
d - double
f - float
i - int
s - string (Pointer to a char*)
u - userdata (Using LUA_UDATA for the argument)

script_return_args - Like parse_args, except returns the specified values. Lua can have multiple return values. If you have created a new Lua object with LUA_NEW_OBJ, note that it counts as a return value (I provide a 'u' placeholder)

How-to
Look at the existing functions I have in there. It should be pretty straightforward. Adding libraries, functions, and objects is done by simply adding arrays and defining function bodies.

General scripting usage
Once you have a script_state global, and have called Create*State for it, that scripting subsystem should be fully initialized. Yes, you should be able to create multiple states...I don't advise it though.

Parsing code for later use
Call script_state::ParseChunk(). This will return a script_hook, which can be used later for...

Running code
Call script_state::RunBytecode() with the script hook from ParseChunk(). This will return 1 if it succeeds. There's no way to get return values from code yet, at least not in a non-hackish way.

You can actually use script_parse_args() with GetLuaSession() after calling RunBytecode with Lua to get return values...that won't work at all for Python though, and somewhat breaks the abstraction I'm going for.

[Nuke]

id probibly need to see some hevily commented example scripts to understand what you just said.

[kasperl]

Originally posted by WMCoolmon
Meh! (Re-rails thread)

Now that I have this committed to CVS...all this is in C, so if you're just interested in scripting with Lua, ignore this and see my recent build.

Note that while I'm keeping Python in for now, I'll end up removing all support for it if noone expresses interest in coding for it after awhile.
.....

[Nuke]

now you know why i dont try to program for the scp

[mikhael]

If python remains in, WMC, I'll use it.

[WMCoolmon]

It's not so much a matter of using it as coding in the stuff for it. Most people seem to prefer Lua, so I'm trying to stick with it, although it's a toss-up as to which API is worse (Python, with its vague function descriptions and single type, or Lua, with its lowlevel stack functions with cconfusing names/descriptions)

[WMCoolmon]

OK, I've just committed a fix to the code that enables operators...that'd be stuff like "+" "-" etc etc.

Would anyone be interested in a FS2_Open LUA API how-to? This would be covering things like how to add classes and objects defined in C to Lua.

[WMCoolmon]

Yet another commit.

This one adds the ability to treat C pointers to objects (eg "ship" or "ship_info" structs in Freespace) as actual objects in Lua.

Basically, procedure is, if you just want to pass a pointer to an object, you use the LUA_CVAR macro with lua_parse_args() and lua_return_args(), with a "p" format character.

If you actually want to throw a whole class/struct into Lua, you use  LUA_NEW_OBJ to create it, then the LUA_CVAR macro with lua_parse_args() to get it.

(Note that in Lua, an object itself is passed as an argument to a function; so if you had GTF_Hercules:setSpeed(3), the first argument would be the GTF Hercules object, the second argument would be 3)

Meaning: more efficiency, less overhead, easier to code in new Lua objects, etc.