Scoundrel

0.7.3 - played (placing fins without symmetry was hell!) 0.10 - finally got around to purchasing as I own a mac (coming up on 10 years old!!!) 0.12 - landed on the Mun and came back first try... all without maneuver nodes or any of that stuff! 0.13.1 - discovered mods and, by extension, the forums. Also discovered that mods make my ancient computer run KSP verrry slowly, so just kept the forums.

I think it is a bit premature to condemn Squad before seeing what 1.0 ends up looking like. I won't argue that the game is in desperate need of a polish, and that the trial-and-error nature of KSP's development (I'm not going to comment on the mismanagement and backlash regarding "project V") has many of us concerned that the game will never meet its potential. That isn't up for debate. However, I do believe that concluding that 1.0 won't be any different that 0.9 is pure speculation, and even if it was, Squad has not indicated that they will simply wash their hands of KSP once it is released, as they have stated on multiple occasions their commitment to continuing to work on the project well beyond 1.0. Apparently people do not believe Squad is capable of producing a finished, professional product despite KSP being the only software they have ever developed. Thus the only conclusion one can come to is that threads such as these, which will, like a star, burn brightly for the first bit before fading into the red dwarf of cyclical white knighting and criticasting, is a result of a chronic PR issue that Squad has never really addressed. So, before we step onto that treadmill, perhaps we could examine what Squad could do to fix that problem before we get another community meltdown.

I like the idea behind the idea, unfortunately Alshain is correct. The proposal as it sits is impractical. I do believe a workable compromise could be achieved, such as having say the first 3 or 4 action groups not require an engineer. That way rudimentary action groups would allow single kerbal aircraft to switch between engines and mess with intakes and the like, and more complex setups (which would likely be 2+ kerbal vessels anyways) would require an engineer. That said, there are many who simply use action groups for convenience rather than necessity, and requiring engineers would be a detriment to that. I think that engineers do need to have their role expanded, but perhaps not necessarily in this direction. I would propose engineers prevent catastrophic engine overheating and add PID control to fix excessive craft oscillation before I suggested they limit action groups.

Ooooh! What if, what if... We take a control pod, such as a lander can, and alter it just a bit thusly: First we create a plane at 0,0,0 in relation to the lander can model and call it the orientation plane. Since the default orientation of the lander can is +y, we set the plane to a +y orientation. We then make the lander can model a child of the orientation plane and set it to also have a +y orientation. Then we create a 2 frame animation. The first frame has the orientation plane and the lander can model oriented +y. The second frame has the orientation plane rotated 90° so it is now +z while the lander can model is rotated 90° opposite so it remains +y. Then all we need is a bit of code to trick the game into thinking it was a "control from here" click so that we don't explode the game since the sudden change in orientation would cause errors as the engine thinks things just instantly slewed 90°. Would this be doable?

I was afraid of that. Thanks for the reply.

What I am humbly suggesting is the ability to change pod orientation (which way things look on the navball) from up to forward and vice versa. As someone who uses lander cans for rovers and fiddles with VTOLs, it would be really convenient to be able to switch this without having to resort to the docking port trick. I also wouldn't mind seeing this as an IVA button for those of us who engage in Manley challenges (IVA only flight to Duna or Jool or wherever), but it isn't necessary. Failing that, what about allowing docking ports and pod "control from here" options to be used in an action group? Perhaps this last one might be more acceptable to those who think my original suggestion is OP.

This is an excellent question and one that I am currently exploring as I work on a novel about humanity being forced to flee Earth to survive. I think the biggest challenge facing humanity is that of the individual. Technologies that enable the individual to be free of corporate and government control are the same technologies that will allow humanity to survive amongst the stars. This will create a conflict between individuals and entities that seek to control people, be it directly or indirectly, as individuals will no longer be dependent (and in fact must not be dependent on) those same entities in order to thrive. That outcome of that battle will be what determines whether or not humanity continues to thrive, or if we collapse in a cycle of violence and expansion. This, of course, brings up some uncomfortable ideas: the right to self-determination; the right to own what one builds; the right to self-defense; the right to travel freely. Humanity as a whole always has rationalizations to oppress people - traditionally for the "common good" - and as human nature has not fundamentally changed over the last 20,000 years or so, I don't see the problems that we still have today of people initiating violence upon each other going away any time soon. Anyways, I best stop now before I challenge the text limit of the forums for post size. I could (and have) write essays about this all day.

Ahhh yes, the good old days! Back when there were 5 quarters to the dollar and all the rocket parts were steam powered and KSP cost just 7 bananas. I remember trying to carefully position those fins (before symmetry!) on my lander so I wouldn't destroy the engine when I landed on the Mun... and I remember having to wait until the mun was on the horizon to make my burn just so I could get there. Makes me think they should have a map mode toggle for difficulty and you have to set maneuver nodes at KSC. Yeah, my memory of which version did what isn't exactly the greatest as they all sort of blur together, so thanks for the clarification. I don't remember it that way, but I guess I never found getting to orbit as challenging as others did, and with all the time I spent on the Mun (and Duna when it came out... ohhh the heady days of discovery!) it likely didn't stick in my mind.

It's a bug where, near as I can tell, keyboard inputs stop. I don't know what causes it, as it is intermittent, but I have experienced it several times. The only way I know to fix it is to quicksave then restart KSP.

If I may weigh in with my worthless opinion... I don't see it as a conflict of interest so much as it is a conflict in general, because people who are biased one way or the other will insist their bias is more rational or more beneficial. This is why we have so many treadmill threads created by people who want to create some form of consensus with others who share similar opinions in order to validate that bias. People will always disagree with each other over something, and it will always be distorted and polarized to the point of absurdity (from a deconstructionist's point of view anyways). In the case of KSP, players sometimes set their expectations a little too high and forget that the devs have a "flavour to taste" attitude towards their own game. I mean it's not like Squad is made up of scientists... they're programmers who superficially educate themselves on a subject so that when you play the game it behaves in a (hopefully) analogous and consistent (if unrealistic) fashion. They also have to make hard decisions that prioritize game performance and player accessibility, while keeping the framework open so people can add more realism in the areas that they feel need to be more realistic. But for some players it simply isn't enough. Consider aerodynamics: it is a high priority for some players because they spend a large portion of the playtime in Kerbin's atmosphere, or focus primarily on lofting payloads. For those who spend most of their time messing around on Duna or the Mun, aerodynamics isn't relevant because it only affects the first 5 minutes of their game experience, which results in these players typically wanting the devs to spend less time messing around with Kerbin-oriented stuff and focus on off-world stuff. And then there are those who are afraid that changes to fundamental aspects of the game will ruin everything in some fashion. Each position has valid points. Unfortunately these "discussions" usually devolve into conflicts as the participants eventually overinvest in the argument and convince themselves that they are influencing the devs to prioritize whatever particular bias is being pushed (one way or the other) when the reality is that the devs mostly insulate themselves from these discussions and make their decisions based on a combination of their own judgement - which has been honed through trial and error - and budget restrictions (not just monetary). So we do influence things... but only a little, and with great effort. Anyhow, that's just my insight into the issue. I'm probably wrong anyways.

The spaceplane parts were originally a mod that Chad (and IIRC WinterOwl contributed a few parts as well) created back around the .13 era of KSP. Prior to the Aerospace Pack (which was the second mod to be made stock), I don't believe there were any form of aerodynamics at all (let alone orbital mechanics or an actual requirement for oxidizer). Based on posts and podcast comments made by HarvesteR and C7 here and on other forums, Squad pushed aerodynamics back as it wasn't an urgent priority (likely since since FAR was available) compared to post-kerbin features that they needed to implement, and both HarvesteR and C7 assured us that once the game was scope complete that they would focus on fixing the aerodynamics and rebalancing the parts.

I remember that thread. It was how I discovered KSP. Lots of gems there, and it's pretty cool that not only has HarvesteR's core vision of the game not really changed all that much over the years, but that he's been open to ideas that expand the scope of gameplay despite the fact that Squad pays its developers in bananas. I often reference it when I think about how Squad would implement a suggestion.

Nah, this is a game and I really don't take anything seriously. I was more concerned about the language barrier and that my words would be misconstrued as some sort of personal thing. I guess it backfired. It's exactly like rocket engines overheating, and players know that when an engine overheats you either throttle down or wait to see if your engine blows up. I'm literally suggesting using a mechanic that already exists in the game, that's all. A simple mod implementing heat at velocity would verify if my suggestion has any validity and would expose any potential exploits. Unfortunately I'm a writer not a coder, so I am naturally lazy and untalented, and thus obviously incapable of writing it myself. You don't need any speed to use it as a first stage... the difference is that your ascent profile is different to maximize the amount of time you spend using jets, which lets you do amusing things in Kerbin's atmosphere, but beyond that they're dead weight if you spend any time outside of Kerbin's SOI. I actually find the aerospikes useless performance-wise (though I like that they're short), and that the 3.75m engines (either one) make using jet engines as a first stage pointless. The only reason I don't rant about those engines is because they're practically the end of the tech tree, so they should be good. Also NASA had input on those engines, so they'll likely be spared being nerfed. When you say MHD scramjet I assume you're referring to an MHD bypass scramjet (as per Sheikin and Kuranov)? The absurdity then is that the MHD generator is upstream of the combustion chamber and the MHD accelerator is downstream... and since the specific heat for the flow has to remain constant for the Isp boost, precooling the flow completely negates the MHD. Actually, I don't think the MHD would function at all precooled... but I'm not a physicist. Ah, okay now I understand what you meant. You were talking about ascent profiles, when I thought you meant that jet engines should spool up slower. My bad. Oh I suspect they'll be getting a nerf... the question is by how much, and if they fix the Isp issues (like actually making thrust vary with altitude rather than fuel consumption).

Heh. I was under the impression that the "problem" was such things as people getting 200km apoapsis with jet engines alone, which, as I understand it, is done through velocity (of delta v fame). Since engines themselves have an upper limit on velocity IRL it seems to me that limiting their velocity solves the "problem" as it has been put forth. Am I mistaken? I don't know how to say this without sounding condescending, so please don't take it as such... generally speaking, the upper limit to any turbine engine's performance is heat, be it from heat causing excessive thermal expansion of the parts (resulting in catastrophic failure) to heat causing the blades to weaken (resulting in catastrophic failure) to the fact that no jet turbine can handle stoichiometric temperatures as a whole (resulting in cata- oh, you get my point). Heat is why there are no Mach 10 jet turbines. As for the "slowly increasing the speed" thing... cruise missiles use turbojets and turbofans. Also FADEC allows high performance aircraft engines to go from idle to afterburner back to idle in an almost violent fashion... just look for jet engine testing for the PW-F119 or the EJ200 on youtube. Unless you're talking about high-bypass turbofans. Then yeah, they take a little bit to spool up. And lastly, about minmaxing... isn't that what you're supposed to do to get to orbit? Well, with all the people complaining about the inlets (why does Squad call them intakes?), I thought suggesting exploding inlets was appropriate... and if you want some RL examples, I believe there are some pics floating around the internet from Purdue's hypersonic wind tunnel experiments where shockwaves and skin friction at high mach have done some serious damage to the test rigs... but you're right, it's not that realistic so consider it publicly retracted if it pleases you that I do so. I guess the thing is that I don't see Squad creating "realistic" jet engines, as simply making them air-sucking slow-to-spool-up pseudo-rocket-engines optimized for either low-altitude or high-altitude flight still allows us to make functional aircraft. Proposing a simple solution such as engine overheating seems to me to be the best compromise between realism and KSPism, as it makes things like IntakeAir moderately pointless: it's needed to keep the engine running, but at high speed it becomes irrelevant because your engine will melt. Gotta love thermodynamics! Otherwise, imagine if Squad did implement realistic jet engines… someone, somewhere would make a thread arguing over whether or not the pressure recovery for the radial intake reflects the correct number of shockwaves in the inlet, or that the basic jet engine's datum blade tip Mach number on the rear compressor stage feels too high (which then deteriorates into an argument about whether or not the high pressure shaft speed needs to be reduced, blah blah blah). Thus, in the end, it won't matter how realistic Squad goes, there will always be someone with a bone to pick with the devs because they can never do anything right (patched conics vs. n-body, aerodynamics, resources, engines, parts, etc.), and they know this. That's why realism suggestions are generally relegated to mods (ala HarvesteR's blog post in response to the aerodynamics thread), and why I prefer to approach topics in a way that increases the likelihood of Squad actually considering them. Otherwise, Hell yeah! Bring on the turbine maps and compressor stalls! A typical high bypass turbofan engine has a cruise SFC around 15-16mg/Ns, and takeoff SFC of 7-8mg/Ns, which translates to an Isp of about 7000s at cruise and about 14000s at takeoff... looking at KSP's config files, they have an ISP of 1800-2500... but that's a lie because they consider IntakeAir fuel at 15:1 (oooh, stoichiometric!), which means they have an actual Isp of over 30000s! That said, I don't think that is necessarily a bad thing considering this is a game about exploration.

The engines are fine, IMHO. All that needs to be added is that inlets acquire heat as velocity increases until they explode or are closed, and the velocities at which heat is accumulated varies with each inlet. You can even do the same thing for jet engines if that wasn't enough. A mod would suffice, but I wouldn't mind seeing it in stock. That said, I find it interesting that people have issues with how other people play a game. Things like the "problem" of intake and engine spamming, because [insert personal opinion and rationalization of why that personal opinion validates dictating what game experience other players should have]. It makes me think of people complaining about how other people play solitaire.

I so want to see flying bacon in KSP. It should even have its own biome. Also I like the idea.

I second this idea, especially since Stupid Chris is pretty generous with his license.

Just a thought re: debris/stage recovery... Would it be acceptable if, say, a chunk of debris has a parachute part that is deployed - or an undeployed chute and probe core - would be "auto recovered" (after, say, 2500m) if the periapsis is below 70km or whatever the atmospheric boundary is for whichever body said debris is being ejected?

If I may present my worthless opinion on the subject*: I think this thread is a bit premature as nobody who can post here has seen the design document detailing the proposed aerodynamic system, nor sat in any of the dev meetings where aerodynamics are discussed... and if they have, they certainly wouldn't be able to reveal any of the particulars for obvious reasons. IMHO, vaguely worded casual musings made by the devs regarding their intent towards improving a feature are hardly the equivalent of design document revelations worthy of declarations unplayability. Therefore I respectfully submit that it would be prudent (and more constructive for the community) if we refrain from polarizing our positions based on pure speculation and reserve judgment for when the new aerodynamics are implemented. Who knows, it might almost be as good as FAR. * Yes, I do understand that this thread is mostly a place for those who were hoping FAR would be made stock could vent their disappointment, but I would like to address the conversation in general.

I agree with just about everything here. I'd also like add: Reveal the Tech Tree: It makes no sense to keep the next levels hidden since you can just go online and see the complete tech tree there. Tech isn't random, so I don't get why a player should have to switch between the game and a webpage just to figure out what their next tech move should be. Vessel Stats in the VAB/SPH: An add-on to the delta v request, I'd like to see something that shows the weight of the vessel and the thrust available for each stage so I know what my TWR. It kind of sucks to stage and discover that your upper stage doesn't have enough thrust to maintain a steady ascent. Of lower priority: the amount of lift generated would help with spaceplanes; the electrical charge requirement of systems and electric charge generation so we can design accordingly; and finally, acceleration and top speed for rovers (as calculated by the rover proper).

This is a well known PID issue with the stock SAS. There's a plugin that deals with it, you'll have to search the forums.

Heh, I was wondering when someone would suggest this. NovaSilisko made the LV-N, and with him gone, likely Squad forgot to change it from LFO to LF once tweakables were added. I too would like to see LV-Ns changed to LF only.

Some interesting replies here and a couple of good points. I shall humbly respond thusly: With regards to regions: Geologically speaking, region is in fact technically the closest to the correct terminology for what passes as biomes. However this game doesn't follow geological reasoning because this is the Kerbalverse and things are different, and thus the proposal of a new term to deal with this discrepancy, which leads to... With regards to learning new words: Some players feel that others won't be able to cope with a new word since knowledge of the word biome came from Minecraft and thus its reproduction here in KSP. As it turns out, I was in fact aware of it, and was the reason why I coined the term Geome rather than push for the terms "region" or "area": it is similar enough to the word biome that few would not be able to associate the words with each other; and adding the word Geo in front of it makes its meaning relatively obvious. So if we put it in the context of "Explore the mountain geomes of the Mun and bring back a sample" a player will only likely be momentarily confused, much like a player who is told to explore a biome for the first time... though it wouldn't actually be presented like that, as it would read "explore the mountain areas of the Mun and bring back a sample" and under the science section where the reports are listed it would read "geomes" rather than "biomes" (where appropriate, of course), making the context much stronger and allowing the reader to draw their own conclusion through simple pattern recognition. And if a player never looks at the science reports, they'll never even know that they're called geomes.

I have to confess that as a science fiction author and an amateur exoplanetologist, the continued misuse of the word biome bothers me slightly, and I cannot help but feel like I am not the only one who is virtually insignificantly irritated by such linguistic abuse. As such I am proposing the creation of a new word that will make certain scientists cringe and whine, but will also be far more accurate for what the game designers intended: Geome |jÄ“ËŒÅÂm| noun Video Game Geology A group of areas or a contiguous area with similar geographical features separate from biological ecosystems and habitats. And just so we're clear, I'm not suggesting the change of any mechanics or anything like that. I'm only suggesting a superficial change: the creation and use of a better, more accurate customized word to replace an ill-used one for use outside of Kerbin.

If I may be permitted to add to the discussion: I think the survey issue and the outpost/station contracts issues are linked in that, while well intentioned, their implementation and execution were not followed through properly. The rewards are questionable and the steps required to fulfill the contracts fall short of actually making the contracts give a sense of exploration... this is actually mostly a narrative issue as opposed to a mechanical one. When we think of a narrative of exploration it usually follows thusly: A probe surveys a potential landing site A manned survey mission confirms a location's viability for long term visitation An outpost is established Now, the specifics should be left up to the player so they can tailor the game to their playstyle, but in terms of broad strokes, what if we did this: A probe or manned mission surveys a site, generating a Survey Report, which must either be transmitted or returned to Kerbin, and which offers small rewards. Successful completion unlocks the next contract, which is: Establish an outpost (the exact details to be determined later), which gives some significant rewards but more importantly... Unlocks a set of 1-4+ final contracts: Each of which require the player to travel 1-5km away from the outpost to perform geological surveys that consist of say a seismic reading, a Geological Report, and the return of a Sample to the outpost. The rewards are some money but tons of science. Now a player doesn't have to play the game this way, they can just make science however, BUT it does offer a player driven narrative and a small set of goals and challenges to accomplish besides "make money and get moar science!" Note that in the contract examples I have above, it isn't actually "get science from this biome (I hate that term I'm inventing a new one)" and transmit to complete, so that a player might accidentally screw up their game or contract. Instead, by making it a non-currency acquisition of data, the player can still get science for exploring (esp. during the initial survey), and still get more science later with the base if they choose to accept the next contract. Anyhow, that's just my opinion on the subject.