natsirt721

I could care less where the other site is, I just want practice launching from a non-equatorial site. There's really no incentive to operate outside of the equatorial / ecliptic plane, seeing as how the launch site is there, the landing site is there, the equatorial keostationary belt is there, the Mun is there, and most of the planets are near there (Moho excluded). The old KSC would be a neat spot if only because it would require you to launch payloads to inclined orbits and work from there. Also, an oblique runway at KSC would be amazing. There's plenty of room for it!

IMO It's not hard to walk the keyboard, especially with fine controls on. That being said, given all the options we currently have available in the context menu it would make sense to have a steering limiter in there. If not a tweakable one limiter, perhaps a fixed system which reduces the slew rate as a function of the proportion of the vehicle's current speed to the wheel's maximum speed? The closer to the max rating the slower the wheel would turn. This would still allow you to flip at high speed if you held the button down, but would greatly increase the ability to perform smooth turns at higher velocity by 'walking' the button.

Agreed - something like this would be very CPU intensive. My solution to this is to build a robust network of relays around Kerbin - for the first extraplanetary missions you only have to look at the body you're orbiting (eg duna and ike) to see when you get blackout - on the surface it's even easier to watch when your orbiter is in your sky. That being said, from a realism standpoint, comms blackout is a critical thing to know when operating a remote vehicle. That would be simpler, but you can basically get that information just by looking - not in the finest detail but hey, KSP has never been known for exactness

Could you elaborate on this? I know a handful of other games which use the giant-text-file method (Paradox Interactive's EU3 for one) and I've not once had an issue with it. I can't really blame them for focusing work on the DLC - what's more important to a company: ensuring that their product meets satisfaction for each and every individual user or making money? That isn't to say they should sacrifice quality development for revenue generating schemes, but at the end of they day the devs need a paycheck. You've bought the game and you're probably still going to try to play it even with bugs, bugs which have no doubt been at least recognized and at most already fixed (but not implemented). Should they roll out a minor patch to fix them? Maybe, maybe not. The game is still playable after all. Can I blame them for not focusing on it? No, I can't. At the end of the day, SQUAD is the one who decides where development goes, not the community. Have a little patience.

After 1.0, there is not much incentive to continue development of core features - hence the 1.0 designation. DLC is a natural way to generate revenue from an old product and keep tweaking the core game - I don't think anyone can blame SQUAD for that. However, I wouldn't expect many, if any major new features from here on out. In this regard, it may seem like development has slowed. Would I like to see perpetual support for KSP? To a point. From what I've read about the limits of Unity, it seems to me as if a sequel based on some other technology would be more aligned with where I personally would like to see the game go. The DLC effectively gives SQUAD another product to sell to not only to maintain KSP, but possibly begin work on a sequel with more functionality (especially if T2 is bankrolling them). KSP was a good start, and I'm sure the devs learned a lot about what to do and what not to do, but pretty soon I think the time will come to move on and start something new from the ground up.

At the risk of stating the obvious, these contracts typically have a set of orbital parameters in which the probe must be in order for it to count. Are you certain you're in the right place?

For those who are willing to believe in the existence of Dres, you can reliably find asteroids in nearly circular orbits around it. The orbits are pretty regular so I'd expect that they generate there naturally rather than get captured - if this is the case than it should be trivial to add a similar feature to Jool, or any other planet really. I'd love to see trojan clusters too - not only for Jool but for Kerbin and other as well.

I don't think it does any sort of clipping asserting, it just check if there's anything too close by a very generous margin. I've had stuff significantly further away than clipping range from the runway spawn point and still had it prompt me to remove or abort. I think this is just something that has to left as-is, as it would be far more effort than it is worth to change for a few niche cases.

You can simply enter the Jool system in a retrograde hyperbolic trajectory and set up your encounter as you like - no slingshotting required. Starting from any of the big inner moons however, I don't think you could do a pure slingshot to Jool retrograde. At the very least you'd need a powered assist. Alternatively, slingshotting to a highly eccentric orbit and reversing direction at apo would be cheaper in terms of fuel (than a brute force approach), but would take significantly longer.

Damn, that was a long time ago.

I'm not sure if this is still possible, but IIRC in the older versions of KIS you could equip the small cubic cargo pod and then attach things to it from there. It's been a while since I tried it though, and the newer versions might not support it.

One of the major contributors to Kessler syndrome is that on-orbit collisions dramatically increase the amount of debris to interact with. Seeing as how collisions between vehicles can only occur while one of them is actively loaded, it seems unlikely to me that you could ever reach a critical mass of space debris necessary for this to seriously impact gameplay. You may get unlucky and get whacked a few times in LKO but the odds are pretty good that you're not going to have a serious problem.

Not exactly. Heat can still be transferred by radiation, not only by dedicated radiators but by passive radiation (blackbody radiation) according to the Stephan-Boltzmann law: Radiated power (W) from a body is the product of A - area (m2) e - emissivity (dimensionless value from 0-1 depending on the material of the body) sigma - the Stephan-Boltzmann constant, 5.67x10-8 W*m-2*K-4 T - temperature to the 4th power (K) Even a very cold body still radiates heat, just a very small amount. Halving the temperature reduces radiated power by a factor of 24=16 times! Conversely, doubling the temperature increases it by the same factor. For unmanned spacecraft with low-power electronics, heaters would likely be required to keep the bus above minimum temperature. However, for larger computers and crewed vessels radiators are actually necessary - all that heat would have nowhere to go and would accrue in the vehicle, eventually cooking your crew and electronics. Currently, the game sets the failure temperatures much higher than they ought to be. Obviously this is for balance purposes, and is probably a symptom of the fact that parts either exist or explode (with the exception of solar panels) with no grey area. Setting a lower thermal bound on parts would require a non-explosive failure mode - something that (IMHO) should be integrated anyway, but this begs the question; what happens when a part freezes or overheats? Chemical batteries would burst or rapidly discharge, and propellant tanks more violently so. Structural parts could be unaffected, or they could fail (frozen struts become brittle and crack, overtemp I-beams melt and shed their connected parts). Aerodynamic parts would be subject to the same constraints as structural parts, after all a wing is basically a plate with a convenient shape. Moving parts would have to be inoperable in extreme cold, if solely due to thermal expansion or contraction causing joints to seize (unless they're made of Invar or some other special alloy). Electronics would probably not survive ultra-low temperatures for more than a few hours or days, and would definitely not function over 400K or so without serious reinforcement. Motors - presumably fed by turbopumps i.e. moving parts would also require a minimum operating temperature. Crewed parts would require some sort of active heating, which would imply active cooling as well in the form of a TCS. On surface temperatures: while IRL planetary surfaces might provide a significant conductive heatsink, most landed objects in KSP don't rest on the ground, the stand above it on legs or wheels. These would provide very little by way of conduction due to their relatively small contact area, so it is safe to say that even implementing a 'realistic' surface conduction mechanic would have little effect on the thermodynamics of the spacecraft - it would likely radiate away most of its heat before conduction became a major player. Also, convection (referring to Duna's atmosphere necessitating heating) is already modeled AFAIK, but to what degree of accuracy I can't say. tl;dr I think more constrained thermal operating ranges is a neat feature, but complexity could rapidly scale out of control. In real spacecraft design, thermal management is a very complex and multi-faceted issue. The game as it stands has a pretty good balance and adding more complexity may get you more than you bargained for.

There's 2 levels of interaction here, and I think it's important to separate the two because they really are separate issues programming-wise. First, we have the large scale, which is how the atmosphere/ground/oceans interact with one another and the sun. Using the stratified cells and heat flux is good enough (I think?) to handle this at a planetary level, and the break-even line is determined by the size of the cells. Smaller cells == poorer performance. Events can be randomly generated - if not all the time then some of the time, maybe not at higher warps? - and the generated events (read:storms) would just propagate through the system requiring no other attention until eventually they dissipate into the 'default' weather. Alternatively, depending on the intricacy of the weather system, storms may spontaneously appear, propagate, and dissipate. Either way, variations from the norm require little extra effort on the simulation. Graphically, the natural or RNG storms would have to be blended into the surrounding clouds at a regional or planetary level, which is probably pretty hard. Then we have the small scale, which is how the weather interacts with your craft. This, I must say is where the real difficulties begin. The flight engine would have to look at the cell that the current craft is in and determine from the available data what sort of weather was going on. Then apply wind, rain, temperature, etc. to make the magic happen. Then, it also has to display these graphically. The current system is pretty adequate for handling static atmospheric conditions and the Microsoft FlightSim crew seems insistent that dynamic atmospheric conditions are no problem, but IMO the graphics are going to be the issue. The fancy clouds are already performance intensive, and unless some better way to display them is discovered (don't hold your breath) it is likely that and good-looking weather is going to be somewhat intensive. So to me, it seems like the limiting factor for weather is making it look good. Maybe if I ever get around to learning how to mod KSP I'll tackle this because it doesn't seem to be impossible, just pretty difficult.

Filtering by SOI would be a nice feature for sure, just as a QoL thing.

@MiffedStarfish That's a good workaround, but if you have multiple Kerbs on EVA that won't work. Yes, thats is what I said was the workaround. But, it is not the best strategy and fine controls would be quite nice.

I say 'zero relative velocity' but what I mean is 'stationary with respect to my ship'. When placing multiple parts it is frustrating to be floating around w/ respect to your ship, especially if you're near the max range of your box. With multi-ton modules, having 3 or 4 kerbals floating around with some non-zero velocity is a pain in the behind. Currently in stock there isn't much to do EVA, but if/when that gets changed the player should have some way of precise maneuvering. Therein lies the issue: the kerbal's RCS is too powerful, such that the shortest bursts still cause my velocity to overshoot the necessary correction (unless I'm KIS carrying something massive). Something that is mitigated with fine controls.

It seems silly to have fine precision for spacecraft RCS but not Kerbal RCS. I know personally it is difficult for me to exactly zero my velocity relative to my spacecraft when doing EVAs for KAS work (or harvesting science from parts), something that has led to me carrying ladders around everywhere.

I think the DLC is going to be huge for people with problems about motivation in KSP. Having access to a vast range of player-made mission options will allow you to pick some that sound interesting and actually have meaningful constraints. In addition, the default missions will set some baseline for what's possible which should include random failures, part constraints, mass and volume and time constraints, etc. in addition to specific rewards. For example, if I'm doing a series of flybys for the inner planets and the whole mission scheme only gives me n science, I'm going to have to budget that science very heavily - actually placing meaning on the oft-bashed points-tree system. I'm not sure if missions would be standalone or integrated into a common save but if they were standalone saves it would place a lot of emphasis on managing funds and science in a meaningful way.

Yeah that's probably the best option.

Probably not, as when changing orbits you rarely go from your current position to the closest point on the target orbit. Hohmann's need minimum 2 burns 180 degrees apart, which is just about as far away as you can get. Personally, I think that eyeballing it with the maneuver nodes is fine, especially given how generous the game can be in determining if your current orbit is close enough to the target.

I started playing KSP in late highschool and when I got to uni and had to take a class on orbital mechanics it was a breeze. There's a huge difference in the learning curve between 'doing the math and understanding what happens' versus 'actually doing it first and understanding the math later'

This would be a nice feature, however the targeting system currently requires a tangible body (spacecraft or a planet), and the orbit is just a path. In my experience, you can pretty easily match the target orbit by simply looking at where your trajectory is relative to the target and adjusting from there. Liberal use of maneuver nodes is recommended. If the contracts were modified to require a position (as a function of time, but a concrete position nonetheless) then you might be able to target a dummy spacecraft, but this seems a little excessive as far as precision goes.

In general, you are going to want less torque for fine-tuned attitude control such as a telescope requires. You can achieve that by reducing the wheel authority slider in the HECS's RMB menu. I would also recommend using fine controls mode (CAPSLOCK). You also may want to disable SAS altogether and manually train the scope, which should be easier with fine controls. If you are using the CactEye telescope, IIRC there are some high-precision gyros that you can use to really dial in on a distant target.

I recently created a spaceplane using the FAT-455 wings, but due to their low thermal tolerance I have to nail my reentry trajectory or the wings burn off. My question is, does increasing the amount of fuel in the wings increase the thermal mass and the amount of heat the wings can soak up before failure? Or is the thermal mass of the part only dependent on the dry mass of the part. The latter seems like it would be really incorrect but I'm not sure exactly how the thermal system handles it.