HebaruSan

Over the holidays, I fired up KSP on a laptop, partly to entertain myself, and partly to see if I could draw any of the extended family's younger ones away from creative mode mobile Minecraft. First, a 9-year-old nephew watched (parts of) a Mun mission and rescue. He checked in periodically but didn't get too involved. Next day, a 6-year-old niece asked if she could build her own craft. Sure! I was surprised how quickly she adapted to the editor with some at-the-elbow support. Selecting and placing parts was no problem. We launched a few simple parachute-pod-tank-engine rockets, and then the plane parts caught her attention, so off to the hangar we went. I probably interfered too much at that point---her first plane flew so well that she got bored with it and wandered off. Overall, I'm convinced that a brief guided session would be enough to allow an interested kid to become self-sufficient in the iterative design process. They may not go to orbit right away (but then again who does?), and the stuff that they do manage will be fun on its own.

What about lag? I thought the game had to update the locations of every craft every tick, including debris, so they could be checked for SOI changes, etc. I know that when I switch from my current relatively empty save back to one with 66 active flights, there's a very noticeable increase in latency that makes piloting quite difficult. I've started ensuring that all my debris gets de-orbited for that reason.

Try updating the list of available mods. It shows up as compatible with 1.0.5 in my files, but it's possible I've already applied the workaround... If you know that a mod is compatible with the current KSP version but the CKAN entry hasn't been updated (fairly common through the 1.0.x versions as few incompatible changes were made and not all mod authors kept up with their CKAN entries), you can fudge the compatibility by editing <KSP folder>\CKAN\registry.json and searching for the mod's name, then changing either ksp_version or ksp_version_max to 1.0.5 (change whichever one is not null). This will allow CKAN to install it for you. In essence it simulates what you'd have if you had installed it before updating to 1.0.5 and then didn't uninstall it. Note that the next time you update the list of available mods, it'll revert your change, so you need to install before updating. (Presumably this voids all sorts of CKAN warranties, so use at your own risk.)

Thank you for a very pleasant surprise! I installed this mod without reading the whole OP simply to get the "N/A" to go away, and suddenly a helpful little suicide burn indicator popped up! It took some guessing to figure out which mod was even adding it. KER? No. NavHUD? No... Also agreed with your appreciation of NavBallDockingIndicator. Its competitor's higher download count might have something to do with there being tutorials that explain how to use all the pieces of it as if it was an independent minigame; the simpler one requires a bit more experience and understanding of what docking is about, I think.

I believe some of that info is 26+ years out of date: ramjets can only go about 12% of light speed, since scooping up the fuel slows them down. Still, I'll check out the references for my spoilered content; thanks for the link.

Yeah, since installing 64K to alleviate my orbital delta-V guilt, more and more of my craft end up resembling a Delta IV Heavy. And if that's not enough dV, a little asparagus on top doesn't kill me. I've also started lessening my efforts to make payloads as light as possible. Designing custom launchers is like half the fun for me, so if I build a lander with a less efficient part (Mk1-2 command pod, I'm looking at you) or extra crew capacity, then that's just a bit more fuel and thrust that I need to budget into the lower stages. It's easy enough to roleplay that this choice was mandated by Kongress or another design team. (Of course this can require mods to avoid part counts that give the game engine heart attacks.)

Reality shows rely on dramatic personalities to generate conflict (with uber-troll producers egging them on, if "UnREAL" is to be believed) and heavy editing to create a narrative. Any space program recruiting program will be designed to generate as close to zero personality drama as possible; astronauts tend to be a pretty stable and capable (i.e., boring) bunch. So while everyone would probably watch the landing and keep up with subsequent progress reports in the media, a Mars base would be a poor source of minute-by-minute "entertainment" as such. I agree that there's no money to be made, at least not yet. I could potentially see a less catastrophic version of @Nuke 's scenario, where instead of total environmental and economic collapse, we run out of one particular resource that happens to be available elsewhere but otherwise we manage to keep civilization going. Something that's very useful and an annoyance to do without but not disastrous. If the scarcity of that commodity drove the price of a cargo hold full of it above the cost of a round trip, then that industry would start contracting for launches. (OT for this thread: Of course, there's little reason for the destination to be Mars...) Regarding non economical reasons to go, what about astronomy? The atmosphere is thinner, and unlike Hubble, a Mars telescope would have a crew nearby round the clock to operate it and perform maintenance. (Though again, if we can get life support working on Mars, we might as well put the same crew in orbit with Hubble itself.)

I wrote a simple bash script to grep CKAN's console output for mods that are newly added since last time, so that works for me. I appreciate how it limits itself to things that are mature/stable enough to be packaged properly, so I don't have to worry as much about fiddling with files manually. And I love that with CKAN, installing a mod amounts to subscribing to notifications when updates are available; even limiting myself to stock mechanics and parts (as I do in one install but not another), there are just too many that I rely on at this point to monitor web sites or forum threads actively. On the other hand, I did hear about Transfer Window Planner, Trajectories, Kerbal Flight Indicators, and NavHud all at once from Scott Manley's review of them (and I still have all of them installed). I'll be grateful for that video for quite some time to come.

Robert L Forward, Dragon's Egg. As far as I can tell as a non-physicist, it introduces just one truly speculative science element*, which is nonetheless treated carefully and fairly and isn't much more powerful than needed to enable the book's plot. The characters are possibly not the most memorable, but I'm prepared to accept that the mastery of physics and writing both take a lot of time, and so it's rare to have both in one place. *:

I believe the "Tree Toppler" mod does something very much like this in fewer clicks (except for setting up the Strategy). I plan to try it in my next career, since optimizing designs around Funds cost is fun, but grinding the final R&D upgrade to spend all those accumulated science points was a real drag. Since we have Science Mode, and Career Mode is basically Science Mode plus funds and contracts, maybe there could be a stock "Budget Mode" which does away with the tech tree but keeps funds and contracts along the lines of your model. It's clear that the building blocks are already there, and they just have to be assembled in a new way.

For what it's worth, rockets flipping is a known and expected problem in 1.0 versions for players who were used to 0.90 or earlier, because the atmospheric physics were changed. You didn't mention why you blame these parts mods, so it's possible that they would work well with a different ascent path. Here's a thread that discusses those changes and describes how to handle them: http://forum.kerbalspaceprogram.com/index.php?/topic/106618-every-rocket-i-build-likes-to-do-flips-stability-non-existent-in-10/

During a routine landing test of a tail-sitting Mun plane on the runway in 0.90, I discovered that on Kerbin, even long strips of concrete are built using a surprising amount of TNT. Only time I've truly guffawed in KSP, and I was lucky enough to reach F12 before the moment passed. I believe the craft escaped the blast intact.

I always thought the advantage was that new players don't have to find, download, and separately install something with universal appeal and no downsides, thus improving the initial gameplay experience and relieving some of the support burden on the community. Parts of KER are a decent example. If someone asks for early-learning-curve help with a mission on the forum, the responses invariably recommend installing this or a similar mod so the launch and burns can be planned properly and the stock maneuver node delta V readout can be interpreted meaningfully. If a certain tool is necessary to accomplish basic tasks in the software (or even to reach a moderate level of proficiency), it's reasonable to suggest including it in the main package. See also BetterBurnTime, which makes no changes other than to make an already-included readout more accurate and useful, and could almost be considered a bug fix. Admittedly I've seen that statement made when this standard clearly was not met (e.g., life support and realistic scale probably boost the difficulty level beyond what SQUAD intends to offer for mass appeal), but it's where I personally would draw the line. Despite that, none of the above should be interpreted as me requesting that any particular feature or mod be added or incorporated by SQUAD. The game is already winning awards and doing quite well at convincing new people to buy and play, which ultimately has to be their primary concern, and I'm content with an ecosystem of mods. Modders can afford to scratch personal itches, but developers need to make sure the time they spend is cost effective.

The way I did specific orbit contracts was less efficient than Wemb's method but maybe easier for beginners: Launch into an ordinary low equatorial orbit (easier than trying to time it right and eyeball the relative inclination on the map during a launch, and you can follow any launch tutorial verbatim) Once in orbit, switch to the map screen and look for the relative ascending node (AN) and descending node (DN) of the target orbit Whichever one has the target orbit farther away, set up a maneuver on the opposite side with enough prograde thrust to intersect the target orbit at the higher point After that burn, place a maneuver at the intersection (which should also be your Ap marker now in addition to the AN or DN) Drag the purple normal handles to match the orbit's inclination, the yellow prograde ones to raise the periapsis as needed, and the cyan radial ones to rotate, with the goal of moving your Ap and Pe markers to match the target orbit Perform that burn once you get there, then fine tune as needed This isn't the absolutely most efficient method, but I never ran out of fuel this way either, since most satellites can be built with very low mass and plenty of extra fuel.

We want a high-energy event on the surface, and we're starting from space. I'm not qualified to run the numbers, but could we use Rods from the Gods? The first one could impact shortly before the base-building probe at escape velocity to create a (hopefully resource-rich) dust plume in the vicinity of the target zone, and additional rounds could brake into eccentric orbits for future use as needed. Obviously a finite supply wouldn't work for long-term sustainable mining, but if you knew you needed a certain amount of a certain surface substance, it might be possible to design the needed impacts. Then again, I suppose the total mass gathered would need to be greater than the mass of the rod to provide an advantage over just loading the materials in the craft on Earth in the first place, which sounds like a stretch for a small automated probe to accomplish in the time the plume would last.

If the goal is that players tour the solar system before unlocking all science nodes, I don't think that can be done indirectly by fiddling with payout rates or diminishing returns. As long as the points can be gotten close to home, it makes the most sense to grind them there (in terms of time, cost, complexity, risk, etc.). Rather, I think you would have to do it directly. Split the tech tree, planets, and even science points themselves into 4 tiers. Tier 1 parts can be unlocked with science points collected in the Kerbin, asteroid, and solar SOIs, but if you stay there, that's all you get. Once you complete tier 1, you hit a wall and have to figure out how to go interplanetary to progress further. Tier 2 points are acquired at Eve and Duna and can be spent to unlock the middle of the tree. You have to visit at least one of them (but you get to pick whether to explore one or the other or both). Again, once the tier 2 tech is done, you can keep grinding all you like, but the rewards for it dry up. Tier 3 is Dres and Jool and most of the late game tech. Tier 4 is Moho and Eeloo, and the last few nodes of the tech tree are unlocked mostly as a sandbox-y reward rather than to be used for career missions (since you're almost done playing); maybe put the Vector and RAPIER here, but all science experiments should be earlier. I realize that interplanetary missions could be challenging with only 30% of parts available, but they're not impossible either, and part unlocks are that much more satisfying if you have experienced a pressing need for them. The different progression tracks of the game (parts vs planetary bodies) would finally be lined up with each other by design, and there would be strong game-mechanic reasons to go interplanetary. You'd also have a reason to pass up that first Jool transfer window since you'd want to visit a tier 2 body first. The science multipliers would no longer have to be balanced against each other across the board, since they're no longer a single indistinguishable mass. The player's progression would be more predictable and therefore a better guide to how the tree should be organized (LV-N partway through Jool, maybe?). And all of this is do-able within the current biome-based right-click-fest as it is; the mechanics don't all have to be completely overhauled, they just need to allow for some differentiation.

I can confirm this is workable in stock as well; a 909 with a claw and a dash of fuel is plenty. In the case of spent stages with some remaining fuel, it also offers the fun of deorbiting the stage independent of the reclamation craft by pointing it retrograde, optionally using the claw craft's reaction wheels to induce a spin for stability, and then gunning the engines and detaching. Genius! I'm a convert to this for my next career. I doubt a real space program would be quite so quick to adopt junk without inspection or refurbishment, but on the other hand it's neat how this alludes to the "build it in orbit" solution to lowering launch costs that would be necessary for larger-scale projects.

Anyone have access to any of the detailed planning documents for the Shuttle? If the gist of the discussion here is correct, then there should (might?) also have been some torque generated by the fuel lines from the external tank to the orbiter, depending on how they were aligned. It wouldn't have been the roll torque of asparagus in that case, but rather a bit of pitch torque, if the endpoints weren't colinear with the center of mass. If that's the case, then some engineer or other ought to have calculated its magnitude and discussed methods of dealing with it (such as keeping the launch clamps attached while the SSMEs warm up, which they did anyway). Similarly we might notice either a pitching motion or attitude jets firing when the ET runs out, if there is video of that stage occurring. I respect the physics and math abilities of everyone here, but I think NASA's design process was probably more resistant to easy errors of intuition that we might make.

Wow! I received that book as a gift decades ago and never cracked it open, but you've just bumped it to the top of my queue. That ship should have been on the cover! Now that Larry Niven's been mentioned, if it's permissible to mention a semi-realistic battle sequence instead of a ship, one of my favorite entries in that category is the sub-lightspeed interstellar chase in Protector, with the pilots spending months and years observing each others' ships and exhaust through telescopes, slingshotting past neutron stars, throwing sabotage devices into enemy ramjet fields, etc. Yes, I know it was later established that Bussard ramjets couldn't go nearly that fast, but I still feel that book succeeded in making space combat its own unique thing distinct from naval or air combat.

Hi and welcome! I started on 0.23, and I also created a forum account today after a long time lurking. Good luck in your forum adventures!

@Tellion and @Sigma88, you are awesome. I had trouble with this in my 64K-OPM install last week (Plock and Karen were missing, and focusing on Plock-Karen crashed the map screen till restart). Since Duna-Ike worked fine, I hoped I could update Tellion's config to look more like the ones from OPM, but I had no luck with that, so I resigned myself to playing with normal non-binary systems. But meanwhile you were figuring it out here, and now with Tellion's latest update and Sigma's updated template replacing the end of OPM/KopernicusConfigs/OuterPlanets/Configs/PlockKaren.cfg, everything is working! Thank you for making this cool stuff and keeping it functional, and please let me know if my updated file should be dropped off somewhere. Here's hoping I can actually get a ship out that far!