Murph

Possibly slightly stronger than I would have preferred. I should have spent longer reviewing my words. Do note, however, that I said "There's actually nothing wrong with cheating…". The remainder is to explain how/why I simultaneously see real world cheating as bad, and virtual world cheating as perfectly acceptable. That goes to the root of the issue, that people are either afraid of the word "cheat" or see it as automatically a negative thing. It is not a negative thing at all, only denying it is negative. The context makes a vast difference, between real world, competitive multi player, non-competitive sandbox games like KSP, etc. The message is intended to also say "embrace your cheating, be proud of it, it's nothing to be ashamed of". N.B. I am not singling out any individual. Opinions and philosophy on the matter may legitimately vary. Yes. No, it's not possible right now, at least not in stock. The experiment results UI is really the problem, it's no longer fit for purpose in the new context of labs taking possibly game years to get through their work. Hopefully Squad can see the issue, and the complete UI rewrite in 1.1 for Unity 5 will improve it significantly. In a nutshell, the problem is a mix of the slow rate of the lab research combined with the reasonable expectation to have something like an orbital lab which processes experiments from that orbit and the surface below, before the experiments are returned to Kerbin. There's just no way to extract already processed experiment results for return to Kerbin. It's also impossible to actually properly see what you've got stored there, once there's more than about 10 results, as it's too difficult a memory exercise while paging through them to answer questions such as "which biome(s) is/are missing?" or "how much unprocessed science do I have left?". We strongly need a list type UI that lets us see at a glance the complete set of experiment results stored there, with indicators for which have been processed, which have return-to-Kerbin science available, which have transmit science available, etc. That list type UI would be the obvious thing for "take individual result", "take all processed results", "take all results with return value", "transmit all results with transmit value", etc.

Totally, completely, entirely, absolutely 100% wrong. It's entirely possible to cheat, as the game makes absolutely zero effort to actively prevent cheating, which is the correct implementation for this type of game. The game does enforce certain things, but that is never primarily to prevent cheating, it is all about making the game mechanics work for those who are not actively seeking to cheat. It is entirely your responsibility to avoid cheating if you want to honestly claim that anything you have done is "no cheats involved". There's actually nothing wrong with cheating in this type of game. There is absolutely no competitive element, no reward (other than satisfaction), no advantage gained. Cheating in the real world is wrong and dishonest most of the time, and very often shows poor ethical and moral character traits. Cheating in virtual worlds, where you are gaining nothing of substance from another participant in the virtual world, it's neither ethically or morally wrong, but it is still cheating. Cheating in a virtual world, then denying that you have cheated, that is either delusional or dishonest (and if it's dishonest, then it's basically as bad in terms of character flaws as cheating in the real world, as the dishonesty is in the real world and not in the virtual world). I am proud to say that I routinely cheat in all games of this type, when I feel like it. I always openly admit when I have cheated, which entirely satisfies my morals and ethics. I reckon that probably more than 90% of people playing this game probably cheat on a regular basis (the nature and extent will vary), and there is absolutely nothing wrong with that (just don't ever deny it). Equally, I enforce rules on myself and avoid cheats when I want to actually enjoy the feeling of satisfaction from having truly achieved something. Even when enforcing rules, there can still be entirely acceptable cheats (which are still cheats, despite being quite acceptable), such as to deal with broken or flawed game mechanics. There are grey areas on the boundary between cheating and not cheating, but many other things are clearly cheating or clearly not cheating.

I agree entirely. Just because something is possible does not mean that it isn't cheating. Widespread use of the klaw, in ways that are clearly not intended, is clearly cheating. Cheat if you want to, however, cheating isn't actually wrong in a single player, non-competitive, open ended sandbox game. Denying that it is cheating, on the other hand, that's either/both delusional and wrong. In this type of game, it is not the game's responsibility to prevent you from cheating, or even make it difficult to cheat; it is entirely the player's responsibility to avoid cheating if they want to honestly claim that they achieved something without the use of cheats. The simple test for me, is that if it's completely unrealistic, or using parts in highly unreasonable ways, then it's clearly cheating (and using the klaw for anything other than debris and asteroids is both unrealistic and unreasonable, with very few exceptions, although exceptions to that are possible). Any attempt by Squad to prevent cheating, other than as an incidental thing that happens as part of fixing real bugs or enhancing intended functionality, would be a very bad thing for the game, as the lack of restrictions are a major positive feature. If you use the klaw because docking ports are "too hard", or you're too lazy to do it right, I'll always view 100% of your progress/achievements/success while using it in that way as fundamentally devalued, or even worthless and invalid. Incidentally, docking ports really are not that hard at all, even with just stock controls and indicators, as long as you go slow during docking and have RCS available. If you want "hard" docking, try docking a 2.5m lander onto a station with 0 RCS fuel and just the single main Poodle on the back of it.

Yup, that's a fundamental part of the NERVA design. The fuel cools the reactor, and the thermal energy gained by the fuel gets translated into useful thrust. I'm not suggesting that it should be "cold", but the current heat levels are really quite absurd, and you end up needing more wings on the upper/interplanetary stage of a rocket than a fairly big spaceplane. Even a Gigantor XL solar array can't keep a single LV-N cool on its own.

When it is docked, it is all one big craft, until part of it undocks again. So, it's the same rules as if you have 2 scientists in the lab, and one elsewhere in the station. I.e. yes, it's all scientists anywhere on the craft, including the docked bits.

A quick bit of research suggests to me that transforming a 1D into a 1D-Vac has exactly the type of issues I mentioned. Yes, they are similar and related engines. No, they are not fully parts compatible (although they have some common parts), and you don't just swap the bell to convert from one version to the other. Edit: Oh yeah, a thought on small radiators. I'm not saying that Squad's current model is perfect, but small radiators don't work in space (i.e. you can't reduce the size of your radiator), as they rely entirely on surface area pointed outwards, away from the vessel and any of its components. There is no air flow as used to enable heat transfer on inward facing surface area on terrestrial engine radiators. Or, let me put it another way, I think the LV-N is badly wrong, and it seems like it's the only engine which really needs a radiator right now. Its current behaviour in-game is totally at odds with the Los Alamos / NASA design, which was cooled by the fuel and did not require vast amounts of external thermal management. They need to fix the LV-N's configuration, not add radiators to the game â€â€.it shouldn't have any major thermal issues at all, as long as it's not pointing its exhaust at something or burning up in the atmosphere.

The model has completely changed. We updated the scale heights on the wiki, but they are now no longer high precision, and not accurate over the entire altitude range. The numbers on the wiki for "scale height' are probably as good as you will get, but are basically a quite rough approximation over the majority of the altitude range, and particularly inaccurate at the upper limit of the atmospheres. They are just a very rough approximation to the completely new model. At the very upper end, Squad's new model basically forces the pressure rapidly to zero (off the top of my head, that's somewhere around 62.5km upwards on Kerbin). The new model does not have a single equation from sea level to space. That Wikia article is from 2013, so completely out of date for KSP 1.0. The official KSP wiki's info on atmospheres on each celestial body's individual page should now be mostly up to date, I believe, thanks to some extensive work by one of the contributors (although I believe he's still working on it). Check the revision history on each page, and it should be quite obvious which articles have been heavily worked on over the last month. (The "Atmosphere" article on the KSP wiki is indeed outdated at present, as noted in the prominent notice at the top of the article.)

Nozzle type swapping is highly unrealistic, if it was to profoundly change the characteristic of the engine. Rocket engines are a complete integrated and matched system, with fuel flow passing through pipes integrated into the nozzle, as a coolant, and limited by the size of that integrated pipework, before flowing to turbo pumps and pre-combusion chambers which need to be closely matched to the nozzle. They are not mix and match from a parts catalogue, but extreme precision and high durability engineering. Small variations might be possible, but would not really be worth the effort to implement. You can re-engineer them, to produce a new derivative engine, such as the SSMEs (RS-25s) being re-engineered from re-usable to disposable (NASA's work to turn Shuttle tech into SLS tech, with a deep engineering design refresh of all components), with ultimately a significant reduction in cost, but that's really just a completely new engine which builds on the previous design and lessons learnt from it (i.e. it's not just swap out a few components ad-hoc, like fitting better carbs to a petrol engine). Radiator on a rocket engine? Sounds like an ashtray on a motorbike, or a chocolate teapot, to be honest! Much better and simpler to plug any significant gaps in the range of available parts, with new parts, and far more realistic.

Actually, that's exactly what we routinely do (add an "outdated" banner if we can't immediately fix it) for cases where there's a significant issue needing to be addressed. You can add the following to the top of a page which is in need of attention: {{Outdated| * Short but clear description of what's needing attention * Another point * Each line beginning with a '*' is a new bullet point * Use as many or as few bullet points as are needed, but try not to turn the notice into a long article in itself. }} N.B. If you're not used to editing a wiki, please always use "Show Preview" before saving any changed. Also, don't be afraid to ask for help at: http://wiki.kerbalspaceprogram.com/wiki/Kerbal_Space_Program_Wiki:Helpdesk If you want to audit the entire wiki for outdated information, please go right ahead and do so. Please don't add {{Outdated}} for trivial or unimportant things, or if you're not certain if a page really is outdated. Preferably only add it where you know with reasonable certainty that something is no longer accurate or complete. If you know the current information and could just correct the wiki as quickly as adding the notice, then just do that. Or, you can do both, e.g. I've been known to fix what I can immediately fix, but also add {{Outdated}} for the stuff I can't immediately fix. Do not add {{Outdated}} to "template" pages, unless you know how to do that without it actually being included in the template itself. For cases where you are not sure about something, or a page that is too complex for you to edit yourself, leave a message on the "talk" page (there's a "Discussion" link top left of every page, and every page has its own talk page). I can't speak for every volunteer editor, but I personally would prefer if you didn't leave a message saying only "is this up to date?" (and nothing else)  if you see a specific problem, please be specific in what you tell us, and it's much more likely to be fixed. If appropriate, you can both add {{Outdated}} with a summary of the problem to the main article, and leave a more detailed message on the talk page. As far as I'm aware, the basic stats on parts showing in the "infobox" on the top right of every part page have been automatically updated by a wikibot using the game's own .cfg files. The tables listing many similar parts with their stats are being steadily updated by volunteer efforts, as and when one of us looks at one of the tables and decides to update it. Edit: Also, that was me that added {{Outdated}} to "Tutorial: Walkthrough for Ye Compleat Beginner" mentioned in the first post of this thread. The article simply needs much more work than I was willing to do at the time (and I've never been motivated to return to it, as I've been working on other stuff).

Correct. In the very early stages of your flight, the horizontal component of your prograde is tiny, so that 174.5m/s horizontal east vector dwarfs it, and your achieved course will be mostly east despite heading directly north. As you gain speed, the achieved vector (the red one in the pic) starts to correct itself (but will still need some actual correction by putting a little of the dV slightly towards west of north, to fully cancel the starting 174.5 east). Even at orbital speed of a bit more than 2000m/s, that's just a little bit less than 9% of 2000, so significant overall unless corrected.

Oh, I think you misunderstood me, or I've misunderstood what was being implied by "bad". That was why I said "actually evil". I don't know which sites we're talking about, but I've seen sites related to other games which have scraped content (including the game's official intellectual properly) and were using the sites to conduct things such as: illegal activity, distribute very dubious installers (which might well include unwelcome malware/adware payload), sell "gold" in games where it's prohibited, phishing, etc. I certainly don't mean to suggest that fan sites should be stomped on, if they are not doing anything "actually evil", even if a portion of the community have some beef with them. And yes, unless each modder was to appoint Squad as an enforcement agent (and Squad actually wanted to be an enforcement agent), the mods are nothing to do with them and they can't get involved. Nuke the evil guys, if at all possible. Leave the fan sites alone, as long as they are not causing significant problems for Squad (other than possibly forum noise if someone gets grumpy with someone else).

Speed isn't the major problem. Stock 1.0.2 just doesn't allow tall and heavy 2.5m rockets properly, with quite low TWR (1.3-ish on pad, never rising above 2.0 while there's air to worry about, nowhere near going supersonic in the early stages of ascent). 3.75m, on the other hand, I find they are much better and are mostly ok with no struts on the 3.75s themselves, just to prevent boosters flexing and giving non-aligned thrust, and to prevent the payload wriggling like a caught worm. Squad need to stop buying Bend-o-Maticâ„¢ brand stack joints for 1.25m and 2.5m, and actually get something decent instead.

Yeah, not sure about the term, but something like that. Kerbin's rotation gives you a "free" 100–200m/s (can't remember just how much) velocity in an eastward direction, before you even leave the pad. In the early stages of the ascent, that's very significant in relation to the magnitude of your prograde vector. On anything other than east and west launches, you need to compensate for it with your heading (not a huge amount, just a little, correcting it over the full duration of your ascent thrust). I can't recommend a specific heading to correct to, as I personally just launch heading directly north or south, then eyeball the correction once established in stable flight. (And obviously it's helping you if you launch eastwards, and hurting you if you launch westwards, but won't change your course, just dV required to orbit.)

I'm certainly not advocating that Squad should throw huge resources at a lost or pointless effort. All I'm thinking is that they probably have legal representation either in house or on retainer (and I'm not one for arguing that lawyers need to be richer, but if you don't have that, Squad, you really should do to protect yourself and your great product). So, there's not necessarily any significant cost (or maybe even no cost if they already have in house counsel) to throw some entirely justified legal letters out against people possibly harming or taking unreasonable advantage of Squad & KSP's good names and intellectual property. Yes, it's important to evaluate the cost:benefit when deciding just how far to go down the legal road. The other side of it, however, is that you simply cannot afford not to protect a valuable trademark. The way the law works for trademarks is that if you don't defend them, you lose the rights. Copyright, on the other hand, doesn't need such an active protection, although knowingly ignoring an issue can potentially lead towards "tacit acceptance" and weaken any future case. The 3rd apex of the intellectual property triangle, patents, well they are just an unholy mess.

Sal, if there are actually evil sites out there, it might be worth you flagging them to Squad's legal people, to see if there's anything of interest to them. If they use any Squad intellectual property at all, it might be possible to get them nuked. E.g. any logos, trademarks, larger chunks of Squad-authored text (trivial/short amounts of text don't really qualify for copyright, and "fair use" can exempt them even when they do).

Tribbles are almost certainly copyright and trademark Paramount/CBS. I've certainly seen Tribble merchandise in the past, which I'm fairly sure was an official licensed product. Prior to the CBS takeover of Paramount, it would have been less of an issue, but CBS have reportedly been behaving in a much tougher way over Trek rights. I don't think it would be in Squad's best interests to try to license the use of them, when they could most likely just invent something suitable themselves.

I couldn't be more against anything which forces you down a particular path in career mode using the tech tree, or that nerfs current science levels. It would be a huge, game-breaking mistake! The tech tree is early game only, end of story. That's how it is, that's how it has always been, that is how it is designed, and that is how it should be. The game is about exploration, not grinding science reports. Science is still useful once the tech tree is completed. If you are incapable of motivating yourself to explore the solar system, without a stupid grinding mechanic and one hand tied behind your back from having a pitiful selection of parts to use, then you are in the wrong game! Career mode is not about unlocking the tech tree, that's just one tiny component of it that is intended to be the earliest, finite, and relatively short start to your career. Once it is complete, you are exploring for the satisfaction of exploring, gathering science for the satisfaction of gathering it (and getting paid for it once the tech tree is complete), designing new craft for the satisfaction of designing them (and to help with the other activities), and fulfilling contracts. Right now, everyone has the choice in how they prefer to start the game, either completing the tech tree locally, or reaching further out while completing it. Taking that choice away and replacing it with a horrible slow grind that involves a huge amount of time warp would be a dreadful mistake and go a long way to euthanising KSP long before its time!

Hehe. By "very old usage", I didn't mean "and obsolete/outdated", just that it's been used that way for long time, i.e. I don't view it as obscure or a new usage.

Yes, it's a very old usage of the word (but still quite current, at least in the UK). Giving it an aeronautical slant, one of the RAF's very long standing nicknames is "crabs", sometimes attributed to sideways movement (debatable whether it's due to the sideways movement of old tail dragging planes when taxiing, or any plane in a crosswind landing; or whether it's due to the RAF's drill movements allowing an unlimited number of sideways paces, unlike the other 2 services). There is another more military explanation (and less family friendly), but I won't post that here.

Read the config that I posted on the first page of the thread. The default configured value for medium rover wheels is 300 (and all others are similarly vastly higher than 30). The new tweaking UI for it has a major bug which clamps all of them to 30, and hits the first time you open the UI. If you have a wheel that you have never opened the UI for, from the very first point you clicked on it in the part chooser, it will use the correct default. Click on it just once either while building/editing the craft, or "in flight", and the brakes are effectively completely broken.

As far as I know it's all quite vague, only a few bits of detail: Completely rewritten UI, as the current UI isn't suitable for U5 (U5 has an all new UI framework). They have learnt a lot about how to do UIs since some of the current UI was implemented, so it should be good (but not all the improvement is necessarily visible). Wheel colliders have completely changed, all wheel code must be redone (comment from me: but don't expect huge improvements, necessarily, I've seen developers complaining that the wheels are still crap, just crap in different ways). Major physics change due to the PhysX upgrade (comment from me: but don't expect much user-visible change, likely just improved performance (hopefully)). Physics should have at least limited multi-thread support, but don't expect miracles or huge new features from that; multi-threaded physics is not, and has never been, a silver bullet; and multi-threaded doesn't mean that everything can be in parallel up the the available cores, only that some things will be able to be done in parallel (others will have to be stuck behind a mutex for complex practical reasons). Much better to have lower expectations here, and possibly be pleasantly surprised, than to subscribe to unrealistic hype and be disappointed. The door is definitely opening for 64-bit, but they sensibly have not promised it for 1.1. I imagine it will be a case of whether it works well when they flip the magic switch, or if it needs more work and is better to at least get 1.1 out the door with U5 in some form, rather than delay it. I.e. if it "just works", I expect 1.1 will probably have 64-bit builds, but if they hit a major snag it could be 1.2. That's just quickly from memory, I've not deliberately omitted anything, but could easily have forgotten something.

Only Squad really know the answers. For now, these are the most accurate answers you will get: 1) A bit. 2) Yes, but not very different.

The lab is deliberately made barely functional on Kerbin's surface. Off Kerbin, all experiments generate data (max once per type & location combination, for a single craft).

Just about everyone that played KSP for more than an hour prior to 1.0 has had problems with chutes opening too fast. They used to be like slamming through a concrete wall when they opened, quite capable of detaching bits of your craft (mostly just if using physics warp).

Steering should be enabled by default for the rover wheels, I believe (or maybe it's just some of them, not sure without checking).