[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[Flibble]

What other modules are on the part?

[RizzoTheRat]

"ModuleGrappleNode"
"ModuleAnimateGeneric"
"FXModuleLookAtConstraint"
"FlagDecal"
"KosNameTag"

Looking at the save file for the ModuleGrappleNode

MODULE
{
	name = ModuleGrappleNode
	isEnabled = True
	stagingEnabled = True
	state = Disabled
	dockUId = 0
	grapplePos = 0,0,0
	grappleOrt = 0,1,0
	grappleOrt2 = 0,0,0
	EVENTS
	{
	}
	ACTIONS
	{
		ReleaseAction
		{
			actionGroup = None
		}
		DecoupleAction
		{
			actionGroup = None
		}
		MakeReferenceToggle
		{
			actionGroup = None
		}
	}
	UPGRADESAPPLIED
	{
	}
}

State changes to "Ready" when it's armed, so that's definitely the parameter I'm trying to change.

 

Backup plan is put it in an action group and toggle that, but it'd be nice to know how to do it properly.

[Dunbaratu]

6 hours ago, RizzoTheRat said:

It's the "Arm" button on the right click menu I'm trying to use, so presumably it should be available.

 

I've tried printing :allfields, :allevents and :allactions for the ModuleGrappleNode

It returns no fields, 1 event (control from here) and 3 actions (release grapple, decouple node and control from here).

Nothing obvious for arming it.

If it's called "Arm" then it won't be the field called "Status".  "Status" is the *effect* of executing the event button called "Arm", and isn't directly set.

Chances are you're looking at the wrong Module.  Try this printout to see what's available in ALL the modules.  They probably have the "Arm" button in a different module from ModuleGrappleNode.
 

// assumes you've tagged the grappling part with the tag name "grapple":
local P is ship:partstagged("grapple")[0].
for modName in P:allmodules {
  print "---- MODULE: " + modName + " ----".
  print P:GetModule(modName). // should print the members of this module.
}

 

Edited May 26, 2019 by Steven Mading

[TBenz]

@RizzoTheRat I'd recommend looking at the cfg file if you want the full story on part modules.

A quick glance at the file and I notice this module here.

Quote

MODULE
    {
        name = ModuleAnimateGeneric
        animationName = Deploy
        startEventGUIName = #autoLOC_502073 //#autoLOC_502073 = Arm
        endEventGUIName = #autoLOC_502074 //#autoLOC_502074 = Disarm
        actionGUIName = #autoLOC_502075 //#autoLOC_502075 = Toggle Arming
    }

It looks like ModuleAnimateGeneric is what manages the actual arming and disarming of the Grapple Node. I haven't actually used KOS (stumbled into this thread to check it out), but I'm assuming that the proper way to arm and disarm the AGU is through calling the respective arm (start) and disarm (end) events, or the toggle action.

[Drew Kerman]

@hvacengi @Steven Mading

In regards to my earlier post about the guidance issues I'm experiencing - could the PID be switching some sort of reference frame at 2.6km that causes all my rockets to readjust their orientation despite lack of any other common factor? I still can't think of any reason they all do this at that altitude.

 

[Dunbaratu]

When low to the ground, the planet is stuck in place and the universe is rotating.  When high above the ground, the universe is stuck in place and the planet is rotating.  KSP converts your velocity and position into the new reference frame when you cross the transitional boundary, and tries to do so seamlessly.  Maybe that's doing it?  But I thought that transition happened much much higher than at 2600m though.

[Drew Kerman]

2 hours ago, Steven Mading said:

When low to the ground, the planet is stuck in place and the universe is rotating.  When high above the ground, the universe is stuck in place and the planet is rotating.  KSP converts your velocity and position into the new reference frame when you cross the transitional boundary, and tries to do so seamlessly.  Maybe that's doing it?  But I thought that transition happened much much higher than at 2600m though.

me too, I mean it does it later on for the game itself when you see the velocity switch on the navball.

I dunno, it's just weird that when I look through my ascent videos I see all the rockets correcting their guidance as they cross this boundary

[Flibble]

4 hours ago, Steven Mading said:

When low to the ground, the planet is stuck in place and the universe is rotating.  When high above the ground, the universe is stuck in place and the planet is rotating.  KSP converts your velocity and position into the new reference frame when you cross the transitional boundary, and tries to do so seamlessly.  Maybe that's doing it?  But I thought that transition happened much much higher than at 2600m though.

The switch on the navball is at around 30km altitude, definitely not that low. It shouldn't break steering anyway, the switch to a new reference frame is pretty simple and doesn't introduce large errors (since you're pretty close to SOI centre).

[FloppyRocket]

On 5/22/2019 at 2:54 AM, Flibble said:

You should have a button labelled "toggle torque" that can be used to disable the reaction wheels.

Thanks, that's what I was missing.

On 5/22/2019 at 2:54 AM, Flibble said:

You should have a button labelled "toggle torque" that can be used to disable the reaction wheels.

Thanks, that's what I was missing.

Quote

Even when you try to view it on YouTube?

I am able to view the video from May 21 now.

[Lookerksy]

Hi, Author. I wonder if you will add the support for Robotics parts of DLC "Breaking Ground Expansion"? Thanks.

Edited June 1, 2019 by Lookerksy

[Dunbaratu]

1 hour ago, Lookerksy said:

Hi, Author. I wonder if you will add the support for Robotics parts of DLC "Breaking Ground Expansion"? Thanks.

I am still working through the DLC as a *player* and haven't gotten to the robotic parts yet.  I'm trying to learn it piecemeal via a career (not sandbox) so I can also see how the contracts and experiments work.

I plan to support it - but first I have to learn it as a player.

 

[kcs123]

3 minutes ago, Steven Mading said:

I am still working through the DLC as a *player* and haven't gotten to the robotic parts yet.  I'm trying to learn it piecemeal via a career (not sandbox) so I can also see how the contracts and experiments work.

I plan to support it - but first I have to learn it as a player.

 

I know that you also like to play with Unkerballed start mod. I have wrote MM patches for that tech tree and moved around slightly BG parts to better accomodate that tech tree. Based on personal feeling how it should be placed. I have left info about it in Unkerballed start forum, ify ou are interested.

[Omann]

I'm looking for a way to interrogate a part to see what it requires.

More to the point, I want to be able to identify which engines require oxidizer and which do not. I have a working script for launching an SSTO that selects the engines to activate based on the altitude. I'm currently using the part name, but would like to swap engines models without the need to edit the script.

Interrogating the part for resources it supplies is simple, however the engines typically require resources rather than supply them. I'm guessing I would have to query an engine module probably.

[Flibble]

3 hours ago, Omann said:

I'm looking for a way to interrogate a part to see what it requires.

More to the point, I want to be able to identify which engines require oxidizer and which do not. I have a working script for launching an SSTO that selects the engines to activate based on the altitude. I'm currently using the part name, but would like to swap engines models without the need to edit the script.

Interrogating the part for resources it supplies is simple, however the engines typically require resources rather than supply them. I'm guessing I would have to query an engine module probably.

You could infer it from Isp - if it's over say 1000 then it's an air breathing engine. There isn't a way to check directly at present though.

[Omann]

4 hours ago, Flibble said:

You could infer it from Isp - if it's over say 1000 then it's an air breathing engine. There isn't a way to check directly at present though.

Pretty good idea. I can't think of a case where that wouldn't work.

[jefferyharrell]

I have a wacky request: Would it be possible to add the ability to open a kOS window in, say, the Space Center or Tracking Station scenes?

I'm asking because lately I've been having fun making kOS talk to Kerbal Alarm Clock. For instance, it's pretty trivial to write a script that takes a target orbit inclination and longitude of the ascending node and kicks out a KAC alarm for the launch window corresponding to that target orbit. The way kOS works makes this slightly awkward, though, since I have to roll a vehicle out to the launch pad, run the script, then recover the vessel. I could have my script time warp to the launch opportunity from the pad, but sometimes I want to just set up a series of alarms and go do other things while in-game time passes.

I know the central conceit of kOS is that you're actually talking to a computer that's physically on the vehicle. But at the same time, there's this idea of the "archive" volume which notionally exists "on the mainframe" at the space center. It's not that much of a leap to imagine having a terminal connected directly to that mainframe.

I know this is a big ask. I haven't looked at the source code but I'd guess that kOS is set up to run as a PartModule, which obviously only exists when there's a vessel loaded. It might not even be possible to make it work in anything other than the flight scene, but I thought I'd ask.

I sincerely apologize if this has been asked before. There's 37 pages here, and I confess I didn't read every word of every page.

[Dunbaratu]

2 minutes ago, jefferyharrell said:

I'd guess that kOS is set up to run as a PartModule, which obviously only exists when there's a vessel loaded.

Yes.  You nailed it precisely.  That's why it's not doing anything in the editor.
That being said, SOME of what a PartModule can do is available in the editor, otherwise you wouldn't be able to do things like adjust wheel friction sliders, or change parachute deploy altitudes in the VAB.

But much of what kOS does requires the assumption that it's attached to a vessel which really "exists" and thus has an apoapsis, a periapsis, a velocity, etc.  The vessel you build in the VAB is a Proto Vessel until it's launched, and is thus missing a lot of the usual data kOS tries to query.

Hypothetically it could be possible for kOS to go through and flag *everything* that requires the vessel be real and somehow protect around it with a check, but it would be a LOT of work to add that support when it wasn't designed in from the start.

[jefferyharrell]

@Steven Mading Yup, makes perfect sense. Thanks for the quick response.

[Flibble]

As an alternative, you could just park a rover with a solar panel somewhere in KSC then switch to it each time you want to add alarms, rather than needing to launch and recover.

[scimas]

@jefferyharrell if I understand what you're trying do correctly, you could possibly achieve it with a combination of krpc and kOS. Manage your broader space program with krpc (like setting up KAC alarms and missions from the KSC without loading a rocket) and then use kOS for the actual rocket flying. 

[KnedlikMCPE]

Hello,

i have been learning kOS a while now, and i can’t figure out some things. I’ve made a launch and booster sep script not controling the rocket itself. I need two things: 1. How can i get the rocket to follow prograde marker? 2. How can i trigger action groups through kOS?

[delta wee]

I'm trying to control the pitch of my plane with kOS, and am running into trouble when trying to change the pitch via user input to the terminal while the script is running. First I lock the steering to the "goalPitch" variable:

SET goalPitch TO 0.7.
LOCK STEERING TO HEADING(90, goalPitch).

Later on in the script I'm trying to change the "goalPitch" by pressing keyboard buttons into the terminal. Here is what I tried to achieve this:

SET tuneRatio TO 1.1.
IF TERMINAL:INPUT:HASCHAR() {
    set inputChar to TERMINAL:INPUT:GETCHAR().
    
    IF inputChar = "7" {
        SET goalPitch TO goalPitch / tuneRatio.
        print "goalPitch = " + goalPitch.
    }
    IF inputChar = "8" {
        SET goalPitch TO goalPitch * tuneRatio.
        print "goalPitch = " + goalPitch.
    }    
}

When I press "7" or "8" the "goalPitch" is printed to the terminal, but it only seems to change once, for example if I press "8" repeatedly the "goalPitch" seems to only go to 0.77 and stay there. Is there something I'm not understanding about locking steering to a variable?

[TBenz]

1 hour ago, KnedlikMCPE said:

Hello,

i have been learning kOS a while now, and i can’t figure out some things. I’ve made a launch and booster sep script not controling the rocket itself. I need two things: 1. How can i get the rocket to follow prograde marker? 2. How can i trigger action groups through kOS?

1.

LOCK STEERING TO PROGRADE.

2. Stock Action Groups

 

1 hour ago, delta wee said:

I'm trying to control the pitch of my plane with kOS, and am running into trouble when trying to change the pitch via user input to the terminal while the script is running. First I lock the steering to the "goalPitch" variable:

[snip]

Later on in the script I'm trying to change the "goalPitch" by pressing keyboard buttons into the terminal. Here is what I tried to achieve this:

[snip]

When I press "7" or "8" the "goalPitch" is printed to the terminal, but it only seems to change once, for example if I press "8" repeatedly the "goalPitch" seems to only go to 0.77 and stay there. Is there something I'm not understanding about locking steering to a variable?

Just to verify, the goalPitch is being printed to the terminal every time? As far as I'm aware, locking steering to a variable should work with updates to the variable (but I only really started using kOS yesterday...) It may be a bit of a brain dead fix, but you could see if adding another "LOCK STEERING TO HEADING(90, goalPitch)." to the end of the main IF statement forces the steering to update properly. 

Edited June 15, 2019 by TBenz
updated link

[Flibble]

2 hours ago, delta wee said:

When I press "7" or "8" the "goalPitch" is printed to the terminal, but it only seems to change once, for example if I press "8" repeatedly the "goalPitch" seems to only go to 0.77 and stay there. Is there something I'm not understanding about locking steering to a variable? 

If you're only getting one print, or is printing the same thing then there's something else broken in your script rather than the lock steering being broken.

[delta wee]

1 hour ago, Flibble said:

If you're only getting one print, or is printing the same thing then there's something else broken in your script rather than the lock steering being broken.

Yep, it was a problem in my script, I was resetting "goalPitch" to .7 every time in the loop .