Dunbaratu

When landing on the Mun and conducting experiments and obtaining samples for return, the location is given with a lot of variety. It might say the experiment came "from Mun Lowlands", it might say "from Mun midlands", it might say "from Farside crater on Mun". Each of these locations seems to be a fresh new place to "mine" science from, getting full credit from scratch even though I'd been to the Mun before. But on Minmus, and on Duna It just says "surface of Duna" or "surface of Minmus". Am I correct to conclude from this that the entire surface of these bodies counts as the same "location" for science? That there are no unique locations on these worlds to "mine" for science when the description just says "surface of" with no more details?

With his buddies Bill and Bob trying to make do living a few years in a crash-landed capsule on Duna while they wait for a rescue mission. It turns out I had accidentally clicked the wrong thing and disabled the torque wheels on the capsule, making it very hard to control the landing. I could steer just fine while under thrust with the vectored engines. But as I made the thrust more gentle as I approached the ground, I lost control over steering and made a tumbling rolling landing. Jeb loved it, grinning like an idiot the whole time. The acceleromoter did gain some nice spinny data to transmit home .

Idea: with 0.22's tech tree, perhaps KOS should have several varieties of computer unit that get better as you climb the tech tree. The execution speed and disk capacity could vary depending on whether you use the primitive versions or more advanced versions of the part.

In the alternate game you're talking about where you have to do additional things to get more data that would make sense. But in this game that's not true. It takes no effort at all to just rightclick through the menus multiple times while the spacecraft drifts. You don't actually have to send an additional mission to recover the rest of the science available from the location you're in. You can just keep re-clicking on the same probe over and over until the science from an experiment is fully depleted. And electricity is an infinitely renewable resource so no, that's not really a cost. It's just a cost in waiting a few seconds for a recharge.

When you recover a mission, you get a little list of what things caused you to gain science points on that mission. I'd like to be able to see a list of all the things a campaign did so far to gain science. For example, if I've already done a sample-return from Mun's farside crater this campaign, it would be nice to have a place to look up and see that fact. I can imagine it becoming a bit of a blur in your memory if you play a few campaigns back to back to remember whether the things you remember doing were done THIS time around yet or not.

Yes, I noticed that too. For "roleplaying" purposes I try to recover the science bay but if I didn't care about that I could gain the science points by just repeating the "transmit data" process over and over. There probably needs to be a limit to how many times you can do that with the same science bay. Perhaps even a limit of 1. Let you keep re-attempting the experiment, but once you decide to transmit it that's it, it's locked.

I prefer two mods doing what they do best, instead of them both trying to do each other's part (with all due respect) half assed. You seem to be implying that what you're saying there isn't compatible with what I said (when you said "prefer" it implies you can't have both and have to pick one or the other, but I can't figure out what it is about what you're saying that isn't exactly 100% in agreement with what I said. If you want antennae range to be a limitation, let remotetech do it instead of KOS doing it, but don't demand that all users of KOS must use remotetech. So what that would mean is that KOS code would do this: If remotetech is present, then: ask remotetech whether or not craft is in range. else always assume craft is in range, effectively making range checks irrelevant. Rather than this this: If remotetech is present: then ask remotetech if craft is in range else sorry, out of luck, pal, you can't use KOS away from Kerbin.

You should be able to hear your own ship, though. It's the other ships you can't hear. If there's no intervening vacuum of space between you and the source of sound you should hear it.

Rover tests under different gravity than the target location don't really prove much.

Oh, and another important thing for driving the rover: The maximum speed listed in the assembly building for the wheels is an outright lie. For example, if it says the max speed is 60 m/s, and you manage to make a rover stable enough to actually not flip over at high speed, you'll find that your controls utterly stop responding altogether (W and S keys have zero effect on your speed) long before you get to 60 m/s, and long before the wheels actually break. There seems to be an unpublished, un-mentioned super secret max speed that's quite a bit less than what's listed: A max speed at which the controls stop doing anything and you're helpless to reign in the speed if it's on a slight slope. I've found that for the ruggedized medium sized wheels, it's really about 25 m/s or so where the controls have no effect at all, even though the max speed is listed as 60 for them.

It's possible, but aircraft landing gear don't steer, as far as I remember. So it works for a wheel in back but would probably give very funky steering physics if it was a wheel in front (where only the back wheels steer).

That's a good idea provided that kOS doesn't become intertwined with RT in a way that makes RT a prerequisite for using kOS. KOS still needs to function correctly for players who don't use RemoteTech. If the answer to "why can't I access the archive away from Kerbin?" becomes "Install remotetech first" it's going to put off some who might otherwise use kOS. Perhaps if RemoteTech is present KOS changes is behavior to use it, but if RemoteTech is not present it falls back to what it does now?

Bare minimum to function: - 4 wheels (footnote) - battery - some sort of battery recharger - solar panel or RTG. - a command core. - whatever structural girders are needed to tie them all together. Good ideas to enhance it: - self-righter mechanism - either landing legs on the top that flip it when activated, or an upward-facing tiny engine that can be thrusted to flip it. - kerbal-carrying seats. (a kerbal passenger can get out and repair broken wheels). - design it as flat and low as you can to make it less likely to flip over in low-grav environments. (footnote: Getting 3-wheel rover arrangements to work is hard because none of the wheels are designed to be attachable from above or between two forks - they're all defined to be mounted on one side, meaning you need a lopsided offcenter arrangement to get a single wheel centered.) Advice for the VAB: - The symmetry settings are hard to use for putting wheels on - often not letting you put the four wheels on correctly unless you do it manually. Placing manual wheels makes it very easy to make a lopsided wobbly lander. Be as careful as you can trying to keep it manually symmetrical. One hint: although you can't use 4-way symmetrical mode, you can use 2-way symmetrical mode to place one pair of diagonally opposite wheels, and then the other set of diagonally opposite wheels.

Oh, with the fact that the sign changes depending on which node you're looking at, I changed the thread to solved.

It's correct at the equator. I wasn't intending to claim it was a general case formula for all points of the orbit, but I admit that wasn't clear.

Already known. Already mentioned in my original post.

Stages are definately bugged currently when ships are broken apart and re-docked together. Even when you manually re-arrange the staging list it still doesn't respect your changes and still does things out of order. Rather than a suggestion I'd call repairing that a bug fix. The way it works now is not just inconvenient - it's actually wrong.

Big planet? yes. But small enough not to be a star. The "only" was referring to "We're calling it a planet because it's too small for a star.

I would like this, but it shouldn't have to be the mission flag. It should be any flag from the flags folder. This would allow you to put different decals on different parts. To implement it, parts would define a portion of their mesh to be the "put decal here" part of it. The part would define a rectangular area of itself to be the zone where a decal image would be stretched onto. Some small parts probably wouldn't have a decal area.

I hadn't noticed that KSP puts a different sign on the reported inclination depending on which node you're highlighting. Normally, an orbit's inclination is a number that is reported as being constant for the entire orbital ellipse, so when KSP showed a negative sign for the inclination, I thought it was reporting the inclination of the orbit as a whole. That's why I was trying to figure out how it decides an orbit (the entire orbit) has a negative inclination. It turns out that's not what it's doing anyway so that renders the question moot.

I'd rather take the approach of building a library of subroutines for people to pick and choose from rather than a single monolithic program. Now that the "Program ended" messages are going away for sub-program calls (once 0.8x gets fixed well enough to be usable) it's going to become more practical to use the "run progname(arg,arg,arg)" command as a subroutine call. It's got a lot of overhead behind doing the call, which makes it a bit slower than a native routine but for a thing like a scripting language it's about like a shell script running a lot of small programs to each do one little thing. And while a forum thread might be an appropriate place to ask questions about such a hypothetical library of example routines, or make announcements about them, I don't think it's an appropriate place to store them for download, as only the thread starter would have the rights to edit the head post of the thread so it would end up meaning it would be a thread of scattered examples to search for. A thing like a wiki makes more sense for collaborative work on a shared library of example routines.

Uhm. I know. That's why I posted what you quoted where I pointed out that the claim that it depends on where on the planet you cross the equator going northward cannot be true.

Are you claiming that the orbital inclination number KSP reports isn't globally the same sign for the entire orbit? That you get a different number if you look at the ascending node versus the descending node? If that's all you meant it could have been explained a lot faster that way instead of telling me what I already knew. I was operating on the belief that KSP applies the sign universally to your entire orbit, which is why it didn't make any sense to me. If it gives you a different sign depending on which node you're highlighting then my confusion entirely goes away based on that one fact alone. If that's what it does then it makes a lot more sense. I'll have a chance to try and see if this is true later tonight (not near a computer with KSP on it at the moment). I was already aware that actual astronomers only use degrees from 0 to 180 for this. But KSP used negative numbers and so knowing what actual astronomers do didn't help figure out what the negative numbers meant. If the sign flips depending on which node you're looking at at the time, then it would all make sense. All orbits with a nonzero inclination will BOTH cross northward of the reference plane at some point and cross southward of it at some point. If all the negative sign that KSP gives means is that it's an alternate way of saying "this is the descending node" then it's simple. If it was giving a negative sign on both the ascending and descending node, which is what I thought it would do, that was what I didn't understand.

Any orbit will do both of those things. It will contain one spot where it goes south across the equator and on the opposite side a spot where it goes north across it.

http://kos.wikia.com/wiki/ Look on the right side list for "tutorials and examples". Bizz has collected together some examples from other places and put them there. When I find a solution to a small problem I put up a small example there to show it. I think that's valuable as the target user for KOS is not someone who wants a fully working mechjeb to do the work for them, but someone who wants to make their own autopilot. So posting small examples that address specific individual problems along with the bigger examples that do an entire task is important. Some people will presumably want to make their own autopilot but want help with things like "how do I calculate such-and-such from the available information?"