jwbrase

I find that I need about one RAPIER and one NERV for every 15 tons of full-load mass. Technically, neither the Whiplash nor the RAPIER matches the performance of a ramjet, because both can operate at zero airspeed. In any case, its high-speed, high-altitude performance in jet mode is better than that of the Whiplash, and an LF only RAPIER / NERV design that forgoes rocket mode on the RAPIER entirely actually works fairly well.

A common way of doing it is to have a certain region of the address space that can be remapped to different areas in memory, either by hardware bank switching (which was common on old 8 and 16 bit systems, where the technique was most prevalent), or by calls to the operating system that cause it to remap that region of the process's address space on modern systems with paged virtual memory (but it doesn't tend to be that common on modern systems because most programs tend to have lots more address space than they need). The specifics differ between operating systems, and between different hardware on the old 8/16 bit systems. Windows, IIRC, has system calls explicitly meant to provide such overlays. On Linux it would probably be done by switching out between different anonymous mappings to the same area of the address space using mmap().

As I understand it, it's not a matter of not being able to rotate the planet object itself around an arbitrary axis (ships, after all, can rotate arbitrarily), but a matter of the physics calculations in an object's SOI being simpler if the rotational axis is aligned with one of the coordinate axes, and Unity not being able to have differently rotated coordinate systems in different SOIs.

With proper landing gear placement and tail-mounted engines it is indeed possible to bash your engine, and tailstrikes are a very real thing IRL. But the solution to this is not to put your landing gear at the rear of the craft, but rather to figure out a safe rotation speed and rotate carefully and only after reaching that speed.

The use of mechanisms such as overlays is rare enough in consumer software on modern operating systems that you will rarely, if ever, these days encounter a program that uses more physical memory than it has address space available to it. And if your program is meant to be cross platform, like KSP, the "quite easily" part goes away: Pretty much every way I'm aware of to do overlays, etc. is system-specific.

What I'm proposing is that the player would launch a new heat shield, rendezvous the heat shield with the vessel with the heatshield needing replacement, EVA an engineer, float over to the headshield to be replaced, select "replace heatshield" in a right click menu, float over to the other heatshield, select "use as replacement" in a right click menu, and the game would then swap the two heat shields (or, for the sake of simplicity in programming, probably just swap their ablator amounts).

I sort of enjoyed the one time that I discovered "rescuing a Kerbal/Pod by enclosing them unsecured in a spaceplane cargo bay is not necessarily a great idea" the hard way. I didn't suffer an LOCV, but it was quite a close call with uncommanded maneuvers taking place as the pod banged back and forth in my cargo bay and shifted my COM every which way. Disabling physics completely in cargo bays would remove that bit of "fun".

To my understanding, flipping is a very real issue that real seaplanes have to deal with, and for a real life seaplane, 50 m/s is quite a high speed to be contacting the water at.

I thought of something along the lines of the part box idea while thinking this up. The reason I suggested the idea as I did is that it conserves mass (which a generic part box might well not). The 2.5m heat shield weighs about a ton, which is not insignificant, and an ablative heat shield like that would probably need to be replaced as a unit IRL, as opposed to changing shuttle tiles. My process would be imagined as the Kerbal laboriously replacing one part with another in an hours-long EVA. It would be implemented in game as the ablator from one heat shield being instantaneously moved to another (with the restriction that they must both be the same part, no using a 2.5m to replace a 1.25m or anything like that).

I have a set of entirely spacebound translunar/interplanetary shuttle vessels. They are, by design, entirely incapable of reentry or landing on Kerbin's surface, however, to save delta-V on return to Kerbin, I have outfitted them with heatshields to allow them to aerobrake into LKO. However, since ablator is a limited resource, I have had to implement the heatshields with docking ports so that they can be detached, discarded, and replaced when the ablator runs out. My first idea is this: Engineers could have a "Replace heatshield" ability, wherein you could launch a spaceplane with a heatshield on board to rendezvous with a vessel with a depleted heatshield. The engineer could then use his ability to swap the heatshields with each other (which would probably be implemented in game as just having ablator moved from one to the other). This would allow heatshields for non-landable vessels to be integrated into the vessel, rather than having to be docked to it. The motivation for my second idea is as follows: I have an obsolete translunar shuttle that uses parts from several levels down the tech tree from where I currently am and is inadequate to my current needs, delta-V wise. I plan to have it dock in a spaceplane cargo bay, at which point the spaceplane would ferry it back to the KSC. The problem is that launching such vessels tends to require that the back end of the spacecraft be propped up with struts in the spaceplane cargo bay, or else the docking joint bends under the weight of the spacecraft and the back end of the spacecraft clips through the belly of the spaceplane. Therefore, I propose that engineers be given an ability to place a limited number of struts between two docked vessels to support deorbit operations. My third idea is this: With current parts my shuttles have to have their engines and heatshields at opposite ends of the spacecraft. Game-mechanically this is fine, but it bugs me a bit, because I keep thinking of my poor Kerbals having to restow everything between an aerobrake and subsequent circularization burn, lest things secured against acceleration in one direction come loose during acceleration in the other direction. It would be really nice to have a heat shield part with a hole in it that can be covered for aerobraking and then uncovered to serve as an exhaust port for an engine.

[quote name='AeroGav']As for overheating , two things will help - lift and drag. The problem with drag is that it is your enemy on the way up, and airbrakes are made of chocolate, but lowering the landing gear can shorten the re-entry ordeal.[/quote] I tend to use the real-life Space Shuttle's solution to this: Rather than using airbrakes, I begin reentry in about a 45-degree nose-up attitude, and hold this until my ballistic impact point is just west of the KSC. At this point I adjust pitch according to whether I am heading long or short of this target point: pitch up if I'm long, pitch down if I'm short. I tend to hover around 30-35 degrees, up to 45 if I need to brake harder, down to about 20 if I need to extend.

[quote name='More Boosters']It doesn't look like a straight line but it doesn't bend much until low altitude either, but that should be expected. Maybe I can take a screenshot for you? [URL]http://imgur.com/gallery/bOysg[/URL][/QUOTE] Your screenshots show that you're coming in on the wrong side of Jool. Tylo orbits Jool at about 2 km/s, moving counterclockwise when viewed from the north (all bodies in the Kerbol system have parallel axes, so we can define a universal north for the whole system). Your encounter trajectory passes by Jool moving clockwise. This means you encounter Tylo going 2 * 2 km/s = 4 km/s faster relative to Tylo than you would if you passed by Jool on the opposite side (because you're meeting Tylo head-on instead of catching up from behind). Tylo's escape velocity at the surface is only about 3 km/s, so a 4 km/s difference in your encounter speed will make a *huge* difference in how much deflection Tylo can give you (as a given ratio of incoming velocity to escape velocity at periapsis altitude will give your flyby trajectory a unique deflection angle).

There has been a longstanding bug on Linux that if any joystick axis is off-center when the game is started (most commonly the throttle because everything else tends to be springloaded to center itself), that axis will be biased off-center and will not have its full range of motion until the game is restarted. The purpose of this thread is not to bring the bug to the devs' attention (I'm fairly certain it's already known), or to advocate that it be fixed more quickly, it is simply to suggest a possible workaround should a fix be technically unfeasible (assuming that the workaround isn't unfeasible for the same reasons as the fix) or lower priority than other bugfixes. My idea is basically to add a button on some options screen, or maybe a keybinding, that causes the game to reinitialize its joystick code. Assuming that the user has centered all axes, this would then cause the joystick to behave correctly without necessitating a full restart (the caveat being that if the reinitialization button were pressed with the joystick off-center, it would then cause the joystick to misbehave).

[quote name='fireblade274']They are necessary for space planes[/QUOTE] Not if you use an appropriately high AOA during reentry. None of my spaceplanes, ranging from 30 to 120 tons full-load, use airbrakes at all, and 1.0.5 didn't break them, though I think heating margins have gotten thinner in places during reentry (and very definitely have during launch).

By the time you reach the liquid phase in a gas giant's atmosphere, you've already reached deadly temperatures. Also, I believe gas giant interiors are also [URL="https://en.wikipedia.org/wiki/Supercritical_fluid"]supercritical[/URL] at depth. So forget having an ocean, just have atmospheric temperature get into the thousands and tens of thousands of Kelvin as you go down, so that all Jool entry vehicles disintegrate from overheating before reaching bug depth.

Actually I do most of my acceleration higher now: I used to go from my climb to altitude into a fairly flat acceleration run, now I spend a good portion of the acceleration run at 10 degrees pitch or so, and do a much less aggressive pitch-up in transitioning from the acceleration run to my climb to orbit.

However big a militia you build, eventually something will reach the fuel storage tanks, and then all of your Kerbals will die in the remains of the !!KSC!!.

Actually not. When I sent up my 1.0.4 workhorse spaceplane for the first time in 1.0.5, my first impression was that I was accelerating a bit slower on takeoff, but I wasn't sure. My first *clear* impression was that I was about 50 m/s faster than in 1.0.4 when I began leveling off after my post-takeoff climb, and I leveled off about 5000 meters higher than I'm used to. At that point the big issue became heating, not drag. I amended my launch procedure to use a shallower initial climb to level off at about the same altitude, and higher airspeed, than before. I then continue in an acceleration phase at about 10-15km, as before, but instead of using speed as my criterion for beginning my climb to orbit, I now pitch up and light my nukes at about 70% temperature for my critical part (as measured in Kerbal Engineer). The pitchup is shallower than I used to do, but I end up going faster from 26km up, and for my spaceplane, which is about 25 tons light load, 30 tons heavy, I end up with in the range of 100 fuel or so more than I used to.

Dropbox wants me to create an account to download your files, which I don't want to do, so I can't view them, but I think the issue that the Whiplash got reworked to be a bit longer, which I think has moved its COM back a bit. This, in turn, moves the COM of your whole spacecraft back, which is leading to aerodynamic instability. One of my spaceplanes remains more or less stable aerodynamically, but now sits on its tail on the runway if I launch it with no cargo (the original design had some issues of this kind to begin with, so I lightened the load in some of the aft fuel tankage and put in extra tanks up front to weigh the front end down. I now have to shift even more fuel forward to get it to sit on the nose gear instead of the tail.

On Linux, which already has 64-bit, both the 32 and 64-bit executables exist in the KSP folder as installed. Steam defaults to launching the 32-bit version, but you just need to change the launch options, as mentioned by Xyphos, to launch the 64-bit version.

Do note that the thread had been quiescent for about 5 months before you responded. That said, for the benefit of anyone else having this issue, I have had chutes randomly end up marked as deployed in my save files despite their stage not having been activated yet, and I have the feeling this is what happened to the OP. There's no real solution other than editing your save to repack the chute.

I'd in general like to see prominent features and easter eggs across the Kerbol system given their own biomes. For example, "Chicxukerb" crater on Kerbin (maybe a Biome each for rim, sea, and peak)and each of the Munar arches (if we found features like that on the IRL moon, could you imagine each one of them not being a huge science target?).

That all depends on your hardware. As I read it, the OP is discussing low memory situations in general, including cases where the amount of physical RAM is less than the 32-bit limit.

Not necessarily, because depending on your operating system and what system calls were used to load the files, and what the program does with the files immediately after loading them, "loading" does not always mean "moving immediately into RAM". Modern operating systems will often tell a program that they've loaded a file but not actually load it until the program actually uses it (and even then, they will only load the parts of the file that the program actually uses).

For the sake of both back compatibility between KSP versions and allowing players to run different sets of mods in different saves, it would be nice to have the GameData folder duplicated into the save folder when a new save is created, and to have the game reference the GameData folder for the current save rather than the global GameData folder. This way, if a new version of KSP changed the characteristics of a stock part, existing saves would continue using the old part, and different saves could use different sets of mods. The potential downside to this is increasing the disk footprint of the game fairly significantly.