Shrike42

A picture would be helpful, if you have it, or a description of the rocket that's having problems.

So, are they rotating about the connections horizontally (trying to go parallel to the ground) or vertically (swinging left/right parallel to the center tank) or are they tilting inwards/outwards? Are the tanks colliding right after decoupling? In any case, the answer IS more struts, but what works for me is putting the decouplers at the middle of the boosters, struts from the central tank out to the boosters near the top of the booster tank (with that placement order, central tank to outer tanks), and connecting the adjacent tanks with one or two strut(s).

They let you make pretty much everything radial mounted, and allow you to get extra distance and structural strength into your designs without that much additional weight.

While we've gone well off-topic again, I don't see an issue with the demo. It's simple and feature limited, and as the purpose of the demo is to demonstrate what the game is about in order to drum up interest and attract potential buyers, just having rockets and a few common parts works well to establish KSP. And then, you have the youtube videos, the pictures on the forum, the announcements of the new update content, and other forms of media to present the final/current build. A buggy demo would hurt more than help, so the only thing that makes any sense at all is releasing demos based on very solid builds.

Er, how would you make the demo feature-limited vs. the full game? Time limit, perhaps? Making demos is extra work for any game company and not always the best investment. I think this video might be helpful for you to watch. It is on the Penny-arcade network, so be mindful of where you wander. Demo Daze by Extra Credits, SFW, Video

I originally sent this to Sputnik-1 as the thread went on a tangent, and he (or she) encouraged me to post it here. Slightly edited for clarity. ---- What you're seeing in the community is something that happens to all growing communities, in real life as well as online. Growing pains, basically. I can see you're worried about the community tanking and ruining your enjoyment of the game, but take heart. I don't see KSP becoming anywhere near as bad as the minecraft forums, the critical mass that MC achieved is almost impossible to replicate, and it's a self-reinforcing feedback loop. Also, it's a cult of personality. Notch and Jeb can do no wrong, death to the heretic! Squad's unintentionally headed off that part, since they didn't start it as a one-man operation and keep a relatively low profile. No one is specifically defending Nova or harvester, but they are defending the group. Distributed out, things are less intense. The other barrier is the learning curve in KSP. Even with the tutorials and wiki and Youtube videos, there's so much that can be done in KSP that it's hard for people to defend specific behaviors in construction that they may have never seen. That's a bit of a filter to help make growth more reasonable, and to get players to trust each other (with good advice and help) even more than the mods and devs, who can't possibly keep up with every request themselves. So, build that community. KSP is in a prime position to hold on to the spark you love, and as long as we set good examples, we can keep things positive for everyone and not end up like the MC forums. ---

Best community I've ever seen was the old City of Heroes forums, seven years ago. And then it became cliqued, both in game and out. It's easy to feel special as an early player, when the devs are far more active and able to respond to more posts, but then those responses make people think they're better than someone else, try to use their reputation score as a shortcut to justifying their positions and rally others, etc.etc. This sort of thing invariably occurs over time, as the playerbase and community grows. People get tired of answering the same questions, get irritated with each other, make mistakes, gain hubris... and fall prey to charismatic trolls. That's a real thing I've watched tear communities apart. It was rather impressive, but no, I'm not going to give any examples. Not family friendly anymore, if those communities still exist. There's far more reasons for it than that paltry list, but still, all communities will evolve, and it's up to each poster to make an effort to guide everyone else if you want to prevent it from happening. Jumping on others, self-appointing yourselves as enforcers of the laws... that's not the way to do it. Keep in mind, KSP is a game at the end of the day. No one will ever live or die because of the choices you make while playing it, but you can impact someone else's life through your behavior in the KSP community. Be excellent to each other.

They have also found a bit of use as long-lasting orbital correction engines for space stations, as each docking procedure alters the orbit slightly.

Not as much as you think. While I agree that there are times when the public opinion is completely wrong, and that people will moan and complain about any change to the established playstyles, it does not mean that straying from the original vision is a bad thing. I'd like to think I made it pretty clear that while DF is amazing and something I enjoy, I recognize that there are problems with it that became canonized because they were more entertaining or awesome (one of the primary faults being that Tarn won't work on the interface until the end... when it's pretty dang clear that he'll be dead before he'll consider it done). You didn't call DF a half-assed game for straying from the original vision, and I have three words for you: Vampires and boogeymen. Tarn Adams is constantly updating his vision for the game, if you read his updates; it's not a static idea, but a series of things he wants to put in, even if it requires completely rewriting the codebase in order to get closer to his new vision. I miss dungeonmasters and taming megabeasts. Likewise, when Notch realized he'd hit gold, he changed direction and did something new that got people excited, even though it was initially feature-poor and continues to be updated by "Hey, this'd be cool!" than any grand plan. The problem with your original post is that you staked out an unreasonable claim based entirely on your opinion, which opened up a whole can of worms that should have been left untouched. It's hard for me to resist tweaking noses when people call out others for using strawman arguments via strawman arguments... which is why I responded, in part, with a strawman. You opened with a clumsy analogy based on your opinion, and got smacked around a bit for it since you left the topic wide open. What you're really complaining about is presumption by the playerbase that the designers are infallible, and that the fanbase will invariably rally around the developers even when there are serious problems. That's certainly something that happens because people will defend what they love/enjoy, and this does carry a risk of shielding the devs from legitimate criticism. However, I don't see it as a big danger here, since people are very quick to offer technical criticism and KSP's community has such a wide range of skill levels and analytical thinking that there's a healthy mix of people trying stuff out because they don't know what shouldn't work, or because they do know what shouldn't work and try it anyway. Even disregarding the alpha status of the game, if you can enjoy the game, it's because you enjoy failing and learning. Hopefully, that should temper the dogpiling and white-knighting I've seen in other game communities.

Speaking of strawmen... While MC was definitely inspired by DF and infiniminer, it evolved as people discovered they liked having personal agency within the blocky sandbox world. That happened pretty quickly, and well before the explosion in popularity that made MC the 'half-assed' game you describe. And as it sounds like you're putting DF up on a pedestal in comparison, let's take a look at DF. So, you're giving a pass to: melting fat off yourself to become fire resistant, quantum stockpiles, danger rooms, atom smashers, burning lignite in metal boxes for evaporating oceans, hydras that are only now not likely to die from a single blow, fluffy wamblers that can decapitate a bronze colossus, catsplosions, overpowered archers, and dwarven reactors. Which are all unintended effects or applications of Tarn's buggy coding (not to mention DF's penchant for entirely pegging a CPU with single-threaded calculations). While decrying things like... asparagus systems, air intake spamming, part clipping without debug, geometry strangeness, and a lack of frictional heating That's quite a dual standard you've got there. Design intent and implementation aren't the same thing. Sometimes errors and bugs can create opportunities to enjoy games in ways no less valid than what the developer originally envisioned. Sometimes these are embraced by the community and the dev team, who work the game around it. Sometimes they are considered errors and stopgaps while something better is put in place. It's one thing to want the Devs to work on their dream without bending to the will of the populace. It's quite another to insist they ignore feedback and happy accidents in favor of pure ideas. And ... you'd prefer that KSP not be a massive commercial success like Minecraft and get people thinking about space exploration and the value of engineering and science? Well, okay. For what it's worth: I'm no stranger to dwarven !!SCIENCE!!, which is the exploration and exploitation of bugs. I was one of the first people to correctly identify what the "acid rain" bug really was, leading to me personally inventing the dwarven healing chamber and contributing to the bug's weaponization in the dwarven microwave.

ASAS: Sooo, wings, and control surfaces. Me: Right. ASAS: And we aren't going straight up? Me: Right again. ASAS: Are you sure that's possible? Me: Yep. LIFTOFF! ASAS: HOLY CRAP THIS IS AMAZING. Me: Okay, time for a course correction, turn off ASAS for a bit, change, and... ASAS: I AM A BALLERINA OF THE SKY! Bill: Hurk...BLARGHhhhh ASAS was destroyed Mk-2 Cockpit was destroyed Bill Kerman was killed Player has facepalmed

Spider-rover, spider rover, does whatever a spider-rover does...

Oh, I see the chair now. Hm. Well, you could use panels or pylons or i-beams to give it a roll cage. Probably not a bad idea in any case, since that light little thing is going to accelerate pretty dang quickly.

Well, how about using that same rocomax tank, putting on landerlegs and ASAS, and put the rover on top? Once you land, you retract the lander legs on the tank, and drive off. Hmmm... How about this: your rover is REALLY low slung. Could you put another set of panels on top of all the sensitive bits to protect 'em from overhead impact, strut together for strength in a structural plate sandwich, then put a lander leg on top so that if the rover flips over, you can extend the leg to right yourself again? With this approach, you could sandwich your lights and sensors and batteries safely inside the rover, put a few solar panels on the outside (if not a few reactors on the inside) and have a solid little system that could handle the drop.

I've been avoiding skycranes. I have a ship that can land and drop off two small rovers and take off again, and a few manned rovers that have a landing stage and separate upon arrival. Edit: To clarify, the landing stage is under/inside the legs of the rover. That way I just have to line it up with the CoM, and carefully weight the rover.

When I was doing the machingbird challenge, I designed my spaceplanes for stability with ASAS. What this let me do was monitor the fuel levels and transfer the fuel from back to front; once the rear fuel tank is empty, it won't refill. I also tended to use the bicoupler to carry 4 fueltanks, two off each of the prongs, which let me keep the center of mass fairly stable by shifting the bottom tanks, then the top tanks. This isn't a pretty solution, but it does work. Probably easier to go with the fuel balancer mod or one of the suggested design strategies.

Well, there's Kerbal engineer, but it hasn't been updated for 0.20. It gives you the TWR, and as long as you can keep it above 1 for Kerbin, you can get it off the ground.

Great! In terms of design, what you need to keep in mind is that the higher the rover's center of mass, the more easily it will roll from side to side. A narrow wheelbase will also make it easy to tilt over. In your future designs, you can try using the pylons and I-beams to make a wider platform for the rover, which will let you drive more safely. Also, you can use the structural panels to 'armor plate' the rover against impacts (don't block the hatch or the windows), and add lander legs to the TOP of the rover to flip it back upright or prevent the command module from hitting the ground headfirst.

Yep. That's what I did. I use the small rockomax tank and four rockomax radial engines, and that allows for mun lift off. The major downside to the design I'll be posting is that getting it off the transfer/landing/refuelling stage is that you need to hover the rover off the top, but I've compensated for that by doing a lot of work on the system's durability. It's still possible to blow it up by going too fast, but it's also got a lot of survivability so long as it remains upright... and it can self-right, as well. I compensated for this by adding armor and a some lander legs to the top, so it can cartwheel instead of crash if it starts to roll.

You can also make your rover from a lander can, and get rid of the skycrane all together. Or, use an oscar tank and some rockomax radials on a small rover to take it off the top of another craft... Or, mount the rover (or two, for symmetry) on the side of your lander craft and drop them off. The skycrane is just one option. It's certainly awesome looking, but if you just want a rover on the moon, there's a number of ways to do it. If you're having troubles getting things to the mun, that's a different issue all together. Rovers don't have to be very heavy, so if you can't get the payload to the mun to start with, you might want to look at your launcher and transfer stage. I'll give you my simple manned landercan rover design, just need to upload it to spaceport.

I'm hoping they go back and revisit the earlier command modules, I still can't see out of the in-line canopy or the shuttle cockpit. Also, they need snacks. Edit: A reduction in the glare on the 2-man landercan navball would also be a nice quality of life improvement.

As an alternative to massive numbers of stages, you can use command groups for the same purpose. This has the extra advantage of letting you repack the chutes and deploy them again.

I tried the new ones, but they won't move at all, the rover sinks into the ground. I can wiggle them... Okay, after putting them on the right way, they work quite well and seem to promise an excellent way to upgrade my rovers for stability without sacrificing too much speed at all. And they're more energy efficient, too!

Google 'ablative armor'. Edit: To clarify, if you design things with crumple zones and parts that are intended to absorb energy and be destroyed instead of transferring and damaging the core component, there's a whole new field of lander design to explore, even for inelegant pilots like myself.

Does this require the craft survive, or just the crew? Edit: Reread the rules, just the command pod or probe body, got it.