kOS Scriptable Autopilot System 0.9

[Dunbaratu]

(when talking about adding arrays)

This would be useful of course, but also adds complexity for beginners. It is fundamental to programming, but also initially potentially confusing.

I think it's important to categorize complexities into two very distinct categories:

1 - Complex things that the mod requires a user to use.

2 - Complex things that the mod allows a user to use.

Arrays would belong in category 2. That makes it far less confusing than a thing in category 1 would be.

Examples of things that are in category 1 right now would be Euler rotation tuples. You can't get anything done without understanding them (and, importantly, finding out the super-secret undocumented fact about the order in which the rotations occur. The same rotation tuple gets different results depending on if you roll, pitch, then yaw, or yaw, roll, then pitch, or pitch, roll, then yaw, etc. And I only found out which way it is because I found a webpage about the Unity engine describing how they do it, and presumed that kOS is using Unity functions so it must be doing it in the same order. That's an example of a complexity that users MUST learn to make sense of the mod, whereas arrays are a complexity the user only adds when they choose to.

[togfox]

Can't get this line to work:

Declare throtsetting

set throtsetting = 0.15

if alt:radar > 50 and verticalspeed > -3 { set throtsetting to throtsetting + 0.1 . } . <---- this line throws an error.

lock throttle to throtsetting.

I'm trying to regulate throttle as the craft descends for landing. There are loops and other things that adjust throttle but I've extracted this line only to keep this simple.

Any clues? Thx.

[Camacha]

I do not think the problem is that line, but the two before. Because you do not have used any terminating periods, kOS sees less lines than you intended. kOS will see only three lines:

Declare throtsettingset throtsetting = 0.

15if alt:radar > 50 and verticalspeed > -3 { set throtsetting to throtsetting + 0.1 . } .

lock throttle to throtsetting.

See the problem? Them periods are important Also, the syntax in the first line is not correct. Try:

set throtsetting to 0.15.
if alt:radar > 50 and verticalspeed > -3 {set throtsetting to throtsetting + 0.1.}. 
lock throttle to throtsetting.

I removed the declaration as you set the variable right after (implicitly declaring it). What you did is not wrong (and some will argue it is more correct), but as you waste clockcycles it is a bit of an optimization. As long as you are aware what you are doing and why, either way is fine.

Edited December 22, 2013 by Camacha

[Camacha]

In other words, kosscript. which looks nothing like c++ or c#. There is exactly 1 thing ONLY it shares with C++ and that's the curly braces. That's IT. Nothing else looks anything remotely like C++. To claim it looks like C++ is to reduce C++ down to one single teeny tiny aspect of the language and ignore everything else about it.

I think he did not mean to say kOS looks like C++, but just that as long as it does not look like that, it is fine by him. You noted correctly that there is little to no resemblance, which means that kOS as it stands looks fine to him

I think it's important to categorize complexities into two very distinct categories:

1 - Complex things that the mod requires a user to use.

2 - Complex things that the mod allows a user to use.

Arrays would belong in category 2. That makes it far less confusing than a thing in category 1 would be.

You are correct. However, the ease of getting into something depends on a number of factors. As a beginner - if all the code you see in this topic contains things you can not fathom, it will not only discourage you, but it will also make it harder to learn from those examples.

I am not trying to say arrays should not be implemented, just that it does have consequences for those that do not use or understand them. I am with you on the Euler rotations - kOS users should not be bothered with those unless they have the desire to.

[John FX]

I think he did not mean to say kOS looks like C++, but just that as long as it does not look like that, it is fine by him. You noted correctly that there is little to no resemblance, which means that kOS as it stands looks fine to him

You are correct. However, the ease of getting into something depends on a number of factors. As a beginner - if all the code you see in this topic contains things you can not fathom, it will not only discourage you, but it will also make it harder to learn from those examples.

I am not trying to say arrays should not be implemented, just that it does have consequences for those that do not use or understand them. I am with you on the Euler rotations - kOS users should not be bothered with those unless they have the desire to.

As a new user, the main thing I had trouble with is `how do I point the nose of my craft the way I want`. +r(x,y,z) was not helpful and slowed my progress. The +r(x,y,z) bit really should be in the advanced maths section. The `lock steering to heading (ptch,hdng).` command should be the only one in the beginner users section.

When you can do that then the rest is a lot easier.

As for arrays, I agree they should also be in the advanced maths section as they are advanced maths for most people.

The way to think is `can I fly to Mun without it` and use that to decide what is for beginners and what is advanced. Beginners just need to be able to get to Mun and land. Same progression as the main game.

Beginners just try first to launch, then orbit, then land, then go to the Mun. After that you are past beginner IMO.

I`m currently trying to do that using as basic code as I can (maths wise at least, for new players to understand it) When I am happy I will release my code with my KerPollo 7.

Edited December 22, 2013 by John FX

[togfox]

Thanks for the syntax tips. I forget about the periods. Its unnatural to me but I get it. I also have a '=' in there which it doesn't like.

I now have a script that will deorbit a craft, point retro, and control vertical speed all the way down to touch down. That is a pretty cool feeling. 8)

Next stage is to move laterally if there is evidence that the craft is over a steep gradient. Might call on some help with that later on.

[razark]

Any syntax that doesnt look like c+/c# is fine by me!

COBOL? BASIC? Assembly? INTERCAL? If those are the other options, C based syntax would be fine.

(Actually, kOS reminds me of my early days mucking with BASIC. Even if it still doesn't hava a GOTO statement.)

[Rosco P. Coltrane]

From my experience teaching people programming, I found arrays are quite easy for them to understand. First don't call them "arrays", call them "lists". Second avoid having to explain that an array has a predefined size and if you want it to grow, it's slow because it's a continuous piece of RAM and you have to move everything and... in other words, avoid explaining how it works under the hood.

In this case, kOS could have a "list": you call Get, you call Add and you call Remove. Efficient, inefficient, don't care about that now, just use the list. Sorta like in any OOP language where you have a List class that you don't know how it works, but for beginners it's just fine.

[erendrake]

Im working on arrays and a bootloader and i have some questions for the group.

Would a limit to simple values ( string, int ) be ok? or would you want the ability to store more complicated values like vectors and nodes be so much more useful?

I was thinking about storing a bootloader in the Vessels description from the VAB/SPH. That way each ship can define its own

copy program from 0.
run program.

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?

Does anyone disagree with this plan? It would have a script header like #!/kerboscript that would run everything below that point so people could still use it to describe the vessel on top.

Edited December 22, 2013 by erendrake

[diomedea]

Would a limit to simple values ( string, int ) be ok? or would you want the ability to store more complicated values like vectors and nodes be so much more useful?

The ability to store an array with any kind of variable that is possible to define in kerboscript. Really need that.

And thanks.

About the bootloader, I will probably never use it, unless there was a way after kOS boots to select one specific program from a list. That would be possible if kerboscript is expanded with the INPUT statement, but as it stands now I can't see a way out.

[togfox]

DOS veterans call the boot loader the 'autoexec' but i acknowledge that is very platform specific.

Boot loader is not noob friendly i fear. Maybe a file in archive call 'autostart' is all we need?

[Dunbaratu]

Changing the name of the bootloader per vessel is kind of ugly. How about making it based on vessel NAME. If I call my vessel "QWERTY1" then it will bootload the archive program called "QWERTY1.TXT".

I;e;. if vessel name is QWERY1, then it will:

copy QWERTY1 from 0.

run QWERTY1.

After it finishes loading the vessel and engaging the physics engine on the lauchpad.

I would assume that arrays would be dynamically growable in order to make it noob friendly. Also, if they don't contain all generic kos objects then there's no point in having them. (and, if you make them contain all generic KOS objects and the array itself is also a generic KOS object then you get multidimensional arrays for free without any additional implementation work - a 2D array is an array whose elements are themselves also arrays. Just make sure that the syntax parsing tolerates this without having to perform additional statements. i.e. something like arr:thingAt(i):thingAt(j) or arr(i)(j) needs to work as opposed to needing to resort to getting it in two statements like set row = arr(i). set thing to row(j).)

As for array size, one style that has been done in the past is to tolerate any array index by simply growing the array as needed to fit the subscript used. i.e. if you have an array of size zero, and try to store something in arr[10], then it grows the array to size 10 and then stores the thing there, rather than erroring out. This approach is very noob friendly, but it does open up the possibility of accidentally carving off an enormous amount of memory and thus crashing the system if you say something like set arr[altitude] to 0 when you meant to say set arr[0] to altitude.

[Dunbaratu]

One of the reasons I'd find arrays useful is that they'd give a way to make the various LIST commands usable by scripts. Right now they're only usable by humans because the data they spew out appears only in screen text and can't be read by the script. But if arrays existed then you'd also be able to alter the LIST commands to say things like LIST PARTS INTO myArr. (Now myArr is an array containing the strings of the part names.)

[KvickFlygarn87]

Is this mod broken or does it work for .23?

Also, where has Kevin Laity gone?

[John FX]

Im working on arrays and a bootloader and i have some questions for the group.

Would a limit to simple values ( string, int ) be ok? or would you want the ability to store more complicated values like vectors and nodes be so much more useful?

I was thinking about storing a bootloader in the Vessels description from the VAB/SPH. That way each ship can define its own

copy program from 0.
run program.

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?

Does anyone disagree with this plan? It would have a script header like #!/kerboscript that would run everything below that point so people could still use it to describe the vessel on top.

I find that the command to run the program is not that much different from the command to run the batch that runs the program. I wouldn`t want it to just launch without me telling it to either.

I have programs in my archive for all my craft that do exactly what you describe. Kerpollo.txt for example loads itself then calls all the programs needed in the right order for a Mun mission with the right parameters for each subroutine and all is good. I am failing to see the benefit from the different workflow.

I`d like the default volume to be archive(0) though, is there any way of setting that? (that would half the commands needed to launch) then you could just "run program" for each craft.

For arrays, I like the suggestions so far with auto expansion and ability to store all data types.

[John FX]

In other words, kosscript. which looks nothing like c++ or c#. There is exactly 1 thing ONLY it shares with C++ and that's the curly braces. That's IT. Nothing else looks anything remotely like C++. To claim it looks like C++ is to reduce C++ down to one single teeny tiny aspect of the language and ignore everything else about it.

It's an impossible dream to a certain extent. unless you sacrifice functionality to get simplicity. Programming languages are complex not because programmers go around trying on purpose to make life harder for themselves, but because there's a minimum complexity inherent in their flexibility.

Myself I like languages that have easy parts that enable you to do something fun with only a little knowledge but have the depth and advanced features that enable you to do really cool stuff when you have the skill.

Then you could essentially have a `noob` command set and an `advanced` command set over the top which would let the new users do some stuff almost straight away (launch, orbit, land) while giving advanced users the features they crave (multidimensional arrays etc). There might even be a setting to open up the advanced commands which would mean you wouldn`t have to deal with the really complex stuff until you were ready.

[Dunbaratu]

I find that the command to run the program is not that much different from the command to run the batch that runs the program. I wouldn`t want it to just launch without me telling it to either.

The launchpad its not the only place a bootloader would run. It would also run whenever an SCS is rebooted. (And if it doesn't then it's implemented wrong).

That makes it a lot more useful.

[Dunbaratu]

Is this mod broken or does it work for .23?

Someone tried making a version for 0.23 that will make it work for KSP 0.23 but it introduced other problems that makes it a pain to use. (I suspect this is because it also contains other github changes people have made that haven't been regression tested and are not in the main code. At any rate it broke the ability to test against a literal string and that would require a lot of editing of my scripts to get them to work with it, so I decided not to pursue it any further until there's a more formal project admin back at the helm again to decide what pull requests are in and what ones are out.).

Luckily I knew that KSP updates tend to break mods, and I knew that we had no mod admin right now, and I knew 0.23 was coming soon, so I copied off my entire 0.22 install of KSP before the update came. If I want to play with kOS I go over into my KSP 0.22 copy to do so.

But right now, if you're somebody who didn't do that, or you are only just getting into kOS now after the 0.23 update, then you're sort of out of luck.

Also, where has Kevin Laity gone?

No idea. Buzz got one limited cryptic message about "dealing with personal stuff" but nothing about whether or not he'd like someone else to take over managing the project or if he's planning to come back to it soon.

The fact that the version on spaceport doesn't work for 0.23 is sort of forcing the issue. We'll need to pick a new admin and set up a new fork of the project, I fear, since nobody can get a hold of Kevin Laity to ask his opinion on what to do with his project.

I'd volunteer except for the fact that all my programming experience has been in UNIX, where hardly anybody uses C# or Mono, so I have zero experience with them. The admin should be someone well versed in the core system being used, and that someone isn't me. I barely consider myself qualified to contribute a one or two line change here or there.

It's licensed using GPL, which being one of the open source licenses means that starting a new branch of the code should be no problem, legally.

But out of respect for Kevin, I think we should be clear in the naming of the branched project that it's something distinct from Kevin's. I.e. calling it "KOS 2.0" would be a bit rude to Kevin. Perhaps a name like "CommunityKos" or another punning of old-school computer products akin to KOS could be used, like "DR-kOS" (Derived Respectfully kOS).

[Dunbaratu]

The other reason for me suggesting a name change like DR-kOS is so that releases can end up on Spaceport. As it is, I don't think anyone other than Kevin can change what's on the Spaceport page for kOS, but if this was a second project with a new name, it could have its own new Spaceport page.

[Sacred Aardvark]

But out of respect for Kevin, I think we should be clear in the naming of the branched project that it's something distinct from Kevin's. I.e. calling it "KOS 2.0" would be a bit rude to Kevin. Perhaps a name like "CommunityKos" or another punning of old-school computer products akin to KOS could be used, like "DR-kOS" (Derived Respectfully kOS).

Seconded on the distinct name, though not sure about keeping the kOS bit in. It'd be a nice nod to Kevin, but on the other hand if Kevin comes back and decides to pick up where he left off, it could create slight confusion to have DR/MS/PC/WE-kOS* and kOS. Maybe k64? kerbbodore? Since kOS uses that c64 lookalike thing for visuals.

*(Must Save / Preserved by Community / WhatEver)

[John FX]

So it seems KOS is only up to 0.22 then. I wish you luck in your fork.

Edited December 23, 2013 by John FX

[Dunbaratu]

I suspect it will work if you make a string variable first:

set str to "Mun".
if encounter = str {print "Mun encounter".}.

It's only comparing to a literal string that broke.

[John FX]

I suspect it will work if you make a string variable first:

set str to "Mun".
if encounter = str {print "Mun encounter".}.

It's only comparing to a literal string that broke.

Aah. cool. So

set text to "Mun".

if encounter=text {print "Mun encounter".}.

would work then. I`m ok with that as a change. (made them already and all is good, tank you very much) Are there any other 0.23 issues anybody knows about as far as KOS goes?

P.S. My vote for the new name is KHAOS

Edited December 23, 2013 by John FX

[Camacha]

Changing the name of the bootloader per vessel is kind of ugly. How about making it based on vessel NAME. If I call my vessel "QWERTY1" then it will bootload the archive program called "QWERTY1.TXT".

I;e;. if vessel name is QWERY1, then it will:

copy QWERTY1 from 0.

run QWERTY1.

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.

If you wanted to prevent having to copy that bootfile on the launchpad, you could make it a rule that when no bootfile is present, the default boot from archive is copied and used. That way the user could set an empty boot file when there is no need for one, or have a specific custom boot file in the archive. I am not sure it is a whole lot of work to just manually copy the bootfile though.

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.

[sirkut]

Being that I forked Damned Robotics into Infernal Robotics I wish you the best luck. It's tough.