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

[firda]

On 2/27/2020 at 10:25 PM, wetnose said:

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.

1. This really needs at least KSP.log, because your description sounds more like general "InputLock" problem than autopilot holding "FlyByWire". Some other mod can do that (e.g. TooManyOrbits had this problem, fixed recently). Also try the reset buttons in the REPL (reset autopilot, reset process) first. You may also try "ksp.inputLock.printLockStack" and/or look at the locks in the Alt+F12 debug window. Being in any editor field may also be holding the controls (to get the keyboard input).

2. The purpose of the autopilot is to control the ship, so you either control it by a script or not. Pitch control is not so easy to override without totally confusing the autopilot. Nevertheless, I created some way of correcting / overriding the autopilot a bit in the code we are currently testing. The main problem is that when you set a direction for the autopilot and then manually override pitch/yaw, the autopilot will immediately try to compensate, because it treats your input as external disturbance (like drag), but the code being tested now (in firda branch) feeds the user input into the PIDs, which is not ideal, but somehow works (e.g. the surface-retro landing assist now lets you adjust the landing zone by user pitch/yaw controls, works a bit like hover, good for low-tech science gathering around KSC). Also "user.pitch" etc. were added to access user controls which you can then use in the script to react to user/player input and e.g. change the direction you feed into the autopilot accordingly (the new feature has "autopilot.userFactor" etc. to control the strength of user input for changing the autopilot output, setting it to zero reverts to original/current behaviour which is no user control and you can then use "user.pitch" or "player.yaw" to e.g. change the angle instead of directly controlling pitch/yaw - the user input can be used in various ways, another would be to control altitude of a helicopter by throttle controls - but you first need to script that well).

P.S.: Is the above the real code used? You should be saved by the 100-instruction rule here (hoping that the "wile true; if ... wait" won't eat 100 instructions), but generally, the button-clicks are handled asynchronously and could interrupt your main code at any time, which includes just after the "if stab" test, which it could pass, then execute the handler (disabling autopilot) but still continue and execute the "autopilot.direction = ..."

Edited February 29, 2020 by firda

[evandisoft]

Version 0.5.1

New Dependency:

• ModuleManager required for part-values/tags to work

API:

• user can now override/correct the autopilot (autopilot.userFactor)
• universal staging logic (mono, ion, LH2, ...), resources and propellants
• OrbitInfo, orbitAt and changes to positionAt and velocityAt
• TimeStamp and TimeDelta

Scripts:

• launch.ros and control.ros: decouplers marked with noauto tag won't be auto-staged
• control.ros: auto-staging disabled until throttling or executing node
• control.ros: srf-retro landing assist and hohmann improved, can now circularize in different SOI
• lua tutorial scripts removed: This was done to remove clutter. You can copy in the tutorial code if you want the tutorials back.

ROS Changes:

• fixed shadowing by loop variable (var i; for var i...)
• string comparision is case-insensitive, new identity operator (===) added for case-sensitive compare
• comparing anything to string first converts it to string (including enums)
• strings now have .format, .substring, .equals, .compare and .contains methods (case-sensitive)

[firda]

Small bug made it to release: last part-tag is ignored (e.g. "noauto").
Workaround: use "noauto=" (or "noauto x=y") instead

Edited March 7, 2020 by firda

[firda]

I hope everybody is well and we stop the virus soon

[firda]

I have some release ready, with science API, with witch you can automate sciene gathering, .... but does anybody realy care?

Maybe I should really switch to "what I want" mode, instead of "what folks may want" ... because there is nobody there.

[Drew Kerman]

3 hours ago, firda said:

Maybe I should really switch to "what I want" mode

default mode of mod development. Best way to keep motivated

[firda]

Allright, does anybody want some feature? There are two kinds of players that may like to use this mod:

1. Modders: the REPL and 'native' is great for exploring KSP API, you can try and learn without leaving KSP. Lua/Moon(Mun)Sharp is mostly what it is, but if you want some feature in ROS, just ask... generics? or at least one-param-generic-no-arg method to be converted to type-arg method (those 'getByType' methods)? Anything? Be reasonable if you want it quick, don't be affraid to express what you need - best would be to say what you want to do/achieve.

2. Players wanting to automate things: I have created some ready-to-use scripts (launch.ros, control.ros - see second post in this topic). Want some feature? Automate solar-panel deploy and retract? Science gathering? (I had something ready... few months ago, left the work when I planned science-containers and probes gathering science for various labs).

@Drew Kerman The problem is that I will never release anything if it was just about doing what I want - because I would just do what I want which is play the game, not bothering about what other folks think and want. There is kOS, we know, but I went the route of possibly helping others when Evan found me after what happened at kOS (search for 'parts redone'). I was hoping to help others, especially modders, by partnering with Evan who was already working on that REPL, I was working on ROS... so we joined to create this mod.

P.S.: I 'fixed' two other mods I liked... no guarantee:
1. [x] Science:

2. Station Science:

 

Edited June 21, 2020 by firda

[firda]

After first testing, this seems to work with 1.10, will do more tests.

Anybody really reading this? I am not frustrated, but currently uninterrested, some feedback or anybody saying they actually use this mod would help

[manaiaK]

On 6/13/2020 at 2:58 AM, firda said:

I have some release ready, with science API, with witch you can automate sciene gathering, .... but does anybody realy care?

Maybe I should really switch to "what I want" mode, instead of "what folks may want" ... because there is nobody there.

I was just thinking this (one-key science gathering would be great!) a couple of days ago...

[ Off topic: In the mean time, I've been struggling to get my head around the  KAL-1000's editor in the "Breaking Ground" expansion.  The thing really needs an in-game manual (with snack stains, torn ringbinder holes in some pages, marginal notes from Bill, etc.) and a library of examples.  It took me an hour to make deployable grid fins (for booster recovery) with a few hinges.]

Somehow I haven't been aware of Red Onion until today.

As the Right Honorable Mr. J said above, sometimes you just can't be having with all the ceremony (a.k.a. faffing around) in kOS. (Other times, of course, it adds to the fun!)

Keep going! Sometimes the best addons take a while to catch on.

[firda]

6 hours ago, manaiaK said:

I was just thinking this (one-key science gathering would be great!) a couple of days ago...

[ Off topic: In the mean time, I've been struggling to get my head around the  KAL-1000's editor in the "Breaking Ground" expansion.  The thing really needs an in-game manual (with snack stains, torn ringbinder holes in some pages, marginal notes from Bill, etc.) and a library of examples.  It took me an hour to make deployable grid fins (for booster recovery) with a few hinges.]

Somehow I haven't been aware of Red Onion until today.

As the Right Honorable Mr. J said above, sometimes you just can't be having with all the ceremony (a.k.a. faffing around) in kOS. (Other times, of course, it adds to the fun!)

Keep going! Sometimes the best addons take a while to catch on.

Thank you, that means a lot to me to see anybody actually interested in this mod... I was loosing hope, feeling like all this work was just "dream unfulfilled" and I should move on to something different.

Take a look at the science API here, please: https://github.com/evandisoft/RedOnion/blob/firda/RedOnion.KSP/API/Science.md

Feel free to build that version (currently in "firda" branch) before we release it. You should be able to automate science-gathering based on what data you have in KSC (something like [x] Science does) and you can use RedOnion.UI to create any UI you like (with that button - try launch.ros and control.ros to see what you can do with this mod).

BTW, you can access raw KSP API already, so you should be able to do anything, including science-data transfers (planned feature for our API) and possibly even that KAL-1000, but would have to experiment with raw reflected API ('native'), possibly crashing the game if you do something wrong

P.S.: Use 'ship.parts.science' to get this: https://github.com/evandisoft/RedOnion/blob/firda/RedOnion.KSP/Parts/ShipPartSet.md

and eventually this: https://github.com/evandisoft/RedOnion/blob/firda/RedOnion.KSP/Parts/PartScience.md

Edited July 2, 2020 by firda

[firda]

OK, I now see there actually is some interest in this mod (exactly what I asked for), so I now feel obliged to do a release.

I am currently working on the Science API, UI.ScrollBox (and ScrollBar) and some collections for ROS (list, queue, dictionary) ... all towards the goal for recreating [x] Science (or something like that) in `science.ros`.

I will consult that with Evan, but, will at least put unofficial `.zip` here (in a month) in case we do not agree on the release.

I am leaving for holiday in two days Have fun

[kubi]

On 7/30/2020 at 6:42 PM, firda said:

OK, I now see there actually is some interest in this mod (exactly what I asked for), so I now feel obliged to do a release.

Just saw your work yesterday. After a quick check of the documentation it seems really promising. I'll dig more into it over the weekend.

My main use case is playing around with KSP APIs quickly without compiling code.

 

[firda]

On 8/6/2020 at 8:23 AM, kubi said:

My main use case is playing around with KSP APIs quickly without compiling code.

A brave man exploring the [Unsafe]

I do that all the time, switching things to public, so that the script can work with it, and experimenting to see what to add to our "safe" API (or learn Unity UI).

We will gladly accept new team member willing to work on any part of this mod, just send me PM (with discord ID) if you are interested.

[evandisoft]

On 8/5/2020 at 11:23 PM, kubi said:

Just saw your work yesterday. After a quick check of the documentation it seems really promising. I'll dig more into it over the weekend.

My main use case is playing around with KSP APIs quickly without compiling code.

 

That is cool, would love to hear what you think about it. It's hard for us to know what is missing from a user perspective.

Edited August 17, 2020 by evandisoft

[evandisoft]

On 8/7/2020 at 1:18 AM, firda said:

A brave man exploring the [Unsafe]

It's not any more dangerous than what a modder has to do to try out code. Just happens at an interactive pace instead of changing something -> compile -> test -> changing something -> compile -> test

I know you know this, but I just don't want people to get the wrong impression.

Edited August 9, 2020 by evandisoft

[evandisoft]

0.5.2

API

• 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

• UI: ScrollBox and Scrollbar (early versions, some improvements shall come soon)

Lua

• Fixed lua completion bug for array literals.

ROS

• Built-in functions and objects (added collections, documentation)
• Fixed break in (nested) foreach (for var e in list)

Edited August 18, 2020 by evandisoft