swjr-swis

You're gonna feel real silly when you load a craft in stock KSP, rightclick the probe core, and notice the 'KerbNet Access' button. Pro tip: it's also documented in the KSPedia (the icon of a white book with a blue rocket, under 'Communications network').

Seriously? Arsonide. I need some popcorn, so badly. You sound like you're so 'old' at KSP that you're not aware of the new 1.2 KerbNet features. These days, them young whippersnappers find anomalies by scanning the surface through KerbNet... the anomalies pop up as question marks. Altitude, scanner and probe cores govern the field of view, so one can even scan the entire broadside of a planet with the right choices.

Actually, at that distance, orbital velocity is still a screaming 1.5km/s, which means the fly-through happens at a 3000m/s speed difference. At that speed, good luck getting your video recording to catch even a single frame of the fly-through that can serve as clear proof. The only place where you can get single digit orbital speeds is close to the edge of Gilly SoI. As far out as the game will cheat, 111862m, it's 8.1m/s, which still means racing at each other at a double digit 16.2m/s, and a collision at that speed means getting deorbited or launched into an escape trajectory for the smaller craft. Pol and Minmus are only somewhat worse at 26-28m/s, everything else is three and four digits. Outer Kerbin orbits are 400-ish m/s. A mere fraction of a degree in deviation of inclination will still show as 0.0, but at those distances will put you off course tens of km.

I play stock, but I wholeheartedly support the request to enable us to change the autostrut setting on landing gear, legs and wheels. A fixed setting to 'heaviest part' becomes an issue in stock too, when docking two complex craft together and both have an identical 'heaviest part'. Knowing how it works one can game the system a bit, but in particular when docking things together, having the system try to be 'smart' will regularly be counterproductive. Let us decide, please.

RIC, any update on this status?

Agreed, I would very much like to be the one to decide when I can switch to another craft, thank you very much. It does seem like Unity could not be the restriction in this particular case. Whatever the technical reason for the 'cannot switch' thing, I think that many cases where this becomes a problem could be prevented by giving us a toggle to select whether we want 'switch to' to work for debris without control points yes/no. Default should be no, in which case the 'switch to next/previous' hot keys should only switch between craft that have kerbals, command pods/seats, and/or probe cores. In those few use cases when one needs/wants to be able to switch to uncontrollable debris, turn the toggle on. I have found it handy at times to be able to switch my camera to a piece of debris that had no control point whatsoever, but after having experienced a few times how switching to a completely useless piece of debris -and then not being allowed to switch back anymore- made me lose an entire ship, I would really prefer this to be something I only enable in those very few circumstances. Especially since we get absolutely no way of controlling/predicting what exactly the game will select next when we hit the 'switch to next/previous craft' hotkeys.

I was merely making an aesthetics suggestion with this: it visually smoothes the transition between the two engines, both in shape and texture. It's about the smoothest fit I've found. But you are correct about the drag penalty. For a craft design that easily breaks Mach 1 at sea level it'll hardly make a difference (top speed affected by perhaps 1-3%), but if it is struggling to break Mach 1, every bit of drag can make the difference. So one should weigh aesthetics against performance. Relevant tidbit: in 1.2.1, shock cones are again the least draggy nose and tail cones, by a noticeable margin. Very worth swapping a midge of fuel for the extra weight compared to other cones (and it also allows more compact stack designs).

I do want the 0.625m mini-nukes, if only for superefficient 0.625m probes and size0 spaceplanes. Yes please. But it is possible to use 1 RAPIER and 1 Nerv in a completely balanced way with all the thrust through the CoM: node-attach the RAPIER on the bottom node of the Nerv, then offset the RAPIER 5.5 clicks (or 11 in fine mode) into the Nerv. The exhaust of both engines will work perfectly without overheating either one. With a shock cone on the RAPIER end, rotated to face front and offset upward, it even forms a nice smooth transition between the Nerv chamber and the RAPIER front edge. Or placed behind a pre-cooler, the Nerv can be offset fully into the cooler to neatly align the RAPIER to it.

Protip: don't run KSP from the default Steam directory. Instead, copy the whole directory somewhere else and run it from there. KSP doesn't require Steam to be running, and it'll saveguard your game from forced patches/updates that may screw up your carefully modded install. It also allows you to keep an older version alongside the latest version pushed by Steam.

Confirmed, I had one appear in low Munar orbit in 1.2.0. I don't know if it's meant to happen or not. Was this in any release notes?

Well, if they do this, I hope they do it right. The two larger landing gear already turn off the light automatically when retracting, but then they do not automatically turn on the light again when extending. What happens then is that the landing gear light loses sync with the Light button/action and any lights that are toggled by it. So, if they are going to turn off lights when retracting, please also turn them back on when extending. Otherwise please stop adding half-implemented 'smart' automatic features.

This issue has been identified and reported several times, all requesting a way to stop the automatic switching: http://bugs.kerbalspaceprogram.com/issues/3980: Option to disable automatic switching of reference frame? http://bugs.kerbalspaceprogram.com/issues/5283: Reset (at least some) autopilots to basic SAS when navball switches modes http://bugs.kerbalspaceprogram.com/issues/6570: Navball should switch NOT switch to Target mode in proximity of a target if the target is landed or if SAS is in pro/retrograde tracking mode I particularly enjoyed the response on the first report I found, from 2 years ago: "A very good and well described suggestion. It has been forwarded for attention." Ah well... they'll get to it at some point. Right?

I'm a bit disappointed that he goes to the trouble of formulating a model for gravity that doesn't require dark matter, specifically with the intent of removing the need for it, which got me all excited... but then it still requires dark energy. It's all a lot of math wizardry to me, so 'disappointed' is very relative in this context; but still, I keep hoping someone will come up with a model that does not require any of the magicks to make the numbers work out.

Can the above explain why in some places the seams leave a gap big enough to move an entire craft or rover into the core of the planet/moon one is on? I've already found at least one such location, and reported it (report #13190).

I don't remember encountering those seams in 1.1.x, which was when Unity 5 was introduced, so I don't think we can chalk this one up to Unity. Something else changed from 1.1.x to 1.2.x for those seams to appear.

Witch! Witch! Burrnnnn him!

This challenge from a while back may be relevant: From page #2 on you will find entries using a jet engine as booster, quickly bringing the weight down of the launchers.

Sorry, that's what you get when you pitch ideas in this forum: people will go 'ooo but then I could also...!' and all bets are off where it will end.

Good to know you already have an eye on it, but sounds like a lot of code complication to fix a rather minor issue, in my view. My vote is for a low prio, below the link to the full album and the title/description fetching.

Hmm I don't know, in a universe with enough tourists and enough funds - and KSP has an infinite supply of both, the option to drive around cheap rovers on a lunar surface or fly a parasail on Laythe might entice more tourists to part with more of their funds than if all they can do is just experience micro-gravity or grab a rock. The additional funds could then further advance the space program, maybe even make it possible to combine the trip with a scientific mission (performed by the scientists). That would require a separate logic for tourists to control a 'simple' vehicle while not being able to control a spacecraft, so it sounds like over-complication. Still, now that I have thought about it, I think I'm going to examine packing tiny probe-controlled rovers for extraplanetary tourist landing contracts. If they pay me enough to bother, that is.

Wayneo... I don't have a problem with my rovers (*). You are the one posting here with a problem with your rovers. We can argue about how we feel that KSP should work, but that's an entirely different discussion. If you wish to know how to get a rover that works correctly in KSP, see my previous suggestions. I've spent a good number of hours now testing this for your benefit, not mine... my rovers already worked, everywhere, even when doubling as a lander. Btw: I started with KSP a long time and many versions ago. In my experience, building a rover with its controlling part pointing anywhere but forward has always shown problems with control; this is not new to 1.2.x. If you do a search in this very forum (try 'rover controls core', then go to the last page of results), you'll find people posting about this all the way back to 2013, and getting the same suggestions I am giving you here about the orientation of the probe core. If you won't take my word for it, at least check what others in the forum are and have been saying, from long before 1.2 came out. Anyway, no hard feelings if you consider my way 'wrong', but I hope you understand I can't keep wasting time on this. We can spend this time much better spent driving around Vall at high speeds - that was fun! (*: other than wheels still being a bit finicky about friction/traction/springs, but that is much better now than it was in 1.1.x, and not the topic of your thread.)

I tried both, and they work a treat! The album tag in particular helped to split some imgur albums I have that contains pics of more than one craft I uploaded. Very handy and very appreciated. Small bug report: when adding a new album tag (not sure if it also happens using the helper, haven't tried that one), initially the frame will be a very thin bar. This can be corrected by dragging or setting the frame to 'autoheight'. I usually let autoheight do it, but I noticed that the first time I select that, when the page is saved, the frame will shrink vertically by a bit. Select autoheight again, and save, and then the frame size stays put. Went through all my craft to update them to the new thingy, and add the autoscroll where applicable. Good stuff.

If you want a rover to also be controllable as a lander, you need to add a second probe core (or a docking port, or a lander can) oriented the way a lander needs. During landing, rightclick and 'control from here' on the 'up' core; during driving, do the same with the 'forward' core. Switching between differently oriented control parts is the only way the game offers to flip the orientation of controls, by design. No disrespect meant by snipping the rest of your text, but this here is the key of the issue. Those rovers, stock as they may be, are built wrong for rover use: the OKTO probe core is oriented up instead of forward relative to the wheels (and they may be suffering from the problem I suspect of rovers built in the VAB instead of the SPH). If the point you are trying to make is that the stock rovers are designed wrong, then we can stop right here because I agree. But don't use them as examples of a correctly designed rover; they are not. Hint: most stock craft in KSP have in fact, on purpose, been built with one or more design flaws. The idea behind this was said to be that the player will learn from correcting those mistakes. Personally, I think that only confuses new players, but I have no say on it.

That would be @ferram4, and I think he would prefer your feedback in the KJR release thread with some logs and a save file/craft file for him to reproduce the issue.

Well, I simply cannot reproduce the issue you describe with rovers built the way the game logic expects them; controls and steering work in all locations. Have you tried the rover I linked? Does it show the same issues at the poles and/or the equator, anywhere? If that one also shows the problems you describe, then your KSP install may not be entirely default/stock. Maybe one of the game files got corrupted somewhere, in which case a reinstall of KSP might be in order. It's not your savefile, because I tested with that (and my own rover) and that worked fine.