Eric S

I was always under the impression that the Rhino was an orbital engine not a lifting engine. With a vacuum ISP of 340, I think the devs agree. The lifting engines had their vacuum ISP nerfed, and the orbital engines had their atmospheric ISP nerfed.

Something to be aware of is that the redone aerodynamics in 1.0 will probably change the way aerocapture works, if only because there's less air resistance now. Unless those tutorials/examples where done in 1.0 (which has only been out for a few days), then they were done in the old aerodynamics system which provided a lot more drag.

A few more data points I've learned (all purely stock, without the "physicsless heatshield" fix: A capsule and parachute, no other parts yield inherently stable results and will orient itself retrograde. Because of the high heat tolerance of capsule parts, it will also survive if you use the right reentry angle and such (30km periapsis, tested from LKO and a bit higher, have not tested from Munar return yet). A capsule and heat shield, no other parts, yield similar results, though the impact will kill it. A capsule, parachute, and heat shield yeild a less stable result. In fact, as near as I can tell, it wants to fly backwards, and stops only because that would mean turning far enough that the parachute is no longer occluded, which pushes the parachute back towards the center, resulting in an entry just far enough off of retrograde to burn up the parachute.

I think the problem is that some people assume that career mode is the equivalent of the campaign(s) that come with most games. Some story that introduces you to the game and then you go on to play in the sandbox with everything you learned in the campaigns. Career isn't a campaign though, in fact it has more that you have to deal with than sandbox.

Actually, in this case, I think we're looking at at least two bugs. First, the heatshields shouldn't have their physics turned off (it's not just massless). As I understand it, the KSP devs added the physicsless thing because Unity has (had?) issues with connecting two parts where one part has more than ten times the mass of the smaller part. Since even the 1.25m heatshield has a 0.3t mass, I don't think it really falls into this category. Second, physicsless parts aren't really supposed to be massless under 1.0, they're supposed to add their mass and drag to the item that they're attached to. If the mass and air resistance of the physicsless parts were being properly added to what they're attached to, then adding a heatshield to a capsule should still work. It may be that this function works correctly for parts that should be physicsless, but it botches it when the mass is more than it should be. This would be the case if they're not shifting the CoM of the part that the physicsless part is attached to, which would be a reasonable simplification if the attached part were actually significantly less mass, but quirky if that's not true. Third, the map mode info popup doesn't include the mass of physicsless parts, but that's a display error only. And no, this is not intended as a bug report, just an explanation why I think what's going on here is a bit more complex than just a flag set wrong.

Depends on your definition. The devs have announced that they're working on 1.0.1, which as a patch update number means that they're not looking at adding features, just fixing a few things that need hotfixes and maybe a few tweaks. After that, I'm not sure if Squad would want to do a 1.1 that is just U5, that is just a regular update (features intended for 1.0 plus anything else they decide to fit in), or if they'd do both in one update. The last time we had a major Unity update, it was practically an update dedicated to just the Unity update but not entirely so, so I think the likelyhood of the third option would depend on just how many features the devs intended for 1.0 that got pushed back. The more that got pushed back, the less likely they are to combine both those features and U5 into a single update. This is all assuming that by seriously looking at Unity 5, you mean an actual intended-for-customers dev cycle. They've already done an in-house Unity 5 test. They're quite serious about Unity 5, there was just no way to work it into the 1.0 development cycle. Long story short, I don't know if they're going to give U5 or the missed 1.0 features priority. We're definitely getting a hotfix patch. I'd be surprised if they did much more than these two things before diving into U5. Edit: So what I'm saying is that if you don't count the hotfixes as an update, then I don't think we'll see "a few updates" before we see an update with U5, unless they hit a roadblock with U5, which is possible. The Beseige devs tried to get U5 working for Beseige and they weren't able to get it working smoothly enough yet from what I've heard, and Beseige is probably the closest game to KSP in the kinds of Unity features it uses.

Am I missing something, or does that just reset "up" as soon as you thrust in any direction?

You don't need to take all the tourists on the same craft. I've been doing my multi-tourist contracts one tourist per launch until I can advance far enough to do multiple in one launch.

Be aware that by suborbital, they mean apo out of the atmosphere, peri under the ground. So just a quick shot up and down that doesn't leave the atmosphere doesn't count.

All it means is that the max thrust scales with ISP, in addition to fuel consumption. Basically, rather than assuming the engine is limited by the total thrust it can create, it's limited by how fast it can pump fuel into the chamber. At max thrust, the fuel rate is the same, but you get less thrust due to lower ISP. This is how atmospheric pressure affects real rocket engines.

You never want to be over 5 degrees away from prograde, that's the biggest issue. If you're managing those checkpoints without having to push outside the five degree limit, I think you should be fine on the piloting side of things.

Fine, gameplay trumps realism. Then explain to us how this change is bad for gameplay. I've easily launched more SRBs than LFE engines in career under 1.0, and every time I try to get away from them, I wind up with something that underperforms compared to what I already had unless it's a lot more expensive. Using strictly expensive LFE engines just doesn't make sense in the lower atmosphere due to ISP affecting thrust rather than fuel flow.

The new atmosphere probably makes wobbling worse, but on top of that, Squad doubled to quadrupled the gimbal range of the lifting engines. I suspect that SAS needs to be retuned.

Every case of a rocket flipping in stock 1.0 aero that I've seen would be worse in FAR or NEAR. I've played all three, and I've tumbled rockets in all but 1.0 stock aero. It's either that they design something that's the aerodynamic equivalent of throwing a dart backwards, or they still think they can follow the old "10Km up then pitch 45 degrees" ascent profile without issues. Not saying that 1.0 doesn't have it's issues, but this one is just a matter of adapting. Wide pancakes don't work well in FAR, NEAR, or 1.0 stock.

Are you playing with mods? Mods that weren't updated to 1.0 (or where incorrectly updated to 1.0) can throw a lot of errors, which really slows things down.

I've had no problems with reentering the mk1 capsule. Mk16 parachute on top, two or three goo canisters, no heat shield, initial periapsis of about 30km, SAS turned off. Capsule starts to correctly orient itself at around 50km altitude, and by the time reentry heat starts is glued to the retrograde marker on the navball. I'll probably need a heat shield if I do a direct landing from a Mun/Minmus return since the capsule heat is hitting just over 2K and it has a 2.4K heat limit. This was with a fresh install, both unmodded and with KER installed.

The engines intended for vacuum operation took a large hit to their amtmospheric ISP, to the point that an LV-909's sea level ISP is now 85, which combined with the change to how ISP affects max thrust, means that a MK-1 capsule, A T400 fuel tank, and LV-909 can't lift off the launch pad anymore.

There's a per-save persistent variable, so you won't necessarily get the same distribution in two different saves even in the same install. I haven't heard if the variable is editable in the persistence file, but I assume so. Which isn't to say that you'll be able to just say "increase the ore the Mun's north pole." You'll probably have to know the seed number that would generate said deposit.

I'm of the same opinion. It's possible for this to be too good or too bad, or even for it to be balanced. I'd be up for this, but I don't think it needs to be in stock.

Even Unity 5 isn't going to help single craft with high part counts that much. In general, PhysX 3 is about 15-20% faster than PhysX2 due to optimizations, anything beyond that requires the ability to run multiple threads, which can't be done for a single craft. Where Unity 5 would shine is if you have multiple craft of approximately the same complexity within the physics bubble.

Just one cloud, but it's like a stalker, always just there when you're looking at it, only sneaking up on you when you're not looking. That way you only need one cloud to make it look like there's scttered clouds everywhere. Seriously, I'd like to see clouds implemented. I'm not big on making things look pretty, but I was rather surprised how much having clouds increased immersion for me when I tried a mod that added them.

Sort of. It still requires the time, you just don't have to leave the satellite focused. You still have to find something else to do while the scanning takes place, and that is the issue. The stock system has the same basic requirements (you need to get into a mostly-polar orbit, a flyby or equatorial orbit won't work) and doesn't have the "find something else to do" requirement. Sure, it glosses over avoiding resonances between the body's rotational period and the satellite's orbital period, making sure your satellite has enough power to continue functioning while in the planet's shadow, etc, but as a simplified mechanic it works fine. I can see where the simplification bothers people and they prefer to mod in something more realistic, but that's fine and the same can be said for every other simplification in the game. I'll probably still be installing ScanSat myself, in fact, but not because I like the way it scans better.

Actually, it is. The "one drill, one converter for all environments" system we've got in 1.0 isn't realistic, but as others have pointed out, NASA's already planning and proposing missions that test or even use ISRU for fuel-related purposes. It's a simplification, but much of this game is a simplification already.

The impression I got from... RoverDude, I think, is that fuel cells are for places that solar panels don't work (farther out in the solar system or on the night side of a moon/planet) prior to having RTGs.

I didn't see anything that made me think that drag and mass had any relationship anymore. I didn't see anything obviously wrong either, though there were definitely a few things that I saw that made me think "I need to test that when I get my hands on 1.0." It's possible that air flow occlusion is modeled in more than just the simple "part a stacked on part b" case, we saw limited evidence of that. It's about 3500 delta-v to orbit, from what the streamers are saying. Atmospheric ISP has been nerfed, SEVERELY in the case of engines intended to operate in orbit. The LV-909 has a sea level ISP of 85, if I remember correctly. It took Shimmy a little while to figure out that the KR-L2 engine is no longer viable as a first stage engine. With changing ISP affecting the thrust rather than maximum fuel consumption, the basic "mk-1 capsule, fuel tank, lv-909" lander couldn't even lift itself off the launch pad.