Jump to content

Any thoughts on a Lua Shell plugin?


Recommended Posts

Anyone working on a plugin to support a LUA shell?

If so, I thought about how something like this might best be implemented.

After seeing some code examples of drawing GUI and pulling data, and after trying out that sweet auto ascent computer and auto pilot - I first envisioned an environment that we could place on rockets in the form of a small model, perhaps an antenna or radial node - and a 1m or larger equivalent part for incorporation in larger designs.

Why we would want a small part became apparent to me while using IFE\'s SLS rocket system. I would have loved to have 'computer' capacity without having to dump the 1m module after payload deployment.

Put another way, the Altair lander doesn\'t have room for a 1m module, and advanced flight controls should be usable for all craft.

If we had a shell, then we could simply run these types of plugins natively without parts; ones that load as part of a vehicle start up systems.

Secondary to this, it would be fairly easy to draw up lua scripts to initialize a startup sequence, build on-screen preflight checklists, and trigger events with functions like sounds for better immersion.

If such a plugin could efficiently pull all the variables from parts, then you could create a system to monitor total vehicle integrity, and hunt down problem areas. It will also be cool to hear a master caution alarm go off seconds before a catastrophic failure.

Link to comment
Share on other sites

I have this idea of trying to make a very simple Forth interpreter in a plugin. Hey, it IS a space-age language, besides being the easiest one to implement. But it\'s definitely a long-term project....

It would have to define Words in 'machine code' (C#, in reality) for all the required interfaces to KSP, but this would have a good side: programs for the virtual computer would be totally harmless to the player\'s machine.

Link to comment
Share on other sites

A plugin-based interpreter would have the advantages that it\'s self-contained and exposes a clean API. However, it has several disadvantages over equivalent C# code:


  • [li]C# is primarily an object-oriented language. Though KSP doesn\'t take full advantage of this, it does revolve around per-object events, so you\'d need some way to elegantly script those.[/li]
    [li]Performance is an issue since some part events execute every frame. To optimize this you could compile a script object at run-time (using reflection, as with regular expressions) or
Roslyn when it comes out.[/li]

But the biggest problem, in my mind, is adoption. It\'s clear that a lot of amateur developers are having trouble building plugins, but I don\'t think it\'s because of the language. It\'s symptomatic of the way KSP classes are structured; they follow Unity conventions pretty closely, which is great for internal consistency. The problem is that Unity conventions are absolutely terrible. As a seasoned C# developer, I find the 'Unity way' is confusing, counterintuitive and problematic, so I can only imagine how difficult it must be for a beginner.

In other words, a scripting interface would make things easier, but primarily because you\'d have to neatly wrap KSP in a clean, well-structured API.

Link to comment
Share on other sites

Performance is an issue since some part events execute every frame. To optimize this you could compile a script object at run-time (using reflection, as with regular expressions) or Roslyn when it comes out.

Yes, but I\'d say we can afford inefficiency... we can easily afford to burn a hundred million cycles per second to run programs that would be very simple for today. I think that even something capable of simulating, say, 50000 high level* 'instructions' per second would prove plenty fast for most purposes.

Reflection is powerful, but wouldn\'t that undermine the inherent safety of interpretation?

(Besides, I like the idea of using Forth for personal reasons, and no, I\'m not talking about a masochistic streak of mine. I suppose nobody will follow me on this though :D)

But the biggest problem, in my mind, is adoption.

Well, I don\'t dream of imposing any standard: we still haven\'t seen any documentation and the guy(s) behind Mechjeb have already done most of what I would have ^^ I\'d be making it to see if I can... of course I would be glad if somebody used it, someone else expanded on it. If a version that uses C# directly gets made, I would be very interested; me, I have no idea how to do that.

(*) KSP function calls, mathematical functions, etc. would be single 'instructions' for the virtual computer.

Link to comment
Share on other sites

I like Lua myself. It\'s a nice, clean language and it interfaces with C# very well as far as I know. I think a fully-documented Lua API would be wonderful for KSP. However, I would like to see the current one stay open as it offers more freedom to programmers. :)

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...