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

[Dunbaratu]

We expect to delay any update to kOS until after KSP 1.4.1 comes, given that KSP 1.4.1 is expected next week and is likely to break things again.  If we published an update today, it would be a version that only works for about 4 days before it breaks again and we have to make another update.  We'd rather just wait and do it once.

[firda]

Was not so hard to make it working again, but I had to delete that FunctionHsva as I do not have the same knowledge as you.
Unity complained about audioClip and few things, so, I have used the suggestion Visual Studio showed me... and, can play again,
my launch script works, my control gui works, all looks good. I do not expect 1.4.1 will break it again.

[Sebra]

So there is a working version of kOS already. It would be good to have.

What part is not working due to deleted function?

We can of course wait till 13 no problem.

p.s. in CKAN max KSP version for kOS marked 1.2.2 for some strange reason.

Edited March 10, 2018 by Sebra

[scimas]

3 hours ago, Sebra said:

p.s. in CKAN max KSP version for kOS marked 1.2.2 for some strange reason.

If I remember correctly, the latest version of kOS was specifically released to address some issue with 1.2.2. That version isn't compatible with 1.3.1, but the second to latest version is. Hence CKAN showing latest supported version 1.2.2.

[firda]

8 hours ago, Sebra said:

So there is a working version of kOS already. It would be good to have.

What part is not working due to deleted function?

We can of course wait till 13 no problem.

They know better how to fix that HsvaColor, see https://github.com/KSP-KOS/KOS/pull/2241

I am not KOS dev, I was just impatient and built my own version

[Sebra]

I had no doubts kOS would be updated.

I believe "short time before next version" is not a good reason to not publish already working update.

But I'm patient enough to wait properly. It seems devs of this beautiful mod are not the only devs, who wait for the next update release.

[scimas]

13 hours ago, Sebra said:

I believe "short time before next version" is not a good reason to not publish already working update

Why? It's perfectly a good enough reason. 1.4 was released about a week ago, 1.4.1 will come in 2-3 days. Why would you want to release an update that's going to be used for only about 10 days? You do realise that mod developers don't get paid for the work they put in, don't you? Depending on the amount of work needed to get the mod working for a new ksp version, it is a massive waste of their personal time if the update is used only for a few days. 

And it isn't a working version from the devs. A non developer person got it working for themselves. The devs aren't holding back a working version. 

[Sebra]

5 hours ago, scimas said:

Why?

You mentioned exact reasons not to demand update from devs. So let be patient.

From the other side _IF_ they have working already version on github or anywhere, they _CAN_ release no matter when next KSP version would be released.

Reasons:

1. Why to wait if work is already done?

2. Changes can be so minor, kOS for 1.4 would by chance work for 1.4.1. Can they?

3. Do you think firda the only one impatient here?

BTW great thanks to developers. You are the best!

[Dunbaratu]

13 hours ago, Sebra said:

You mentioned exact reasons not to demand update from devs. So let be patient.

From the other side _IF_ they have working already version on github or anywhere, they _CAN_ release no matter when next KSP version would be released.

Reasons:

1. Why to wait if work is already done?

2. Changes can be so minor, kOS for 1.4 would by chance work for 1.4.1. Can they?

3. Do you think firda the only one impatient here?

BTW great thanks to developers. You are the best!

The reason is that there's an annoyingly long checklist we go through when we make a release and double- and triple- check things.  There's also a suite of regression tests I run that can't entirely be automated because it involves actually playing the game.  Doing so and then doing it again right away a few days later is a little frustrating.

[Ernos]

Will this version of kOS work in 1.4? I am working on a cruise missile that needs kOS. I am also gonna try, but I want to know if something doesnt work because of my stupidity or the game version.

[Dunbaratu]

5 hours ago, Munar pilot said:

Will this version of kOS work in 1.4? I am working on a cruise missile that needs kOS. I am also gonna try, but I want to know if something doesnt work because of my stupidity or the game version.

It does not work for 1.4.  Squad announced that 1.4.1 is coming when the DLC happens (scheduled for Tuesday this week, if they get it out when expected), and we're waiting for that.  If 1.4.1 doesn't come out on time, then I may release the 1.4 version we have.

 

[Ernos]

15 hours ago, Steven Mading said:

It does not work for 1.4.  Squad announced that 1.4.1 is coming when the DLC happens (scheduled for Tuesday this week, if they get it out when expected), and we're waiting for that.  If 1.4.1 doesn't come out on time, then I may release the 1.4 version we have.

 

Ok, thank you. I plan on getting the DLC

[hvacengi]

New release:

v1.1.5.2 - Basic Compatibilty for KSP 1.4.1

 

This release is mostly just a recompile to make kOS work with
KSP 1.4.1, with the few changes that were needed to keep it
working, and whatever bug fixes happened to already be
implemented when when KSP 1.4.1 came out.

DOWNLOADS:

Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.1.5.2
Curse: https://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files/2540960
Spacedock: https://spacedock.info/mod/60/kOS: Scriptable Autopilot System

Edited March 14, 2018 by hvacengi

[maculator]

I have a noobish question :s

I wanted to play arround with KOS after a long time and I'm just too stupid I guess....

I got my bootscript running:

declare global function hudmessage {
	parameter message.
	hudtext ("KOS: " + message, 5, 2, 30, green, false). //40 is too big!
}

hudmessage("loading script").
wait 1.
copypath("0:/tourist.ks","1:/tourist.ks").
wait 1.
hudmessage("done").

and I'm unable to access the function hudmessage from the script the bootscript loads....

It just keeps throwing errors on me.

All the script contains for now is:

hudmessage("I'm tourist.ks").

I thought since I declared the function in my bootscript and that script is on the drive it would be accessible for everyone.

Do I need to declare it again outside the bootscript? If yes: why?

Cheers.

[ElWanderer]

7 hours ago, maculator said:

I'm unable to access the function hudmessage from the script the bootscript loads.

Does your boot script end, then you run tourist.ks manually? Functions and variables set by a script only stay available while that script is running.

My approach is to set-up the mission files as boot scripts and have each one run common library/init scripts on start-up.

If your boot script is copying tourist.ks into place then running it, that should work.

 

Edited March 21, 2018 by ElWanderer

[Dunbaratu]

48 minutes ago, ElWanderer said:

Does your boot script end, then you run tourist.ks manually? Functions and variables set by a script only stay available while that script is running.

My approach is to set-up the mission files as boot scripts and have each one run common library/init scripts on start-up.

If your boot script is copying tourist.ks into place then running it, that should work.

 

To put this another way - any time you drop back to the interpreter prompt, all loaded library functions are deleted.  To use a library function, it has to have been loaded (run) by the program that's using it.  We considered making them persist after program death, but decided against it  because that would mean needing a good way to choose to remove them later, or else crud would accumulate after multiple runs.  Also, we'd then have to deal with relocatable code in the memory array where the opcodes are stored (so you can delete a function and reclaim its space).  Right now we don't have to bother because we can just remove everything when the program ends.

[maculator]

Thanks guys. So using my bootscript to run a "libary.ks" wich contains all my functions won't help.

I think I got it now, if I understand it correctly:

Bootscript to load the actual script and the actual script "runs" the functions script it needs first to make the functions available.

I do love KOS, but I have no codin experience so I sometimes struggle a bit, but I'm making progress. thanks.

 

[maculator]

Allright it all worked out. Exept I stil don't know how to be able to load functions and execute them myself.

Problem: bootscript boots script with functions and runs it (does obviously nothing), all good, but when I want to start a function it won't let me.

I can't run start(12) for example.

Here is what I mean:

Bootscript:

(this is not the problem)

Spoiler

//bootlaunchdirection.ks
//
//boots "launchdirection.ks" to a vessel.
IF exists("1:/launchdirection.ks") = true {
	deletepath("1:/launchdirection.ks").
	IF exists("0:/launchdirection.ks") = true {
		copypath("0:/launchdirection.ks","1:/launchdirection.ks").
		print "launchdirection.ks copied to 1:/".
	} ELSE {
		print "launchdirection.ks not found on 0:/".
	}
} ELSE {
	IF exists("0:/launchdirection.ks") = true {
		copypath("0:/launchdirection.ks","1:/launchdirection.ks").
		print "launchdirection.ks copied to 1:/".
	} ELSE {
		print "launchdirection.ks not found on 0:/".
	}
}
runpath("1:/launchdirection.ks").

 

Problem is the booted script:

(the last line is a workarround, because that's what I'd like to do myself via the console, but I can't. It's not allowing me :S)

Spoiler

//launchdirection.ks
//
//provides a function to launch a vessel into a suborbital trajectory with a user defined direction.
function stagecheck {
	WHEN ship:maxthrust < 0.01 THEN {
		IF ship:liquidfuel > 1 or ship:solidfuel > 1 {
			stage.
		} ELSE {
			print "out of fuel".
		}
	}
}
function ascentstep {
	parameter targetaltitude, targetdirection, targetangle.
	UNTIL ship:altitude > targetaltitude {
		lock steering to heading(targetdirection, targetangle).
		stagecheck().
		wait .1.
	}
}
function start {
	parameter targetdirection.
	print "start into heading " + targetdirection + "°".
	ascentstep(1000,		targetdirection, 90).	
	ascentstep(2000,		targetdirection, 80).	
	ascentstep(5000,		targetdirection, 65).	
	ascentstep(10000,	targetdirection, 45).	
	ascentstep(20000,	targetdirection, 30).	
	ascentstep(30000,	targetdirection, 25).
	ascentstep(40000,	targetdirection, 20).	
	Until ship:apoapsis > 71000 {
		lock steering to heading(targetdirection, 0).
		stagecheck().
		wait .1.
	}
	set ship:control:pilotmainthrottle to 0.
	sas on.
	print "ascent complete".
}
start(90). //WORKARROUND I WANT TO DO THIS WITH CUSTOM PARAMETERS VIA THE CONSOLE!

 

Edit:

It's probably something small I don't get. The reason for making a new post is that I'm hoping to get a quick fix because thats the first set of scripts I wrote from 0 that actually (besides the drama) work out of the box without that horrible "somethings wrong" -sound from KOS. I'm really motivated to keep on working.

If this is the wrong thread to ask for help I'd be glad if somebody can point me to a better location.

Cheers.

Edited March 21, 2018 by maculator

[Dunbaratu]

40 minutes ago, maculator said:

  Hide contents

start(90). //WORKARROUND I WANT TO DO THIS WITH CUSTOM PARAMETERS VIA THE CONSOLE!

 

 

A program itself can also take parameters.  You can include parameter statements at the top of a program file, then do:
 

run myprogram(arg1, arg2, arg3....).

 

[maculator]

Awsome, now it works.

[kcs123]

Just now, maculator said:

Awsome, now it works.

Not so long ago, I posted example of my launching scripts in other thread. I often use some sort of library scripts with collection of functions in combination of main scripts.
You may use it as example how to combine functions and triggers.

 

[maculator]

6 hours ago, kcs123 said:

Not so long ago, I posted example of my launching scripts in other thread. I often use some sort of library scripts with collection of functions in combination of main scripts.
You may use it as example how to combine functions and triggers.

 

it only contains KOS, a few crafts and strange things, no scripts.

[Crimsyn]

I'm having some issues trying to communicate with the telnet server. I'm very new at this, and just scraping what I can off the web, but I'm running into a brick wall here. To get right to it, if my log shows

[LOG 01:27:28.591] kOS: Telnet client just told us its terminal type is: "VT100".
[LOG 01:27:28.592] kOS: Telnet client just told me its window size is 80x24.

then doesn't that mean I've properly sent my ident and dimension data to the server?

But, what's happening for me, is even after those log entries are made, the server just keeps spamming IAC SB TTY 1 IAC SE.

Do i need to send one large command at once, or break it down into individual sets?

 

I thought IAC DO SGA IAC DO ECHO IAC WONT ECHO IAC WILL SGA IAC WILL TTY IAC WILL NAWS was the correct setup, followed by SB on TTY and NAWS after agreement?

which would have been IAC SB TTY IS VT100 IAC SE and lastly IAC SB NAWS IS 0 80 0 24 IAC SE

 

Am I misunderstanding how the spec is written?

 

KOS seems to jump right to "TELL ME YOUR TTY, NAO!", and even when I do jump straight to it, and the log shows it received, it just keeps asking. Sorry if this stuff is simplistic or obvious, but I've just started with this and could really use some pointers here!

 

The whole reason for doing this in the first place, was just for me to make my own little control panel with controls and maybe some flight data that I could display on my laptop. I know there are mods that do this already, some good and some not so hot, but none of them are mine, and I won't learn anything interesting by using them.

 

 

 

 

 

 

[kcs123]

13 hours ago, maculator said:

it only contains KOS, a few crafts and strange things, no scripts.

Look at my post on that thread under spoiler section. Have no idea why forum linked OP from that thread instead of my own post. I will try to link again on exact post from thread:

You need to click on link next to my nick name for exact post, instead of forum title.

 

[hvacengi]

9 hours ago, Crimsyn said:

I'm having some issues trying to communicate with the telnet server. I'm very new at this, and just scraping what I can off the web, but I'm running into a brick wall here. To get right to it, if my log shows

[LOG 01:27:28.591] kOS: Telnet client just told us its terminal type is: "VT100".
[LOG 01:27:28.592] kOS: Telnet client just told me its window size is 80x24.

then doesn't that mean I've properly sent my ident and dimension data to the server?

But, what's happening for me, is even after those log entries are made, the server just keeps spamming IAC SB TTY 1 IAC SE.

Do i need to send one large command at once, or break it down into individual sets?

I thought IAC DO SGA IAC DO ECHO IAC WONT ECHO IAC WILL SGA IAC WILL TTY IAC WILL NAWS was the correct setup, followed by SB on TTY and NAWS after agreement?

which would have been IAC SB TTY IS VT100 IAC SE and lastly IAC SB NAWS IS 0 80 0 24 IAC SE

Am I misunderstanding how the spec is written?

KOS seems to jump right to "TELL ME YOUR TTY, NAO!", and even when I do jump straight to it, and the log shows it received, it just keeps asking. Sorry if this stuff is simplistic or obvious, but I've just started with this and could really use some pointers here!

The whole reason for doing this in the first place, was just for me to make my own little control panel with controls and maybe some flight data that I could display on my laptop. I know there are mods that do this already, some good and some not so hot, but none of them are mine, and I won't learn anything interesting by using them.

The telnet part of the mod isn't exactly in my wheelhouse, but it sounds like you're pretty well versed in the underpinnings for telnet itself so I thought there might be some benefit pointing you towards the mapper for VT1000: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/UserIO/TerminalVT100Mapper.cs

You may also want to look at the telnet singleton server: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/UserIO/TelnetSingletonServer.cs

I know that when @Steven Mading worked on the telnet code, he spent a lot of time looking through the standards along with some of the unofficial implementations.  But there's always a chance we got something wrong.  If you find an issue before he is able to reply, please feel free to post it and let us know.