[FAR,kOS] Land on Mun! 3 Difficulty Levels... Steam Games for prizes!!!

[TheGreatFez]

Hello all,

EDITS: Procedural Fairings mod added, Team Entries are allowed, Entry Due Date extended

I am a moderator on the /r/kOS subreddit. I have been spending the last couple weeks working out the kinks in this challenge to post on the subreddit. To get more exposure I wanted to post it on here so that others might find interest in it!

If you don't know what kOS is, its a mod for KSP that allows you to write automated scripts that control your rocket using a language called Kerbo Script. Here is a link to the forum on the mod.

The challenge will require you to code an autopilot script and design a ship to fly to Mun and Land with 3 different difficulty of objectives.

Here is the link to the Google Doc with the description on it. Its quite lengthy but I believe it covers much of any issues that might arise with this competition.

If you have any issues/questions/comments please let me know!

Deadline for submissions is April 25th at 11:59pm (UTC-6).

Good luck!

Edited March 31, 2015 by TheGreatFez

[rudi1291]

A scripting language for KSP? That´s nice. Maybe, if i manage to install this, i will try this

[TheGreatFez]

Yeah its not too bad to install and get started. If you are looking for any help, the documentation sight is a great place to start. Also, you can learn a lot from /r/kOS on Reddit!

[Aphobius]

Hey, I was thinking about participating, but FAR greatly discourage me, some people just don't like mods.

Anyway, in case I'll still participate or maybe you'll allow entries without FAR, I have a question. The rocket/script should be able to complete the challenge starting from any date or all of the 3 tests are going to take place on a new save file?

This is very important, since a script with precalculated data (mostly burns) is much easier to make than a script that can complete the challenge by starting from any date.

[TheGreatFez]

Hey, I was thinking about participating, but FAR greatly discourage me, some people just don't like mods.

Anyway, in case I'll still participate or maybe you'll allow entries without FAR

Let me think about this... FAR does add difficulty since you can't make sharp easy turns. The reason for its addition is the emphasis on efficiency for Tier 1 and Tier 3 and to a lesser extent Tier 2. FAR is much more efficient than stock aerodynamics so I wanted to give them the best chance they had. If I let people enter without FAR it might be concidered cheap since its there is much larger margins for error in stock than FAR. Which also makes it easier to write scripts... However the players without would suffer from efficiency so it might be counteracted by this.

The rocket/script should be able to complete the challenge starting from any date or all of the 3 tests are going to take place on a new save file?

You are welcome to run things at a precalculated date. I can start a new save file if necessary. However... I suggest that you write into your code to determine when to launch based on the Universal Time. Since you can accelerate time to whatever date you wish at the launch pad you can move to the launch date that would best help you. After all, all launch windows come up every day/month with respect to Mun.

Hope this answers your questions! Let me know if you would still like to participate. I might add a section on those who do not wish to use FAR if there are enough people who wish to do this...

[Aphobius]

Thank you for the answers. I might try it if I have time in the week-end.

[celem]

This is very important, since a script with precalculated data (mostly burns) is much easier to make than a script that can complete the challenge by starting from any date.

Boy, you aint kidding. My entry for this challenge hit exactly this issue, it worked beautifully... provided it launched at UT 0.

Making a pre-calculated script resilient to this is less of a chore than it seems however, KerboScript is pretty smart and has a lot of options including solid timewarp controls. Adapting a precalculated script to find its intended transfer from any launch time is fairly trivial. (afterall its a window that pops up once per orbital period of your ship for Mun, so probably every 90 minutes or so) Certainly an easier concept than making a script that uses no such pre-calculated data and genuinely finds its own way.

Would strongly recommend those interested in diving into this challenge to stop by the subreddit, a number of us have been discussing the various hardships involved and solutions over there. (though you wont see any code, its a contest after all. XD)

Edited April 2, 2015 by celem

[John FX]

I found that if you get to an 80km orbit then an FRT needs exactly 872Dv. The timing of the burn can be calculated by seeing if Mun is closer or further away, when it changes from getting closer to getting further away then it is exactly above you and you are at a fixed point. Can't remember the exact amount of seconds to wait but you then wait for a precise time (around 3/4 of an orbit) and burn prograde for 872Dv. I was able to get a Pe around Mun of between 10 and 15km by timing my burn accurately. burn retrograde 100 seconds before Pe (at least on my craft) for 120 seconds and you are in orbit. Tidy your orbit and circularise and you are in orbit around mun from any point in time.

A good mix between checking and pre-calc and hardly any maths either...

AFAIK it's how the Apollo people did it. They knew a lot of the numbers and hardcoded them and had the AGC figure out the limited number of things that would change in the mission. They had hardly any processing power or sensors so it was how they had to do it.

[TheGreatFez]

Boy, you aint kidding. My entry for this challenge hit exactly this issue, it worked beautifully... provided it launched at UT 0.

Making a pre-calculated script resilient to this is less of a chore than it seems however, KerboScript is pretty smart and has a lot of options including solid timewarp controls. Adapting a precalculated script to find its intended transfer from any launch time is fairly trivial. (afterall its a window that pops up once per orbital period of your ship for Mun, so probably every 90 minutes or so) Certainly an easier concept than making a script that uses no such pre-calculated data and genuinely finds its own way.

Would strongly recommend those interested in diving into this challenge to stop by the subreddit, a number of us have been discussing the various hardships involved and solutions over there. (though you wont see any code, its a contest after all. XD)

Okay, I reallly hope this doesn't sound rude. But I am not sure exactly why a pre-calculated script is needed. Is it so you get the proper launch window to get to Mun? Could you explain in more detail why it is that you need to launch at exactly UT 0?

My issue here in understanding is that since you dont have any life support needed, then can you not get into orbit and then wait until you reach the proper phase angle to launch?

After I understand the issue better I might be able to aid you guys by somehow starting the game for your test runs at the same time OR more helpfully I might be able to give you guys some help into solving the issue.

I would greatly appreciate your input!

- - - Updated - - -

I also want to point out one thing to help incase anyone does not know already:

You can determine what the Longitude and Latitude of Mun is in respect to Kerbin. For example, if you "print MUN:LONGITUDE." it will give you the longitude that Mun is currently at on Kerbin. This is kind of important since you can use this data to then get a phase angle between you and Mun. Using this you can then figure out when to launch, based on what altitude your parking orbit is. That part you will need to Google and find out yourself but I hope this helps others!