M5000

There was a Youtube user who tried out doing 2-litre bottle rockets powered by air pressure, that he filled with different liquids or powders as the reaction mass. You could try pressurizing a 2-litre bottle and filling it first with water as a control group, and then replacing the water with different reaction masses, possibly trying flour, dirt, or any other kinds of things that you could propel out of the back of the bottle. Time your launches to see which stays in the air the longest, and that would be your "height traveled" which in turn could tell you which of the propellants you tested is the most optimal. Obviously you would need multiple launches per propellant, and you would have to explain your predictions. /Why/ do you think one propellant would be the best or worst? What sets it apart from the others? Determine what factors from the environment around you could pose a problem to perfectly accurate data, for example, the wind blowing may create slight bits of lift on the bottle and slightly skew the descent time, or parallax caused by your reaction time on the stopwatch. Perhaps you could also factor in aerodynamics, try making different nose cones and doing launches with each propellant, seeing which nosecone would yield the longest amount of time in the air. Here's a starter, the bottle with the closest body to the Sears-Haack Body will likely get the furthest in an aerodynamics test. Also, moving this thread over to the science labs, the people over there live for threads like this.

Yup, going to go ahead and report some kind of bug that everyone else seems to be having. When exiting from a flight (reverting) back to the VAB, I get an instant CTD with no error messages. Ship was almost exclusively KW parts, never had any problems in the past. I was in orbit, if that matters at all. And right before I tried to revert back to the VAB, all the tanks appeared translucent or something, like I could see through them. That's probably not actually the case and it was pry due to some kind of framerate flickering, but regardless, that's how it looked. So I'm just reporting that bug. Also, a few of the parts list view models are flipped around from where they used to be. (Like a different side of the part is showing) Not sure what that is or if it's even intentional, but just making note of that.

Oh god, why did I not know about this... KW Rocketry is my absolute favorite mod of all time, if I had to get rid of every mod except one, KW would be the one that sticks. Having a run over with the parts, and doing a re-design of my baseline lifter, integrating said parts.

Used to not have any naming system at all. Working on fixing that for my mainstay craft, which I plan on very seldom changing, and using them as the backbone for missions, so right now I'm doing a TON of designing, but once I round out my fleet, I'll be doing far more flying than anything since I'll already have some basic designs down. I generally try to name things after stars in our real world, but if I can't happen to find one I like, I'll just use one I made up that sounds like it may be legitimate, or I find an animal I'm particularly fond of. This name is then applied to a series of crafts, a "family", if you will, which will have I's II's and III's and so forth assigned to them based on size/use. Then, I will append to the end of the Roman Numeral a sub-reference designator, based on a single letter which is derived from the most notable special feature on the craft. I will then test this and make minor edits to the craft design until it works well. Once it has the numbers (Delta-V is enough according to KER in-editor) and it passes some basic flight tests (these vary on a per-ship type basis. Rockets must achieve orbit with some payload, usually a fuel tank, whereas landers simply need to hover around the KSC, where still unmanned probes may only need to do a test-engine fire or solar power test), the craft will then be saved with an ! next to the name to put it in first in the list of all the craft, so I know that it's a proven, tested design, ready for repeated re-use. If I happen to make a major edit at a later date, or build a craft from the ground-up in such a way that it is nearly identical, visually and functionally, to a previous version, a special word may be appended to the end of the name, past the single-letter sub-reference designator, to remind that it is not the original iteration of this exact craft. Also, craft with no special features outside of their outlined purposes and criteria are not given a special sub-reference designator. For example, a 3-seat OTV would not get a sub-ref, because an OTV of that size is expected to carry at least so many crew. However, if the OTV happened to have a different propulsion system than standard bi-propellant engines, for example Ion, Nuclear, or Monopropellant, it may be given a sub-reference. The same goes to modified craft with special purposes. One of the more popular ones I've come up with is the Betelgeuse series.. We had the.. Betelgeuse-I Betelgeuse-I Delta Betelgeuse-II Betelgeuse-M Betelgeuse-III Gamma Betelgeuse-V Betelgeuse-X Though, this series is a bit messed up, as the Betelgeuse-I is actually quite larger than the Betelgeuse-II will be, and the Betelgeuse-III Gamma never had a "non-gamma" version, and is basically just a REALLY optimized Betelgeuse-I Delta. Also, the Betelgeuse-M is basically just going to be a re-useable version of the Betelgeuse-II I don't know, it made sense in my head, don't judge me.

Oh man I absolutely love these types of threads. Sit back because I'm about to attempt to remember all my missions/programs/crafts/scapped designs since I first began... At least based on screenshots and current craft in my game's files.... So here's how I'm going to lay it out. The mission will have a bold title, with each sub-craft or sub-section being color-coded based on its status. Here are the color codes: Planned Design/Future Mission In Active Service/Mission Currently Underway In Testing Phase Decommissioned/Phased Out Completed Mission Abandoned Project/Scrapped Design Mission Did Not Achieve All Goals -------------------------------------------------------------------------------------- Archernar Grand Tour Project Archernar-I Arcturus Project Arcturus-I Duna Surface Rover Apogee Mun Program (We don't talk about Apogee...) Apogee Ultra-Light Mun Lander Callisto Eve Program Callisto-I Low-Eve-Orbital Probe Tortuga-II/R Surface Rover Project BrightStar BrightStar I Low Kerbin Orbit Station Embarker Mission Embarker-I Mun Surface Rover Embarker-II Mun Surface Rover Embarker-III Minmus Surface Rover Long-Term Exoplanetary Exploration Project HEV-HAB MegaRover MEG-HAB MegaRover MEG-STRUCT Mega Rover Nautilus-I Massive Surface Rover Iasillo Joolian Orbit Mission Iasillo-I Jool-Plunge-Map I KerbLab Mun Station KerbLab One KerbLab Two KerbLab Three Munar Atmosphere and Lack of Environment Exploration (MALEE) Project Knieval-I Ultra-Low Orbit Probe Pioneer Unmanned Mun Mission Exploration Landers (PUMMEL) Project Pioneer I Mainstay Mun Lander Pioneer II Mini Mun Lander Pioneer III Mini Mun Lander Pioneer IV Mini Mun Lander Pioneer V Mini Mun Lander Project Polark Polark I Low Kerbin Orbit Station Unity One Wyvern-I Manned Mun Surface Lander Serenity One Serenity Base Outpost The Oasis Microstation Project Oasis-I Oasis-II Oasis-III Kerbin Air-filled BallOOn Manned Mission (KABOOMM) Balloonigan I Balloonigan II Balloonigan III Balloonigan IV Balloonigan V Balloonigan VI Beryllium Project Bluerock Sub-Orbital Manned Capsule Denebola SSTO Project X-1 Jolly Rancher Project Stability Stability-9 Low Kerbin Orbit Station Tuxaedo Grand Tour Mission NVMSS Tuxaedo Nexus Intelligent Systems, Incorporated: Aerospace Division: Design House Pegasus-15 Kitten-I Multi Purpose Unmanned Rover Kitten-II Multi Purpose Unmanned Rover Kitten-III Multi Purpose Unmanned Rover Kitten-III/C Multi Purpose Unmanned Rover OBS-Base Core System Yoonyte-I SRV Kerbcon-9/Wyvern J-L336-8 AstroDuck JR-MFUN Rover Flame Burner X-5 STOL LAX-1 Doodlebug RMK4-Oxen Orbital Tug Nexus Intelligent Systems, Incorporated: Aerospace Division: Commission of Unified and Streamlined Tactics for Applied Rocket Design (CUSTARD) Regulus I/AP - .625m Transfer Tug Regulus I/XP - .625m Transfer Tug, Extended Range Regulus II/AP - 1.25m Transfer Tug Regulus II/XP - 1.25m Transfer Tug, Extended Range Regulus III/AP - 2.5m Transfer Tug Regulus III/XP - 2.5m Transfer Tug, Extended Range Regulus V EX375 - 3.75m Transfer Tug for 2.5m Payloads Regulus C Block 4 - 2.5m Crew/Support Module Carrying 4 Crew Regulus C Block 8 - 2.5m Crew/Support Module Carrying 8 Crew Regulus C Block 16 - 2.5m Crew/Support Module Carrying 16 Crew Eclipse I - Light Satellite Bus Eclipse II - Medium Satellite Bus Eclipse III - Heavy Satellite Bus Aldebaran I - .625m Load Balanced Orbital Tug Aldebaran II - 1.25m Load Balanced Orbital Tug Aldebaran III - 2.5m Load Balanced Orbital Tug Aldebaran III/S - 2.5m Load Balanced Orbital Tug, With Adapted 1.25m Port Umbra I - Single-Seat Open-Cockpit Vacuum Surface Lander Umbra I/C - Dual-Seat Open-Cockpit Vacuum Surface Lander Umbra II - Single-Seat Closed-Cockpit Vacuum Surface Lander Umbra III - Dual-Seat Closed-Cockpit Vacuum Surface Lander Umbra IV - Quad-Seat Closed-Cockpit Vacuum Surface Lander Umbra V - 16-Seat Closed-Cockpit Vacuum Surface Lander Penumbra I - Single-Seat Closed-Cockpit Staged Surface Lander Penumbra II - Dual-Seat Closed-Cockpit Staged Surface Lander Penumbra III - Tri-Seat Closed-Cockpit Staged Surface Lander W/Ion System Equinox I - Single-Seat Heavy Return Lander Equinox II - Dual-Seat Heavy Return Lander Equinox III - Tri-Seat Heavy Return Lander Gala - Single-Seat OTV Nautilus - Tri-Seat OTV Kraken - Quad-Seat OTV Starshot I - Lightweight Sounding Rocket Starshot II - Heavier Sounding Rocket Archer I - Light Satellite Lifter W/Integrated NTR Stage Archer II - Medium Satellite Lifter W/Integrated NTR Stage Archer III - Heavy Satellite Lifter W/Integrated NTR Stage Compass I - Light Serially-Staged Manned Rocket Compass II - Medium Serially-Staged Manned Rocket Beltar I - Probe Launcher Beltar II - Probe Launcher W/Integrated NTR Stage Beltar III - General Purpose Medium Heavy Lifter Betelgeuse II - General Purpose Heavy Lifter Betelgeuse III - General Purpose Super Heavy Lifter Betelgeuse III Block D - General Purpose Medium Lifter Betelgeuse V - General Purpose Manned Heavy Lifter Betelgeuse X - General Purpose Ultra Heavy Lifter Betelgeuse M - General Purpose Fully Reuseable Heavy Lifter The Betelgeuse Project (Joint Project with CUSTARD) Betelgeuse I - General Purpose Super Heavy Lifter (Experimental Proof-Of-Concept) Betelgeuse I Delta Heavy - General Purpose Super Heavy Lifter (Experimental Prototype) Betelgeuse II - General Purpose Heavy Lifter Betelgeuse III - General Purpose Super Heavy Lifter Betelgeuse III Block D - General Purpose Medium Lifter Betelgeuse V - General Purpose Manned Heavy Lifter Betelgeuse X - General Purpose Ultra Heavy Lifter Betelgeuse M - General Purpose Fully Reuseable Heavy Lifter (Based On Betelgeuse II) So, as you can see, I've done quite a bit of missions and design work, yet I still have a ton of design work ahead of me that I've laid out for myself. CUSTARD is currently my biggest undertaking, attempting to make some really good spacecraft based on the few mods I have installed.

He also mentioned deep valleys and high mountains, so that implies that the surface would be solid, so that doesn't prohibit anything outside of something like an Eve lander. Who's to say you can't strand a Kerbal there, and if you don't like killing/stranding Kerbals, you can still launch a probe there.. Maybe this is one of those things that some people simply won't be able to do. It'd add a nice dimension to the game, having some more challenging bodies like Eve would be awesome. However, Mu also said in the stream, if I remember correctly, that a new planet isn't a priority right now and that it may not be in the next update, so I wouldn't get your hopes up.

Ahem. Basically, what everyone else in this thread just said. If your ship is small enough to the point where an LV-909 gets you more DV than an LV-N, your ship isn't massive enough for it. You see, due to the diminishing returns of sticking a massively heavy engine onto a tiny craft, the LV-909 still has some relevance on smaller vehicles. Now, the larger your ship gets, the less and less the LV-N's mass matters in the grand scheme of things, so you're able to take advantage of the higher Isp with some meaningful outcome. That's what I see as the beauty of this game. Every ship has an optimal engine you're going to want to use, and that's all going to depend on how big/massive it is, and where it will be doing the majority of its operations, read: how much atmosphere will it encounter most often? You have to actually design your ship. Generally, yes, the LV-N will have more applications than the LV-909. That is, unless you're Giggleplex and all your stuff is teeny tiny. But, if you happen to be designing a 1.25m or smaller 2.5m craft, the LV-909 may be more useful for you. Really, try it out. Experiment with a Delta-V measuring tool of your choice, and see what the results are as you change the mass of your ship, amount of fuel, and engines for propulsion.

I got my brother to buy this game, he rarely plays it and very much dislikes it. No matter how I try to get him to play or show him videos, he doesn't seem interested at all. He has other games like Awesomenauts and Left 4 Dead 2 and there's no good way to get him to play it reliably. Really, the game isn't for everyone, it's best to let people discover it on their own, as forcing it on someone makes you look kinda bad.. :c

Yes, the above information is pretty good advice, but why not go for a landing? Landing wouldn't be too much work, as Moho has about double the gravity of the Mun, but still is very low compared to Kerbin's. A small lander could be devised and strapped on the ship

BOTH! I have it on both platforms, for reasons I will never understand. No, one was not a gift, I actively purchased under my own power the game on both platforms.

No, I get it.. Don't worry Moon Goddess, you're not the only one who does this. I don't know if the reasons we have for not flying stuff ever is the same, but there have been many times I've built things that never flew. For example, the design just turns out ugly in my eyes. I really try to avoid flying ugly rockets. Elegance in my program is key. But yes, I spend so much time in the VAB it's insane, sometimes by definition. I design the same thing over and over again expecting different results. Other times, a craft is just too much work and I dump it. You are not alone!

Antikris: Very nicely drawn infographic you have there, what program did you use to make it? And to answer the thread: I love to build stations. Here are some of the key things you can do to keep your part count low, and your station organized and effective at what it does. -Throw "making the station look good" out the window. Form MUST follow function on large things such as stations. If you build your station well, it will end up looking good anyway. -Keep in mind what you want to accomplish. Set a goal for the station at the beginning, and follow that goal. -Design a lifter that has a main purpose of station building. Give it either a transfer stage, or an enlarged insertion stage, with its own support systems, so that you don't need to put RCS, electricity, or probe cores on each station module. This will really cut down your part count. The modules, once docked, will have their own support systems once docked to the rest of the station, where there are already electricity supplies, fuel, and anything else of that nature. -As others have said, design the entire station, in its entirety, as well as any types of expansions or alterations you may make to it, out in your head, or in the VAB, or, like I do, on paper or in a graphics program. It doesn't have to be DaVinci quality sketches, but you want to know basically how you're going to lay things out. This also lets you allocate where you're going to place resources, and lets you know which modules are actually going to need RCS thrusters. (Not every module needs them, but some of the station's extremities may need them for better rotation.) It will allow you to plan your light placement, and hopefully your solar panel placement, so that they are away from high-traffic areas, and will receive the best sun exposure. -Use as big of resource containment pieces as possible. This is an interesting problem. When you use a larger fuel tank to hold some amount of a given volume, you reduce part count, but you also reduce the potential for modularity. In general, if you've set some number for how much of a resource you want to keep aboard your station, you want to use as large of a part as possible to make that happen. For example: Let's say I want to keep an orange tank worth of fuel on my station. Well, the best way to do that in respect to part count, is to place..Well, an orange tank of fuel on my station. I could also sub-divide that into smaller tanks, if I wanted to spread out the mass, or make the design more modular, but it will require more parts. This is where your planning really comes in handy. When you plan, you'll balance your needs and decide what's best for your application. Want a supply of RCS? Use a big RCS tank. Wanna spread it out? Fine, use smaller ones and spread it out. But it really doesn't make sense to use a bunch of radial cylindrical tanks to store 4000 units of monoprop. It's more parts than you need.. It may arguably look cooler, but it's more parts than you need. -Keep one unmanned orbital tug on-hand at all times. Your station lifter will peter out sometimes on you, and other times you'll need to move loads around, so for those times, it's always good practice to keep a medium-duty unmanned tug on-hand. -Also a good idea, keep an OTV/Space capsule on board in the event of needing to rescue a Kerb. -Build your station in lower orbits, and boost it up as a whole with a disposable tug. This will allow your lifter to loft much larger payloads, so you can make much larger modules with less relative parts, rather than boosting smaller payloads to a higher orbit. Those are all the station tips I've built up over time, and I've gotten station building down to an art, and it's currently my favorite thing to do in the game.

I don't refuel, but I don't see much point in refueling at Mun or Minmus for an interplanetary trip, as I like to launch my missions from as low of an orbit as possible, usually 70Km, to exploit the Oberth effect, which is why stations are to be constructed in the orbital "tier" of 100Km to 750Km to avoid collisions with departing missions, for general purpose, in my space program. That said, I've only thus far sent single-shot missions containing probes or rovers out there so far, as I don't see much point in manned missions in the first place, so I haven't really had the need for refueling anyhow. Just design your vehicle to be able to perform at least one single MASSIVE burn from one planet to another, say, Eeloo to Moho. Yeah, really big burns. If you can handle that massive burn, I say the best place to refuel is a moon on the outer orbit of the planet or system you're to explore. That is, assuming you're a Kethane user like myself. If you happen to have a fuel station dedicated and in orbit, by all means should you use that. However, for Kethane mining.. Coming in to the Jool system? Refuel at Pol or Bop. Coming in to Duna? Refuel at Ike. Coming in to Kerbin /from/ somewhere out there? Refuel at Minmus. Coming in to Eve? Refuel at Gilly. I would speculate that if you're performing a mission to a place that /doesn't/ have a teeny-tiny super low-grav moon on its outer orbit, the planet will have low enough gravity to make refueling relatively efficient in the first place. As you can see, all those systems I listed above have a small, low, or very low, gravity world on their outer rims. However, for those that don't, for example Dres, Moho, or Eeloo, you would still be able to refuel with similar but not identical, trouble to that you would have on the Mun. I'm actually in the process of planning a grand tour mission that will be set into motion as soon as I can get SSTO spaceplanes down to an art, but the mission route I have planned goes straight from a 70Km orbit, to Jool's system, and actually hits the Mun and Minmus on the way home. In short, low gravity worlds where returning Kethane from the surface to the orbital refinery (how I would choose to do it) is a trivial task, so that you can maintain peak efficiency. That's how I'm seeing it. -M5K

Yes, the advice in this thread is valid, ctrl+Z for undo, but be careful as the functionality is a bit sketchy at times...

Make the rovers the same wheelbase/chassis dimensions/ratio as a supercar in real life. While the aerodynamics may not accurately represent reality, the gravity and momentum and center-of-mass physics are pretty much spot on.. This baby goes 20m/s no problem: Drives horribly on Kerbin, but really shines on the Mun.. How did I get it there? Well, I don't have any pictures of the launcher, but imagine this: With even bigger 3.75m stacks on each corner. As for the actual landing...Also note the center of mass... And safe on the Mun, with 16 Kerbs inside. Left some space so they got some room to move around. God, I got so much air..erm..vacuum in that thing.. Seriously, if you can handle the lag, a gigantic rover like that is a ton of fun, especially just watching it jumping over things, leaping and bounding over foothills without a care in the world. Just be careful. If your tires start to pop, HIT THE BRAKES IMMEDIATELY, otherwise, you will skid for miles. Speaking from experience. Somehow nothing got broken other than the wheels, which were able to be repaired...

I disagree with this. Seeing as you use RCS for mostly translation, not rotation, having RCS thrusters as close to the center of mass as possible. If you're using RCS to perform rotation, you need more reaction torque. You can perform a docking with remarkably low amounts of RCS if you use this method. I've done docking using like, 20 units on a 3-man capsule because I didn't use RCS for anything other than translation. Sure, if you place your thrusters evenly about the center of mass you can get more effective torque, but if you have any amount of respectable reaction wheels, you can use them for rotation. However, I do agree with you that it's less about "How much distance" and more about "how much relative velocity". Remember, the only way to slow down in space is to impart a force in the opposite direction in which you are moving, usually by means of monopropellant RCS thrusters or your bi-propellant main engines. When you're docking, there's usually two situations you'll be in, more likely than not. 1: Two small craft docking 1-to-1. 2: A craft of some undetermined size, is to dock to a large craft that is immobile. In situation 1, docking is really an effort on the part of both ships involved. First, when you get close enough to begin moving on RCS only, foregoing your main engine, switch to your target's craft. It's at this time you'll need to prepare the ships for close encounters. First, kill out your relative velocity to the target by burning retrograde with the navball in "Target" mode. Find the ship that will be docking to this target somewhere in space. Point the docking port you're going to want to dock with toward the ship you'll use to dock, so that it's already lined up for approach. Now is also the time to retract any extremities that may be vulnerable or risky to move around, such as solar panels, as well as turning on any lights that may be intended to help you find the craft's position in space. Once you've prepared your target for the final approach, switch back to the craft which you were originally piloting. Prepare it for docking as well, retracting solar panels if necessary and turning on your docking lights to see what you're looking at. (Not necessary, but VERY nice if you're on the dark side of Kerbin.) Attempt to set the actual physical port on the craft you're going for as a target, ensure the Navball is set for Target mode, and your camera to "CHASE" mode, line up toward that marker, and translate forward to begin the approach. Watch the navball. Try to keep your nose marker right on the pink symbol, as well as your prograde marker. If they drift apart (they probably will) simply use your translation up/down/left/right to move the prograde marker around on your nav ball. Yes, it is that easy. The prograde marker, at low velocities, will very responsively follow your IJKL keys, with H and N making it harder or easier to move, due to increased or decreased velocity. Simply keep adjusting, trying to keep your nose, prograde, and target-prograde all aligned, and you will eventually be close enough for it to simply engage. A final docking speed should be, ideally, no more than .1m/s, but .3m/s could be done safely as well. Once the magnets begin to engage, let the game take over. Disable your SAS and RCS systems immediately and as quickly as possible. The magnets will guide you into place. In the second situation, where the target is not easily movable to face your position, you will need to get close to the large craft using the same basic method as above, but once you get close enough, say, about "one fully-extended Gigantor-XL Solar Panel"'s length away, then use your translation to move around the craft, just like a gigantic Kerbal EVA pack. Hope this helps, once you figure it out, it's super easy.

This. A vehicle is a vehicle, parts are parts. It doesn't matter where they're built. It's just that the VAB makes it easier to build taller structures, typically associated with rockets, and the SPH makes it easier to design long or wide structures, like spaceplanes. Really, all the building does in the end is determine whether you launch from the pad or the runway, which obviously, depending on your craft's design, matters.

Nope, I have this same issue, and I have NO idea what causes it. Just came here to express my "I know that feel bro." Let me guess, you're doing multiple probe missions to mark off significant altitudes in the Kerbin system, and this one happens to be the "Safe orbit" probe. Because that's what I was doing and, sure enough, my AP/PE lower whenever I timewarp. Like, as soon as you un-warp and physics enable again, the PE/AP jump a tiny bit ahead...Really annoying..

Landing accurately and precisely on planets with atmospheres. UGH.

Look, here, I'll make this as simple as possible. Say you have 15 tons of sand. Say you need to get it somewhere else 100 yards away. You have to use a conveyor belt that runs at a fixed speed. You can choose between a 3 foot wide and a 6 foot wide conveyor belt. The 6 foot wide belt can move more sand, even though both belts are going the same speed, because it is WIDER and has more CAPACITY. The pile of sand is data in the computer's memory. The speed at which the conveyors run would be your processor's clock rate. The "somewhere else" is the computer's processor and other things after that. The conveyor belt is the data bus for the memory and processor. The wider you make the data bus, the more data you can move. The comparison from 32 to 64 bit is actually less like a 3 foot and 6 foot wide conveyor, and more analogous to comparing a 3 foot and a 200-yard wide conveyor. (It's exponentially scaled, not linear.) The problem with the 200-yard wide conveyor is that the structure may get unstable at such large sizes. That's why 64 bit is better in every conceivable way, but since it's a bit unstable on Windows right now, it's hard to implement. That's as simply as I can explain 32 vs 64 bit hardware/software. Motokid600: Yes, you could install and run as many mods as you wanted, as long as it doesn't use up all the RAM you have available on your PC itself. It would allow your computer to, instead of addressing the 3.5gigs-ish it can with 32 bit, allow it to address up to exobytes, which is more data than you'll ever use on your computer ever. Limited by Windows, it's serveral hundred Terabytes, which is probably still more memory than all the existing, previous, and future installs of KSP and all past, current, and future mods take up combined.. So yeah, it will take the limitation off of the software, and place it on the hardware. If you exceed your hardware's limitations, you may experience crashes just like you do now.

I don't know if this helps, OP but there's a company named Pac Tec that can do electronic enclosures. -I don't know what they carry in its entirety, but maybe you'll find it useful. -A company I used to work for used some of their boxes and they seem pretty solidly built. -You may need to still cut holes in the enclosures for your displays... -Really, this is me just trying to throw ideas at you here. You may be able to order them with holes already done, but I don't know. Using this in conjunction with that aluminum faceplate site may be a good start to the supply process. Like I said, I don't know if Pac Tec will have what you're looking for, but they MAY, so you might want to look around and possibly contact customer service to ask about what you're looking for. All I know is that they certainly can support any supply demand you'll be facing, so there's that. http://www.pactecenclosures.com/ Check it out, they also have drawings for all their products on the website, so you know exactly what you're going to be getting.

I went to Vall one time, and this happened: Ion engines are not good for retrograde collision-course avoiding...

I would think it's easier to assemble your station Kerbin-side and push it to the destination, rather than taking it to the destination and assembling there. Reasons: -Less long-distance piloting, therefore less room for errors. -No need to run parallel missions so that everything departs from one transfer window in one vehicle. -IF you were using parallel missions with separate modules, you would either have to wait for a transfer window and hope you get all the modules sent on their merry way at once (Eg, you better be ready) and if you miss one or want to send another module, you have to wait for another transfer window. Alternatively, if you send them each on their own window it takes forever. -Less cost (if you play that way) because rather than having to design a rocket that can bring modules up from Kerbin and then also bring them interplanetary, you can design it to bring the modules to LKO and just tack on a single tug at the end. -Less debris in the destination orbit. (Station building is likely to leave some debris in the form of decoupled struts, fairings, stack separators, or possibly entire transfer stages. Leave the debris back home so it's easier to manage later.) -Allows for, possibly, larger payloads per-launch. The extra mass it would take to bring up not only the module to be added on, but the transfer stage, could allow for larger modules in the station. If you build your station in as large of parts as possible, it is likely to be more structurally sound, since you are using less docking/berthing connections. So, those are my arguments FOR building your station in LKO and then simply tacking a tug onto the FRONT of the station and pulling it along to its destination.. So here are some design tips that I've seen as valid... -Try using these mod parts. They are Common Berthing Mechanisms that you can use in place of docking ports. They come in the four most common standard sizes, from .625m to 3.75m, and they are incredibly rigid. There is also an active and a passive (male/female, of sorts) for each size. However, this should not matter, and is really just for aesthetics. Also, they should link up with the stock docking ports, but certainly you will want to test this before departing if you are relying on them for a pivotal part of your mission. -Try designing your non-core modules to all be the same size. Perhaps a module initially turns out to be smaller than some of the other ones...Add a reserve of fuel or maybe some solar panels or structural bits to help even out the size and mass. This will allow you to play with your station like Legos. -A generally good design is to use 1.25m CBM (the mod parts up there) ports, placed around a central "core" or "shaft" of a station, which can be 2.5 or 3.75m in diameter, depending on application, using said above CBMs to link up the parts. 4x symmetry for the modules you will attach radially is a good idea, remember to make these the same size. -Fuel tanks make a great central core structure, and, they, you know, hold fuel. -For your propulsion, it is advisable to PULL your station, rather than to push it. When you push a structure of considerable mass, you impart an acceleration upon it, and it becomes similar to if that structure were sitting on the surface of a planet. The gravity of this "invisible planet" is entirely dependent on your TWR, but the effects can be devastating. To fix this problem, create a propulsion module that can dock on to the front of your station, and point the engines backward, held out on some kind of outrigger, possibly, like a gigantic space train. One more thing that is also very important if you go this route: ENGINE GIMBALS DO NOT WORK PROPERLY WHEN PLACED AHEAD OF THE CENTER OF MASS. So, assign an action group to disable or toggle these gimbals, so you can turn them off when needed. Steer using reaction wheels instead, which should be integrated into your design. When building the modules, try putting a small reaction wheel on each module so that the forces can be distributed more evenly. -Plan your RCS thruster placement. Use them efficiently and you won't need to bring very much RCS. -Use struts if possible. -Turn on fine controls -Symmetry is key. -Plan your station before you build it. Try drawing a sloppy schematic in paint or on paper even, let your imagination run and you'll find that more often than not, when planned properly, your station will come together beautifully. -And above everything: BE GENTLE. This may be a near or multi-megaton mass station, but it is as delicate as a baby. Be precise. Be gentle. Tread lightly. Baby steps. So, that noted.. Here's my first large station design I ever made. Actually, it's more of an interplanetary ship, designed for a grand tour mission. It's also an example of what NOT to do: I was so confident that it would work. Left it unpaused in orbit and went to lunch and came back to this:

I dunno. I like it how it currently is. I mean, we kind of assume they're male because most people are generally wired by societal influences to see sex-less things as being masculine unless defined otherwise, but in reality there's nothing definitively masculine or feminine about them, other than some having traditionally male names, but others certainly have names that could be construed as female. Their appearance, to me suggests asexuality and I personally am just fine with there being no real mention or definition of their gender. Even if there have been some who claim the Kerbs are all males, I refuse to accept that analysis and assert that, at least within my own space program, the Kerbals are genderless, or, should a definite border between male and female Kerbals ever be implemented, that Nexus Aerospace Division is an equal opportunities employer destroyer. Besides, this is a space program simulator, not a sexuality simulator. But no, I don't really have any feelings one way or the other, I feel that the current Kerbals are asexual enough to be considered genderless, and that's fine. I give less than a care /what/ I send up in my rockets, so long as whatever I send up is able to control them well, and die when I crash it, so that there is a stigma of preservation and importance of life with every manned..Or..Womanned...OR...uh..Kerbaled mission. -M5K

Whoa! Just downloaded and tried this after some initial skepticism... Works very well! This is a must-have if you use subassemblies at all! Just re-built a complex rocket with no visible hitches at all! Very well done! -M5K