• Content Count

  • Joined

  • Last visited

Community Reputation

52 Excellent

About Scourge013

  • Rank
    Bottle Rocketeer
  1. OBS is the awesome sauce. It meets all your it seems you'll have plenty of help on the forums based on the sheer number of users who are using it. For video editing I, I use Windows Movie Maker. Okay, now that you are all done laughing. It's fairly friendly to use. It's free. It has cloud storage so I can work anywhere. And since I only really use it to cut out "boring" parts of the gameplay and maybe slap a title card on the front or back of the video, it's perfectly adequate. OBS allows me to record audio right at the same time as the video, so when using OBS you don't need to worry about syncing up the audio or anything like that. It really is the one-stop shop, OBS is. Always record your narration live while playing and you'll not really run into any trouble... If you are going to be making your own intense CGI cut-scene and audio balancing multiple audio sources taken at different times from different equipment (say the game audio from OBS, and then a recording of your narration from a mic using some software other than OBS), then my vote goes to Final Cut Pro. An individual license for Final Cut isn't that bad it comes for Windows and Mac.
  2. Long term lurker, few time poster. But I've followed KSP's development closely since buying the game (since version 18 something or other--the build before going to Steam IIRC). I've been around a while in other words. While "hating" Squad is certainly inappropriate, Squad has done some things that deserve criticism...and despite that criticism being structured, persuasive, and, well, prominent in the KSP community, Squad hasn't been very receptive to it. This does deserve frustration on the part of the community towards Squad. Not hate. Frustration. Similar emotions, perhaps, but ultimately very different. Long-timers like me might be frustrated at some persistent patterns of behavior that Squad has refused to change despite being detrimental to the ongoing KSP project. Here are the behaviors as I see it/heard others describe them: 1) Closed testing of Release Candidate builds. In a lot of respects, the run up to 1.1 was the ONLY time Squad did it half-way right...they released a public Beta branch on steam to collect information on bugs and hiccups from the general KSP community to get fixes in. For most of the game's life, release candidate-type builds were only made available to a select few Twitch and Youtube personalities, who were mostly under non-disclosure agreements. There are some pure testers in the "Experimental" group but whatever playable experiments they are doing, too, remained under wraps. Their job (Experimental testers, particularly the media personalities) seems to be not to test the game, but to create media showing a more or less bug free experience, to promote the game and the new features coming out in that update. Many times I recall certain personalities explicitly mentioning that they'd encountered bugs, but refused to elaborate saying that they've told Squad of the bug and expect it to be squished by the time we ordinary folks get the build. Who knows how much follow through there was on that. It's very frustrating to watch promotional content instead of gameplay content. 2) Despite testing, critical bugs affecting basic game play slip through into almost every build...and lay unaddressed for months. A prime example would be the bugs with the temperature gauges from 1.0.x. The new heating concept was one of the major (and completely untested in terms of the larger KSP community) features in the 1.0 update. The very thing that would let you know you are overheating CAUSES THE GAME TO CRASH. A single play-test launch of a re-entering rocket seems like it would have caught the issue...seeing as many players encountered the bug literally on their first post-update launch. I remember a very frustrating Twitch stream I was doing on launch day playing the same launch over and over and over until a helpful chat member told me that I needed to turn the gauges off because they caused a critical memory leak. This bug existed FOR MONTHS and essentially removed a critical part of the game from the experience for that whole time. Very frustrating. 3) Engine Denial. KSP's vision was always too grand for a 32-bit game. There existed an opportunity for a good long while to use Unity 4's 64-bit engine and/or Unity 5's engine almost a year before 1.1 even started work. Squad appeared to hem and haw at the idea of upgrading the thing, despite the smoother experience this would have created for users--and I'm not including the users who would mod the game--I've always considered people who mod the game to exist outside of valid complaints in regards to KSP stability. But still, extending Early Access to implement a new engine was a realistic expectation, but they reflectively chose not to do it, for reasons that still elude me. 4) Recent KSP build create that unique "I wish I had something I already have" feeling. At least for me. When I first came here I had a game, that while less feature complete, was much more polished. Sure there were bugs in all versions of KSP, but right around when they introduced the Science-only career mode, the game was pretty good. It was well polished...the bugs were present, but didn't get in the way of every trivial or routine task. They weren't something you had to deal with until you stumbled across them by accident. And you could always revert your save and deal with it that way. Now the story is different. Bugs are present in EVERYTHING. First it was re-entry heating and the heat gauges mucking things up...something you have to deal with EVERY time. Now taking off and landing a plane or just driving a rover around, the new wheel system is terrible (and what's more is that there were previous incarnations during the beta-phase of 1.1 where wheels seemed objectively better to me...). I find myself pining for previous versions of the game, just before version .90 where bugs were less in your face. It's very frustrating to see the game experience decline so dramatically from what we can remember. So yeah...I don't hate Squad. But I'm frustrated with them. I haven't played KSP for a long time in a long time. Just little sessions every now and then...I encounter some well-documented bug on the forum and stop playing days or even weeks in the hopes the game updates. But I know from experience it will be months. That the community at large won't play test the update and that ultimately I'll be drawn back to the game by a heavily edited Scott Manley video, only to experience disappointment that some glaring technical issues were created or remain unfixed. How else would you recommend that I (and others with a similar viewpoint) feel towards the developers?
  3. I spent many years as a coach of a collegiate Debate Team. I mention this because I call things as I see them. So here's how I see this: Thoughts on the OP: I did not read all of your post. Not because it was "sciencey" but because after your direct and helpful tl;dr, I found your tone to be dismissive and rude. I heartily suggest that the next time you want to write a persuasive argument about something controversial, you put the air quotes and sarcastic references to rocket science and magic away and use the good ol' fashioned three step Refuation Model: State the claim you disagree with, state your position (and NOT how you feel emotionally), present your observations or other evidence, explain--with reasoning--why your observations or evidence supports your point of view. People will be more likely to take your point of view seriously. Side notes that I think all of us should keep in mind: Opinions on a topic are subjective--they rely more on personal experience and frames of reference for their formation and validation than reality or truth. This is why scientists insist on reproducible experiments that can transfer from culture to culture and person to person--people need to have the same personal experience with reality, usually, in order to agree on what reality or the truth is. However, the controversial nature of a topic is objective. Ironically enough, the fact that people use facts to support their respective positions is what makes two sides of an issue controversial--and that controversy isn't going to go away just because you have facts to back you up because again...everyone has facts to back them up. It's like an academic Mexican Standoff if you will. Everybody has the rhetorical equivalent of loaded guns pointed at each other and the situation is not likely to get any better just because you personally have a loaded gun. Being dismissive in that climate is only going to provoke someone to pull a trigger. And that's going to make things very messy. Until consensus is reached, this topic will be controversial and needs to be treated with care by all parties so that there is less shooting and more experimentation and common experience being shared. Summation of the issue: Clearly, the OP thinks that LV-N heating is not a big issue because wing parts circumvent the mechanic--obviously the OP has done research to demonstrate how subjectively easy the OP feels this is. While others feel a mechanic that, in practice anyway, requires aerodynamic parts designed for lift in atmospheres to be used on a craft that will only ever be in the vacuum of space to be laughable regardless of how easy it is--this is also a fact. Except for their apparent heat radiating qualities, wings are just extra dead-weight mass on a deep space craft. This is especially troubling considering how many deep space craft designed by the community are "min-maxed" to get the most delta-v and adding wings will interfere with that. My thoughts on the controversy: I think what we need now is some experimentation that attempts to compare the relative efficiency of a craft with an LV-N and wings for radiation versus a reasonably similar craft with an LV-N and no wings, but thrusted down such that the engine won't explode if left on unattended. But first we have to agree on what "efficiency" is. Is it total delta-v? Is it ease in playability? Is it something else? In order to form a consensus about efficiency we are going to have to do whole lot of writing and thinking about--okay, you know what? [Cynicism]This whole scholarly attitude on controversial issues thing is too hard. The last time I had to put wings on a vacuum-only craft to get it working was when I had to put wings on my Mun lander because there weren't landing legs yet. This ain't no 1.0.x release, this be Beta .91. Derp derp, Squad, derp derp.[/Cynicism] [serious Mode] Though for what is is worth, I did find radiators an interesting design challenge and mechanic on the Interstellar mod. I would not be upset if Squad added radiator part(s) in a subsequent title update. Even if requiring them for a LV-N is apparently unrealistic, I feel it'd lead to more interesting design decisions. Quite frankly, I could go either way on this because I also feel LV-Ns should also work out of the box without support parts given the gamey nature of...uh...the game.[/serious Mode]
  4. I'm currently play-testing TAC Life Support (IMO the most advanced and well balanced--mix in USI Kolonization and you have a very rich experience!). I've not had any game breaking issues. The big limiter as far as Kerbal Rescue contracts go is Electricity. In TAC Life Support, the command pods alone get 3 days of each resource...except electricity (to run the heaters necessary to keep the Kerbal alive). You only get about 2 hours and 30 minutes of that. But the Kerbal can survive upwards of a day without the heat. While this would seem to be a limiter, keep in mind that it only takes about a day to get to the Mun. So pretty much any Kerbal in Kerbin's sphere of influence is going to survive long enough for you to rescue. If the Kerbal is beyond or near Mun's orbit, you just have to bring some more Delta-V and be more aggressive with your rendezvous. Also keep in mind the Kerbal doesn't spawn until you accept the contract. With the new difficulty of 1.0's rescue contracts, plus the common sense nature of my travel agency program, staging rescue pods controlled by probes at various orbits around Kerbin, Mun, and Minmus before being offered rescue contracts is also a wise strategy. I don't consider that gaming the system. NASA had plans like that when they were designing a moon base in the 70's I believe whereby there'd be several strategically positioned pods supplied with food, water, and oxygen should something go wrong on the base on the Moon.
  5. This is basically the system we already have--and it doesn't work. What they need to do is keep the Experimentals and Q&A teams more or less as they are, but leverage the Beta option on Steam more effectively. After the Experimentals and Q&A teams have at the game, use the Betas tab in Steam to release a "Pre-Release" build based on that smaller team's feedback. This build is open to the whole community, but doesn't force anyone, at least for the moment, to use it. Anyone who is interested opts in to the Beta, plays it, and provides feedback on a public Beta Builds forum that the devs watch closely. Minecraft, Project Zomboid, StarMade, Subnautica and other games use a system just like this and their respective communities really appreciate it. Not sure why Squad doesn't--maybe it will "delay" the process of updating? But Squad is independent. They make their own deadlines and like Blizzard can say to the community "It's done when it's done, now test this sucker for as long as you can." That way there is an ever-increasing pool of testers from truly all segments of the KSP community critiquing the game. At least for me, things like the 1.0 release heatshield bug, while annoying and seemingly obvious, aren't the issue--it could have been an honest mistake toggling a flag that shouldn't have been toggled while addressing other Q&A feedback literally moments before pushing the update. The issue is huge balance revisions that increase the drag for every part across the board that can or have the potential to render whole fleets of rockets useless across the entire player-base with no warning. The Steam Beta tab feature is a way to work around that while experimenting with the balancing of features. Hot-fixes and bug fixes are good...across the board gameplay balances implemented with no discussion (even if they are marketed as "fixes" or provide a "better" game) are not so much, regardless of whether or not it takes the game in a favorable dimension. If Mojang for example wanted to "fix" building in Minecraft by incorporating a physics based structural integrity simulation, while making people craft a "cement" item to make placed blocks stick together if they don't have direct contact with the ground (i.e. no more floating houses in the sky), the game might be more fun because it involves management of another resource and also make the game more "realistic". However, whole structures across the entire player-base would come tumbling down. Mojang, however, before they implemented such a game-changing feature would release it during their opt-in Pre-Release build phase the whole Minecraft community can take part in. For some reason Squad makes similar game changing, uh...changes, but does not involve the community in this manner, using instead a very small group of players relative to the ever-expanding player-base.
  6. I don't think you have quite understood my point. It's not that we literally don't know how to play the game. I for one, have at least 1,000 hours playing it. 700 on Steam and at least several hundred undocumented hours in "offline" play and earlier versions. Most of this time was broadcast on Twitch as well. I'm quite familiar with the game and its mechanics and have been an active, if somewhat irregular part of this community for years--just not on the forums. My criticism isn't leveled at "Oh, woe is me, I have to redesign my fleet of rockets because of the new Aero or Ore Tank changes." If I may put on my monocle: That feat is done easily enough for someone at my skill level. My criticism is that I have to. The game is no longer Early Access. Release builds of the game should no longer be treated as mass testing or gameplay balancing versions. The game should be stable both in terms of software bugs and gameplay practices. For the Record: No software is going to be bug free...but at least for me, that's not the issue in my criticism of the process since 1.0 hit. I'm going to go back to my card game analogy for these changes. KSP has always been a game about flying rockets to space. Poker has always been a game about having a stronger hand. However, when one changes the aerodynamics model on a week to week basis, which is well before many of us can complete a career play through, it's like going from Poker to Texas Holdem while still playing the same round. They are both undeniably similar games, but also undeniably different. How are we supposed to play when the rules keep changing so drastically? This is a direct result of Squad failing to use their chief advantage of having a game in Early Access: the sheer amount of people willing to test the game. It's why I bought the game in Early Access. I understand the need to have a smaller team test the game to make sure the product pushed to Steam isn't all regression, no progression. But once a build gets to that point, it should be provided to the Early Access community. I seem to recall a poll on this very forum asking this community if KSP should go from .90 to 1.0. And the poll was decidedly against that. By several hundred votes. The issues we are seeing now with the game aren't the result of Q&A or Testers, but of a failure by the developers to leverage the advantage of having an Early Access community. They should have released components of what eventually became 1.0 to the wider Early Access community gradually over several builds. We could have critiqued the game over the past several months constructively and had a 1.0 version that doesn't change rules or core mechanics from week to week. Early Access builds of any product are supposed to change rules and core mechanics--and frequently. If people were to complain, that's too bad for them, because they don't understand Early Access. We have now had more updates in a single week than we did in the past four months. These updates change the way you have to play the game. These are not bug fix releases--they are core changes. The game is now in a different phase of its life. It's supposed to be "done." And its gameplay and underlying systems should not be revised as drastically as they have in the past week. These revisions are necessary...but they are the result of not doing Early Access properly. It makes it difficult to play the game, not because the game gets harder or easier...but because we don't know if we are doing Poker rules or Texas Holdem rules. At this juncture, Squad needs to pick one and stick with it--and also tell the community not to expect an update to the mechanics in question for a significant amount of time so that we know it's "clear" to start a serious long-term play through of the game.
  7. Let me preface my comments by saying that I too find the criticism of the volunteers who do Q&A and test Experimentals by saying that I find the underlying attitude behind these complaints as negative--not constructive, and that this negativity is both unbecoming and out of character for the general tone of this community. I see no real justification for this. However, having said that I feel the following also needs to be said: Much of the invective and frustration directed at the 1.0.x releases is, well, a bit justified.'s the thing. 1.0 is supposed to be the finished product; the "fulfillment of the original design document's vision" as Squad kept saying. Why then, are core aspects of the game being fiddled with? After a game or software hits 1.0, only minor revisions are supposed to come out OR there's a long time between significant updates that do more than fix bugs. With the aero and ore sotrage tank revisions in the past week, the game is essentially a different experience in 1.0.2 than it was in 1.0--this makes these updates a major revision, not a minor one. And the time between these two versions is less than a week (let's not mention there were just hours between 1.0.1 and 1.0.2). It doesn't matter if I like or dislike these changes (I agree with the changes, by the way, before you all lump me in the category of people who just need to shut up and L2P). My frustration is that I invested dozens of hours in a game that was working under a rule set that was a lot like Poker, and now, just days later, the game is more like Texas Holdem. It's still a game about drawing cards and having the best hand--KSP is still a game about flying rockets into space--but the impression of the overall experience is entirely different. Nearly all all my designs that worked in 1.0 no longer work. This would be a small niggle...except that the gameplay is supposed to STOP evolving past release and remain more less static until "DLC" or explicit expansions start being released. Why? Because the beta testers were supposed to have at the game and provided balance feedback well before release. Who are these mysterious beta-testers? We are. The whole community who bought the game in Early Access. See, these are the kinds of game-changing and "frustrating" experiences we Early Access users understood we had bought into. In Early Access, I don't have a complaint when I say "Man, I had to redesign my entire fleet of rockets." It's because Early Access games are supposed to change the fundamental experience of the game--and frequently too. Instead updates were months in between and rigorously tested well before released to the Early Access crowd and the game remained static between updates. Updates were also relatively small in scale. Adding a few parts here and there, and major mechanics like the Science system and Career mode were gradually introduced element by element. These mechanics are the strongest elements of the game by far. Why? Because the whole Early Access community was testing them well before official launch. The post-release situation is essentially different. We've had more updates in one week than we've had in four months. That's backwards. We should have been spammed with updates as a whole community in the month or so prior to full release. The fact that the game has received two updates in a week that majorly rebalances the game indicates that it is not currently the "fulfilled vision of the design documents." And that is irritating--because now the game is supposed to be "done." The whole community should have been testing the new aero model and heating system. The whole community should have been testing the resource gathering mechanics and parts and their balance with the fuel tanks. These are components of the game that should have been released during the beta phase. Q&A testers and the Experimentals aren't at fault for's Squad's decision making regarding going from .90 to 1.0 in one big update. And while bashing them too is not the correct way to deal with this frustrating situation, criticism of the developer's decision is very much warranted. I guess what I'm trying to say is: Don't criticize the Q&A people or the Experimentals testers. Criticize the system for these things that Squad designed. Squad had legions of volunteer testers in the Beta versions. They were the Early Access player pool. Squad deliberately and intentionally decided not to release code to this player pool. Why? Because a release version that was essentially just a bug fix version of a Beta .99 that had the new aero model, new thermal system, and resources couldn't be hyped so much. And that's because there wouldn't be many shiny new gameplay elements to "reveal" to the community. We would have had them already and balanced them out to perfection. But that's exactly what a game release version should be--a small iterative step between a nearly complete Beta version and what you are asking a premium price for. The polished finished product. The kind of product that has had its gameplay niggles and overall balance critiqued into to the ground before the big day. That's not what we have. We have a game that will likely receive patches week after week until it is acceptable. And those of us playing the game will experience rule set changes frequently enough that we might just get frustrated and stop playing. Nothing is wrong with Poker or Texas Holdem. But gosh darn it, there is something wrong when the average person doesn't know which one they should be playing. And that's what it feels like since 1.0 hit. It's not that the changes themselves are bad. It's that I don't know how to play the game because the rules might be different next week. This kind of instability is appropriate for Early Access. Unacceptable for a 1.0 version.
  8. I feel I have to chime in, here. The only context I've heard Harv rail against time-based mechanics was when people were asking for a rocket build-time. His rationale, if I recall, was that especially early in the game, having the game make you WAIT to build a rocket didn't make sense, because it was essentially using TIME as a way to keep you from actually playing the game. Especially early game, you usually have to launch one flight at a time because the parts available rule out the longer term interplanetary missions. In other words, If you have no rocket to fly or other flights to fly in the mean-time the game was basically dipping into the cesspool sludge that is "Freemium" gaming. Maybe he shouldn't have said "Time-Based Mechanics" and said "Wait-Based Mechanics." Sure, at a different point in the game, having you wait to launch rockets when you have other flights to manage might be "fun." But the reality is, the way the game starts, it would just encourage the player to mash timewarp rather than manage a schedule or make interesting emergent gameplay-type decisions about missions. However, this change to the Science lab, is not of the ilk that Harv had railed against and so often. It's more a mechanic to make the player invest in infrastructure-- to give purpose to those pesky one-off contracts that you could launch and forget. If you want the maximum science yield of any body, including Kerbin itself, you will have to invest a Scientist Kerbal and some expensive hardware to get a big ol' heavy science lab in orbit of whatever body you are studying. Time is just used as a way to keep the player interacting with this new sciencey space station--a way to keep you checking up on it every little whip-stitch rather than timewarping to maximum yield then forgetting about it. In fact, the fixed amount of science per transmission coupled with the science decay is a mechanic that is supposed to discourage this type of behavior. They are trying to keep the player invested in checking in with and interacting with stations they create. It's going to be a lot more efficient science point-wise to manage your flights and make a schedule of when to check in with your science stations than it would be to run a "huge" one-off science spam mission to whatever body. This essentially makes an efficiency-minded player make an emergent gameplay decision on when to launch science missions and what kind of insfrastructure they should take along for the ride. No more Stayputnik probes that can "do it all." We have to invest our funds in infrastructure now. The fact it uses time to encourage this higher-level gameplay is more a point of necessity...almost a coincidence. This is not a "Wait-Based Mechanic" like Harv was talking about earlier--it is totally optional if you want to play this way, plus you get the benefits of having a science lab immediately without needing to wait an arbitrary time for its primary functionality to come online (that is a higher transmission value for science and refurbishing of experiment modules). As I understand this change, no "apology" necessary...because he's not being a hypocrite. This is a different type of mechanic/gameplay goal entirely.
  9. Just wanted to mention in case anyone is subscribed to the thread: I have updated the scores. Please let me know if you believe there to be an error.
  10. Hello Forums! Long time lurker and reader, first time challenge creator. Also, I've streamed KSP on Twitch for like 500+ hours. Don't call it a first post, I've been here for years. That seemed funnier before I wrote it down. Anyway, I've been working on a little project since teaching keeps me from my usual shenanigans. For some reason, it got into my head that I could design a Single Stage to Mun spaceplane. After looking at the forums, I saw that there was indeed at some ancient time a challenge related to this endeavor. However, it was several versions ago (like in the days of .19 or so) and it had some pretty arbitrary restrictions that I didn't like (such as restricting certain engines or flat-out stating that you had to cut your turbojets off at a predetermined altitude, etc.) Plus the scoring, and therefore the planning/playing of the challenge involved math. After finishing my PhD dissertation that involved using statistics, I have concluded that math sucks. I have therefore re-written and expanded the original challenge to be less restrictive and more fun (read: requires no math for me to score or for you to plan your scoring). Wait, KSP and no math? That's crazy! But being crazy never stopped me before. Instead the basis of scoring AND the challenge itself is to create a single-stage craft capable of doing certain things during a mission. Let's call these "Achievements." Instead of having a big windy description of what I want you to do, we'll embrace the sandboxiness of the game itself and let you choose which Achievements you want to try for/think are reasonable for your skill level. The person who can bag the most Achievements in a single mission wins. In the event that multiple people do all the achievements in a single mission, then we shall have a lot of fun, because that's a lot of playing this wonderful game. The list of possible achievements can be expanded as people give feedback on the challenge. In cases where achievements are inclusive then both achievements are awarded. For example, if you achieve "Return to Sender (land on the runway/within the boundaries back at KSC intact)" you also get "Down Home on the Terrain (return to Kerbin's surface intact)." See? Two achievements for one--Blast! I just realized something. Scoring this challenge will require addition. Oh well. Nothing is perfect. Ground rules: 1) a) Stock parts only. *Exception for .24.2: You may use Spaceplane+ since that will soon be added to stock.* .25 and higher should use only stock parts. Craft must be a single stage controlled by action grouping if you need to switch between engines. c) It can be either a spaceplane or a rocket or a hybrid of both (i.e. a VTOL). d) No refueling allowed. The only direction fuel may flow is out of your craft. 2) You may use Kerbal Engineer Redux. 3) You may NOT use Mechjeb (at least for piloting--using it in the VAB/SPH is fine). 4) List of acceptable mods not lucky enough to get their own line in the rules: TAC Fuel Balancer (or equivalent). Docking-Camera or Docking Alignment Indicator. Enhanced Navball(s). Anything that adds ONLY visuals or sound effects (Texture Replacer, EVE, etc.) ScanSat. RasterPropMontior. Basically anything that doesn't add fuel tanks and engines or too much difficulty (or ease). This is to make entries comparable. 5) FAR and NEAR are allowed, but will be recorded on their own score board. 6) With the exception of payloads, you may not detach anything from your craft. This includes "Litho-staging" spent tanks or engines by scraping them across the terrain in a controlled fashion. This also includes using over-heating to discard tanks/engines. This also also includes using action groups to "Jettison" engines. Any attempt where a craft loses parts is considered a failure. 7) A payload must have mass and (at least conceivably) serve a purpose. This means a "payload" cannot be a Kerbal in a capsule that you will transfer to a station, as said Kerbal won't add mass to the craft. Acceptable payloads include but aren't limited to: Fuel tanks with docking ports left in an orbit (as fuel depots FOR OTHER CRAFT). Mapping or communications satellites (even if comms don't matter in the stock game), science modules that you literally drop onto the surface, mini-drone-based-lander-thingies (you know what I'm talking about), or perhaps a little rover for Kerbals to tour around in. Again it must: serve a conceivable purpose and have mass. 8) All landings must be done with the main craft--no sending a dockable lander! 9) To submit your entry take a screenshot or video of any of the achievement conditions. Make sure the UI is displayed and Resources Panel is visible. Make sure the screenie makes sense (i.e. take a pic of the map screen showing your Ap and Pe if you are trying to prove you have a stable orbit). That's about all I can think of for now in terms of ground rules. Here are the achievements: It's a Bird! It's a Plane! No! It's...Well, it's a Plane. (your craft is flyable as a spaceplane during your mission). Rocketeer (your craft is flyable as a rocket during your mission) I am Sir (or Lady) Mix-a-Lot! +3 (your craft can take off and land horizontally AND take off and land vertically during your mission) I'm on a Ship! (Your craft is Kerballed). I'm Here, I Can Steer, Get Used to It! (your craft doesn't rely on torque to navigate through the atmosphere) Note: The word "rely" is the key word here. This doesn't mean "not use" but it does mean you don't slap "excessive" amounts of SAS on your 5 turbojet spaceplane to counteract asymmetric thrust and/or drag forces. I Can See My House From Here (your craft achieves a stable orbit around Kerbin during your mission). It's a Small World After All (your craft achieves Keostationary orbit around Kerbin during your mission). I'll Just Put This Here (your craft delivers a payload on a stable orbit or deposits a payload on a celestial body). Goo-Goo Daddy-Oo (your craft could use Mystery Goo at least once during its mission). Materially Immaterial (your craft could use the material bay at least once during its mission). Hot or Not? (your craft could use a thermometer at least once during its mission). He Who Felt It Dealt It (your craft could use a Seismometer at least once during its mission). Under a Lot of Pressure (your craft could use the Barometer at least once during its mission). Aww...I Wanted Ravioli (your craft could use the Gravioli detector at least once during its mission). I Feel It Coming In the Air Tonight (your craft could use the Sensor Computing--nuts to it, the nose cone ma-bob, at least once during the mission). A Miracle of Science! (your craft can perform all of the science experiments at least once during your mission). I Could Do This All Day (your craft can recycle all expendable experiments during your mission i.e. it has a science lab on it). Ground Control To Major Bob (your craft can transmit science data to KSC). A Souvenir (you take a soil sample from the Mun). It Tastes Like Burning (you take a soil sample from Minmus). Out of This World (you take your craft to a different planet's SOI). I Hope I Don't Forget It (you leave a payload in orbit around a different planet or a moon of a different planet). Son of I Hope I Don't Forget It (you leave a payload on the surface of a different planet or a moon of a different planet). A Romantic Rendezvous (you dock with a space station or other vessel during your mission and transfer fuel to the other vessel). Ion? Try I-OFF! (you do not use Ion engines). Don't Kiss Me, I've Got Mono (you use the new Mono prop engines during your mission). Conscientious Objector (you do not use Nuclear engines or RTGs during your mission). The Propulsion of Tomorrow...Today! (you use Ion Engines on craft during your mission). Fallout 4 Confirmed (you use Nuclear Engines or RTGs during your mission). Note: These last few achievements are added to balance play-styles. It's balanced so that you either 1) are encouraged to not use the super-high ISP engines OR 2) you are encouraged to use as many different fuel-types as possible. Either way, it should hopefully encourage some "emergent" gameplay not typically seen in our community. Leave Nothing But Flags (you land on a body other than Kerbin, dropping off and RETRIEVING the same payload, taking it with you). Seeing the Sights (you visit two other planet's SOIs during your mission). Leisure Cruise (you visit three other planet's SOIs during your mission). The Gold Package (you visit four other planet's SOIs during your mission). The Platinum Package (you visit five other planet's SOIs during your mission). Science Boat Diplomacy (you visit all six planets' SOIs during your mission). Jool of the Orient (you land on Laythe during your mission). Moon Hopping I-IX (you at least get a stable orbit with one or more Joolian moons during your mission (additional plus ones for landing on each moon for a total of 9 achievements (10 if you count the "special" achievement for Laythe). The Easter Bunny (you visit at least one easter egg during your mission). Oops Voucher +0 (you experience a catastrophic failure during your mission and you do not want to reload and continue--your entry is complete but this does not count towards your achievement total) A Three Hour Tour +1 (you get stranded in an SOI other than Kerbin's during your mission--your entry is complete, counts as one achievement). Close But No Cigar-Shaped UFO +2 (you get stranded in Kerbin's SOI during your mission--your entry is complete, counts as two achievements). Back Home on the Terrain +3 (you return to Kerbin's surface intact--your entry is complete, counts as three achievements). Return to Sender (you return to KSC, either on the runway or within the 100% part cost refund border--your entry is complete, counts as an achievement, giving you four total achievements for your return since you also get Back Home on the Terrain +3). I am the Greetest! (yes, that's spelled get all possible achievements in one mission, save the ones dealing with exclusive propulsion methods or failed return attempts (i.e. you do not have to get Ion? I-OFF! and The Propulsion of Tomorrow in the same mission and you MUST land at KSC). Note: Hey...every classic sandbox game has to have an achievement that is unreasonable. That's how you know it's a classic game. How to submit your entry (again): Take a screenshot showing the UI and resources panel every time you, well, achieve one of the above conditions. Make sure the screenshot is proof of your accomplishment. I.e. if it's about achieving a stable orbit, make sure it is of the map screen or the orbital information from KER or something is displayed. For each screenshot verifying an achievement, you get the achievement. I'll try to keep a running list on the OP. These missions can take quite some time over multiple play sessions, so keeping a running total is important. I will only keep track of your mission with the most achievements for score purposes. You may also submit Youtube videos or Twitch highlights or something of the like. I will submit my Single-Stage to Mun craft as an example and proof of concept later, and will edit this post when I do. Stockton (stock aerodynamics scoreboard): 1. Overfloater: 13 Achievements for the Astro-Cruiser SSTO (Plane, gets to two planets in the same mission and can return to the runway) 2. Redshift OTF: 6 Achievements (could be worth more if I can see that it can get back to Kerbin) *Celine Dion voice* NEAR...FAR...Wherever You Are (NEAR and/or FAR scoreboard):