JumpsterG

Please read in Spock's voice: It was caused by a malfunction of the ion engines, captain. An ion-energy pulse was released, interacting with the closest organic matter of significant density: Aldner. Any number of unpredictable effects could have ensued. In this case, it seems a recombination event has occurred, with Aldner impressing his molecular structure onto nearby matter. This has resulted in, what appears to be, an exact duplicate of the Kerbonaut. Whether his complex brain chemistry was replicated perfectly has yet to be seen, but, for now, we must accept that there are two, real, Aldners. (I've been watching WAY too much original Star Trek lately) Edit: RIP Nimoy.

What would be more interesting (and WAY less controversial) would be a holistic survey that accounts for more factors than just Male/Female. It doesn't have to be about whose in the minority, since we fall into many different classifiers. For instance, I may be a part of the majority as far as gender is concerned (Male), but I am probably a minority when considering ethnicity (How many Russian/Puertorican mixes do you know?). I personally would be very interested to know how many different countries, ethnicities, and favorite colors are represented here on the forums.

First, respect to all members of the KSP community. You all rock: males, females, non-genders, super-genders, cross-genders, and socks. OP's observation is that there are few or no female KSP players. While the way in which this is presented may strike nerves, there's an interesting discussion to be had about demographics, social trends, and the visibility of gender populations on the forum. Unfortunately, there is no accurate count of male vs. female players for us to analyze statistically. This poll will not give accurate information due to inherent biases: -the forum is a specific subset of the KSP community and not representative of all players -the nature of the poll calls on a class of people to identify themselves publicly which is uncomfortable -A stigma exists surrounding gender issues that affects males and females from participating (people avoiding the thread entirely will not be counted) While I don't feel that gender makes any difference at an individual level (it's just one piece of a larger puzzle that makes up someone's personality), I do believe that a community built from a mixture of genders (and other classifiers) is friendlier, more welcoming, and provokes more interesting discussion. So, regardless of it's dryness, try not to take this thread as shining a harsh spotlight on a minority, and instead try to see it as an invitation to bring more people of different types into the community. Peace!

Hey, I've poked around the files but, without spending a lot more time, I don't think I'll be able to narrow down what is causing the instability just from looking at it (too many things that might or might not be well-formed). Something that could be tried is removing all the vessels from the save file and then reintroducing them one at a time (or a few at a time to save sanity) to see what vessels (if any) are causing crashes. I would need to recreate your mod environment to test it myself. I don't have oodles of time, but if you make your mod list available, I don't mind trying. Is there an existing tool for manipulating save files? If not, I might try to create one to help with this type of thing... But don't expect that to come quickly.

For those confused, this all started with an innocent question regarding forum reputation. Specifically, was it possible for someone to have negative rep, and whether there were red pips that could be assigned beneath a person's name. Red Iron Crown, newly appointed as a moderator, apparently tested the system and created his nemesis account, Green Iron Crown, which proves that yes, negative rep is possible in the system, and, indeed, they are awarded red pips beneath their name for their nefarious deeds. There was a realization that positive rep could be given to this GIC (Green Iron Crown) to eventually neutralize its negative rep, and thus a forum game was born. The thread WAS correctly located in the forum games section of the forum, but posts to that section of the forum cannot receive reputation, so the mods moved the thread to General for publicity and lols. TL,DR - Moderators and forumers are having fun giving rep to a novelty account that has negative rep. Enjoy!

Cool. I'm at work now, but tonight I'll crack open the save files and see if I can figure out what's going wrong. No guarantees, but it's worth a shot. In the worst case scenario, do you think your .craft files might still be working? You could hyper-edit things back into place if the objects can be re-created.

We can win if we just

Sorry for not responding sooner. Was sick in bed most of the weekend. Reading the output logs, it looks like a lot is going on in your save, mod-wise. I think you're saying (and the logs show) that even without the fuel line conversion it's crashing. Could you describe what happens when you attempt to load the save? Immediate crash, or does it crash during gameplay? If you pm me your save file (0.25 version and 0.90 version) I can at least verify if my converter is causing any new problems and update it. I could also take a look for mod-specific save information and consider if it is possible to repair some of those details that might be getting scrambled after the 0.90 update. It may be that an individual mod does not survive through the 0.90 update gracefully. If nothing else, carefully uninstalling and removing mod-specific data from the save file (possibly to be added back in later with a new version of the mod) could fix crashing.

During conversion from 0.25 to 0.90, fuel lines on existing vessels break. I've made a tool that fixes these fuel lines. Dropbox Link: FixFuelLines.zip FixFuelLines.exe creates a fixed version of the file you select. You should backup the original save file and replace it with the newly generated file. Note that you must have an already updated save file (Loaded to the Space Center in KSP 0.90) or unexpected behavior is expected. The "brotoro" folder in the zip contains the source code (a vb solution with one form). This is a windows program, so if anyone is running Mac or Linux and can't use it, feel free to PM me a copy of your save and I'll be happy to run it for you. Credit for figuring out HOW to fix vessels goes to Brotoro, whose Long-term Laythe Mission thread was put on hold until the broken fuel line problem could be solved. All I did was automate the process so no one has to hand-edit hundreds of fuel line parts with a text editor. As for licence: There is nothing sophisticated about this code and I am making it freely available for anyone to use however they wish. No need to give credit. Please report any errors or unexpected behavior via PM or by replying below and I'll help however I can.

In case anyone has need, I've made available the tool that fixes fuel lines in a 0.90 save that was converted from 0.25: https://dl.dropboxusercontent.com/u/100018891/BrotoroFuelFix/FixFuelLines.zip FixFuelLines.exe creates a fixed version of the file you select. You should backup the original file and replace it with the newly generated file. The "brotoro" folder in the zip contains the source code (a vb solution with one form). This is a windows program, so if anyone is running Mac or Linux and can't use it, feel free to PM me a copy of your save and I'll be happy to run it for you. I'll post this over in the Tools subforum also.

Sorry! I didn't have time to share the tool I made before needing to leave my home for the holidays (visiting family). It parses a save file and creates a new copy with the fuel lines fixed. In a few days I'll have access to a PC and will be happy to share the fix as a windows executable. Feel free to PM me a link to a copy of your save AFTER having loaded it at least once in KSP .90 (good idea to keep the .25 copy, just in case, but I should just need the .90 file). I'll run it through first thing so you can get to playing sooner. Otherwise, you can wait till I make the tool available.

Aw shucks, it weren't nothin'. I imagine some lowly intern at KSC was grumpily working after-hours to fix the software bug introduced by the .90 guys who already left on vacation. Hopefully they promote that guy. I'm at work now, but if I can squeeze in some time, I'm going to generalize the solution for fixing fuel lines into a windows executable that anyone can run to do the same with their save file. If anyone wants a quick fix on their save file in the meantime, just PM me a link to your file and I'll whip it out tonight when I get home.

This seems automate-able. Is it possible for you to make available the .sfs files (pre and post update)? I might be able to whip up a quick vb script to make those changes.

Consider that a reasonable gameplay purpose for the biome map is as a visual indicator of biomes that have and have not been visited/scienced by the player. Perhaps as science is done within biomes, those biomes are made visible in the biome map filter, leaving other, unexplored areas transparent? They could even represent how much science has been extracted by having individual biomes become more opaque and less transparent until all science has been done everywhere, leading to the full biome map overlays we see in the preview video. This could still give a use for a mapping-type mission if an orbital camera (or other scanner parts) could do science in orbit, either by adding one more experiment to all biomes that can only be done from orbit (similar to low orbit EVA's), or by contributing a small amount of science towards all biomes on a planet from one orbital experiment (maybe requiring a polar orbit to run). A scouting probe in a polar orbit could therefore do basic science over an entire planet, creating the first, faint colors of the biome maps, which could be filled in further by ground missions. All styles of exploration are rewarded by this type of system. Methodical, probe-first approach can faintly identify all biome boundaries before ground missions are planned OR straight to Kerballed landing approach will fill in just the biome that has been explored, leaving the rest of the planet's biome boundaries a mystery until they have also been landed in.

I'm suddenly very glad I never unsubscribed from this thread. Awesome result, Tsevion! That is a high speed "docking" if ever there was one.

I think we'll also be able to change symmetry modes on the fly regardless of which building we're constructing in. So, it basically won't matter which building you use, except that SPH craft launch from the runway and VAB craft launch from the pad.

You could leverage non-steam cloud services. For instance, install KSP within a dropbox subfolder (remember, there's no DRM on the steam version, you can copy or move the install folder to anywhere). Though the sheer size of the installation + mods would likely outgrow the 2GB space dropbox gives with a free account, this could be an option if you already pay for dropbox. I haven't used Google Drive much, but if it's possible to use it the same way as dropbox, I think they offer a whole 15GB of storage tied to your existing gmail account.

Unlocking skippers and 2.5m tanks is a turning point for me. Efficient, powerful, and gimballing skipper cores are simple to build, can carry light loads to orbit almost by themselves, and are wider mounting points for boosters and cumbersome payloads. Skipper Lifters carry me through mid-game pretty nicely.

In order for Kerbals to provide meaningful buffs, there needs to be something to buff... -Engine statistics are off the table, which I'm very happy about for reasons that have been beaten to death in this thread. -Currency buffs are very likely to happen. Most likely, specialists will give currency boosts. Scientists will return more science points (being more thorough), engineers will return more funds (better at maintaining the reusable equipment), pilots will return more reputation (everyone wants to be that guy). These buffs are a little boring; 5% more funds/science/rep on a mission are nice gimmies, but don't radically change much. They are still a good reason to keep experienced Kerbals alive. -Efficiency of systems (like energy generation/drain, science transmission, speed of resource extraction) remains a possible buff, though redundant. If you can just add another panel and 2 batteries, why require an electric specialist?! And you start running into the problem of different Kerbals causing different mission results despite flying the same profile (running out of battery unless you have an electrician aboard). There might be a realism issue here too (how can you make your calculator not run out of battery as fast?), but definitely not as bad as with engine stats. -Control surface reaction speed (mentioned by Maxmaps on twitter) is possible. Would only affect flying in atmosphere, follows physics well enough (assuming the changing deflection of control surfaces is accurate in the sim), and is something a pilot could be better at (pulling on the flightstick confidently). I could buy that, though I could see being annoyed at have the controls be artificially more/less responsive based on the Kerbal pilot. -Certification-Requirements could limit things already available to Kerbals (repairing parts, EVA thrusters, ability to use certain engines or ship systems), but I'd be careful about removing access to features and then calling it a feature. I'm not sold just yet on Kerbals being unable to press "Launch" because they haven't trained on a certain engine. It could be a fun mechanic, but I'd have to see some examples to know it would not cause gridlock or grinding. Further, Flag planting skill isn't a thing, all Kerbals need their jetpack since tethers don't exist, repairing wheels can either be done or it can't (which could be annoying), and I doubt sitting in a chair requires any knowledge. Goofy traits could be fun to have... Bill's a Good Jumper. Bobgas is Flatulent. Lemmy wears sunglasses at night. I definitely wouldn't mind some little details to give character to Kerbals that have no direct impact on gameplay. Autopilot has been suggested as a stock mechanic, whereby Kerbals would be better or worse at flying maneuvers based on experience (with probes perhaps using this mechanic at a baseline level). This would be cool and unobtrusive (since players can use it for convenience, to role play mission control, or manually control vessels at their leisure). This is basically a whole different feature from Kerbal Experience so it's implementation is not guaranteed. Plenty of good suggestions going around. I'm glad I followed this discussion from the beginning.

Wow, I wanted to chime in on this topic. I've been reading through page by page in one window on my work computer during breaks but couldn't get to the last page! Now devs have already responded; talk about being late to the party! I said elsewhere that I didn't think Kerbals should affect rocket performance for an additional reason from what's been stated here: Why bother including an experienced Kerbal? If you want 5% more dV on your rocket... Add some more fuel, maybe? If you want 5% more thrust... Use a bigger engine, or two? If you want 5% more SAS control... Add another SAS unit? Kerbals performing these fine-tune adjustments is redundant and they just become massless parts that fit inside your capsules (as well as throwing an effectively random statistic into rocket capabilities). I feel that engineering should exclusively affect a rocket's capabilities and that Kerbonauts should continue to be funny little explorers whose only experience is being sent on rollercoaster missions by a player's space program. I never came up with any really interesting alternatives for useful XP but thankfully this thread is full of neat suggestions for making Kerbals more interesting. Kudos!

Building on what I've written earlier, and on opinions and responses from others, I've refined what I'm thinking of as the simplest implementation for stock refueling. Some of this may just be a repeat in different words, but hopefully it shows a little more insight. Refueling should be reflective of real-life proposals for ISRU -Players, new and old, draw inspiration from actual space activities and will want to imitate what they see (or should wind up engineering similar missions without realizing it). Having a mechanic that has no basis in reality will confuse players and break immersion. A "YOU'VE RUN OUT OF FUEL! PAY X FUNDS TO CONTINUE!" system would fail this need. (I don't really think this is where Squad is heading, but it is a possible implementation). Refueling should be obvious in its usefulness and in its implementation -Similar to how the CLAW is immediately recognizable and can be used with no prerequisites for capturing asteroids (something in real life that would require much more complexity), a DRILL could be a one part system for handling refueling (handling the entirety of collecting the rocks, performing chemical processing, and pumping out desireables). It's use is immediately obvious and it's benefit (extracting fuel) and downsides (mass, power draw, possible durability considerations) are easily understood. Extraneous parts should be avoided -A new tank (or 3 or 10) for containing rocks (or other raw resource) will not be immediately interesting and will imply that some amount of the player's time will be spent hauling rocks, which have no use on their own. -A converter part immediately follows from having tanks of rocks to provide something to DO with the rocks. Since it is just a chain link between an extraction tool and a pair of tanks, a player will see this only as a requirement and not something that provides a benefit. The simplifying of refueling to a single part does not preclude complexity -Though the DRILL might be just one part, that part's behavior can be made interesting in dynamic ways. Using the DRILL in different places should yield different types of resources. Being able to drill not only on planets, but on asteroids, and maybe even parts (poor Bill!) opens up more places the DRILL could be utilized for fun and profit. -Just because there's no rock tanks and converters does not mean you don't still have to move around all that fuel! If building infrastructure is what a player wants to do, setting up drills in permanent places and creating fuel depots is definitely possible (and useful!). The DRILL sounds like it would be tempting to stick onto any landing vessel since, hey, free fuel! -The DRILL needs to require enough ElectricCharge, be massive enough, bulky enough, expensive enough, and high enough on the tech tree to avoid its use becoming too trivial. I can just get fuel wherever I land, right? -Spreading different resources out across different biomes would make the landing site for a mission crucially important (or necessitate roving solutions). Either by picking a biome that has access to multiple resources, or by straddling the border between biomes to ensure access to both's resources should be a consideration to a player. Liquid Fuel, Oxidizer, Monopropellant, and Xenon could potentially all be found at the same time in one rare biome, but more likely you'd find 1 or 2 resources in each one (or find ZERO useful resources in some barren places). Minmus' flats could be veritable frozen lakes of Liquid Fuel with nothing else present, while MonoProp and Oxidizer could be found up on the midlands, and the slopes might be useless for extraction. Balance discussions now involve deciding which planets and where on them are easier to perform ISRU missions. Having a new mechanism in-game for distinguishing biomes would be useful for this! -If different biomes have different resources, players need to know they're landing in the right spot! So, how do we know which biome to visit? -I'm trying to avoid adding parts and repetitive activities, so I'm hesitant to suggest a scanning mechanism like Kethane's... Instead, we could make use of our various science experiment parts to tell us about the composition of the biomes in question. Materials studies, mystery goo, gravioli detectors, etc. could reveal resources that could be extracted, and since we are already doing these experiments, it would not add any new tasks. It's worth mentioning that revealing the resource would be handy, but the biomes would likely always have the same resources throughout different saves and playthroughs so it's possible to just know ahead of time what will be where (especially if there is some logic to the placement of resources, i.e. Ice=Oxidizer). So, how long is this gonna take? -The action of resource gathering should be instantaneous or at least on the level of solar panel/RTG rates of generation. Time-warping on the active vessel should have the same effect as with solar panel/RTG ElectricCharge generation, meaning that filling any fuel tank should take just seconds of the player's time, while also allowing for in-game time constraints to factor in. Chemicals don't work this way! What is this magic fuel I'm pulling out of the ground!? -Hand-wavium mostly. Some simple flavor text in the DRILL's description could allude to the real-life equivalent chemical processes, but it's really just a game mechanic. Keeping it simple is preferable for the base game, with the possibility that modders can liven it up with realistic variations on the system as well. Maybe I can drill some fuel near the space center and recover it for free money! -Overpowered exploits should be shut down whenever possible. Specifically it should not be profitable to bring fuel back to the space center (or it should take a reasonable effort to get enough resources home to be profitable). I think it would be enough to make the fuels themselves less significant in the overall pricing system, so bringing back a full tank of gas would only net you a little bit more funds than coming home empty. -JUST A DRILL? REALLY? Ok, maybe you can have air and liquid scoops/filters also. They would provide a similar role, collecting fuels from the biomes associated with flying in atmosphere or splashed down. Placing these parts up and down the tech tree could also be a nice way to introduce ISRU abilities a little at a time since each part could be limited in what they could possibly generate. -Why just fuels? Can't we have oxygen and water, too? If Squad brings in life support which requires resources, then sure, this system would work for that too (I personally want the Snacks! mod to be a thing, in which case a greenhouse part with biome requirements would be amazing). I don't know if life support will be implemented this way or at all in the stock game, though. Thanks to everyone for good discussion. I don't disagree that there's more than one way to skin a cat, so feel free to point out further problems and solutions. It may not be that Felipe and crew will be taking ideas from this thread, but it's still great ideas for yet another resource mod... (Maybe if I can squeeze in some time... lol)

I'm very grateful that we have Kethane, Karbonite, and the old Resources system to compare and contrast, since they all bring good ideas to the table: [table=width: 500, class: grid] [tr] [td][/td] [td]Old Resources[/td] [td]Kethane[/td] [td]Karbonite[/td] [/tr] [tr] [td]New Resources[/td] [td]Many (blutonium, water, etc.)[/td] [td]One (Kethane)[/td] [td]One (Karbonite)[/td] [/tr] [tr] [td]Resource Location[/td] [td]Dependant on resource (Eve oceans, Duna ice, etc.)[/td] [td]Land only, at deposits randomly distributed in each new game[/td] [td]Land, oceans, atmospheres, orbital locations, with varying concentration[/td] [/tr] [tr] [td]Resource Amounts[/td] [td]Infinite[/td] [td]Finite[/td] [td]Infinite, with variable extraction rate based on concentration[/td] [/tr] [tr] [td]Method of Discovery[/td] [td]None, resources always exist in the area they are found in[/td] [td]Scan reveals resource over time by an active vessel traversing[/td] [td]Scan done instantly by an active vessel with scanner part[/td] [/tr] [tr] [td]Resource Visualization[/td] [td]None, resources always exist in the area they are found in[/td] [td]Map view overlay over celestial body toggled on/off through toolbar[/td] [td]High concentration nodes in map or flight view, toggled by scanner part[/td] [/tr] [tr] [td]Conversion Method[/td] [td]Various parts convert different resources[/td] [td]One part type converts from Kethane to all other resources[/td] [td]Two parts convert from Karbonite to other resources[/td] [/tr] [/table] Let me know if I'm misrepresenting something, please. [Minor Edit: Fixed the Conversion Method for Karbonite from one part to two, as per Northstar1989] [i may have been ninja'd a little, since this took time to think and write, but here goes my own idea:] My opinion is that Squad had the right idea on resources being tied to where you were extracting (and it being essentially infinite), but having so many different resources that do nothing on their own and each requiring a different collector, container, and converter parts was the complexity that killed the fun. Both Kethane and Karbonite implement only a single resource and single type of converter to remedy that problem. I think that the ideal simplified system would not require all the added resources, special containers, collector parts, and converter parts. Instead, a single part could perform the act of creating a single, already existent resource when in the right conditions. This removes the need for new resource types, a range of tanks in every size category, and the need for converter parts. Solar panels are already a resource collecting part with a requirement that the sun be shining on them. It's not too hard to envision a part that creates Liquid Fuel when active in Eve's ocean or Oxidizer when active over ice on any applicable planet or moon. There's some heavy hand-waving to be done regarding the chemistry involved, but I think this system would fill the need for NASA-style ISRU. Travel to Duna, carrying only enough oxidizer to get there and land (saving weight on the vehicle), then use the ice cracker to restock oxidizer in order to go home. Balancing the generating part would be the trick (it has to be lighter than the oxidizer ordinarily needed to be worth bringing!). You might think this system would preclude any need for processing plants, but if the collector parts were substantial enough, it would be beneficial to continually reuse them in place, leading to potential surface bases and/or orbital projects with dedicated landers making repeated trips up and down to restock their station or mothership. The useful fuel can then be transported to where it is needed with tanker vessels using all the parts we already have available. This system would require careful planning of what fuels can be collected where (biome dependent?) and what the parts that do the collection would cost in terms of mass, bulkiness, their own fuel requirements (electriccharge?), funds, and tech tree progression. Ensuring multiple fuel types cannot be gathered from any one location would encourage the development of infrastructure. Oxidizer processed on Mun could be combined with LiquidFuel from Minmus at a mining station set up between their orbits where Rockets destined for interplanetary missions could fuel up. Since monoprop thrusters/engines are generally the least efficient engines (except for the new massless, cheating one, hope that gets changed!) this fuel type could be more common than others, making some monoprop-dependent designs more desirable despite their inefficiency (creating a new niche for existing parts). Xenon could be interesting as a resource collected exclusively from atmospheres, but it might be tricky to balance with the huge dV capacity of ion vessels. Just some ideas to contribute towards a solution to a proven-difficult problem.

They're also in a no-win regarding the choices of features to work on in beta/release/post-release. Felipe himself summed up the inevitable response to the announcements: The community clearly LOVES KSP and can't get enough of it! Unfortunately, Felipe admits that Squad only has so much manpower at its disposal: In order for a release to ever happen, they need to prioritize only the absolutely necessary features for the game to be "complete". It's really important that they move the game out of the "Early Access" status so that sales can climb up and give them the capital they will need to continue further development. If it seems like they are cutting the feature list short, that is why. Luckily, Felipe makes it clear they intend to continue adding to the game long after release. The above is observation, the following is opinion: I'm extremely happy with how Squad have handled things. I empathize with their small-team efforts and believe they've made responsible, professional decisions on where to apply their limited development resources. They've managed to have a very tight relationship with their community, improving communication over time and addressing issues as they arise. Any mistakes they made along the way were handled well and have clearly helped to guide their later decisions. Maybe they could have a better game design process or could have better communication then they do, but I can't possibly say they've done a BAD job (or even just MEDIOCRE, judging by how much I (and seemingly many others) have enjoyed their product so far!). And I think I've gone off topic, but I'll post the above anyway. On-topic: I love everything they've announced, and like everyone else just want more details on specific features (Kerbal XP, aerodynamics changes, ISRU). Editor adjustments are welcomed greatly and I can only hope the tycoon elements of the game become more fully formed (Yay FinePrint integration!).

LOVE THIS UPDATE. So much good stuff coming. On the topic of Kerbals affecting flight performance: While it sounds nice at first (my rockets fly BETTER as my Kerbals survive more disasters!), the truth is, I (the player) actually do all the flying, with the Kerbals screaming (or grinning) in the little PIPs in the corner. From a role-play perspective, sure, you can say that Jeb is in the pilot seat, but unless there's an automated flight system on the way (I doubt it), he wont ever have to prove his mettle by landing my spaceplane for me. Understanding that I'm the pilot and my skill is what matters: If I fly 2 different missions with exactly the same craft and same control input, I should get exactly the same results; which would NOT happen if some of the craft's capabilities rely on which Kerbal is at the controls. Consider the situation where Jeb increases thrust for all SRBs due to his Moar Boosters trait (yay!). On first launch, your rocket gets to orbit (yay!). Even cooler, Jeb's Moar Boosters skill got even better after the first successful mission (yay!). Thinking you have a really good design, you go to launch again. This time, your rocket fails to achieve orbit (huh?). You realize that the SRBs were wasting fuel by pushing too hard against atmosphere now that Jeb is causing them to burn even harder, causing you to lose dV and not achieve orbit (yes, you can have too much thrust). So you have a good laugh at how silly Jeb can be and try Bob, who has the Moar Science trait, instead. You launch but this time you find your SRBs are putting out LESS thrust than your first flight which ALSO causes you not to reach orbit. even though all 3 situations use the same craft (and 2 use the same pilot!), you wind up with 3 different results, only 1 of which is what you planned for in the first place. This problem extends to craft that I download from someone else. I shouldn't fail to make orbit just because the craft author designed it with a level 100 Kerbal at the helm (which of course is not downloaded with the craft). Thought about another way, giving Kerbals flight performance statistics means we would end up treating them like just another rocket part. I.E. this kerbal adds .05 torque to reaction wheels and this other kerbal effectively adds a free 10 units of fuel. Maybe this isn't so bad, but I feel that engineering problems should be solved through good design and not because you sat a wily Kerbal in the command chair. I'm NOT saying I don't want kerbals to gain experience or track individual achievements. I would LOVE that actually. I just don't think they should have any impact on flight characteristics. Instead, find other things for them to be good at: science processing, limit repair actions to engineer-trait kerbals, give additional rep when a famous Kerbal plants a flag, I dunno...

Welcome to the club! It sounds like you're off to an excellent start! I've been stuck playing since May! Answers: - The science building does have an overview tab which will show what you've gotten so far and from where, though it won't outright say what science you haven't gotten. - Not by default (as of the current version). Craft or debris that are in atmosphere (not on ground or in vacuum) are automatically destroyed about 2 km away from your active vessel. This includes craft on suborbital trajectories that are not in focus. (Note that there is a quirk (bug?) of the game that allows orbits of non-focused craft beyond 2km from active vessel with periapse above 30ish not to be destroyed or encounter aerobraking despite technically being within atmosphere). At least one mod (I think there's another if you search around) allows recovery of non-focused stages and craft provided they have parachutes and/or fuel and engines capable of landing themselves: http://forum.kerbalspaceprogram.com/threads/86677 - Squad is adding a few more Kerbal characters in the next update, so hopefully a friendly Chris Kerman will come along some day (along with customizable Kerbals, maybe?): https://www.shacknews.com/article/86391/kerbal-space-program-introducing-administration-building-to-career-mode