kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Please no, that would force you to keep a whole list of archived boot files, one for every craft. I liked your earlier idea much better, where any local file called boot would be executed upon booting.

But that has the opposite problem. If you have one start script appropriate to one kind of craft and another appropriate to another kind of craft you can't separate the two in your archive because they have the same name.

Also, I would very much like craft to run a script from where it left off when unloaded, but I can imagine this takes some doing. It would reduce the amount of boots in a massive way and makes missions where kOS is used flow much more naturally. Things like station keeping all of a sudden become a lot more viable.

There seems to be code attempting to do this already in kOS but it doesn't seem to work. At the moment it's hard to tell whether or not this is just because of the variable context loading bug or if there's other reasons it doesn't work. But it does seem to be trying to pick up where it left off when the craft reloads.

[Dunbaratu]

One potential legal hurdle to doing a fork is that while the licensing terms of the C# code are explicitly mentioned, there are also the part definition files to worry about (the SCS module's texture and mesh files and config file) and they're not in the github. Their licensing terms are unmentioned (and when it's not mentioned the default is that you can't do anything with it).

[sirkut]

One potential legal hurdle to doing a fork is that while the licensing terms of the C# code are explicitly mentioned, there are also the part definition files to worry about (the SCS module's texture and mesh files and config file) and they're not in the github. Their licensing terms are unmentioned (and when it's not mentioned the default is that you can't do anything with it).

The CFG and model is the easy part. Just create a new one or reuse a squad model with a new CFG.

[razark]

In regards to a boot script/autoexec, I like the idea of being able to specify one in the VAB description, and failing that, falling back to a boot.txt on Archive. I wouldn't mind seeing a way to preload programs at design time, so that you can automatically have that set of software on Volume 1 when you go to the pad.

[Camacha]

But that has the opposite problem. If you have one start script appropriate to one kind of craft and another appropriate to another kind of craft you can't separate the two in your archive because they have the same name.

That would not be a problem, as there is nothing that prohibits you from having a hyperjetboot next to a transporterboot and rocketboot. People tend to work on a certain craft for a period of time before switching to another, so all they need to do is temporarily rename their Hyperjetboot to boot and everything is set while working on that craft. Alternatively, you could also manually copy the appropiate file from archive to your local drive, rename, and all is well

Of course, this could mean you end up with a specific boot for each craft, but at least you do not have one for each instant of each craft (even though they might be exactly the same). So no need for a seperate Moonrocket1boot, Moonrocket2boot et cetera for what is essentially the same craft. And if you have a boot that is more universal the number of files will again be reduced.

Also, I think it is important that you can choose whether the file on the local disk will be overwritten or not. If you use the method of copying the file with the name of the craft from archive, you might overwrite your local file with changes that were not intended. But only if it is within range, adding unpredictability.

I would much prefer a simple solution to a complicated one.

[Dunbaratu]

That would not be a problem, as there is nothing that prohibits you from having a hyperjetboot next to a transporterboot and rocketboot. People tend to work on a certain craft for a period of time before switching to another, so all they need to do is temporarily rename their Hyperjetboot to boot and everything is set while working on that craft. Alternatively, you could also manually copy the appropiate file from archive to your local drive, rename, and all is well

This is no fewer steps than just not even having a boot program and copying some arbitrary program manually.

I would much prefer a simple solution to a complicated one.

Then why are you promoting one that is more complex? With what you're suggesting doing, its more complex than what I suggested.

Edited December 24, 2013 by Steven Mading

[Dunbaratu]

In regards to a boot script/autoexec, I like the idea of being able to specify one in the VAB description, and failing that, falling back to a boot.txt on Archive. I wouldn't mind seeing a way to preload programs at design time, so that you can automatically have that set of software on Volume 1 when you go to the pad.

This is by far the most elegant and flexible solution anyone has proposed. Make use of the description field in the VAB to create your boot loader.

Embed some syntax in it that marks "start of boot loader" and "end of boot loader" and have the mod read the description and copy that bit to your local drive as BOOT.txt and run it.

If you sentinel the kOS code with a start/stop keyword around the code section, you can still use the description for the human readable text too.

For example, your description field might look like this for a craft with a custom boot for just that craft:

This is a craft that I'll use for the Mun and Minmus.  It is kOS
capable and has the following action groups:
1=atmosphere stuff (panels, chutes)
2=emergency escape tower
BOOTSTART.
print "press AG9 to give control to kOS".
wait until AG9.
copy loadMunMission from archive.
run loadMunMission.
run doMunMission.
BOOTEND.
Other notes:
If you fly manually instead of using kOS, beware that
using full throttle during early ascent tends to waste
fuel as the design is a bit overpowered and exceeds
terminal velocity.

Or it might look like this if you don't have a custom boot and instead use some generic one for all your craft:

This is a craft that I'll use for the Mun and Minmus.  It is kOS
capable and has the following action groups:
1=atmosphere stuff (panels, chutes)
2=emergency escape tower
BOOTSTART.
copy genericboot from 0. run genericboot.
BOOTEND.
Other notes:
If you fly manually instead of using kOS, beware that
using full throttle during early ascent tends to waste
fuel as the design is a bit overpowered and exceeds
terminal velocity.

Remember that if you change just a few things about a craft and then save it under a new name, like if you have "myMoonLander1", "myMoonLander2", "myMoonLander3", and so on, that the description field is part of what you inherit from the earlier version of the craft, so you would inherit the boot loader behavior when you make a bunch of slightly different craft this way, solving both my and Camacha's needs with the same solution. Also, people wouldn't be surprised by accidentally triggering unexpected behaviors by happening to choose program names used by the boot loading process. This VAB description technique makes it so that the only way you get boot loader behavior is if you know the feature exists, and deliberately type in the right stuff into the description field to use it. It also has the advantage that when sharing files with others for the sake of showing how you ran a challenge mission, you don't need to have manual instructions for exactly what to run to get it started - that would be something that's embedded inside the vehicle's craft file.

This is a very good solution all around.

Do you know if the c# code in kOS can query the vessel description field and read its contents?

Edited December 24, 2013 by Steven Mading

[Camacha]

This is no fewer steps than just not even having a boot program and copying some arbitrary program manually.

Maybe we are not understanding each other, but I do believe it is fewer steps:

1) No bootfile on archive or local drive: the situation is the same as it is now.

2) No bootfile on archive, bootfile on local drive: local bootfile gets executed.

3) Bootfile on archive, no bootfile on local drive: bootfile gets copied from archive to local drive and executed.

4) Bootfile on archive, bootfile on local drive: local bootfile gets executed.

Like I said before, people usually work on the same craft for a while, making it worth while setting a specific bootfile for that craft on the archive. You will only have to do that once, removing the need for subsequent action and thus reducing steps. Only when changing the vehicle you are working on (going from Mun rocket to Eelo rover for example) you might need to change the archive bootfile again.

In the case of 2, 3 and 4 fewer steps are needed. Or am I misunderstanding what you mean? That being said, I could live without the archive boot file and only executing a local bootfile when present. It would just eliminate the endless copying from archive when iteratively editing a vehicle in the VAB/SPH.

Then why are you promoting one that is more complex? With what you're suggesting doing, its more complex than what we have now without a boot loader.

Maybe I should be more specific - I prefer a system that is as simple as possible, while not being very annoying at the same time. Not having any system is indeed the least complex, but having to copy from archive and running that file a couple of hundred times starts getting on your nerves pretty quickly.

Edit: I wrote this with the understanding you were opposed to the description code idea (and I was attempting to provide an alternative). I see now that you are not

Edited December 24, 2013 by Camacha

[Camacha]

One possible objection I see to the desciption code idea is that it would be hard to change the bootfile (firmware, it you will) after launching the craft. Strange or unintentional things might also happen if you do alter the craft file after launching.

I do not think it has to be a big problem, I am just trying to figure out the consequences.

or whatever else you want to get done. I would also add a launch button when the ship is in PRELAUNCH but otherwise it could run whenever the ship boots up?

I do not think you need a seperate condition for PRELAUNCH. If you want a button to push to launch, kOS is equipped to make that happen - you could even use an official staging command. By having a launch button in case of a PRELAUNCH condition you would always need user interaction to launch, while that choice is probably best left to the user.

Edited December 24, 2013 by Camacha

[Dunbaratu]

The CFG and model is the easy part. Just create a new one or reuse a squad model with a new CFG.

But there's also the 3D mesh description. That's copyrightable content as well but the license terms aren't mentioned.

[Dunbaratu]

Maybe we are not understanding each other, but I do believe it is fewer steps:

1) No bootfile on archive or local drive: the situation is the same as it is now.

2) No bootfile on archive, bootfile on local drive: local bootfile gets executed.

3) Bootfile on archive, no bootfile on local drive: bootfile gets copied from archive to local drive and executed.

4) Bootfile on archive, bootfile on local drive: local bootfile gets executed.

In the case of 2, 3 and 4 fewer steps are needed. Or am I misunderstanding what you mean?

Case 2, which you were promoting, would only be fewer steps if there was a way to pre-populate volume 1 with a boot program. But since local volumes always start off empty until you copy things onto them, by the time you copy a boot file onto the drive, the time during which the boot would have executed (at least on the launchpad) has already passed. The local drive will always be empty when the vehicle is first put on the pad. So you still have to copy the file to the drive manually, and you still have to kick it off manually (since the boot already happened), so it's complication that adds literally no additional functionality and still has just as many manual steps.

Maybe I should be more specific - I prefer a system that is as simple as possible, while not being very annoying at the same time. Not having any system is indeed the least complex, but having to copy from archive and running that file a couple of hundred times starts getting on your nerves pretty quickly.

Then why promote the version that requires the file to be local? That's exactly what you'd have to do if the boot loader only runs off the local drive.

Edit: I wrote this with the understanding you were opposed to the description code idea (and I was attempting to provide an alternative). I see now that you are not

I hadn't thought of that idea until razark made that small post suggesting it, which happened after the post by me that you were responding to.

Edited December 24, 2013 by Steven Mading

[Dunbaratu]

One possible objection I see to the desciption code idea is that it would be hard to change the bootfile (firmware, it you will) after launching the craft. Strange or unintentional things might also happen if you do alter the craft file after launching.

I do not think it has to be a big problem, I am just trying to figure out the consequences.

That's a good point if the boot process looked at the description every time the vessel loads from on rails, but I was picturing it being a thing that only occurs during initial deployment, like so:

During initial loading to the launchpad or runway:

- If there is a BOOTSTART/BOOTEND section in the description, make a local file called BOOT on the local drive (*) and fill it with the contents of the BOOTSTART/BOOTEND section.

- run BOOT.

During any other time the SCS module is booted besides that initial load:

- just run BOOT - don't rewrite it from the description.

Basically the description would just be a way to get around the "local volume always starts empty" problem, as a means to pre-populate a small BOOT program onto it.

[Camacha]

Case 2, which you were promoting

I was not promoting case 2, I was promoting the full set. They go together and give the player a choice of how to handle things. It is simple: if a local bootfile exists, the local bootfile gets used. If no local bootfile exists but it does on archive (typically on the launchpad, but not exclusively), the file gets copied, then used locally. That is all. This will allow a bootfile to get loaded and used on the launchpad, while a local bootfile is present after that for use in space/out of range.

The local drive will always be empty when the vehicle is first put on the pad. So you still have to copy the file to the drive manually, and you still have to kick it off manually (since the boot already happened)

No manual copying, because it gets copied from archive in absence of a local bootfile. That is what I meant by only having to set in once per vehicle you work on. The only need for manual copying is when there is no local bootfile and no bootfile on the archive, and in that case it would just work like it works now. You copy and run the desired file manually.

That's an odd thing to presume given that that suggestion wasn't made until after my post that you were responding to, so obviously that suggestion wasn't among the ones mentioned at the time I wrote what I wrote.

I made the assumption based on this post, with the idea suggested three posts before by erendrake.

[Camacha]

That's a good point if the boot process looked at the description every time the vessel loads from on rails, but I was picturing it being a thing that only occurs during initial deployment, like so:

During initial loading to the launchpad or runway:

- If there is a BOOTSTART/BOOTEND section in the description, make a local file called BOOT on the local drive (*) and fill it with the contents of the BOOTSTART/BOOTEND section.

- run BOOT.

During any other time the SCS module is booted besides that initial load:

- just run BOOT - don't rewrite it from the description.

Basically the description would just be a way to get around the "local volume always starts empty" problem, as a means to pre-populate a small BOOT program onto it.

Ah, kind of a hybrid solution. I think I like that, as it permits manual handling of the local bootfile as well. It is actually similar to what I was proposing, only the manner of injecting the bootfile to the local drive is different. Need to ponder the consequences though, there might be some unforeseen consequences.

I wonder whether right clicking in the VAB/SPH and then selecting a file on the archive drive as bootfile would be possible.

Edited December 24, 2013 by Camacha

[Dunbaratu]

I made the assumption based on this post, with the idea suggested three posts before by erendrake.

You're right, now that I re-read the post by erendrake. It wasn't clear to me what was meant by that the first time I read it. For some reason the meaning didn't click until Razark's post, so I thought his was the first suggestion of it.

[Dunbaratu]

With the idea of a small boot script embedded inside the description text field, What is the intended behavior when there exists more than one computer part on the vessel? Do all of them get the BOOT file and run it? Does just the first one? How does the player determine which is going to end up being the first one?

[Camacha]

With the idea of a small boot script embedded inside the description text field, What is the intended behavior when there exists more than one computer part on the vessel? Do all of them get the BOOT file and run it? Does just the first one? How does the player determine which is going to end up being the first one?

I guess it would be most beneficial to have a mother unit and a couple of children, as that would allow for boosters guiding themselves down after separation and things like that. How one would to that I have no idea. I am not sure how units name themselves at the moment, as they tend to be named incrementally. It would be a bit clunky yet usable if the first unit would be the mother, controlling the rest. From there it could go on copying the appropiate files to the other units.

[Hyperlynx]

I've been using kOS for a few months, and found it absolutely fantastic.

However, I just grabbed SCANSat (http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping), and it seems kOS and SCANSat aren't compatible. If I have SCANSat on my craft, the kOS console stays in its transparent "background" state, and when I click on it it just flickers back into the background. That's even if I don't have the SCANSat main window open. I'd really like to be able to use both parts on the same vessel

[KvickFlygarn87]

So Mading, are you going to push on with kOS or is it basically dead? If you're going to continue it, here's an idea for the bootloader. You write it using tweakables (and you can also write other scripts and copy from archive) in VAB. Then you name the bootloader "boot". When you go to the launchpad, it runs "run boot." if there is a file called "boot".

[John FX]

Merry Christmas Guys!

Here is my Apollo Replica with scripts to take it to Mun and back. (You`ll have to land by yourself though)

http://kerbalspaceprogram.com/kerpollo-7/

And here is the thread if you have any questions.

http://forum.kerbalspaceprogram.com/threads/50361-*Complete-Rebuild*-Kerpollo-7-Saturn-V-2-Kerbal-Rover-CM-MM-ALSEP-Ullage-Retros

[Camacha]

are you going to push on with kOS or is it basically dead?

That is a bit of a non sequitur. I think Steven has indicated that he does not feel he is the right person to pick up the job. However, there were a number of other people that said they might continue development or fork kOS, and we have not heard from Kevin about his plans yet. Let us not jump to conclusions.

[Dunbaratu]

I've been using kOS for a few months, and found it absolutely fantastic.

However, I just grabbed SCANSat (http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping), and it seems kOS and SCANSat aren't compatible. If I have SCANSat on my craft, the kOS console stays in its transparent "background" state, and when I click on it it just flickers back into the background. That's even if I don't have the SCANSat main window open. I'd really like to be able to use both parts on the same vessel

Are you sure that's the fault of incompable mods? I got that exact behavior from the kos terminal as soon as my Ksp got updated to 0.23 but I hadn't tried updating kos yet.,

[Hyperlynx]

Are you sure that's the fault of incompable mods? I got that exact behavior from the kos terminal as soon as my Ksp got updated to 0.23 but I hadn't tried updating kos yet.,

Hmm.

I've just tested with a craft with a kOS module and no SCANSat module and the same problem happened. Then I tried deleting my kOS install and installing the latest version, and the same thing happened. I'm pretty sure I've been able to use kOS with 0.23 before, and it's only after installing SCANSat that it's stopped working.

edit: I just tried removing SCANSat and tried again, same effect. So you're right. I guess it's an incompatibility with 0.23, then

Edited December 25, 2013 by Hyperlynx

[pa1983]

Hmm.

I've just tested with a craft with a kOS module and no SCANSat module and the same problem happened. Then I tried deleting my kOS install and installing the latest version, and the same thing happened. I'm pretty sure I've been able to use kOS with 0.23 before, and it's only after installing SCANSat that it's stopped working.

edit: I just tried removing SCANSat and tried again, same effect. So you're right. I guess it's an incompatibility with 0.23, then

I just forked it and tried to compile it, but it doesn't even compile for this version of ksp. However, think I managed to stumble onto a hotfix - both sides of the lock/unlock now want an identifying string. I think I remember a mention in kerbal kon about the bug that was supposed to fix - kOS uses the ship editing "picked up a part" logic to capture game focus. Anyway, I'm about to load up ksp with my own build to test this fix.

Edit1: works beautifully. Now to check the license then stick it in dropbox.

Edit2: GPL makes it simple. Here you go for a working version. Source is the same except adding a string literal for the lock and unlock calls.

https://www.dropbox.com/s/0gmwx6latfb9fth/kOS.dll

Edit3: Pull request added, so whenever he comes back it's only a couple clicks; he won't even have to know what caused the problem.

The fix is in the thread. Searching the problem on startpage.com found the relevant posts for me a few days ago. Works fine for me with that hotfix.

[Dunbaratu]

The fix is in the thread. Searching the problem on startpage.com found the relevant posts for me a few days ago. Works fine for me with that hotfix.

This is NOT a working version. It fixes one problem and introduces others. It broke the ability to make comparison tests against literal strings, requiring the addition of pointless extra lines of code to replace all such instances with comparisons against string variables. Since my code happened to be near the 10k limit already, and has a lot of comparisons to literals, this is a nontrivial change to make, and its a rather bad idea to make that change for a thing that is clearly a bug introduced by somebody's recent edit of the code.