JumpsterG

FIRST: Please get and use RCS Build Aid: http://forum.kerbalspaceprogram.com/threads/35996-0-23-RCS-Build-Aid-v0-4-3-blizzy78-s-toolbar-support It will display your dry center of mass in addition to your starting center of mass and helps IMMENSELY with making sure your center of mass doesn't end up somewhere you don't want after burning a lot of fuel. No parts or obnoxious elements, just a straight-up editor tool. Just yesterday, I succeeded in designing and flying a stock SSTO spaceplane carrying 13 Kerbals (Mk2 cockpit + 3 hitchhikers). Takes off, lands softly (even fully laden), reaches orbit with 900 m/s dV, and has ejection parachutes to boot. I'm not at home, so I can't get the specs or screenshots for it, but I think it's dry mass is somewhere between 20-30 tons. It's not so big (compared to other's designs), but I'm now scaling up 3x to a 37 Kerbal capacity (Mk2 + 9 hitchikers) and, surprisingly, I'm finding it's not that much harder to go bigger (with proper strutting; god help you if you don't strut well). The biggest problem I have found is that the number of wing pieces (total lift) required to takeoff and land gets ridiculous and it can be a struggle to find places to put them all without clipping or looking strange. The best trick I have found so far is to extend the length of the plane by adding additional large fuel tanks at the back. Thanks to tweakables, you can adjust fuel load wherever you need to, so some tanks can be used just as structural elements. This gives you more room to attach wings and provides more flexibility for tweaking center of mass and center of lift, since parts and fuel can easily be moved more forward or backward over a wider area. It's been said before, but I'll reiterate it: Putting your intakes at the back of the plane (behind center mass) helps maintain stability by a wide margin (inversely, having them up front will cause a tendency for the plane to want go backwards). This makes me want a fourth indicator in the editor: A center of drag indicator that shows the average of drag from all parts. Maybe I should throw that on the suggestions page... Finally, I advise leveraging the massless-ness of the tiny cube struts when extending your landing gear below the plane. Since you will need some good clearance from the ground and will likely be using a lot of wheels, you need to avoid adding too much structural weight below the plane (this will cause center of mass not to line up with center of thrust, causing a nose-down force).

Your bump reminded me that I had not returned to post regarding this mod working in .23. It does. Not this mod's fault, but any attempt I've made to do VTOL with jet engines just ends in tears. If the mod handled the spool up time of jets, just maybe I could make one work by compensating for my bad piloting, but more likely it's my designs that are flawed.

One way to help prevent engines from compressing a light load (and also from spazzing horizontally under a heavy load) is to run a few strut connectors directly to the engine from other parts. If you need somewhere to start the strut from, throw some cube struts just above the engine and connect lines from them to the engine. You can use this trick to "stitch" other segments of the stack together as well if you find their connections too weak. Throw those cube struts on the big SAS (a known, squishy part), and connect strut lines between the cubes and the segments above and below for sturdier connections.

I like pretty much everything suggested in this thread (except the thermometer reading minigame). I would love for rovers to gain more usefulness. Their advantage over other types of vehicles is actually pretty significant: Their electric-powered wheels can run forever with RTGs or Solar panels and consume no fuel. 2 things hurt the rover and prevent us from taking advantage of it: -Comparatively slow travel - If it didn't take so much real time (albeit time acceleration helps) to get places with a rover, we would use them way more. See @Capt Snuggler's link above for more discussion. -Nowhere to go - Well, we do have multiple biomes to visit, but having more (and more densely clustered) areas of interest would incentivize the use of rovers. Not necessarily smaller biomes or easter eggs but perhaps smaller anomalous targets that provide some reward (science or otherwise) for investigating or setting up an experiment package. As for the other things suggested (that would benefit all types of missions!): -Tank Treads - Awesome. -Car Steering - Actually, you can get proper car steering by disabling your rear wheels' steering and optionally disabling the front wheels' motors; I think it can be done in the VAB/SPH now with tweakables, but you can definitely right-click in flight. -Sample drill - I have done mockup probe sample collection missions (before science was added, even) and would love this. -Hull Camera - I have used the hull camera mod to great effect and would love a stock version:

This is just plain fun. I would love to see personnel files for our Kerbs. Resume, mission log, achievements, statistics, etc. There's a lot of potential here for adding flavor to the game, as well as a groundwork for accessing any RPG elements that may be added in the future.

As noted, this is possible in the game currently with a little fidangle. Removing that extra busy work of exit pod/grab science/reenter pod would be nice, though. What could be asked for is that all experiments immediately place their results in the command pod "data folder" after being run (automatically stacking inside as a side effect) rather than keeping them in the part that generated them. This gets complicated, though, since a vessel with only a probe core could not carry data, and vessels with multiple command pods would need a way to select which pod gets the data. It spoils the fun of having a kerbal interact with the science parts to move data around but removes some of the busy work, so... Neutral change, I think. I don't know if it's a great suggestion, but I think it's the next logical step to thinking out a solution to the problem laid out in the original post. Solves the problem and makes more aspects of science collection (potentially) easier to manage.

Free antivirus options are more than enough for most users (Microsoft Security Essentials gets a bad rep, but is pretty sufficient and lightweight), but if it's a corporate level machine (provided by employer), or you legitimately use it for sensitive business work (for example, I routinely have copies of customer databases containing financial details and personal contact information on my machine), it's wise to use the paid services. I personally would choose Kaspersky over Norton for a single computer, but that's just opinion based on feeling that Norton takes too much control over the computer while Kaspersky provides some pretty awesome tools for free: http://www.kaspersky.com/virus-removal-tools For company-wide protection, I'd say Norton is the standard, but I'm not an expert in network security. I've just seen the majority of businesses I work with using it.

I AGREE, hopefully there is some improvement to this. I may be somewhat OCD, but it always bothered me that the starting point of struts and fuel lines can be snapped to angle but the end points can't.

I don't see a downside to this except for changing the behavior of right-clicking parts in the list (which currently explodes/minimizes the part details). Nice idea.

If some stock parts were revamped to include some dim light sources, I think the problem would be partially solved without needing to remember additional parts (although some "mood lighting" sources would be nice to have). For example: the windows on the pods could have some backlighting to them representing the light from inside, docking ports could have a soft white glow around their base, probes could get some steady and/or blinking lights... Could be some others, but it's a trick not to overdo it (wouldn't want every wing and fuel tank lit up like christmas trees).

It sounds like you've nailed it, and just don't realize it! If at any point you're under 5 km away, and you've zeroed relative velocity (or at least less than around 10 m/s), you're basically done using the map view; switch camera and move it to see both vessels at that point. Maybe you whizzed by a little and are farther than your closest predicted point, but now you are effectively close enough to ignore the orbits and move like you are in empty space. At this point, you should Point toward target prograde and burn until you are approaching at some speed (20-40 m/s was a good estimate given earlier), then watch as you get closer. If you ever seem to be moving away instead of closer again, you can zero your velocity again (burn target retro until close to 0 m/s), then repeat pointing to target and burning. Once you're happy with how close you are (100 meters?), zero velocity again and enjoy floating next to your target. You might be finding yourself heavy on the throttle and are overdoing your speed if you keep overshooting. Try burning only a little and time warping until you are closer rather than increasing your speed to close the distance faster. This way, it is easier to kill your velocity when you need to.

That is one lovely whale of an SSTO you've got there! Difficult to turn, I imagine?

If you're interested in figuring out good departure dates, travel times, and sub-optimal (but still within dV budget) launch windows, the charts plotted with this tool are amazing: http://alexmoon.github.io/ksp/

I don't think the science system is overly grindy right now (could maybe be improved still, but not broken). I'd wager, many people are simply getting bored of collecting science, since it seems like the only thing to do in career mode, right now. The rest of the grinding complaints, I feel, come from trying too hard to get all science from individual biomes before moving on. Currently, filling out the whole tech tree does not require sucking each biome dry. I don't have the numbers in front of me, but there is way more potential science around the Kerbol system then the total needed to complete the tech tree. You're probably most efficient if you only do 1 mission to each biome since each mission is bringing back the maximum points per trip. Once you've exhausted all options for a first mission, then start revisiting. My point is, if you find it grindy right now, it's maybe because you're collecting from one biome at a time and that biome is exponentially decreasing in value each time you visit. The first 50% or so science points can be collected in just 2 missions, whereas to get the rest will take at least 4 more. I need to run the numbers to back this up, but you can see that those 4 missions are better spent visiting 2 new biomes than squeezing the first. If you want to make it your goal to collect ALL science from each biome, that's fine too, but realize going into it that it takes a lot of time and is unnecessary. Regarding the science lab: I feel its bonus to transmission is just that: a bonus. It's not a game changer for transmitting data home, just nets you a few extra points. The reseting of experiments is the real purpose of the lab, and it allows for reusable science vessels where otherwise you'd have to launch brand new missions. It's a mission extender, allowing your science gathering to be more efficiently done when planned well. It's definitely not a necessity though, and could be argued as a weak addition to the parts list, though that's not my opinion.

Kethane, to me, is a grey area. If implemented as-is (a way to refuel in-situation) as a stock feature, It wouldn't change the game fundamentally, only adding to existing features (good); but on the flipside, I feel it's a feature that would not be universally used by all players (not as good). Why: It's frankly a pain in the neck to set up Kethane supply lines when you have the alternative of just bringing more fuel (either on the same ship or via refuelers). Interestingly, this may change completely when career mode involves budgets... Free fuel just sitting around on Minmus becomes very attractive when you're paying a premium to fuel your rocket. KAS is a little better. It doesn't change what a player will be doing, but gives new, attractive options for how to do them. It's only downside, in my opinion, is its complexity: Containers for parts, EVA grabbing and placing parts, winches with multiple attachments, connectors, EVA place-able pipes and struts. Essentially, KAS would need to be broken down into separate features and those individual features weighed for their "stock-fitness". Though I admit, even as-is, I wouldn't mind it being stock and made bug-free. I was about to go way off topic talking about predatory DLC vs fair DLC, the increasing cost of making games contrasting the decreasing prices offered to consumers, and the complication of companies and consumers doing business in the wake of an economic recession... Instead, I'll just say, do your research, follow your conscience, only pay when you know it's a good deal, and when you do really like something, pay for it, even if it's in the form of DLC. It's not always the devil.

Good to know for this incident, but it's still dangerously close to being a snuff film, IMO. On topic, I'd say this feature as a new failure type isn't high priority, but intake blockage (by other parts on the same ship) could change the way our aircraft are designed in a similar way to how we currently avoid blocking our engines. This could limit intake spam and part-clipping intakes. (I realize there are aesthetic arguments to be made for part-clipping, though, so there's some discussion to be had.) Maybe this needs a separate suggestion thread? I bet it's already been suggested as a part of improved aerodynamics...

Not so happy after watching the video used for demonstration. I agree with Sirrobert that there shouldn't be a random element to this but the idea of intakes sucking in objects in front of them has potential for new kinds of failure (fun). Plus, the blocking of intakes by other parts would be a realistic engineering concern.

I think it's better than "just ok" out of the box right now, but that's just opinion. Some mods lend themselves better than others to being stock implementation, either because they are in line with what Squad has said they want to do anyway or because they add to the game without fundamentally changing HOW it is played: -FAR brings aerodynamics up to a more realistic implementation -Deadly Reentry implements reentry effects -KMP allows multiplayer -Crew Manifest allows Kerbals to transfer easily between docked vessels without EVA. Other mods add tools or requirements which can make the game experience very different. These cause the game to be more/less challenging and potentially involve features that players will not universally use: -Kerbal Engineer and other stat-displaying mods. -MechJeb and autopilots -KOS programming -RemoteTech There's a LOT of grey area, and any individual mod could be discussed heavily on it's merits/drawbacks of becoming a stock feature. In one of the recent interviews, Harvester said that he has not spent much time playing with mods. Still, I wouldn't put it past them to get inspiration from good ideas. The majority of the KSPX parts pack did get added to the stock parts list, for example, and I've heard that the spaceplane hanger itself only came about after C7 put together the existing spaceplane parts and the devs made spaceplanes a part of KSP (after not including them in the scope of the game, originally). Out of curiosity, what makes you think Squad might not be adding more core functionality? They are in the midst of making career mode and will very likely be including new objectives, parts, and interesting things to do as a part of it.

I very much approve of this challenge. Wish I had more free time!

@EvilotionCR2: Aww, no hate. If they slack, you can complain all you want. People may not listen, or be happy about it, but no harm done. It's valid we want more tangible stuff: planets, sounds, art, stuff to do. And modders have done an outstanding job providing these toys. They're on the fringes, spending free time to experiment and focusing on their specific niches. Squad is kind of outshined by the modders. There are TONS of amazing developments coming from the community, and it's awesome! I don't see this is as a strike against Squad, either. I believe it shows that the time they could have spent implementing a few features themselves was instead spent making sure players can play the game any way they want. In short, modders get to code just their fun features, while Squad is responsible for ALL features that are, or can ever possibly be, in the game and making sure it doesn't crash. The fun stock features will come, but they're interspersed with working on the plumbing, which isn't glamorous at all.

Hope you find it useful! Let me know if you come across any mod part in particular that fails to show (either in app or in game). I've tested stock parts, KAS parts, and RemoteTech parts, but haven't taken the plunge to test the big part packs, yet. Everything SHOULD work at this point, but you never know when something exotic will pop up (like some stock parts still referencing .DAE files even though they're actually using model.mu files... )

Allowing us to change the conics drawing mode in game would work with this. There is currently a config edit you can do to change how orbits are displayed such that they show your trajectory where the planet currently is. Would be great if using the change you suggest, the game would automatically switch to this localized trajectory view. (I personally have not changed my config for this, but there are mods like preciseNode that make it available in game via button clicks)

The mountains near KSC are pretty jagged. I have not landed on them with a plane yet. I managed to find a nice upward slope in these mountains near Kerbin's north pole, though (sorry for zoom out): Allowed me to get a neat shot of Jeb atop the peak:

I don't want to feed any fires, but I would like to summarize the grey area between the black and white sides of this discussion. I tend towards regarding Squad as a pretty good developer overall, but as you can see by my TL/DR, there's nothing to say you can't complain if you don't like their development style's consequences. Development IS slow - Squad's team is small and personal. An art guy, a handful of coders, and a handful of QA's. They wont grow in any large way in the foreseeable future. This means we get the 3-month cycles we currently have (arguably a long time). On the flipside, this is a fairly efficient team size and structure, which shows in the relatively bug-free releases. As teams grow in size, they become disjointed and do not work as efficiently, so there is an upside to the slower, smaller team. They also happen to be VERY deliberate in their design process, so they add very few new features to the game at a time. They ARE focusing on Early-game (for now) - It is true that it would benefit Squad to attract new players, and a progression-based career mode helps. Keep in mind though, that career mode was a planned feature from the start. They didn't decide out-of-the-blue to implement it because they wanted to drive new sales. They needed to work on this feature sometime, and for it to be all it can be, it requires a large commitment of time and effort. Simply, they can't work on much else until it is finished. (Again, slow, small team development). They've said numerous times that their features wishlist is gigantic, and that they want to do as much as they can. Harvester has also said that resource mining in it's previous form is not happening, but that it may turn up again in a better way when they come back to focus on wider features again. Lack of deadlines - They don't know what they'll be working on 3 or more updates down the line, or how long those updates will take, or when to expect it all to be done. They work in cycles, wherein they decide what is going to be added to the game in each cycle as it comes. It's very haphazard. The tradeoff is that Squad is more flexible and does not need to adhere to a list of "Must haves", instead focusing on what they feel is the best thing to work on at that time. This mostly is a benefit for things that don't work out (Resources), since they're not locked into using a feature that can't be done elegantly. TL/DR -Small, slow team makes less-buggy releases, slower. Not much to be done... -Career mode needs to be done sometime. Now seems good... -Roadmaps? Where we're going, we don't need roadmaps...

Hello! I'm relatively younger: only been playing since .19 (I think May? Wow, it's been longer than I thought!). It's great that KSP allows you to play however you want. I've changed my playstyle with every save. Sometimes I've gone heavy with mod parts, other times I've focused on mission planning with life support and RemoteTech, and recently, I went stock with just helper plugins. Lots of great ways to play. I haven't done the FAR/Deadly Reentry/Real Solar System combo yet... Maybe next game.