Eric S

I'm not getting how you're mounting the quad thrusters from your description, and it's definitely not the way I do it. 4 quad thrusters placed with symmetry around the CoM works fine, as long as the CoM hasn't moved much before you need to use them. That rotates on all three axis, and translates in any direction.

You know, I wonder if this is the actual reason. The original plan for KSP was a 2d game, at which point you had to go to the left for your gravity turn because it was the only direction you could turn, and when they started making it 3d, they just stuck to turning to the left for continuity or out of developer inertia. I'm not complaining, I'm used to it the way it is for my stable launches, and my less stable launches always involve looking at the nav ball to see which way east is and which way I'm spinning.

Yeah, even while I might think our community is capable of overreaction on occasion, I've still seen worse elsewhere. Once saw a post where a player was deliberately trying to stir up hate towards a specific dev to get him fired, and said as much in his posts. Someone told him to keep the criticism constructive, as per the rules of that forum. User responded with "If he gets fired, the game will be better, so this is constructive criticism." Here's a hint. Even if I agree with you on what changes were good or bad, you'll never get my support if that's your attitude.

My comment probably came across in a way other than it was meant. I wasn't calling you out for having not read everything ever written about the game, I was just going into detail as to why it was on the "do not suggest" list. If you're interested in the future of the game, though, I'd recommend augmenting the wiki ToDo page with the developer blogs and weeklies, they often go into details that haven't made it to the wiki yet.

Because it would always place struts, even if they're not needed. Knowing how the craft is used (and is failing) lets me know what force I need to deal with, which lets me know where to place the struts, rather than just strutting everything.

Not having our **** together is the human steady state. There will always be something wrong, so saying this is tantamount to saying never.

Not only is this on the "do not suggest" list, but if you'd been reading the announcements of what the devs are working on, you'd know that at least part of the reason it's on the list is because the devs agree and it is coming. In fact work is already in progress, and it may make it in 0.22, with the may in there just in case something goes wrong. As for what can be a starting point, there are two requirements as I recall. 1) It has to have attachment points 2) It as to be able to have things surface attached to it. I can understand these requirements, as it reduces the frustration of someone new to the game by eliminating the "I just started a craft, why can I not attach the second part to the craft?" though I'm not sure how strong that argument is. I think the first rule is a good rule, as I can't think of a single part that surface attaches that would make a reasonable core of the ship. The exception to this would be radial decouplers, though to be honest, that only matters when it comes to subassemblies, and I put the radial decouplers on the main craft and then mount the subassembly on them, so them not being an exception has never been a problem. I'm less sure about the second rule but don't see it as a huge issue.

As I understand it, yes, the reduced drag is why reasonably aerodynamic rockets work better with FAR installed. I've seen launches use as little as 3300 delta-v to achieve LKO.

As I understand it, the last engine placed will be the first to flame out. If you place the last engine centered behind the CoM, when it flames out, you'll have a warning that you need to deal with it, either by throttling down or shutting down engines. Unfortunately, you need three engines to take advantage of this.

Sometimes miniaturization counts as a technical limitation. If the midrange engines come first, then that's because that size is easiest to get right, which generally means that it will take less time to go from concept to finished product given the same technical starting point. Heck, the thing is still too powerful for doing orbital maintenance on light geosynchronous satellites, even at minimum thrust.

That was in a Bobcat mod pack, the FLY space tug parts pack (combined with something else, MPSS?) if I remember correctly.

Maybe the LV-1 was the first to start development, but finishes later due to technical limitations? The first thing to be designed doesn't always reach production first, look at 802.11a vs 802.11b.

1) Probably, but I'm not one of them. 2) It might save delta-V over a regular launch to orbit then transfer, but it's still at least slightly less optimal than a gravity turn straight into an interplanetary transfer, and the lower your TWR, the more significant the difference. Scott Manley did a video on it. Basically, going straight up maximizes gravity losses, which are not insignificant. Think of it this way. If you have a rocket with a WTR of 2.0 and thrust straight up, the first 1.0 of your TWR goes to cancelling out gravity. On the other hand, should you thrust at the correct angle, you'll split the thrust into 1.0 vertical thrust and 1.732 horizontal thrust. The 1.0 vertical cancels out gravity, leaving you with a TWR of 1.732 accelerating the craft, or 73% more than you'd have going straight up. As you build up horizontal velocity, a portion of that horizontal velocity starts cancelling out part of gravity, allowing you to use more of your TWR for acceleration. Yes, you still have to take aerodynamic losses into effect, which is why traditionally KSP players have started their gravity turn at 10km height. At that point, they're past the thickest of the atmosphere, so it's time to start worrying more about gravity losses than aerodynamic losses.

Can't be done stock, but there is a mod that enables that. On the other hand, I can't remember the name of the mod, but I'm pretty sure it's on spaceport.

I like Dwarf Fortress, the only real downside was that just about the time things get interesting, things get very slow.

I take it I failed to communicate, then. My "definition of alpha" comment was specifically aimed at the question pertaining to releasing unfinished software. I then went on to explain that the situation isn't as simple as the poster thought it was, and even mentioned that I don't think squad CAN add multi-threaded physics without an effort significant enough to risk killing the project, though other optimizations are possible. I couldn't agree more. KSP has had a significant amount of "feature creep" and the Unity engine hasn't kept up. Originally the game was to be a 2d rocket simulator, and it's gone beyond both 2d and just rockets, and even the rockets are probably far more complex than anything the devs originally envisioned. I don't know what other options were available for game engines back when they started coding this and I don't know how well Unity would have handled the final version of the game that they originally envisioned. Unity may have been the wrong choice for the original vision and the devs didn't see the limitations in time (been there), or it may be the feature creep that caused the level of problems we're seeing. Having had a career in software development, I know how these kinds of decisions can bite you in the tender bits. If saying "Of course it's not finished, that's what alpha means, which isn't to say that your primary concern will or even can be addressed" counts as fanboy-ism, then I'd say we have different definitions. In fact, most of what I see in this thread isn't people saying that everything is fine, it's people saying that the OP doesn't have realistic expectations, for exactly the reason you mention. Sure, there is some level of it, but if you're staggered by it, you either have a very low tolerance or a broader definition of fanboy-ism

Actually, it still does, at least for the payload section. I've picked up tricks for minimizing the shift so that my RCS works fairly well no matter how much fuel and monoprop I've used. I used that addon to fine tune my technique on both the orbiter and lander for an apollo style Mun mission, and docking was cake. Also, the addon now adds a second (red) CoM indicator to show your dry-mass CoM, so you can tell where it's going to shift to.

I'm tempted to say "the definition of alpha." The game's alpha, by definition it's not a finished product. It's also not released yet, we just have access to the more stable development snapshots. And if you'd been reading the thread, you'd see that the best multi-threaded plugin can't multi-thread the physics calculations, and the one project that was a serious attempt at upgrading the physics was abandoned. This isn't a trivial thing you're asking for. No one has succeeded yet, and yet you think that it's a no-brainer that squad should be able to do it. Yes, it sounds like the terrain, especially the ocean coding, could use some optimization. I'm not going to try to say that the game's perfect as is, it's not, but they know that and they're working on it. I expect them to work on what they reasonably can, but I don't expect them to be the one group of people to slay the Unity thread-safe physics monster. To be honest, the game is already worth what I paid for it from my point of view, despite the fact that I came in late enough that I don't think they've increased the price since then. I hope that they can overcome the physics problem somehow, but if they can't, then I still look forward to all the other stuff they're working on.

Like many challenges, the challenge isn't to do it, but to do it the best/most. The scoreboard on this is the payload mass in orbit. So while small masses are easy, heavier masses get hard. Perhaps more so than a conventional rocket, perhaps less so, but it doesn't matter. More mass is harder, and that's where the challenge comes from.

THAT'S why Jeb, Bill, and Bob come back if you kill them. Jebediah isn't a name, it's a title! It means "Craziest One!" Bill and Bob are probably insult titles. Whenever one of them dies, the next in line takes the title. It all makes sense now.

Orion disagrees with the first point and agrees with the second, though since it never actually flew, should be taken with a grain of salt. Shaped nuclear charges do exist (I was surprised to learn this), and an even semi-realistic Orion drive outclasses just about any other drive in KSP except for the far-flung Sci-Fi addons. On the other hand, it does require a pusher plate, and I'd assume you'd need a pusher plate in the case of an asteroid unless you weren't too worried about increasing the amount of debris in space. TLDR: Using general purpose nukes to change an asteroid's orbit would quite likely be a bad idea, but assuming you could brace it properly, an Orion drive could probably do the job. Of course, turning the thing would be a nightmare. Personally, I think that adding asteroids in non-fixed orbits would be a very optimizeable feature as long as they're treated similarly to craft, right up until players start moving them. It would be easy to add 100 or even 1000 objects that spend almost all their time on rails, as long as you're not trying to display them on the map or in the tracking station, and it wouldn't be hard to only check their exact positions when you're near the asteroid belt. Hmmm.... you'd have to remove that optimization for any asteroid that the player has moved, but as long as they don't just go crazy with the asteroids it would be fine. Yup, all it would take is sane players. I'm sure we can find a handful of them somewhere.

It depends on how intricate the communication setup we get is. Picture a lander probe on the back side of the Mun. It has data to send back. If they enforce line of sight on radio communications, then that lander can't directly send back the data (or maybe they even go so far as to enforce short range vs long range communications). But you've got a comms satellite in low Munar orbit. When the probe establishes communication with the satellite, the satellite is also on the back side of the moon (a satellite in a higher orbit wouldn't have this issue) so the data can't be transferred in one pass that way. One solution would be to relay the probe's data to the satellite and then have the satellite transmit the data to Kerbin (or to a satellite in kerbin orbit, but this would require the requested ability to basically store the data in craft other than the one that gathered the data. Ooh, there's another handoff that will need to be done for science, though I think someone else mentioned it here as well. Apollo style mission. LEM goes down, gathers physical science data, links up with the orbiter. We need some way for the orbiter to now have credit for the physical results, because the LEM isn't going to be landing back on Kerbin. I'm not sure it matters if the credit is copied or transfered, as long as we can't turn in the same results twice.

Yes, and they've stated that the tech tree is career mode only. If you're saying that we need the money part for career mode, yes, eventually, but if 0.22 comes out with career mode that differs from sandbox mode only in that it uses the tech tree, it's still a step forward.

Actually, one of the devs mentioned this back the weekend before 0.21 came out, that they intended to do a compromise system that depending on the rotational velocity, would either save the rotation, or kill it, during warp.

It's a test to make sure it's at least semifunctional before trying to bring it down near any expensive facilities.