swjr-swis

With wheels the way they are in KSP at the moment, the only rule of thumb that is 100% guaranteed to be true is: if you drive a wheel over your thumb, it'll hurt. In a properly working game, the default settings should cover most of the logical use cases without problems. But wheels in KSP are still not working properly, since a Unity engine update a few versions ago broke them. Expect unpredictable behaviour, regardless of any claims by anyone of specific values being better. That said: Spring and damper - I don't bother changing these from the defaults unless the vehicle starts bouncing spontaneously at loading (which does happen with some regularity). Even then, there seems to be very little logical correlation between the settings and the behaviour. I just keep trying different settings until it stops bouncing. Friction - I usually apply low friction on front wheels and high friction on the back. This seems to minimize random skating and makes turning at speed a bit more predictable.

As others have mentioned, the problem is drag, or rather, because of the specific way you want your rocket to point/land, a lack of it. Once the fuel is expended, the engines at the bottom are by far the heaviest part of the rocket, and the rest of the rocket is, as rockets tend to be, rather sleek, so there's no drag to counter the engines from 'wanting' to get to the ground before the rest of the rocket. Airbrakes at the top would be one way to counter this, but as you've noticed they are rather sensitive to reentry heating. Two methods to protect airbrakes from too much heat: 1) pumping the airbrakes - when they start heating up too much, close them for a bit so they cool down, then reopen, etc. 2) limit their authority slider (advanced tweakables in the game settings) so they don't stick out too much outside the reentry wake. An easier alternative: place service bays between the mainsail engines and the bottom tanks, and add toggling them to the brakes action group. That way when you engage the brakes, the service bays open and provide a bunch of drag at the engine end, which should help keep the rocket pointing the way you want.

Did you look at @Tyko's suggestion (and my video, which amounts to the same thing)? The answer hasn't changed since this question was asked - it works without fail. Welcome to the forum btw.

Mutter... I still blame Star Trek for breeding an entire generation of project managers that believe replying "You have half that time." in a forceful tone will change the fabric of spacetime.

There should be an earlier part enabling Comms right from the start of the tech tree. A good name would be 'Can-U HMN'. It should be from the 'Found lying by the side of the road' manufacturer, and consist of two empty tin cans attached through the bottom by a piece of string. It would only have Direct comms capability, not be combinable, and have a very low bandwidth. To balance those disadvantages, it would require no EC for transmissions. It will need to be a compound part like the struts and fuel lines, but without a length limit so it can reach all the way from KSC Mission Control to the orbiting craft. We're still trying to figure out how to keep the string from wrapping itself around the planet. There should probably be a second slightly more advanced model that attaches three cans in series, which would obviously give it Relay capability. That way the other end could be given to a Mun rover.

You need to check the drag of the tank in front of the engine. Those numbers don't surprise me, the small variant should have the smallest amount of drag, but the unmatched bottom node of the tank should -if acting consistently- show more drag with the smallest unmatched variant than with the medium matched one.

Question about this one: will the drag cubes for this also be looked into, so it works a bit better for drag reduction? The current one is rather bad at being a nose cone. Looking good. Are the buttons in the 'rock sample examination area' a clickable IVA target? Do the arms move?? Can we.... <breathe> ok never mind me, just having a moment of potentials expanding asymptotically. The Terrier has been a main staple of many of my space programs, and its distinctive look will be missed, even despite its irritatingly incorrect default rotation screwing with mirror symmetry. The new variants are welcome (especially the bare one), detail level and textures I think are on point, and its new look is more consistent with the rest of the revamp, which is also good. Still... silently hoping a lil bit that someone considers letting the 'old' Terrier stick around in some way, if not as a variant, at least as a hidden part. I'll probably end up moving on eventually, but this might be one of the more difficult ones to let go of. Awesome, times two. Like a whole pile of hotdogs awesome. !! I can't imagine this having been an easy decision. I hope the choice works out for the development process and players both. Welcome. Please check your halfway normality at the door... we don't allow such nonsense here. And to your better half and the cats: I apologize in advance for all those stretches of time you're gonna have to miss him now that KSP is in his life - your sacrifice is appreciated.

Careful gents. Enthusiasm for good looking stuff is to be expected, and considering how good the teasers are looking even more so, but let's not burn out the people volunteering their unpaid time and resources at the very start of the effort. Considering how much work they are taking on, lets give them some breathing room. It'll be released when it's ready.

<whisper> I know. I'm one of them. </whisper>

It is, in fact, exactly right... for me. Which is my point. I have heaps of screen real estate, and not nearly enough options to use it effectively for all the information I want on it pretty much at all times. I get much more annoyed by constantly having to work through multiple menus, screens and button clicks to enable things that default back to disabled every single game load... than by having one more set of numbers visible at moments that I don't really need it yet. That doesn't sound right for you? That's fine too, and I'm all for you also getting the option to limit your information as much as you feel is 'enough'. Just don't decide for me what is 'too much' for me. Let us have the option to choose ourselves how much is 'enough'. In my case, the answer is in all probability always going to be - enable it all, all the time, thank you very much.

My opinions: There is no such thing as 'too much information'. If I don't need certain information I'll just not pay attention to it. There is no such thing as 'too many options'. If I don't need a particular option, I'll just ignore it. I want (the option) to have dV info and per-stage details always on. I can't think of any reason why I would want it locked or hidden, for any reason, in any game mode. In the implausible circumstance that I do explicitly want them disabled, I'll gladly open a menu and change a setting. If I had my way, things like 'Show aero/thermal data' would also be a toggle button in the PAW menus, and there would be game-wide toggles in the main settings to default them always on (along with things like 'Show authority toggles'). Tl;dr: Give us a way to set our own preferred defaults, please. Some of us want all options/info always on by default.

It's not special though, is it? Unexplained inconsistencies are kind of a hallmark of KSP, especially when it comes to mass/capacity and visible volume. Mk2 tanks hold the same amount of fuel as 1.25m tanks, Mk3 tanks barely hold more fuel than the half-volume 2.5m tanks, FL-T400 holds twice as much fuel as FL-T200 being only 1.5 times as long, Mk3 LFO short/Mk3 to 3.75m adapter/S3-3600 tank where to even start, fuel cell arrays visually depicted and textually described as six small cells but delivering 12x the power, a gigantic Atmospheric Fluid Spectro-Variometer weighing the same as tiny flimsy thermometers or aerial antennas. The Oscar-B would be special only if its capacity or mass had any kind of explainable connection with its volume.

My answer would be: take some time off, away from KSP. Play some other (types of) games. If KSP has you hooked, it'll tug the line at one point or another, and you'll come back to it naturally. If you're having to force yourself to play, it's time to take a break.

Did you mean to ask a question and forgot to add it? Are you posting a challenge and forgot to explain the objective? Are you asking for ideas for your career, or trying to tell people how to play KSP? In short: what is this message about?

Agreed... a set of different lengths would add a lot more in practical usability than just a single texture update. Would bring part count of tiny craft and payloads a bit more in proportion.

I should've phrased that differently. Kerbals spawn inside a cabin with their helmets off - at least all the stock cabins. What I was focusing on is that we have no way to change this status in the current stock game. Since they are adding a feature to the game in 1.6 to allow removing the helmet when outside, it would be logical to also allow us to do the reverse when inside... ie. put on the helmets. It's speculation though because the preview doesn't show an inside (IVA) interaction.

Yes, I assumed that's what you meant, since you referred to IVA and launch/descent. In retrospect, I guess their little teaser doesn't really say anything about IVA. Would be a bit disappointing if it turns out they can't remove their helmets inside a cabin. But we'll have to wait and see when 1.6 comes around.

You can't. Not yet anyway - the most recent KSP Loading preview shows (among other things) the possibility of removing helmets and neck rings, but this is a feature to be introduced in the upcoming version (1.6) of KSP. There's no such thing as an 'IVA helmet' btw. They either wear their EVA helmet, or nothing.

"You take your helmet off... After a few long seconds of gasping and haphazardly flailing about you manage to secure your helmet again. You erase the checkbox on your report for breathable atmosphere."

The only correct way to play KSP is pure stock. Implying any differently is a blasphemy of the highest order and a violation of the One Prime Directive "Thou Shalt Not Mod", which is punishable by violent eye-rolling and derisive laughter. Repent now, and we may suffice with mocking you until your sins have been atoned.

The launcher has been stillborn for quite a while now - it's still included in the game files, but stopped working several versions ago. Why they keep adding it to the game files is a mystery - it just continues to confuse people. Ignore the launcher, and start the game through the KSP_x64.exe file (or a shortcut pointing to it). What you're trying to do won't work anyway. KSP requires any save to be located inside the <KSP>/saves/<savename> folder to load it. There is also no command line parameter to insta-load into one specific save. At least not in stock.

Or create your own starting set with the debug menu, Kerbal/Create. You can pick their genders, professions, experience, personalities, make them badS or veterans (or both), and give them your own choice of name. You can even make them tourists. You can make a whole new set for every single game... or half-way an existing save. We have the technology, people.

IPS abandoned markup code for users and chose explicitly for WYSIWYG only. So that's what we get. There's still some legacy crap in there that parses some codes.. or it may not, since they don't care to keep it updated, and any update may break it or drop it altogether. https://invisioncommunity.com/forums/topic/417407-ips-40-the-current-state-of-bbcode-and-its-future-is-bbcode-officially-abandoned/?page=4

Some things have to be changed on the fly, and many settings (especially sliders) cannot be done in action groups. Hence the request for actual 5/7/9 editor symmetry still being valid. No less merit to your method of composite symmetries - if all you're after is the visual or mass/thrust balance effect.

Quick, change the thrust limiter or gimbal setting on all 9 engines of your balanced symmetry group before the burn... oh wait. Visual symmetry <> functional symmetry group.