scripting support

[popsch]

Hi.

As we now have a new release and it seems to be quite stable, I would like to discuss the idea of adding scripting support to oolite, again.

An excellent candidate is: Lua at http://www.lua.org/
It is lightweight, mature, portable (in C) and has an objc-c bridge.

These are the points in favor of scripting:
- full fledged language (loops, debugging, calculations, etc.)
- good documentation & community support
- existing libraries (e.g., for string operations, so no more [[commander_name]] hacks)
- no explicit function enabling
- can be run in parallel with the existing one

A simple script could then be:

Code: Select all

function OnExitWitchpoint() {
  if ( random() < 0.1 ) {
     if ( numberOfShips("pirate") < 3 ) {
       // trader festival
       addShips("trader",10)
     }
  }
}

Also ship's AI would be more readable and can be easier programmed, e.g., multiple escorts attack in formation or with certain styles (e.g., distance shooting instead of fencing).

I know, the decision is up to Giles, but what do you think?

[Murgh]

Lua seems highly recommended by many. not that, at first glance, the language feels significantly more accessible than Oolite's own.

you mean this could really be implemented without pain and leave the existing scripting and AI totally intact?

[JensAyton]

Lua seems highly recommended by many. not that, at first glance, the language feels significantly more accessible than Oolite's own.

Possibly not more acessible, but much more expressive. Oolite’s current system is a finite state machine, or type-3 grammar; Lua is a Turing–complete type-0 grammar. What this means is that Lua, unlike Oolite’s system, is a complete programming language.

It would be possible to rewrite the AI completely in Lua, for instance, including tracking and aiming, and the ability to completely override these; you’d be able to write your own broadside-fighting code for heavy ships. You can use loops and complicated conditions. And, more prosaically, you would have direct access to the objects used within Oolite and could, for instance, generate your own unnamed NSColor, and be the first to have a lime-green laser. ;-)

you mean this could really be implemented without pain and leave the existing scripting and AI totally intact?

Without pain for the end-user and OXP-maker, almost certainly. Without pain for Giles, possibly. :-) However, the existing Lua Objective-C bridge hasn’t bee tested with the GNUStep runtime, so some pain for winston seems likely. :-/

Also, it doesn’t seem to have any security features. Placing some restrictions on the classes available to scripts seems prudent.

[aegidian]

Possibly not more acessible, but much more expressive. Oolite’s current system is a finite state machine, or type-3 grammar; Lua is a Turing–complete type-0 grammar. What this means is that Lua, unlike Oolite’s system, is a complete programming language.

Just to be clear, although the AI system is a FSM, the scripting system is slightly different. It's been a long time (19 years) since I took comp-sci so I couldn't say more about it as a language.

Lua (or Python or whatever) is NOT going to happen in the main branch until the major issues I'm currently working on are dealt with.

If someone would like to fork the GUSTO to set up a branch with different scripting support (with a view to merging it into the trunk when it works well across all platforms), then they should register with berlios and approach Ahruman, Winston and me about doing so.

[winston]

I think I mentioned it in the linux forum, but the GUSTO branch now builds on Linux and OS X (Cocoa) out the same tree. I still have some issues with the xcode project (which I might just recreate anyway) - I'll prolly do that when my visitors have left.

It's in the Oolite-Linux repo, look in the branches directory for 'cocoa-merge'.