r_rolo1

Nixing the thrust of a rocket engine due to outside pressure should only happen if the exterior pressure is above the combustion chamber one while the engine is working ( think on it as the atmo pushing the exhaust into the combustion chamber again ) While that most likely would happen above certain pressures for some designs ( like in the 92-3 atm pressure of RL Venus ), there is no way that any rocket engine would be blocked by the 5 atm of pressure of low Eve atmo. Even the typical water rocket engine used in demos for small kids would most likely still have some thrust in Eve ... BTW the reason why the aerospike is mostly insensible to atmospheric pressure changes is exactly because it does not have a combustion chamber

Well, it is diferent. In 0.90 all the engines worked ( sort of ) in Eve and the aerospike was the one that suffered less from the pressure. Nowadays most engines nil themselves in low Eve atmo ( BTW that is unrealistic, but gameplay is gameplay :/ ) and the aerospike actually works better in Eve than in Kerbin

Some do. Others have their efficiency heavily reduced and there is one that actually performs better at pressures higher than Kerbin ( the aerospike ).

The worst thing is that the game already makes almost all the calculations needed for determining the dV of a ship, mostly as part of the manouver nodes mechanics ( especially the time for the burn ) and if you are diligent enough, you can pick the few numbers already displayed on screen and reverse engineer them to get atleast the current stage dV. But for some reason, giving that particular number to the player ( atleast without sending one kerbonault to Eve or Duna, that is what they were suggesting in the proposal the OP refers to ) would be evil

Well, I don't know yet about how monoprop really works on 1.0, but in 0.90 monoprop, electric charge and intake air worked the same: from sources to users, and not stopped by anything, including decouplers. Like I said before, I believe this is a bug. There were reasons why the decouplers were made to not allow fuel flow in the first place ( they weren't in the beginning ), both of RL roleplay ( You don't want fuel lines inside explosive separators, , right ? ) as to avoid the kind of situation the OP is describing ( upper stage fuel draining ). Unless they forgot why they done that in the first place ... :/

That is strange . It looks almost like they forgot the reason why they made decouplers to not allow fuel flow in the first place ... that or this is a bug.

Answering the OP questions... No this feature is not in game at the moment Yes, Maxmaps explained in one Squadcast before release that the feature they wanted to implement was not fleshed out enough for their taste for the 1.0 release, so it would be postponed for later.

In better words, the chute + MK1 capsule + 1,25 m ablative shield has the center of drag in front of the center of mass if you try to put it with the ablative shield in the right direction ( due to the confirmed bug about the ablative shield being massless ). That is a highly unstable proposition and the ship will flip backwards as soon as you get too far of the velocity vector. What the OP made was to put the center of drag further behind by putting the extra part in between the chute and the capsule, making it stable again ...

Well, I do not want to harp much, but, as someone that was already once in this kind of show, I can say that, for whatever issues KSP 1.0 has, the QA people is most likely not to blame. First , because how QA works and second, because the ultimate responsibility of any code falls in top of the developer team. It is not QA that codes or even that decides what is in game or not or what bugs are worth to lose time fixing ( or even if they are fixable at all ) ...

Yup, oxygen + hot metal is not a recipe for long lasting metal structures , like this friendly PSA of ol'days shows www.youtube.com/watch?v=unki1tMWHt8

Well, in fact ,with the new atmo model, if you have to give input to your rocket while it ascends, you're probably designing your rocket wrong since well designed rockets now will put themselves in orbit with fairly low pilot input compared with 0.90 ( In other words, we can actually let gravity turn the rockets now like in RL instead of forcing the rocket to turn by ourselves ) On topic: 1.0 is a good update and it is a fun ride. has it's bugs , surely, but TBH I know enough of programming to know that a bug free program is a mirage. Now in terms of polish and general UI handling ... well, the UI is still very messy and like others said, there is still a lot of necessary eye candy and little details to fix for the game to create the necessary suspension of disbelief. In other words, this update is a good update by itself, but it is short of what would be to be expected in a RC, even more of a actual release product. Atleast that is my own 0.02€ in this subject

In fact , in RL the nuke engines of the kind we presumably have in game would heat up when not thrusting, for that exact same reason ( and would probably need a minimum level of thrust to keep the temps from rising ). That would actually be a fun challenge in game: how to keep nuclear engines cool when not in use

Hum, ablative shields made out of cubic struts in a row in front of a ship ... That is a good one, and a tribute to the inventive minds of the KSP players

Well, I didn't said it didn't had it's uses niche. I just said it was the worst SRB by stats AFAIK

Well, I can agree with that on face value ( also , it beats with what Scott Manley said in one of his videos ), but let's face it: a) it does not mean that there is not a need for atleast one 0.625m SRB It is only like that because the first flight in the main devs mind, for #reasons, has to have a kerbal showing the bottom right of the screen, thus needing a 1,25m booster to put below the MK1 capsule. If there wasn't that need, a 0.625m (SRB or not ) rocket would be the natural candidate for first launch ... That said, in the constrictions the devs put themselves on, the RT-5 is not that bad ... in pushing the first capsule out. After that, it is probably the worst SRB by stats ( it is clearly worse than it's bigger brother atleast ) ...

Hum, for someone that is here before the devs, Jeb definitely does not post a lot And that rep level ...

TBH I still maintain my opinion that I stated even before the game came out: the difficulties that people are having with controlling their rockets is half badly designed rockets/ bad piloting and half SAS overcorrection issues. That said, while the SAS is not tuned up in a more sensible fashion, the best thing to is simply to follow the advice people are giving here: low TWR at take off, turn a little at low speeds and let gravity do most of the work. It works like magic

TBH I echo the poster that said that LV-N should cool down when providing thrust, since that most ( not all, though ) RL nuke engines proposals would use the propellant as the reactor cooler... That said, in general we should have radiator parts, period. It does not make sense to have heat mechanics for space ships without taking in account that, for all proposes , ships are thermally insulated while in space besides radiation exchanges, and thus , they cool down very slowly...

Well, basing myself in Roverdude comments in one of the KSP-TV pre-release streams, solar panels supposedly are good radiators. Still have to try it though ...

Thanks for the intel, panzer1b. Some of this stuff is downright bizarre, but the stack of cans giving more drag than a longer big can actually makes sense, due to the breaking of smooth airflow in the joints between tanks.

Well, this whole issue of the capsules turning around nose first already happened once in KSP history, and for the same reasons: for one reason or another the (real ) center of drag of the capsules gets in the front of the ( real ) center of mass ( in the first time it happened in KSP , it was because they had made the capsules on propose to be less draggy than the rest of the rocket parts, to stabilize launches. This time it was because a mandatory (sort of) adding a massless very draggy part below the capsules made this happen ). Anyone that dabbles with planes in this game ( or any other that has any kind of minimally realistic atmo ) knows that this is a very unstable proposition and will get your ship flipped as soon as you get too much out of prograde/retrograde alignment ... Now , if you have multi parts payloads, you can actually make that the center of drag goes to it's natural place by juggling parts around. But as we can't change the CoM of individual parts, this becomes quite a issue ...

Not me, but in counterpart, I killed Jeb in a test to the reentry dynamics of a lander can ( results: with some work you you can survive a reentry with the can ... but it helps to bring parachutes, since the varying Isp with atmo pressure makes power assisted landings harder to judge accurately )

That definitely does look like a bug, since the Mun can't give that much of a gravity assist :/

@Roverdude I read what you said and I'm not disagreeing with your decisions per se . I might be disagreeing with your assessment that the two things are so different as you paint them, though ( I do see information as a exactly as tangible resource as the fuel count in game context, so I could live exactly as well with a slow forming map as with leaving a ore mining drill slowly working to fill my tanks. Others would not, I reckon, but those are points of view differences ... ), and I am definitely disagreeing with your implicit premise that people will see those two things as different in the same way that you do

@Roverdude Well, you also see as the map information about resources as a tangible resource , and let's be honest, most people would both warp the ore generation and the scans if they both were not instant ... but that is the fault of the game lack of real support to using more than one ship at a time, that is something that you could obviously not do anything about at this time of the show. Anyway, TBH, while I do understand your design choices ( some people really dislike waiting for scans and stuff ), you have to admit that the same arguments will be stacked against ore collection: the same people that don't like to wait for scans will rip their hairs out waiting for ore ( simply because their stock of patience is shallow ), and the people that would be OK with the long time ore collection will be puzzled by the instant scanning of a planet , even when the scanning device could not even see one of the sides of the planet, due to its quasi-magical nature ( and the fact that the game treats the other geographical intel as national secrets that have to taken away from it by force makes the whole thing to look even more disjointed, but again, not your fault on the biomes subsystem ). I was just pointing out that , by using that solution that at your eyes it is a compromise one, you are opening yourself to flak from both sides