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

[Grigetio]

@Steven Mading

I've created a pull request to fix the loading of the DDS textures for 1.8 (and all other versions I presume). At least that part will work .

P.S. Yes it was under my other pseudonym.

Edited October 20, 2019 by Grigetio

[Dunbaratu]

2 hours ago, Grigetio said:

@Steven Mading

I've created a pull request to fix the loading of the DDS textures for 1.8 (and all other versions I presume). At least that part will work .

P.S. Yes it was under my other pseudonym.

Can you elaborate on a specific scenario, hardware and OS, where it was failing before this PR, but working after it?  I ask because I never saw the original texture problems other people reported so I'd like to know an exact thing to do to make it happen.  I fear it may be graphics card dependent, as DDS decoding is sometimes done by the device driver.

[Grigetio]

Windows 10, Nvidia, Intel

I do have some graphics wonkiness (in the toolbar right now, purple box) which I haven't looked at at least in terms of the image itself. Maybe I'll poke around since I have it open.

Regardless, I think there is an issue in KSP 1.8. The KSP method I commented out just returned null, no matter what I did with the images. I have no idea what they're doing under the hood. Of course I'm not a graphics expert either.

Having said that, I am curious about my purple button.

 

Edit: I do remember the purple button was there before, and then 'fixed' somewhere along the line. Weird.

Edited October 20, 2019 by Grigetio

[Grigetio]

My purple problem was particular to my person.

Toolbar couldn't find the texture, but that was because I was running a directory deeper than normal, so no worries there. Everything appears to work with the icons now, with the code I checked in.

[Lookerksy]

kOS has User Function. Will kOS has User Structure?

I want to write PID controller by myself. But kOS's PIDLoop Structure can not be changed.

[DarkNounours]

I've just given a try to kOS in 1.8.1. All seems to work fine until I run a script. I have an unexpected error on the SHIP object such as

// Save the current vessel in a variable,
// in case the current vessel changes.
SET MY_VESS TO SHIP.

kOS says Undefined Variable Name 'ship'.

Also found that lock Throttle to is not working anymore.

[fulgur]

Yes I had the same problem.

Plus the variable 'up' was also undefined.

[kcs123]

@DarkNounours, @fulgur,  there is a reason why kOS not working properly. From previous page:

On 10/19/2019 at 8:55 PM, Steven Mading said:

... kOS is almost completely broken on KSP 1.8 and that's the problem you're having.  All of kOS's bound variables are missing in KSP 1.8 - verticalspeed, core, ship, velocity, apoapsis, etc.  I know why and fixed it in the develop branch but there's other problems with the KSP 1.8 update I need to fix first before I release a kOS that's compatible with KSP 1.8.

(Without going into too much detail, the problem was apparently caused by a very subtle difference in how "Reflection" does things in the newer C#/.Net, causing some Types to be "Equal" which were not "Equal" before.  kOS was storing information about these Types in a collection that requires unique keys and this change meant they weren't unique anymore.)

Edited November 1, 2019 by kcs123

[Dunbaratu]

Update for KSP 1.8.1 released.

Special thanks to @Thunderous Echo, who started contributing to the code with this release.

v1.2 Unity Update

This update is mostly to make kOS compatible with KSP 1.8.x, which started using a newer version of Unity, and a newer version of .Net, which have some consequent changes in the code and build process.

BREAKING CHANGES

None that are known about, other than the usual reminder that KSM files need a recompile after every version update of kOS.

NEW FEATURES

• Now forces both the toolbar window and the telnet welcome menu to list the kOS CPUs in a consistent unchanging sort order. Previously, it was pretty much random what order you would see kOS CPU's listed in the menu, which made it hard for JonnyOThan's Twitch-Plays-KSP chatbot to know which CPU it was attaching to when it sent commands to kOS. This has been changed to a predictable sort order as follows: (1) Sort by which vessel the CPU is on, starting from the active vessel, and then for other vessels, sorting by distance from the active vessel, closest first. (2) When the same vessel has more than one CPU, break that tie by number of "hops" from the root part, such that CPU's attached closer to the root come first. This is by "number of parts to walk through to reach root" rather than by actual physical distance, since using physical distance might have led to inconsistent sort order given that some ship parts can hinge and extend, changing that distance. pull request
• New suffixes Dockingport:PARTNER and Dockingport:HASPARTER will tell you which docking port this docking port is docked with. issue pull request
• HEADING() Now allows optional 3rd argument, "roll". issue pull request
• Let user-made GUIs toggle IMGUI's wordwrap flag with a new suffix: Style:WORDWRAP. This should let you fix that annoying problem where a GUI Label would insist on wrapping even when it could have fit by making the window wide enough. Setting wordwrap to false will force the GUI layout engine to keep the label's area wide enough to not wrap the text. issue pull request
• Add BODYEXISTS test issue pull request
• Allow FLOOR() and CEILING() to specify a decimal place other than the one's place, like ROUND() can do. issue pull request
• Add a constructor, CREATEORBIT() that will make a new Orbit object for any hypothetical orbit given Keplerian parameters, without it coming from a vessel or a body that already exists. issue pull request
• Added new suffix to waypoint: :ISSELECTED, which will tell you if the waypoint is the one the user has selected for their navball. issue pull request

BUG FIXES

• Bound variables like SHIP, UP, VELOCITY, etc stopped existing in the KSP 1.8.x update. This was because kOS makes use of reflection techniques to store information about C# Attributes that help it find the bound variables in its code, and .Net 4.x changed the meaning of Attribute.Equals() in such a way that it broke what kOS was doing to store this reflection information. A Dictionary that kOS was using to track bound variables by Attributes started having key clashes because of that change to what it means for an Attribute to be Equal to another Attribute. ((No link to a github issue because this was part of the general KSP 1.8 update PR and didn't have an issue.))
• Prevent waypoints with bogus body names. pull request
• Fix a problem that made the GUI terminal sometimes get stuck refusing to repaint when resized to a size too small to hold all the text it previously had showing. issue pull request
• Several minor doc typos pull request pull request
• The startup message about default font and "if you want the old look" was quite obsolete by now and needed to be removed. issue pull request
• Changed the technique used to load DDS icons used in the kOS GUI terminal and the kOS toolbars, to bypass KSP's strange API and go directly to Unity. This may or may not help people who had the purple square icon problem. ((No issue - SlimJimDodger contributed PR out of the blue.)) pull request

[DarkNounours]

Thank you very much guys for the work provided!

[SiRCrashaLot]

 

[fulgur]

I don't know why this is happening. I just re installed kOS for 1.8.1 and it is not working. Reinstalled it again (see error message) and it still isn't working. It worked before (well got past this part anyway) with the old version. I have got the .dds files in my KSP_linux/Game Data/kOS/GFX so I don't know why it isn't working.

Running 1.8.1 without many mods and with Ubuntu 18.04 LTS.

Edited November 2, 2019 by fulgur

[Dunbaratu]

kOS v1.2.0.0.zip is broken on UNIX platforms.

The PR contributed for DDS fixes had hardcoded backslashes in the filenames, which I thought .Net libraries would make cross-platform but they do not.  It only makes it cross-platform in one direction but not the other.  (The .Net file routines will convert Unix paths (with slashes) so they work on Windows, but won't map the other way.  They don't convert Windows paths (backslashes) to work on UNIX.)  I'm making a new ZIP which has the paths in the UNIX way so they'll work on all platforms.

[JebIsDeadBaby]

First, I must admit I'm not sure it's a kOS bug but anyway... The problem I have is that if a ship has no connection to the KSC when a script starts (e.g. via a boot file), then it can't control ship's attitude (at least via RCS and reaction wheels, a working gimballed engine will do the job AFAIR). I use CommNet, with PermitAll the problem does not occur. I saw someone's comment that that's CommNet's limitation and kOS can't do much about it, but the thing is everything works just fine if a script gets started with a working connection. Then, even if connection goes down during execution of the script, kOS retains control over ship's attitude. Anyone has the same problem?

Edited November 2, 2019 by JebIsDeadBaby

[Dunbaratu]

13 minutes ago, Steven Mading said:

kOS v1.2.0.0.zip is broken on UNIX platforms.

The DDS texture loading bug on UNIX platforms should be fixed in the hotfix I just released, called v1.2.1.0.

I do not have access to a Linux or Mac machine powerful enough to run KSP (mine are very old computers) so I cannot test this myself.  I am *hoping* the change I made fixes it.  Please try it and let me know.

10 minutes ago, JebIsDeadBaby said:

First, I must admit I'm not sure it's a kOS bug but anyway... The problem I have is that if a ship has no connection to the KSC when a script starts (e.g. via a boot file), then it can't control ship's attitude (at least via RCS and reaction wheels, a working gimballed engine will do the job AFAIR). I use CommNet, with PermitAll the problem does not occur. I saw someone's comment that that's CommNet's limitation and kOS can't do much about it, but the thing is everything works just fine if a script gets started with a working connection. Then, even if connection goes down during execution of the script, kOS retains control over ship's attitude. Anyone has the same problem?

Try to put a wait of a few seconds into the top of the boot script.  It sometimes will load the ship and let its PartModules start operating (like kOS) before KSP has finished loading up and populating Comnet fully.  Waiting 2 or 3 seconds should give commnet time to finish settting itself up.

[Dunbaratu]

I uploaded the wrong ZIP file for v1.2.1.0 to the three sites (curseforge, spacedock, github) and just uploaded a corrected version.  If you obtained it within the last 2 hours, please download it again to get the new correct ZIP.

[JebIsDeadBaby]

12 hours ago, Steven Mading said:

Try to put a wait of a few seconds into the top of the boot script.  It sometimes will load the ship and let its PartModules start operating (like kOS) before KSP has finished loading up and populating Comnet fully.  Waiting 2 or 3 seconds should give commnet time to finish settting itself up.

That's not it, I already do it. 

But here is the thing - it always happens to me in Mun SOI, when I use my script that performs Mun orbit departure. The important part of code look like this:

until vang(KERBIN:POSITION, MUN:POSITION) > 160 
{
	print "Angle: " + round(vang(KERBIN:POSITION, MUN:POSITION),2) + "     " at (0,10).
}

RCS ON.

lock shipDptDir to ship:prograde + R(0,max(0, 2*(vang(ship:prograde:vector, kerbin:position)-90)),0).
lock steering to shipDptDir.

wait until vang(SHIP:FACING:VECTOR, shipDptDir:VECTOR) < 1.

So it basically waits until the ship finds itself almost directly between the Mun and Kerbin, then rotates the ship prograde (with a small correction in case prograde points away from Kerbin) and the at vang > 175 initiates the burn (code not shown above). So up to RCS ON everything works fine, then (if there is no connection) the ship just stays motionless. Those little indicators for pitch, yaw and roll in the bottom left corner of the screen do not move at all, so it's not like the script tries to rotate the ship but can't, it simply does not try. So it looks like steering command is not executed properly. If the connection returns at some point, then steering starts doing it's job. 

I also pasted the code above to a test script and used it as a boot file for a ship I put in Mun's orbit via a cheat in sandbox mode. With no connection the code executed correctly, which puzzles me even more. There is literally nothing in my script before this code that could affect steering IMO - the boot file just chooses the right file to execute (the one that contains this code) and there is one trigger that checks for engine flameout. Then it's the code above. 

[RizzoTheRat]

On 11/2/2019 at 1:50 AM, Steven Mading said:

Update for KSP 1.8.1 released.

Awesome work guys, love this mod.  

Quick question, is this back compatible with 1.7.x or should I stick with the older version until I update to 1.8.x? 

[Dunbaratu]

1 hour ago, RizzoTheRat said:

Awesome work guys, love this mod.  

Quick question, is this back compatible with 1.7.x or should I stick with the older version until I update to 1.8.x? 

Because of the changes to Unity, I seriously doubt it will work right on 1.7.x, although I haven't tested to verify this.

On 10/20/2019 at 2:20 PM, Grigetio said:

@Steven Mading

I've created a pull request to fix the loading of the DDS textures for 1.8 (and all other versions I presume). At least that part will work .

P.S. Yes it was under my other pseudonym.

BTW, I never had the problem the PR allegedly fixed.  The original code loaded textures in 1.8 just fine.  But I trusted that there was some case where the change was needed but it was a case I didn't have.

Ironically, the PR actually *caused* textures to fail to load for many people.  It hardcoded Windows-style backslashes instead of slashes into the pathname, so the PR caused the texture errors people on  UNIX systems were getting.  Anyway, it's all good now in kOS v1.2.1.0, where I took your PR but swapped the backslashes for slashes and it now works cross-platform.

[Dunbaratu]

3 hours ago, JebIsDeadBaby said:

That's not it, I already do it. 

But here is the thing - it always happens to me in Mun SOI, when I use my script that performs Mun orbit departure. The important part of code look like this:

until vang(KERBIN:POSITION, MUN:POSITION) > 160 
{
	print "Angle: " + round(vang(KERBIN:POSITION, MUN:POSITION),2) + "     " at (0,10).
}

RCS ON.

lock shipDptDir to ship:prograde + R(0,max(0, 2*(vang(ship:prograde:vector, kerbin:position)-90)),0).
lock steering to shipDptDir.

wait until vang(SHIP:FACING:VECTOR, shipDptDir:VECTOR) < 1.

So it basically waits until the ship finds itself almost directly between the Mun and Kerbin, then rotates the ship prograde (with a small correction in case prograde points away from Kerbin) and the at vang > 175 initiates the burn (code not shown above). So up to RCS ON everything works fine, then (if there is no connection) the ship just stays motionless. Those little indicators for pitch, yaw and roll in the bottom left corner of the screen do not move at all, so it's not like the script tries to rotate the ship but can't, it simply does not try. So it looks like steering command is not executed properly. If the connection returns at some point, then steering starts doing it's job. 

I also pasted the code above to a test script and used it as a boot file for a ship I put in Mun's orbit via a cheat in sandbox mode. With no connection the code executed correctly, which puzzles me even more. There is literally nothing in my script before this code that could affect steering IMO - the boot file just chooses the right file to execute (the one that contains this code) and there is one trigger that checks for engine flameout. Then it's the code above. 

I don't know what to say.  I can't tell what's happening.  I can only suggest trying one of these two things, as they have made a difference in the past:

1 - If it's a manned ship with no unmanned capability (only a crewed capsule, no probe core), try adding a probe core to it as sometimes the comms system doesn't bother doing work when the capsule is manned, under the assumption it doesn't need to bother checking for connection for control when the ship requires a person in it anyway to control it.

2 - If the antenna is of the "direct" type, try having a "relay" type antenna on it as well as (or instead of) the direct antenna.  Some aspects of the comms system seem to only be loaded by KSP when the vessel is relay-capable, as some kind of way to save CPU cycles, again under the false assumption that commnet only has to check for human control ability and the subsystem that checks for distance and hops doesn't need to exist when nobody else could be piggybacked onto the connection to this ship.

[CardboardGuy]

This sounds really cool! And also, what language is kerboScript based off of?

[Dunbaratu]

8 hours ago, CardboardGuy said:

This sounds really cool! And also, what language is kerboScript based off of?

It seems to be home-made and not "based on" anything pre-existing.  Originally it was meant to sort of feel like the slow primitive BASIC interpreters that 1980's era home computers tended to have.  In fact the original terminal was painted using a bitmap template taken from the Commodore 64 character set to give it that look.  (I've since changed it to use a real system font from your computer OS, so it can support more Unicode glyphs for people printing things out in Russian, Polish, Japanese, or whatever.  The C-64 font has a lot of nostalgia for me, but it only ever had glyphs for English letters.  I didn't want the job of having to draw out little bitmap images of all the letters in all the languages to add them to the texture template it was using, so I made the change to a real OS font to offload that burden onto the font makers not me.)   kOS has also passed through multiple hands of stewardship, with more than one person working on it so it currently looks very different from what the original person had in mind, probably.  (For example, the original had only global variables, with no local variable scoping and no function calls, both of which I've added later.  Since I added them later, I have no idea if their syntax is "in line with" what the original author had in mind.)  I'm the current maintainer but not the original initial creator, and there's definitely stuff about it that I wouldn't have picked to be that way but I don't want to tear it to shreds and start over ruining everyone's existing scripts so I try to stick to the same "general" principles it appears to have started from, which are:

1 - Tends to use keywords more than punctuation.  i.e. "SET X TO 5." rather than "X = 5;".  Using a period (".") as a statement terminator instead of a semicolon or just an eoln like many other languages do.

2 - Reading it in English should sort of sound like what it does.  as in: Set x to 5.  lock throttle to 1. wait until altitude = 1000.  When blah is true then print "blah".   and so on.  (This is one of those styles I'm not a huge fan of, for reasons too long to go into right now, but I kept trying to adhere to it with the many features I added, because I figure keeping the whole language in the same style is still better than switching to a new style halfway through for the new stuff, while keeping old stuff in the old style, creating a style clash.)

As an example of *trying* to make it English-ish, when I wanted to implement something like the 3-part for loop of C: (the one that looks like this: for (init; check; increment) {body}), I struggled to find a way to make that sound vaguely english-like, when there's no real English construct that looks like that.  So I settled with FROM init. UNTIL check STEP increment DO body. to get the same general idea but kinda sorta make it look vaguely like english.

[DarkNounours]

Yeah I am not a huge fan of the syntax too but as soon as a goal can be achieved this is fine to me

[CardboardGuy]

6 hours ago, Steven Mading said:

It seems to be home-made and not "based on" anything pre-existing.  Originally it was meant to sort of feel like the slow primitive BASIC interpreters that 1980's era home computers tended to have.  In fact the original terminal was painted using a bitmap template taken from the Commodore 64 character set to give it that look.  (I've since changed it to use a real system font from your computer OS, so it can support more Unicode glyphs for people printing things out in Russian, Polish, Japanese, or whatever.  The C-64 font has a lot of nostalgia for me, but it only ever had glyphs for English letters.  I didn't want the job of having to draw out little bitmap images of all the letters in all the languages to add them to the texture template it was using, so I made the change to a real OS font to offload that burden onto the font makers not me.)   kOS has also passed through multiple hands of stewardship, with more than one person working on it so it currently looks very different from what the original person had in mind, probably.  (For example, the original had only global variables, with no local variable scoping and no function calls, both of which I've added later.  Since I added them later, I have no idea if their syntax is "in line with" what the original author had in mind.)  I'm the current maintainer but not the original initial creator, and there's definitely stuff about it that I wouldn't have picked to be that way but I don't want to tear it to shreds and start over ruining everyone's existing scripts so I try to stick to the same "general" principles it appears to have started from, which are:

1 - Tends to use keywords more than punctuation.  i.e. "SET X TO 5." rather than "X = 5;".  Using a period (".") as a statement terminator instead of a semicolon or just an eoln like many other languages do.

2 - Reading it in English should sort of sound like what it does.  as in: Set x to 5.  lock throttle to 1. wait until altitude = 1000.  When blah is true then print "blah".   and so on.  (This is one of those styles I'm not a huge fan of, for reasons too long to go into right now, but I kept trying to adhere to it with the many features I added, because I figure keeping the whole language in the same style is still better than switching to a new style halfway through for the new stuff, while keeping old stuff in the old style, creating a style clash.)

As an example of *trying* to make it English-ish, when I wanted to implement something like the 3-part for loop of C: (the one that looks like this: for (init; check; increment) {body}), I struggled to find a way to make that sound vaguely english-like, when there's no real English construct that looks like that.  So I settled with FROM init. UNTIL check STEP increment DO body. to get the same general idea but kinda sorta make it look vaguely like english.

Thanks. this seems kinda like block based programming languages, like scratch, or blockly.

 

[Idleness]

Hi, I'm basically new to kOS and trying it out with some web tutorials and the great documentation online.  Problem I'm having on my install though is that it doesn't seem to execute code properly - or at least, not in all cases.  There are apparently patches so that the basic command parts have kOS computers in them, nice.  I'm just using a basic ascent script to launch a bare-bones rocket and do a basic turn to a designated apoapsis.  Originally everything seemed to run fine.  I was modifying a boot script and simply reverting to try and run it.  Problem came when I made some functions and moved the launch/ascent to it's own file.  If I don't run in a boot script though the code doesn't seem to execute.

I had changed the boot from running everything to just copying the script to the local box (a Stayputnik probe core) and it should have executed the script after download.  Instead it did nothing.  Not error, nothing.  No feedback; just the cursor in the console waiting for more commands.  I tried to execute the file manually and it behaved the same.  The console did accept and run basic commands.  I locked steering to up.  I staged; I staged again, all with basic commands and no problems.  When I asked it to run the file it didn't work.

Anyone have this problem before?

edit - wanted to add this from the log.

[LOG 20:03:52.871] Unpacking Untitled Space Craft
[WRN 20:03:52.899] kOS: First Update()
[LOG 20:03:52.909] kOS: Pushing context staring with: File                 Line:Col IP   label   opcode operand
[LOG 20:03:52.914] kOS: Saving and removing 0 pointers
[LOG 20:03:52.930] kOS: FlightControlManager.AddTo 7c0d9999-4455-4ff7-8cd5-87502799390c
[LOG 20:03:52.945] kOS: Pushing context staring with: File                 Line:Col IP   label   opcode operand
[LOG 20:03:52.945] kOS: Saving and removing 0 pointers
[LOG 20:03:53.011] [UIMasterController]: ShowUI
[LOG 20:03:53.140] kOS: Open Window by event
[LOG 20:03:53.147] kOS: Breaking Execution Automatically Contexts: 2
[LOG 20:03:53.148] kOS: Popping context 2
[LOG 20:03:53.149] kOS: Removed Context File                 Line:Col IP   label   opcode operand
[LOG 20:03:53.150] kOS: Deleting 0 pointers and restoring 0 pointers
[LOG 20:03:53.150] kOS: New current context File                 Line:Col IP   label   opcode operand
[LOG 20:03:53.150] kOS: Execution Broken

 

Edited December 3, 2019 by Idleness