Kerbart

No no, in the contest of having him grounded through non-conventional means (command seat, claw, harpoon, etc). You'll land him safely but that doesn't count as a "save" in the contract. At that point you'll launch him in a mk 1, have it fly for a few hundred meters, and land it. NOW you have "landed" your saved Kerbal in a command pod.

I like the way you think.

Mk-I capsule, less than a handfull of FLT-800's, a handful of engines and some auxilery equipment (parachute, moar struts, landing gear)... That really shouldn't cost that much.

If you define "wanting to be inefficient" as "enjoying the game while playing it, instead of a blind numbers-driven race to bring in as much science and funds with each mission" then yes, I want to be inefficient. Personally I think it's horribly inefficient to play KSP if you all you want to do is play the numbers. The stock market is a much better place for that. Me? I just like building stuff in space, making large space stations and challenging myself with docking and landing procedures. So I'm very glad that there is a "science lab" part that i can include in my stations. Please explain to me why that is inefficient? My goal is to enjoy the game. MPL helps me with that. Sounds very efficient to me.

Not sure where that symbol is rooted it.

Calculations inside the physics bubble are expensive since they take each part into consideration. Why not introduce a third physics mode, call it for argument sake "the simple bubble" where objects are still not on rails, but are now considered a single part with x mass. "Simple bubble" objects would only be spawned from objects under control and get destroyed (in an OOP sense) under the following circumstances: Hitting the surface above impact speed (determined by the weighted average maximum impact speed of all parts) Hitting the surface below impact speed -- object is respawned as the original object but is now static at surface like other debris/vessels on the surface Orbit: when the periapsis goes above zero, the object is respawned as an "on rails" object Destroyed: once outside twice the radius of the current SOI body the (it can be pretty large as the objects are lightweight to evaluate) and not meeting one of the above criteria, the object is taken out of the game Focus switch: any mini bubble objects are destroyed when the player switches to another craft. Minibubble objects would have very simple behavior: they're immutable in the state they were at creation (so you better make sure those chutes activate when staging). Above criteria would allow you to do a "bomb run" on an atmospheric body, drop parachute probes over a large area to cover multiple biomes and get science, without having to make a full descend. It would also allow recovery of booster stages (downside of that would be that everyone would apply parachutes to anything to recover it). I have no clue to what degree it could be implemented though (and I doubt it ever will)

It depends what your angle is on playing KSP. If your goal is to maximize the yield of every mission (science/contract wise) then there's little need for the MPL. Of course there's little need for anything as you can unlock the entire tech tree in two missions, as Scott Manley has shown. If you play KSP with a bit of a role playing angle, the MPL gets more and more useful. In the past it mainly served as a reason to have a sizeable space station with a science mission. Now you can use it to do science in orbit or on the surface when a contract asks for it, reset the experiment, and get funding as science for little effort and cost (once the MPL station is in place). Of course you can do the same with a thermometer readout but that doesn't feel like something a Kerbal Korporation would be willing to pay $30,000 for, where a goo experiment in orbit sounds much more realistic in that sense. Again you don't have toâ€â€there's plenty of scientific experiments that don't need resetting in the MPL but for me it's just more fun doing it that way.

Players who are new usually just jump straight in, without bothering to read any documentation. Heck, experienced players don't read the documentation given all the "OMG I'm saving the Kerbal but he doesn't do anything once he gets close to my ship" posts. So, what happens when you stage on the launch pad (pressing the spacebar is a fairly obvious thing to do)? Nothing. At least when throttle is zero. At 50% "something" happens although it's usually not enough. Now the player is encouraged to figure out how to increase throttle. With 0% they're not even aware there's a throttle contorl. Experienced players who want 0% throttle? They press X A single keystroke is not that much work, and it makes the game easier for starting players. I don't see what the issue is.

On Kerbin?

But then you'd have to explain the ball. WILSON!! Unless there's a Fedex rocket that crashed onto Duna Mars as well.

Unless I've just been lucky, but it seems that the PA and PE markers don't jump around like crazy anymore when orbit eccentricity reaches zero. Or at least it has to be a lot closer to zero before they start jumping (and no longer at the point where it's impossible to create maneuver nodes).

Sure. Show me the math, if it's that simple. Also: did you actually read the title of the thread? Unless I'm mistaken it's "remove local atmospheric despawn because of recoverability" and not "regard despawned jettisoned parts as recovered under certain conditions" but English is a second language for me, so please excuse me if I got that wrong.

I agree that there's hardly any need to "do science" in career mode as contracts deliver it in bundles. Solutions? Less science yields through contracts Science missions that have more variety in biomes and what needs to be scienced. We now have "run test" as an option on parts; why not have a "run science" option on science parts that tie in with contracts? "Measure temperature while landed at the desert" or "Measure air pressure while flying between 1000m and 5000m over Kerbin Highlands" something along those lines. Science unlocks the boxes in the tree. The parts have to be unlocked with separate missions/contracts.

The contract text suggests that it's the result of an eksplosive kind of mishap. Ironically of course in a game about orbital mechanics where most players know that an explosion would always result in a suborbital trajectory (unless you have some kind of circularization burn).

Is there anything that needs "fixing?" Science is meant as a way to enhance gameplay by setting goals and posing challenges (performing missions without the parts that make it easy). The thought of tying in Science with Contracts (R&D) is interesting and I wouldn't be surprised if .25 is already being developed in this direction. If the challenge is to make science more realistically, tying it to reaching certain bodies is not in line with that. But certain milestones would surely work (first orbit, first mun landing, etc). Perhaps new science can only be unlocked in the tree if all the parts in the parent nodes have been "triggered" (staged, tested, put in orbit, etc)? In a game where 100,000x time acceleration is available anything that is time-based to force players "to do without this technology until it becomes available" is bound to fail. Tying it to real-time clocks will not go over well, and is hard to defend in light of "making things realistic"

Doing one contract per mission is a good way to run out of money. Start approaching it in a more economic way and the money piles in in ridiculous amounts: Pile up all the "at an escape trajectory" contracts. Once you have half a dozen, build a rocket for them and you can execute all contracts at once (make sure you deal with the right-click test run parts first before staging) In a similar fashion, Pile up al the "landed at Kerbin" contracts. You can recover most parts here, so don't actually launch anything. Just test on the launch pad, and recover everything after the experiment Third of these "do everything at once" contracts are the "splashed down" ones. Same approach. Just toss 'em in the water (one or two RT-10's will usually get the job done, throw in some RV-8's to make the stack controllable), test, profit. Do science. By know everyone has science stations (fancy mobile labs or a simple thermometer readout) that make these missions the "printing money in 30s" type. The remainders are where the real fun is; testing parts at various altitudes and velocities. This is where I think the game really has matured. No willy-nilly launches: each of these launches is meticilously planned to make sure all tests are compatible with each other (or can fail without a problemâ€â€let's throw in "test small gear bay" here in case I overspeed) and for each of these launches I now have checklists and I need to monitor the ascent carefully to stay within the testing envelope. No "full throttle see you in orbit" launches but challenging ascents where I'm trying to cover three or four contractsâ€â€or even more sometimes. Take this into account and you'll quickly find you have more than enough funds to burn.

Yes, I did not consider that option. BUT... this would mean that every part with a control unit would constantly be inside an "active" physics bundle. The minute you say "well deactivate them after landing" you're just going to get other complaints by users who find that their plan of bomb-dropping probes all over the place isn't working. Ok, so we keep 'm active*. Keep in mind that you're stuck in Physics Acceleration until all of those spawned off units have been resolved. And since you're running a handful of them (or more), Physics Acceleration at maximum speed probably means realtime. At best. More likely your simulation will be running at half-speed. Or quarter speed. "So what?" Well, you're going to be stuck with that for the full 500m those items are floating down on their chutes at a leisurely 7.5 m/s - That's about 1m gametime, and if you're running at quarter speed that's 4m of real world time. And that assumes you can keep track of them until they land and hit "recover" to speed things up. Let's hope your launch vehicle doesn't need attention in the meantime. I'm not saying it's impossible. But it involves adding a lot of features to make it happen, possibly dramatically impacting framerate performance. It's a lot easier to say "design wisely. Boosters spent are boosters spent and won't be recovered. If you don't like that, start working on those SSTO skills" What I do suspect in future versions is that some boosters will have some auto-recover flag. After all, the KD25K description already states "This super heavy booster is designed to be recovered after jettisoning. Once recovered, it is refurbished and refueled for another launch."

Whenever you find a shortcoming in the game, ask yourself a few questions. Why did they do it that way? What would happen if that limitation wasn't there Would I like the new version? It is safe to assume that in-game limitations are there for a reason, and not put in by the developers to troll us. For recovery it is indeed annoying that individual parts that spawn off your ship (booster rockets, etc) simply vanish. Ok, so let's run those four boosters in their own little physics bubble. Surely it will slow down gameplay, but hey, now you can build recoverable boosters. Ain't that cool! And then you launch a whackjobian contraption that dumps 36 first stage boosters in the first 2000m of your ascent. Frame rates crawl to a halt... Wait! It gets worse! Two of those boosters crash into each other, causing an explosion which spawns off 60 parts splattering all over in all directions, and of course crashing into other spent boosters. A chain reaction follows and now there are 684 parts flying around that the game has to keep track off, each in their own little physics bubble. "Well don't put them in different bubbles" How would you merge the bubbles? How much calculation time is allowed to be spent on that? "Simply increase bubble size" To what? 100km? Whatever the size is, it's always going to be not enough and it's quickly going to be too big for your computer to handle. The problem with most suggestions is not that they're bad; they work very well for the intended scenario. The problem the developers are facing is that they have to make their code work for every scenario we, as users, can come up with. And we come up with a lot... As a result we end up with a lot of limitations that seem arbritary, yes even silly. But it's pretty safe to assume they're there for a good reason.

That makes sense from a balancing perspective, but not from a game play perspective. Do this and you'll get complaints that players get rewarded for failing by getting more high-yield contracts. I'm not sure if, in the current form, there's a satisfying solution. Reward success and the game gets too easy as you succeed. Make the game challenging as you get further and the game punishes success. In most games you can easily adjust this by increasing the resistance, but that's not possible in a game built on physics. What I'd like to see with contracts is payloads. Have a separate group of "payload objects" and have a contract that says "put satellite KZ1267" (which will be available in the payload group after accepting the contract) in an xyz orbit around abc" As your reputation increases: Satellite weight will go up Deadlines will go down Orbits will get further away (higher altitude, different planet, etc) Orbit definitions will get tighter (apoapsis between x1 and y1, periapsis between x1 and y2, inclination between x3 and y3) As the reputation goes up, the difficulty and payout goes up. Contracts can then also include missions to de-orbit objects.

The more Funds you recover. So, this is good... But this is better!

Gotta love contracts!

Debugging is generally considered as one of the hardest aspects of software development. A statement like “I mean it's just a bug so it shouldn't be that hard to get rid of.†raises the impression that, as far as writing software is concerned, the author of such a quote likely has little practical experience with it. Some might even go as far as calling it “ignorant†To get an idea how hard it is, the first step in squashing a bug is to be able to reproduce it. So just for giggles, set yourself a task and describe exactly how to invoke a Kraken. Every single time, 100% predictable. “Load this craft, go into this and this orbit. Do this, do that, set warp to 100x, do this, this, and this. Set throttle to 100% and BAM! There's your Kraken† something along those lines. Mind you, it doesn't work if you get the Kraken 9 times out of ten; you have to figure out how to summon it every single time, and leaving out any unnecessary steps in the process. And that's only reproducing the problem. Now you can start trying to fix it. And just because you know what the problem is doesn't mean it's easy to fix. The Kraken found its origin in the fact that only sixteen decimals of precision doesn't cut it for KSP. But those sixteen decimals are all you get in Unity. Oh, and whatever you do, it shouldn't break existing mods, it shouldn't affect performance and you'd better come up with a solution fast because the users expect the new version to have new features, not "just" bug fixes.

No, the Brits were basically able to crack all Enigma communications (with the help of the knowledge of the Polish secret service) without capturing any devices. The name "Enigma" was well chosen though; cracking the code meant figuring out many aspects: the encoding of each of the code wheels, which ones were used, and what their initial settings were. Knowing the configuration of the code wheel sped up things and capturing devices sped things up but without them results were made as well. An implementation that made Enigma very practical in daily use was the reverser stator, but this also proved to be the key weakness. The way Enigma was constructed meant that the same machine and the same "code" (initial settings) could be used to code and decode. That is practical on the battlefield; you don't need to lug around separate machines for sending or receiving, or set them up differently for sending or receiving. It also meant though that a letter could never be encoded to itself (e.g. an "a" could never be encoded as an "a") and that turned out to be key in deciphering the messages. In the end, Enigma was not as secure as the Germans thought although this posed a problem to the Allies: acting upon all information intercepted Enigma traffic revealed would signal to the Nazis that their communciation was compromised. The fact that the German forces never realized Enigma was broken shows that this was handled successfully.

Great idea! Not everyone loves writing things down and VAB tripping does get old. Tip: Go to the KSP wiki and use your browser to research parts. At least you don't have to trip to the VAB, just outside KSP and then come back where you were. But this is really a good suggestion! It would be nice if the user could resize it, at least in vertical direction. Also: show Funds when in the VAB to know if what you're building is worthwhile (see point #1) That requesthas been out there for a long time. Just launch it and use the revert function for that purpose. It's only "cheating" when you consider it so, and especially when you do a launch purposely to test things I wouldn't refuse reverting "because it's cheating" because, well, it was never intended as a "real" launch. Click on the crew button in the VAB, unload the existing crew, and reload with other Kerbals. Also, launch a Mk-III capsule with Jeb, Bill and Bob, land it after a few seconds just outside the VAB and name it "Jeb's Tiki-Bar" and simply never recover it. The dudes will be hanging out at the Tiki Bar and hapless victims will have to volunteer for your missions. Oh boy... There's a mod for that. This has been discussed at large. Short version: if Harvester & Crew wanted KSP to be realistic, do you really think they'd stuck to little green men and Kerbin? Wouldn't an alternate Earth make more sense? It's a game, games are fun. It's more fun to send your little people into space than to send cold anonymous electronics. And you can always use the BetterThanStartingManned mod.

“Nothing is impossible for the man who doesn't have to do it himself†â€â€my father