The_Rocketeer

Arthritis

Thanks for clearing that up JPLRepo. A way to launch two connected but separate vessels would also be a great help in the realm of stock hinges and bearings. There could be other applications and untapped potential here. (Perhaps that would stir up Azimech's enthusiasm a bit more too )

I'm confused as to how is different from launching two vessels connected by a docking port at the same time?

@Azimech I tried that as soon as I noticed this - no joy. The same problem is affecting my electric props, trim and symmetry groups both. Latest release versionwise. I do have a string of (mostly cosmetic) mods installed, but thought I'd ask in case I'd missed something Squad had done.

So having looks at the source, this looks a bit theoretical to me. There is no example of a real world rocket demonstrating this, just a patent citing functional specifications for a propellant grain that does not appear to exist yet.

Been tinkering with turboprops again, I'm having problems with variable prop pitch because the game now isn't treating the blades as a group on one slider but as individual sliders per tooltip menu. Anybody know how to get around this? On a related note, trim adjustments on the shaft seem to be forgotten as soon as I switch to the main craft again.

So, snail shapes go slow and cheetah shapes going fast? Who knew...! I'm not closed to the idea of new parts as a rule, engines included, but I do think that there are already redundancy issues with the ones we have in KSP. Unless the engine adds something new that makes it unique (think of the Dawn, Nerv or RAPIER), you're basically just playing top-trumps, inventing new cards just to be the best. None of the engines in KSP are exactly like their RL analogs, all are abstracted to a certain extent. Thus, I don't find the argument 'these exist in real life, so they should exist in KSP' very compelling. I'd prefer an example of an engine in RL that fills a niche that no engine in KSP currently does. A great example would be a water pump-jet/impeller engine (jetski propulsion) - nothing like this exists in the game yet. I could get behind a suggestion like that, because it's not just a tweak but an entirely new direction that opens up many more possibilities.

Can we go back to the 'if it's a mod it will be slower than if it's stock' discussion? I'll admit I don't really know the difference between how KSP operates the core game to how it operates mods, but I'm struggling to see why this would be noticable, if it's even true at all.

@AlamoVampire I am entirely serious, but don't let that upset you. Re-entry effects are coded by Squad, and also disabled by Squad. I suspect there is a reason for this that goes beyond the belief that Squad are simply too lazy or too mean to do anything about it. Your assertion that this is "something that squad really should turn on already" is unfounded. The mentality of "well a mod does it so what's the deal" might be a lazy argument, but that doesn't mean it's a bad one. The Mod has it fixed, therefore Squad can focus their time on something more important, like testing and bugfixing the console port, or more inspired, like the upcoming Making History expansion, or more anticipated, like fully supported multiplayer or a higher-res skybox. Players don't need a mod to turn on a bit of code, but if they want it the mod it exists, and if they don't want it or don't care... well. Whether the feature is enabled by a mod or by the stock game, it'll still use resources and files that otherwise would not be used. Having few mods in general might correlate to better performance, but that doesn't mean that making a mod stock means it will necessarily run better. I can't really argue with your point about (console) players who can't use mods, but frankly they have bigger problems that they would be better off Squad devoting time to at the moment. For what it's worth, I think this is a great mod, but I don't see any reason why it need be anything more.

(skipped 1 and 2 cos yeh, I know) 3. So you want Squad to change the game to fix a problem you already fixed for yourself even tho it may have undesirable effects for an unknown number of others, even tho those others might prefer otherwise. 4. You literally already did this. The mod made changes you could have made yourself by editing a file or two. [Edit: this mod appears to be cleverer than was previously implied] What you're asking for is a button in an options menu that you'll use once and forget about. Same thing.

Then why would you want it to be stock instead of mod dependent? On, it would appear, is not on.

Turning off launch plume smoke helps with slowdown during launch, period. Whether that's because something else is eating up all the system resources is moot, because there's nothing we can do about that. What we can do is build rockets with fewer, bigger engines, which reduces the amount of smoke. During re-entry, presumably any part that gets hot enough will generate re-entry plasma smoke. This is a significant difference between a launch plume and this feature. If every part during launch produced a smoke plume, you might find the slowdown affecting your game too.

Because answering questions from the fans would be a full time job for a much larger team, and would have a negligible effect (if any) on their key directive, which is to produce, test, release and support the game. Chatting about hypotheticals to make the fans feel loved would be a monumental waste of professional time. You're right to draw attention to things you'd like to see take a higher priority in development, but it really isn't justified to criticise the dev team for not talking about these things with you right now just because you want them to. I think this feature looks good, tho I'm more impressed by the distance shots (red streaks) than the close-ups (little puffs of pale gold). I'm also concerned about tanking performance on large or complex ships. Not every descent is just a pod on a chute. SSTOs, surface and atmospheric vehicles, bases - these are a bit more involved than that.

Banoffee.

Actually I heard there's a KerbalCon every year, held on the Moon. I know its a bit of a hassle to get there, but c'mon guys. A) you are ALL rocket scientists, and B) you don't even need to go interplanetary and C) your smartphones have more computing power than Apollo. Get to it!

I've seen the effect after surface impacts - Mk3 parts do it very well as they have excellent impact resistance, so the parts don't pop. G-force, like impact force, is still force - you just exceeded the structural limitations of the joints. Personally I think this is awesome. I'd like to see a lot more distortion of parts and joints, and less total-destruction of parts. Makes surviving a crash landing and attempting a recovery far more interesting.

Perhaps it would if Mars was 90% liquid water ocean... like Laythe. [Insert withering water-related pun].

Last time I checked, space included oceans, and space exploration included the search for available water, and the search for life sustained by available water. Your explanation does not wash.

I'm not sure how you define the scope of a vehicle creator/sandbox interplanetary exploration game without allowing that it's totally up to the player what vehicle they want to create and which parts of those planets they want to explore. Boat parts are long overdue in my opinion and well inside the scope. Given the lengths Squad went to to overhaul buoyancy and submersible depth issues (used to despawn at -600m), I don't think there's a lot of evidence they agree with you.

+1 Rover Proving Ground +1 Dock - stock seaplanes and submarines are definitely viable these days. I also support the wind-tunnel idea, but I'd take it a step further and make it a 'local conditions simulator'. I envision a facility that allows you to load up a spherical-body (think 1990s-era visuals) of the same size and with the same atmosphere and gravity as any body you choose, either in an orbital re-entry scenario, or as a surface launch. Why not HyperEdit? Too cheaty, breaks immersion, can get Kerbs killed, can be saved. It isn't a simulation if it uses virtual magic to make persistent changes to the game.

For solar, the visual representation of darkness-time is less useful that a read-out of how long it will last per orbit. That sort of information is critical for minimising cost for EC storage and charging parts, or for critical power depletion issues on other crafts traversing the shadow.

This could have been suggested before but IDK. In the manner that it indicates closest approach and ascending/descending nodes, I suggest the orbital trajectory line in Map View should also indicate where and when a vessel will move into the solar or communications shadow of another body, or at least of the body that it is orbiting. To keep the path from getting to cluttered, I propose the orbital line should change to a darker hue to indicate a blackout zone with a detailed tooltip of duration and source on mouseover. This would really help manage unforeseen upcoming power or communication issues and give the player a little in-mission time to plan around them.

Well, semantics, y'know? Who'd have thought humping something would be called twerking in 2017? But it's ok, I will accept your correction. My attempts to style it out have clearly failed. I'll go back to my hole.

*looks at @Tex_NL extremely skeptically* What, you're omniscient now? ()

*looks at @Tex_NL very skeptically* I'm sure it used to be Hoffman...