Jump to content

[kOS] The Automated Mission Challenge


Recommended Posts

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.

I'm working around this by minimising loop usage - in many cases, you can calculate how much time will pass until a certain condition is met - thus instead of using UNTIL or WAIT UNTIL I just wait a set amount of seconds while warping. Not perfect, but so far it works.

Link to post
Share on other sites
Another rules question: can people be allowed to use the mods that mod the KOS mod itself?

I don't have a problem with this. I went ahead and added Sensor Reporter to the rules. Also note that a non-official version of kOS is, for all intents and purposes (at least in my mind), not kOS. I'm going to edit the rules to clarify this.

Also, as far as the loop issue goes, unless it is demonstrated to be a clear and impassible barrier for longer missions, I see no reason to allow persistence editing.

I also see no reason not to allow multiple videos, both for computational reasons and because some of us might not have the time to perform the longer missions all in one go. :)

Edited by Thrfoot
Link to post
Share on other sites
I don't have a problem with this. I went ahead and added Sensor Reporter to the rules. Also note that a non-official version of kOS is, for all intents and purposes (at least in my mind), not kOS. I'm going to edit the rules to clarify this.

Also, as far as the loop issue goes, unless it is demonstrated to be a clear and impassible barrier for longer missions, I see no reason to allow persistence editing.

I also see no reason not to allow multiple videos, both for computational reasons and because some of us might not have the time to perform the longer missions all in one go. :)

The following two things you just said are (in the current version of kOS) mutually exclusive and cannot both be true:

1 - You are NOT allowed to edit the persistence file.

2 - You ARE allowed to perform the mission in more than one go. (come back to a saved game later and continue it).

In the current release of kOS, you cannot quit the game halfway through a kOS mission and return to it later unless you edit the persistence file to work around the vessel reloading bug, as described earlier.

If you're saying you can't do that to the persistence file then you ARE in fact saying the whole thing has to be done in one go.

Link to post
Share on other sites

I have the first interplanetary mission - to Duna and Ike and back home to Kerbin. I did it all in one go and had to compress video as I go, so the video quality is only so-so, but it's good enough to qualify, I figure:

I did a video of it, but it's very long. Even though I edited the video to speed up a few of the boring waits it still is 1 hour 24 minutes long. If you don't want to watch the long video and instead just use still screenshots as proof, they're down below.

Here's the video:

Take off From Kerbin.

I96yMGp.jpg

Stable orbit around Kerbin. (JUST barely. The periapsis is ever so slightly out of the atmosphere.)

nMl2PST.jpg

Escape from Kerbin SOI

Stable Sun orbit.

yicsGUJ.jpg

Transfer from Sun orbit to Duna SOI.

YHFuxGU.jpg

Captured at Duna to stable Duna orbit.

4Kc7nw8.jpg

Landed on Duna.

5dsSX0T.jpg

Ascend back up to stable Duna Orbit again.

MI61k73.jpg

Transfer to Ike SOI.

Zjxjtpj.jpg

Captured at Ike to stable Ike orbit.

mnaiL4f.jpg

Landed on Ike.

Xn8rgVO.jpg

Ascend back up to stable Ike orbit again.

mJvFR4s.jpg

Transfer from Ike SOI back "down" to Duna SOI and get recaptured.

2gix9YF.jpg

Escape Duna SOI back to Sun SOI.

Transfer from sun SOI back to Kerbin.

eOtYraD.jpg

Deflect course to intersect Kerbin's atmosphere and use it to stop me.

4gmDTqz.jpg

Parachutes on for "dumb" Kerbin landing.

7fO6QN3.jpg

Recover Vessel.

Yczv9pU.jpg

Code and Craft Files here:

https://drive.google.com/folderview?id=0Bxkeai7oN35fUkM1bmFRV0VKV3M&usp=sharing

Edited by Steven Mading
Link to post
Share on other sites
solution to the inclination problem.

I wrote a control loop solution to inclination, but it slowed the game to 3 FPS when running.... I unpacked the LOCK statements and it takes a side of printerpaper to write out by hand, so I'm going to go back to calculating a node then running it - it's a pain, it means I do a rough adjustment, then half an orbit and a fine adjustment, but.... even doubling clock speed on the CPU would still leave it on it's knees and I don't see a 7.5GHz processor happening any time soon

Link to post
Share on other sites
I think this challenge, in addition to being fun, has also turned out to be quite USEFUL to the development of KOS itself. .

It's made people ask for a lot of things, wether they are good or not is a different matter - several of the "pull requests" and "issues" are pushing for omniscience.

Edited by JoCRaM
Link to post
Share on other sites
It's made people ask for a lot of things, wether they are good or not is a different matter - several of the "pull requests" and "issues" are pushing for omniscience.

A "pull request" isn't someone begging for a solution. It's someone who already IMPLEMENTED one in their own forked copy of the code and is requesting that it be pulled back into the main code. And there's been a lot of that going on. It's just not in official release because Kevin is away.

Link to post
Share on other sites
A "pull request" isn't someone begging for a solution. It's someone who already IMPLEMENTED one in their own forked copy of the code and is requesting that it be pulled back into the main code. And there's been a lot of that going on. It's just not in official release because Kevin is away.

I know what a pull request is, and they implement omniscience - e.g. adammada's position of a node; and ORB:ECCENTRICITY - both of which I hope are rejected, should Kevin ever return.

Link to post
Share on other sites

Can I, with my craft in a stable orbit, create a maneuver node by hand and then run a program that uses it? Sort of like the current comet mission I think, they lobbed a craft way the hell out there and it's been sitting for years, now it's being updated with new directions from Earth, probably including a literal maneuver node :D

Example:

1) Run kOS program that gets to stable Kerbin orbit.

2) Manually create maneuver node to get to Mun SOI.

3) Run kOS program that uses the node from 2.

Alternatively, how do you create/test nodes inside the kOS program? I can't find info on that.

Link to post
Share on other sites
I know what a pull request is, and they implement omniscience - e.g. adammada's position of a node; and ORB:ECCENTRICITY - both of which I hope are rejected, should Kevin ever return.

Ah sorry. I misunderstood on whose part you meant the omniscience to fall. I thought you were complaining that the programmer would have to be omniscient to implement the request (i.e. the request is asking for impossible programming from the human being in our world, not the Kerbal in the simulated world.).

I'm of two minds. I see your point but some things are sensible to do in the faster world of c# instead of the slow world of kOS. Like having a natural log function instead of running a converging series in a kOS loop for it, or having an operator that does vector cross products in one statement. But it can go too far to the point where ALL the thinking was done for you in the c# code and you may as well just use Mechjeb's autopilot instead.

Link to post
Share on other sites

I know what a pull request is, and they implement omniscience - e.g. adammada's position of a node; and ORB:ECCENTRICITY - both of which I hope are rejected, should Kevin ever return.

You should be aware, that not everybody want to do "rocket science", and calculate by hand everything. I find kOS really interesting, just as i liked Colobot - because its robot programming, not because i have to use equations for orbital mechanics and make subprogram for all activities.

Edited by adammada
Link to post
Share on other sites
You should be aware, that not everybody want to do "rocket science", and calculate by hand everything. I find kOS really interesting, just as i liked Colobot - because its robot programming, not because i have to use equations for orbital mechanics and make subprogram for all activities.

But don't do the mistake of trying to do TOO much for them, as the players who want the work done for them already have another mod for that called Mechjeb.

I don't agree with Jocram about this one though. I don't think it's any more unrealistic to give people eccentricity and node position than it is to give them apoapsis and current velocity, though. In real spacecraft autopilot software even getting THAT much telemetry information is not automatic and takes work. Once you've accepted that it's okay to dive into the API to get things like your position and velocity it's hard to make the argument about avoiding the other data. Also, while having to make utility routines that calculate that data may be a fun programming challenge in a fully functional computer, it's not so fun in a 10k computer that runs at about 10 commands a second. Once you have to use up most of that 10k of code to just have library support routines there's nothing left for your piloting. Yes I know the real space program used computers with tiny storage but they weren't trying to fit ascii source code on them. The computer only stored the machine language code and also the designers didn't make the computer do all the work. Some of the logic was the responsibility of the peripheral control electronics, which they were also designing from scratch. Back in those days the idea that the peripherals should just be dumb and all the thinking should be on the computer wasn't the way things were designed.

If anything the way maneuver nodes work NOW on kOS even before adammada's change is giving people MORE power than they get playing manually and doing it by position is actually LESS powerful than what kOS does now. Playing the game manually you can't set a node by ETA time. You can ONLY set it by location. Via kOS you can set a node at a time further into the future than one orbital period from now. Playing the game manually you can't. If you click to set a node at a spot on your orbital path, the UI assumes you meant the next time you'll get to that spot in THIS orbit, not one or two orbits from now.

Edited by Steven Mading
Link to post
Share on other sites

But don't do the mistake of trying to do TOO much for them, as the players who want the work done for them already have another mod for that called Mechjeb.

Sure. I assume that kOS shouldn't get less information than player can get. And player can look where node is

Playing the game manually you can't set a node by ETA time. You can ONLY set it by location.

But its just interface thing, because you can just move forward-backward node until you get desired ETA.

You could argue that "lock steering to" is too much help, because its active steering, not avaiable in game for player. (like lock steering to prograde).

Link to post
Share on other sites
In the current release of kOS, you cannot quit the game halfway through a kOS mission and return to it later unless you edit the persistence file to work around the vessel reloading bug, as described earlier.

Oh wow, I hadn't picked up on that. In that case I guess I have no choice but to allow persistence editing. Thanks for pointing that out! :)

I have the first interplanetary mission - to Duna and Ike and back home to Kerbin. I did it all in one go and had to compress video as I go, so the video quality is only so-so, but it's good enough to qualify, I figure.

Nice work! I can't actually view it right now (everything is blocked at school), but I should be able to verify your entry later today and add it to the leaderboards. Edit: Verified and added!

Can I use an unload preventer mod? I am currently prompting to go and wake the other processor, but it's messy.

I am uncertain what you mean by this. Please elaborate.

Can I, with my craft in a stable orbit, create a maneuver node by hand and then run a program that uses it? Sort of like the current comet mission I think, they lobbed a craft way the hell out there and it's been sitting for years, now it's being updated with new directions from Earth, probably including a literal maneuver node :D

Sorry but no. Because kOS is capable of generating and reading maneuver nodes by itself I can't allow it to be done manually.

Alternatively, how do you create/test nodes inside the kOS program? I can't find info on that.

I believe one of the earlier entries did this quite well. Let me got get a link for you... Edit: http://forum.kerbalspaceprogram.com/threads/58068-kOS-The-Automated-Mission-Challenge/page5?p=783499#post783499

Edited by Thrfoot
Link to post
Share on other sites

@Steven Mading

About your mission:

I really liked your asparagus autostaging! I was searching for way to do it by "maxthrust", but it turned out that maxthrust doesn't check if engine has any fuel avaiable, so i gave up. I was ready to add some microengine to droppable tanks just to know that i can drop them, but i couldn't find way to check if engines have fuel. Your solution - to look for fuel usage change - brilliant! I will copy it.

Why didn't you use aerobreaking at Duna? I'm not sure if it would be enough to enter orbit, but for sure it would help.

Link to post
Share on other sites
Sure. I assume that kOS shouldn't get less information than player can get. And player can look where node is

But its just interface thing, because you can just move forward-backward node until you get desired ETA.

I wasn't aware that it let you slide it all the way around the orbit several times to put it far in the future but I just tried it and your'e right, it does. Never mind about that then.

Link to post
Share on other sites
@Steven Mading

About your mission:

I really liked your asparagus autostaging! I was searching for way to do it by "maxthrust", but it turned out that maxthrust doesn't check if engine has any fuel avaiable, so i gave up. I was ready to add some microengine to droppable tanks just to know that i can drop them, but i couldn't find way to check if engines have fuel. Your solution - to look for fuel usage change - brilliant! I will copy it.

Thanks. Beware that I've only tried it when lifting with Mainsail and Skipper engines. Because it's dependent on watching the rate of fuel loss, using engines with significantly different ISPs not in the 330-390 range of the typical liftoff engine might not work so well, or you might have to tweak the threshold numbers a bit. I figured testing it with every engine was not a high priority given that if you're asparagus staging it's probably because your payload is big. So you probably are doing it with the heftier engines.

Why didn't you use aerobreaking at Duna? I'm not sure if it would be enough to enter orbit, but for sure it would help.

Because math.

When areobraking ALL of the following enter into your calculation:

The faster you are going the more deceleration there is.

The amount of deceleration also varies depending on how deep in you are to the atmosphere, and that is a value that dynamically changes during the pass through the atmosphere. You start out at the thinner atmosphere, but then eventually end up in the thicker air as you pass by periapsis, and then back up to the thinner air after periapsis. But the shape of this path you take through the air *itself* is dependent on how much you decelerated during the pass, so the math gets very hairy.

So I avoided it because the challenge gives you more points for getting a stable orbit, and I didn't want to end up diving into the atmosphere and then STAYING there and having to go directly to the landing sequence because it's not coming back up. (EDIT: also, the challenge terms would have made it impossible for me to do so because a collision path for Duna is a time when I'm not allowed to tell the craft to change it's intended plan and try something different. I'd have had to intentionally *expect* to be stuck in the atmosphere and design the mission steps that way, and then be disallowed from fixing it if it didn't work out that way.)

So I did it to avoid hairy math. The challenge scoring system gives you no extra points for efficiency anyway, and in fact in some ways demands LESS efficiency because you get more points when you pause and get yourself stuck in stable orbits in places where direct landings and direct transfers would be more efficient.

For example, when going from Kerbin to Duna I briefly considered working out an algorithm for a direct transfer burn such that that the moment the craft leaves Kerbin's SOI it's already on an intercept path for a Duna encounter and you don't have to burn while in orbit of the Sun. But then I realized this would get me LESS points because it wouldn't count as a stable orbit while in the Sun's SOI if it had intercepts coming.

Edited by Steven Mading
Link to post
Share on other sites

I'd like to see a challenge where the "can't' interact at high speed because of light speed delay" terms in the rules were based on the actual time it takes to do so given the distance to the vessel, not "are you landed or in a stable orbit?". Because with interplanetary missions there's cases where the craft will technically not be in a stable orbit and may be on a collision path or an escape trajectory, but will still have many days before that happens in which to communicate with it at slow light speed radio delay on the way.

For example, take the NASA Voyager 1 and Voyager 2 missions. We sent and received signals from them quite a lot while they were on escape trajectories. The mission depended upon being able to do so. If a player wanted to get SOI points by trying a grand tour Voyager style with lots of flybys and slingshots eventually ending up on a path to escape the Sun, by the rules of this contest they'd never be in a position where they could give commands to the craft during all of that.

Perhaps a stripped down version of my simRadioDelay (without the fancy display, which isn't quite working right anyway) could be made a public "library" routine that people have to use to do their operations. The rule would then be that you can interact with the craft whenever you like provided every command you give it from the ground is given via a simRadioDelay call instead of directly. It wouldn't impact the 10k limit because simRadioDelay is called from the ground and therefore can be left in the archive volume.

The way it works, if you haven't seen it, is this:

while "switch to archive'd", you run this:

RUN simRadioDelay("some command here.").

and it will wait the amount of time it would take to do a round trip at light speed to and from the craft based on its distance from Kerbin, and then on the craft it will run "some command here", whatever it was.

You can see an example of me resorting to this (while landed so it fits the challenge rules anyway even without my proposal) in my video when something gave a flagrant error for unknown reasons after landing on Duna. (It starts at position 39:37 in the video) I cleared out the state and restarted the mission code entirely via simRadioDelay commands.

If you like this idea let me know first, as I would need to change one thing about simRadioDelay first. Right now it's hardcoded to presume your operations are all occurring on local volume 1, so it wouldn't be usable by people with multi-volume ships who might have been on volume 2 or 3 or 4 at the time. I can fix this to make it handle the more generic case once the various pull requests on github get back into a main release - there's one that gives you an ability to ask 'what is the current selected volume', which right now you can't do.

Edited by Steven Mading
Link to post
Share on other sites
I'd like to see a challenge where the "can't' interact at high speed because of light speed delay" terms in the rules were based on the actual time it takes to do so given the distance to the vessel, not "are you landed or in a stable orbit?".

I'd be more than willing to amend the rules when you've cleaned up your light delay code as you mentioned. The only reason I used the rules I did was because I wanted to avoid using other mods like RemoteTech while still requiring transmission times to be taken into consideration. Because the only time you can be absolutely certain that your craft will not impact anything before it receives the transmission is when it ls landed or in a stable orbit, I decided this was the best restriction I could impose. It would be much fairer and realistic if an actual light delay calculator was used.

Link to post
Share on other sites
Like having a natural log function instead of running a converging series in a kOS loop for it
most of those should be done by doing, instead of precaclulating :P
, or having an operator that does vector cross products in one statement
absolutely - a system like this would have dot and cross product hardware (and probably triple and quad product) - but I only have a little free time, and my planned modifcations to the language are about forth in line of my KSP things to do.
Link to post
Share on other sites
Oh wow, I hadn't picked up on that. In that case I guess I have no choice but to allow persistence editing. Thanks for pointing that out! :)
well, a well written program :P cleans up it's dangerous variables before shutting down for a save, so strictly speaking not needed....

I am uncertain what you mean by this. Please elaborate.

when my lunar module separates from my command/support module and lands on the target, the C/SM is "unloaded" by KSP as soon as the craft are 2.5km apart. In order for the C/SM to retrieve the LM (once it has taken off and established a low orbit), the user needs to switch to the C/SM, open the kOS module and manually run something. Currently

There are several mods that purport to prevent KSP from unloading craft, which would mean that the C/SM would be able to automatically retreive the LM once it had taken off without intervention.

Sorry but no. Because kOS is capable of generating and reading maneuver nodes by itself I can't allow it to be done manually.

That's a silly restriction - a manuever node is simply a time and a vector, if it's legitimate for you to type run "donode(27,V(100,10,0))." then all you're doing is making it awkward for someone to do that - and as the OP pointed out in their question that's just the sort of thing that happens in real life. If a participant's mission entirely consisted of them setting up nodes for the program to follow (following the interaction rules) it would be a legit automated mission, but we, the audience, wouldn't be very impressed. however, if someone can't figure out how to automate one aspect of the mission then I'd rather see what they have done than see nothing.

Edited by JoCRaM
Link to post
Share on other sites

I can see both sides. On one hand real space programs precalculate pretty much everything currently as I understand it.

On the other hand, this is an automated challenge, not a "write a kOS program vaguely like NASA does it in real life" challenge.

Were it my challenge I'd allow making nodes by hand, but it's not, and that's fine. I got my answer (and quickly, which I appreciate!), and while it makes things more awkward for me, I'll manage.

So far I've got orbit pretty well nailed down with one craft (and a script, I seriously doubt I'll be tackling the math to go deeper. I'll be going NASA style here :D), and have just accidentally escaped Kerbol SOI due to an odd bug in a script simple enough that it shouldn't have bugs.

What I'm aiming for is a free return trip to Mun and back.

What I've got is a lot of things in orbit, some interesting splatters, and a staging test vehicle headed for another star. Progress! :D

Link to post
Share on other sites
well, a well written program :P cleans up it's dangerous variables before shutting down

Uhm. No. You can't be seroiusly trying to pretend this is analogous to anything in the real world. First off real world computers can clear RAM without naming each variable individually. Secondly bad software even if that accusstion wasnt bull**** still does not make half the vessel vanish from reality. Stop pretending this is even remotely like a real world problem. I won't insult your intelligence by pretending you believe what you said.

Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...