Allow editing of lua scripts in an external editor

[samdeane]

(previously filed here)

Implementing some support for external editing would be a much better use of limited programming time than trying to enhance the in-game script editor.

There are various ways this could be done - one suggestion is given below, but there are other ways it could work.

---

The game should be capable of packing/unpacking the scripts attached to a controller into a file-based format (in a similar way to wrap.lua).

Any scripts that the user has permission to edit in-game should also be cached in the file format, using predictable file names and locations on disk, such that they don't change over time.

The game should monitor these files for changes, and update the scripts in-game when the external files have been edited.

This would allow script authors to edit their scripts using an external editor such as VS Code, with all the advantages that would bring (auto-completion, syntax colouring, linting, search & replace, etc).

As this is a feature primarily aimed at script authors, it could be enabled/disabled with a client setting, to avoid affecting performance for non-author users.

[Archaegeo]

You can do this already by editing .conf type scripts using various editors, but I get what you mean

[NQ-Ligo]

Hi there!

Honestly, this could be something for us to implement. But we clearly don't have the resources to do it. So probably not.

[samdeane]

But we clearly don't have the resources to do it. So probably not.

I don’t understand this statement.

It would be a lot easier to implement this than to get an in-game editor into a state where it is actually good. Something like VS Code gives you syntax checking, linting, colouring, etc, etc, all without NQ having to write a line of code.

All you have to do to implement it is:

• add an “edit externally” option to the client preferences
• when the user hits “edit” on a script, write out the existing code to a temporary directory, using a well-defined mapping to put each handler into a separate lua file
• tell the external editor to open the folder
• put up a “Save/Cancel" modal dialog in-game, and when the user hits “Save”, read the contents of the temporary directory

There are obviously lots more clever things you could do on top of this, but just doing this would be a massive quality-of-life improvement for people who are writing serious scripts. Those who are just dabbling can continue to use the basic in-game editor.

[matpratta]

@samdeane I know this is not official and definitely now as efficient as having the game hot reload your scripts from a directory in your PC, but I invite you to try my Lua CLI. It is a bit more advanced than wrap.lua and has an option of directly exporting the JSON into your clipboard, so you can iterate faster. It also has a few extra goodies to deal with links and events, in case those interest you.

https://github.com/wolfe-labs/DU-LuaC

[samdeane]

Thanks, sounds cool, I will check it out. I have a fairly complex custom setup which does all the event dispatch and uses multiple Lua modules via imports and then builds them all into a single json file for release. Works ok, as far as things go, but a lot of what it does would not be necessary if DU was vaguely sane :).

[samdeane]

Your stuff looks cool @MatheusMK3.

The system I developed is quite similar in some ways, and I think the motivations are pretty convergent.

With my system you install the stub event handlers in the controller in DU, and a small bit of configuration which tells the rest of the system which modules you are using. It also auto-detects what things are linked to the controller.

Modules in my system are functional units which do things like provide a single instrument for the dashboard (altimeter, fuel indicators, whatever), or a single bit of functionality (auto-gear support, auto-navigation, etc). You can pick and mix what you want for any given core/controller setup.

During development each of these modules is in its own lua file on disc, and at runtime it is brought in with import. However, there's also build/pack functionality which takes the content of all used modules and combines them into a single script which can be applied back to the controller as JSON (it could also make auto-conf files, though I haven't found that I need them). These packed versions of the scripts can still use import to access the latest code if it is present on disk locally, but can also work standalone so that constructs are useable by people without the local source.

I always intended to make all of this open source, but it was in a constant state of flux and I wanted to clean it up and make it really simple to use before dropping it.

Ultimately I lost motivation (with DU, rather than with my framework). That's mostly down to the approach they've taken with how they've implemented the lua scripting, and how they've implemented the various restrictions.