Eric S

It depends. If increasing the heat resistance of a part also increases the mass and cost of the part, then that would be a fair tradeoff, and not something you'd want to do to every part "just because." It would be a design decision, especially if it can be done to varying degrees. Yes, arbitrarily letting the player pick values would be bad without constraining them by difficulty, but we don't know that squad is doing that. In fact, we don't know anything at all beyond reentry heat being an adjustable thing and no discrete heat shields. Squad has been talking and thinking about reentry heat without dedicated heat shield parts for over two years. I'm not going to assume that I'll think that whatever conclusion they've come to in that time is a good one, but I'm not going to assume it's a bad one either. I'm sure in two years they've at least come up with more options (and pros/cons to those options) than you talk about here.

I didn't get the impression that they were actively looking into it, it sounded more like they had looked into it and ran into too many problems.

Sigh. Two things: It's not a lack of heatshields, it's a lack of heatshields as a discrete part. I suspect that there may be some significance to that wording. Second: You'd expect better rocket science out of this community. Nasa's dealing with reeentry velocities that are three times what we do, and reentry heat is proportional to the square of the velocity (among other factors), so that makes nine times the heat. Even if Squad left out heat shields all together, this would really only be an issue for Jool aerobraking or Eve reentry/aerobraking. Or of course, for stupidly dangerous maneuvers like coming in so steep that the upper atmosphere has no chance to slow you down. I've played DRE and landed on planets with atmospheres without a heatshield, and that was before the DRE "nerf" that reduced it to realistic heat levels. With DRE, heatshields tend to be either something you don't need and wonder why you brought it, or something you desperately need, depending on the specific nature of the maneuver in question, with very little middle ground. I haven't tested it lately, but back when DRE didn't have settings and was far more dangerous than reality, the difference between a Duna landing that didn't need a heatshield and one that failed despite the presence of a heatshield wasn't much, less than a 2km difference in periapsis. I can't speak for how necessary flaps and spoilers are, I've flown spaceplanes with FAR without needing them, but not a wide variety of them.

You should probably clarify this, the original post linked to said that they may be added, not that they were confirmed to be adding heat shields as standalone parts, and the 4/10 squadcast clearly stated that they have not added standalone heatshields. Probably a minor oversight, since you do include a statement from that same squadcast about the potential for fairings to function as heatshields.

Same here. I've been following the development for over two years, and the closest to this I remember is a statement that at some point the game would be done and they'd move on to something else, they didn't plan on adding new features forever.

They said no dedicated heatshield parts. It's not the first time they said that either. First time I remember it was over two years ago, so this wasn't a matter of not making the deadline. It looks like they have a vision for reentry that doesn't quite line up with your vision. Or maybe they plan on using something that's already in the (v1.0) game, like fairings. There's quite a lot of wiggle room in what has actually been said, and we don't have enough info to really evaluate this. As for complete, they said that the game would have everything that they originally envisioned would be in the game. They also said that development of the game would continue. Yeah, I expect some fan reviews to be upset by a non-final 1.0, but to be honest, anyone looking at the game from the outside probably wouldn't realize that there's some minor stuff missing. I'm I saying that 1.0 is going to be close to perfect? Nope, too soon to tell. I've always been sceptical of devs that say they're going to fix everything in a single patch, but at least it sounds like the game will be less buggy (especially memory leaks, which are a major issue with 0.90). The major functionality is going to be there. We won't know how well it hits the target until we get our hands on it.

I'm not quite in that particular crowd myself at this time. Without seeing how it's balanced, we don't know how big an issue it will be. As someone that always aerobrakes when an atmosphere is available and frequently plays with DRE, I know that LKO reentries are only half the story.

The more realistic justification would be that a reentry from LKO is about a third the velocity as one from LEO, so they're just not as necessary. Not sure if you were using DRE back when they adjusted it to be realistic, but everyone complained that DRE had forgotten the D part.

I'm of the opinion (unsupported by data) that the price is going to go up when 1.0 officially releases, so I wouldn't wait too long to buy it, even if it's not on sale. No, I have no idea how far it might go up, and I don't think it will go up so far that a sale won't bring it down to the current price.

Nothing, if for no other reason than the part rebalance will mean that my craft won't have the delta-v and TWR that I planned for the mission. Between aero changes, reentry heat, and part rebalance, I strongly suspect that any of my existing craft will either be incapable of performing their mission or overkill for said mission. Or even both, in a few cases.

I don't. The devs have stated that they're going to evaluate U5 after 1.0 gets out the door, and haven't contradicted that in any way. They've been repeating that 1.0 doesn't mean the end of new development and features. They may or may not prioritize U5 higher or lower than the features that they cut from 1.0, or they may stick them all into 1.1. They haven't said that they will definitely port to U5, but I suspect that that is because saying that before having the chance to evaluate the impact of U5. I strongly believe that the evaluation will come out in favor of U5 and that they'll do the port in 1.1 or 1.2.

Do you remember exactly what was said? I am actually interested in that. Then again, I've seen so many times that gaming communities turn offhand remarks by people not in the position to commit the development staff into "promises," including this one (this community, not this specific claim), that I tend to be rather skeptical. Which isn't to say that there haven't been companies or development teams that delivered product far short of their early claims for that matter. What I'm saying is that I've been following the discussion on a U5 port since before squad publicly commented on it, and while I do remember some very enthusiastic (and fairly unofficial) comments about it, I've never seen anything to indicate that they'd drop whatever they were doing when U5 became available.

174.53 m/s to be precise, according to the wiki, so more than a few m/s, but not so much that it drastically alters launch vehicles.

Basically, KSP doesn't give anything gravity unless it's got enough to have an SoI. Since Asteroids in game don't have SoIs, they have no gravity.

As Kaboom says, yes. basically, like the Oberth Effect, it doesn't need to be programmed into the simulation, it's just present from the level of physics simulation that's already present.

I'd put fixing memory leaks as more important than load on demand, especially if you'll be unloading the assets when they're no longer needed. Repeatedly loading the same asset when every load leaks memory could be worse than what we've got now. Personally, I'm interested in seeing the impact of the fixed memory leaks and possible switch to DDS textures before debating how beneficial/necessary load on demand and 64-bit memory addressing are. I won't deny that they'd be nice to have, but if the worst of the memory leaks are gone AND textures are only taking up 1/3 the memory they used to, then that's going to take a lot of the pressure off of this.

Sorry, not doing your work for you, you're gonna have to be a little more specific, otherwise I'll just assume that you've got your own interpretation of some offhand remark that I've already seen. I don't see any significant number of people saying it's virtually impossible to do the port. I see people saying it's not a trivial port, and seeing as KSP uses PhysX, and that's the one big area where U5 isn't backwards-compatible with U4, unlike the U3 to U4 transition, which all by itself took over a month (almost two, but the christmas holiday season fell in the middle of that), I'd say that's a reasonable expectation.

Could vs should. The numbers I've seen indicate a worst case speedup in the 10-20% range, and unless U5 lets Squad run multiple PhysX threads per craft, we'll probably see something close to that worst case for KSP when you're only dealing with a single craft. Docking two craft of similar complexity will be quite a bit nicer since we should be able to run each craft in a separate thread, coming close to doubling the FPS. Personally, I think people are getting overly wound up over the issue. 1.0 has gone to experimentals, so there's almost no chance of it getting ported to U5. The devs have stated that they'll be evaluating a switch to U5 soon after 1.0 gets out the door, so a U5-based 1.1 is quite possible (or possibly 1.0.X, though I suspect those versions, if they exist, will be strictly for bug fixes). At this point we're basically debating which version of KSP should be called 1.0 and questioning whether Squad's evaluation of U5 will be adequate. I'm not saying that U5 won't be an improvement over U4 for KSP, and I definitely look forward to seeing KSP moved over to U5. I am saying that I strongly doubt it will be the magic wand of FPS and 64-bit stability fixes that some people are assuming it will be.

That came out wrong, even though technically correct. I haven't crashed in 0.90 due to memory leaks. In fact, I can't remember crashing at all in 0.90. Because I haven't crashed, I haven't paid attention to memory usage. I am in no way denying that 0.90 suffers from memory leaks. I'm not too worried about the memory leak in the VAB->Launchpad scene change because that's one of the few memory leaks that they confirmed that they fixed already. Max said that they've probably fixed 8-12 memory leaks if I remember right, but wouldn't state what any of them were, but one of the devs mentioned that specific one in the dev notes.

Actually, skylines switched over to Unity 5 in late beta. In addition, there were already games using the 64bit client back when there were bugs that would have prevented KSP from running for more than a few minutes at a time. Different games use different feature sets, so unless the games are using the same feature sets, you really can't say that just because game X using engine Y is stable that game Z should be as well. The same goes for how easily the game can be ported from U4 to U5. KSP uses PhysX, which is one of the few parts of U5 that is not backwards compatible with U4. Source? I've seen comments that they're very excited about Unity 5, one tweet that said that Unity5 would be a high priority after it was released, but nothing stating absolutely first priority. Also, the release version of Unity 5 didn't land until Squad was well into the 1.0 development cycle. Switching directions at that point probably would have been bad.

For some definition of "we." A not-insignificant portion of the players would rather have more interesting stuff to do on the existing planets before we get more places to go the same way we go anywhere else but with different delta-v and TWR requirements but in no other way significantly different than what's already in game. Only if they bring in higher physics warp. Burn times with ion engines are already long enough, solar sails would be even worse. So a stock equivelent of KAS or KIS? I wouldn't mind that, but it's not what I'd consider a high priority for 1.0. Not something I'd object to, would definitely be nice if/when we get more stock planets or play with mods that adds more, even at max warp orbits at or around Eeloo-altitude take way too long. I seem to remember an announcement that the reentry heat already has this slider. On the other hand, this thread wasn't about asking for suggestions for 1.0, it was about asking specifically if we wanted more features that the devs already had in mind (though that wasn't explained very clearly) or fewer bugs/more polish. Since 1.0 is now in the experimentals stage, I'm surprised this thread hasn't been locked since the only way anything here would have any bearing on 1.0 would be if they found something so wrong that they had to take 1.0 out of the experimentals stage (has only happened with one previous version to the best of my knowledge).

From reading the online documentation, Unity 4 does have the ability to dynamically load and unload assets. I'll admit that there may be catches that I'm unaware of. On the other hand, KSP texture loading has memory leak issues as of 0.90, so dynamic loading/unloading of assets could actually make the situation worse as the memory could get leaked multiple times. Not in Unity 4. This should be possible in Unity 5, but as I understand it, much of the Unity 4 API isn't thread safe and in fact there are safeguards within Unity 4 to ensure that only the proper thread accesses the API. You might be able to bypass Unity's texture file loading, load from the file in a separate thread, then have the main thread load the texture from the memory that the other thread loaded it into, but I'm not sure you're really gaining anything there. EDIT: ugh, thought there was two similar threads, sorry for two similar posts.

I've heard (but not confirmed) that one of the memory leaks in KSP has to do with the fact that the memory it loads the on-disk textures into doesn't get released after conversion to the graphics card's (or is it Unity's?) preferred texture format. If that's one of the memory leaks that have been fixed, then this becomes a non-issue. I'm not sure if converting to DDS textures on disk will eliminate this or reduce it, and I'm not even sure that that change is going live with 1.0, but if it is, it will reduce the memory leak even if the memory leak itself isn't fixed. Why is that memory leak important? Because if you've got a memory leak, you're better off only doing it once, not repeatedly. A load-once and then keep resident method would get around this, but could still cause problems, say you do a grand tour in a single session, you'd then have all the HD planet textures in memory regardless of which one you're in orbit at the end of the tour. It's possible that the reason that KSP doesn't do dynamic loading/unloading is because of the memory leaks. It's also possible that they just haven't gotten around to it. And yes, it's also possible that they don't consider it important. I can understand the first two as long as there's progress being made, but I'd disagree with the third, though how strongly I'd disagree would depend on how much fixing 0.90s memory leaks and DDS conversion help vs how much the new 1.0 assets hurt. I haven't run into memory problems with 0.90 even modded, but I've heard that if you're running on an actual 32-bit version of windows your margin for leakage is smaller so even stock crashes after a few scene changes or a few hours. I'd like to see KSP reach the point that you could heavily mod it even on 32-bit windows, but I don't see that as a critical priority for 1.0. Being able to run stock or even lightly modded KSP for hours on a 32-bit OS would be more critical for 1.0, and at this time, I don't think we have enough information to know how close to any of these goals 1.0 will be.

As some people have pointed out, the delta-v charts assume fairly optimal maneuvers. The best thing to do would be to measure your delta-v at each point along the trip and let us know which specific steps seem to be costing more delta-v than you calculated they should. Any of the steps could be done inefficiently. The most common place that you'll find suboptimal maneuvers is in landing. If you go from a normal orbit, kill most of your rotational velocity so that you start dropping, then occasionally thrust upward to keep your downward velocity from getting too high, you can easily double or triple the delta-v required to land, and when I was learning, sometimes I'd go even higher. This is a common way for people to land before they learn how to do it more efficiently. Some people do rather inefficient launches as well. I normally budget about 4750-4800 m/s for launchpad to LKO, but when I was learning, I'd occasionally have a bad launch that took closer to 6000 m/s delta-v. The transfer burn should be a single burn in LKO, and should be a hohmann transfer. Don't overshoot, you want the transfer orbit to have an apoapsis very close to the Mun's orbital altitude. If you use a higher apoapsis, then not only does it take more delta-v to transfer into that trajectory, but you have to kill more velocity when you reach the Mun. Efficient circularization at the Mun requires a fairly accurate intercept. The higher your Munar periapsis pre-circularization, the more delta-v it's going to take to circularize in a low orbit over the Mun. Also note that if you need to lower your periapsis right after crossing into the Mun's SoI, radial burns tend to be more efficient than prograde/retrograde burns in order to change your periapsis, since you're not close to your apoapsis or periapsis. Returning to Kerbin efficiently is basically burning so that you leave the Mun's SoI moving in the Mun's retrograde direction (compared to the Mun, you'll still be moving in the same direction as the Mun, just not as fast) so that you're in an orbit with an apoapsis near the Mun and a Kerbin periapsis of about 20km. I've never managed to do that perfectly, but you want your munar transfer burn to be as close to this as possible so that any correction burns are small. Lifting so that you're barely out of the Mun's SoI and then setting up the return trajectory may sound close enough, but it's not. TLDR: Use Kerbal Engineer Redux or MechJeb to measure your delta-v during the mission and compare that to what your plan says you should have, and that should narrow down what part of the mission is going over budget. Ugh, sorry.

One of each? OK, no RAM-Toaster install, but I usually run three or four installs running from stock all the way to "every mod I'm interested in." One vanilla, one UI/Information mods only (so KAC/KER and the like), one that adds DRE/FAR/TAC-LS/RT2-like stuff, and then the full boat. If I had to pick which one I play the most, either Stracciatela or Chocolate. I tend to play Stock right after a version release, Stracciatela after mods get updated, and Chocolate when I start to feel that I need more to do.