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

[NewtSoup]

Memory use has climbed again to  11.5gb.  I'm not getting the huge disk reads this time though.  Disk read total is still at 2.3gb and the read speed is still 0.  I'm going to leave it another hour.

[NewtSoup]

Memory use now at 13.1gb according to the "Resources" tab I've used 99.4% of my physical ram.  But without kOS installed I'm not getting the freezing and stuttering.  The system is still perfectly usable so I'm tentatively going to say that kOS was not responisble for the bloat, but was indeed doing something. Whups no.  It just froze.  I wonder what's causing it.  It may be a launchpad thing.  but kOS I think is off the hook. 

Next test.  Copied KSP install to home directory.  Will point CKAN at THAT and remove all mods. and see what vanilla KSP does.

[NewtSoup]

Vanilla runs fine.  Will install kOS again, just kOS and no other mods.  Will put a KAL9000 back on the vessel too as I want to start writing this script 

One hour of sitting on the LP with just kOS running and nothing bad happened.  No memory bloat kOS is officially innocent.  Sorry for the bother.  Just bizarre coincidence.  I will just install my "must haves"

kOS 
KER
Maneuver Node Evolved.
6 Crew Science Lab
6 Seat Mk 3 Cockpit.
Better Time Warp
CAK
DPAI and
TAC Fuel Balancer.

Edited October 3, 2018 by NewtSoup

[NewtSoup]

There is just ONE bug in Linux with kOS.  I have just kOS installed right now and using the internal editor for mining.ks the keys R, S and E still do not work.

It's not an issue because I'll just write scripts in an external editor on my right hand monitor and copy them to the ship in game.

 

[NewtSoup]

Well this mostly works:

The mining is automated switching between drills and isru.
It monitors the electric charge because this was an issue and so if the charge drops low it will wait for the fuel cells to catch up.
Half the time though charge is not an issue as the game glitches at warp an nothing seems to use charge so that's fine.
However it never reaches it's exit conditions.
The isru and drill both shut down because they meet their shutdown conditions but the loop which waits for LF and OX to be full never exits even though I've manually checked the conditions at the command line.

Can anyone spot my logic error or is it just game glitchyness?
 

Print "Initialising Mining Program".
set mIRSU to ship:partsnamed("isru (mostlyversal lander mk iv)")[0]:getmodulebyindex(1).
mIRSU:doaction("stop isru [lf+ox]",true).
set fuelcells to false.
set RADIATORS to false.
wait(5).
set DEPLOYDRILLS to true.
set FUELCELLS to true.
set RADIATORS to true.
//wait for drill to fully deploy
wait(7).
	
until ship:liquidfuel > 4580 and ship:oxidizer > 5580 {
    if ship:ore < 299 {
        Print "Ore Not Full:  Starting Drill".
        set DRILLS to true.
        wait until ship:ore >299.
        Print "Ore Full.  Stopping Drill".
        set DRILLS to false.
    }
    else if ship:ore >299 {
		Print "Ore Full:  Starting ISRU".
        mIRSU:doaction("start isru [lf+ox]",true).
	        until (ship:ore < 1 ){
            wait until ship:ore < 1 or ship:electriccharge <100 or (ship:liquidfuel >4580 and ship:oxidizer > 5580).
	            if ship:electriccharge <100 {
                print "Power Low:  Waiting on charge.".
                mIRSU:doaction("stop isru [lf+ox]",true).
                wait until ship:electriccharge >1399.
                Print "Power Restored: Restarting ISRU".
                mIRSU:doaction("start isru [lf+ox]",true).
            }
        }
        if ship:ore < 1 {
            Print "Ore Empty: Stopping ISRU".
            mIRSU:doaction("stop isru [lf+ox]",true).
        }    
    }       
}

Print "Fuel Tanks Full".
Print "Shutting Down".
mIRSU:doaction("stop isru [lf+ox]",true).
set DEPLOYDRILLS to false.
set fuelcells to false.
set RADIATORS to false.
wait(7).
Print "Mining Program Ended".

and yet on the launch pad with full tanks the loop exits right away and the program ends as expected!.  crazy stuff

 

Edited October 4, 2018 by NewtSoup

[NewtSoup]

Spotted the error.. Loop in a loop. I had the inner loop Lf and Ox  leave conditions in the wrong place.  They needed to be on the loop and on the wait. Looks inelegant now though.  There must be a better way of doing it.

Edited October 4, 2018 by NewtSoup

[Dunbaratu]

9 hours ago, NewtSoup said:

Vanilla runs fine.  Will install kOS again, just kOS and no other mods.  Will put a KAL9000 back on the vessel too as I want to start writing this script 

One hour of sitting on the LP with just kOS running and nothing bad happened.  No memory bloat kOS is officially innocent.  Sorry for the bother.  Just bizarre coincidence.  I will just install my "must haves"

kOS 
KER
Maneuver Node Evolved.
6 Crew Science Lab
6 Seat Mk 3 Cockpit.
Better Time Warp
CAK
DPAI and
TAC Fuel Balancer.

Thanks.  It's *still* possible that it's some kind of an *interaction between* mods  where *both* have to be present for the problem to happen, but those are a *real* pain to trace down because it means trying n*(n-1) combinations to find it, and if each test takes a few hours, that's probably not worth the time.

Quote

There is just ONE bug in Linux with kOS.  I have just kOS installed right now and using the internal editor for mining.ks the keys R, S and E still do not work.

You're not the first to report this.  It's just impossible for me to diagnose because it doesn't happen on any other platform, and I don't have a Linux install to play with it on.  If you can compile the mod on Linux you could help track it down (?).

 

[NewtSoup]

Keys - ahh.. I suppose I could try.  I used to have a head for Java programming many years ago ( computer science undergrad).  I've no idea what I'd be looking for though but sure.  It would actually be an interesting thing to take a look even if I can't solve anything.

Memory Bloat - with my favourite functional mods installed I spent a long time on the launch pad ( more than 2 hours) and the memory never went above 4.5gb.  The only mods missing were the prettification ones - EVE, Stock Visuals, Stock Terrain, Kopernicus,  Planetshine, Distant Objects.   My main suspect now is EVE and the clouds causing the bloat.  I don't usually sit on the Launchpad for 2 real time hours or more and I think that the clouds from SVE and EVE may have been causing the issue as one of the Logs had a ton of textures from those being dumped due to memory needs.  I'll leave them out for now and put them back when I go to planets that would benefit from the visuals.

[Pand5461]

@NewtSoup I think Steven has fixed the keys issue with this PR.

I hope you know how to build mods from source

If you need a livelier discussion, you can look at /r/Kos or join the Discord server.

[NewtSoup]

I have no clue how to build a mod from scratch.  I do want to make one though.  I want to make some main engines that tie into Reaction Control System controls so that there's a more powerful Lf Ox alternative for bigger heavier craft. Vernor engines are great too.. but don't really cut it for what I have in mind.  I figured that would be a half decent foray into mod making.  Though it does require me to make models too.  Not my forté.

[Pand5461]

I meant, building from the source code, not from scratch.

You can download the branch where the ESR issue is fixed, build the .dll using MonoDevelop and enjoy kOS experience without the editor key locks.

[MaltYebisu]

I'm trying to show how much free space is available on the hard-drive. I've read the kOS Documentation: Volume, but I can't figure out how to print the information I want.

I have tried different approaches to no avail.

//Some stupid attempts:
// 1
print volume:freespace.

// 2
print kOSprocessor:volume:freespace.

// 3
set p to ship:partstagged("Telemetry")[0].
for f in p {
  print f:volume:freespace.
}

// 4
set p to ship:partstagged("Telemetry")[0].
for f in p {
  print f:kosprocessor:volume:freespace.
}

Does anybody know how to print the free space left on the kOS hard-drive? Also, does anyone have any tips on how to read the documentation? I have a hard time figuring out how to do things on the pages without examples. 

[ElWanderer]

CORE gets you the CPU module which your script is running on. Modules that are a kOS CPU have a VOLUME suffix.

So CORE:VOLUME:FREESPACE should get you the free space on the volume used by the CPU part module.

If you want to check other volumes, it is a bit more awkward. If you have named a volume, you can use VOLUME(volume_name):FREESPACE. I think I found by default the name is unset, so my multi-CPU scripts name them all on start-up. You can loop through all volumes by looping through all the CPU part modules (e.g. LOCAL pl IS LIST(). LIST PROCESSORS IN pl.)

[NewtSoup]

Your mistake is a KOSProcessor is not a part it's a part module

if you make a simple ship  and tag your kOS part (kal9000 in this case) with the tag "brain" the following will work:

print ship:partsTagged("brain")[0]:getModuleByIndex(0):volume:freespace.

 

[ElWanderer]

1 hour ago, NewtSoup said:

Your mistake is a KOSProcessor is not a part it's a part module

if you make a simple ship  and tag your kOS part (kal9000 in this case) with the tag "brain" the following will work:

print ship:partsTagged("brain")[0]:getModuleByIndex(0):volume:freespace.

 

Is it guaranteed that the kOS CPU part module will be at index 0? A safer way would be to find out what the module is called and replace getModuleByIndex(0) with getModule("module_name")

As to how to find out what the module is called, I would try PRINT CORE:NAME. Sometimes I just put a ship on the launchpad and run a script to print out all the part names and their modules...

PS thanks, I had missed getting the free space with a tag/part as the starting point from my own answer.

[NewtSoup]

No, it's not guaranteed but I didn't want to over complicate the point and stuck with a simple example.  Took me quite a time at first working out how to turn on an isru to make a specific resource.  And yep code for one ship fell over in the same ship copied to a different save as the part and module orders changed

[Dunbaratu]

8 hours ago, ElWanderer said:

If you want to check other volumes, it is a bit more awkward. If you have named a volume, you can use VOLUME(volume_name):FREESPACE. I think I found by default the name is unset, so my multi-CPU scripts name them all on start-up

VOLUME() takes a number if you like instead of a string (it's overloaded to take either one).

If you give it a number, you can just use the volume number instead of the name.  VOLUME(0) for archive and VOLUME(1) for local disk.

[MaltYebisu]

Thank you for explaining this for me @ElWanderer , @NewtSoup, and @Steven Mading ! 

This forum community makes it fun to have questions. I learnt a lot from your posts.

[infinite_monkey]

Are any mods known to interfere with kOS cooked steering? The only thing I remember installing lately was FAR. Now I have problems with kOS as well as with MechJeb Ascent Guide. It seems to want to go to some arbitrary direction.

[Dunbaratu]

2 hours ago, infinite_monkey said:

Are any mods known to interfere with kOS cooked steering? The only thing I remember installing lately was FAR. Now I have problems with kOS as well as with MechJeb Ascent Guide. It seems to want to go to some arbitrary direction.

Is SAS on?  Obvious question, but I have to check.

[infinite_monkey]

15 minutes ago, Steven Mading said:

Is SAS on?  Obvious question, but I have to check.

No. I tried turning it on as well, doesn't seem to make any difference. I uninstalled FAR now, as well as Throttle Controlled Avionics and KerbalActuators. Problem is gone. I'll reinstall them one by one and see which one is the culprit.

Now engine:AVAILABLETHRUST is messed up - it always reads 0. It seems some weird config is still left over.

Edited October 13, 2018 by infinite_monkey

[Warp11]

I'm having a problem with the "lock steering to" command. Sometimes when I use it point at a maneuver node the controls for one or more axis just spasm around wildly, burning through all my precious RCS fuel. It also does not settle down eventually, the control just keeps oscillating quickly.
I can't really tell when this happens and when not, so its really difficult to pinpoint the problem. SAS is off :).

Is this a known issue?

I'm running KSP 1.2.2, RT 1.8.9, kOS 1.1.0 and Realism Overhaul v. 1.0.3.0. MechJeb is also installed.

Thanks a lot!

Edited October 14, 2018 by Warp11

[infinite_monkey]

1 hour ago, Warp11 said:

I'm having a problem with the "lock steering to" command. Sometimes when I use it point at a maneuver node the controls for one or more axis just spasm around wildly, burning through all my precious RCS fuel. It also does not settle down eventually, the control just keeps oscillating quickly.
I can't really tell when this happens and when not, so its really difficult to pinpoint the problem. SAS is off :).

Hmm, is it a heavy craft? Cooked steering has some problems with that. You might try to tweak the PID parameters. In my Falcon 9 landing script I set the values to this:

SET STEERINGMANAGER:MAXSTOPPINGTIME TO 8.
SET STEERINGMANAGER:PITCHPID:KD TO 1.
SET STEERINGMANAGER:YAWPID:KD TO 1.

It kind of works, but is still pretty inefficient, so sometimes when it gets stuck to some arbitrary direction I briefly turn SAS on manually, and as soon as the vehicle starts moving, I turn it off again. Vehicle mass is about 20 tons.

[ElWanderer]

2 hours ago, Warp11 said:

I'm having a problem with the "lock steering to" command. Sometimes when I use it point at a maneuver node the controls for one or more axis just spasm around wildly, burning through all my precious RCS fuel. It also does not settle down eventually, the control just keeps oscillating quickly.
I can't really tell when this happens and when not, so its really difficult to pinpoint the problem. SAS is off :).

Is this a known issue?

I'm running KSP 1.2.2, RT 1.8.9, kOS 1.1.0 and Realism Overhaul v. 1.0.3.0. MechJeb is also installed.

Thanks a lot!

To add to infinite_monkey's answer: if you are running Realism Overhaul then you probably have no (or practically no) reaction wheel torque. The steering manager is known to struggle under such conditions.

Also, are you locking to a particular vector or are you providing a direction with a sensible top vector? If you don't provide a top vector, it'll default something and quite possibly try to rotate the ship right around as well as hunt for the new forevector, which can result in a complete mess, though I think this has been improved relatively recently (only rotates once you're facing down the right vector), but I've lost all track of kOS version numbers!

[Warp11]

1 hour ago, ElWanderer said:

To add to infinite_monkey's answer: if you are running Realism Overhaul then you probably have no (or practically no) reaction wheel torque. The steering manager is known to struggle under such conditions.

Also, are you locking to a particular vector or are you providing a direction with a sensible top vector? If you don't provide a top vector, it'll default something and quite possibly try to rotate the ship right around as well as hunt for the new forevector, which can result in a complete mess, though I think this has been improved relatively recently (only rotates once you're facing down the right vector), but I've lost all track of kOS version numbers!

I'll have to try to mess around with the PID settings. I have a probe with only RCS, but quite low RCS thrust relative to its inertia. I usually provide a top vector by doing something like: "lock steering to lookdirup(nextnode:deltav,ship:facing:topvector). Most of the time it gets to its intended orientation just fine but starts going crazy when it's there. Quite often its also only one axis doing it. It also happens sometimes and sometimes not, even on the same vessel.