Spheniscine

Arsonide, whyyyyy http://gyazo.com/1f38ab47c33ecde4e458bf9a82f226f6 http://gyazo.com/123094d7c8208169381d254ebbaa9c61 30 minutes of slogging through that terrain. >.< So glad the first point I visited is the right one. Next time I'd actually look at the map closer to see where the contract wants me to go...

Request: Ability to turn crossfeed off for radial decouplers? Seriously they shouldn't have crossfeed capability at all just like stack decouplers (and just rely on fuel lines for times when you want crossfeed)... but just the ability to turn it off would be nice.

I don't pay much attention to that because I have a bad habit of leaving games running in the background...

I think it's roughly in Mozambique actually

Fine Print contracts are based on part unlocks; they won't appear until you have researched nodes with key parts. (If you're playing with buy-in costs on, you do not have to buy-in to the parts for the missions to be offered, only unlock the node.) Without part mods that rearrange the tech tree or add new stuff earlier in the tech tree, this would be: Tech level 5: Electrics (probes and solar panels) for satellite missions (I suggest getting this first because it's among the easiest missions. You can generally use the same design for everything within Kerbin SOI, though note that some satellite contracts require you to stick one or more specific science equipment to them, always from those you've already unlocked) Aerodynamics (jet engines) for aerial survey missions (you might get them with only Flight Control, dunno if that is changed, but I don't suggest you attempt them without Aerodynamics, as liquid fuel engines don't have good range in the atmosphere. The wing parts are almost essential too. Stick to short range and lowish altitude (<13000m) ones until you get turbojets. I like using unmanned aircraft for these so if I screw up the landing, I won't kill a kerbal and lose reputation); Tech level 6: Specialized Construction (docking ports) for station/base missions; Electrics are also required. (Stations are really easy too as long as you can move a payload [i suggest Heavy Rocketry]; due to the differing requirements of each contract, expect to use the VAB a lot. Bases are similar, but will also require you to land them on a body.) Actuators (the Klaw) for asteroid retrieval missions, naturally Tech level 7: Field Science​ (wheels) for rover missions

Do you mean Kerbal Joint Reinforcement? Can't find a mod by the abbreviation "JRE"

I just treat these as "get payload X to location Y", nothing more (and not care why they'd want to do things like test a jet engine on the Mun; "it doesn't freaking work" is a valid, if expensive, test result after all), and usually use an unmanned probe to do it so I don't have to worry about returning or surviving the tests themselves. (another hint is you can empty SRBs or thrust-limit your LF engines to 0 so they don't actually fire when you activate the stage). Now that one I understand; they don't pay enough either, and often don't even cover the cost of the part itself. Suborbital tests pay much better and are much easier as all you have to do is strap a probe and enough SRBs to the thing to get to your altitude window. As for one thing I'd like to see... expanded rescue contracts. Keep the current (LKO circular near-equatorial) ones as a stepping stone for newer players and re-title it "Rescue Dandock Kerman from low Kerbin orbit", but add more complex ones, probably using a similar orbit generator that FinePrint uses for satellites, so you have to rescue from higher/inclined/retrograde/whatever orbits, or from other bodies. (Perhaps detect if you've completed an LKO rescue in your save. If you have completed an LKO rescue, these new "hard" ones have a chance to generate. If you have completed a "hard" rescue in your save, phase out the LKO ones, and only "hard" ones will generate.) And perhaps also throw in the occasional rescue from a suborbital/collision path with Kerbin (only Kerbin though; I'm only a little evil >), to give a little time and guilt pressure. (Just ignore/decline one of those, I dare you)

I believe that's intentional. They were pretty valuable to me when I was trying to design my first rovers. That way you can get a working design, use it, and get used to driving and the rover mission, before worrying about strapping it on a rocket to bring to other bodies.

Is it possible to add a feature to categorize craft by tech level? (perhaps a full tree might be too complicated, but they might be able to be sorted into tech level 1, 2, 3, and so forth)

I'm not sure what you read into my post. It's true that you can't see keystrokes in videos; if the player doesn't announce it, it'll look just like it switched automatically. Perhaps you thought my post was less helpful than the others since I did not tell you what keys to use... but the others already did, so there was no point repeating them. If anything it was more directed at RSwordsman's speculation that it might be a bug; my post is meant to say that "it might not be a bug; Dire_Squid might've just thought it switched automatically when the YouTube player used the hotkeys".

Or perhaps the person uses the key without announcing it? You can't see keystrokes in a video.

Hm... very interesting. I entered that formula into a spreadsheet, and apparently VOID's estimated burn time is wrong, and uses "t = -(m0 ve / T) (1 - e^(dv/ve))" instead of "t = (m0 ve / T) (1 - e^(-dv/ve))" (note the red minus signs). Sanity checks: Doubling the maneuver ÃŽâ€v should slightly less than double the burn time, as you get more acceleration as the ship burns up fuel. Similarly, increasing Isp should increase burn time slightly, as less fuel is burned, so you get less increase in acceleration. The second, correct formula will pass these tests, but the first won't. Here's the spreadsheet, so people can use it and/or check my work: https://dl.dropboxusercontent.com/u/26985795/burn%20time%20calculator.ods edit: based on the code you posted, the correct formula should be: return initialMass / massFlow * (1d - Math.Exp(-deltaV * massFlow / thrust));

Thank you for the tip, but I'm not quite as worried about assembly dV count (at least now that I know what the problem is), but rather that the burn time prediction doesn't work when I'm down to the top engines + rover. I'm kinda a stickler for that and the stock burn time prediction often doesn't work or is wildly inaccurate (saying like 1s when it's really minutes). edit: Ooh a test weight mod! Now I don't have to slap together bunches of fuel tanks to simulate asteroids <.<

The numbers are identical on my installation. The problem is with stage 1: note that the bottom rover decoupler is jettisoned at the same time the radial engines are fired (creating a lander probe + rover combination), and the final stage simply separates the rover from the engine (so the lander can either suicide or return to orbit). However, VOID fails to detect the radial engines and considers stage 1 to have no dV. Stage 0 displays the dV of the top part, but doesn't account for the weight of the rover. You can "fix" this by placing the rover at the top of the stage, but it would make landing the thing complicated. That's how I found the actual dV of the lander+rover stage (3.536 km/s; 7.915 km/s for the whole rocket), but I had to undo the changes before flying the thing, so VOID's in flight calculations during that stage becomes inaccurate again (and burn time for maneuver nodes becomes "NaN") edit: Is the stage information window from KER? If so they have the same problem... re-edit: Test-installed KER and it does indeed have the same problem. If it isn't fixable, then I guess I'll just have to deal or redesign.

By the way Toadicus, this is the rover lander where VOID gets confused about staging: note that on the penultimate stage when you discard everything below the rover (including the bottom decoupler), bottom stage dV reads 0.00, and the total dV isn't correct. https://dl.dropboxusercontent.com/u/26985795/Minmuscod.craft

The values are correct, but the units are weird (millimeters?)

How about... if non-phys time warp is unavailable, switch the time warp bar to be phys time warp (the one with the four arrows, capped at 4x). It's a little silly that people who don't know the key combination to force phys time warp (which are Alt+. and Alt+, by the way) are stuck at 1x when close to (or even landed on!) an airless body.

I understand that - I won't want the last part to be "switch navball relative velocity display to target, point retrograde and kill it" (which isn't even the last part of rendezvous/rescue/docking, since you actually have to then rendezvous/rescue/dock) either, but rather to have to use maneuver nodes to match the orbit. Really all I want is the intercept point/distance, as that is hard to see (right now I'm forced to use the apoapsis or periapsis as intercept points, which is probably not as time/fuel efficient as if I can intercept at any point).

Waypoints do have points that can use improving; mainly in ways that make them more similar to targeted bodies/vessels. I wonder if stock integration would open up some capabilities, making these improvements easier? 1) Marking the ascending/descending node on your current orbit, which will change when you tweak a maneuver node (as mentioned by paul23) 2) Intercept points, showing the closest point from your current orbit to a satellite contract orbit (also changes when you tweak maneuver nodes). This would require the ability to target orbits rather than bodies/vessels; no target prograde/target retrograde markers since that won't make sense. Probably no target relative velocity as well; would probably make things too easy. I just want intercept points because they're very hard to see (things that look close together on a two-dimensional screen can actually be pretty far apart). 3) Target retrograde markers for aerial/rover checkpoints; this is useful because a) helps you know where to turn if you're currently facing away from the checkpoint (though a maneuver-node-like arrow may be more helpful for this), and Target retrograde helps you when landing a rover; you can aim to land on or near one of the spots, to shorten drive time.

I think the dV calculations are off when you're using radial engines... specifically I'm using 4x Rockomax 24-77 engines, with the fuel tank attached to a rover. When I got to LKO it said I had 2.7 km/s, then when I did my transfer burn to the Mun (about 860 m/s) it then went down to only 680ish m/s. That's more than a factor of 2. Additionally, the "Bottom Stage dV" reads 0 when the radial engines are active, and VOID's burn time estimation doesn't work. (stock one still works fine, though less accurate and intolerant of quickloads) edit: Apparently it's not the radial engines' fault, but the rover. Attaching it to the bottom somehow fails to take its weight into account, and confuses the way VOID detects staging.

It would be useful if you could limit your parts by tech tree (temporarily of course) in Sandbox mode. This makes it easier to build a deliberately low-tech design, whether as a test for Science or Career mode, as a self-imposed challenge, or simply a way for new players to dripfeed themselves into rocket design without being overwhelmed by all the part choices. (I'm aware there's Science mode for the third bit, which is what I did. I soon moved on to Career mode though, and found it so much fun I stuck with that until I surpassed my current progress in all my Science mode games, forcing me to use the Wiki to plot out the rest of my tech advances.)

Interesting suggestion. As you might see in , it is possible to "skip ahead" and explore bodies even when not told to, and the missions would update accordingly to include planting flags or exploring further bodies... but the relevant explore mission might be forever denied for that playthrough...One thing that video doesn't show though, is that perhaps (I'm not sure) if you enter the SOI of a body but not yet got into orbit with it, perhaps you might be able to grab the relevant explore mission from the mission center?

Unless rescue contracts get expanded to include high orbit or other bodies

But it won't fit the Rovemate or whatever chassis I try to build that way; it's difficult enough to keep this thing from flipping over as it is >.<

Yeah that is currently missing; however I have learned a kinda crude way of finding your ascending/descending nodes: position your camera so that both your current orbit and your target orbit look like straight lines (you should end up viewing right through the center of the orbited body). The "intersection" is your ascending/descending node. While we're talking about rescue missions, they need more variety. I suppose having the first one or two be the relatively easy "low near-circular near-equatorial orbit around Kerbin" would be fine (learning to rendezvous is difficult enough for a new player, heck, I should know), but after that the game needs to start throwing some curveballs at you... highly inclined, high orbit, retrograde, highly eccentric, or around other bodies, or any combination of these, (or even, if you want to be truly nasty, "escape trajectory out of Kerbin"? Or even "collision course with Kerbin" [wow I'm evil; think about how bad people'll feel passing up those missions]) with correspondingly increased rewards. At the very least it'd allow me to add more rescue crosses to my ribbon without "accidentally" stranding kerbals for that