Murph

It doesn't eliminate it. It's still entirely possible to overload KSP with too many mods and push it into memory crash territory with ATM installed. ATM just helps a little with the problem. Nothing can fully fix or eliminate that problem until KSP goes 64-bit (which Unity 5 should hopefully deliver). I use half res myself, as I find the quality sufficient and prefer the performance enhancement from half res (it's a quarter of the texture data). As far as I'm aware, but I could be wrong as I don't do it, the stock game runs fine on a Mac with full res textures, it's only when you overload it via mods that you hit a problem.

From what I read, they discovered a bug in the heat implementation. The fix in 1.0.2 changed it to what it was always intended to be in 1.0. The behaviour in 1.0 was actually a bug, not intended behaviour, even if you happened to like the effects of the bug. As I understand it, the heat in 1.0.2 is "working as intended", although is quite obviously open to future tuning. There was no "knee-jerk mucking", and you don't rush another hot fix out to change something that isn't an urgent bug. Heat in 1.0.2 might not be to everyone's taste, but it's not bugged. You're getting another hot fix anyway, it's coming, and they are taking their time over it, to get it right, as many vocal complainants demanded they do (although frankly I sincerely doubt that any of those demands actually had any bearing on the timescale). Comments like that just make you look quite foolish and lose all credibility with many people. That was entirely unnecessary.

The engine nodes will always be 1.25m in that example, and I imagine that it will work on a "weakest link" principle, so the basic suggestion would not improve overall strength there (unless we get auto-struts for fairings). It only saves 1 part, by effectively combining fairing base and decoupler (which may well be a good idea). That's not really enough to sell it on part count benefit. If it gave STRONG auto-struts, that benefit would increase, maybe to 9 or higher, then it's more of a valid point.

Well, you do have choices. You don't have to unlock the tech tree before leaving Kerbin SoI, that's just one option. Really though, unlocking the tech tree is only the start of the game. Others will view it differently, but I view tech tree completion as getting my space program fully established. Once established, I've got the full set of tools available for exploring greater distances properly. Subsequent science gains can be converted into funds and/or reputation, once the tree is complete and you bank a little extra science to unlock any extra nodes added later by mods (or possible future official expansions) or to spend in the admin building to enable a policy. After tech tree full unlock, the game is all about exploration, completing contracts, pure self-satisfaction of building up a complete collection of science reports, and playing around with different designs and types of craft; in whatever proportions you prefer. To me, that's the real main game, an open ended sandbox simulation, the tech tree is only the introduction and first phase. It's also the long end game, much like other games where you initially are focussed on levelling up, then enter the long end game at max level. It has parallels in the real world, with NASA (and others) effectively having to unlock their tech trees, but eventually reaching a point where they had mostly unlocked everything and were then able to use it for exploration. Sure, they are still inventing new stuff, but it's more like variations on existing themes and refinements of existing tech, rather than unlocking completely new tech. It would be difficult within KSP's current framework to simulate those variations and refinements to any great extent. Perhaps a future version of KSP might find a way to reasonably unlock enhancements to tech (e.g. performance upgrades to the same parts) after tech tree completion.

No, that would cause worse problems in the opposite direction, deleting craft that very much should not be deleted. The altitude threshold is set to a level that should pretty much guarantee capture, no matter where you're coming in from. If you're coming in from even just the Mun, 50km isn't remotely close to capture, and from solar orbit it's barely going to make a dent in your velocity. You can de-orbit things on rails, it's the "Terminate" button in the tracking station. Try to think of it as a "rapidly simulate aerocapture combined with burning up on re-entry" button in that situation. ;-)

Ahh, ok, as far as I know, it has nothing to do with when and where the traditional experiment results were loaded onto the craft. It's all about where the craft is when they are processed to generate data for the lab. You will lose the same SoI bonus if you leave Minimus before you have processed them into research data. Once processed into research data points, location no longer matters. Honestly, though, the bonus is nice, but not essential. Between Kerbin, Mun, and Minimus, there's more than enough science to unlock the entire tech tree before you get any from a lab. The same SoI bonus doesn't improve the rate of generated science (the amount per day), only the total long term science generated. Max reward from the lab is far from essential, and there's enough data from Mun & Minimus to keep a lab running for quite a long time without the bonus.

Apollo 11 had to delay landing and fly over the surface, as they initially were coming in to an unsuitable spot. "30 seconds" from CAPCOM in the transcript immediately before landing refers to their fuel state, and the time remaining to either find a spot and land, or abort and return to Earth without landing. Neil Armstrong explained shortly after landing was complete and essential tech admin work was done. http://apollo11.spacelog.org/04:06:55:16/#log-line-370516 The earlier "turn blue" comment from CAPCOM immediately after landing refers to the landing taking much longer than just a simple touch down at initial target. http://apollo11.spacelog.org/04:06:46:06/#log-line-369966 Apollo 11 was less than 30 seconds from mission abort and failure because it is tricky to find a good landing spot on the lunar surface.

Yeah, max return from the lab requires you to wait and load all the stuff before taking traditional results back to Kerbin for traditional style science points. You don't have to do that, however, you can collect the same experiments again in the future, and load them into the lab even if their traditional science value has dropped to 0. You just can't load the same (experiment+location) combo twice into the same lab. That said, go do something more interesting while it slowly processes data; please try to avoid just abusing the lab via an endless stream of warp->load->transmit->warp->load->transmit->etc. It might unlock the tree easily, but it's really missing out on a huge chunk of the game, might as well just edit yourself 100,000 science points into your persistent.sfs file, in my opinion. If you were not planning on such abuse, good for you, well done! I'm only about 90% certain, but I think the bonus is only for loading data in the same SoI that the original experiment came from. I.e. Minimum experiments will get a bonus at Minimus (and possibly Kerbin orbit, not sure), but not Mun or another planet. You really shouldn't need to take Minimus results to more exotic places, as the exotic places have more valuable experiment results so should fill up the lab rapidly without doing that.

The proposed pigs are too expensive. I want to strap them into an external command seat during re-entry, for a crispy bacon roll after landing. Probably need a radial attach sauce dispenser as well. Seriously though, while I like the idea of more types of science, more things to do in career, etc, I see a problem with this. It has to be capped, or people would just have an endless stream of flying pigs to max out the science tree. So, that's a whole load of implementation effort for possibly not so much use. Taking them to other SoIs, biomes, etc, I'm not sure if that really makes sense for a zero g animal study. Not saying it's a totally crazy idea and shouldn't be done, only that a lot of thought needs to go into how to do it in a way that isn't any of: 1) A 1 shot or 2 shot deal, then never used again 2) Pay 80k and get 40 science, repeat until tree unlocked 3) Completely fake and unrealistic to prevent abuse 4) Completely fake and unrealistic to provide an ongoing purpose

Hmm, I'm still quite sceptical, and it's still feeling like a solution desperately seeking a problem. Interstage: fairings can do this (poss with a bug if you don't jettison the fairing, not sure if they fixed that yet) Smaller decouplers: you can already do this, they can be readily used today instead of decouplers for all purposes I can think of Drag: Not convinced, separator is more when you want to use both A & B afterwards, rather than discard A and keep B. This rather suggests it's in space, e.g. a single rocket delivering multiple probes, or something like that. Also, questionable drag saving on the tail, probably worse drag on the nose, and carrying weight around that could have been discarded. Aesthetics: possibly, but not feeling a compelling argument from that point. It's not that I'm strongly against it, it just doesn't have that "yeah, that would be cool" feeling, more a "why bother" feeling. If it's giving me that feeling, there's at least some chance it will give Squad that feeling.

I'm not sure I really see the point of it. Once you've detached the thing on one side of a separator, the separator no longer serves a useful purpose. Separating both sides at once gets rid of it and you can move on with something more interesting. What major advantage does it give to keep it around with nothing on one side? Right now the feeling this suggestion is giving me is that it is a solution desperately seeking a problem. Possibly some practical examples where it would make a significant worthwhile difference? - - - Updated - - - The CEO of StrutCo was seen handing an envelope stuffed full of cash to Squad, to ensure that business didn't suffer with the introduction of fairings. Their preferred stack joint supplier, Bend-o-Maticâ„¢ also voiced concern about the fairings seeming a bit too rigid and making their stack joints seem a bit crap.

When done properly, a gravity turn is the most fuel and aerodynamically efficient path to orbit. Some highly simplified things to think of: At all points of the ascent, your real priority is gaining horizontal velocity, not vertical. At sea level, horizontal is very limited before it becomes highly inefficient. At all altitudes, vertical is inefficient, as it has none of the velocity that you actually want, it's just using finite fuel to repeatedly punch gravity (which has infinite stamina). Once a velocity vector is established, it takes time and energy to change that vector efficiently, hence the slow progressive turn, which also should avoid putting the nose too far across the airflow (which can create a growing force pulling you away from the desired vector, as well as far more drag than going directly into the airflow). It's all about getting horizontal velocity as soon as possible, but without forward velocity becoming so high for the current altitude that you're fighting huge drag from it. As the practical horizontal limit rises (due to lowering air density), you want to be following that limit as closely as practicably possible. The curve of a real gravity turn is mostly vertical in the early portion of the flight, only slightly horizontal until you're up into much thinner air, but gives you much better than 0 horizontal when you reach the thinner air, with overall velocity vector much closer to the horizontal that you really want/need it to be. Alternatively, think of a playing field. To go from corner to diagonally opposite corner, you can walk along the edges, but it's quicker and uses less energy to walk diagonally across it. It's also quicker and uses less energy if you cut across the intermediate corner in a long smooth curve (which is closer to a gravity turn).

It can certainly be a mistake to add a feature, if that feature comes at a high cost to other more useful or essential features, such as a heavy performance hit for the active flight. It would be a very naive implementation that performed full physics simulation of every active flight on every connected client in multiplayer, as that would be horrifically unscaleable. A clever implementation can have each client perform only the physics needed for that client's own active flight(s) and share the computational load for a far greater scaleability. Remote clients can easily cover any data update gaps via the normal on-rails processing, or an enhanced version of on-rails (but still overall simplified) process, until they get their next full update. Glitchy problems like you describe are no surprise when something complex like MP is forcibly retrofitted on top of a framework that was never designed to cope with MP issues, without any proper ability to modify the internals of the original framework. Those sort of problems should be far easier to reliably deal with when it is Squad doing the work, with the ability to provide proper support throughout the framework. For example, someone else's active ship would never get deleted as debris because it would have a flag set marking it as an active player ship, which would short-circuit the normal debris handler. Simple things become complex, hacky, and unreliable when you can't get any real support from the underlying core (when the core doesn't already provide the necessary methods/properties/attributes/interfaces/etc, or behaves in a conflicting manner). Exactly, it's quite feasible to do a "more than good enough" computationally simple calculation (doesn't rule out complex maths, as long as it's overall quick for a CPU). That doesn't have to be done once per physics frame (many frames per second), and should give basically 99% the same result as a full simulation for most reasonable cases (if your craft/debris is completely bizarre, live with less accurate results). That scales extremely well; full simulation doesn't scale at all well. For stages and debris, it really doesn't matter if it lands in the precisely correct spot, or if an object with highly marginal survival chance falls on the wrong side of the cut (fix the object, if it's highly marginal it wouldn't survive every time under full sim). Auto-recovery of survivable landing/splash, sure, no argument against that (only that I don't personally feel it's a high priority need, but it is still a worthwhile feature). Auto-delete for the rest, yup. If we're to get better stage/debris handling, I want to see the simple yes/no (as above) for each compound object as a whole, then auto-recovery or auto-delete based on the outcome of that simple calculation. I'd even allow a 3rd case of (optionally?) leave in place if it has an active command part (probe core, or manned pod). False positives and negatives are just fine with me, for something like this, as long as they are edge cases, and the vast majority get a reasonably correct outcome.

There is no exact answer to that question. No two flights will use the same amount of memory, if it's memory usage that you're concerned about. Total number of parts out there in the universe is likely to have as much of an impact, if not a greater impact than the number of flights. If you have too many mods, it could be as low as 1 complex flight being enough to prevent you doing anything else. The answer also depends on which OS you're using, Windows reportedly seems to use most (3GB+) of its (less than 4GB) before it gets going. On OS X, a fresh install of KSP uses less than 2GB of the 4GB max. On 64 bit Linux, the max is much higher, more limited by loss of performance if you get close to or exceed your system's RAM capacity.

Full simulation really isn't necessary or beneficial to the game. It's just not needed, and I believe would be something only 1% of users would really appreciate. The other 99% would suffer from unnecessary complexity, and considerable development time diverted from far more useful things. A simplified quick yes/no calculation could be of interest to many, there's merit to adding that. As far as I'm aware, the physics engine only supports a single bubble for full physics, so it would be major development effort to deliver that 1% solution, therefore a mistake to put effort into it. To me, you're arguing for implementation of a "worst for most" solution, when it should be far simpler to implement an "adequate for most, substandard for a tiny minority" solution. I don't care if it is never implemented at all, but I can see how some might like an improved mechanic, and I strongly believe that the simple solution would satisfy the vast majority of them. Full physics simulation is extremely computationally expensive, if it's even possible to get the engine to run more than 1 simulation at the same time. Multiply the physics load by the number of dropped stages, random junk on suborbital reentry, etc, and it's entirely possible to turn the game into a slideshow on even the most powerful systems. Evaluating the object for total parachute area vs. mass is computationally extremely cheap, and only has to be done once per object, not something far more complex many times per second for full simulation.

There's really no scope for error, KSP uses tonnes, not imperial tons. 1 tonne == 1000kg. It's not a conversion, just standard mega/kilo/milli/micro magnitude scaling. Tonnes are the correct natural metric unit to use, as you're dealing with craft roughly ranging from 1t to 500t (yeah, there will be outliers beyond that range). Individual parts range roughly from 0.005t to about 50t. You can call them megagrams, if you prefer. ;-)

Yeah, I can confirm the engine issues is WWII era planes. I've flown real de Havilland Chipmunk T10s which use the old Gipsy Major engine dating back to the pre-war Tiger Moth. It's basically a poor man's Spitfire, certainly the same tech level as the Spitfire and has been the official pre-Spitfire trainer from just after the war until the present day; it's just smaller and the most it's armed with is a recon/spy camera (used as spy planes over Cold War Berlin). It can't handle negative g to any great extent, the carbs just send the fuel back over the cockpit canopy instead of into the engine, stalling the engine if you let it (but it will windmill start again as soon as it gets fuel). Positive g, no problem at all. In that type of aircraft, the other reason for positive g only (inverted, or otherwise), is being able to see where you are going, with unlimited upward visibility and very little downward visibility. Sitting in the cockpit, negative g is indeed unpleasant; positive g a whole load of fun. The Chipmunk is rated for +6/-3.

If the mini-panel for the contract is not showing a green tick against Kerbin, and not showing one against "Launch Site" when you're on the pad, that's a bug. I strongly suspect it could be caused by one of your mods, but can't be sure of that, it just seems likely. I've had loads of contracts just like that, no problems with them at all. It has nothing to do with biomes, I know all the biome names around KSC, and that is not one of them. "Launch Site" is the main pad at KSC. For "landed at the pad" contracts, no flight is necessary, you just put together whatever you need in the VAB, launch it onto the pad, then do the test (typically hit staging, but could theoretically be "Run Test" on the part's menu). That isn't a biome name, it's just the name the contracts system uses. Can you try it without mods? (N.B. I don't know what impact that could have on your save file, so backup first.)

I stand by my previous statements. It is irrelevant what is possible in the game, only what is realistic. It is unrealistic to use the LF-only tanks with the LV-N, as the fuel density is far too high. That is the only necessary factor to make me consider it to be cheating to use them with it. It is a hack by the game, to avoid introducing another fuel type, and is quite clearly balance around using LF+O tanks with the O part empty. I don't need the devs to handcuff me in choices, I'm quite capable of recognising that it's very unrealistic to use the LF-only tanks with the LV-N, now that I have reviewed the evidence. We absolutely do not need more LF-only tank options, as they would push the LV-N towards being overpowered. It is just fine as-is, used with LF+O tanks. There is no problem to solve, it is not broken, nothing needs urgently fixed. Squad, please DO NOT give us any new LF-only tanks for the LV-N, they are not in any way needed.

Well, you're not being given any as you don't actually need them, and there isn't an equivalence in reality for them. You can cheat and use plane tanks to create an unrealistically small LV-N rocket, or you can use LF+O (with 0% O) for something getting closer to reality. They are not a perfect equivalence, most likely actually being too high density, but are closer to the truth. (For me, cheating in this type of game includes any time you do something which is known to have a fundamental conflict with reality. But, there's actually nothing wrong with cheating in this type of game, define your personal rules as you see fit. If realism is important, never use the current LF-only tanks with the LV-N.) Pure LF-only tanks are very much needed for the jets and RAPIER in air mode, and realistic for those purposes. They just shouldn't really be used for the LV-N.

The wings in KSP are all just flat surfaces, so are relying on deflection to generate life, not differential pressure due to greater length over the top of the wing (as in the classic aerofoil). That's a reasonable choice when it's mostly supersonic flight that's being modelled. With that type of wing, it's all about angle of attack, namely the angle of the wing relative to the prograde vector, so it makes no difference which way up you are, only the angle of the wings to the airflow. Inverted flight would only really be relevant with classic aerofoil shapes, and I'm not sure that KSP's aerodynamics would even simulate that. The end result should be the same for nose 10° below prograde with the plane normal side up, or 10° below (still down towards the ground) prograde with the plane inverted, assuming that the plane is basically symmetric vertically (simple tails and the cockpit bump shouldn't make a big difference whether they are on top or bottom). If it's significantly asymmetric, there might be some variation.

Yup, Squad, pay attention. Scott seems to be basically saying that there isn't any real problem with the LV-N, and we do not actually need any new tankage. Or, if you're going to change anything, introduce liquid hydrogen as a fuel type, with a whole new line of LH-only tanks that are much larger, and make the LV-N LH only (and correspondingly physically HUGE low density tanks, which I'd bet very few people would like). I agree with him. I was 99% sure there wasn't a real problem before, seeing that video has pushed me to 100% convinced that what we have today is actually quite ok, and there is no serious problem with either the LV-N, or using LF+O tanks with it. It is a perfectly reasonable approximation as-is. Well done, Squad, you got it right, and there's no real need for change! (Edit: although the thermal issues should probably still be seriously thought about, I'm only talking about LV-N and tanks there.)

The way I interpret Scott, and I agree with him, is that he's saying that you're actually getting a more than fair deal when you use a LF+O tank with no O in it, combined with the LV-N. Taking the LF to be Kerosene/RP-1, which makes sense for it being a common fuel for both rocket and jet engines, the fuel quantity when you use a LF+O tank with no O for the LV-N is better than if you had the correct LH tank for the LV-N. In reality, the LV-N can't actually run on KSP's LF it has to use LH. LH needs bigger tanks, and it's a more than fair equivalence when you emulate that with a LF+O tank with the O half empty. Ignore the fact the tanks are LF+O, and pretend that they magically become LH when configured as 100% LF + 0% O. If you do that, everything is fine, there is no real problem, and we don't even need more tank choice.

It might have nothing to do with it, but the single->double->single style of build could possibly be causing issues with the heat flux. Only 1 of the 2 singles will actually be connected to both doubles, the other will only be connected on one side. In real physics (ignoring for a moment that the real world doesn't have restrictions on connection types), there's only half the path for heat to be conducted there, but not sure if KSP physics cares about connection size for heat transfer.

In the long run, 85k is not a particularly expensive launch. Whether it is for you right now or not, only you can say. With reasonable rep, one good contract pays for that. For me, I'd just ignore the cost.