Dunbaratu

It would be better to use a normal homemade variable instead of target here. Because target is a special variable tied to KSP's current target, and KSP itself refuses to let you target your current SOI body, you might not be able to set target to ship:body.

There are many things for which having some type of array variable type would be useful.

Oh no, that explains it. I didn't get your explanation. It sounded like you were just telling me that Mun:body:name returns "Mun". So to get my current parent body is just Body(body):body then?

That's not the question I asked. I was talking about the PARENT of the body. To write a generic routine. Instead of hardcoding something like this: "I know I'm at the Mun. I know the body I'll end up orbiting when I leave the Moon's SOI is Kerbin". I'd like to do a thing like this: "I know I am in the SOI of body X. I want to know about the parent body Y. Find Y given X." For the time being I'm still using my own bodyDB file for stuff like that, but it would be a good thing to have in the built-in BODY structure.

Is there a way to get the parent body of a body? For example, Mun:PARENT would return Kerbin.

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.

While you can list things with a command like this: LIST TARGETS. The list only shows up on the terminal screen and there's no way to capture it into a variable (yet?). I suppose a prerequisite for getting that data into variables would be support for arrays, which KOSscript doesn't have (yet?). (You'd need to store the result in something you could iterate over (thing 1, thing 2, thing 3, etc) and that would have to mean arrays or lists or something like that.

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 can't see the relevant difference between that and what I'm doing, which is this: // "steering" is already locked to "mysteer" by this point in the script. lock mypitch to 90. lock mycompass to (90 - endIncl). lock mysteer to HEADING mycompass BY mypitch. And then later on when I get to the altitude I'd like to begin my gravity turn, I do this: when altitude > gTurnBot then { // Steer it based on a cheezy parabola path (which isn't exactly right // for a gravity turn but the true answer requires ugly differential // equations and integration by slices, so screw it.) // The closer to the final desired velocity, the closer to horizontal to steer: lock mypitch to (90 - ( sqrt( (usevel:mag) / endSpd ) * 90 ) ). }. So it flies at HEADING 90 by 90 until it hits the height I want to start the turn at, and then it leaves the compass part alone and changes pitch to follow that sqare-root path. And the moment it does it turns NORTH instead of east, and then after about 10-15 seconds finally has corrected itself to east. If I'm going about 220 m/s when the turn starts, it typically ends up rotating down to about pitch 64 or so at that point. (The exact pitch changes depending on how fast I'm going. EDIT: oooooookayyyy.. I just ran my program a second time without changing ANY of that code at all, and now it works fine. I'm wondering if I had some leftover lock of some type that only cleared when I quit and restarted KOS?

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.

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.

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.

We all know that when you first tell KOS to change steering it tends to spin around stupidly for a bit first in completely the wrong direction before it realizes which way to turn and fixes itself. This is giving me a lot of trouble during my ascent script because when I tell it to go from a pitch of 90 degrees down to a pitch of 70 degrees in the east direction, it always first aims north for a bit and then curves around to east. by the time it does that it's already imparted enough delta-v in the northward direction that it will cause my final orbit to have a bit of inclination when I didn't want it. In the past I could always get around this by shutting the engines off until facing matched the desired direction, and THEN burn. But I hadn't made a launch script yet. That method works great in space, but not when launching. When launching you don't want to shut the engines off for the 10-15 seconds or so it takes for KOS to find out which way is which, because you need that precious momentum.

For the people who incorrectly think that a more modern computer fixes the limitations of the Unity engine, please stop. When it won't use multiple cores, and won't use 64 bit, then there's an upper limit to how much your modern computer will help. Modern computers get about the same performance as ones that are 6 years old on KSP because of those limits.

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.

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

Yes, it is. But it doesn't have to be. I chose my words very carefully there. I didn't just say that it is irrelevant to the calculation of whether or not the debris IS removed. (i.e. describing current game behavior). I said it was irrelevant to the calculation of whether or not the debris SHOULD BE removed. (i.e. describing how I am claiming the game should behave). As long as the drag coefficient is >0.0, then it doesn't matter if it's 0.2 or 0.5 or 200 or 500 or whatever because ANY drag will mean the orbit will eventually decay and fall in. If it only went as deep as 50,000 m or 60,000 m and had no parachutes it would still eventually go away. That's why I'm saying there shouldn't be a situation in which a craft dips deep enough into the atmosphere to be removed if it has parachutes, but not be removed if it doesn't.

I thought they broke in atmosphere like solar panels.

The up-arrow is the Commodore 64's font set way of printing the caret character, and the game borrows a Commodore 64 font so I guess this is what's happening. (I sort of wish it had the full Commodore 64 font set so I could draw boxes and lines with it, but it doesn't have those characters.)

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?

No, but lots of people have the same problem, and the more that report it the better. I thought it was just me, but clearly it's not. Something is broken about going on-rails and then coming back off-rails again, which also uses the persistence file and has the same symptoms.

Idea for how to submit. What if the submission involved having to post up code files and a .craft file somewhere along with the screenshots? The proof that it's really the code is that someone else can download it and run it. (which means you'd also need instructions with it, like "run this program, then this one, then wait until X condition and run that one.") The nice thing about that is that it would result in a nice repository of different examples after the contest is done. (EDIT: I tend to prefer to indent my code well and comment it well, and as such I usually run it through a little perl script to strip comments and indents before running it on KOS which penalizes you for good style. This means I'd probably want to post both versions of the code - the stripped version to actually execute and the unstripped version so it's legible and you can read it. The unstripped version might not run because it would exceed 10kb.)

Also, there is no such thing as a random number function in KOSscript. Sure, you could homebrew one using the classic divide/remainder technique, but it's not natively there.

It's not a bad idea but the only way to really prove that it's using that is to run the entire thing twice under two different settings. And that means twice as much mucking around with screenshots or video captures. Well there's two different parts of what I said. One is that I don't think it's necessary to *require* that the script perform the timewarps for a submission, as to a certain extent that decision is driven by the boredom of the player not the needs of the script, and as long as you're just drifting it shouldn't change anything whether you time warped or not, therefore it should be treated the same as the camera angle - not relevant to the correctness of the script program so go ahead and do it manually if you want. Sometimes I want to watch. Sometimes I don't. Let me decide on a case-by-case basis instead of having to hardcode it in the script The second part of what I said is that I dislike that it even exists at all because of breaking the fourth wall and that. That's really a second point and just my opinion, and not relevant to this contest. What's relevant to the contest is that I shouldn't *have* to do it that way, as it doesn't make the script any easier or harder to write. It just alters the boredom level of watching it. No RCS translation exits yet in KOS so that would be a HUGE challenge. You'd have to correct your drift by constantly rotating around and using the main engine to push left/right/up/down. And once you do dock. we don't have script control of the "undock" functionality.

I think that the actual steering under the hood is in a different frame of reference than the one exposed to the KOSscript programmer, and when setting the special variable STEERING to a direction you give it, it translates frames of reference between what you told it and what it uses under the hood. But then when printing the value of STEERING out, it doesn't translate it back so you see the under-the-hood version. Thus why locking STEERING to your own variable and printing your own variable gives a different result than printing the STEERING variable directly.