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

[infinite_monkey]

@kcs123 Thanks for your explanation, I'm sure it will help some beginners land their rockets. I knew all that (except for LOCAL foo TO somevalue. - is this SET or LOCK?), and I'm able to land a Falcon 9 booster (from Tundra exploration) pretty accurately on land, and with some luck even on a ship. I now want to land a BFR booster on the launchpad - so huge mass (> 200 000kg), slow turning rate, and high precision needed.

The problem (that KER or Trajectories won't solve either) I would need some help with is that when the rocket is not perfectly vertical over the landing pad, vertically aligned with 0 horizontal speed, steering becomes very hard - the engine should point away from the direction you want to move in, while from an aerodynamic perspective you want to point right into that direction, so which way should I steer? Simplest thing coming to my mind would be to steer the booster's body and grid fins separately from the engines. But I guess that is not possible in KSP, or is it?

[Luovahulluus]

8 minutes ago, meyerweb said:

This did not work for me.  Does there need to be a `WAIT 1`. before it or something?

It works for me.

You need to save the boot file to the boot directory, and then set the file as the boot file in the editor.

[kcs123]

16 minutes ago, infinite_monkey said:

 I'm sure it will help some beginners land their rockets. I knew all that (except for LOCAL foo TO somevalue. - is this SET or LOCK?), and I'm able to land a Falcon 9 booster (from Tundra exploration) pretty accurately on land, and with some luck even on a ship. 

...

the engine should point away from the direction you want to move in, while from an aerodynamic perspective you want to point right into that direction, so which way should I steer? Simplest thing coming to my mind would be to steer the booster's body and grid fins separately from the engines. But I guess that is not possible in KSP, or is it?

I just copy-pasted pieces of kOS function, yes it is meant to explain things for beginers. LOCAL command is used for declaration of variables inside of function whole thing is under spoiler section:

Spoiler

declare function VelocityLimit {
  parameter HoverAlt is 0.  // Altitude when craft starts to hover
  parameter ShutOffAlt is 1.// Radar altitude shown when craft is landed - when engine should shut off
  parameter MaxFallAtmo is -60. // per craft parameter due to fliping because of drag
 
  local Body_g to SHIP:BODY:MU / (SHIP:BODY:RADIUS+altitude)^2.
  local CraftWeight to SHIP:MASS * Body_g.
  local CraftMaxThrust to SHIP:AVAILABLETHRUST.
 
  local FallTime is 0.
  // alt:radar is measured from ship centre of mass that is higher than lowest craft part
  // this is different for each craft
  local FallAltitude is alt:radar - HoverAlt.
  if FallAltitude > 0 // calculation makes sense only if we are not already on ground
  {
    if ship:verticalspeed = 0
    {
        // we can use simplified equation if starting velocity is zero
        set FallTime to SQRT((2 * FallAltitude)/ Body_g ).
    }
    else
    {
        // On this line is NaN if equation under SQRT gives imaginary result, or divide by zero occur or any other undefined value
        // happened also if cheated to Mun orbit with engines off, could be due to celestial body changes between physical ticks or number becomes too small
        if (MAX(0,(ship:verticalspeed^2 +4 * (((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)*FallAltitude )) > 0) and (CraftMaxThrust > 0) and (Body_g > 0)
        {
            set FallTime to -1 * ship:verticalspeed/(2*(((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g))  + SQRT(ship:verticalspeed^2 +4 * (((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)*FallAltitude )/(2*(((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)).
        }
        else
        {
         set FallTime to 0.1.
        }.
    }.
  }.
 
  local SafeVelocity is 0.
 
  if alt:radar < HoverAlt + ShutOffAlt
  {
    // Additional safety measure to slowly hover before touching down
    set SafeVelocity to -1.
  }
  else
  {
    // Assuming that TWR is greater than 1
    // Tested on "Kerbin" "Mun" and "Minimus"
    set SafeVelocity to (FallTime) * (Body_g - ((CraftMaxThrust - CraftWeight) / SHIP:MASS)).
    set SafeVelocity to SafeVelocity - ship:verticalspeed.    // current ship velocity must not be ignored
    
    // Additional safe mesure to prevent fliping rocket if drag cause it in atmosphere
    if (SafeVelocity < MaxFallAtmo) and (SHIP:BODY:ATM:EXISTS = true){
        set SafeVelocity to MaxFallAtmo.
    }.
    
  }.
 
  // in some situations, SafeVelocity become positve and that should never be a case.(when wrong equations were used)
  // craft accelerate to UP, for example that above equation does not cover
  if SafeVelocity > 0
  {
    //set SafeVelocity to -5.
    // previous checkings put here, to have working script on Kerbin body too
    if (alt:radar < 5000 + ShutOffAlt)
    {
        set SafeVelocity to -50.
        if (alt:radar < 2500 + ShutOffAlt)
        {
            set SafeVelocity to -25.
            if (alt:radar < 1000 + ShutOffAlt)
            {
                set SafeVelocity to -15.
                if (alt:radar < 200 + ShutOffAlt)
                {
                    set SafeVelocity to -10.
                    if (alt:radar < 50 + ShutOffAlt)
                    {
                    set SafeVelocity to -5.
                    }.
                }.
            }.
        }.
    }.
  }.
  return SafeVelocity.
}.

I created that piece of code as function and have it in library that can be used in all kind of situation. It is meant to be most univeral as possible. As you can see, I have encountered in similar problem as you have with fliping rocket in undesired direction, that is reason why I have "MaxFallAtmo" parameter for vertical velocity. So, if previous calculation gives solution that is much higher than what is considered "safe" for rocket to be able to steer, it will give max safe atmosphear velocity that can be properly handled instead.

I'm using info from that function in main script that handle steering and engine throttle with PIDs. It is less efficient due to higher fuel consuption than it is necessary when you have everything calculated accurately 100%, but it does job well enough for rocket to survive landing.

So, answer to second question, what direction you should choose trough landing is that engine should point away from the direction you want to move in (generaly speaking). With such big rocket don't rally only on fins for steering, use it in combination with RCS too. Real life falconm rocket also use them, although it is not so obvious from their launch/landing videos. I usualy use RCS trusters from B9 mod instead of stock ones.

It is hard to give you exact solution that will work in all cases, so you will have to adjsut things a bit depending on celestial body with atmosphere, rocket that need to land, suborbital or orbital trajectory, etc. But with a bit of trial and error it can be handled. To mimic space X landing, when booster is separated from upper stage, while still at high altitude you need to bleed out all horizontal velocity and a bit more to go in oposite direction toward launchpad. You need to overshoot it to some amount because drag forces would kick in and you will also reduce horizontal velocity while maintain "safe" vertical velocity at same time.

What I'm doing at this part of landing procedure is to lock steering to retrograde while watching to maintain "safe" vertical velocity trough PID/ main engine throttle control. Because of being on angle instead of 90 degree, rocket also bleed out horizontal velocity too. That is actualy desirable as you want on final aproach for rocket to be completely vertical, so it does not tip over when you shot off engines. IIRC RCS can be used separatly from main engines and regardless if are used for steering or not. Use that info with grain of salt, though, but I think it is possible to use kOS translate RCS feature along with them being lock for steering too. RCS should be strong enough to correct small errors in impact point as you aproach launchpad.

Impact point can be obtained from kOS orbital values (where ship would be at some time with current trajectory). From that position you can get long/lat on clestial body and compare it with desired landing/impact point. Of course, because it does not take in account drag from atmosphere it will change all time, but you also can re-calculate steering all time too and make necessary adjustments.
I recommend fine tuning steering for exact precise impact point when you bleed out most of velocity and rocket is subsonic, so atmosphere forces are managable to handle.

[ElWanderer]

9 hours ago, meyerweb said:

This did not work for me.  Does there need to be a `WAIT 1`. before it or something?

Hmmm. My shared boot script does have this first, so possibly:

WAIT UNTIL SHIP:UNPACKED.

[squidgeny]

13 hours ago, infinite_monkey said:

You should have an icon in the toolbar from where you can open the console

I'm fairly sure I had a good look around for something like that, but I might have missed it. Thanks - I'll have another look later today.

13 hours ago, ElWanderer said:

You can get one to open automatically if you stick the following in a boot file:

CORE:DOEVENT("Open Terminal").

 

12 hours ago, Luovahulluus said:

It works for me.

You need to save the boot file to the boot directory, and then set the file as the boot file in the editor.

This sounds ideal, but I'm too much of a newb to know what it means..!  If I can guess though: I need to create a file with a very particular name and stick it in "volume 0" ?

Thanks for the quick responses though. I'm loving this mod and have had great fun trying to make a "suicide burn" program for my mun landings. It's an incredibly deep mod so I'll probably be back with more questions in the future!

[Luovahulluus]

1 hour ago, squidgeny said:

I'm fairly sure I had a good look around for something like that, but I might have missed it. Thanks - I'll have another look later today.

 

This sounds ideal, but I'm too much of a newb to know what it means..!  If I can guess though: I need to create a file with a very particular name and stick it in "volume 0" ?

Thanks for the quick responses though. I'm loving this mod and have had great fun trying to make a "suicide burn" program for my mun landings. It's an incredibly deep mod so I'll probably be back with more questions in the future!

Create a file called boot.ks, type CORE:DOEVENT("Open Terminal"). in it and save it to [kerbal directory]\ships\script\boot\ 

In the editor, right click on the kOS computer part and in the appearing menu you can choose the boot.ks as a boot file.

More info: https://ksp-kos.github.io/KOS/general/volumes.html#special-handling-of-files-in-the-boot-directory

Edited January 24, 2019 by Luovahulluus

[meyerweb]

1 hour ago, Luovahulluus said:

Create a file called boot.ks, type CORE:DOEVENT("Open Terminal"). in it and save it to [kerbal directory]\ships\script\boot\ 

In the editor, right click on the kOS computer part and in the appearing menu you can choose the boot.ks as a boot file.

More info: https://ksp-kos.github.io/KOS/general/volumes.html#special-handling-of-files-in-the-boot-directory

Ahhh, it was the “set a boot script in the VAB before launch” that I was missing.  The documentation there assumes you’ll study the picture very carefully to infer what’s needed and why, and I hadn’t—I was concentrating on parsing the text for instructions.

[TGApples]

On 1/8/2019 at 8:02 AM, Willem_D said:

First of all, great mod. I cannot image playing KSP without it.

I do have a question. I use RSS+RO+RP-1 (with RemoteTech). Is it possible to transfer the the ScienceData from an experiment (like barometer) to a probe core., assuming the probe core has a ModuleScienceContainer? I can do it manually (with the Ship Manifest mod), but that only works when a have an active connection to the ship, and with the normal signal delay. I have a feeling KOS should be able to do the same, but I cannot find out how.

What I tried:
- The ModuleScienceContainer has an action "Collect All", but that does nothing.
- I tried the TransferAll from the resource transfer functionality. But apparently, the ScienceData is not in the Resources collection of the part that contains the ModuleScienceExperiment. So I cannot transfer it.

Anybody any ideas? The purpose is to use it in a automated script that collects sciencedata during a flyby (like Venus), and keeps collecting sciencedata when the planet is between the probe and earth (no connection). What I do now is having many duplicates of all Science experiments on board (like 3 thermometers). But I'd like to have just one science experiment, that collects data and transfers it automatically the the probe core.

Maybe the ScienceData of an experiment needs to be in the Resources collection of the part?

I'd be interested in knowing if you can get this to work. This is actually one of the main reasons I wanted to use KOS in the first place.

Edited January 24, 2019 by TGApples

[Dunbaratu]

On 1/23/2019 at 4:02 PM, meyerweb said:

This did not work for me.  Does there need to be a `WAIT 1`. before it or something?

Yes.  The script starts running before the ship is fully unpacked.

It's usually good to start a boot script with this:
 

wait until ship:unpacked.

 

[infinite_monkey]

Is the program state saved in a quicksave? So if I use FMRS, do stage separation, continue to orbit, then jump back - will a program stored in stage 1 continue where it was at (stage separation + FMRS save delay)?

[ElWanderer]

20 minutes ago, infinite_monkey said:

Is the program state saved in a quicksave? So if I use FMRS, do stage separation, continue to orbit, then jump back - will a program stored in stage 1 continue where it was at (stage separation + FMRS save delay)?

No, but the local hard drives retain their state. So you can save commands to a file on the local hard drive that put you into the right state to resume after a reload.

My approach is fairly simple most of the time, saving "SET run_mode TO x." to a file that can be run during start-up to get the current run-mode. You can store quite a few variables if needed, though. The complicated bit is writing the main program in such a way that it can recover gracefully from a restart using this data.

Edit: you would need the craft to run the mission from a boot file to do this automatically, else you'd need to run the program manually on switching back.

Edited January 26, 2019 by ElWanderer

[JebIsDeadBaby]

After discussion about kOS core placement in the Tech Tree in Probes Before Crew mod (where the 0.625 core is available at Start, making  the 1.25 core available later virtually obsolete) I got an idea of a new part for kOS and I hope this thread is the right place to share it. PBC mod places the 0.625 core at Start to let players toy with small sounding-type rockets before advancing to bigger ones.  In stock kOS probe cores come a bit late and for a good reason, as they are a very powerful tool. However, how about a Tier 0 or Tier 1 part that would simulate early, ground based computer guidance? The part would be small enough to fit on 0.625 or smaller rockets, maybe radial. It would give an access to the terminal just as a standard core but:

- it would have no internal storage

- it would require connection to KSC (script would still run in the background until failure but the core would not be able to control the ship)

- it would be a subject to signal delay

This last thing would be quite hard to implement I imagine but if sensor readings like radar alt were delayed too, it would add a very interesting programming challenge for someone wanting to make a lunar landing with ground based guidance. On Hard setting the 1.25 core is the only one available for quite a long time, so it's the core of choice for early Mun missions. It's cumbersome and heavy enough to make a laggy, unreliable ground controlled core an interesting option. 

Edited January 28, 2019 by JebIsDeadBaby

[Dunbaratu]

5 hours ago, JebIsDeadBaby said:

After discussion about kOS core placement in the Tech Tree in Probes Before Crew mod (where the 0.625 core is available at Start, making  the 1.25 core available later virtually obsolete) I got an idea of a new part for kOS and I hope this thread is the right place to share it. PBC mod places the 0.625 core at Start to let players toy with small sounding-type rockets before advancing to bigger ones.  In stock kOS probe cores come a bit late and for a good reason, as they are a very powerful tool. However, how about a Tier 0 or Tier 1 part that would simulate early, ground based computer guidance? The part would be small enough to fit on 0.625 or smaller rockets, maybe radial. It would give an access to the terminal just as a standard core but:

- it would have no internal storage

- it would require connection to KSC (script would still run in the background until failure but the core would not be able to control the ship)

- it would be a subject to signal delay

This last thing would be quite hard to implement I imagine but if sensor readings like radar alt were delayed too, it would add a very interesting programming challenge for someone wanting to make a lunar landing with ground based guidance. On Hard setting the 1.25 core is the only one available for quite a long time, so it's the core of choice for early Mun missions. It's cumbersome and heavy enough to make a laggy, unreliable ground controlled core an interesting option. 

About point 1 - That is hypothetically do-able.  I think if what you're trying to imitate is the idea of early probes without storage, what might work better is some kind of rule that says the booted software is "ROM" - meaning files cannot be edited after initial spawning on the launchpad.  To do this we'd have to add the notion of "pre-filling" the kOS core with multiple files in the VAB.  Right now we rely on ONLY populating the boot file and running it on launch.  Any further files it needs have to be obtained by executing copy commands while "live", to populate them after launch.  But if we want to "pre-load" files onto the core in the VAB and NOT allow further file copying after spawning, that would require a more complex widget in the VAB than the current "just pick a boot file" widget we have.  Unless we want the early probe core rule to be just "it can only run the one boot file and nothing else.  It cannot even run other files."

Actually, that second thing would be the hardest to implement - suppressing the program's ability to steer when the connection is lost.  This is because we had to bend over backwards to get it to STOP acting that way when we DIDN'T want it to.  The stock game's assumption that "no comms means disable everything" has to be actively fought against so that a program can run autonomously when, say, on the backside of the moon.  Being able to program a probe to do a complex pre-planned thing while out of contact or under extreme delay is kind of the point of kOS for a lot of people (especially people using Remote Tech).  I fear that adding a flag that says to re-enable that (otherwise undesirable) behaviour in some cases would turn some already messy code even messier.

For the third thing - we always used the philosophy that if signal delay is what people are after, we should have them install Remote Tech and we should defer to Remote Tech for that.  It's already got a very complex system for handling it, and we shouldn't be re-inventing the wheel like that.  At the moment, the way it works is this: "Do you want lightspeed delay?"  If yes, install Remote Tech and tell kOS to use it.  If no, then don't install Remote Tech."

Edited January 28, 2019 by Steven Mading

[JebIsDeadBaby]

21 minutes ago, Steven Mading said:

I think if what you're trying to imitate is the idea of early probes without storage, what might work better is some kind of rule that says the booted software is "ROM" - meaning files cannot be edited after initial spawning on the launchpad.

What I have i mind is even simpler. I dunno a technical term for it, I think it's called Automatic-Line-Of-Sight-Guidance, where both tracking and guidance are performed by ground installations. The missile is kinda like an RC plane - it has no means of self guidance. This video from the 60s explains it. In-game it would mean that the T0/T1 core would work just as a regular core, as a ground based operator could run programs just like a Kerbal on-board a vessel (because the actual core would actually be a ground based IBM 704 style monstrosity, the in-game part would just serve as an interface for the player and could imitate a dedicated antenna for example). But a working connection would be required to transmit commands to a vessel. Without a connection it would be like trying to send commands to RCS thrusters on a ship with disabled RCS - the script would try to do it's thing but with no effect. 

[Dunbaratu]

kOS Scriptable Autopilot System v1.1.6.0 for KSP 1.6.1

Available at the usual download places (see first post in thread for links)

v1.1.6.0 It's been too long without a release.

Built for KSP 1.6.1

It's been a long time without a release. We kept putting it off until "that one more thing" was merged in, and there was always "that one more thing", again and again, that kept putting off the release more and more. Eventually we decided to release what we had since there's so many fixes the public weren't getting.

This release incorporates 50 separate Pull Requests from many individuals. As always, thanks to everyone who contributed over the last year. (Has it really been that long? Almost.)

BREAKING CHANGES:

(None that we know of, but this is a big update so we could have missed something.)

BUG FIXES:

• Was reading POSITIONAT() from the wrong orbit patch when getting a prediction for the moment when a patch transition should occur. pull request
• Stage:resources gave wrong values in cases of stages without a decoupler. pull request
• Several documentation clarifications. See individual links below for more details:
• dead links on Vector doc page
• a typo
• a spelling error
• sphinx old code deprecated
• HUDtext style corner documented wrong
• cleanup gh-pages branch having source in it
• Mention Simulate in BG needed
• SKID clarification
• Error in basic tutorial example
• Removed old obsolete notices
• Fixed error detecting VT100 terminals in telnet (used wrong substring compare). pull request
• Fixed bug of multiple ON triggers melting their "prev value" trackers together if the triggers came from the same line of source code. pull request
• Fix a bug with RemoteTech autopilot premissions getting lost. pull request
• WHEN/ON statements inside anonymous functions now working properly. pull request
• (attempt to?) Fix problem where bootfiles weren't copied in Mission Builder missions. pull request
• Massive refactor of how trigger interrupts work, that allows them to behave more consistently and allows more complex layering of triggers. (In this CHANGELOG, This is listed both under "new features" and "bug fixes" since it's both.) pull request
• Fix stack alignment bug that happened when a bootfile runs a KSM file that locks steering: pull request
• Fix: Locked steering refusing to let go if the IPU boundary lands right in the middle of kOS's steering trigger (kOS not having "atomic sections", the ordering of the opcodes mattered a lot). pull request
• Fix: Undocking/Decoupling while a kOS unit on the lower half has locked steering used to cause the lower stage's kOS unit to spin the upper stage's steering and never let go of it. pull request
• Fix: Hyperbolic orbits now allow negative anomaly angles to represent measures "prior to periapsis" correctly. (Previously it represented a value like -10 degrees as +350 degrees, which doesn't make sense if the orbit isn't closed and won't come back around.) pull request
• Fix: E,S, and R keys now working right in text editor widget in Linux port. kOS incorrectly prevented the E, S, and R keys from passing through to other widgets before. This error was only noticed on Linux because Unity3d's event queue passes through widgets in a different order on different OS ports. pull request
• kOS will now let go of the steering when the program dies due to a lack of electricity. This allows your vessel to get some power recharging again when it starts getting sun on the solar panels again. (Previously the steering deflection was still present, meaning the ship needed a recharge rate higher than the power the torque wheel expended in order to actually get a net positive recharge.) pull request
• Fix: UTF-8 text files that contain a BOM (Byte Order Mark) are now parse-able. (Notepad.exe was really the only text editor that triggered this problem. No other editors put a BOM in UTF-8 files.) pull request
• Fix: If you lock steering from the interpreter, then also run a program that locks steering, that program used to bomb with error when it tried to exit and return to the interpreter. pull request
• Fix: Using the meta-key AltGr on some European keyboards was causing garbage to appear in the terminal interactive prompt, but only on the Linux port of Unity3d. Again, Unity3d does weird things in its Linux port for no apparent reason (they're not because of the OS itself), that we have to accommodate. pull request
• Fix: Bulkhead profile added to part files. It is required for the new KSP 1.6.x filtering "by diameter" feature. Without it, the VAB could hang forever when a user clicks that tab. pull request
• Fix: Map View no longer rotates with the vessel when focus is on the terminal window. It's a stock bug that required a bit of trial and error to pin down, then an ugly kludge to keep it from being triggered. pull request
• Fix: OrbitInfo:TOSTRING now prints the body name properly. pull request

NEW FEATURES:

• Made several of the string parameters to GUI widgets optional. pull request
• Massive refactor of how trigger interrupts work, that allows them to behave more consistently and allows more complex layering of triggers. (In this CHANGELOG, This is listed both under "new features" and "bug fixes" since it's both.) pull request
• Allow "close window" button to exist on the RMB menu. pull request
• New suffixes to read if Body has a surface, an ocean, or children. pull request
• Added KUNIVERSE:REALTIME and KUNIVERSE:REALWORLDTIME. pull request
• Vecdraw now can set updater delegates directly in its constructor. pull request
• All command codes in a script text file will be treated as whitespace now, just in case there's any in there junking up the file. pull request
• Add a "CID" Craft-ID suffix to Parts. pull request
• Constant:G is now being calculated from the game itself instead of being a manually typed constant in the kOS source. pull request
• New value, Constant:g0 - useful for ISP calculations. pull request
• Make terminal's "dim" unfocused mode stop being transparent, for extra readability. (It was never transparent enough to usefully see through, but it was transparent enough to make it hard to see the letters.) pull request
• GUI tooltips now implemented. pull request
• Fix: All the image files and texture files are using .DDS format now, and both X and Y resolutions for them have been resized to exact powers of 2, which DDS requires. (Unity loads DDS files faster, and they form a smaller download ZIP). pull request

[MaltYebisu]

Wow! Congratulations on the release! 

I want to try it right away 

[Dunbaratu]

Important bug in the latest release:

Apparently MAXTHRUST is now returning the max the engines would have in vacuum, regardless of whether you're in vacuum or not right now.  (It's supposed to return the max you currently have in your current atmospheric situation.)  For a lot of engines, that's a big difference.

There's a fix proposed by the author of the original PR that broke it, but I want to make sure I understand that fix before I merge it.  I'm awaiting a response from the author.  If I get that response before the end of the afternoon, I'll make a quickfix release today.  Else I'll have to wait till tomorrow.

[Drew Kerman]

hoooolly moholey, at last! yay! Has anyone tried this on v1.5.1 yet? I'll report back when I get a chance if not

[Devoblue]

Thanks for your work on this. Much appreciated.

The first thing I noticed with this was that my ascent script progressively turned ksp to glue, slowing down the simulation so much that phys warp 3 was approximately real time by the time I was a minute into flight.  I guessed that this was because I was locking steering and throttle every pass through a loop, so I optimised these and performance went back to expected.  This was a gradual process of slowing down so I wonder if there is some loss or inefficiency in LOCK that worsens over time.

 

 

[Dunbaratu]

IMPORTANT QUICKFIX UPDATE v1.1.6.1

The bug with MAXTHRUST being reported wrong (as if in vacuum even when at sea level) is fixed in this quick release.  If you obtained v1.1.6.0, then please update it to v1.1.6.1 immediately.

As I type this, the kOS-v1.1.6.1 update is already available on Spacedock and Github, but it won't show up on Curseforge and CKAN for a few hours yet.

[RizzoTheRat]

Can anyone enlighten me as to how functions operate within the file structure.  I'm clearly missing something about what's allowed to call what, but as far as I can see in the documentation I should be able to declare a global function that I can load and call from anywhere.

I have a boot script which calls a script specific to the ship, and I then have couple of scripts containing just functions.

If I run the functions scripts from within the boot script I can happily call them from the ship script.

However if boot script calls the ship script, and the ship script calls the function scripts before trying to run any of the functions, it says the function name is an unknown variable when I try to run it.   The function scripts are showing up on the KOS module if I list files, and if I put a print statement in the file it's definitely running, but I just can't call the scripts.

 

Boot file

Clearscreen.
core:part:getmodule("kOSProcessor"):doevent("Open Terminal").
SWITCH TO 1.
Function LoadFile{
	Parameter FileName.
	print "Loading File - " + FileName.
	COPYPATH("0:/" +FileName +".ks", "").
	RUNPATH("1:/"+Filename+".ks").
}
LoadFile("Funcs-Common").
//LoadFile("Funcs-Launch").
if ship:altitude<1000{
	Loadfile(ship:name).
}

Ship script

Set TurnVel to 30.
Set TurnPitch to 12.
Set LaunchBearing to 90.
Set LaunchApo to 80000.
Set LaunchStages to 2.
Set MaxQ to 0.5.
LoadFile("Funcs-Launch").

Set KUNIVERSE:TIMEWARP:MODE TO "PHYSICS".
Set ShipHeading to ship:facing:vector.
Lock Steering to ShipHeading.
Set Thrott to 0.
Lock Throttle to Thrott.
print "Launching " +ship:name.

Launch.
QClimb.
FinalApo.
Circularize("Ap").

Print "End of script".
	

Funcs-Launch

Print "Loading function Launch".
Global function Launch{
	Print "Launch Function Running!".
}

 

I've tried defining it as Function Launch as well as Global Function Launch without any difference.  It prints the line about it loading but falls over when I try to run it.

[Dunbaratu]

5 minutes ago, RizzoTheRat said:

I've tried defining it as Function Launch as well as Global Function Launch without any difference.  It prints the line about it loading but falls over when I try to run it.

Does it work better if you use empty parentheses on the call, calling "Launch()" instead of just "Launch"?

[RizzoTheRat]

Damn you're good, works like a charm   Doesn't even need to be a global function.  Odd that it works fine without the parentheses if the script is run in the boot script though.

Thanks

 

[Dunbaratu]

Another quickfix release - v1.1.6.2

"Feature"?:

The terminal's background image is now much darker, increasing the contrast you see with the text so it is a lot easier to read.

BUG FIX:

This fixes the issue some people have on some graphics cards with Direct3D in kOS-v1.1.6.0, where image textures wouldn't load and the icons were blank black rectangles.  It has to do with the step KSP takes to convert images from PNG to DDS not working on some people's graphics cards (it uses the GPU to perform the conversion at runtime, apparently, not not all cards support doing it at all resolutions).  So we just published the files as DDS ourselves to bypass that conversion step that doesn't quite work right.  People with cards that had the problem have reported to me that this change fixed it.

 

[infinite_monkey]

With the latest update, the kOS icon is now a purple square

Playing on Linux with open source AMD drivers (Radeon RX 470)