thylordroot

I have no particular naming convention for my ships. A lot of the names are corruptions of their function (e.g., "Pwober MkI"), but I've been naming my launch vehicles names like "Ert" and "Bernie" lately. I just recently started working on an idea similar to the original plans for STS, and I am naming these vehicles "ITS <x>", where x is a name pulled out of my hat and that is a name that succeeds the last in alphabetical order.

HoY, absolutely; I think this would be perfect for recreating the Hiller Flying Platform and small drones. I will have to check back from time to time to see how you are progressing on this project.

IVA view does have at least one perk to it (which is the radar altimeter). I used to use IVA mode for landing so that I had a reasonable idea when I should start braking. Now that I have KER, I find myself not doing this so often. I certainly don't complain when a mod author includes a cockpit in a command pod, but I don't use it all that much. I agree with 5thHorseman with respect to the poll, as it answers a subtly different question than the one you are asking. It instead asks, "How detailed should IVA mode be?". Analogously, this is like trying to answer "Do you like pizza?" by asking "What toppings do you like on your pizza?", and then assuming that "no toppings" might indicate that I do not like pizza. I think many of us have answered the question from the perspective that you were actually asking "When IVA is implemented in command pods, what level of detail do you prefer?" Of course there is also the argument that command pods have IVA by default, and as far as I know, this is an attribute that every command pod has. I can think of a few corner cases (like the lab module), but I do not think this is technically considered a command pod by the game. I think in this light, 5thHorseman's question could be simplified to "What is the minimum level of effort you expect concerning IVA view in a command pod?", which seems to be the question you really want to know the answer to because you appear to be trying to find out whether or not implementing IVA is worth the effort for your part. To that question, my answer is "none". I don't complain when IVA mode is available, but considering that we are still less a cockpit in some stock parts, I think it's forgivable that IVA view on your new part is a secondary concern.

You will have to let us know how your thesis defense goes! I will gladly do this survey for you. Question 1: Are you an active user of modifications in KSP? Yes. Question 2: Do you create modifications to KSP? If so, what are your motivations for developing modifications to Kerbal? Do you develop for your own personal use or for other users? Are you looking to showcase your skills for commercial companies or simply for your own enjoyment? If not, what are your reasons for not creating modifications? Yes, but only minor ones and for my own enjoyment. When I do so, it is largely to modify a part that I feel is missing from the game, but that could be easily accommodated by modifying an existing part. I have not yet dove into KSP's Mod API. Question 3: Why did you choose KSP as your platform for creating modifications? Do you develop in other games as well? If so, which? What does Kerbal offer you that other games do not? I chose KSP because I play it most often, and the modifications became a natural part of exploring the game. I rarely develop mods for other games, thought I did write a genetic algorithm for optimizing Starmade reactors a year ago. Question 4: Which types mods do you create and/or use in KSP and why? Most of the mods I use are related to increasing game difficulty; the reason that I hack parts is largely to meet some in-game need that I feel needs to be addressed, and recently, I have been doing it to reduce lag by bundling several parts together. Question 5: Under which licenses do you choose to release your mods and why? Do you have any aversions to releasing modifications under certain licenses? I have not released any of my modded parts; if I did get around to writing code, however, my first choice would be the GNU GPLv3 or the LGPLv3 depending on the use case. Both are explicit about how rights are conveyed to users, and I largely agree with their philosophy concerning distribution. Question 6: There is a large forum and community around KSP. What is your experience on receiving feedback on your modifications, help with getting started and in general the interaction with the community? Do you in feel that you are part of a larger society, or one creator of many. KSP generally has one of the best-behaved communities I have seen in a while; almost everybody seems to be willing to help others whenever they can. Mod developers are especially diligent in their replies, and they usually solve outstanding issues quickly. Though I tend to lurk, I take the perspective that I am part of a larger society. Question 7: What are your thoughts on FOSS(Free Open Source Software)? Is this something you consider when creating/using modifications? I am a strong advocate for Free software, but I am not adverse to proprietary software (otherwise, I will not play KSP). I feel that it is critical that the holders of any copyright should be able to license their software as they see fit (within reason, of course), but I personally choose to release most of my software as Free software for the very reason that others can (hopefully) learn from it. Question 8: Do you contribute to the KSP community in other ways beside creating modifications? Trivially; as I said, I tend to lurk on the forums. Like many others, I do Let's Play videos, and I occasionally offer advice on the forums whenever I think I can help somebody. Question 9: Do you have any other comments or issues you want to address regarding KSP? No, but do keep us up to date on your research! Good luck, Bjørnar and Vegard, If you decide to make your thesis available to all, please share it with us. I'd love to see the data you've collected.

I've decided I will put links to the suggested mods in the OP for my own and others' convenience. Thanks all for your suggestions, and feel free to make more! I have been looking at your mods, and already have Karbonite installed. As for Community Tech Tree, it looks interesting, and I think the Alcubierre Drive is a reasonable endgame goal. This one looks to be the least deleterious for an existing game, but I will have to do some testing. Thanks for your input. Wow! That is a huge tech tree. I understand that what you mean by the above is that Station Science is not explicitly supported, but that you have not enountered problems thus far. The fact that it does integrate most of my mod list is quite promising, though. This is definitely worth a look. This is an issue in stock, too. I guess the rationale is that miniaturization happens late and that the small parts are the culmination of advanced electronics technology. Then again, Kerbals have managed to invent the command pod before the wheel in stock, so I am not sure how well that holds. It's hard to tell, but this tech tree looks like it may rearrange things. I suppose only testing will reveal whether or not this is the case. Fortunately, I have about 900 science saved up in my game, so if it does, maybe I can recover from this. Thank you both for your suggestions. It looks like I have a few options to consider this weekend.

SLS, maybe I will give Interstellar a shot. My biggest fear here is that I will shut down my satellite network because I have not prepared any of them with radiators. However, I am looking through the ISP Lite git repo, and it appears that waste heat may not be implemented yet; in this case, this may work out just fine. I will put more research into it and see if I can successfully integrate this into an existing savegame without a ton of relaunching. In the interim, any other suggestions would be well received. There may be other mods worth checking out for this purpose, so I would love to hear suggestions for them.

Greetings, I've been working on a career mode save since 0.24, and have now gotten to the point in my game where I am doing interplanetary travel. There's just one problem: I've almost managed to complete the tech tree, and I just left Kerbin. About 3800 or so science remains in my tech tree, which seems like a reasonable amount except the following: Three of these nodes are (in fact) from mods. Two are for procedural fairings, the other is for Kerbal Attachment System. The remaining nodes are related to spaceplane nodes that I never bothered to unlock. I have a couple of mods that provide additional science: namely, ScanSat and Station Science. I wasn't expecting ScanSat to have science (though I will gladly take it), and I have not done much with Station Science (although I presently am working on an interstellar craft utilizing it). These are the only two mods I'm aware of that add science in my installation. Contracts have been providing more science than I was expecting them to. Some of the stock contracts I have been offered provide 300 science for something like testing a part that has splashed down. I thought it might be interesting to what was out there for late game stuff, and I am looking for balanced mods that add high-level tech tree nodes. Here is a list of mods that I currently have installed (many of which add parts): Ferram Aerospace Research Deadly Reentry RemoteTech 2 Kerbal Engineer Redux Procedural Fairings Procedural Parts Firespitter Kerbal Attachment System TACLifeSupport Station Science SCANSat kOS Ubio Welding Ltd I know that the Interstellar Pack has some very-high level tech tree nodes (some of which require thousands of science points to unlock), though I am not sure how wise it is to install at this point (particularly because of the waste heat issues). Nonetheless, it does serve as an example of what I might be looking for. If you know of any mods that extend the tech tree in this manner and which are reasonably fair (i.e., well-balanced), I would love to hear your ideas. Thanks in advance! Regards, ThyLordRoot Edit: The following is a list of mods that have been suggested so far to meet this goal. Interstellar Lite (suggested by SpaceLaunchSystem) - http://forum.kerbalspaceprogram.com/threads/91867-0-24-2-Interstellar-Lite-Tweakscale-Integration-v0-12-3-Sept-7 Community Tech Tree (suggested by RoverDude) - http://forum.kerbalspaceprogram.com/threads/100385-Community-Tech-Tree-1-1-last-updated-19-11-14 Near Future Tech (suggested by RoverDude) - http://forum.kerbalspaceprogram.com/threads/52042-0-25-Near-Future-Technologies-%2817-11-14-All-packs-CTT-compatibility%29 Mod-Oriented Tech Tree (suggested by StreetWind) - http://forum.kerbalspaceprogram.com/threads/90938-Mod-Oriented-Tech-Tree-%28November-4-v0-2-97%29

Back during 0.20, Duncan from the Yogscast decided he wanted to do a let's play series on KSP, and after a bit of mucking around, he decided he was going to land on the Mun. He built a direct ascent lander with the Mk1-2 pod and a Mk2 landing can underneath it (presumably under the assumption that his Kerbals would emerge from it). He manages to pull off the landing alright, but is surprised when his Kerbals are coming out of the pod instead of the landing can. Not aware that Kerbals have jetpacks, he decides the best course of action is to put Bill on the ladder and take off, only to find that Bill cannot cope with the acceleration and has fallen off. He tries to leave the Mun's sphere of influence and doesn't quite have enough juice for his approach. Bill ends up getting kicked out of the capsule somehow, so he decides to rescue Jeb. But as he's trying to figure out how to get his rescue craft to rendezvous with him, the lander re-enters the Mun's sphere of influence and crashes into the surface.

I think stock aerodynamics is sort of the elephant in the room and the one that most frequently inhibits gameplay. KSP's drag model works great for rockets, but not so great for spaceplanes; and since few of the stock parts generate lift to begin with, it encourages wing spam. I can see a couple of interesting use cases for where thermal management becomes important. For instance: A high temperature environment might kill kerbals and ruin electronics. Conversely, the opposite extreme could cause kerbals to freeze to death, keep engines from starting, and might even cause probes to cease functioning because they've undershot their minimum operating limits. Squad could also let excessive G-forces rip parts off of your rocket and be a death sentence. I think neither have occurred simply due to gameplay reasons; rocket building might be significantly slowed down by this sort of thing. It really depends on what changes to temperature you propose. If you propose this in isolation, then I doubt it would either (in fact, I'm not sure how it would significantly impact gameplay). Yet, when we start talking about alternate consequences of temperature, then it possibly could, and it goes fairly deep. We have to start considering how temperature propagates throughout the spacecraft, and whether or not a situation like thermal runaway should be permitted. Kerbin is apparently a good source of bizarre material; after all, Kerbin's mean density is some 10x greater than Earth's! And the list doesn't even stop there: just look at the specific impulse of Kerbal engines (especially their jetpacks), or the fact that their helmets can withstand impact at terminal velocity, or that they carry multiple tires many times their own size in their pockets. The Kerbol System is a strange place. Despite all of this, I think there is some benefit in stock's cartoonish approach to, well, everything. I can crack open a beer and pilot my rocket recklessly. A mistake in stock is usually a blunder caused by the fact that I was not paying any attention to what I was doing. KSP's apparent lack of congruence with reality rarely enters my mind when I'm playing; in fact, I've come to count on it as a source of entertainment. The realistic mods are tremendous fun, too, but they do not share this same sort of gameplay experience, IMHO. I absolutely agree with this sentiment: this is a bug and should be fixed. It can do nothing but improve rocket performance. I won't speak for the OP, but I welcome this. The "big posters" have probably been playing for a while and have meaningful input into the discussion. Their disagreement should be welcome (that is, if they're not being contrary for the sake of being contrary; and I haven't seen any evidence of that yet) because it can genuinely improve gameplay. I am very much new to the forums and in comparison to some of the posters, to KSP as well (I really only got into it around June 2013), but I think some good points are being raised in this discussion. Even better, some of the mod developers have gotten involved. These people are familiar with KSP's internals (at least more familiar than I am) and probably see KSP in a way different way than we do. When NathanKell spoke about what I can only are magic numbers in thrust calculation, that does smack me as a legitimate gripe. Even that .01 m/s^2 error stacks up quickly, and its something that some time with grep would probably fix. This is a bug that could be fixed; it's just a matter of Squad finding the time to fix it. Ferram4 has occasionally cleared up some misconceptions about how stock actually behaves. Not as such (thought there's nothing preventing you from running C# code through cpp), but I'm pretty sure what you really meant to ask is if it supports constants, and it does for primitive data (c.f. C#'s const keyword). IIRC, these are permitted to be inlined at compile time. It has about the same result as I think you are asking for, and you're absolutely right: magic numbers make a large codebase a veritable PITA.

I think that the current solution of enforcing realism through mods is a good approach, personally. I haven't read through all 28 pages of the thread (and that is probably to my detriment), but one argument seems to be that new players have expectations about the way KSP should work and that when it behaves in a manner inconsistent with their experience, the result looks unpolished. What I'm about to say is anecdotal and should be taken in that context, but in my experience, new players don't see it this way because they have rarely have enough experience to know what to expect to begin with, and whatever model of rocketry they've formed in their heads is drastically flawed, anyhow. Let's look at some common mistakes that new players make: New players often launch straight up when they are trying to achieve orbit. New players often build insanely huge rockets (then again, who wouldn't?), even though a smaller rocket would get the job done. New players often burn radial when they are trying to leave orbit and will burn directly towards targets now instead of trying to find a suitable transfer orbit. I will start off by saying that I think there is merit in shattering misconceptions that arise out of common sense. I think KSP is fun simply because when you fail, it is usually catastrophically and hilariously. With that being said, I would hazard to wager that the new player's experience with respect to orbital mechanics is fundamentally incomplete; I know that mine was when I started playing KSP. As a result of KSP, I've gotten to the point where I really wanted to do my own self-study on the issue. I think we sometimes forget that to these players, even getting into orbit under stock conditions is rewarding (even under stock conditions) because they have no concept of what constitutes a realistic rocket in this case. I now play with FAR, RemoteTech, TAC Life Support, and Deadly Reentry, which I have found can (and often do) punish relatively minor sins against physics with an iron rod. I've gotten to the point where I actually like this, but I am not so sure a new player will. If they really want that experience, our capable and diligent mod community has toiled without end to provide it to them. Don't misunderstand me: I think there is certainly room for improvement in KSP and some additional realism in stock will help that. I occasionally also find that Squad puts too much emphasis on new players sometimes, and that has occasionally manifested itself in some rather silly ways (like spaceflight preceding the invention of the wheel and manned exploration preceding probes). Spaceplanes are still a chore to design (although they appear to be receiving some much-needed love in 0.25). For all of stock's idiosyncrasies, however, I think that it kept me motivated to keep on playing and to eventually desire a more realistic simulation. As others have suggested, perhaps the best way to approach this issue is to allow certain aspects of the simulation (such as aerodynamics model) to be chosen at the start of a new save; then, it's just a matter of providing sane defaults. I wouldn't blame them for not focusing on this quite yet, however; I'm sure they have a lot of things they want to get knocked out first, and they seem to know what they are doing (I haven't yet seen a patch that was anything short of awesome). Until then, knowing that mods are available to mitigate this issue has worked wonderfully for me.

It's an awesome idea, I just think that it's a huge undertaking. Internationalization is often a lot more than just changing a few strings, and there are a lot of gotchas to be had. Outside of textual content (which is tricky enough as it is; just consider problems arising from idiomatic expression), there are other issues such as text direction, the ubiquity of metaphors we take for granted, and other conventions. Squad would likely need to bring in a linguist as a consultant if they wanted to best determine how to implement it; the problem isn't intractable, but it is a problem that even huge multi-national companies have trouble with. Take Oregon's DMV manual as a point for comparison. Oregon has to worry about these things, too, but then again, it is a single document. When Oregon has to update their manual, it is conceivable that the document is simple enough for an expert to be hired for a few days to ensure its correctness; even targeting a new language may not be that much of a problem. Imagine if Oregon was tasked with making all such media accessible internationalized, however: they've now got a much bigger tasks ahead of them, and they have to decide where to draw the line in terms of support. Squad could potentially crowdsource this content, but the framework has to be there in order to support that, and the locale primitives built into the operating system may not sufficient for some more esoteric use cases. Well, to be fair, the contract language isn't inherently meaningful to begin with (arguably, just as in real life); as I understand it, contract verbiage is generated procedurally. I've seen the contract generator spit out sentences that are devoid of semantics. There may even be some grammatically incorrect sentences in there, but I don't read the flavor text when I accept contracts. I imagine it comes down to resources, and the educational potential of KSP is quite alluring. Squad might be able to work alongside willing institutions to make it happen (as they worked with NASA in ARM). Again, it's not impossible, it's just tricky, and if they do it, they need to do it correctly for their own sake and everybody else's.

Absolutely not. My rockets are prone to rapid unplanned disassembly.

I'm currently doing Career with FAR, Deadly Reentry, and RemoteTech 2 (along with a few other mods). Like Nadreck, I have explicitly disabled revert and quicksave, but I have an additional rule such that when my reputation gets in the orange range, I delete the save. In vanilla stock, that seems easy enough to avoid, but because FAR makes flying rockets a lot more difficult, I've quickly come to prefer probes. I've just recently added in Station Science (which adds contracts of its own) and ScanSAT. Once Kethane and Kerbal Attachment System are released for 24.2, I will add those in as well.

I imagine the proper way of doing this (if Squad doesn't do it already) is to use System.String.Format() as described here (http://msdn.microsoft.com/en-us/library/txafckwd%28v=vs.110%29.aspx). Any implementation like this should be locale aware, because just as English speakers have a preferred number format, so do other locales; As a trivial example, the Germans switch the role of the period and the comma when writing numbers (e.g., 1.234,5 instead of 1,234.5), and I think there are some countries that don't break digits into groups of three. String.Format() should use the system locale when processing numbers. To that effect, you can check to see if Squad does this by setting your system locale to do this. If not, then I agree that it is somewhat of an accessibility issue, but it would probably require a fairly large code audit to implement this because of the number of strings I would image KSP would have.

After trying a rescue attempt as suggested above and finding Johnzer died almost immediately, I am content that my question is answered. Thank you both for the help!

Incidentally, Scott Manley put this weird notion into my head that turning off Quicksave and Revert was a wonderful idea. Paired with FAR (which I am still getting accustomed to), I have blown up a lot of ships since two weeks ago. I guess I could turn it back on, although this is my Let's Play save; but to be fair, I did briefly attempt to cheat during the recording this happened to do infinite EVA fuel; no dice, presumably because his pack was already spent. TD;LR: I probably bit off way more than I can chew. Nonetheless, I definitely think of it a learning experience, and if it turns out that there is nothing I can do, then I will deal with the consequences of my bad piloting and move on. I had initially tried this, but without RCS, I could not get properly oriented so that he could reach the hatch. Maybe now that I have it, I should make a minor upgrade that will allow the rescue craft to use the fuel in the pod. This approach is probably worth revisiting, and I will probably do so. The Hard-Mode solution may teach me a thing or two, after all. He's actually in LKO at some 116K. I apologize for the confusion; in hindsight, I did not really specify where he was, and my post does suggest he was at the moon. What I meant to say was that after my rescue attempt failed, I sent a mission to the moon and back. I'm surprised he's still alive after two days, to be honest, since I figured TAC would've killed him after two hours (my experience is that stranded Kerbals do not spawn with any life support resources when you get in range of them). I am not sure if this behavior is based on a flawed assumption about the way TAC works on my part or perhaps a bug in the mod, but perhaps he will cheat death long enough for me to send a rescue pod up there.

Greetings, By now, I am sure that most people have encountered the "rescue X Kerman" contracts, and through my own sheer stupidity, I have managed to accidentally expend all of his EVA fuel after accidentally firing the engine in his general direction (I hadn't unlocked RCS ports yet). I ended the contract thinking that he would die as a result, and because I have TAC life support installed, he will eventually if I take no further action. I decided the merciful course of action was to try to have him burn up in the atmosphere, but this also failed. However, as Johnzer Kerman is merely teetering on the brink of death (and also because I have another Kerbal to rescue if this mission fails), I'd like to try to rescue him again. I'm not even sure if I have a chance of getting to him in time (since I have been to the moon and back since then), but I have since researched RCS (though I do not know if this is going to be enough). The grabber is also potentially within my reach at this point. I'd like to know how you might approach this situation. Or, if you feel that the situation is not recoverable, is it more merciful to let him take the suicide pill (i.e., delete him in the tracking station) or die of asphyxiation?

This is a perfectly reasonable hypothesis, and I can see how it would cause phantom forces on my rocket. I haven't had the time to look at the source code you've graciously provided to the community, but do you posit that there may be a minor numerical stability issue at play here (though perhaps out of your control)? At any rate, I am impressed by the promptness of your reply. Let me know if your project accepts donations and I will send some beer money your way. This seems consistent with what I've read on the topic. I've been initiating my gravity turns at 60 m/s, usually with a TWR around 1.2. To that extent I am probably excessively paranoid; I try to never let the TWR exceed 1.6 until 30K (which has caused me to avoid solids), but it is good to know I have a little leeway here. Part of my issue must be over-correction. I am trying to break the habit of flying without SAS (especially since it now causes positive feedback), but I have to admit that my biggest problem is that I have no idea what I'm doing. To have feedback of this kind is great, because for many of us, KSP is that game that makes us yammer incessantly about what we've learned from it. At this time, most of my rockets are fairly bulbous at the top (since I only have the 0.675 and 1.25 meter procedural fairings at the moment). It has therefore been my habit to utilize a single stage to get me suborbital; that single stage usually has around 3.2 m/s delta-V. The hope is that I can hold on to my control surfaces as long as possible so that I can use a second stage for orbital insertion. My upper stage is admittedly quite weak in these rockets (about 0.9 TWR), but the hope is that the tradeoff is that I will have substantially more time to perform my insertion burn. I haven't messed around with 3-stage rockets yet, but it is an appealing prospect for the mission I am currently working on (which is a direct ascent landing on the moon). I'll keep these notes in mind as I work through this issue; I think I may have an idea of how to solve it now.

Before I ask my question, I'd like to thank Ferram4 and other contributors for their hard work on this mod and their patience and diligence in addressing the questions that so many of us have. This mod has certainly made KSP more challenging for me, to the point where I'm kicking a lot of bad habits I learned in stock. Please keep up the good work! I have a question related to performing the gravity turn maneuver in rockets. The first has to do with a tendency for my rockets to pitch up at launch (this is without SAS enabled). I've noticed that this tends to happen quite regularly, and I was wondering if this is behavior that I should expect, or perhaps if the problem exists between the user and the keyboard. To some extent, adding tailfins with 4x symmetry helps (I usually place the fins near the engine), but I still usually end up about 20 degrees off of course when I try to fly east. According to KSP, my center of mass is in-line with the center of thrust and center of lift. Is this something that is I should correct with a roll maneuver, or is there likely some sort of instability issue with my rocket? If needed, I will post a sample craft file or image when I return from work for further inspection.

Have you ever wondered why Kerbals fly, or what might happen if they stop? Have you ever wondered why all Kerbals have the surname "Kerman", or why Kerbin is so sparsely populated? In my Flight for Survival series, I attempt to explore the answers to this series whilst also exploring the question "how do you lose this game, anyway?" I freely confess that the above exposition is merely an excuse to play around with FAR, Deadly Reentry, and the like. I figured that since contracts and reputation have been implemented, however, that it was the perfect opportunity to go all in. Currently, there are but two rules in this playthrough: I must never hit orange reputation or my space program is done for. I must never quicksave or revert to the VAB during recording. It seems like hitting Orange in stock almost has to be done deliberately, so I've added a few mods to make this scenario more likely. No longer may I aggressively reenter Kerbin's atmosphere, nor may I forget to pack lunches for my Kerbals on those long interplanetary flights. Here are the mods I am currently using: Ferram Aerospace Research Deadly Reentry TAC Life Support Kerbal Engineer Redux Final Frontier Kerbal Alarm Clock Firespitter Procedural Farings Of course, if you want to make my life harder, feel free to suggest any additional rules, mods or gameplay tweaks to look at. After I assess their feasibility, I may include them. Other feedback is also welcome. Series playlist is available here: https://www.youtube.com/channel/UC0c7KDfRGQTmbZJpqmC7Tpg * Videos may occasionally contain four-letter words, poorly improvised humor, and nonsensical utterances reflecting my immediate state of mind.

A note to any mods who might see this: in hindsight, I think I placed this in the wrong forum. I just realized that this is probably better placed in Challenges. I apologize for this, and I'll try not to let it happen again. Noted; I could do what Bob Fitch is doing with his Project Odyssey series and manage a SandBox game externally. It seems to be working out pretty well for him, but somehow it just doesn't feel right doing it this way. The greatest appeal of using Career mode is that I am substantially limited in what I can do, and that means that it's not a question about what seems appropriate, but rather whether or not what I'm doing what is feasible. For what it's worth, if the game can enforce those restrictions on me, all the better, since it limits bias caused by forgetfulness on my part. I am currently looking into mods that might help the fun factor (as in Dwarf Fortress "fun") in this way. I definitely think it's time to start looking into things like Ferram Aerospace, Deadly Reentry, and TAC Life support. I guess what I'm looking for are self-imposed rules that will keep things interesting. This is one wrinkle I've never really liked about the tech tree. I, too, would prefer to see the tech tree arranged in this manner (although I can understand why Squad implemented it in the way that they did). There are tools like TreeLoader that might be useful in this regard, but I haven't tested it and I'm not sure how well they integrate with contracts yet.

Jeb is currently in orbit around Kerbin after completing a rescue contract. He snuck into my probe-operated rescue vessel and I had to kick him out to make room for the bounty. I guess it's probably better that it's Jeb than anybody else, given how hardcore he is.

Greetings, I am in the process of getting a video series going for the the new Career mode, and thought I would set some rules for myself that would make losing possible. I know that (at least at present) there is no concept of losing in the game, so these are things would probably end up being self-enforced (that is, by deleting the save when I have violated one of the losing conditions). I was wondering if anybody else has given this any thought, and if so, I was hoping that we might compare notes. So far, the two mechanisms that I can see for losing are reputation and funds. I am not sure if it is possible to go into debt (or if the worst that can happen is to hit $0), although I do know that the devs have always had an out in mind. I do know, however, that is it possible to drive your reputation into the ground, and I think this would be a good starting place for such a rule set. Here are my thoughts so far: The game could end if my reputation gets low enough. The justification here is that recurring failure causes the Kerbals to lose faith in their space-fairing prowess, and they might question whether or not they are even meant to be in space at all. The game could also end if I can find a way to say that the space program has become insolvent; if so, the space program dies a political death since there it has become clear that the management cannot fund it. My testing indicates that it is not possible to go bankrupt; no matter what I do, I can't seem to get my funds under $12. For the former, I'm thinking the game terminating condition might be when I hit red ( <= -1000 reputation), although that almost seems like it'd be too easy; it seems like you have to kill a lot of kerbals to do this. Alternately, I could make orange the cutoff point here, as that seems to be much easier to get to. The funding problem seems like a harder one to tackle though: are there any suggestions for a reasonable cutoff point here, or should I just not worry about it?

5thHorseman offered some excellent options to start with, but I think it is also worth pointing out that there are things that you can do to make your money stretch a bit further as well. In particular, how you get out of the atmosphere makes a huge difference on your delta-V budget in orbit; I wouldn't bring this up otherwise, but you said you've been playing for a couple of weeks, and it took me months to start doing my gravity turns properly. The advice I usually give to my friends who are just starting is not to overbuild their rockets and to learn how to efficiently maneuver. My understanding is that the new contract system will always provide an out if you're having trouble maintaining funding. I'm not sure exactly what happens if you go into the red (I'm sure Danny2462 came pretty close, though), but it seems like there is the option of grinding funds or science until you get to the point where you can approach the landing the way you'd normally do it. Nonetheless, stacking contracts and doing multiple tests in one mission seems to be a good strategy at this point.

In hindsight, yes; I was just excited to be doing contracts and jumped the gun a bit. I think I'm beginning to get the hang of how to stack contracts to get more bang for my buck, however. The #KSPHypeTrain had me all ready to go, I suppose.