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

[Inspierio]

On 5/25/2018 at 9:09 PM, ElWanderer said:

Alternatively, you could tag the engine(s) in the VAB and look for just parts with that tag in your code.

How can I do that?

I've tried giving a nametag and calling it but it refuses to work

[ElWanderer]

1 hour ago, Inspierio said:

How can I do that?

I've tried giving a nametag and calling it but it refuses to work

How are you "calling" it? Are you using the syntax from the kOS docs (bearing in mind that you get a list of parts from SHIP:PARTSTAGGED, so have to iterate) e.g.

SET allSuchParts TO SHIP:PARTSTAGGED("my nametag here").

// Followed by using the list returned:

FOR onePart IN allSuchParts {

// do something with onePart here.

}

Copied from:

https://ksp-kos.github.io/KOS/general/nametag.html#examples-of-using-the-name

[jbakes]

Hey guys so I'm trying to write a simple hover script. My main problem is that I need a way to turn off the thrust if the ship starts increasing in altitude and then turn back on when it starts to decrease again. I have my steering locked to velocity:surface*-1 so whenever it starts to increase in altitude it starts flipping around but if I could turn off the throttle till it starts falling again then it would fix the problem.

if ship:surface:velocity:vector < 1 

lock thrott to 1.

if ship:surface:velocity:vector > 1 

lock thrott to 0

Basically something like that. Is there any code that can tell if my ship velocity is negative or positive?

 

Edited June 12, 2018 by jbakes

[kcs123]

54 minutes ago, jbakes said:

Hey guys so I'm trying to write a simple hover script. My main problem is that I need a way to turn off the thrust if the ship starts increasing in altitude and then turn back on when it starts to decrease again. I have my steering locked to velocity:surface*-1 so whenever it starts to increase in altitude it starts flipping around but if I could turn off the throttle till it starts falling again then it would fix the problem.

For hovering do not lock steering anything related to velocity vector. Use rather some fixed direction, like this:

set MyDirection to HEADING(MyHeading,90).

Where "MyHeading" in this case is set elsewhere trough GUI in code. You may also sometimes want to not lock steering at all, leaving kOS script only to handle throttle trough PID and you steer craft trough manual input controls. Works nice for semi-auto VTOL crafts, like helicopter or similar.

Also, you don't need to lock throttle either, you can use "set" command instead. If you put wait command inside PID calculating loop, like 0.2 - 0.5 sec, or similar, it will give you enough time frame window to interupt throttle input by pressing Z or X keys for max or min throttle for short time until next PID delta time comes to calculate and set throttle value.
That can be enough to save craft for crashing if PID is not adjusted yet properly and react too fast or too slow.

In case of powered landing phase, instead of howering, you may want to calculate angles between prograde vector and vertical vector and then deceide if it is better to steer toward retrograde (to bleed out ground speed at same time) or it is better and safer to point ship vertical with 90 degree pitch.

I use this piece of code in my landing script for such purpose:

set GroundAngle to round(VANG(SHIP:FACING:VECTOR,(-1)*SHIP:VELOCITY:SURFACE),2).
		set UpAngle to round(VANG(SHIP:FACING:VECTOR,HEADING(MyHeading,90):VECTOR),2).
		set SteerAngle to round(VANG(HEADING(MyHeading,90):VECTOR,(-1)*SHIP:VELOCITY:SURFACE),2).
		
		if (UpAngle < 10) and (GroundAngle < 10) and (SteerAngle < 10) and (ship:verticalspeed <0) // aditional check that craft fall down
		{
			set MyDirection to ((-1) * SHIP:VELOCITY:SURFACE) + R(0,0,0).
			set output to "Vertical retrograde descend".
			DisplayBlock:call(output).
		}
		else
		{
			set MyDirection to HEADING(MyHeading,90).
			set output to "Vertical normal descend".
			DisplayBlock:call(output).
		}.
		lock STEERING to MyDirection.

 

It is not full script, but I hope that is understandable enough.

[jbakes]

5 minutes ago, kcs123 said:

 

I have't learned PID controllers and Vectors yet. I've taken calc 1-3 so I understand the math just not the koS code. I was going to look into those next but for now all I'm doing is getting a craft vertical to 500m and then falling back down and landing but I want the throttle to turn off when it altitude starts increasing and turn back on when it starts decreasing again.

[scimas]

1 hour ago, jbakes said:

Is there any code that can tell if my ship velocity is negative or positive?

SHIP:VERTICALSPEED

[jbakes]

32 minutes ago, scimas said:

SHIP:VERTICALSPEED

I thought I tried that but thanks it works!

[infinite_monkey]

Can anyone suggest a good algorithm for controlled descending speede while going sideways as well? My Falcon9-like landing script works fine if I descend slowly (16 m/s) for the last 500 m or so, but that consumes a huge load of fuel. Descending faster also also needs my horizontal steering to change faster, but my rocket can't turn that fast. Should I use something like a 2-dimensional PID for steering? What would my set point be?

I also find it hard to get the correct moment of reverse my steering: at higher speeds, i point my engine to a multiple of my impact point mirrored at the target (not quite mathematically correct explanation, but I hope you understand what I mean). But as the speed drops and I come closer to hovering, I have to point the engine in the opposite direction. Currently, I'm doing that when my vertical speed is below 180 m/s and thrust is over 0.5, but these are just arbitrary numbers that I found via trial and error.

[Kartoffelkuchen]

Automated Airplane Landing Script v4

 

Compared to the last video and versions, I highly improved the script. It now lines up much better with the runway, I optimized the final approach as well as completely reworked the pitch holding logic, no more oscillations or too late corrections.
As you can see, in the first clip the plane has to do a rather extreme approach, coming in far from the north with only a short time to line up with the runway, but it manages just fine, except for landing a little too far off the centerline, but with a more "normal", less aggressive approach, the plane would have landed just fine on the centerline.
It still needs some work, especially in regard to landing on runways which are not exactly 90°, but this is not too big of a deal to do any more. Also, quite a lot of optimization can be done I think, the code is already quite "clean", but there are some parts which can be highly optimized to allow the program to have a higher tick rate. You can see the time the program needs for one "cycle" at the bottom of the kOS interface, usually the time is around 0.4s in landing mode but might increase under certain circumstances to 0.76s.
This is not too big of a problem, but it is always a good idea to optimize whereever you can.

However, it is coming together really nicely, what do you think?

 

On 6/13/2018 at 11:35 AM, infinite_monkey said:

Can anyone suggest a good algorithm for controlled descending speede while going sideways as well? My Falcon9-like landing script works fine if I descend slowly (16 m/s) for the last 500 m or so, but that consumes a huge load of fuel. Descending faster also also needs my horizontal steering to change faster, but my rocket can't turn that fast. Should I use something like a 2-dimensional PID for steering? What would my set point be?

I also find it hard to get the correct moment of reverse my steering: at higher speeds, i point my engine to a multiple of my impact point mirrored at the target (not quite mathematically correct explanation, but I hope you understand what I mean). But as the speed drops and I come closer to hovering, I have to point the engine in the opposite direction. Currently, I'm doing that when my vertical speed is below 180 m/s and thrust is over 0.5, but these are just arbitrary numbers that I found via trial and error.

@infinite_monkey I totally understand your problem, been there myself when I worked on my script.

As for the "reverse steering" problem, it all depends on the drag / lift created by the vessel at different speeds, really hard to calculate if you don't know the exact dimensions of the ship. I've also just had a number, above the number the steering would be reversed, below it it would point towards the target. Check this video for example, I've got a couple more on my channel as well.

 

 

 

Edited June 17, 2018 by Kartoffelkuchen

[MaltYebisu]

I'm having problems with a boot script that is supposed to copy a script from 0:/ to 1:/, run the script, and delete it when I press an action group. I intended to have this boot script running while I make small changes to the script file and save the changes. And whenever I press the action group, it should load the script and run it.However, the boot script does not copy the newly saved script file. It just "copies" the original script. Is this a limitation of kOS or am I doing something wrong?

Boot script:

//Testing Computer Bootscript 0.2

clearscreen.
core:part:getmodule("kOSProcessor"):doevent("Open Terminal").
print "Testing Computer Bootscript 0.2".
print " ".
print "Press Actiongroup 1 To load Test".
on ag1 {
  print " ".
  copypath("0:/test.ks", "1:/test.ks").
  print "Copied Test Script".
  wait 1.
  print "Running Test Script".
  print " ".
  runpath("1:/test.ks").
  print " ".
  wait 1.
  deletepath("1:/test.ks").
  print "Deleted Test Script".
  print " ".
  print "Press Actiongroup 1 To load Test".
  return true.
}
wait until false.

Original script:

print "===============".
print " Test number 1 ".
print "===============".

Edited and saved script:

print "===============".
print " Test number 2 ".
print "===============".

Spoiler

As you can see, the boot script does not update the saved changes. If I end the boot script and copy and run manually, the saved script works as intended.

I'm not sure if this applies, but here is the usual information:

Spoiler

Mods:

- AdvancedJetEngine v2.10.0

- AGExt 2.3.2.3

- ATKPropulsionPack 3.1

- B9_Aerospace_ProceduralWings 0.40.13

- B9PartSwitch v2.1.1

- BackgroundResources v0.13.6.0

- Chatterer 0.9.93

- ChattererExtended 0.6.2

- ClickThroughBlocker 0.1.2

- CommunityResourcePack 0.8.1.0

- ConnectedLivingSpace 1.2.6.2

- ContractConfigurator 1.23.3

- CrowdSourcedFlags 1.55.5

- CustomBarnKit 1.1.16.0

- DeadlyReentry v7.6.2

- DistantObject v1.9.1

- DistantObject-RealSolarSystem v1.9.1

- DMagicOrbitalScience 1.3.11

- DMagicScienceAnimate v0.19

- EarlyBird 

- EditorExtensionsRedux 3.3.16

- EngineLight 

- FASA 1:v7.2.2

- FerramAerospaceResearch 3:0.15.9.1

- FinalFrontier 1.3.6-3189

- FirespitterCore v7.6.0

- FirespitterResourcesConfig v7.6.0

- FreedomTex 1:v1.5.1.0

- FuseBoxContinued 0.1.15.4

- HangerExtenderExtended 3.5.2

- HaystackReContinued 0.5.3

- HazardTanksTextures 1.0

- JanitorsCloset 0.3.3

- KaptainsLog 0.1.4

- KerbalAlarmClock v3.8.5.0

- KerbalConstructionTime 1.3.9

- KerbalEngineerRedux 1.1.3.0

- KerbalJointReinforcement v3.3.3

- Kopernicus 2:release-1.3.1-7

- kOS 1:1.1.5.0

- KSCSwitcher 1.4.3.0

- KSP-AVC 1.1.6.2

- LaserDist v1.0.1

- LSPFlags v2.1

- MagiCore 1.3.1

- MainSailorTextures-Complete 2.0.0.0.1

- MainSailorTextures-Essentials 2.0.0.0.1

- ModularFlightIntegrator 1.2.4.0

- ModuleManager 3.0.4

- PersistentRotation 1.8.4

- PlanetShine 0.2.5.3

- PlanetShine-Config-Default 0.2.5.3

- PoodsMilkyWaySkybox v1.2.0

- ProceduralFairings v4.0

- ProceduralParts v1.2.15

- ProceduralParts-Textures-SaturnNova 1.2

- ProceduralParts-Textures-SCCKSCS 1

- ProgressParser 8.0

- QuickMute v1.30

- RasterPropMonitor 1:v0.29.3

- RasterPropMonitor-Core 1:v0.29.3

- RCSBuildAidCont 0.9.5.1

- RCSSounds 5.2

- RealChute v1.4.5

- RealFuels rf-v12.6.0

- RealHeat v4.5

- RealismOverhaul v12.1.0

- RealPlume 2:v11.0.0

- RealSolarSystem v13.1.0

- ReentryParticleEffect 1.2a

- RemoteTech 1.8.11.131

- RetractableLiftingSurface 0.1.5

- RP0 (dev)

- RSSDateTimeFormatter 1.4.3.0

- RSSTextures2048 v13.1

- SCANsat v18.4

- ShipManifest 5.2.0.0

- ShowAllFuelsContinued 1.3.1

- SigmaReplacements-SkyBox B_v0.2.2

- SmokeScreen 2.7.6.1

- SolverEngines v3.5

- SovietEnginePack 0.4

- SXTContinued 1:0.3.23.1

- TACLS v0.13.6.0

- Taerobee 1:3.0

- TestFlight (dev)

- TextureReplacerReplaced V0.5.4

- Toolbar 1.7.16.5

- ToolbarController 1:0.1.4.7

- TransferWindowPlanner v1.6.2.0

- VensStylePPTextures 1.1

- VenStockRevamp v1.9.6

- WildBlueTools 1.41.0

 

Player.log

[kcs123]

Haven't messed with kOS for a while, but you should check out if some file exist before attempt to copy new one. Also issue might be using such thing within trigger. I no longer recall details, but you should not use wait command inside of "On AG1" trigger. Either, try to separate commands that copy script and command that delete script to different AG group. Or you can use something like this:

if not exists("1:/test.ks")
{
	copypath("0:/test.ks","1:/test.ks").
}else
{
	deletepath("1:/test.ks").
	copypath("0:/test.ks","1:/test.ks").
}.

 

[Kartoffelkuchen]

Ok, got a problem here.

I have a list of coordinates for some 'waypoints' for my script (not like a real waypoint, but just as of a variable with latlng), now I'd like to visualize their position.

I basically only have the latitude and longitude of the 'waypoint' and for some a minimum altitude at which it needs to be passed. How would I go about visualizing them in the game itself? I know you can draw vectors on the screen, but how would I create a drawn vector with only the given coordinates and maybe a minimum altitude? The direction would be "up" for each vector, so each vector should point straight up relative to the surface with a given length. I want it to look a bit like these vectors from FSX:

 

 

Edited June 19, 2018 by Kartoffelkuchen

[Pand5461]

13 hours ago, MaltYebisu said:

It just "copies" the original script. Is this a limitation of kOS or am I doing something wrong?

I have a similar script, and that works as expected - i.e. it overwrites the file in "1:/" by the edited file.

So, are you sure you actually saved the file in the Ships/Script folder before calling AG1 in game? (I do forget doing that sometimes).

I suggest that you debug print open("0:/test.ks"):readall:string.

2 hours ago, Kartoffelkuchen said:

how would I create a drawn vector with only the given coordinates and maybe a minimum altitude

One way off the top of my head:

set wpmarker to vecdraw().
set markerlength to 150. // arrow length in meters
set markerendalt to 0. // end of the arrow AGL altitude in meters.
set markerwidth to 10. // arrow width 
set wpmarker:show to True.
set wpmarker:startupdater to { return wpcoord:altitudeposition(wpcoord:terrainheight + markerendalt + markerlength). }.
set wpmarker:vecupdater to { return wpcoord:altitudeposition(wpcoord:terrainheight + markerendalt) - wpcoord:altitudeposition(wpcoord:terrainheight + markerendalt + markerlength). }.
set wpmarker:width to markerwidth.

WPCOORD is the GeoCoordinates of your waypoint.

The vector will be pointing to the ground if MARKERLENGTH is positive, and to the sky if it's negative.

(some assembly may be required, I did not test the code)

[ElWanderer]

@MaltYebisu

Spoiler

Spoiler

Posting on a mobile, can't get rid of these

 

I know that when I first started using kOS, when you did "RUN X" twice in a row (without rebooting in between), you'd get the same results even if you'd changed the contents of X in the meantime. It's as if the file is cached when the run command is issued. From memory, there was a technical explanation about how files are parsed and their symbols stored when run, but I can't remember the details.

It's entirely possible that's still the case. One way around it is to vary the name of the file e.g. by appending a counter. That said, I'd echo @Pand5461's advice of checking the actual file contents first.

[MaltYebisu]

Thank you all for the response.

I know I saved and changed the script file in the script folder, and I have also tried it a couple of times with different scrips and got the same result. 

On 6/20/2018 at 1:58 AM, kcs123 said:

Haven't messed with kOS for a while, but you should check out if some file exist before attempt to copy new one. Also issue might be using such thing within trigger. I no longer recall details, but you should not use wait command inside of "On AG1" trigger. Either, try to separate commands that copy script and command that delete script to different AG group. Or you can use something like this:

if not exists("1:/test.ks")
{
	copypath("0:/test.ks","1:/test.ks").
}else
{
	deletepath("1:/test.ks").
	copypath("0:/test.ks","1:/test.ks").
}.

 

Thank you, I tried that and it didn't change the result.

On 6/20/2018 at 4:43 AM, Pand5461 said:

I suggest that you debug print open("0:/test.ks"):readall:string.

Thank you, I tried to insert the debug line. And it also doesn't update when I save the edits to the script.

On 6/20/2018 at 5:51 PM, ElWanderer said:

I know that when I first started using kOS, when you did "RUN X" twice in a row (without rebooting in between), you'd get the same results even if you'd changed the contents of X in the meantime. It's as if the file is cached when the run command is issued. From memory, there was a technical explanation about how files are parsed and their symbols stored when run, but I can't remember the details.

It's entirely possible that's still the case. One way around it is to vary the name of the file e.g. by appending a counter. That said, I'd echo @Pand5461's advice of checking the actual file contents first.

It looks like this might be the case still then. I guess I would have to do something with rebooting or changing filenames to make my script tester. 

[fitemesquirrel]

Hello,

 

I was just wondering how kOS detects the addons such as Infernal Robotics? I have IR Next installed, and I was looking to make a script to automate the position of a solar panel on a robotic hinge, but I'm not getting IR detected in my installation. 

 

print addons:available("ir").         
False

print addons:IR:allservos.
'IR:ALLSERVOS' command requires Infernal Robotics addon to be available.
__________________________________________
           VERBOSE DESCRIPTION
It seems you tried calling a function or suffix
that relies on the availability of a certain mod installed.
You can check the availability of addons via 'addons' global,
for example 'addons:rt:available' returns true if RemoteTech is present.
__________________________________________
__________________________________________
At interpreter, line 42
print addons:IR:allservos.

 

I went poking around in the mod to see if this was some kind of script or something I could tweak to make this work, but I didn't find anything. Is this in the C# code that this detection happens?

[kcs123]

6 hours ago, fitemesquirrel said:

I was just wondering how kOS detects the addons such as Infernal Robotics? I have IR Next installed, and I was looking to make a script to automate the position of a solar panel on a robotic hinge, but I'm not getting IR detected in my installation. 

IIRC, there is small piece of code in IR plugin that makes kOS aware of IR being installed. But, please note that IR next is almost entierly different plugin (code wise) regardless looking the same and have same functionality. Also IR next use different module name for parts in config files (module that allow parts to move). So, bring that issue in IR next developing thread, when other issues are solved, that one too will come on "to do" list too.

[wowKerbal]

It would be great if there was a way to have "helper" functions that you can get usually from the stock map view, like AN/DN nodes, their eta, closest approach, etc. I know they can be derived with code but being that they are already available in the map view, I guess they could be easily read by kOs? Any chance this functionality will be implemented?

On a different note, I am using kOs to play mission control style multiplayer with friends, and I was wondering if there is a way to disable telnet access and volume 0 when the vessel has no signal?

Edited June 26, 2018 by wowKerbal

[fitemesquirrel]

So, I'm using kOS with KSP 1.4.4. Is it normal for the cooked steering to make absolutely no sense and not work at all? I've been trying to implement some simple steering scripts, but it's not responding at all how I expect, and indeed even something basic like "Lock steering to North." does NOT point the craft at north. Or heading(90,10) does NOT point it at 90deg at a 10deg over horizon. I can't even figure out what directing its trying to head, it just spins in circles, usually trying to go straight UP and yawed hard to the side. I tried to help it along by pointed it near north, and then locking steering to North, and it started turning it back towards south. I'm just completely confused as to what I'm doing wrong. None of the example code in the docs work as they say they do. 

[Dunbaratu]

3 hours ago, fitemesquirrel said:

So, I'm using kOS with KSP 1.4.4. Is it normal for the cooked steering to make absolutely no sense and not work at all? I've been trying to implement some simple steering scripts, but it's not responding at all how I expect, and indeed even something basic like "Lock steering to North." does NOT point the craft at north. Or heading(90,10) does NOT point it at 90deg at a 10deg over horizon. I can't even figure out what directing its trying to head, it just spins in circles, usually trying to go straight UP and yawed hard to the side. I tried to help it along by pointed it near north, and then locking steering to North, and it started turning it back towards south. I'm just completely confused as to what I'm doing wrong. None of the example code in the docs work as they say they do. 

Do you have SAS on?

You can either steer with SAS or steer with LOCK STEERING.  Not both.  They fight each other.

[fitemesquirrel]

2 minutes ago, Steven Mading said:

Do you have SAS on?

You can either steer with SAS or steer with LOCK STEERING.  Not both.  They fight each other.

Nope. I read the warnings in the docs. This is completely pilot-control. None of the examples for Cooked Control in the docs work for me at all. Just wondering if I'm doing something wrong, or if this is normal.

[Dunbaratu]

26 minutes ago, fitemesquirrel said:

Nope. I read the warnings in the docs. This is completely pilot-control. None of the examples for Cooked Control in the docs work for me at all. Just wondering if I'm doing something wrong, or if this is normal.

No idea.  The probe core isn't upside down is it?  You mentioned it aiming south when trying to point it north.

[fitemesquirrel]

3 minutes ago, Steven Mading said:

No idea.  The probe core isn't upside down is it?  You mentioned it aiming south when trying to point it north.

I attached this to a plane, basic first jet engines. Mk1 Cockpit, CX-4181 unit right behind it. The lettering on the part looks like it's facing the right way? I don't know what direction these kOS units have to be, or even that they had an orientation. I just selected the part when building my plane and attached it to my cockpit part. 

[Dunbaratu]

2 minutes ago, fitemesquirrel said:

I attached this to a plane, basic first jet engines. Mk1 Cockpit, CX-4181 unit right behind it. The lettering on the part looks like it's facing the right way? I don't know what direction these kOS units have to be, or even that they had an orientation. I just selected the part when building my plane and attached it to my cockpit part. 

You didn't say it was an airplane.  That's highly relevant.

The cooked steering is optimized for rocketry.  i.e. you want to turn left? Then just yaw left.  But planes aren't like that.  if you try to turn left by just hamfistedly yawing left, the plane starts to roll funny.  The stock steering system in kOS doesn't understand how planes need to bank to turn, not yaw to turn.  You can use kOS for an airplane, but you'll have to design your own steering algorithm and take control of the controls directly with your script (i.e. set ship:control:roll to -0.1. that sort of thing.)  The built-in "training wheels" of cooked control assume you don't have to bank to turn, and you can wait till you're pointing the right way before bothering to adjust the roll axis.

 

[fitemesquirrel]

1 minute ago, Steven Mading said:

You didn't say it was an airplane.  That's highly relevant.

The cooked steering is optimized for rocketry.  i.e. you want to turn left? Then just yaw left.  But planes aren't like that.  if you try to turn left by just hamfistedly yawing left, the plane starts to roll funny.  The stock steering system in kOS doesn't understand how planes need to bank to turn, not yaw to turn.  You can use kOS for an airplane, but you'll have to design your own steering algorithm and take control of the controls directly with your script (i.e. set ship:control:roll to -0.1. that sort of thing.)  The built-in "training wheels" of cooked control assume you don't have to bank to turn, and you can wait till you're pointing the right way before bothering to adjust the roll axis.

 

 

Ahhhhh. Okay, that makes a lot of sense considering what I was seeing. I didn't notice anything in the docs saying that so I didn't realize. I'll work with the raw and pilot control systems then. Thanks!