Eric S

Considering the fact that one of the recently fixed 64-bit Win Unity client bugs was "raycasting randomly causes crashes," I really don't think we can really say that the 64-bit Unity Win client isn't the issue. They've obviously done at least all of the non-OS specific 64 bit recoding, because there's a 64 bit version of the Linux version of KSP. I'll admit that it's possible that all the remaining bugs are on the KSP side, but we've got no evidence that that is the case.

I noticed that too. I'm assuming that that will happen later, since it's the main reason I want tweakables.

It doesn't look like this is in yet. When Yarg was showing it off and he reduced the amount of oxidizer in the tank, the fuel limit stayed where it was, so it doesn't look like you can take a mixed-type tank and turn it into a fuel-only tank with a greater fuel capacity. I saw nothing to indicate that non-fuel tanks gained the ability to hold fuel.

It looked like it.

The SABRE-like engine can be set to automatically switch between air breathing and rocket mode.

I disagree. Public domain is entirely different from Creative Commons licensing, especially from a legal standpoint. The first one is the proper answer.

True, even FAR has it's share of approximations.

Not that I'd use it this way, but some people would want an option to put it one stage up from the bottom, to replicate how it's done in real life. Light up the engines, and let go of the craft once you know that they're all properly functioning. Not a desperate request by any means, just getting ahead of someone else asking for it.

The negative drag suggestion has come up before and people have actually experimented with it, and in order for the negative drag to have a noticeable effect on the drag of a real craft, it had to be enough that craft that were built as Smidge suggests could use the force of a single decoupler to reach solar escape velocity. You could get around this by doing something like "nosecones reduce the drag coefficient of all parts connected below it by X%, but at that point, your asking them to write code for a minor improvement to a placeholder subsystem. The KSP devs know that their current aerodynamic model is at best a gross approximation, and every time the subject of replacing it has come up, if an answer was given, it was that it would be replaced at some point.

Well yes, but the special guests and such will be on the live stream, not sitting in an auditorium somewhere.

Sadly, as much as I would love this kind of science system, I have to think this. Something like this would provide benefit for manned missions, as some information could be gained directly through observation, and just about all types of information would require less equipment if the equipment only has to take the measurements and doesn't have to deal with acquiring the sample and moving the sample from instrument to instrument. One way trips would need heavier equipment because they'd need to do the analysis in place, etc. It would also allow you to separate out consumables from the actual equipment, so if you plan running a materials science experiment once, you wouldn't need as much consumables as you would if you were going to run it 10 times, but you also wouldn't need to duplicate all the equipment 10 times. In the end, however, I realize that if they were to design the game exactly how I would design it, I'd probably be the only person playing it. Playable game mechanics tend to trump realism, and I think they should. The current retransmit-until-no-more-science game mechanic is broken, not fun, etc., and it's getting fixed. Without knowing exactly how they fixed it, all this discussion about how to improve the science system is purely theoretical, as we don't know how much of it will apply to the 0.23 science system, where that game mechanic is getting fixed. This isn't to say that 0.23 will be perfect and need no improvement.

Was hoping to get an answer to that myself, Friday's not an issue, but I need to rearrange my schedule on Thursday or possibly Wednesday depending on what time it starts.

I'm going to disagree. Having each part be individually balanced is probably a good starting point, but unless all the parts are the same mass, size, and RCS thrust, there will probably be imperfections in the RCS balance of the joined craft, and it's possible for the imbalance to be more than slight. As an example, imagine a craft that is the size and mass of a Rockomax 200-16 fuel tank, and you've got four RCS quads mounted around its center of mass. Dock this end-to-end to another craft the same and mass of a Rockomax 200-32 fuel tank, also with four RCS quads mounted around its center of mass. You've now got two craft that individually are perfectly balanced but when docked, the center of mass and center of RCS thrust are no longer in the same place. The center of mass would be a meter towards the larger craft from the docking point, but the center of RCS thrust would be half a meter from the same point in the same direction. Now, if the larger craft had twice the RCS thrust of the lighter one, then the center of mass and center of RCS thrust would stay together as the craft is joined. However, it will get harder and harder to maintain this as you connect multiple parts all with different masses, as RCS thrust isn't very flexible. On the other hand, if you turn on fine control (caps-lock), there's a very simple RCS balancer that kicks in that should help the craft be closer to balanced.

The omniwheel from TT Modular Multiwheels. I haven't checked to make sure it still works in 0.22, but I've used it to great effect in earlier versions of KSP for modular base building. Being able to move in any direction and adjust the height is wonderful for that kind of work.

Slight (and possibly wrong) clarification. The dev notes described the possibility of sabre engines without a plugin, the stream strongly implied that we'd also get a STOCK sabre-like engine. That we'd get a stock engine at some point that took advantage of this was likely, but this makes it sound much more likely to turn up in 0.23. The stream went on to imply that cleaning up the spaceplane parts (including adding cargo holds) might just get bumped up in priority because of this engine. They said that how much of a craft returns to Kerbin will affect the budget for your next launch, and that this type of engine is going to make SSTOs more feasible. We all expected that some fraction of the cost of the parts that return would go back into the budget, but this is the first I've heard where the devs are actively talking about it and the implications it will have.

The devs have said that they don't want a single difficulty setting, but they have mentioned when discussing most of the topics you mention that they will probably have a setting per "advanced" feature that you can turn on or off.

It won't get deleted, just locked. L1, L2, and L3 aren't stable lagrange points, so you're talking something that few KSP players could really take advantage of. L4 and L5 are stable, but can be faked easily enough. For that matter, L3 can be faked as well, though unless you're talking the Sun-Kerbin L3, it would be far enough from the real position to be definitely noticeable. In my opinion, most of the reasons people want lagrange points in game comes from the real-world benefits of lagrange points, which is to say that orbits in lagrange points are far more stable than other orbits. Well, in KSP, that's not a problem, because unless your orbit intersects an atmosphere or celestial body or changes SoI, it's even more stable than an orbit in a lagrange point would be.

I use asparagus staged rockets with FAR all the time, and I've never seen this problem once I got out of the atmosphere. They're touchy below about 20-25km, but once that far up, it's easy to forget that FAR is installed. My guess is there's something else going on, though it could be a bug with the latest version of FAR, I haven't upgraded yet, still one version behind.

This. While it's always possible they may change their minds, the devs have already stated that they're not interested in a single difficulty setting. They are willing to consider having the ability to turn things like reentry heat and life support on and off (assuming they get implemented), but those would be individual settings so you could pick and choose between them.

A reasonable point I hadn't considered. I tend to go to Minmus before the Mun, so I've usually got the 48-7S unlocked by the time I go to the Mun, but that doesn't apply to everyone.

Try Kerbal Engineer Redux, and maybe one of the mods that add KER functionality to all command pods. With or without the extra mod, you can get delta-v readouts starting on your first mission. While strictly true, the capsule is capable of storing multiple surface samples as long as they're of different biomes. I've returned 15 surface samples in a single Mun mission. As to the main purpose of the thread, I find the trick is to be choosy about overbuilding the craft. For example, this is my multi-biome Munar lander. It has enough delta-V that I can usually hit 4-6 biomes in a single mission and is usable far earlier in the tech tree than you are now (the only tech it uses that you don't have are the folding solar panels, and you can easily work around that). The four radially mounted fuel tanks are chained drop tanks, so I drop the first two as soon as they're empty, and the other two when it's time to go home (and they're empty). The center stack as enough fuel to return the craft to orbit and put the craft into an aerobrake return to Kerbin, provided the drop tanks have been dropped. As you can see, that's over 10k delta-v, which is serious overkill if you're not planning on suborbital hops to go to multiple biomes. Though definitely do suborbital hops rather than a full return to orbit then landing, that will take over twice as much delta-v per hop. Heck, I even do most of my initial landing using the transfer stage, dropping it only when I have to so that it won't be under me when I land. I think you'd have to be really meticulous to have any chance to even get close to 15 biomes with that craft, however. My other multi-biome Munar lander takes a slightly different approach. The lander is a multihop lander/rover combination, so it drives to biomes that are close, hops to those that are farther away. This is the one that I've hit all 15 biomes in a single trip with, though it takes a lot of driving to pull that off. This one uses the same technologies as the first one plus wheels, so it often isn't my first Munar lander in any particular career mode save.

The 48-7S version of that craft would have 100 more delta-v, not less. As for the TWR, to be honest, when I was learning to land on the Mun, a TWR of almost 10 would have been an issue, far to easy too overcorrect and wind up going back up. Even the 6.9 TWR of the 48-7S might have been a little much. Not trying to say you need to change it for the sake of the newbies, I just think you're underestimating the OPnes of the 48-7S, especially in the case where the 909 would be a significant fraction of the mass of the resulting craft. I honestly expect that engine to get nerfed before final release. Half the thrust in a fifth the mass more than makes up for the lower ISP on lighter craft.

If I think I can do it better, I do it again, though usually not as the very next mission, just so that I don't devolve into repeating the same mission over and over just to reach perfection.

Actually, that's not true, but mostly because career mode is far from finished so far. The only part of it that's there is science and the tech tree, and the tech tree had multiple purposes, one of which was to ease the introduction of new players. Personally, the only things I've done in sandbox mode since career mode came out have been reddit challenges and experiments. I've filled out the entire tech tree several times, and started playing with alternate tech trees. For the most part, the alternate tech trees either didn't feel that different once I got a few basic parts or changed the focus of the game so much that I lost interest. That said, at it's current level of implementation, career mode doesn't add that much to keep me interested in KSP, but it does provide something that was new for a while and still adds a little complexity to the mix.

I think that the rest of the features coming to career mode will deal with many of your issues, including diluting the importance of maximizing science return. Sure, mission X gets more science than mission Y, but if mission Y has a better expense to science ratio, it might be more lucrative, or even necessary, depending on how tight your budget is. As for repeat science experiments, it sounds like the devs are already doing something like that. Personally, I don't think the science rewards need to be balanced too much for this, I've been playing this way for weeks and have never run into "I need more science to get to where I want to go next, oh woe is me!"