Murph

Yes, not being able to rename and reclassify objects because the battery is flat is a frankly daft restriction. We should also be able to rename and reclassify from the tracking station.

Yes, that's not a bad summary. They provide less thrust when you need it most, and too much (which isn't really a problem in that phase) when you don't need it.

360s is not that great for the second half of the ascent, and the lack of power combined with lower max air speed makes them less efficient in the first half, than turbojets. I've built a cargo delivery plane which can do 70t+ to LKO without a problem, and it really needs much bigger and better than the stock plane parts, so that's B9 for me. Once B9 is in the picture, quad SABRE Ms are a much more appealing alternative to a large number of smaller, mediocre engines.

I wouldn't even consider them for that role, frankly. They are too small, underpowered, and too low impulse. There are much better alternatives.

A little over 15% less powerful than the turbojet, before factoring in needing more fuel.

Resource mining is not cancelled as a concept. Only the old "not fun" plan is scrapped, with the concept open to be revisited in the future. It's really too early to say what missions and contracts might include, but I'd guess satellite launches, probes to specific locations, and probably a random selection of science gathering type things. I'd imagine that a big part of it will be to engineer efficiently, to a budget.

I deal with that situation by manually copying the craft file from saves/<name>/Ships/SPH to saves/<name>/Ships/VAB, then editing the VAB copy to have "type = VAB" instead of "type = SPH". I then load it in the VAB, rotate it vertical, strap on whatever boosters and launch clamps I need, save, and I'm good to go. Do not edit a SPH design copied across to the VAB (other than slapping boosters and clamps onto it), as the VAB engineers eat SPH struts and symmetry as snacks when you do that. I suspect that the warranty is probably void with that procedure.

I'm aware that you were suggesting it for stock, I was just giving you a way to have the functionality today, instead of at some indeterminate time long into the future. Contrary to some rumours out there, using MechJeb doesn't give you cooties, and there's no pentagram-bound contract in a long dead and arcane language before you get to use it.

There is a clear cut answer, it's a combination of pressure differential (dominant in the classic aerofoil), and deflection/downwash. The balance between the two depends on the design choices and intended role of the aircraft, with sub/supersonic being one of the most significant design factors. Air crew and aerospace engineers understand it quite well.

It could well be a graphics driver bug. On a relatively recent Mac, the GPU drivers are quite likely to have been relatively new in 10.7. Upgrading to 10.8 (if you want mature stability), or 10.9 (if you don't mind the bleeding edge) should give you more mature graphics drivers. 10.7->10.8 isn't too painful a jump, on the whole, unless you've got a strong known reason to stay on 10.7.

It's actually quite correct that the classic aerofoil shape generates lift via differential pressure, just it's not the only way of designing a wing. Classic non-aerobatic, non-supersonic planes (e.g. big passenger & transport planes) make significant use of it to generate far more lift than mere deflection alone could generate. It's taught by the RAF, amongst other people, and I'm quite inclined to trust their opinion on the matter. Stunt planes and supersonic planes are very much a different case.

Well, then the short answer is that it can't be done cleanly, only by complicated hacks which could attract the attention of a Kraken.

It can be done in stock, but it's extremely hacky. It involves a pseudo-hinge or loop made of cubic struts, and a 2nd ship consisting of a probe core and the door, opening/closing with reaction wheel torque, and with docking ports to hold it in the closed position. The door-ship/module is trapped in cubic strut hinge loops at each end. There's a video of someone doing it on YouTube. While the hack is interesting, my opinion is that you're much better just doing it with mods. My recommendation would be the B9 pack, it has several different cargo bays to choose from.

MechJeb's warp helper can do all of that.

The part.cfg files are unchanged between 0.22 and 0.23 for all of the rover wheels. You might just be seeing data which wasn't so visible in the editor parts info before. I've not played around with rovers in 0.23 so far, so no comment on the actual behaviour of them, just an observation on the part configuration parameters, which is where any change like that should be visible.

You'll need something like TAC Fuel Balancer for that. If it's set to "Balance All", that will probably stop the CoM moving around horizontally.

It does come from the part.cfg, but the bandwidth isn't in there directly, it's calculated from 2 parameters which are in there. The behaviour is correct when transmitting for the parameter values, but the displayed bandwidth value uses an incorrect calculation to get the number it shows.

That's not time warp, it's physics warp, and should generally not be used during launches. If memory serves, there's a popup the first time you use it, warning that it can cause problems. Large ships, and any situation with large physics forces (thrust, drag, aerodynamic control, etc) are liable to have failures with it. Bottom line, expected behaviour, don't use physics warp when there's forces around, or with large ships.

Ahh well. Thanks for the response, and thinking about it, it's much appreciated. I guess I'm just stuck with camera gymnastics to hide lots of gear reinforcement struts.

Sure, they don't do a lot, but if you partially deploy early enough to get maximum benefit from them (and I'm not sure just how early that is, tbh, but earlier is better), they do give some extra braking. Sometimes all you need is just a little bit more, sometimes early partial deployment can provide just enough. Sometimes you need everything, max partial deployment, burning the engines at max just before full deployment, etc. Of course, if the design is so marginal that it needs everything to avoid failure, the real problem is the design itself, which can be fixed for the next mission.

I think you may be misinterpreting what is intended by "what not to suggest". I could be quite wrong on this, but I understand it to be a list of things which is BOTH stuff which has been ruled as never going to happen, AND stuff which is actually quite likely to happen (or be fixed) eventually. It makes sense to me for it to cover both functions for the purpose of keeping the noise down in the suggestions forum. There's very little value in repeatedly having threads suggesting stuff which is planned anyway, unless they open with significant detail on how something should be implemented, way beyond "we should have xxxx". Edit: To quote the opening of the WNTS sticky: "This is a list of features that are commonly suggested, already planned or denied.".

Since I seem to have opened a can of worms on the wish for super-heavy gear, I just want to clarify what my wish is. With the current HDG gear, there's a significant tendency for the gear to shimmy/wobble sideways, causing a loss of directional stability on takeoff roll, on huge and heavy planes. That's even with the gear strutted onto its surrounding parts, and plenty of parallel individual wheel units sharing a common wheel axis to spread the load. So, the wish is for either beefed up HDG or a super-heavy variant which solves or improves that sideways wobble/shimmy/instability. The cosmetic appearance doesn't matter all that much (not to say looking awesome is unimportant, it's just not the primary issue here), it's the practical function that I'm really looking for.

I'd imagine that they will still find plenty of new people to jump in and buy it once it hits 1.0. And yeah, I'm eligible for the lifetime free, but might pay anyway if they are still a cool company, doing cool stuff, the price is reasonable, etc. They are not scrapping stuff from the feature list, that I'm aware of, only scrapping specific plans that they no longer think look like fun. All of the general concepts are still on the possible feature list. The features were also not a clear promise of anything. They seem like a decent bunch of people, decent company, so I think they will honour concrete promises such as lifetime free for early folks. I fully expect they to look at DLC, expansions, etc, once the dust settles on KSP 1.0. I wasn't suggesting that the various post-release extra revenue streams were unavailable to them, just that you can't count all of the current supporters for those, necessarily.

Many of us (that purchased sufficiently long ago, before the end of Apr 2013, if memory serves) are on a promise of lifetime free dlc, expansions, everything contenty. If they feel happy with the current size of team, I think it's quite prudent for them to avoid any rash expansionism, as that can be a good way to kill a company if you get it wrong. Edit: Oh, and they already have the "Kerbalizer" for a small fee, I think.

That would be "kOS".