Raptor9

I approach it from what the payload is and how/where it can be used. For example, all my station parts are subassemblies since any given station a player wants to build or where he/she wants to build it is so various, I didn't want to put them in pre-set payload packages or pre-fit launchers. That and there are so many. However, other large payload combinations such as my EV-4 components or my M3V kits are smaller in number and are specifically grouped together for a purpose and/or destination, so I took some of the work out of the process and pre-fit them with ideal launchers, ready to hit LAUNCH. It all comes down to how you want to present them and how they're meant to be used. At the end of the day, if a player wants to use them differently, they can always change it themselves. You can't accommodate every possible combination or technique of applications. Oh, and if a craft has fuel ducts or struts, I would avoid publishing it as a subassembly since their placement might come back wonky, especially if you used the offset tool on them.

This one's for you @Rune. You got me motivated this morning to take another pass at my DC-X analogue. It can't SSTO from Kerbin, but has more than enough "oomph" to deorbit from low Duna orbit, drop off a habitation module, and return back to Duna orbit. And since it's fully robotic, it utilizes pure retropropulsion for landing since it wouldn't be practical to have an engineer constantly repacking chutes; especially if it's placing surface modules before any crew shows up. Still working out the details of the cargo delivery system, but right now it's able to accept payloads in orbit, and place them on the surface. The one payload that is too big for it is a Mobile Processing Lab, but I have another cargo lander available for that. Lateral hover translation test from the launchpad to the runway. And for those that haven't seen it, the second photo is a composite image of the real-life DC-X doing a similar hover test in the mid-1990's.

Not entirely sure yet, my first iteration this summer used Mk2 Fuselage parts for corners and wing panels in between, to try to mimic the DC-X boxy look. But after learning a little with my LV-4B and another Duna lander I'm working on, it could either be cylindrical parts or a combo of those and fairings. @Exothermos did an interesting job with his Lockheed Martin Mars lander recreation. Yeah, it feels good when you get your own thread cleaned and organized for currency. I need to update some info and screenshots in mine too, not to mention my craft video is grossly outdated, being filmed in 1.0.5.

I like the DC-X as well. I've been trying to make a DC-X style lander that's bigger and better than my existing LV-4 'Armadillo's. That darned, delicate balancing act of getting the cool and practical to work together.

That's where I got the idea from. My inspiration for the LV-4B is from the Mars Excursion Module and the Dragon 2.

It still requires some more testing and refinement. It's not a high priority since the LV-4B already provides that role. I'm trying to refocus my efforts on my new atmospheric cargo lander so I can get my larger surface base elements practical for delivery to other planets like Duna. However I still plan on getting that larger SSTO out there since delivering 7 kerbals at a time to a large surface base is more useful than the 3 delivered by the LV-4B.

Lol, ok, I got you. Funny you used that word, because I was reviewing the LV-4B graphic after you posted that like "Did I make this ambiguous somehow?" 8x "Twitch" engines working together is comparable to a Mk55 "Thud" which is no slouch against Duna's surface gravity. Plus the Duna atmosphere is thin enough that it really doesn't shave too much thrust or Isp from the "Twitch" performance. With the fuel you consume during the deorbit burn and the during the final approach and landing, you'll probably be lifting off with a gross weight under 21 tons and a TWR of 2.0 or greater.

Neither of those landers can get to Duna on their own. The rockets transport them to Munar orbit, where they are docked to interplanetary propulsion stages or large ships. This is why they are mounted to adapter plates with large docking clamps. Most of my landers are mounted this way. If you look at the graphics in the post just above the landers, you'll see how they fit into the architecture. But I still wanted the landers available as standalone downloads outside of the M3V Landing Kits in case someone wanted to use other methods of getting them to their destinations. Glad you like them the landers @Rune and @Fearless Son.

And the next contestant is: "Duna Landing Kit", "Ike/Dres Landing Kit", and standalone launchers of the LV-4B 'Armadillo' and LV-2E 'Cricket'. All four are available for download on KerbalX...whew (wipes brow before pivoting back to the surface components of M3V). It's worth noting that the LV-2E is capable of landing on the Mun as well, but with a tighter margin (~200m/s less dV) than the LV-2D 'Cricket'. So be careful if you decide to commit to such a maneuver. Also, the LV-4B is also more than capable of landing on the Mun, Ike, Dres, etc. In one test, I departed with full tanks from a 65km Duna orbit to Ike, landed on it, and then launched and returned to a 65km Duna orbit. Or, from an equatorial Ike orbit with full tanks, conducted a 60 deg inclination change, landed, launched back to orbit, and then did a reverse inclination change back to a 0 deg inclination orbit around Ike. So the LV-4B is a very capable and flexible lander or in-SOI crew transport. Both landers have surface refueling reports if such a capability is needed.

Or the 225 mods you maintain...

Ten more M3V kits published; all advance equipment kits, all main 'Windjammer' kits, and three of the five EV-6 support kits. The 'Duna Landing Kit' and 'Ike/Dres Landing Kit' will be published tomorrow, along with standalone launchers for the LV-4B 'Armadillo' and LV-2E 'Cricket' landers. So to start off with the first graphic; each kit includes an M3V-PL research module, but the second module is what is unique in each kit. Each has a specific purpose, or may meet certain criteria of ship/station contracts, like having a cupola. What is unique about the 'Exploration Kit' is the fact it has an RC-L01 large probe core and powerful communications, enabling you to control probes and rovers in any far away SOI without relying on a signal from KSC, even through multiple hops. Such applications that came to mind was controlling mining rigs/ships in the Dres SOI, or controlling science probes/rovers throughout the various Joolian moons. It should be noted that having a NITE docked to a ship with a pilot also gives you this capability since it has a large probe core and good communications. The second graphic is the core of the orbital portion of the M3V project. Depending on what flavor of EV-6 you want, you launch either a Basic, Extended or Heavy variant, and then further customize your mission equipment with more propellant, crew vehicles, landers, or whatever else you want to take with you (provided you have enough delta-V for your destination). The EV-2L 'Runabout' is also central to the operation of the EV-6 'Windjammer', just as the Orion is crucial to the Mars Base Camp concept. The EV-2L provides the propulsion, attitude control, command module, and if necessary fuel cell power generation. Not to mention that you can also use them to reenter the atmosphere of Kerbin if you aren't able to re-enter a stable parking orbit with the entire ship. One unique aspect of the M3V-PH 'Heavy Propellant Module', is that the aft side has docking ports for two EV-2L's, and an additional large docking port for LITE/NITE stages, or even an SLV-M to dock to. These could be used to reposition the ship if the EV-2L's are off doing their own thing. Not to mention it carries a lot more propellant as well. This layout also allows for two EV-2L's to use their propulsion systems at the same time for better TWR, and it allows other payloads to be mounted to the front of the EV-6 such as landers. In an emergency, if an EV-6 'Windjammer' equipped with only two M3V-PB 'Basic Propellant Modules' and two EV-2L's were to arrive in low Duna orbit and was not able to refuel from any ISRU depots, an emergency return config was tested. All remaining propellant was consolidated into a single LITE stage from one of the EV-2L's, and the ship reconfigured as in the image below. The LITE was almost completely full prior to the departure burn from Duna, and when the capsules separated for Kerbin reentry nearly half the tank was still filled. It hasn't been tested from Gilly orbit, but it "should" still work. Of course you could ditch the large habitation module if the Kerbals don't mind being cramped in the small Mk1-2 pods for the long journey home.

Finally, M3V is seeing the light of day. Bottom line up front: the next couple days will see the first sixteen craft files published, with two already on KerbalX. These two are a pair of Advance Logistics Kits for Ike/Dres and Gilly respectively. Essentially these would be the first stage of an interplanetary expedition, sent ahead to establish a minimal ISRU capability to start generating in-SOI propellant ahead of the next shipments. For those familiar with my catalog, the 'Ike/Dres Logistics Kit' doesn't necessarily include anything new, but it's a pre-packaged kit of existing equipment in a single launcher. The 'Gilly Logistics Kit' however, does include an all new ISRU rig design, the IV-2A 'Badger'. There are some considerations to keep in mind when using these kits, which I will list in the Engineer's Notes next to their KerbalX links tomorrow after I get some sleep. The second stage following ISRU logistics kits would be Advance Equipment Kits. These pre-positioned kits would bring research facilities, comms, etc. The final stage would be the actual EV-6 'Windjammer' crewed ships. Since you can only publish so many craft files to KerbalX at once, I'm holding off on the bulk of the kits until tomorrow so I can release them at once (they're all inter-related, so trying to keep it easy to follow). Several more will follow the day after. As previously stated, these will be just an initial series of craft files, and don't represent the entirety of the M3V series. As more kits are completed and graphics finished, they will be published in the near future. They'll be located in the VAB>M3V section, newly established between the Satellites & Probes and the Rocket Market.

Fortunately, there is a handy tool in the Alt-F12 menu that allows you to hack gravity to whatever levels you want. If you check the various surface gravities on the KSP wiki, and then move the gravity slider to the appropriate level, you can properly tune not just suspension settings but also docking port alignments. This way you can practice assembly at the KSC to ensure everything is properly designed. Some sample values for the "Hack Gravity" slider would be 0.17 for the Mun or 0.30 for Duna. My go to method in the past was to use modules that are on wheels, but with deployable landing struts that lift them slightly off the ground, like outriggers on heavy construction equipment. I would recommend using docking ports to connect the base though. I would limit Claw-usage to assembly equipment, and avoid using multiple Claws for connecting all the modules together. The graphic below shows the start of a Mun outpost. The wheeled/docking port method, tested at the KSC, made assembly a piece-of-cake when I actually got to the Mun. Plus, when you get this technique down, it makes moving fuel and ore between surface-landed craft easier. If you look at the right side of the closest lander, you can see a small docking clamp I use on all my landers and refueling craft at a standard height to allow surface refueling.

(Not saying you're a sissy @severedsolo, you just reminded me of this Calvin & Hobbes with your post )

There's really nothing fancy to it. In order to keep similar template layouts, I make a copy of a completed graphic and simply place content on top of it in the appropriate places. For the renders I use Kronal Vessel Viewer, and for the captioned photos I just use cropped screenshots. Everything else is simply typing words and drawing lines.

M3V update, for anyone that cares. As I've said before, this is partly a way for me to put my thoughts into text form; and the series of Notepad "memos" I keep in my KSP projects folder. I've referenced the Lockheed "Mars Base Camp" concept several times, and if you consider it as a large interplanetary ship that also serves as a space station when it arrives on-site in Mars orbit, this is sort of what I'm going for with the baseline M3V orbital component. In keeping with my existing naming convention, the new modular exploration vehicle will be named the EV-6 'Windjammer'. It's closest brethren is the EV-4 'Longship', however unlike previous EV-series, the EV-6 won't be further designated by Model or by Block. Since it's assembled using "kits", the EV-6 configurations are being divided into several main "EV-6 Windjammer Kits", which can be further outfitted into sub-configurations by "EV-6 Support Kits". An example would be a "Heavy Windjammer Kit" being equipped with either a "Duna Landing Kit" or an "Ike Landing Kit". So far I've completed tests of various EV-6 configurations traveling to Eve, Duna, Dres and even Jool; although Jool is really scraping the edge of the current range, even when launched from Munar orbit. These trajectories didn't take advantage of gravity assists or aerobrakes, so there is always potential there. I'm working on another main EV-6 configuration called the "Long-Range Windjammer Kit", which is specifically designed to go to Jool. Besides the obvious propellant requirements, additional modules it would possibly be outfitted with are a dedicated communications array and a "nuclear reactor" (RTG cluster inside a service bay) for the solar energy drop-off. But this configuration changed three times just this morning, so not much point in going into further detail. I've been really busy with my real-life job, and a move to a different residence, but I'm trying to iron down the first group of kits so they can be published on KerbalX soon. I want to import these craft into my career save as soon as possible myself.

Open the craft file in Notepad, the second line will say "version = 1.3.1". Change it to say "version = 1.3.0" and save the file.

This is a really handy tool @HebaruSan. Thanks. What I like about it is it helps to understand how to set up interplanetary transfers requiring multiple nodes. I've always done it manually, but I had no idea how much more efficient on delta-V it could be. This is a good teaching tool for myself.

Very cool @Exothermos! The orbital components of my M3V project has been inspired by this Lockheed concept, but I'm trying to adapt it for multiple destinations. I really like how you did the SSTO lander. Looks a lot closer to the real concept than mine does. You beat me to the punch as the first person to publish "Mars Base Camp" style craft.

Unfortunately, you can't install a craft with a version number higher than what you're using. However, an option is to open the craft file in notepad and edit the version number from 1.3.1 to 1.3.0, but that may lead to bugs that are present in 1.3.0. Like craft that have struts or fuel lines inside fairings exploding on the launchpad. It's one of the more significant bugs with 1.3.0.

I'm not gonna address the clearly overbearing nature of that post, because I know you have no filter. Instead, listen closely. It's not a matter of a few radiators, it's a matter of "part count creep", and it is a valid consideration when making a multi-craft architecture (which is what I believe @Rune meant by "complex architectures with lots of moving parts", not literal moving parts) For argument's sake, it would take 16 large radiator panels to fully enclose the two X200-16 fuel tanks like what are on the lander in question. Let's take half that to be conservative: 8 parts, and say that an example interplanetary expedition consists of 7 large modules/craft (which is how many sections the basic configuration of my upcoming M3V consists, not even including the lander). If you can shave off just 8 parts from each module, that's 56 parts in total. 400 parts in orbit is around where the clock starts flashing yellow for me, but I also have Environmental Visual Enhancements installed. 56 of 400 is a 14% optimization of KSP part CPU usage. That's a 14% margin available for ship/station growth, additional visiting ships in physics range, etc; or in the case for KerbalX-shared craft, a margin for players of lower CPU capability. Further, in any depot-based architecture where you're doing a lot of orbital refueling and moving propellant around in-SOI, you will be doing a LOT of rendezvous and docking. That can get tedious enough as it is before prolonging each R&D sequence with a slow clock, even if it's only a small reduction "into the yellow". The same argument is why I use standardized rocket lifters from the KSC instead of using SSTO's or recoverable SpaceX-style boosters. It multiplies the repetitive game-time the player has to dedicate to each rocket launch, which again can get tedious when assembling an interplanetary ship or a large surface base somewhere. Personally, I don't understand why we're still debating this, none of our gameplay styles are gonna change; and like Rune put it, I build to play. I'm a KSP player first, and craft builder second. All the craft I publish are craft that I use, or have used, in my career save. I don't publish anything that doesn't have a practical purpose in my gameplay. And in my gameplay, a slow clock is a hindrance, therefore part count is not an "excuse", it's an ever-present consideration in the VAB.

I really am not the best to answer that. I believe there was a bug like that before, but I don't recall for sure. "1.X" covers a LOT of versions and bugfixes, so that's another wildcard. I personally would recommend getting 1.3.1 if you're just getting back into it, before you get really invested in a save file, but that's your prerogative. _______________________________ In other news, I updated four craft today. The first I wanted to point out is the EV-2L 'Runabout'-Lightning. For some reason, a lot of the RCS thrusters on the crew capsule had "Fore by Throttle" enabled in the Actuation toggles, I have no idea how or why that happened, but the version on KerbalX has been corrected. The other three are the PD-32 and PD-64 orbital propellant depots in the Robotics section, and the 'Lightning' rocket itself in the Rocket Market. Each of these craft lacked the Communotron 16S on the LITE stage's probe core. This could either be a big deal or a non-issue depending on the state of your comm network. or even if you play with CommNet enabled.

Oh, you really don't want me to stream most of this stuff...it is agonizingly boring to watch I'm sure. It's not boring for me, because building large complex projects that solve engineering problems is satisfying for me, but there's a lot of sitting there and thinking while staring at the monitor. Ha ha, my career really isn't that chaotic, but it does have a substantial persistent file size.

The SM-N1 is also a really lightweight payload, at 0.86t. But even in the EV-2L configuration, which is basically a LITE with a 7.6t crew module as it's payload, it should still be able to make a one-way trip from low Kerbin orbit to low Duna orbit. But that's just using straight numbers and a delta-V map, and I wouldn't "subject my Kerbals to an interplanetary trip in a single capsule". Actually using some of these craft in such a manner is another story since I don't use MechJeb, and sometimes I'm not exactly on my game when I plot maneuver nodes for interplanetary transfers. This is why I always take my craft on a test mission before publishing; sometimes the margins are just a little too close, needing some craft tweaking. This is also precisely what I'm doing with my M3V interplanetary/orbital elements this week... _________________________________ Instead of being packaged like the EV-4 modules, which was one launcher per one module; or as subassemblies like the SM station modules, requiring the player to mate them to rockets; a lot of the M3V components are being packaged as "Kits". An example of one of my verified/tested kits is the 'Ike Logistics Kit': a Titan 4N loaded with an IV-1B ISRU rig and an HLV-5B fuel transport lander. Since the NITE upper stages from the Titan 4N's serve as both interplanetary propulsion stages and then remain as fuel depots, you can establish an initial propellant refueling capability in the Duna SOI with one launch. So far I've built 11 of the 14 initial series of kits, and tested/verified 8 of them. I'm sure more kits will come later, but I'm also sure they won't cover all the various combinations a player may want to assemble into an expedition. Some of these kits will have spare payload space for additional equipment the player wants to throw in. But outside of those cases, it will be on the individual player to reconfigure as necessary to suit their needs.

New mission-creating aspect, new parts, etc? Why would people pay money? 1) Native support for those additions out of the box (mods are hit or miss depending on the dedication of the mod creater) 2) Good chance it will already be localized for several languages, with several more future languages already announced (mods are dependent on mod creater) 3) Content will be ready to use immediately after any future updates (modders have to play catch-up after an update, despite Squad making efforts to give them a headstart) 4) Some players can't or don't like to use mods due to computer limitations or personal preferences. 5) Some players (including me), are planning to pay for the DLC to support Squad. If someone chooses not to pay for the DLC, that is their prerogative. However, if you don't plan on getting it, and it does nothing to affect your current or future gameplay, what's the issue? If a player didn't use mods (for whatever reason), and he jumped down to the Add-On Releases/Development and started posting "Why are all of you using mods? You shouldn't use mods for reasons X, Y, and Z", what purpose would that serve other than to garner further friction and arguments among the forum community. Not to mention that nobody really knows the full scope of the DLC content, nor the price, and any conclusions drawn from such a lack of information is foolish.