[1.10.x] RedOnion: Unrestricted in-game scripting v0.5.2

[evandisoft]

RedOnion and Kerbalua

A joint effort of Evan Dickinson and Lukáš Fireš to create unrestricted scripted environment inside Kerbal Space Program for all players and even modders wishing to control the game, vessels, anything, with own script.

Current Features:

1. Repl/Editor with intellisense.
2. Scripting engines that can interact with Classes from any loaded CLR assembly.
3. Lua scripting engine called Kerbalua that uses a slightly modified version of MoonSharp.
4. Powerful custom language/engine (RedOnionScript) built by Lukáš Fireš.
5. API's for doing things more easily or more safely, including Autopilot API, UI api, and more.

Goals:

1. Provide ability to produce mods in Kerbalua/RedOnionScript and modify them without restarting the game.
2. Provide ability to debug mod code/scripts without restarting the game.
3. Provide ability to write user scripts, like automatic control of your ship.
4. Provide ability to interact with live game objects in a repl.
5. Provide powerful general editing capabilities inside KSP
6. Provide powerful API for modmakers/Users
7. Help document the KSP API for modmakers.
8. Help people learn to program in a fun way.

License: MIT

Github: here

Github Pages is where the most up-to-date information is.

Warning: Do not use scripts from untrusted sources! This is not a sandbox, any script has the power to do almost anything a modder could do in C#. We plan to eventually implement a switch to limit the power (disable what is marked [Unsafe] in the code), but our goal now is to:

• Allow users to do whatever they wish to do to the game environment to have fun.
• Help modders develop and debug their mods using this mod.
• Help anybody to explore KSP API, their own or other's mods (read the license of other mods you decide to use this tool to interact with, we expose only public members directly).

Releases

Your scripts are in GameData/RedOnion/Scripts. If you delete this folder, it will destroy your scripts. I believe that CKAN does not delete them when uninstalling the mod or updating it, but you might want to make a copy of the folder just in case. We provide example scripts in a zip file, which will appear in the list of scripts in-game but wont be in the Scripts folder. If the example programs don't run, check out that section in TroubleShooting

Latest Releases are available at: - CKAN - Spacedock - CurseForge (Note about using Twitch Client "Install" button)

ChangeLog: here

Documentation

• Scripting - Documentation related to scripting.

• LiveRepl - The main user interface for the project. Where scripts can be loaded, written, and executed.

• Troubleshooting - Some possible issues and solutions.

• Development - Main page for development documentation (project structure, implementation explanations, etc).

Videos are listed here

Upcoming Features

• Next Release

• Planned

Feedback

All feedback is appreciated. Feedback can be left on our forum thread, as a new issue, or as a comment on any of our videos.

Contributing

We welcome people of all skill levels to contribute or give feedback, ask questions, etc.

Here is more information about contributing.

Edited August 17, 2020 by evandisoft
New Release

[firda]

v0.5.1 post-release notes:
- the new part-values/tags ignore last tag written without equal sign, so use "noauto=" as a workaround - fixed in firda-wip branch
- the new user override (autopilot.userFactor) unfortunatelly affects non-active ship as well, if you are controlling it by a script - just noticed that when rotating my station to make attaching new addon easier (and having control.ros still controll the addon pointing it towards the station - rotating the station also rotated the addon) - fixed in firda-wip branch
- rewriting the user override for next release, adding autopilot.pylink for better 2D/3D behaviour (rotation in straight line instead of curve, maintaining pitch/yaw ratio)
- working on new UI.ScrollBox and ScrollBar, hoping to one day include good scrollable text/source editor and other controls

v0.5.2 future release so far:
- fixed part tags (e.g. "noauto", required "noauto=" or "noauto x=y" before)
- reworked autopilot override + "pylink" for better 2D/3D control
- Science API, science.ros (supports DMagic's Orbital Science and DMModuleScienceAnimateGeneric)
- OS/Process API (early version of MunOS API for scripts)
- UI: ScollBox and Scrollbar (early versions, some improvements shall come soon)
- ROS: built-in functions and objects (added collections, documentation)
- ROS: fixed break in (nested) foreach (for var e in list)

launch.ros:
- launch and circularize script with param gui
- default parameters were chosen to launch selected stock ships successfully (AeroEquus and Dynawing)
- try increasing the "first altitude" (and maybe "first angle") for ships with high drag (like massive station that won't fit inside fairings)
- lower it (and select more aggressive profile) for small ships with powerfull engines (e.g. light sattelites) for better delta-v efficiency
- there is some AoA limiting based on Q, so add some tail-wings (I like the deluxe) and/or change the parameters if the ship flips-over

control.ros:
- orbit/surface prograde/retrograde/normal/anti-normal/radial-out/in hold
- srf-retro has throttle-limiter as landing assist (full throttle will kill the speed until the ship hovers / slows to 0.5m/s descent)
- target towards/away hold and match speed (relative stop) with throttle-limiter (again full throttle to stop relative to target)
- maneuvers and node creation - circularize, incline, hohmann transfer (or return to Kerbin from a moon)
- MAN now presses the "EXEC" button automatically, while NDE only creates the node (MAN may be removed in the future e.g. for options)

science.ros:
- will be included in future v0.5.2
- basic science gathering helper window
- rather "proof of concept" at this stage, shall be enhanced later

autorun.ros:
- not part of included scripts yet, but you can find it in the repo
- autostarts launch.ros or control.ros automatically based on situation, just exec autorun.add "autorun.ros" once in the REPL

P.S.: Current Common API Documentation
Latest unreleased documentation in my branch here

Edited August 8, 2020 by firda
Notes about future v0.5.2

[evandisoft]

Version 0.4.1

• Fixed bug where outputting a lot of things quickly (with something like "while true do print(1) end") takes more and more memory and is very slow.
• Fixed a bug where misformatted lua code would run anyway and just repeat an error message.
• Intellisense works for enums.
• Fixed a bug where completion on CommonAPI properties (like the global "body") wasn't working properly.

Edited November 25, 2019 by evandisoft

[evandisoft]

Version 0.4.2:

• Bug in ship.parts relating to explode functionality fixed.
• Tutorial of how to fallback to native functionality.
• Tutorial for selfDestruct.lua
• Tutorial for using the ui in Lua code (uibasics.lua)
• More docs.
• Fixed a problem with new(ui.Button,"buttontext",function() end) where the new function wasn't properly converting a lua function to the Action\<Button> that the ui.Button constructor requires.
• Removed randomPartDestruct.ros as its code was outdated.
• Fixed bug with autoloading the last scriptname.

Edited November 30, 2019 by evandisoft

[evandisoft]

Version 0.4.3:

• Undo/Redo for LiveRepl Editor. Stores at least 50 of the last changes.
• Fixed bug where Lua was outputting strings twice
• Renamed KerbaluaMoonSharp assembly (our modified version of MoonSharp) to MunSharp.
• Fixed MoonSharp issue where some classes could not be automatically registered because of having members that hide base class members without overriding them.
• Improved format for CommonAPI docs.
• Removed OtherDLLs folder and switched to using nuget for the MunSharp.dll, so we can potentially make more changes in the future.
• Tutorial showing how to iterate over the parts and modules of a ship.
• Lua constructor improved. (Firda found an already implemented, but undocumented version in MoonSharp)

Edited November 30, 2019 by evandisoft

[evandisoft]

Version 0.4.5:

(Dropped in the wrong zip for 0.4.4 so releasing it again as 0.4.5)

• Fixed a problem with Lua engine not resetting.
• Also the terminate button now will destroy UI's and vectors that were created by a script.

Edited November 30, 2019 by evandisoft

[Drew Kerman]

Even tho I'm sticking to kOS for a while still since its well established and I have a lot of stuff built off it, def keeping an eye on this for future projects as well possibly

[Superfluous J]

This looks amazing. I'm a bit shocked that nobody replied for almost a week unless you did some kind of stealth release where you titled the post "Listen to my Podcast" or something else you knew no one would ever click on, until just recently.

I'll be trying this out for sure in the near future, it's kind of what I always wanted kOS to be, just scripting without all the rigamarole.

[evandisoft]

14 hours ago, 5thHorseman said:

This looks amazing. I'm a bit shocked that nobody replied for almost a week unless you did some kind of stealth release where you titled the post "Listen to my Podcast" or something else you knew no one would ever click on, until just recently.

Could be because we aren't really well known by the community. Thanks for replying!

14 hours ago, Drew Kerman said:

Even tho I'm sticking to kOS for a while still since its well established and I have a lot of stuff built off it, def keeping an eye on this for future projects as well possibly

Understandable. I used kOS for quite a long time. You could possibly use both. Though I wouldn't try using both's autopilot's features at the same time. You might be able to run scripts from both simultaneously if you are not using KSP api features that would interfere. Merely using the LiveRepl in cases where you are not running a kOS script and have no kOS locks set should be totally fine (though I have not tested it).

Edited December 1, 2019 by evandisoft
OCD

[firda]

8 hours ago, Drew Kerman said:

Even tho I'm sticking to kOS for a while still since its well established and I have a lot of stuff built off it, def keeping an eye on this for future projects as well possibly

I will slowly be porting my kOS scripts to ROS, implementing and documenting things on the way (still need targeting and node manipulation for the control.ros). Some other things (stage.burntime) need improvement, but launch.ros already does decent job

8 hours ago, 5thHorseman said:

I'll be trying this out for sure in the near future, it's kind of what I always wanted kOS to be, just scripting without all the rigamarole.

Always wanted to run kOS in the editor (VAB/SPH)... now I can run ROS/Lua

Still a lot of work ahead. And a lot of fun!

[Daedala]

This is extremely cool! I love it!

I do have one request -- would it be possible to get LiveRepl to respect KSP's "UI Scale" setting? Everything's very tiny and difficult to read on a 4K monitor at the moment...

[firda]

5 hours ago, Daedala said:

I do have one request -- would it be possible to get LiveRepl to respect KSP's "UI Scale" setting? Everything's very tiny and difficult to read on a 4K monitor at the moment...

Made a note in our discord for Evan to look at it. Also added to my own todo list to use the scaling for RedOnion.UI used by the script (e.g. the launch param UI) and to add scale factor to UI.Window (so that each window can be scaled individually from a script). Looks like RedOnion.UI scales well, because it is Unity UI and KSP scales the canvas it is on. Evan is working on the Repl.

BTW, currently working on try..catch..finally in ROS - will need some time to make it right.

Edited December 2, 2019 by firda
update

[evandisoft]

12 hours ago, Daedala said:

This is extremely cool! I love it!

I do have one request -- would it be possible to get LiveRepl to respect KSP's "UI Scale" setting? Everything's very tiny and difficult to read on a 4K monitor at the moment...

Thank you for informing us of this issue! The fix will be in the next version released within a few days I think.

I've managed to scale everything but the scrollbar widths. A compromise is that I was able to enlarge the area that accepts dragging, but not the part that looks like a bar and goes up and down when you drag it. So hopefully you'll be able to easily drag the scrollbar on your monitor. But the visible vertical bar (if you can see it) will be on the left of a somewhat larger area where you can use the mouse to drag it.

(I don't have a high resolution monitor so on 200% ui scale I can only verify that the parts that fit on my screen worked)

Edited December 2, 2019 by evandisoft

[evandisoft]

Version 0.4.6:

RedOnionScript (ROS) Changes:

• Try/Catch/Finally for handling errors. Kerbalua has Lua's pcall.

LiveRepl Changes:

• Fixed an issue where the global keybindings of LiveRepl could be activated when the input is not locked to the window. (input is locked when the mouse is inside the window bounds)
• Made LiveRepl use KSP's UI_SCALE setting. Hard for me to test this thoroughly as I don't have a monitor with a high enough resolution, but from what I can see it is working. I could add an additional scaling factor in some other setting later, if desired, to make it even larger. One thing I did not find how to scale was the scrollbar. But I was able to scale the part of the scrollbar that accepts mouse dragging.
• CompletionArea resets the scroll position each time the completion results list gets updated.

Lua Changes:

• Lua reflection api was a bit confusing. I'm changing the terminology to type and runtime type instead of static and type. So what was once a static will now be called a type, and what was once a type will now be called a runtime type. (runtime types are for reflection whereas types are for accessing static members of clr classes or passing as the first argument to new to create a new object.)
• Removed dofile, loadfile, and loadfilesafe as they do not use the Scripts directory as the base directory and cannot be configured to do so. Versions of these (at least dofile) will be implemented in the future.

require can be used because it allowed me to specify the base path. However, require will only run something the first time you call it on some filepath. To make it run that file again you have to do packages[filepath]=nil first.

Edited December 4, 2019 by evandisoft

[Beetlecat]

On 11/30/2019 at 5:02 PM, Drew Kerman said:

Even tho I'm sticking to kOS for a while still since its well established and I have a lot of stuff built off it, def keeping an eye on this for future projects as well possibly

And they serve different purposes, to an extent, yeah? kOS is fairly consistent with being a "lore-friendly" automation add-on (optionally) requiring parts on craft, and code storage space considerations, etc. ROS is much more of a universal deus ex machina. It's pretty awesome to have both!

[firda]

13 hours ago, Beetlecat said:

And they serve different purposes, to an extent, yeah? kOS is fairly consistent with being a "lore-friendly" automation add-on (optionally) requiring parts on craft, and code storage space considerations, etc. ROS is much more of a universal deus ex machina. It's pretty awesome to have both!

kOS will always have its place and RedOnion/Kerbalua also have other goals besides flight automation - to enrich the community by giving modders good tool to explore the internals of KSP and to test and debug their mods.

P.S.: Speaking of which, native.GameSettings.UI_SCALE gives you the scaling factor (@Daedala) and native.GameEvents.OnGameSettingsApplied.add def => print ... lets you react to the apply button and you can try that in the Repl without leaving the game and building any mod.

P.P.S.: Just noticed the `print` is delayed (until you execute another repl-line or have it in yielding script). Will be fixed in next patch-release.

Edited December 4, 2019 by firda

[evandisoft]

Version 0.4.7:

General Changes:

• time.warp.ready improved
• added GameSettings and GameEvents into KSP namespace

ROS Changes:

• launch.ros and control.ros now use try..finally
• fixed delay in repl for native events in ROS

LiveRepl Changes:

• Fixed bug where LiveRepl cleared all Input ControlLocks instead of just the one it had set.
• Stopped using the ControlTypes.KEYBOARDINPUT lock. Now keyboard input (except camera control) is only locked to the window when the window is focused. Still have to lock ControlTypes.CAMERACONTROLS when mouse is in the window bounds, as otherwise scrolling the mouse zooms KSP in and out regardless of the mouse being over a window and that window being focused.

[Daedala]

Thanks, the UI scale thing really helps on 4K monitors! I did notice one little oddity though -- unexpectedly, this change not only caused this mod's windows to scale up, but also some other mods I have installed as well! I'm not sure if this is a bug or a feature... lol... it works great when those mods weren't already scaling, but not so great if they were already scaling themselves up.

Edited December 7, 2019 by Daedala

[evandisoft]

10 hours ago, Daedala said:

Thanks, the UI scale thing really helps on 4K monitors! I did notice one little oddity though -- unexpectedly, this change not only caused this mod's windows to scale up, but also some other mods I have installed as well! I'm not sure if this is a bug or a feature... lol... it works great when those mods weren't already scaling, but not so great if they were already scaling themselves up.

thanks. I will work on a fix. (I did not intend to modify anyone else's scale).

Edit: I've installed a bunch of mods and am checking for any issues in general.
Edit2: After trying a bunch of mods I see that this at least effects ToolbarController.
Edit3: Found an issue where I was modifying the default style for GUI.Label instead of modifying a copy of it. I think that is the bug. Fix will be in next patch.

Edited December 7, 2019 by evandisoft

[evandisoft]

Version 0.4.8:

ROS Changes:

• ROS: fixed problem with variables with same name
• launch.ros: pitch-down logic for tilted/off-center engines (Dynawing)
• target and ship.target - works for bodies, ships and parts (docks)
• control.ros: targeting, rendezvous and docking assist

LiveRepl Changes:

• Changed Kerbalui to use GetControlID to get a unique controlid for each window.
• Fixed issue where LiveRepl was making modifications to the fontsize of the default GUI.Label style instead of making those changes to a copy of that style.
• Hitting run will only save the file if it has been modified in the editor. Otherwise it loads the file from disk into the editor. This will allow you to more conveniently use an outside editor.
• Scene changes, including revert, now terminate any windows or vecdraws.

[evandisoft]

I've started regularly playing with a highly modded install (52 mods). I'm including many of the most popular mods. I cannot make any guarantees, but hopefully if there are compatibility issues I will encounter them.

If anyone else encounters compatibility issues, please let me know, and I will start working on a fix immediately.

Edited December 9, 2019 by evandisoft

[Daedala]

19 hours ago, evandisoft said:

• Fixed issue where LiveRepl was making modifications to the fontsize of the default GUI.Label style instead of making those changes to a copy of that style.
• Hitting run will only save the file if it has been modified in the editor. Otherwise it loads the file from disk into the editor. This will allow you to more conveniently use an outside editor.

Nice! Scaling is now working well for me without affecting any other mods, and as a Sublime Text user, I'm very happy to see the changes for loading files from disk. Thank you very much!

[evandisoft]

I found a bug in the lua engine's "new" function when you pass in no arguments beyond the type itself.

HashSet=native.System.Collections.Generic.HashSet

myset=new(HashSet)

Causes an error.
Normally I would fix this immediately, but we're working on a big release that is not ready.

A workaround is
 

HashSet=native.System.Collections.Generic.HashSet

myset=HashSet.__new()

 

Edited December 23, 2019 by evandisoft

[evandisoft]

Version 0.5.0:

MunOS:

• Initial version of our system for running multiple scripts at a time, called MunOS.

API:

• autopilot.disable now also resets killRot to false (was often locking roll in control.ros)
• api for maneuver nodes, sas, rcs and some other orbit-related properties

Lua:

• Fixed bug where the new function was causing errors when it recieved no argument except the type to instantiate.

Scripts:

• control.ros: maneuver executor, circularize, Hohmann planner, inclination match
• control.ros: srf-retro throttle limiter (below 10km) as landing helper (full throttle makes the ship hover)
• launch.ros: fixed the wobble at the end of circularization

And also, happy new year.

Edited January 1, 2020 by evandisoft

[wetnose]

KSP 1.9

Problem 1. Sometimes, after using of the autopilot, I loose ability to control the ship - it ignores all the control buttons even if disable the autopilot.

var wnd  = new ui.window false, ui.layout.vertical
var stab = false
var vv   = 10

wnd.x -= (unity.screen.width - 200) / 3 
wnd.title = "Kill H/s"

def autoUp
  stab = true


def autoOff
  stab = false
  autopilot.disable()


var btnUp  = wnd.addButton "ON", autoUp
var btnOff = wnd.addButton "OFF", autoOff

btnUp.width = 120
btnOff.width = 120

wnd.visible = true

try
  while true
    if stab
      var hv = ship.srfvel.projectOnPlane ship.away
      autopilot.direction = ship.away * vv - hv
    wait
finally
  wnd.dispose()

Problem 2. When the autopilot is enabled I cannot correct the ship orientation manually - all my commands are ignored. It is contrintuitive. MechJeb2 Translation Tool allows manual corrections.