Eric S

Actually, its ISP is much better than the radial version, and while the 909 has a better ISP, it has five times the mass for twice the thrust, and for low-g environments, I never use all the thrust anyway. If I take the single 48-7S off of my Minmus/Mun lander and replace it with a 909, the total delta-v of the craft goes down because the mass went up. I've got a spaceplane I designed in 0.22 that uses a turbojet and two 48-7S engines. That craft gets to orbit with more fuel remaining than a similar craft with a single RAPIER, and the craft has less mass (from engines) as well. The biggest advantage of the RAPIER is that you only have to find space for a single engine, though only having to set up fuel lines for a single engine is also a solid advantage.

Kerbal Space Program focuses more on gameplay than realism. Because of that and the fact that it's "Space Program" you're pushed towards rockets. There are mods that change the tech tree once you feel comfortable with the game, and I'm pretty sure I've seen at least one where planes come before rockets. For similar reasons. Manned missions are easier to get right for new players. They don't have to worry about power, and capsules are easier to control because the have larger reaction wheels. There's also the fact that the kerbals in the corner of the screen, whether they're screaming or laughing maniacally, tend to draw people into the game so that what is happening matters more. Again, because the focus is on manned space flight, and while manned missions benefit from batteries, they aren't as critical as they are for unmanned missions. I don't think you're missing much. Early on, the only science you get from probe missions are from recovering a craft that went someplace. Again, because the focus is on manned missions and having access to science sensors and all the manned science at the same time would have players blowing through the early tech tree. Once you get another level or two into the tech tree, there are science sensor parts that will let you gain science through them. The thermometer is probably the first one you'll get. There's also a barometer, seismograph, gravitoli detector, and atmospheric analysis sensor. EDIT: Oops, forgot about the goo container and materials science bay. You should have them unlocked by now, so they're a source of science for probe missions. You probably need to push out farther, though you might be missing some science where you're at. My first mission in a stock career mode usually nets about 100-145 science, at which point I can make it to Minmus, which nets enough science that I can do a better Minmus mission, or go to the Mun. By the time I've hit the Mun, I've got the parts I need to go to Duna or Eve (but not a return from the surface of Eve). By the time I've gone to Duna and Eve, I've got the parts I need to go to Moho/Jool/Eeloo. It's possible you're missing the fact that the kerbals have a jet pack. You need to hit 'r' to turn it on while they EVA. They all make sense, and in fact, most of them are frequently asked questions, heavily debated topics, or frequently requested features, in the case of EVA tethers. If you find that doing manned missions before unmanned missions bothers you, there are mods that will change that, and they're not hard to find. Part of the reason I'm willing to accept the gameplay over reality focus is that the gameplay emphasis helps newer players, and experienced players know how to install mods to make the game closer to what they want.

To be honest, with the latest changes there's little reason to do probe missions. Having one less difference is fine in my opinion. In 0.22, the difference between a manned and unmanned mission science-wise was the lack of EVA reports, crew reports, and surface samples. In 0.23, however, probe missions took a hit because you have to return now, repeated transmissions can't compete with actual returns. Furthermore, the ability to move results to the capsule via EVA means that even with a single thermometer, you can get full value return results from multiple locations for a manned mission, but the probe is still stuck with at most one return per thermometer. Manned missions can use the same thing to ditch the mat-sci and goo container parts, returning significantly less mass to Kerbin, but still get full return value for those experiments.

The problem is that you just replaced the important function of the lab with something quite a bit more portable. On the other hand, version 0.23 did give EVA a new science related use that I think is almost OP. You can, while on EVA, remove the science from an experiment and store the results in the capsule, gaining you a full return value when the capsule is recovered. This means full return value for goo and mat-sci without having to bring the part itself back home. I'm throwing two mat-sci and two goo containers on transfer stages now, using one of each at high orbit at the destination, the other at low orbit, and then stuffing the results into the capsule before I ditch the transfer stage. My first 0.23 Minmus mission got full return value for six materials science experiments and six goo experiments despite the fact that only the capsule and a parachute actually returned all the way to Kerbin. My first Mun mission is going to have full-return-value temperature/seismic/gravioli readings without having to place a part for every biome on the return craft. Trust me when I say that this can have a profound effect on how much you EVA :-)

I've got a post on reddit that goes over the sources of pre-science-part science and describes how to get over 130 points of science on your first mission. Even if you don't try to follow the recipe, it'll show you the options that you might be overlooking. It was written for 0.22, but pre-science-part science hasn't changed much in 0.23.

Not really. The sensor-type experiments are reusable, but the diminishing returns were changed so that even if a transmission only gets you 20% of the value of a return, a second transmission from the same location is going to return much less science (like a third as much as the first one), and each subsequent one is much smaller. Because of this, repeat transmissions can't return as much, let alone more, science as a single return. However, if you're doing a multi-location mission, then the sensor-type experiments are still capable of getting their usual bite out of every location. In fact, because you can now move the results into the capsule via EVA, you can now get full return value from a single sensor from multiple locations if it's a manned mission.

As long as the fuel types are fixed in the VAB and not tweakable while in flight, I don't see a problem with this. Since different types of tanks have different volumes and dry weights, they'd have to take that into account, but as long as they do that, it's fewer parts and more flexibility. I don't know if the devs have changed their minds on this, but this ability to change the type of fuel in a tank was mentioned as one of the things they had planned when they first started talking about tweakables. Later on, this type of tweakable was mentioned as what they were waiting for before switching over to atomic engines that don't use oxidizer. Because removing oxidizer would reduce reaction mass, they'd be severely nerfing atomic engines if they did that without giving us tanks that could hold more liquid fuel without dealing with the dry mass of combined tanks that just aren't holding oxidizer. It was also brought up when Claire was doing KSPX. The devs didn't want to color code tanks according to what fuels were in the tank because by their plan at the time, the fuel types of any given tank wouldn't be fixed. Sadly, that thread was one that went poof back in April. As I said, they may have changed their minds. They may have also done this as the first pass on tweakables and they're not done adding features to tweakables yet. Either way, at some time, the devs had intended to do just that, the only difference is whether or not they still intend to do that.

I think a lot of the fuss over the RAPIER engine has to do with people not realizing how many behind the scenes changes there were that affect all spaceplanes. My 0.22 spaceplane is doing far better in 0.23 than it did in 0.22 and even better than my first RAPIER spaceplane does. I was at about 30 km altitude, 2300 m/s, and both gaining altitude and accelerating off of a turbojet engine. I'm positive I've never seen that happen before.

Yup. Between that and the change in the material sciences bay and goo container, I've started placing those parts on transfer stages, and then moving the results to the capsule before I drop the transfer stage. I'm also placing them on the drop tanks of my high-delta-v munar (and now minmus) landers. The only thing that comes all the way back is a capsule and a parachute, and the only thing I transmit are crew reports. Hmmm... I wonder if I can do an eva report, pull it from the capsule, do an eva report in another biome, and then put the first one back. Too late to test tonight, but I'll definitely test it tomorrow. Though since EVA reports transmit at 100%, that wouldn't gain much.

They're not way overpowered compared to 0.23 turbojets, just the 0.22 ones you're used to. Compared to the last spaceplane I was experimenting with in 0.22, the RAPIER version took more fuel to get to orbit. The thing is, there have been changes to turbojets and resources (the way IntakeAir gets handled) that have seriously changed the performance of any spaceplane in 0.23, and that's a lot of what people are seeing when they're thinking the RAPIER is OP. Having the dual mode engine is nice, but it's mostly a conveniece, it really isn't going to do that much that a conventional spaceplane can't pull off.

Now that you mention it, the engines automatically throttling back was one of the improvements mentioned in the Squadcast that announced the RAPIER. They also mentioned other things that would improve spaceplane functionality, but I can't remember too much of them.

As I understand it, jet engines will automatically throttle down before flaming out. I know I was nursing a good bit of delta-v out of my turbojet even after the IntakeAir resource read 0, though the thrust was dropping fast.

The RAPIER is a matter of convenience, you only need to find a place to put a single engine. The WOW factor that people are seeing (and in some cases mistaking for the RAPIER being OP) is because of changes to intakes, jet engines, resource handling, etc. Without extreme levels of intake spamming, I just put a spaceplane into a 112 km orbit on all of 60 delta-v from the rockets, the rest came from an old fashioned turbojet. Among other things, I'm not sure if turbojets still lose thrust at some point, but at 2300 m/s and an altitude of about 30km, I was both climbing and accelerating, and I don't think any amount of intake spamming would have managed that in 0.22.

No, it really doesn't. That was just knowing how to do action groups. Trust me, fly one of your old designs and you'll realize that most of the WOW factor of the rapier comes from the fact that it came out at the same time as a serious overhaul of some of the spaceplane functionality. I pulled out one of my 0.22 spaceplanes, and it got to orbit better than the RAPIER test craft I put together. Admittedly, since it had three engines (one turbojet and two Rockomax 48-7S) it had three air intakes compared to the one on the RAPIER design, but they had comparable masses and amounts of fuel. I used the rockets for a total of 60 delta-v in reaching a 112 km circular orbit.

That's not the point in contention. I probably shouldn't have trimmed the quote down as far as I did. Most of the people I've seen wanting 64 bit support have been asking for it so that they can run more mods without the game crashing. Yes, there are people that think that 64 bit support will dramatically improve the performance, even a few that think that 64-bit support would magically make KSP spread it's physics workload across all CPUs. These people are misguided, we both see that. I see them as the minority of the people wanting 64-bit support, though, and I think that's the only point we disagree on. That wasn't directed at you, sorry if it came across that way.

Yes, people have claimed that, but for every person that has, two people have disagreed saying that 64 bit code would provide a minimal at best speed increase, the real win is the game not crashing when mods use too much memory. That is brought up all the time, sometimes by people that don't even realize that the problem is that they're running out of memory. None of which affects whether Squad should put more effort into hammering out bugs (I'm in the camp that thinks 64 bit Unity for win is the issue, it's not Squad that is holding it up), or even what optimizations are in 0.23. On the memory front, Scott Manley mentioned that 0.23 compressed textures in memory, instead of keeping them all uncompressed, which should help quite a bit.

I very much doubt that they're looking at anything like an MMO version of KSP, so I very much doubt single player is going anywhere.

The Unity devs haven't forgotten about 64 bit, there are bug fixes listed for 64 bit clients, and one showstopper that was 64 bit windows client specific. I just don't think they're focusing on it. I don't know too many games that are severely restricted due to 32 bit addressing space. KSP happens to be one of them, but that by itself doesn't mean that the problem is common enough for the devs to prioritize it.

Actually, while I agree with this idea, geo-kerbin orbit is not low enough if you're doing three satellites (or using the Communotron 16s, but you already covered that). Here's a little geometry/trig for satellite setup in KSP for anyone that finds this thread at a later date (my math skills are a little rusty, so feel free to verify all of this): Four satellites at a geosync altitude of 2868750m above a 600000m sea level, this gives a distance of 3468750 m from the center. At 90 degrees of separation, that gives you a satellite to satellite distance of 4905553.3m, which is just under the 5 Mm range limit of the 32s. At 120 degrees of separation, that gives you a distance just over 6 Mm, which is longer than the communication range of any omnidirectional antenna in RT2. The obvious solution if you either don't have the Communotron 32 yet, or if you only want to use three satellites is to lower the orbit. Geostationary is used in reality because it's easier to communicate with a satellite that never moves. We don't have that issue in KSP with RT2, satellites are tracked as necessary. The only disadvantage for us is that all of the satellites have to be able to communicate with the ground. This would be an issue if we were using dishes, but not with omnidirectional antennas, since the same antenna that communicates with the other satellites can also communicate with mission control. Since a synchronous orbit works for the Communotron 32 with four satellites, cutting the distance from the center in half will work for the Communotron 16, so your ceiling from the center becomes 1734375 m, or 1134375m altitude above kerbin sea level. In the case of a three satellite network using Communotron 32s, your max distance from the center would be about 3468750 m / 6008051 * 5000000, or 2886751 m from the center or 2268751 m above Kerbin sea level. For three satellites with communotron 16s, your max distance from the center would be half of that, or 1443375m, resulting in a max height of 843375m. I should point out that those maximum height numbers for the three satellite configuration have no margin of error, so I'd orbit at least a few kilometers below that point. There's a minimum orbit too for this, the point at which Kerbin is in the way of two satellites trying to communicate. With a radius of 600 km, for a 4 satellite configuration, you have to be at 248529 m above sea level to have line of site. For a 3 satellite configuration, that increases to 600000m. In my career mode saves with RemoteTech 2, I've been using a three-satellite configuration where each satellite has a communotron 16 and three of the smallest dishes, aimed at active vessel, the Mun, and Minmus, at an altitude of 776.57km above sea level (a 1.5 hour orbit) with no issues. Once I start heading to other planets, I add another three satellites with a Communotron 16/32 and two big dishes, one set to active vessel and one to whatever planet I'm exploring. By the time I can put craft large enough to have enough long range antennas to cover the entire system without switching planet targetting, I'm usually so close to finishing the tech tree that I don't bother, since I start a new save as soon as the tree is finished (at least until we get more of career mode).

This is actually close to my first impression of what Harvester said during KerbalKon. The problem they had with the resources system that they had laid out was that it was a micromanaging grind and not fun. I've said as much about Kethane. Yes, it enables me to do more interesting missions, but the enjoyment came from those missions, not from finding/mining/processing kethane. I got the impression that Harvester wanted to find a fun way to enable the same types of missions if possible (or at least non-grindy), and would rather not put something that is pure grind in the game and then suffer backlash from removing it if/when they came up with a better solution.

If you're aiming at synchronous orbits, I strongly recommend placing a very weak engine on the satellite and installing Kerbal Engineer Redux. KER gives a readout of your orbital position to within 0.1 of a second. If you're doing synchronous orbits, that means that they're in a 6 hour orbit, which would drift at most 146 seconds out of position (0.7%) in a terestrial year. Don't focus on your perapsis or apoapsis or orbital velocity other than getting them close. Then use the weak engine to fine tune the orbit to something close enough to a 6 hour orbit that KER doesn't report the difference. MechJeb can also be used, but the last time I checked, only reported orbital periods to a resolution of one second. EDIT: Depending on the precision you can adjust it to, the variable max thrust part of tweakables may render the need to put a weak engine on the craft unnecessary, as you will be able to make any engine weak. But be aware that even 1 m/s will have a very significant effect (for these purposes) on the orbital period, so you'll still want to get as accurate an orbital period as you can.

To be perfectly honest, the "go somewhere and mine resources" type stuff isn't fun in and of itself. It enables you to do different categories of missions that would otherwise require refueling missions, but other than the initial joy of hearing that first beep of the scanner or the first time you actually pull kethane out of the ground, it's really quite boring and not that interesting, it's those missions it enables that are fun. I view MP the same way. There will be things that I can do that I couldn't do before, and depending on just how MP is implemented, some of them might even be important to me. I'm not at all interested in combat in KSP, though this will certainly enable that. I'd be more interested in being able to ride shotgun on someone elses mission and kibitz. Several times ever week, I encounter someone that needs help playing KSP, and it usually involves half a day or more of back and forth messages trying to figure out what they're really doing wrong. It would be nice to be able to pull up his/her craft in real time, watch the fuel drain, etc. More interactive than watching a stream, I always get frustrated because I want to view some part of the ship that the player isn't paying attention to, check the orbital parameters when they're focused on something else, etc.

I've used them for just about every reason mentioned here, and one more on top of that. I often use them as a booster for satellites. I'll put a multi-satellite launching vehicle in an orbit that's got the right apoapsis, but a periapsis that makes the orbit faster than the final orbit, and I kick the satellites out one at a time and they do their own circularization. Depending on the amount of delta-v that they'll need to circularize, I may just use RCS, I may use a few Sepratrons to give it an extra kick, or I may even mount a regular tank and engine.

I'm looking forward to seeing it, but unless the Rockomax 48-7S gets nerfed, I suspect that the RAPIER will still be more mass than a turbojet plus a few of those, though it will certainly be more convenient. Those little buggers are just plain OP. I've heard a lot of talk about the RAPIER being overpowered, though at least some of that is probably due to changes that are going to benefit the regular jet and turbojet engine as well. Not at all surprising, passenger rail transit just isn't as popular here, the country is too spread out for people to take their time travelling by train. I don't mean just the size of the country, I'm talking the distance between population centers. Get out of New England/the midwest/California, and you start seeing warning signs along the lines of "Next gas, X miles." I used to regularly drive past one that was "Next Gas, 106 miles" when traveling between my parent's home and the college I was attending. As for commuting within a city, there were some rather active lobbyists a long time ago that convinced most major american cities to rip out their light rail commuter systems and replace them with busses, and that trend has only started reversing in the last decade or two.

If KSP were done MMO, you'd be right. If it were done with mostly public servers, you'd probably be right. On the other hand, if I use MP to play with friends and one of them acts like that without being lighthearted about it, they probably won't be invited back. It's the difference between playing with friends and playing with strangers.