OHara

I tried your craft, using two boosters, and had no problems. (I never do, it seems the Kraken is afraid of me.) This sounds like a problem with autostruts. I hate autostruts. When you decouple they automaticaly lock rigidly to a different part that might be flexed, preventing it from flexing back to neutral. This can over-stress other joints, or over-stress the physics simulation while two auto-strut constraints argue with each other and exert large forces. The new engine-plates force everything attached to them to auto-strut to their grandparent. The identity of the grandparent depends on the root (image). If you turn on the option alt-F12:Physics:visualize-autostruts, I bet you can find what is causing you trouble. Edit: I have seen the orange lines disagree with the autostrut settings while in the VAB. They make sense, though after re-loading the craft file or going to the launch pad.

Remember that having Kerbin one-tenth the radius of Earth, with the same surface gravity, cuts the time to orbit by 1/3, for a given G-force on the astronauts. That makes the player's early try-fail-retry experiences much more enjoyable. It also forces other unrealistic factors, like the weak engines, to make rockets look somewhat like Earth rockets. You can see a consistency, though, as if they are all some type of hypergolic-fuel engine that restarts and throttles, in exchange for low efficiency. But, the numbers in re-entry heat are not so consistent: one-tenth the orbital energy does not require a system with 3000K heat-tolerance. I can see the wisdom in making a game with immortal Kerbals that do not eat, so that players can concentrate on the more fun aspects of getting them to Jool. The strong reaction-wheels rather confuse me, though. I find it more fun to fly with engine-gimbal and aero-surfaces, turn in space with RCS, and use only weak reaction-wheels for fine-tuning orientation. But I can simply build that way, so I do. Where the deviations from reality are simple, make the game more fun for beginners, and leave a self-consistent set of rules, I like them, especially when KSP lets mods easily change the rules when you get bored with them. More new players to support KSP and eventually recruit into RSS.

It is your choice where to install the game -- at least when you get it packaged the way Squad supplies it from their direct store. Version 1.2.2 (a good version) sounds like GOG ? You probably want to change the name of the folder to KSP122 or something like that, and then remove the folder holding the demo after you're sure the new installation is working.

Good question. I can demonstrate the inflated heat-shield and ignited NERVAs problem, using blowfish's method of deleting partDatabase.cfg in a stock 1.6.0, without Making History. That might narrow down the problem, so I'll update entry 20758 on the bug-tracker.

I meant that if your KSP installation does not use Steam, you can skip the first four steps in the 6-step process from ShadowZone that I quoted above. I'll edit above to clarify.

Some rules and limitations make an interesting game, so you play the game trying to succeed within those rules. Some rules are frustrating. Frustration is subjective so which which ones are frustrating varies from person to person. Those are rules to change. Often, we post our changes on Suggestions/Development thread or the community list of Module Manager Patches

There's a nice example at the "no-contract challenge". At first that sounds like the opposite of "financial mode", but it does have a financial constraint that the only source of funds is the World's-First Milestones. Kergarin makes it look easy, but if you ignore all the clicking he does to collect science, he is also playing your financial-efficiency game.

So far, the best advice is to try again, maybe squaring up the alignment like Cannon did in the thread below. There is some bug here, but whenever I try to make an example that always fails, it starts working.

Then reputation would be a measurable thing, convertible to /year. The mechanism for rewarding specific activities with specific amounts of reputation would be central to this proposed game-mode. It could be the current contracts system, using contract configurator to set the rewards, but I haven't seen any contract packs going in this direction. Simpler to collapse everything onto funds, and have the Kerbals draw a monthly salary if you want to penalize stagnation.

The JavaScript you linked to is finding shortest paths through the community delta-V map (forum post) and that map does not show all the shortcuts. Specifically the locations on the map called 'Intercept' are orbits that touch the associated planet and also touch Kerbin's orbit; the map is Kerbin-centric in this way. Decelerating from Eve-intercept-Moho-Intercept to Moho orbit can cause even less than the 2410m/s shown on the map between a Kerbin-intercept-Moho-Intercept and Moho orbit. How much less depends on what shape of Eve-Moho leg can be made with a gravity assist of Eve; 4×4cheesecake's example got it down to 2025m/s.

The system as it is supports multiple variant-selection sliders, but they can only change certain aspects of the part (mesh, size, cost) not including fuel capacity (forum link) (api documentation).

This has been suggested before, but now that the mechanism to chose variants of parts is established, and now that the VAB fuel tab is crowded, it might be worthwhile to consider this again. For backward compatibility, the mechanism of hiding old parts, but having them available for existing craft, is working well. One can imagine having just one fuel-tank part, with configurable (1/2) top/bottom cross-sections (3) length (4) paint scheme and (5) mix of fuel/oxidizer/monopropellant to fill the available volume, using five variant selectors. But, even one additional variant selector for length would let me find the FL-T{100, 200, 400, 800} after learning what just one of them looks like. If the diameter is a on a third variant selector, we might lose some of the flavour text from Junkyard/Rokomax/Kerbodyne, but that is no great loss. The different diameters can keep the distinctive detailing associated with the 'manufacturers', because different variants can load different models. (I don't immediately see this suggestion on the bug-tracker, but would not be surprised points out an entry they made years ago.)

Yes I also like to skip the science collection, and enjoy making efficient missions. We can set up something similar, by starting a Career save and then pressing the buttons 'Technology' and 'Facility' (and probably also 'Experience') in alt-F12:Cheats, to skip the science collection and building upgrades. I do not see any reason to give the player a budget for every year (even though there is a mod for that) because then you win by waiting. The player can use the contracts to fund his efficient missions. Even if you hate the generated contracts, you can use them as a source of revenue, cleverly completing contract requirements as a side-effect of the flying missions you really want. The contract rewards are generous enough that an experienced player can make this work, or one can double the 'Funds Rewards' setting to give a bit more freedom in choice of missions. I also like the option '[yes] Entry purchase required on Research' so I need to use the basic parts to earn money for the advanced parts.

I'm suggesting that Squad set both WASD and IJKL to operate wheels by default (the image in the top post). Then when people ask about rover controls here (most recent example) we can say simply "try using IJKL" rather than "quit to the main menu, then back to settings ..." among the other suggestions. 'Primary' and 'secondary' behave the same way; 'primary' is just written first. I was thinking to suggest WASD primary and IJKL secondary, but then noticed that WASD are disabled from wheels in Docking Mode, Linear Translation (player reaction thread) so I thought maybe list IJKL first and have them control wheels in all modes. I'm asking here to see if there are better suggestions, or changes to make it easier for left-handed single-button mouse users -- whatever I haven't thought of.

ShadowZone gives six steps to solve the problem, many involving Valve's system 'Steam'. If you don't use Steam, the same symptoms might appear on the first start after adding/removing a mod or mods, and are solved by closing and restarting KSP.

There are significant advantages to binding I J K L to control the wheels. You can accelerate without commanding pitch forward, and steer without commanding yaw, so there is no longer a need to disable reaction wheels and RCS while driving to reduce spin-outs and flips. The you can let SAS control reaction wheels and/or RCS to hold prograde as you bounce over the bumps. SAS does not try to steer the wheels. Mod-I sets a forward-drive trim, independently of pitch trim, that you can use as an approximation of cruise-control. Now that the EVA headlamp defaults to 'U' (was 'L' long ago) there is no conflict to controlling wheels with IJKL, even with Kerbals in command seats. The existing W A S D can be secondary keys, so that existing players can still command pitch-forward and drive simultaneously, while new players can use 'I' for wheels-forward and not be surprised that the craft bounces from the reaction wheels trying to pitch it forward. I am about to put this in a 'feedback' item on the bug-tracker, and thought I might collect other people's thoughts first. (A related idea is to add IJLKHN as secondary keybindings for EVA-Kerbals' RCS-packs, so that they can be flown in the same way as a craft under RCS translation control.)

I'm sure you're both right, and I'm surprised I can't find any historical post here with the math all in one place. The most Δv you can get from a close encounter with the Mun, without hitting its surface, is about 500m/s. But, that 500m/s is a vector difference, mostly deflecting your path. The resulting boost is not going to be in exactly the right direction that you need, and is not as effective at boosting your energy as would be 500m/s in low-Kerbin orbit when you are moving faster (Oberth effect). In an idealized case, suppose the gravity assist from the Mun ejects you exactly along its orbit at 300m/s, you have 300m/s + 540m/s = 840m/s relative to Kerbin, at the Mun's orbital radius. The excess energy above that needed to escape Kerbin is E = v²/2 − μ/r = 840²/2 − 540² = (250m/s)². But first you have to get to the Mun from low-Kerbin orbit using roughly 840 m/s using fuel You could get the same excess energy directly from low-Kerbin orbit burning Δv such that (2400m/s + Δv)² /2 − (2400m/s)² = (250m/s)². I get Δv = 1010 m/s, using fuel . So 170m/s savings in the idealized case, mostly because Δv at the Mun's altitude is not worth as much as in Δv in LKO. I think @Laie's example here shows the minor benefit really well: Gravity assists from moons, other than the Mun, start being very useful when you visit Jool.

Different terrain-quality settings (under 'Graphics' options) make the shape of the land different (especially around the Island Landing Strip). A craft that was on the surface with one setting could end up partially underground with another setting. KSP seems to try to account for this by storing both the craft's altitude and height above terrain, and does better after some trouble in 1.3, but does not do a perfect job.

Sorry. Freudian slip. I suppose I was taking for granted a minor patch the first week of January.

In the regular game, outside of any missions or the training tutorials, you need to explicitly turn on the navigation markers on the navball by clicking on the teardrop markers in the mapview, shown on the wiki-page you linked, and selecting 'Activate Navigation'. If some missions you played earlier turn them on for you, not all missions will.

Nearly everyone has noticed this in one form or another. Without mods, the second start of KSP should clear the problem (at least that is what I found and reported in the in a bug report, which I suppose you saw just now but for some reason it didn't work for you?) If you saved any craft when the problem was happening, after starting KSP again you will need to replace the affected parts with a "fresh copy" to get their right-click menus working. It looks like the PartDatabase.cfg is changed by adding/removing mods, or maybe on the first install from Steam, and the first time KSP generates it itself, it does so incorrectly. Other people, though, with different combinations of mods, used more elaborate solutions. Maybe verifying files from Steam link. Maybe deleting PartDatabase.cfg is needed (link). Maybe deleting *.loadmeta files is needed (link).

1. Autostrutting makes no change to the tree of parts attached to other parts (similarly to EAS-4 struts). Struts and autostruts make their attached parts move together as one rigid body, without changing the logical connections use for purposes of un-docking. 2. If the strutted-to part is detached, the autostrut releases (similarly to EAS-4 struts) and then attaches to some other part depending on the setting 3. The setting sets the rule for which part the autostrut should attach to. I think you know the idea of a 'root' part to which some 'children' are attached and so forth. Setting to 'grandparant' makes the part automatically set an invisible strut past or through its parent, to attach to its parent's parent. 4. A single EAS-4 strut or single autostrut will do the same job to keep two parts from moving relative to one another, so one cannot supplement the other. EAS-4 struts are for when you want to see exactly which parts are being held in place. Autostruts are for when you cannot set an EAS-4 strut between things that you want to be held in place -- most useful between parts that are docked together. 5. If the problem of a space station is the docking attachment points being wobbly, then an autostrut from one side of the weak link to the other will stop the wobbling. If the physics simulation is working reasonably, maybe simulating a feedback oscillation between reaction wheels and SAS through a wobbly connection, a wisely placed autostrut will probably help. Conversely, multiple autostruts holding parts rigidly in place relative to each other can cause large forces between these parts and the rest of the craft, and that can make the physics simulation get jittery.

I have not seen nor heard of any bug that sounds like you describe. There were not any changes with version 1.6 in how you assemble craft. I can't quite imagine what trouble you are having, but I'll take a guess that is likely wrong. Many people expect to drag with the mouse (mouse-button-1 down, move, then release the button) but in KSP you don't drag things, rather you click them once to pick them up, then move the mouse, and click again to place. The parts turn green when they are in an attachable place on the craft. If you put them down elsewhere, they become transparent, and red when the mouse is over them, but there is no need to clean them up.

Deleting PartDatabase.cfg and restarting is actually a sure-fire way see the right-click-menus bug (20734) with no mods. (See MM discussion here.) I only noticed the bug myself after deleting PartDatabase.cfg to clean up after some configuration-fixes I tried for the nerfing of the Terrier.

I have only seen this error when I got my install folders mixed up. The Making History and KSP version numbers match now, 1.6.0 for KSP 1.6.0 (different to how it worked a few months ago). KSP 1.6.0 has a buildID64.txt with "build id = 02395 2018.12.20" and Making History 1.6.0 has an uninstall.dat with "KSP-Making_History_Expansion-en-us-v1.6.0"