OHara

I don't know why but here is my understanding of when you get each type of collider: Close the fairing on a part. We have to be careful with quicksave/quickload, because the reload might have loose parts in the fairing collide with the fairing wall. Close the fairing on a part, then decouple that part. Close the fairing to a point.

I wasn't sure, so I just tired it. Just closing on a part also gives a hollow collider.

Before the Breaking Ground add-on, I was happiest with a two-stage shuttle that depends on a surface base for refueling. The Mk3 booster portion is shown at left at the refueling/science base, with the local exploration aircraft in between. The 4-kerbal Mk2 upper portion is shown at right docked to the orbital station. This 2-stage shuttle needs to start about 7400 meters above sea level, so the colony is restricted to on of Eve's high points. The shuttle launch to orbit (link) and glide back to the peak is just difficult enough to be fun --- difficult enough that I didn't want to return the shuttle to the base just to make a screenshot here. Be sure to see Kergarin's thread,

The fairings that close to a point have a solid collider. Fairings that close on another part have a hollow collider. You can enable the 'interstage nodes' on the fairing base, attach a nose-cone to one of the resulting green nodes, and then close the fairing on that nose-cone.

No viscosity; KSP's atmospheric drag is all of the Cd×velocity² type from stirring up momentum the air. (At slow speeds the oceans act like they have viscosity -- so that your splashdown comes to rest and lets you hit 'recover' reasonably quickly.) The density and force of gravity are the only mechanisms I know of that makes different planets feel differently to aircraft. Eve has similar density to Kerbin at the altitudes where the have similar pressure, if the wiki is still correct. There is an 'aero data' option in the alt-F12 debug menu that might show you more that you are interested in.

About a year ago, a bug appeared that sometimes makes fairings not let go, https://bugs.kerbalspaceprogram.com/issues/21915 It appeared when Squad implemented a feature-request to keep the deploy mechanism active on fairings between stages, and now it seems we are stuck with it. The reason it sounds like you hit this bug is that it depends on where the 'root' part is relative to the decoupler inside the fairing. The root part is the first one you place. When sections of the rocket separate KSP follows the section with the root part. You can change the root part with the fourth button in the upper left of the VAB screen, after 'offset' and 'rotate' If that is the problem causing you trouble, then the workarounds are: + After decoupling, right-click on the fairing and select 'Deploy' so that the fairing separates into pieces, or + Quicksave and quickload, F5/F9, or + While still in the VAB, change the 'root part' to something above the decoupler

You got an answer here (link), not a solution but suggestion of how to start figuring it out, that you might not have seen. Jimmymcgoochie suggests looking at the file 'ksp.txt', but it might be called 'KSP.log', for clues. You have two posts on the topic, which happens a lot to new people on the forum for some reason.

Yes it still exists. In fact, Deddly just recently put it on the bug tracker (here) and he would have been careful to check if it was already reported. No one working for Squad has been collecting reports here (in any visible way) for years; they don't seem to be a big enough company. Did you (or someone else on the forum) post it two years ago ? We could refer back to the earlier report, which might help, couldn't hurt. I don't often notice it, so I think it does not always cause a problem. If it isn't fixed yet it might be for a stubborn reason so we might be wise to learn to avoid it.

KSPs wheels produce a force (specified as 'torque' as it would be from the drive shaft) that falls off with speed. For the XL-3 wheels in particular the torque falls very quickly; at 6m/s it is just 12% (3 ÷ 25) of the rated torque. torqueCurve { key = 0 25.0 0 0 key = 1.5 15.0 0 0 key = 3 5.0 0 0 key = 6 3 0 0 key = 15 0.5 0 0 key = 15.5 0 0 0 I change the game to my own liking with a module-manager patch, just for these wheels as the others seem fine to me :

Ablator makes very little difference (thread link). KSP includes radiative cooling in its thermodynamic simulation, and if you look with the alt-F12 thermal debug information, this mechanism dominates the cooling of heat shields when they start to get dangerously hot. Radiative cooling increases quickly with temperature, T4, so 20% additional heat raises the temperature in Kelvin just 5%. The heat shield survives a rather high 3300K, and has very low thermal conductivity so it protects further parts quite well. Given the physics that is modeled, reducing the temperature at which heat-shields fail would be a more effective way to increase the difficulty in this area of the game. I realize that that was just observations of the game, and you asked about rationale. I think @NathanKell adjusted the thermal model when he was working with Squad, after having experience with his Real Heat mod among other things, so you might look in that mod's thread for insight. I would not assume that he was able to put all that he wanted in to KSP, of course. Also, there are a few independent mods and suggestions on the bug-tracker in this area, so you are not the only one who finds KSP imperfect in this area.

Are you using SAS ? If I understand your craft, the Thuds are pointing opposite their usual direction, relative to the control point. If a tiny amount of roll starts, then the SAS would gimbal the Thuds in a direction that makes it worse. (Pitch and yaw controls don't flip so don't have this problem.) You can turn off the Roll response of the Thuds (enabling the option in in-game Settings: Advanced Tweakables). Or you can change the 'control from here; part or select 'Control Point: Reversed'. Or you can leave SAS turned off. Or some better solution you'll probably think of. If it is not SAS, maybe one of the Thuds' exhausts is being blocked by the asteroid, which would cause a pitch or yaw. I can imagine the gimbal to correct that pitch/yaw with partially blocked Thuds could induce some roll.

What do you think of a longer strip mowed into the grass ? Even better, I think would be to have KSC modeled to look like a tidal island, where geologic rebound has raised a former tidal flat to form a flat plain of bare packed sand. Then there is something that looks like a runway that we can try to land on if we find it fun to try, but a convenient alternative that looks appropriate for experimental aircraft. A couple years ago Kergarin (who is rather good at making craft with extreme capabilities) suggested a longer runway (forum link). The forum (which was somewhat less friendly then than it is now) was unable to convince Kergarin that he was playing the game wrong, but we found it rather easy to convince him that having a runway that typical aircraft find reasonably challenging, is often fun. Several of the basic parameters in KSP were adjusted when the game was first designed. Smaller planet, heavier engines and fuel tanks --- and air that feels thicker at low speeds. (Actually under the hood the density stays the same but the lift and drag forces are increased at low speed.) This makes KSP planes much heavier than the real-life craft they resemble, but perform very roughly the same. So you might consider the length of the runway to be one of the choices for game-balance. If you are using the mod FAR, this increase in low-speed lift is absent, so it is harder to use that runway unless you use other mods to get realistic masses.

You are confusing me with @AHHans there, who by coincidence also was the first to note on the bug tracker that your former nemesis the targeting bug had been resolved. ( It occurs to me now that you might like to have the docking ports engage only when the rotation is square. I don't think you really need it unless you care exactly how the docking ports at midpoints are oriented. KSP has a mechanism to wait until the ports are rotated ('clocked') correctly before engaging the docking clamps, that we can enable using the patch in this post :

Steering with alt-J/alt-L trim helps a little. That is, if you go into settings and assign IJKL keys for wheels. Using my right hand on IJLK for wheels, and left hand on WASDQE for the reaction wheels, and SAS holding prograde, made rovers fun for me --- s,till difficult to keep upright, but in a fun way more than a frustrating way.

I've made smaller similar things, because it seemed like fun. Sir_frost has some self-assembling cages on kerbalx: https://kerbalx.com/sir_frost/craft The fine control mode on RCS, with [Caps Lock] on giving you the blue indicators, will approximately balance the thrust from RCS ports so that translation commands mostly translate, with just a little rotation; the approximation is better when the ports are well spaced out, as yours appear to be. The SAS targetting bug you might be thinking of 20513 is fixed in version 1.9.0 With those long beams, I think it would be more enjoyable to first rotate them square, then translate into position. The Navball Docking Alignment Indicator would help with the orientation if you like that mod.

Part-search works for me with mods, including your Tokamak parts. Maybe some other mod you have is getting involved in the parts cataloging system.

The 'title' is the displayed part name, so yes the intention was to include the displayed name in the search. (I found the more details in the thread linked below) Something is going wrong with that system and your installation of that mod with the inflatable parts. I noticed that the displayed name of the solar panel in your screenshot is is different to mine: this is the OX-STAT where your screen shows IX-STAT --- Edit: or maybe that is the version from Near_Future_Solar

Aha! That's it. I looks like there is a 'tags' entry in each .cfg file, and the search mechanism looks at each part for + a word in the part's 'title' that begins with what you typed, or + a word in the part's 'tags' that matches the beginning of what you typed, ignoring upper/lower case. The inflatable airlock has, in the English version of KSP, tags = berth capture connect couple dock fasten join moor shield socket "Inflato Workshop" must have something odd about the 'title' of its parts, or their entries in the translation dictionary if it uses translations.

Welcome to the forum, Dr. Monty. I happened to have screenshots from when I had a RoveMate directly under one of the Mun Arches. The RoveMate does show the anomaly 100% of the time, but you really have to be directly on top of the point where KSP marks the anomaly. The sensors have a field of view defined in terms of their viewing angle, which makes sense physically if you think of them as cameras. The RoveMate has a wide-angle (160°) view, but if it is only 1 meter above the point that marks the Mun arch, that view only covers a 11-meter diameter. Fortunately, KSPs markers for the anomalies are buried about 20 meters below ground (depending on terrain settings) so finding them on KerbNet from the RoveMate on a rover is at least feasible, if time-consuming. The images at right are all from a RoveMate under the Mun Arch, as I move by about 20 meters across the surface. The '?' is the point defined as the center of that anomaly. The elevation map covers 160° field of view projected down to the Mun's reference level, analogous to sea level, which is about 4000 meters below. So the same 160° field of view covers a tens of meters for finding the anomaly and 20 km for showing the elevation map. Some things in KSP are unpolished; some things are a lot of fun; opinions differ on which are which; this forum is a good way to find what other people find to be fun parts.

Sorry no one has suggestions for you. Players have reported the bouncing with wheels/landing-gear on hinges here, https://bugs.kerbalspaceprogram.com/issues/24614 but there are no suggestions for avoiding the problem. You might have already tried enabling 'Advanced Tweakables' to set 'Spring/Damping: override' and increase the 'Damping' in the right-click menu on the wheels. I don't know if that will help but it is a guess. If you've used 'Advanced Tweakables' and auto-struts, that can cause similar problems, more jittering than bouncing, so you might disable those if you have used them.

The keyboard commands (in default Windows keybindings) are F6 and F7 to switch forward and back through the sets.

It is not just you, @Kerbalwerks This is a new bug since version 1.9.0 and it is on the bug-tracker (link)

At one of the interviews, ShadowZone explained one use for a more general construction method, directly to the KSP2 team (link to time-stamp in the YouTube video). To build the desired craft from that video, in KSP1 we have to build from one docking connection along one of the legs and then back up the other, then bridge this second docking connection with a strut. In the image at right, the root part is at right to match the video, and I mis-aligned docking ports just to show which one is not directly connected. If the EAS-4 strut would have zero mass (KSPv1.2 already removed its drag) we would have the result we wanted. KSP1's simulation handles the resulting loop of physical constraints just fine. Placing and dragging an EAS-4 strut is the only way to indicate the second physical connection in KSP1. Does anyone know of a good example for a user interface, that allows users to connect subassemblies in more general ways? In KSP1 we place a part-or-subassembly onto a chosen part of the craft under assembly, with a single mouse click, which naturally leads to the single point of connection and tree structure. CAD software (used for designing automobiles and such) tends to use tree structures, plus various ways to add constraints that I think are too complicated for a game. The ReCoupler mod for KSP1 automatically joins additional nodes that are close enough, with some added highlighting and user interface tools to help see what is happening. Maybe those U.I. concepts can be streamlined into KSP2 without making it too complicated for new players. KSP2 would need some way to make clear when we are making two or more connections. It might be wise to store craft in a more general structure, directed acyclic graph instead of tree, so that multiple connections are truly equivalent. The nature of building craft by adding 'child' parts to a 'parent' or 'parents' gives the structure a natural acyclic order, so that if we offset a part it remains clear which parts are 'descendants' that should follow along with the offset.

You can push, placing your thrusters as close as you can to the carried mass. The advantage of pulling is that the asteroid tends to pull the joint at the grabber straight when you apply thrust, where the force of a pusher can bend bend the joint. Then the thrust stays in line with the massive load. If, on a pusher system, your asteroid load swings so that its center of mass goes to the side, so far that the gimbal on the pusher cannot aim the thrust at the center of mass, then you lose control. So if you want to push you should place the thruster close to the load, so the gimbal can more likely aim at the center of mass even after it wobbles a bit. For pullers, you would probably want to put the grabber in an 'interstage' fairing; attach the lower stages to an 'interstage node' of the fairing and then close the fairing shell around the grabber to extend down to the lower stage. For pullers, remember to make the thrusters clear the asteroid, because KSP coarsely simulates the force of the rocket exhaust if it hits the asteroid. (You can avoid this by moving the thrusters far away from the asteroid to fool KSP into failing to notice that the exhaust hits the asteroid.)

Some players use the Steam Workshop to post their craft to share with others. Only people who bought KSP through Steam can download those craft. The workaround here is to ask the poster to post the craft on KerbalX.com.