[kOS] The Automated Mission Challenge

[Fail-o-matic]

I apologise. You are correct. Somehow I got my signals crossed and uploaded the same thing (the full unstripped files) to both directories.

I have re-run the programs in the unstripped directory through the stripper and re-created the stripped directory.

I hope it works. I don't have the chance to test it as the versions of those programs I'm using now have been edited a bit since then as I'm trying to work out the problem of a Duna transfer. and they're currently in a sort of halfway broken flux. So I didn't want to just upload what I have now, and I didn't want to swap them out for the version on the google drive. So I didn't test if the stripped version still works. In principle it should be the same thing as what I used before, so it should work.

That did the trick. Liftoff to splashdown. Thanks!

[Sma]

You only can hope that either Scott Manley has no programming skills or does not want to participate. Otherwise we all know who the winner is.

Haha, very true! I have yet to actually start anything offical for this. but good thing there isn't really a deadline lol. I haven't gotten on to KSP in about a week

[Dunbaratu]

looking at this docking and undocking looks doable (but hard) but I dont think you can transfure fuel to the lander which is limiting.

Yeah you can do anything that's doable with action groups. And fuel transfer isn't doable by action group.

One idea I had is that the way right clicking on parts beings up a menu seems to have a universal generic interface so it might be possible to implement a KOS thing to open that up to scripts - something like "For all parts, you can say 'do the Nth thing on this part's right click menu'. "

[Sacred Aardvark]

something like "For all parts, you can say 'do the Nth thing on this part's right click menu'. "

You have now closed your solar panels, opened an antenna, jettisoned an engine, shutdown a second engine and activated a third one, not to mention starting up windshield Re-frosting (why did we install this?) and the automatic re-entry hull polisher while disabling oxygen circulation.

Okay, probably wont be that bad, but since the r-click menus have differing amounts of actions, especially with mods, you'd need to be fairly attentive when building your rocket not to have unexpected stuff happening, if you were to do say 2nd action down on all parts.

Aren't most of the right click menu things mappable to action groups btw? I'm sure there are a few, I just can't think of a one that isn't... Except fuel transfers which aren't, but you'd need to target two tanks for it, so it probably wouldn't work by doing an action on all parts (repack chute just came to mind as something in r-click but not mappable to ag, but that requires an eva-kerbal doesn't it?)

[Dunbaratu]

You have now closed your solar panels, opened an antenna, jettisoned an engine, shutdown a second engine and activated a third one, not to mention starting up windshield Re-frosting (why did we install this?) and the automatic re-entry hull polisher while disabling oxygen circulation.

I suspect you are responding as if I had said you activate the action on all parts AT THE SAME TIME. I never said that. I said for all parts you CAN say 'do the Nth thing on this part's right click menu'. Meaning the capability is there on all parts, not that they're all tied together.

[Sacred Aardvark]

I suspect you are responding as if I had said you activate the action on all parts AT THE SAME TIME. I never said that. I said for all parts you CAN say 'do the Nth thing on this part's right click menu'. Meaning the capability is there on all parts, not that they're all tied together.

Oh, yeah, d'oh.. I thought you meant getting that ability now, i.e. before we get the ability to affect individual parts outside of action groups, after getting that ability, it sounds sensible.

Edited November 22, 2013 by Sacred Aardvark
attempted phrasing clarification

[Dunbaratu]

Maaaaan I am SOO close to having a working Duna mission including a stopover on Ike while I'm in the area, and a return. The only thing I still need to do is alter my orbital transfer program to be able to handle either case no matter which way the sign points (the same math that finds a transfer orbit position using prograde delta-V to go from Kerbin to Duna shouild be able to find a transfer orbit position using retrograde delta-V to go from Duna to Kerbin. But my script had a few places that made presumptions about the sign that I need to make more universal for either case. That's the last thing I need to fix and then I can start making the video.)

It will probably be broken up into two videos because this one is a much longer mission:

It consists of the following individual steps, each a separate program with parameters:

ascend to Kerbin orbit.

escape Kerbin SOI in Kerbin's prograde direction.

transfer to Duna.

get captured at Duna.

descend to Duna landing.

ascend to Duna orbit.

transfer to Ike.

get captured by Ike.

descend to Ike landing.

ascend to Ike orbit.

escape Ike in Ike's retrograde direction.

When back in Duna SOI, escape it its prograde direction.

transfer to Kerbin.

get captured by Kerbin, at a low enough altitude to areobrake.

hit the 'chutes.

done.

The craft itself will be an ugly monstrosity because I'm trying to do all of this without any re-docking so I have a lot of stages and a lots of consumable, separable fuel tanks to leave behind in all those landings and taking offs.

So watch this space. I should have it in by the end of the weekend.

[adammada]

And another entry.

Mission plan:

Kerbin orbit

Minmus orbit

Minmus landing

Minmus orbit

Mun orbit

Mun landing

Mun orbit

Kerbin landing (without parachute!! ).

Code + Craft:

http://speedy.sh/9FWQ7/upload.zip

[Dunbaratu]

And another entry.

Mission plan:

Kerbin orbit

Minmus orbit

Minmus landing

Minmus orbit

Mun orbit

Mun landing

Mun orbit

Kerbin landing (without parachute!! ).

Impressive. I would have expected that deadburn technique would waste a lot of fuel (to kill all horizontal speed and fall straight down) but it seems to work okay. I also like your solution to the inclination problem. You seem to be waiting for 1/2 of ETA and then correcting it. That seems to depend on finding an encounter first before correcting inclination though. I think it might not work as well on interplanetary transfers where an inclination of a few degrees means the game won't report an encounter at all - it's too far off - but first to Minmus! Good job.

[adammada]

That seems to depend on finding an encounter first before correcting inclination though. I think it might not work as well on interplanetary transfers where an inclination of a few degrees means the game won't report an encounter at all - it's too far off - but first to Minmus!

No, when searching for encouter second node normal burin is also changed ( -maxnorm, -maxnorm/2,0,maxnorm/2,maxnorm), so i think it would work for interplanetary flight.

SET norm TO -1 * maxnorm.

UNTIL norm >= maxnorm {

SET nnode TO NODE( nodetime + midtime, 0, norm, 0).

ADD nnode.

if encounter = bo:name {

BREAK.

}

REMOVE nnode.

SET norm TO norm + (maxnorm / 2).

}

First I try to find encounter with inclination change, then tune it. Then execute first node.

After that tune second node again (due to first node execution errors).

Worst part was Mun -> Kerbin transfer, because it can't be done by using nodes. Encounter doesnt report switching SOI to Kerbin, so i don't have its periapsis. I had to do it by pretty hardcoding burn based on longitude. I hope that they will enchance nodes in next kOS version.

Edited November 23, 2013 by adammada

[Dunbaratu]

Worst part was Mun -> Kerbin transfer, because it can't be done by using nodes. Encounter doesnt report switching SOI to Kerbin, so i don't have its periapsis. I had to do it by pretty hardcoding burn based on longitude. I hope that they will enchance nodes in next kOS version.

The thing that I think would help the most is the ability to read those "Closest Distance" chevrons when you *don't* have an encounter. That would allow you to use KSP's own built-in functions that solve the hairy calculus-by-slices problem of working out eliptical orbit timings. (There is no clean mathematical solution to working out how long it will take an object to get from point P1 to P2 in an elliptical orbit other than numerical approximation by iterating over finite slices. Trying to do that sort of thing in a slow computer like the KOS SCS is just not practical, but KSP under the hood is already doing it when it shows you those encounter chevrons, so it would be nice to have access to that information.)

[Dunbaratu]

No, when searching for encouter second node normal burin is also changed ( -maxnorm, -maxnorm/2,0,maxnorm/2,maxnorm), so i think it would work for interplanetary flight.

Looking at the code, yes you're right it does. But it didn't look that way in the video. It was moving far too fast to be trying different normal burns at each position. When I try that it takes *forever* to iterate over the guesses and you can watch it trying each guess on the screen.

[adammada]

When I try that it takes *forever* to iterate over the guesses and you can watch it trying each guess on the screen.

Strange. I dont have any super-fast CPU ( http://www.cpubenchmark.net/cpu_lookup.php?cpu=Intel+Pentium+G850+%40+2.90GHz&id=1116 ) .

Did you try to run my code?

[Xeldrak]

Hm, I'm working on this challenge Just downloaded KOS yesterday end fiddled around a bit with it. By now I get my rocket reliably into orbit and I'm working on a mun-transfer program.

But I have to admit - considering the methods you guys are using I'm hesitant to post my ragtag script ^^

By the way - how to I toggle antennas?

Edited November 24, 2013 by Xeldrak

[Dunbaratu]

I see a nasty potential cheat exploit in how the rules are set up. The rules as they stand now allow multiple launches into Kerbin orbit and only after you leave Kerbin orbit with one of them are you not allowed to launch more. As long as you do this your launches get to be called "one mission composed of separate launches", even though they were designed and they operate entirely independently of each other. So I make one mission that gets to the Mun and back and test it. Then I make another mission that goes to Duna and Ike and I test it. Then i make another mission that goes to Eve and Gilly and back and I test it.

At this point I'd have done 3 missions:

1. a mission that goes to 1 moon.

2. a mission that goes to 1 planet and 1 moon.

3. another mission that goes to 1 planet and 1 moon.

To weasel my way into more points I could just do this:

launch mission 1. Get it to the point where it's in orbit around Kerbin and stop there.

launch mission 2. Get it to the point where it's in orbit around Kerbin and stop there.

launch mission 3. Get it to the point where it's in orbit around Kerbin and stop there.

From then on, the way the challenge rules are worded, those three are the "same" mission. Now I just go back to each of them and finish their separate missions to the end and I get to pretend I went on one mission to 2 planets and 3 moons when I didn't, not REALLY.

Granted, there's a bug right now that gets in the way of trying to do this, and that is the fact that when you go on rails and come back your ship doesn't load up properly if you have any scientific notation variables in the context store.

However:

1 - It's not a good idea to make the scoring rules utterly dependent on a bug remaining unfixed (especially in this case as the bug *is* fixed in a github fork and is just waiting to be pulled back into the master for release).

2 - There exists a workaround to avoid the bug even now - just have the craft set all the variables it used to zero before putting it on rails so none of them will be hard for the mod to load back in again.

I think the phrasing for multi-launch missions needs to be worked on to remove this exploitable wording. Something about how in order to count as one mission, at some point all the crafts have to have been attached together into one craft during a transfer from one SOI to another. Any craft that did not participate in that single joined together craft does not get to be called part of the same mission.

[TelluriumCrystal]

I see a nasty potential cheat exploit in how the rules are set up. The rules as they stand now allow multiple launches into Kerbin orbit and only after you leave Kerbin orbit with one of them are you not allowed to launch more. As long as you do this your launches get to be called "one mission composed of separate launches", even though they were designed and they operate entirely independently of each other. So I make one mission that gets to the Mun and back and test it. Then I make another mission that goes to Duna and Ike and I test it. Then i make another mission that goes to Eve and Gilly and back and I test it.

Thanks for pointing that out. I made a small modification to the rules that should prevent that from being possible.

And another entry.

Mission plan:

Kerbin orbit

Minmus orbit

Minmus landing

Minmus orbit

Mun orbit

Mun landing

Mun orbit

Kerbin landing (without parachute!! ).

~snip~

Code + Craft:

http://speedy.sh/9FWQ7/upload.zip

Wow, that's the best so far! Nice work. Impressive powered landing too.

Adding your second attempt to the leaderboards now...

Edited November 26, 2013 by Thrfoot

[Dunbaratu]

Thanks for pointing that out. I made a small modification to the rules that should prevent that from being possible.

Do you mean this part?

"Also note that only the first craft to leave Kerbin orbit counts towards any points."

It would be a good idea to make it clear that you are allowed to assemble this ship out of pieces and split this ship apart later, so long as it's one ship when it leaves Kerbin orbit. People might not think of an assembled collection as "one craft" and might not realize what you meant.

[TelluriumCrystal]

Do you mean this part?

"Also note that only the first craft to leave Kerbin orbit counts towards any points."

It would be a good idea to make it clear that you are allowed to assemble this ship out of pieces and split this ship apart later, so long as it's one ship when it leaves Kerbin orbit. People might not think of an assembled collection as "one craft" and might not realize what you meant.

Good point. I went ahead and added another sentence to clarify that.

[Dunbaratu]

Here's another rules question that's coming up in my case because I'm trying to make an interplanetary Duna mission and there's a lot of steps and it's triggering a problem in KOS itself (I *think*) that I can't do anything about.

That problem is this: The longer KOS has been running a loop, the more KSP gets lagged - the commonly known stutters in sound and simulation problem (that people have been reporting with a lot of other mods too) seems to be really common with KOS if you've been running an UNTIL loop a long time. One temporary workaround I've found that seems to work is to quit and restart KSP once I get to one of the stable points in the mission (landed, or in a stable orbit - basically any of the places this challenge allows you to type commands). After the restart I then continue the mission where I left off. But to use this fix, of course I have to be able to save and reload the persistence file, which in turn triggers the other bug in KOS about failing to load the craft from on-rails if there's any variables in its saved state.

So what I have to do to make this work and to work around those bugs, is to manually edit the persistence file and remove the variables context (effectively clearing the memory of the KOS SCS unit) before reloading the game. If you do that you can avoid the bug and get it to reload the craft correctly.

Once a variable is set there's no way to unset it, so there's no way around this bug other than editing the persistence file, and there's no command in KOS that seems to clear the variables out - shutdown doesn't do it and reboot doesn't do it.

So I can understand that editing the persistence file would normally be a cheat, but can an exception be made for this purpose and this purpose only - to be allowed to edit the persistence file to clear the variables so you can reload the saved game and continue your mission from where you left off? (Provided this is only done when your mission is at one of the states during which the challenge rules would allow you to type manual commands.)

My desire to be able to come back and continue the mission isn't just for the sake of the stuttering bug, by the way. It's also because I want to make a video of it and when I start getting into interplanetary missions that makes it into too long of a video capture session for me to want to fit it all into one go. It would make quite a long raw footage of a few hours, which will eat up lots of disk space. I'd rather make a few separate videos of half an hour each rather than one enormous hour and a half video. That allows me to compress the raw footage down and save disk space before going on to the next part. And then I'd be able to go back and edit out the boring parts or speed them up, and re-combine those separate videos into one. But at least I wouldn't have to temporarily store an hour and a half of raw uncompressed footage as an intermediate step, which is what I'd do if I captured the entire mission in one go.

[Sacred Aardvark]

My .02$: Sounds legit, I'd allow it.

[Bobnova]

I played with this a bit before leaving on a business trip, I can get to orbit and back easily, I have no clue how Y'all are doing the maneuver node testing inside kOS, my eventual entry will likely be hard coded entirely.

In any event, expect an entry of sorts from me next week, and thanks for having this challenge! kOS has turned out to be a lot of fun, and I'd never have checked it out workout the challenge.

[Dunbaratu]

I think this challenge, in addition to being fun, has also turned out to be quite USEFUL to the development of KOS itself. After the challenge started there was a sudden uptick in the rate of reported issues on the KOS Github page, and I think that's largely because in response to the challenge people started trying to do more difficult things with KOS and thus discover limitations they hadn't run into before.

In a sense, the challenge became a "use case" scenario for testing KOS.

[Dunbaratu]

Another rules question: can people be allowed to use the mods that mod the KOS mod itself?

i.e. http://forum.kerbalspaceprogram.com/threads/51211-Sensor-Reporter-for-kOS for example.

The way the rules are phrased now, KOS is the only allowed mod.

If mods like the Sensor Reporter *do* become allowed, I'd recommend doing it by adding to the rules an explicit whitelist of allowed mods. given by name, rather than simply saying "any mod that contains KOS hooks in it". I say that because I can see a potential problem with opening it up entirely to ANY possible future mod that might be made which happens to have a hook for KOS to call, because then if, say, Mechjeb adds a few KOS calls you could have Mechjeb installed. Such a rule could become a backdoor into allowing someone to pretty much ignore KOS and instead write a Mod that controls the mission from the C# code, and have that mod create a hook to allow a KOS script to trigger the Mod's code and have the Mod's code actually doing the work rather than KOSscript doing it.

I guess on a similar note, maybe a rule should be added to require that the mission has to work using only an official release of KOS (but perhaps an older release is allowed), rather than something compiled from a personal private fork of the github code, for the same reason - someone could fork KOS and then write their own C# solutions to things that aren't in the main release for others to use. This is more for the repeatability of the test by others than anything else. Granted, at the moment because Kevin isn't around to merge pull requests back into the main releases this means having to avoid using any of the fixes people have made for things, but the alternative to allow anyone to use any fork of KOS they made would be too hard to control and keep the challenge fair.

[adammada]

Here's another rules question that's coming up in my case because I'm trying to make an interplanetary Duna mission and there's a lot of steps and it's triggering a problem in KOS itself (I *think*) that I can't do anything about.

Using my scripts previously used for Minmus -> Mun fly i could fly to Duna and havent noticed issues. Its not entry here, because i wait for next KOS version, wchich would include better nodes handling (i even added code for it to github, but where is Kevin Laity?) i dont want to do some workarounds when all i need is getting position of node.

[Dunbaratu]

Using my scripts previously used for Minmus -> Mun fly i could fly to Duna and havent noticed issues. Its not entry here, because i wait for next KOS version, wchich would include better nodes handling (i even added code for it to github, but where is Kevin Laity?) i dont want to do some workarounds when all i need is getting position of node.

I have discovered that the problem might be "revert flight". There must be something in KOS that is being "left behind" that the DLL is still trying to run, or perhaps some memory it's still holding onto, when you revert flight, so that in a session debugging your script, if you keep trying to "revert flight" and try again, each successive time you do it makes the lag worse. Something is getting left behind. I can tell because when I remember to always issue a "shutdown." command to the KOS terminal before I revert flight, the lag never accumulates to get worse, whereas when I don't do that and instead just revert flight while the KOS SCS unit is still active and turned on, it always DOES get worse the next run through.

So I don't have the lag problem as badly, but I still do think it would be convenient to be able to record the video in separate goes with saving the game between so I don't have to make it one enormous video.