Jump to content

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

Dunbaratu

By Dunbaratu
in KSP1 Mod Releases

 Share

Recommended Posts

Dunbaratu

Dunbaratu

Posted
  • Author
Posted (edited)

The problem @DerGnom described persisted even with a probe core present.

These are slightly different:

(A) Manned capsule is present, but probe core is not.

(B) Manned capsule is present, and Probe core is present, but signal is not.

danielboro, You're talking about (A), and DerGnom's post is about (B).  Niether (A) nor (B) should prevent local control, so making local control work right would fix both situations, but they're slightly different.  (A) is troubling because if the problem was merely signal, (A) should have only intermittent failure to work (it should work when there's signal and only fail when there's not).  With (A), it appears that even when there's a signal that can reach the vessel, RT doesn't seem to be reporting this when kOS queries it for signal path, unless you also add an (otherwise unnecessary) probe core.  That's a *different* bug that would still need looking into possibly, even if manual control is fixed.

Edited by Steven Mading
Link to comment
Share on other sites
DerGnom

DerGnom

Posted
Posted
  On 10/6/2017 at 3:52 AM, luizopiloto said:

Is someone else having KSP 1.3.1 crash during load when using kOS 1.1.3.0?

Expand  

Yes. 

The KOS plugins need to be recompiled for the new (1.3.1) Version of KSP. If you would like to try, there is an instruction on the KOS github page (under "setting up your environment"):

https://github.com/KSP-KOS/KOS/blob/develop/CONTRIBUTING.md

Otherwise there will probably be a new release in some time.

 

 

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
  • Author
Posted
  On 10/6/2017 at 8:58 AM, DerGnom said:

Yes. 

The KOS plugins need to be recompiled for the new (1.3.1) Version of KSP. If you would like to try, there is an instruction on the KOS github page (under "setting up your environment"):

https://github.com/KSP-KOS/KOS/blob/develop/CONTRIBUTING.md

Otherwise there will probably be a new release in some time.

 

 

Expand  

It would be easy to fix if not for the fact that 1.3.1 happened at the same moment that we were trying to figure out the RT problem you found DerGnom.  I just ran some tests in which the code changes you suggested didn't fully fix the two similar but different bugs (and yes this confirms that they are two *different* bugs, danielboro, because what fixed one didn't fix the other).  Your fix makes it so that with both a manned capsule and a probe core present, but no signal, local control works.  But it still didn't fix the fact that a probe core is needed at all, in addition to a manned capsule, when it shouldn't be.  A manned capsule alone, with or without probe core, *and* with or without signal, should be sufficient and it doesn't seem to be.  Your fix fixed the signal problem, but not the probe core requirement problem.  I'm going to see if I can figure out why.

If I can't figure it out today, then we may end up having to punt on that and release a small update that just gives 1.3.1 compatibility and nothing else.  We can't leave 1.3.1 compatibility unsolved for too long.  Especially since 1.3.1 compatibility is trivially easy to fix and it would be a shame to hold that off too long waiting to fix a harder problem.

Link to comment
Share on other sites
DerGnom

DerGnom

Posted
Posted
  On 10/6/2017 at 11:22 AM, Steven Mading said:

But it still didn't fix the fact that a probe core is needed at all, in addition to a manned capsule, when it shouldn't be.  A manned capsule alone, with or without probe core, *and* with or without signal, should be sufficient and it doesn't seem to be.

Expand  

The fact that a probe core is (with or without local control) required comes from the implementation of the "HasConnectionToControl" method in the RemoteTech Connectivity manager. To change the behaviour of KOS to allow access to the terminal even without a probe core I tested the following change:

//Changed Implenentation that allows to access terminal when having no connection even without probe core being installed

public bool HasConnectionToControl(Vessel vessel)
{
            return RemoteTechHook.Instance.HasAnyConnection(vessel.id) || vessel.CurrentControlLevel >= Vessel.ControlLevel.PARTIAL_MANNED;        
}

 

In the current (KOS 1.1.3.0) implementation

public bool HasConnectionToControl(Vessel vessel)
{
            if (!RemoteTechHook.IsAvailable(vessel.id))
                return false; // default to no connection if the vessel isn't configured for RT.

            return RemoteTechHook.Instance.HasAnyConnection(vessel.id);        
}

the " || vessel.CurrentControlLevel >= Vessel.ControlLevel.PARTIAL_MANNED" statement was missing (adding this fixed the problem where you alway needed a connection even for a manned vessel).  Also the first If (...) requires that every vessel needs to have a RemoteTech probe core. Removing this statement allows you to access the terminal on manned vessels without probe cores.

Link to comment
Share on other sites
danielboro

danielboro

Posted
Posted (edited)
  On 10/5/2017 at 8:48 AM, Steven Mading said:

The problem @DerGnom described persisted even with a probe core present.

These are slightly different:

(A) Manned capsule is present, but probe core is not.

(B) Manned capsule is present, and Probe core is present, but signal is not.

danielboro, You're talking about (A), and DerGnom's post is about (B).  Niether (A) nor (B) should prevent local control, so making local control work right would fix both situations, but they're slightly different.  (A) is troubling because if the problem was merely signal, (A) should have only intermittent failure to work (it should work when there's signal and only fail when there's not).  With (A), it appears that even when there's a signal that can reach the vessel, RT doesn't seem to be reporting this when kOS queries it for signal path, unless you also add an (otherwise unnecessary) probe core.  That's a *different* bug that would still need looking into possibly, even if manual control is fixed.

Expand  

ignor me
i responded before reading the rest

edit 2: after reading
did i understand correctly

  On 10/6/2017 at 12:01 PM, DerGnom said:

the " || vessel.CurrentControlLevel >= Vessel.ControlLevel.PARTIAL_MANNED" statement was missing (adding this fixed the problem where you alway needed a connection even for a manned vessel).  Also the first If (...) requires that every vessel needs to have a RemoteTech probe core. Removing this statement allows you to access the terminal on manned vessels without probe cores.

Expand  


that my original understanding of the reason for the problem was correct? see croses out lins below

 

 

my analisis

kos:
if  "has a prob core connected to KSC" {can input} else {no signal}

the part of OR "has a kerbald  command pod" never worked
i see A and B as the same bug
in A and B having a kerbaled command pod has no effect on the ability to input commands in kos
 

if  "has a prob core connected to KSC" OR "has a kerbald  command pod" {can input} else {no signal}
this will fix A and B in 1 fix

 

Edited by danielboro
Link to comment
Share on other sites
Xandaros

Xandaros

Posted
Posted (edited)

Alright, I'm at my wits end.

 

Why does "lock steering to 0." just not do anything at all?

Relevant section: 

		when apoapsis > desiredHeight then {
			print "coast to apoapsis".
			getvoice(0):play(Note(400,0.2)).
			lock throttle to 0.
			wait 10.
			print "lock throttle to 0".
			lock throttle to 0.

 

It prints and beeps just fine, but keeps on thrusting like nothing happened...

 

Full script:

http://tcpst.net/7tfi

Edited by Xandaros
Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
  • Author
Posted
  On 10/12/2017 at 7:43 AM, Xandaros said:

Alright, I'm at my wits end.

 

Why does "lock steering to 0." just not do anything at all?

Relevant section: 

		when apoapsis > desiredHeight then {
			print "coast to apoapsis".
			getvoice(0):play(Note(400,0.2)).
			lock throttle to 0.
			wait 10.
			print "lock throttle to 0".
			lock throttle to 0.

 

It prints and beeps just fine, but keeps on thrusting like nothing happened...

 

Full script:

http://tcpst.net/7tfi

Expand  

Reading through your script I get the impression you might have misunderstood how WHEN works.  It appears you think it means this:

Wait until condition is true.  Once the condition becomes true, do the body.

But what it actually means is this:

*In the background*, keep checking again and again for the condition to become true.  In the meantime keep going past this statement and execute the rest of the program.  At some future point in time, when that condition becomes true, then interrupt what you're doing and run this body of code.

Anyway, what I'd recommend is that you go through *every* place in the code where it does a lock throttle to (anything) or an unlock throttle statement, and put a printing statement just before it that will identify that that's the line being executed.  (i.e. PRINT "lock throttle to 1 on line  123". - statements like that everywhere.)    It's possible that it locks throttle to 0 but then also locks it to something else at the same time and that overrides it.  With all those WHEN..THEN triggers active at once, and multiple ones of them touching the throttle, it's possible more than one are firing off at a time.

It's not enough to prove the lock throttle to 0 is happening when you think it is.  You *also* have to prove the other lock throttles and unlock throttles are *not* happening when you think they're not.  This is because if you use WHEN triggers like this, it's entirely possible for more than one of them to become true together and both of them to fire off back to back.

 

 

Link to comment
Share on other sites
DgD

DgD

Posted
Posted

my first try here Hi all :)

after recompilation to 1.3.1 game runs without crash yay :P

My next "discovery" ... documentation is mostly outdated

I wonder why the data about ship acceleration or gravity forces is deeply hidden when it is available 24/7 on navbal - no mather current sensor-parts set.

as a quickfix I did https://github.com/DamnGoodDevill/KOS/commit/8cd9179db57266baebf495dd63f14a511542986c

ugly place for code but it's just quickfix on old DOCs where I can replace every occurrence of SENSORS:ACC, SENSORS:GRAV with SENSORS:VESSACC and SENSORS:VESSGRAV

Prolly there is easier way of doing this in current api :)

I'm using kOS with RemoteTech (pretty obvious) , any plans to merge this 2 projects???

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
  • Author
Posted (edited)
  On 10/12/2017 at 5:58 PM, DgD said:

my first try here Hi all :)

after recompilation to 1.3.1 game runs without crash yay :P

My next "discovery" ... documentation is mostly outdated

I wonder why the data about ship acceleration or gravity forces is deeply hidden when it is available 24/7 on navbal - no mather current sensor-parts set.

as a quickfix I did https://github.com/DamnGoodDevill/KOS/commit/8cd9179db57266baebf495dd63f14a511542986c

ugly place for code but it's just quickfix on old DOCs where I can replace every occurrence of SENSORS:ACC, SENSORS:GRAV with SENSORS:VESSACC and SENSORS:VESSGRAV

Prolly there is easier way of doing this in current api :)

I'm using kOS with RemoteTech (pretty obvious) , any plans to merge this 2 projects???

Expand  

"Mostly outdated?"  "Mostly" is a large claim.  More than 50%?

Where is acceleration on the navball?  Where is gravity as a separate value independent of any thrusting on the navball?  What is on the navball is speed and direction, which are both available from the vessel's velocity suffix, and a directionless "g" force as a scalar, with no vector info about which way it's pointed.  The claim that the info you added is available from the navball just isn't true.

"but it's just quickfix on old DOCs" -> the change you linked to doesn't touch the docs.  I don't understand what this means.

Edited by Steven Mading
Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
  • Author
Posted

@Xandaros - I'm trying your code and there's definitely something wrong going on here.  I'm trying to work out what it is.  Note, it's important to see that the throttle isn't going back up to full (1.0).  It's going back to a value that's nearly full but not quite (about 0.86 or so), that indicates it's none of the `lock steering to 1` that's doing it - it's reverting to the original lock steering to 1.7/twr formula for some reason.

 

Link to comment
Share on other sites
Xandaros

Xandaros

Posted
Posted (edited)
  On 10/12/2017 at 11:09 PM, Steven Mading said:

@Xandaros - I'm trying your code and there's definitely something wrong going on here.  I'm trying to work out what it is.  Note, it's important to see that the throttle isn't going back up to full (1.0).  It's going back to a value that's nearly full but not quite (about 0.86 or so), that indicates it's none of the `lock steering to 1` that's doing it - it's reverting to the original lock steering to 1.7/twr formula for some reason.

Expand  

@Steven Mading Yes, it's weird.

Also, I have to defend myself here a bit. I understand how when works :P

There is also only ever two triggers active at once (they are nested) and at the point where this problem occurs, there should not be any other active trigger. Even if there was, there is a large wait after the throttle change. Since other triggers cannot activate while a trigger is being executed, this should be fine.

You did make a great point though and I should probably move most of that code into the mainline and use "wait until" instead. This is my first script, so I don't mind some suggestions for how to improve the general style.

 

Edit: I changed all the chained triggers to "wait until" and now it works. I still maintain that my original script should work, though.

Edited by Xandaros
Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
  • Author
Posted (edited)
  On 10/12/2017 at 11:12 PM, Xandaros said:

Edit: I changed all the chained triggers to "wait until" and now it works. I still maintain that my original script should work, though.

Expand  

I've had a look through it and I agree.  The strange thing is that everything I looked at so far in my debugging indicates it *should* be working.  The throttle lock *has* been altered to the version that returns a hardcoded zero, but the system is ignoring that for some reason.

Also, it doesn't happen when I make a simpler example case.  I tried figuring out if the nested triggers were broken but when I mimic what you did but with simpler conditions... the bug doesn't happen.  It only happens with that *specific* program and I'm still trying to figure out why.

 

EDIT: I found the condition that triggers it.  Here is a much much simpler program that demonstrates the problem case - any changes you make to LOCK STEERING or LOCK THROTTLE while inside a trigger body *will* take effect, but not until the trigger body finishes: 

// Run this on a ship on the launchpad which has NOT
// had it's engines activated - that way you can just
// look at the throttle indicator and watch it move
// harmlessly without actually taking off:

lock throttle to 0.75.
wait 0.
print "Throttle now moved to the 0.75 position.".


print "Please wait, a trigger will happen at T+5 seconds.".
set startTime to time:seconds.
when time:seconds > startTime + 5 then {
  print "5 second trigger invoked.".

  lock throttle to 0.25.
  wait 0.
  print "Throttle has been locked to 0.25 position.".
  print "But it doesn't move yet.".
  print "It's stuck at its prev value until this trigger body is over.".

  for i in range (10,0) {
    print "Ending trigger body in " + i + " seconds.".
    wait 1.
  }

  print "NOW it will move, as this trigger expires.".
  print "(You can hit control-C now to end the test.)".
}

wait until false.  // stuck here until ctrl-C.

In your example program, the WHEN's body had a warpto() command which kept it from finishing until the warp time was over, which in turn kept the throttle from ever changing.

 

I'm not sure the problem is easy to fix, though.  It's complex to explain why, but basically the part of the system that calls your throttle expression (the expression inside your lock) is *itself* a trigger, so it won't fire off until your existing trigger finishes.  In general it's a bad idea to use triggers to do anything that lasts a long time.  They're meant to be interrupts.

I don't know if I can get around to fixing this soon, but I recorded my thoughts on it in This github issue.

 

Edited by Steven Mading
Link to comment
Share on other sites
DgD

DgD

Posted
Posted (edited)

@Steven Mading Thx for lesson what is where and why... I'm not rocket science expert ... my understanding of newtons laws covered in navbal was simply wrong

  On 10/12/2017 at 8:13 PM, Steven Mading said:

"but it's just quickfix on old DOCs" -> the change you linked to doesn't touch the docs.  I don't understand what this means.

Expand  

my typo I mean quickfix for old DOCs examples to pass (code where SHIP:SENSORS:ACC passing) ... and I should modify DOCs to reflect the API not the code itself

 

  On 10/12/2017 at 8:13 PM, Steven Mading said:

What is on the navball is speed and direction, which are both available from the vessel's velocity suffix, and a directionless "g" force as a scalar, with no vector info about which way it's pointed

Expand  

 

thank you so much for "velocity suffix" now my code is useless :P 

I have easy access to velocity vector then... and I can calculate G-force :)

 

Edited by DgD
Link to comment
Share on other sites
Redneck

Redneck

Posted
Posted

I only have this mod installed. It crashes KSP on loading screen everytime. KSP 32 or 64 bit in windows 10. if somebody can give me a hand getting KOS to load. Logs are here:

output_log.txt

  Reveal hidden contents

error.log

  Reveal hidden contents

 

Link to comment
Share on other sites
Redneck

Redneck

Posted
Posted (edited)
  On 10/15/2017 at 6:02 PM, reducing said:

It hasn't been updated for 1.3.1 yet.

Expand  

well then there ya go....thanks. I got confused with all the different versioning on github. o7 I didnt realize there was that big a difference in KSP API 1.3.0>1.3.1. Should prolly add a zero on github to read 

" v1.1.3.0 (for KSP 1.3) Bug Swatting Release to read v1.1.3.0 (for KSP 1.3.0) Bug Swatting Release"

https://github.com/KSP-KOS/KOS/releases/

I see now that it does say that in the little multi color boxes above the title. But anyways. I reverted back to ksp 1.3.0 and it loads so all is well

Edited by Redneck
Link to comment
Share on other sites
DgD

DgD

Posted
Posted (edited)

this script sits in boot folder and it's loaded on launchpad 

switch to 1.
print "copying files:".
COPYPATH("0:/toursetup.ks", "toursetup.ks").
COPYPATH("0:/tourmain.ks", "tourmain.ks").
COPYPATH("0:/tourup.ks", "tourup.ks").
COPYPATH("0:/tourdown.ks", "tourdown.ks").
print "done".
list.
wait 1.
run tourmain.ks.

1. coping files from zero to rocket disk.

2. then running tourmain.ks (I hope locally on the rocket)

3. then I have 10 seconds countdown there to leave the launch pad ... and I can't leave at all  :(

tourmain.ks starts from countdown... then I leave to Space Center

think is ... it STOPS! drops everything!... when I jump somewhere else to the different view ... it's automatically loaded via boot script chosen in VAB so... why it stops???

I want to do other things when my rocket is launching the tourists to the orbit

when I'm watching everything go smoothly but I can't leave the rocket even in space it lost the code.

What I'm doing wrong? Can I launch the rocket without my attention?

I thought I can but when I leave the rocket view everything driven via kos script STOPS! :( even when files are copied locally to the rocket :/ (I hope 1 is the number of first rocket drive)

it's KSP 1.3.1 with recompiled kos tag: v1.1.1.3.0 career mode early in the game with 45 science tier tech and literally first tourists mission

any suggestions how to make it fully automatic if not via boot script then how?

all scripts do their job but only when I sit and observe everything.

nahhh... It might be lvl 1 buildings in career: mission control and tracking station

ops just checked it can't launch without "me" watching even on sandbox with fully upgraded buildings

Edited by DgD
Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
  • Author
Posted
  On 10/15/2017 at 9:01 PM, DgD said:

think is ... it STOPS! drops everything!... when I jump somewhere else to the different view ... it's automatically loaded via boot script chosen in VAB so... why it stops???

I want to do other things when my rocket is launching the tourists to the orbit

Expand  

We cannot do anything to stop the fact that the base KSP game can only have the ships "near" you loaded and fully working.  The reason the script stops is because the ship that contains the kOS computer gets "packed" when you get too far away from it.  In this mode, the underlying game engine (Unity) stops calling kOS's updates on the parts in the ship, and so the kOS computer cannot continue.

Even if the kOS computer *could* run, it couldn't actually do anything that controls the ship if the ship is "packed".  The game itself prevents the ship's parts (engine, fuel, etc) from working in this mode.

You can come up with clever ways to make the boot script remember where it was and try to continue where it left off the next time it boots, but that's not easy. 

Link to comment
Share on other sites
hvacengi

hvacengi

Posted
Posted (edited)

for KSP v1.3.1 Downloads this release
This version is functionally identical to v1.1.3.0, however the binaries are
compiled against KSP 1.3.1 to allow it to properly load with the updated version
of KSP

BREAKING CHANGES:

  • This build will not work on previous versions of KSP.

NEW FEATURES:

(None)

BUG FIXES:

(None)

DOWNLOADS:

https://github.com/KSP-KOS/KOS/releases/tag/v1.1.3.2

Edited by hvacengi
Link to comment
Share on other sites
danielboro

danielboro

Posted
Posted
  On 10/16/2017 at 2:46 AM, Steven Mading said:

You can come up with clever ways to make the boot script remember where it was and try to continue where it left off the next time it boots, but that's not easy.

Expand  

it is easy. practically all my scrips have that
got it from CheersKevin from his KSP programming siris 

set runmode to 0.
if EXISTS("getrunmode.ks") run getrunmode.
function set_runmode {
  parameter mode.
  log "" to getrunmode.ks. deletepath("getrunmode.ks").
  log "set runmode to "+ mode +"." to getrunmode.ks.
  set runmode to mode.
}
  On 10/15/2017 at 9:01 PM, DgD said:

Can I launch the rocket without my attention?

Expand  

like Steven Mading wrote, the game only works 1 ship at a time.
if you`r not looking at it its not a ship, only a dot moving on a map (or not moving if it was landed wen you left it)

Link to comment
Share on other sites
DgD

DgD

Posted
Posted
  On 10/16/2017 at 2:46 AM, Steven Mading said:

The game itself prevents the ship's parts (engine, fuel, etc) from working in this mode.

Expand  

thx for that explanation

After my last post I went to the KSP.log and RemoteTech/kOS code to figure out mysterious "dispose" calls (derp)

With pack mode we are screwed :/ and yes my next assumption was that the ability to auto-fly the ship and in between do something else - for example, short mission with aircraft - will kill physic engine or at least the calculations might be not very percise/dropped etc. :( 

I hoped for unattended "refuelling station" missions or "fly by" tourism missions not an option due to processor "math powers" conservation for the task at hand

 

  On 10/16/2017 at 9:45 AM, danielboro said:

it is easy. practically all my scrips have that

Expand  

technically I have (maybe unnecessary) 2 numbers - for more fun.

1. plan => what I want to do "going to orbit", "in orbit", "landing procedure" (sneaky file management here)

2. runmode => current state of plan: "going straight up till 9km" [...] "decelerating till Peri 64km" (where inside the file)

and for even more fun positive number of runmode means I'm "accelerating"  for example 1 up to 6 making an orbit

negative number for runmode means I'm decelerating: -1...to -3 deorbiting, falling, checking all the chutes active :wink: 

rumode zero is idle (not implemented just end of program)

and functions:

describe_plan

describe_runmode

just for fun :wink: and more humanoid form :D 

Well I need to look deeper into AlarmClock integration... the last command in script should put alarm clock for next time I need to become observer and let script maneuvers to occur

the result - at least semi-unattended it might be :) 

Fully unattended??? ... with quantum processors? :D ...  easy jet ...  until then AlarmClock will have to do :wink: 

Link to comment
Share on other sites
danielboro

danielboro

Posted
Posted
  On 10/16/2017 at 10:29 AM, DgD said:

Fully unattended??? ...  AlarmClock will have to do :wink: 

Expand  

i have 3 main scripts
1- intercept and dock whit a space  station in kerbin orbit (resupply and station tourists)
2- go to orbit wait 4H(and add a KAC alarm) and get back (tourist to orbit )
3- rescue a kerbal in kerbin orbit (lunch intercept and then wait until thr`s 2 kerblas in rescue ship, then go back)
and im working on a scrip to thake tourist to mun and back


i start the script and go to do something else (like sleep or work :) )

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
  • Author
Posted
  On 10/16/2017 at 9:45 AM, danielboro said:

it is easy. practically all my scrips have that
 

Expand  

That's not what I meant.  That's resetting to the beginning of a task.  In that context you don't need to remember any variable values other than just which mode you were in.  I was talking about having to pick up right where you left off, and thus needing to remember things like what the value of a loop counter was, what a running total in a variable was, etc.  (Basically, like hibernation mode on a PC).  Howver, yes, given the tasks these autopilot scripts are doing, it is usually possible to restart at a reasonable point, as CheersKevin's scripts usually do.  It's a good-enough solution to the problem given the kinds of tasks these programs do.  To a large extent it works because all the variables you need to remember can be queried again from the system ( ship position, ship velocity, what planet are we around, etc), instead of *actually* having to save the full memory context.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...