SkyRender

EDIT: It's advisable that you don't follow the link here, as the site that was found could well be a malware site. I was doing a random Google search today when I came across this thread on another forum. If it seems somewhat familiar, it's because it's the first five posts of this thread from our own forums, except with different user names. Does anyone have the slightest clue about... well, anything going on here?

My own terms are generally: Mohovian Evian Gillish Kerbin Munar Minmal Dunan Ikish Dresian Joolific Laythocentric Tyloptic Vallian Boppish Pollen Eeloosive Generally quite silly, in short.

Any mission involving the NASA parts is going to pay out absurdly well, because of their high price (which appears to be the main factor in deciding how valuable a contract's pay-out is). The only real problem is, you only ever get one contract for any given NASA part per save. As for those of you who can't seem to get rid of 1-star contracts, the trick is to actually complete some of your outstanding 2- and 3-star contracts. If you only ever go for high-value contracts and reject all the low-value ones, you're only ever going to find the list populated with low-value ones in the long run. This is because there are hard limits on how many active contracts you can have of a particular star rating. If your active contracts are all 2- and 3-star, the game can't generate any more potential 2- and 3-star missions and so you get nothing but 1-stars.

Given that you can legitimately max the tech tree and get absurdly high funding levels without ever leaving Kerbin's SOI no matter what you set the difficulty to, the LV-N is less critical than it could be. The most critical, of course, are science instruments (and the solar panels and science lab that you get on the way to unlocking all of them). After that, fuel lines and struts. Then docking ports. Maybe probes. Everything else is just icing on the cake. My ideal Mun mission requires no more unlocked than all science instruments (and solar panels; again, unaovidable on the way to those parts anyway), a lab, a probe core, fuel lines, and docking ports. It can pluck the science right off every single biome in all situations and basically max the remaining tech tree in that single mission as a result. And that's not even accounting for contracts, which are so broken at present that you just need an orbiting craft with a thermometer, solar panels, and an antenna to get infinite funds, reputation, and science (albeit in small doses).

I'd be quite happy to help with that, but of course I don't have the authorization to do so. A game like this that's in development and quite popular really does need at least one dedicated Wiki moderator and maintainer. It's a tedious job, but some people (myself included) actually enjoy that sort of bookkeeping work.

The main page of the Wiki was last updated shortly after 0.20.2 came out, a year and a half ago. That was before any Career mode features were implemented. As a result, it is glaringly outdated and needs an update. However, common Wiki editors cannot edit the main page; only those with admin privileges can do that. Would someone who has permission please update the main page so it has proper links to the Career Mode, Science, and Tech Tree pages? Those, if nothing else from recent updates, should definitely have main-page links.

My own take is this: Kerbals are actually pretty sharp little buggers. They know how to make a quality product and can make sure it never works outside design specifications (something even we can't manage in our own space programs, I might add). But... well, they're also very much enthusiastic about space and want to get there right away. This is why they don't even bother with designing space probes first, and start launching Kerbals right away into the great blue yonder. It fits perfectly with this mentality that, upon getting together enough funds to actually buy the "facilities" for a rocket launch, Jeb and crew would just buy up an old farm and retrofit it instead of taking the time and effort to build a complex setup. All that time and money being spent on nice-looking facilities would be time not going to space! So yes, in my eyes, this is pretty much exactly what the first KSC would look like: a hastily repurposed series of buildings that were never meant for this sort of thing but that will do well enough for the role. Heck, just read some of the early part descriptions and you'll realize that most of the early Kerbal space flight technology has its roots in repurposing things that were never meant for use in space.

This sort of thing is why Alt+F5 and Alt+F9 were made stock features so you can make multiple quicksaves per file. It's also a good reason not to play on Hard just yet, since quicksaves are kind of insurance against this sort of thing.

The Hitchhiker's Guide has extensive articles on Kerbal culture, actually. You can find them right over here.

I don't want that sort of thing either. That's why I want to make it comprehensive. Instafailure of parts doesn't even enter the equation until the quality's down to 28% with this particular formula, and part tolerances are unlikely to be exceeded unless you lower the quality to an extreme. I want it to give the player a wealth of options and proper risk/reward payout, not to punish the player by making it so their engine can explode just because they dropped the quality to 99%. EDIT: Just to highlight what this formula I've come up with does, let's take your 90% quality example. At 90% quality, parts will perform between 87.37% and 97.37% of stock capacity, depending on how it rolls. At worst, you'd be looking at slightly below standard-issue quality. With the ranges I have in mind, you'd have to do something really crazy to cause a part to undergo failure even worst-case like that. The distribution of the quality formula is specifically designed so that you can decide for yourself how much risk you want to take, instead of just putting an arbitrary "part fails 0.01% of the time regardless of circumstance". The entire idea of the mod is to actually give circumstance to failures in the form of tolerances (and give you the ability to make a reasonable estimate on how likely a part is to exceed those tolerances).

I've made some more refinement to the quality variance formula I came up with, which is currently as follows: N + ((1 - N) * rand()) - (1 / (1 + N)) + 0.5. N is a value between 0 and 1. This results in a very interesting distribution wherein the extremes between maximum and minimum values constantly rise as you drop N closer to 0 (hitting a 50% to -50% range at 0; it's a solid 100% to 100% "range" at 1, and 83.33% to 33.33% at 0.5, to name a few example values). The data points look something like an undone zipper when you plug it into a chart. I'm wondering if this formula can be refined any. Certainly it has all sorts of interesting potential use, though.

Using FAR, so I never risk more than 2-layered asparagus staging (ie. 2 sets of 2 side tanks). Even that can have some unwanted side-effects if the payload has an odd balance to it.

I've been toying about in Excel so far and came up with a fun little formula for quality that should give a very interesting range of possibilities. The randomizer gets more and more impact as the quality drops, to the point that below 25% quality you're getting into the territory of "fails immediately upon going to the launchpad" risk. The discounts get much more generous as you go too, starting out at barely noticeable rates of around 1%, a healthy 51% discount at 20% quality, and climbing up to 80.3% for a 10% quality item (which, incidentally, will almost certainly fail at launch and will only perform at around 30% of a 99%-quality item's capacity if you get obscenely lucky and get the best possible results for all numbers; fat chance of that). I really hope I can make this mod happen!

There's been a lot of discussion on the forums about part failures, particularly in light of recent events involving a failed real-world launch. I personally am against random part failures, which is why I think that if KSP is going to have any such feature, it should be a robust system that doesn't rely entirely on chance and circumstance to mess up the player's chances. I've composed a concept for such a system that would make parts much more interesting to play with while not sacrificing the current fun of the stock system. My main problem is, well, I don't really have the coding chops to write out the code for such a system... So that's why I'm here! I was hoping to recruit some coding talent to help me out with what I have in mind. I should warn you ahead of time that when I say "comprehensive", I am not kidding. Some of the subsystems involved include: quality, part lifespan, repair, analysis, failure states, damage, and tolerances. I am not willing to sacrifice the core functionality of any of these features to the RNG, either; while there will be some small RNG involvement in generating the initial parameter modifiers, everything will potentially be available to the player to uncover and work within the limits of. If you'd like to see the more in-depth document outlining the concepts I have in mind, you can read up on it here. Anyone who's interested in helping me out, just shoot me a PM and we'll work out the details.

I don't think you can really call anything the "greatest ever", if only for the fact that mankind is constantly trumping previous accomplishments. Maybe if you confine the list to a specific time period, but even then you'd need quantitative measures to have any sort of validity. All that aside, KSP is definitely my favorite game of all time at this moment in time, going by the qualitative measure that I've dedicated more time to it than any other game I own.

Polygon rips like that are all over every last body, and especially bad near the poles. It can't be helped, as the entire terrain generation system hinges on "circling the square" in 3D, "spherizing the cube". You always get errors when you do that, especially in the polar regions.

Indeed, NASA will not go to space today. Probably shouldn't have used so many boosters. Relatedly, I am so glad that random hardware failure is a feature that KSP will never feature in stock.

Yeah, having linear deductions and other such malarkey for a log-scale component like Reputation just plain does not work. It also renders any Reputation-to-X option completely and utterly valueless, since you'll have to basically spend all of your reputation to sacrifice all future reputation... which you will then be unable to recover because all reputation will be converted into something else. For science and funds, that's no big deal, but for reputation, the only way to get high-reputation-rewarding contracts... is to have high reputation. You get this "delightful" Catch-22 scenario as a result.

I suspect it's because your reputation is so low. Even the exploration contracts have minimum reputation requirements, they're just set to something really unlikely for a normal player to run into (-750 or -500, I think?).

Being on an AMD-centric system, the dreaded part lag starts hitting me fast and early, around the 200- to 300-part mark. It makes constructing anything interesting a bit of a challenge, to say the least.

It does work just fine. The only real point of note is that the pricing schemes are generally not adjusted to match other parts, particularly not for research cost (if you enable that feature, of course). Apparently there's a way to get Fine Print to even generate Kethane-related contracts for you, but I'm unclear on how.

"Ladder drift" is a long-running problem, actually. It can even happen on the surface of a celestial body (sometimes to absurd degrees; try landing on the north pole of the Mun and see how fast your Kerbal launches up the ladder he's ostensibly holding onto!). As for the EVA "blast-off" problem, there's two main causes. Cause #1 (which most people experience) is that Kerbals try to hold onto ladders based on their current camera orientation. If their positioning is not parallel to the hatch, they'll fling themselves around like ragdolls. This can happen even when getting out of the capsule, and is a good reason to keep your capsules oriented north-south when getting out of them. Cause #2 is having any sort of part which juts out over the top of the command pod. Even though it's not obstructing the hatch, it will cause your Kerbal to do some pretty crazy acrobatics (how crazy depending on how much headroom they've got getting out of their capsule).

I suppose part of the problem with a Kerbal's experience affecting craft performance is, well, the player's experience already does that. As you get better at performing tasks in KSP, you use less resources to do those tasks and get better results. Even though it makes perfect sense that Kerbals too would get better at them, the fact remains that the player is the one controlling the craft. Having them be able to make vessels suddenly get better ISP or thrust just by being inside of them doesn't really compute. Improving the control of the pitch/yaw/roll of the craft subtly based on the pilot, however, makes a bit more sense if we assume that the baseline control values listed are when you have an average pilot in the command seat. A skilled pilot genuinely can outperform an inexperienced one when it comes to maneuvering. I see no issue with Kerbals getting better science and reputation rewards from their experience. Both of those work out fine and even have real-world analogues. Some other possible things to cause experience to improve: repair speeds (once a delay on repairing things like rover wheels is implemented), speed of processing and cleaning experiments with science labs, EVA maneuverability (this would definitely have to be subtle!), and of course their Courage and Stupidity scores changing based on their experience would be nifty too. As well as the potential for a Kerbal to become a BadS after getting enough experience.

Gilly is a fun little space potato, it's true. Back in the days of 0.18, there was a challenge called the Bobcat Colonization Challenge, and Gilly was a particularly hard site to colonize. Not because it was especially difficult to get to or anything, but because it took an insane amount of patience and care to land there and not accidentally knock your colony structures over in the process.

So... Maybe I'm missing something, but how exactly do the Kethane bypass jets work? Because it seems like they just automatically flame out at 15KM on Kerbin no matter how fast you're actually going at the time, dropping instantly from 2.00 KIntakeAir to 0. No idea how they perform on Duna, Laythe, or Eve yet, but I suspect that similar shenanigans will be afoot. EDIT: Major shenanigans, as it transpires! The Zero-Bypass Turbine can only get up to 450m/s or so no matter what the atmosphere using FAR, it would seem. To the point that you get the nonsensical case of the intake getting less air as you travel faster at level altitude! I also discovered, testing them on Eve, that if the engine flames out, it never comes back online. Ever. I was 3 atmospheres deep on the fall back to the surface of Eve and the KIntakeAir remained at 0 despite this. I don't know how much of this is FAR and Kethane not getting along and how much it is the ZBT having major issues, but I suspect there's a mix of both going on here. EDIT 2: So I read some of the back-posts in the topic and discovered that this is how the ZBT is "supposed" to work because of balance issues, and that Majir is open to suggestions for other ways to balance out the Kethane jet engine. I have a suggestion: just make it burn exponentially more Kethane the thinner the atmosphere gets to make up for the ever-decreasing atmospheric pressure. In fact, you could make it a full-on Kethane-burning engine this way by having it be able to even fly in a vacuum, but giving it an ISP in-vacuum that's undesirable (say the equivalent of a 200 ISP engine that uses LFO?). The ISP would be considerably better the thicker the atmosphere is. That would not only make it a much better choice for a low-atmosphere engine, but it would give you a means of getting to space on Kethane alone (albeit a far-from-ideal one).