Stoney3K

The reason I usually skip those missions is because they tend to pop up at the other side of the planet, and I really don't feel like spending an hour to cruise towards my target location on a pair of Junos (basically do nothing but fly forward and stare at the screen) just to do a temperature reading. And fly the entire part BACK again, even though those missions may be cheap to do, they waste too much of my time. Trying to hit the spot from orbit will usually work, but that is limited to a certain altitude/speed combination if you want the mission to have any payoff.

It depends a lot on your ship's mass and the amount of reaction wheels / RCS thrusters that are on the craft. Part of the problem is that the reaction wheels and RCS are always running flat out, no matter what distance they are from the CoM of the craft, which causes the outer part of the craft to move more when compared to the inner parts of the craft. This is also what causes the craft wobble and flex (which is especially noticeable when you have a station). Depending on the location of your control unit, this causes a feedback in the SAS control loop which in turn causes oscillation. SAS needs to be fixed in a future version, as @ibanix said, MechJeb's Smart A.S.S. can usually track a target marker or maneuver node just fine. For starters, the reaction wheel torque and RCS thruster strength should be proportional to the part's distance relative to CoM.

Because the SAS action is usually too much to hold the exact point where you want it to go. That's not limited to the 'Target' setting, the same thing happens with prograde, retrograde, normal and radial settings, to a certain degree. You can notice it most when you're re-entering and you have SAS set to retrograde -- it will jiggle, wobble and drift all over the place while it stays perfectly stable using the 'Stability Assist' setting. I do believe it's caused by some minor bugs in the SAS code that cause the control loop to overshoot if you want it to track something.

At least give us the option of a taller steerable gear set so we don't have planes that plow the nose into the runway when speeding up for takeoff. The alternative is to have the medium gear and have it dangling 3 feet under your plane using struts, which is just ugly.

The way you describe it can already be accomplished through KAS. You can send containers full of rocket parts to offworld locations where they can be unloaded and assembled, piece by piece, by the Kerbals on site.

Exactly that: Don't rely on experimental parts to accomplish a mission. I kind of like the proposed dynamic: It gives players an incentive to do the (otherwise) boring, grindy test contracts because they get a chance to "earn" new parts for free or for a bargain price, without having to do all the science to get them. I'd like to add some test conditions, like not just "staging" an experimental engine to complete a contract, but have it run for X seconds and require an attached antenna, so the test crew can get reliable telemetry from the test. Recovering of a test part to complete the contract is not always a good idea, how are you supposed to recover a part that you just flung into an escape trajectory from the Sun? It would also discourage players from using that experimental part outside of the testing mission because it is prone to failing.

The only issues I had with gears were with the smaller (tiny steerable, small retractable, medium retractable) gears. These seemed to poof out when doing a take-off roll above 70m/s with hardly any weight on them. This may have been because of traction control, but the wheel stress meter kept reading zero while instantly going to 'overstressed' when going too fast. It's not something that is impossible to work with, though. The stress tolerance balancing has already been mentioned -- what could still use some attention is the size ratio between the medium and large gears. The medium gears are the largest steerable gears available, but the landing strut length of the smallest "large" gear is a LOT longer. So it you attach the medium gear as a nose gear while using a large set of gears as main body gears, it means your aircraft will have a ridiculous nose-down stance on the runway (which will ultimately cause extra stress on the nose gear). The only solution is to mount the body gears higher up on the fuselage to make them level with the nose gear, but that would mean raising the wings, which is not always desirable. When using the huge gear, the medium nose gear is absolutely dwarfed. But using a medium gear for the nose gear is inevitable since that's the largest gear available which has steering.

There is some different logic which determines if an orbit is "stable" (not hitting anything on the surface) if the craft is on rails. I believe the minimum altitude (ASL) for checking if a craft didn't smash into the surface when it's on rails is higher than when the craft is focused. Also, there may be some crazy stuff going on when you're using RSS, since RSS re-purposes the existing bodies in the Kerbol system to act differently.

That being my point exactly. AFAIK the crash/heat tolerance for a cargo bay and an Mk2 fuel tank are the same, as well as the body lift. If you close the bay doors during flight (which I did not do for the picture just to make it clear that it's a cargo bay) all parts are protected from heat and drag. You pay a small dry mass penalty for cramming twice the amount of fuel in the exact same space as a standard tank (without any tank clipping involved), leading to a craft that is a lot more compact (or a craft that has significantly more range for the same size).

The point is, you can cram double the amount of fuel tanks inside an Mk2 cargo bay and still have room to spare for some small auxilliary systems. Or have the same amount of fuel inside your cargo bay, and still have room for your payload in between. The cross section (area) of an Mk2 fuselage is just about twice that of a single 1,25m circular stack, so you would expect the fuel capacity to be double that, because its volume is also twice as large. In the situation as depicted above, the Mk2 rocket fuselage has the same fuel capacity as a single FL-T400 fuel tank. I suppose the rest is wasted, empty space? I can understand it having 1,5x or 1,75x the fuel capacity of its 1,25m counterpart (due to added structural bits and bobs), but this feels a bit too easy to exploit.

Here's two setups of Mk2 space plane parts, each taking up the same amount of space: Which one do you think contains the most fuel? (All tanks are full. The cargo bay holds a total of 10 Oscar-B fuel tanks) Is this a conscious gameplay decision by SQUAD, or was it just overlooked?

Not 100% true, that will only happen if the part is connected somewhere in the stack from the root part. Radially-attached tanks, for example, don't always get drained while tanks on the main fuselage do. For example, the tanks that make up the upper deck of the 747 are somehow attached radially to the main fuselage. You could add some fuel pipes next to the struts to make the tanks feed into the main fuselage and supply the engines.

This is especially useful if you're building a station since you don't want to re-orient it every time a visiting craft wants to dock. MechJeb's Smart ASS can re-adjust the orientation of a ship if it is in physics range, but the stock SAS can't control any craft except the active vessel.

If the standard docking port is large enough to squeeze Kerbals through between modules, it can definitely dock with the vacuum of space.

Thanks, I can start with that, but my point was primarily that the documentation for modding KSP is definitely lacking. There used to be a wiki with some information but that is grossly outdated.

I believe that in previous versions there was no option of returning to the space center when in the atmosphere or when "about to crash". I have not tried that in 1.1.2, but when going to the space center, it means the active vessel goes on rails, and the simulation logic will delete it when it goes below a certain altitude (I believe that's 40km for Kerbin, and zero for airless bodies) to simulate re-entry. That's why you can 'cheat' if you flunk a re-entry which would only burn the craft up but it has a periapsis above 40km.

The way I see it, debris (and flags!) should be targetable if you use them as marker beacons, but not 'switchable to' by default. The same would be true for map view, where you could target debris but not switch to it (unless you explicitly want to, like in your second scenario). I lost count of how many times I missed my target vessel for rendezvous because I could only click on the debris (a decoupler) that was floating right next to it. I would DEFINITELY be in favor of implementing [MOD]+[ or [MOD]+] to tell the game you explicitly want to switch to debris and flags, and ignore them in the switching logic otherwise. Agreed, in cases where switching to another vessel would result in immediate destruction of the active vessel, the user should be presented with a popup asking "Warning: You are in the atmosphere. Switching to a different vessel will cause the current vessel to terminate immediately, killing all crew on board." (Cancel) or (I know what I'm doing , proceed anyway!) That would also eliminate the "cannot switch vessels while under acceleration" under certain cases which would just slam the vessel on rails and continue the burn from there, if the physics engine allows it. Would be a great solution for ion craft. An explicit 'self-destruct' button next to the abort (or opposite it) would also be in the spirit of being Kerbal. Covered by a red-yellow button cover, you can click it (twice to confirm), it becomes active, and a 10-second countdown starts, after which the entire ship would explode in a big mess of parts blowing themselves all over the place. That would be a great way of getting rid of satellites that have no means of control or do not have any purpose except your current flight (which you just completed), so you would not need to go back to the Space Center and clean them up from there, but instead, just enjoy the fireworks.

I'd say 10% config files, and out of those 10%, it's about 99,9% trying to figure out what the hell all those config directives actually do. I have yet to find any up-to-date documentation on the part.cfg files and their directives. How do you define an Isp curve for an atmospheric engine? How do you set a drag model appropriately? The only reference there is is by replicating existing part files and editing them. For example, I want to make a jet engine that can be used as an inline VTOL lifter for Mk2 form factors, with about 250kN of stationary thrust (on afterburner) that falls of rapidly at higher speeds, and has the same characteristics as the Panther otherwise. But I have absolutely no clue where to start to accomplish that.

Alternatively, if the medium gear are just Too Damn Huge (tm), try doubling up on the main gear by just adding another set. Keep them close to the CoM (but behind the center of lift) so the nose gear won't get overloaded. There is a Stress Tolerance number in the part description which shows how much force your gear can take. Divide the sum of all gears by 10 and it should be more than your plane's weight. Also, try tweaking the spring and damper settings and overriding the friction control.

I would support this. Crew management is definitely an important part of your space program, and it would also give the Astronaut Complex more meaning beyond spending funds on purchasing as much expendable Kerbals as possible. The exploityness could be balanced by having a multiplier for certain bodies and a maximum XP that a Kerbal can achieve within a certain SOI, much like the science system is set up now. Sure, you can tell Bill to swap a few tires and repack some chutes on the runway, but once he has done that on the runway ONCE, his 'tire swapping and chute packing' XP on the surface of Kerbin is done. Similarly, Jeb would have a maximum of flight time that would gain him XP in a certain SOI, and Bob would only gain so many XP from each science point that was collected by a flight with him on board. Not so fast there. The ISS's water, waste and oxygen systems are completely closed cycle. The only resupply required is the astronauts' food, as well as some small amounts of water and other chemicals that are lost due to leakage. ISS is even looking into growing their own food crops in space.

It puzzles me why we even have the ability to switch to debris altogether. Debris are, by definition, not flyable ships and considered destroyed and/or uncontrollable. So why allow them to become the active vessel in the first place? Giving the user a choice to at least disable switching to debris when scrolling through ships nearby would already make a lot of difference.

A good "stockalike" suggestion for those would be a 3,75m series of parts which are half-cylindrical? Much like a scaled up Hitchhiker that is sawed in half so it has a flat base to which you can attach feet, a sky crane or a landing engine, and stick it to a central spine-like structure for launch. Such a part could have 1,25m attachment nodes at either end to stick on stuff like airlocks or docking ports.

That's absolutely no good if the wheel's parent part (e.g. the wheel well is underneath a cambered wing) is not rotated on an angle snap point. If you use the angle snap, you'll always rotate past alignment in either direction, if you don't, there's a good chance you're a fraction of a degree off. Even if the gizmo is in absolute mode, the snap is still relative to the part's current orientation.

I really like that idea. Especially when you combine it with a storyline-like "strategy" system so the game knows what you're aiming for, e.g. your first flight to the Mun or your first interplanetary mission to Duna. Once one of those strategies is active and you zoom out to the map view, you get a Werner popping up to say "Ah, I see you're trying your first hop out of Kerbin orbit. Let me tell you all about the Hohmann Transfer maneuver". From there you can get onto KSPedia to read about it, maybe watch a tutorial video, or let Werner give you a few tips and some help to set up the maneuver node for the first time. The same would be possible with all other "first achievements" like docking two ships together, aerobraking or trying to land somewhere.

One thing I'm missing a lot in the KSP gameplay, which would really warrant research missions and more science-y behavior: Part failures and reliability, which introduces randomness and thinking on your feet mid-mission. For example: When you have an engine that you have never used before and you use it on a critical mission like a first flight towards the Mun, there's a considerable chance (e.g. 55% dependent on engine type) that the engine will either go kapoof on your landing burn, its gimbal locks up so you have only limited control, it starts leaking fuel when running, or its thrust suddenly drops dramatically. This is completely in style with Kerbals duct-taping their rockets together, which increases the chance of stuff randomly breaking because it was built in a dodgy manner, and it means the player would either need to install sensible back-up systems to catch any failures, have more run-time on the parts he wants to use (which increases their field use and therefore their reliability), use research points to buff the reliability of existing parts, or purchase more reliable, and heavier, more expensive parts from a different supplier. The most prominent moments we know in history of our own space program is when Something Went Wrong(tm). There are hardly any reports from the mundane launches of IntelliComSat 9242 which are launched almost every day. So why should these be interesting to a player?