Jump to content

[kOS] The Automated Mission Challenge


Recommended Posts

Currently KOSscript has no way to let you extend antennae, which sort of matters for trying to obtain data from the archive. The only way to make antenae extended is to do it manually with a right-click. Otherwise they start retracted on the launchpad and that's it they stay that way because no script program can extend them.

Can we make that another manual task exception too? That we're allowed to manually extend the antennae to get around this problem?

Link to post
Share on other sites

2. You may not make any control inputs to the craft after launch, including (but not limited to) staging, fuel transfers, and docking/undocking. You may manually use timewarp.

I think that you can extend antenna before running program on launchpad.

kOS question - is there way to get trajectory inclination in kOS? Like when going to Mun and wating to end at equatorial orbit by mid-course burn?

Link to post
Share on other sites
Currently KOSscript has no way to let you extend antennae, which sort of matters for trying to obtain data from the archive. The only way to make antenae extended is to do it manually with a right-click. Otherwise they start retracted on the launchpad and that's it they stay that way because no script program can extend them.

Can we make that another manual task exception too? That we're allowed to manually extend the antennae to get around this problem?

If you bind things to action groups you can get kOS to do stuff with them. This is how I got it to open the solar panels on my vessel.

Link to post
Share on other sites
I think it's fine the way it is. The idea I imagine is to stop people from using things like mech jeb, or modified engines/fuel tanks with insane power/fuel efficiency etc.

And the KW pack at least adds some variety to the engines, making it easier than stock to pick the "perfect" engine for the task, in addition to the super-powered engines. (meaning you'll need less boosters for TWR on big crafts, and have less structural issues)

There are some mods I'd like to be allowed, but since they shouldn't affect the flight characteristics I can just run the first mission with the mods("a simulation" or something) while fine-tuning the code and then do it again without mod parts and hands free for the screenshots. :)

Currently KOSscript has no way to let you extend antennae, which sort of matters for trying to obtain data from the archive. The only way to make antenae extended is to do it manually with a right-click. Otherwise they start retracted on the launchpad and that's it they stay that way because no script program can extend them.

Can we make that another manual task exception too? That we're allowed to manually extend the antennae to get around this problem?

Unless I've missed something and it has broken, kOS can trigger action groups, and antennae can be set to de-/activate/toggle via action groups. 1+1=11, yes? :)

If you're using stock, the antennae shouldn't break, at least I was happily abusing science transmissions while flying around in stock back when it came out and mods hadn't updated. With DRE or RT they do break, not sure which is causing it, but RT has the dipole omni that's active from the start and doesn't break in athmo. (though I've just realized that I don't think I've ever tried puling stuff from the kOS archive using RT antennae, so I'm not even sure if they play nice with it.)

Link to post
Share on other sites
I thought they broke in atmosphere like solar panels.

Everyone else beat me to it, the assigning antenna to action groups, and that stock antennas don't break. Guess I'm just not on top of things today lol

Oh, also I think instead of assigning my solar panels to ag's, I'm just going to use the "panels on/toggle panels" command instead, except of course in the case of panels that need to be deployed seperately, like on an ascent module/probe, or ascent module carrying 3 kommsats, then ill just have the ascent modules panels on an ag, and the kommsats will deploy via panels on.

Edited by Sma
Link to post
Share on other sites
And the KW pack at least adds some variety to the engines, making it easier than stock to pick the "perfect" engine for the task, in addition to the super-powered engines. (meaning you'll need less boosters for TWR on big crafts, and have less structural issues)

There are some mods I'd like to be allowed, but since they shouldn't affect the flight characteristics I can just run the first mission with the mods("a simulation" or something) while fine-tuning the code and then do it again without mod parts and hands free for the screenshots.

I think the biggest concern about mods was the re-runnability by others. It's a mess to require that in order to check out your code someone has to have the same mods you have installed (and the same mods NOT installed, so the tester can't just install the superset of everyone's mods but instead has to keep adding/deleting mods to test different people's configurations.)

If you're using a mod like Engineer Redux to help make the craft design and then not using the mod or its parts during the run you submit then how would anyone else know anyway?

If you're using stock, the antennae shouldn't break,

Oh. Okay. I guess I was so paranoid about it after losing solar panels once that I just assumed antennae did the same thing and never actually tried having them deployed in atmosphere after that. Opening them on the launchpad and then running like that is fine.

Link to post
Share on other sites
I think that you can extend antenna before running program on launchpad.

kOS question - is there way to get trajectory inclination in kOS? Like when going to Mun and wating to end at equatorial orbit by mid-course burn?

You know the velocity vector, and the Up direction. With my tfDirtoUnitV over on the wiki (I can't easily go look up the URL now as I'm typing this on a phone) you can turn the Up direction into a unit vector, and then cross product that with your velocity to get the normal vector to the plane of your orbit.

Knowing the normal vector is the same thing as knowing the inclination, when you think about it.

Link to post
Share on other sites
kOS question - is there way to get trajectory inclination in kOS? Like when going to Mun and wating to end at equatorial orbit by mid-course burn?

There is also a BODY:POSITION vector for every body and vessel. The origin V(0,0,0) is your ship and all POSITION vectors are relative to the origin. You can move the origin to Kerbin or Kerbol in order to calculate angles between bodies.

Btw, Mun has no inclination relative to Kerbin equator so it pretty easy.

Inclination is little bit more difficult.

Edited by baloan
Link to post
Share on other sites
There is also a BODY:POSITION vector for every body and vessel. The origin V(0,0,0) is your ship and all POSITION vectors are relative to the origin. You can move the origin to Kerbin or Kerbol in order to calculate angles between bodies.

Wait, Mun:POSITION is the Mun's posiition relative to your SHIP? I thought it was relative to the center of the body it was orbiting (Kerbin). This really needs to be documented better, that changes everything and might explain why my Hohmann transfer calculations were a bit off.

Link to post
Share on other sites
Wait, Mun:POSITION is the Mun's posiition relative to your SHIP? I thought it was relative to the center of the body it was orbiting (Kerbin). This really needs to be documented better, that changes everything and might explain why my Hohmann transfer calculations were a bit off.

Yep, if you are in Kerbin orbit and print SHIP:POSITION:MAG it should be equal to Kerbin's radius + ALTITUDE. And by "You can move the origin" I mean that you subtract SHIP:POSITION from all BODY:POSITION vectors. That way you end up with position vectors relative to Kerbin then being at V(0,0,0).

Edited by baloan
Disable smilies in text
Link to post
Share on other sites
Currently KOSscript has no way to let you extend antennae, which sort of matters for trying to obtain data from the archive.

accessing stuff fromk the archive is... going against the premise of the challenge - that things should be local to the craft to avoid problems with the speed of light.

Personally I think kOS is still a little immature for this challenge, but I'm hoping to add a PROM and mid 70s stlye boot loader - once I've finished fiddling with using kOS to do the efficiency challenge - I'm at 8 units of fuel so far, I will get it to double figures..... but my next mission may well be an automated apollo style moon landing.

Link to post
Share on other sites
I think it's fine the way it is. The idea I imagine is to stop people from using things like mech jeb, or modified engines/fuel tanks with insane power/fuel efficiency etc.

well, ofcourse we dont let people who use the insane OP mods, i mean stuff like nova punch or B9 or KW

Link to post
Share on other sites
accessing stuff fromk the archive is... going against the premise of the challenge - that things should be local to the craft to avoid problems with the speed of light.

That is false. The challenge allows you to manually intervene to initiate programs as long as you do it at slow times when you could reasonably assume you had the time to do it with the lightspeed delay, and those slow times are explicitly detailed in the rules. So why are you implying that while communicating with a human is allowed during these stages communicating with the archive isn't?

In real life space programs, we've beamed software updates to probes a lot. Even the venerable old Voyager was designed to let us do that and we did several times. The idea that this challenge requires remaining out of communication entirely is utterly false if you read how the rules are laid out. You just need the communication instances happen when the craft is free to take its time.

Link to post
Share on other sites
Yep, if you are in Kerbin orbit and print SHIP:POSITION:MAG it should be equal to Kerbin's radius + ALTITUDE. And by "You can move the origin" I mean that you subtract SHIP:POSITION from all BODY:POSITION vectors. That way you end up with position vectors relative to Kerbin then being at V(0,0,0).

Oh, I get that once I realize this is what BODY:POSITION meant. It just wasn't documented that this is what it meant. It's not immediately obvious when in orbit around Kerbin and asking for the position of the Mun, as it will give a similar answer whether it's from you or from Kerbin. But I just tested the Muns position when I was in orbit around the Mun, and then the difference was clear. A few hundreds of thousands of meters instead of a few millions of meters.

Link to post
Share on other sites

I'd like to claim 3 points for a Kerbin orbit for the Kerbal Robotic Mission Project. After polishing the LaunchToOrbit, Atmosphere script we now are able to accurately and reliably launch to low Kerbin orbits. In a historic mission Orbiter 3 launched to orbit. Enclosed find proof of the endeavor. The LaunchToOrbit script and the mission toolkit v2 has been published on the kOS wiki.

KerbinOrbitBeforeLaunch.jpg

KerbinOrbitApoapsisBurn.jpg

KerbinOrbitMapView.jpg

Edited by baloan
Link to post
Share on other sites

By the way, is there such a thing as SHIP:POSITION? KOS tells me there's no such suffix. I'm running some ugly transforms math to turn UP into a unit vector and then multiplying that unit vector times the scalar (radius+altitude), where radius is Kerbin's radius.

Link to post
Share on other sites
By the way, is there such a thing as SHIP:POSITION? KOS tells me there's no such suffix. I'm running some ugly transforms math to turn UP into a unit vector and then multiplying that unit vector times the scalar (radius+altitude), where radius is Kerbin's radius.

I tried it. It exists for all bodies, like Kerbin, Mun, .... Apologies for the inaccuracy. No SHIP:POSITION and no VESSEL:POSITION.

Link to post
Share on other sites
I'd like to claim 3 points for a Kerbin orbit for the Kerbal Robotic Mission Project. After polishing the LaunchToOrbit, Atmosphere script we now are able to accurately and reliably launch to low Kerbin orbits. In a historic mission Orbiter 3 launched to orbit. Enclosed find proof of the endeavor. The LaunchToOrbit script and the mission toolkit v2 has been published on the kOS wiki.

And we have our first successful mission! Nice job! :)

I still can't get my kOS to work (likely due to a mod conflict), so I'm not going to be able to attempt this for some time. :(

Link to post
Share on other sites
That is false. The challenge allows you to manually intervene to initiate programs as long as you do it at slow times when you could reasonably assume you had the time to do it with the lightspeed delay, and those slow times are explicitly detailed in the rules. So why are you implying that while communicating with a human is allowed during these stages communicating with the archive isn't?

In real life space programs, we've beamed software updates to probes a lot. Even the venerable old Voyager was designed to let us do that and we did several times. The idea that this challenge requires remaining out of communication entirely is utterly false if you read how the rules are laid out. You just need the communication instances happen when the craft is free to take its time.

I was talking about the general case, not the "exceptional" periods. Otherwise you could simply have your main program be "switch to 0.until 0{run nextcommand.}.

Link to post
Share on other sites
I was talking about the general case, not the "exceptional" periods. Otherwise you could simply have your main program be "switch to 0.until 0{run nextcommand.}.

Wait what? You can run stuff straight from the archive? :o What happens if you have an archive program running and you go OoR of the archive? What happens if you have a running archive program that you edit externally? :huh:

Link to post
Share on other sites

I also managed to get some points. Here is video:

I decided that video would be best to show "brute force" approach in node creation (jump to 3:48 time ) :).

Kerbin stable orbit: 3 points

Mun SOI: 1 point

Mun stable orbit: 3 points

Total: 7 points.

I decided that i do not want to go and calculate vectors, launch angles etc. I want to use nodes just like i would do it in game.

So i have simple program for launch and start coasting. Since then i'm using create / execute node approach.

print "MAIN PROGRAM STARTED".

run autostage. //autostage for first stage

print "GETTING INTO KERBIN ORBIT".

run launch(100000). //launch routine, ends with coasting

run addcircnode. //add circulization node at apoapsis

run executenode. //execute node

print "TRANS LUNAR BURN".

run encounternode(Mun). // search for encounter with Mun by moving node around orbit (change time of node)

run encountertunenode(50000). // tune node by adding-removing prograde

run executenode. //execute node

run soiwait. //lets wait for Mun soi

print "ENTERING LUNAR ORBIT".

run tuneapproachnode(50000). //probably we ended on different periapsis than planned 50 000 . Lets fix it by radial burn node

run executenode. // execute node

run addcircnodep. //add orbital insert (circularization node) at periapsis

run executenode. //execute node.

print "MAIN PROGRAM ENDED".

Most interesting part is creating node for trans-Mun trajectory. It works that way:

(encounternode.txt)

- create node

- add prograde until its apoapsis equal Mun apoapsis

- then move node forward in time (basically around orbit) until we will get encounter

- when we will get encounter still move forward until periapsis of encounter will start to rise. (so we will probably get direct hit)

(encountertunenode.txt)

- here i modify prograde burn of node so i will get desired encounter periapsis

- first i add some prograde to node and check - what will happen. Will it raise or lower encounter periapsis?

- then i keep adding/removing prograde to achieve desired encounter periapsis

And then node is executed. Because i dont check node while execution (for example because of staging while burning and loosing ship max acceleration, or because of warping while soi change) i will probably end not on desired Mun periapsis after burn end. So program waits until entering Mun SOI and then i create node with radial burn to adjust periapsis. After that i create node at periapsis to circularize.

Remeber - all nodes are created by "lets add/subtract prograde/time/radial and see what happens". No precalculated deltav, just looking at node/encounter periapsis/apoapsis and keep changing input until i get desired output. So its basically brute force...

If you want i can post sources, just i'm pretty ashame of it, because currently there are no comments in it...

Edited by adammada
Link to post
Share on other sites

Am I allowed to click on the "Keep" button from science experiments? There is no control over this dialogue box in KOS, so although I can make an action group take the experiment, I can't make the popup box go away without clicking it with the mouse.

Yes, I'm trying to make a landing where I actually do some science robotically and bring it home robotically. Not part of the challenge but it's good for story.

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...