Raptor9

Nice I like that shark-teeth radome. I hadn't realized BD Armory had advanced with so much detail.

I have no idea, I don't use Mechjeb.

My simultaneous refinement of the HLV-5 and mining rovers is going great. At the moment, two different "front ends" to the HLV-5 can be fitted to the aft propulsion section (basically a LITE upper stage with a lander mission kit installed like the ULA DTAL/XEUS). A crew section which can be seen in previous images in the thread here, and a cargo delivery rack. The cargo delivery rack has a toggleable ramp for deploying rovers; in this case the MIR-series (Mun ISRU Rover) family. Also, compared to my previous iteration of mining rovers, these rovers (in the image below) have a much lower part count. What you see in the image is 114 parts, but in reality, you can get away without the ore storage rover, bringing the total part count for an entire mining operation down to 91. The reason I even have the ore storage rover is to provide additional ore overflow tankage, and as a delivery vehicle to an ore hauler for those ore delivery contracts. More rovers could be brought in, such as additional propellant tankers, additional drills, or even power generation equipment. All rovers are based on the same chassis height with the docking ports at the same height (or close enough). The propellant "fuel truck" has an additional port mounted up higher for plugging into compatible landers (which already include the LV-3A, LV-3C and Base Module - Utilites, but will also include the upcoming HLV-5 and LV-2D reusable landers). This assembly in the image has enough power (in sunlight) and thermal control to keep the system running steady-state with one Converter function activated. If operations are to continue with additional equipment or in darkness, additional power generation options will have to be plugged in.

The bug that is shown in the OP is a Hyperedit problem. I've seen this exact situation myself with Hyperedit in KSP 1.1.3, and so have users in the Hyperedit sub-forum. A work-around appears to be: "teleport to orbit, then go to Space Center and back." What gets me is that players still immediately jump to blaming Squad for bugs they encounter after posting screenshots (or in this case video) of a KSP install that clearly has mods installed (in some cases, a metric ton of them). Squad is not responsible for bugs that are generated from the installation of a mod. Having said that, Squad has very smartly been working with the code of KSP over the past several versions of KSP to ensure it is mod-friendly (not mod-proof, that's impossible). It would seem they [Squad] recognize that a significant portion of the KSP fan base leans on mods as a way to enhance their gameplay, however Troubleshooting Step 1 should always be "Attempt to replicate bug in a mod-free KSP install".

Man, those saddle trusses look legit.

I've considered it, but never did because I never really made probes myself in my career save. That and contract requirements would always dictate what equipment you had on a satellite. Having said that, I probably will in the near future at some point. Now that I've gotten a solid set of craft files for Duna landings (and I'm obviously looking into Ike, Dres, and Eve equipment), it makes sense to have something to scout potential landings sites (ie, places that are level and have adequate concentrations of ore for ISRU propellant generation). Having a probe or rover icon on the surface will also give the first lander a target to shoot for. If I do start making something along those lines, it will probably begin with a Curiosity-style Duna rover...because-do I even have to explain why?

That's why I use conventional rocket tanks drained of Oxidizer for powering my LV-N's. To my mind, the additional empty volume would be where the less-dense Hydrogen volume would need to occupy for an NTR-powered ship. As @Rune puts it, I "self-impose challenges" on myself. I have no idea if the actual volumes would be accurate (probably not), I don't care to get that in-depth into the real-life comparisons.

I sure have, but in my current play style, I don't see any benefit to it. Unless you're playing with mods that require life support or snacks, their's no requirement for an analogous craft in KSP.

So I downloaded and installed Kerbal Engineer for some hard delta-V numbers. The EV-4 Block 4's outboard NTR Mk3 assemblies I believe were what was hindering my transfers to Eve. Looks like the additional mass of the NTR Mk3 modules (with four LV-N's on each) were more or less compensating for themselves and doing nothing for my overall delta-V. Since I waited so long to jettison them, that's probably why I couldn't do an efficient Eve transfer. The delta-V numbers on the EV-4 Block 3 look promising at just over 6700 delta-V. That should be enough, but only a few test missions will determine that for sure. Assuming your quoted statement is correct, and the EV-4 Block 3 can make it to Dres and back, it should be able to do a transit to Eve and back.

Nice Saddle Truss

Only 10%...? You must use it way less than most people I know. This post was where I first posted an image of it. It hasn't changed much, the most noticeable change is I ditched the fixed landing gear so it has a better launch profile inside a fairing. Yeah, the prototype has been around that long, I've just been focused on other stuff while it gathered dust. But I'm now simultaneously working on the HLV-5, a brand new reusable lander, and the ISRU rovers to ensure they all work well together. I'm not just thinking about Mun operations anymore; I'm thinking about Ike, Dres, etc where it just doesn't make sense to have two-stage, expendable landers like the LV-1A/B or LV-3A. Otherwise every time you wanted to go back down to the surface, you'd have to send another fresh lander from Kerbin across deep space...transfer windows...expensive propulsion stages...AHHH! A little ways down that page you may also see this post. While the HLV-5 will feature a separate crew ascent stage, it's use may become optional depending on total delta-V results after the design is finalized.

Oh don't worry, I hardly use any pop culture references at all. I'm actually a pretty boring person to be around in real life. I don't even use social media...

You were clear. That's why I had this paragraph in my long post a few hours ago in response to your initial comment posted 9 hrs ago (with emphasis added just now ): " Remember, the whole point of the EV-4 'Longship' block configurations are to serve as a transfer vehicle for Kerbalnauts in the same manner of the Constellation NTR-STS. While you can use some of the components to transport cargo or other unmanned stuff to other destinations (which can get away with being one-way trips), the ships themselves are designed for crewed missions. That means they need to support an efficient landing & ascent strategy, as well as efficient interplanetary transfers." I understood what you were getting at with unmanned cargo drop offs, but I was countering your point by clarifying the purpose of the 'Longships' themselves. The EV-4 'Longships' are interplanetary crew vehicles, not cargo transports. However, it just so happens you can use their propulsion and fuel tank modules as a means to transport cargo, but the primary focus of the EV-4 design considerations remains crewed missions. That made me laugh...cuz it's true. Although I have no idea what "greeblies" are.

If that's true, I must be drastically messing up the interplanetary transfer from Kerbin to Eve and coming in at a much steeper angle across Eve's orbital path than necessary. I'll run a few more test transfers to Eve this week. Maybe I was just having one of those days during my last attempt. Well you still have the problem of ensuring the ascent vehicle has either enough remaining delta-V to accelerate into a matching orbit, or you dock with an orbiting fuel/propulsion section to do it for you.

Nice. Whether it's landing a capsule on KSC or splashing down near the beach east of the pad, or landing a spaceplane back at the KSC runway, it's so satisfying to nail a good landing back home; so you can hop out, stroll to the KSC parking lot, and drive your Kar down to get a post-mission brewsky at the local pub.

The two immediate problems with leaving the interplanetary transfer vehicle in a highly elliptical orbit are: 1) The periapsis would be out of position for the Eve ejection burn. I could either adjust the orbit so the periapsis is synced with the proper ejection angle, or use the periapsis as is to enter into an interplanetary transfer trajectory and adjust the trajectory during one or several mid-course correction burns. In either case, I estimate the amount of delta-V required to do either would be significant. Further, depending on the interplanetary approach angle back to Kerbin, I may have to spend an even greater amount of delta-V to capture into Kerbin orbit due to the steeper approach angles. 2) Any ascent vehicle would have to have a large delta-V reserve to not only make it out of the Eve atmoshere, but also speed up enough to enter the same elliptical orbit as the transfer vehicle. (Same problem they encountered in "The Martian" when trying to intercept the Hermes at the end) Remember, the whole point of the EV-4 'Longship' block configurations are to serve as a transfer vehicle for Kerbalnauts in the same manner of the Constellation NTR-STS. While you can use some of the components to transport cargo or other unmanned stuff to other destinations (which can get away with being one-way trips), the ships themselves are designed for crewed missions. That means they need to support an efficient landing & ascent strategy, as well as efficient interplanetary transfers. To that end, these are the two possible mission architectures I'm looking into: Mission Option A (similar to NASA's Mars DRA 5.0, with a slight variation): 1) Ascent vehicle is sent to Eve ahead of crewed mission. EAV (Eve Ascent Vehicle ) conducts EDL to a suitable landing site. ISRU generates propellant for EAV (I'm assuming I'll need to burn the bottom stage engines to adjust final landing and touchdown location). 2) Crew lander is sent to Eve ahead of crewed mission in same transfer window of the EAV. Crew lander propulsively captures into a high circualr orbit around Eve. 3) Crew transfer vehicle departs Kerbin during next transfer window, assuming the EAV has generated propellant for ascent trajectory. Transfer vehicle rendezvouses with crew lander in high Eve orbit. 4) Crew lander alters orbit to enter a low Eve orbit (~100x100km). The lander will consist of three modules: - A lander module itself which will bring the crew to the surface. - A habitation and docking module. - A propulsion module most likely powered bya single LV-N. 5) Crew lander leaves habitation and propulsion section in low Eve orbit while the lander itself touches down near the EAV. Crew conducts surface activities for whatever amount of time. 6) Crew uses EAV to return to low Eve orbit and R&D with the propulsion/habitation module. Ascent vehicle is jettisoned and propulsion module propels the habitation module back to the interplanetary transfer vehicle in high Eve orbit for the return trip back to Kerbin. Mission Option B (almost the same as Option A, with additional objectives to Gilly): 1) Ascent vehicle is sent to Eve ahead of crewed mission. EAV conducts EDL to a suitable landing site. ISRU generates propellant for EAV. 2) Eve crew lander and Gilly lander is sent to Eve ahead of crewed mission in same transfer window of the EAV. Eve and Gilly landers propulsively captures into Eve SOI and transfers to parking orbit around Gilly. 3) Crew transfer vehicle (carrying additional crew for Gilly surface exploration) departs Kerbin during next transfer window, assuming the EAV has generated propellant for ascent trajectory. Transfer vehicle rendezvouses with crew landers in Gilly orbit. 4) Eve surface crew executes same sequence of events as before, staging from Gilly orbit. 5) Gilly surface crew executes Gilly landing. Both surface crews conducts surface activities for whatever amount of time, after which Gilly crew returns to the interplanetary transfer vehicle in the same single-stage lander. 6) Eve crew uses EAV to return to low Eve orbit and R&D with the propulsion/habitation module. Ascent vehicle is jettisoned and propulsion module propels the habitation module back to the interplanetary transfer vehicle in Gilly orbit for the return trip back to Kerbin. So a lot of moving components, but I believe that these scenarios provide a good solution to managing delta-V budgets as well as keeping the individual ship part counts low. There will undoubtly be a large part count in physics range when the EV-4 'Longship' rendezvouses with the crew lander in high Eve orbit/Gilly oribt, but it would be less than with a heavily-fuel-tanked EV-4 R&D with the crew lander in low Eve orbit. (If you've made it to this point in reading this long tangent, I'm impressed )

The updates to my EV-4 'Longship' Modular Exploration Vehicle series are now finished (with the MEV Block 4 undergoing review to determine it's viability, but I'll get to that in a second). I'm much happier with the refined state of the series now, and managed to iron out a few shortcomings. I've consolidated all the modular components to a single print which allows players to see the extent of their options for orbital assembly. [@max_creative, I'm looking in your direction with this next sentence ] I'm also happy to declare my MEV Block 3 is certified for Dres transfers, with the caveat that it's launched from Munar orbit instead of LKO. The amount of delta-V it takes to get out of LKO to higher altitudes, like the Mun's, is a significant hindrance IMO when going further out beyond Duna's orbit. Of course, nothing stops anybody from throwing a little more propellant onto their EV-4 if they don't want the hassle of re-positioning to Munar orbit to top off on liquid fuel. The below image is the EV-4 Block 3's arrival at 15km Dres orbit: The prints in the OP provide better detail of the EV-4 Block 3, as well as the newly updated list of EV-4 modules. Notable differences from the Block 1 & 2 configurations include the brand-new EV-4 In-Line Tank Mk3, improved 'Star' Truss Assembly, and the cupola-style cockpit. When used as a faster transit Duna transfer vehicle, the Hab+Lab Mk2 module should probably be swapped out with a Mk1 so an EV-2C 'Runabout' crew vehicle can be docked on the front. As usual, download links available on the OP. And please report any issues (as with any craft file really) Some future additions I'm looking into are strategically placed O-10 'Puff' monopropellant-powered engines. When a series of In-Line Tanks are used on an EV-4, the amount of monopropellant reserves climbs significantly, and this resource could be put to good use as a more logical rendezvous & docking (R&D) engine instead of firing up the LV-N's. The real-life NTR-STS vehicle from the Constellation program was to use it's maneuvering thrusters for R&D maneuvers as well. Regarding the Block 4, this is shamefully a design I hadn't play-tested since 0.25 or 0.90 timeframe. Yeah. I tried a test Eve transfer mission today, and no dice. By the time I reached the target 100x100 km equatorial altitude, I was down to 4000 units of liquid fuel left. There was no way I was going to get anywhere close to escape velocity out of Eve's SOI. So for now, the Block 4 is on indefinite hiatus. Most likely I'll have to come up with a new module combination to increase the total delta-V while retaining the higher TWR of the MEV Block 4, or develop new modules altogether. We'll see, but don't expect much progress on this front.

Well, I should note that it never stopped working for me, aside from certain washout conditions depending on VAB/SPH lighting conditions. But that can be worked with. From reading the KVV thread, some people are in fact having issues with KVV not rendering at all. Assuming some of those users are windows users, it may depend on computer hardware, like what graphics card they have. I have no idea.

Thanks Rune. The OP overhaul a month or so ago was a bit of work, turning it into an expandable "tree" of spoiler tags, but it needed to be more user-friendly after the sheer amount of craft I've posted this past year. But really, the craft file "brochures" that I do aren't too bad when done one at a time as craft are posted on KerbalX. If I had to do a bunch of them at once (Like with the EV-5/LV-3D/LV-3E and associated lifters last month), that's what becomes a pain in the cheeks. But it's sort of become my thing, or my standard, so I don't think I can stop now.

Ha ha, I read your comments on the previous page and saw you were 999...so I liked one of your posts.

I've been playing KSP for years and I didn't even know this. I thought the very same thing. Ever since the RCS thrust limiter tweakable became available, I've been thrust limiting and tweaking every craft to try and get the balance right. And yes, I also know about placing RCS thrusters around the CoM, but sometimes it's not possible (like spaceplanes or other asymmetric designs). The other drawback is that if you change your control axis, such as selecting your docking port as the "Control From Here", the ship won't rotate/translate correctly because the axes have changed orientation. Makes docking a pain sometimes, but regardless, I'm glad that capability is there. Now if we can make it so enclosed RCS thrusters don't enable themselves when the fairing is jettisoned. If I disable the thruster in the VAB, I don't want it to activate until I Action Group it...

There's a lot in @Pthigrivi's post that I like. Regarding updating planets and such, as much as I would like Gas Planet 2 (and/or 3), more gas planet moons, more interesting terrain (like real-world Mars), and other cool phenomenon like ice geysers or weather...I think if we see anything like that it will be a ways off. However, to address a few of the previously asked questions with my own two cents: adding more stuff to do on a planet I believe would be a bit more manageable than "Planet Overhaul 2017". I am no programmer, just a KSP player, so I'm probably about to speak out of my rear end here. The following are a few things that I think could be implemented with an update or updates that don't require the scale of the KSP 1.1 update. At the moment, when you build your first surface base, the only two contracts (that I've so far encountered at least) that allow you to get repeated use out of the base itself are resource extraction/refinement, or getting "Base Expansion" contracts. The second contract type is especially troublesome to me as, depending on your skill level and computer hardware, after a while the amount of parts in physics range may start dragging down your gameplay. Point #1 addressing "Things to do": I would propose that the likelihood of getting a surface survey contract (ie "Take seismic surveys at Site Alpha, Beta, Gamma, etc") in the immediate vicinity of your surface base goes up. This would give the Kerbals on-site consecutive scientific jobs to go out and complete, so Bob climbs in his rover and checks out some random crater a few kilometers to the east of the base. The more of these surface base area surveys that are completed, the further out from the base they will continue to populate or be more spread out in area. Point #1 gameplay additions: - Player gets more utilization from his surface base. - Player is encouraged to develop reliable and/or better rovers (or even aircraft for atmo planets or small thruster-craft for vacuum moons) to cover increasingly larger areas and/or longer distances from the surface base. - If a player prefers brand new survey sites not close to the base, or if he/she does, the appropriate contract will become more prevalent based on the player's contract acceptance preferences. Point #1 estimated development requirements: - Contextual Contracts aspect would need to be updated and revised. Point #2 addressing Base Part Count: A dedicated set of surface base parts would need to be developed to not only further encourage surface bases, but it would provide a more manageable long-term base expansion contract scheme. Namely, these parts would really need to be "assemblies". A single-part base module that lacks only utility additions such as wheels or antennas or the like. One such mod that I think would be an outstanding example of this strategy is Kerbal Planetary Base Systems. Many of the part modules serve multiple purposes or store multiple resources. One such part has fuel storage, engines for propulsive-landing, and properly oriented side surfaces that can easily accept landing struts or wheels. This combines fuel tank parts, engine parts, and any structural pieces for mounting all into a single part tracked by KSP physics. The same could be said about new and dedicated rover command pods or chassis. Point #2 gameplay additions: - Parts better suited to surface base gameplay (ie, the existing PPD-10 Hitchiker pod and MPG-LG-2 Processing Lab are somewhat cumbersome to correctly orient and piece together on the surface. These parts are more optimized for space travel in my opinion). - Any given computer would be able to handle larger bases due to an overall reduced part count per base module. Point #2 possible limitations: - When incorporating several functions into a single part, this may limit a player's creativity or construction options to a degree. A proper balance would have to be found between the lego-like system of KSP, and keeping part counts low. - When incorporating multiple functions into a single part, a bug that affects one system has the potential to affect the use of the entire part. Point #2 estimated development requirements: - Brand new parts would need to be developed or existing mod parts would need to be updated/incorporated into the stock game (sort of like Spaceplane Plus in KSP v0.25). - All aspects of career such as tech tree, contracts, and science system would need to be updated/tweaked to reflect additional part types. Obligatory Caveat: Again, I am no programmer, nor do I understand what goes into programming a game like KSP. The above paragraphs are simply what I think would be a more manageable "short-term" project to give us all more to do on the surface. Also, I understand that the bulk of these suggestions address Career gameplay, and some KSP players prefer Sandbox (or Science).

I hope you weren't burning the midnight oil waiting for that little feature.

I guess you have more attention to detail than me.

@Majorjim, how's your HLV's coming? Looking forward to seeing your versions of the aeroshells. I missed something in all those Mars DRA documents. The Constellation Mars video at 7:15 says "Jettison MAV and Contingency Consumables"; I always assumed that meant the contingency supplies were moved by hand from the aft circular container into the MAV command pod prior to jettison. However, after taking closer analysis at one of the previous documents you and I discussed, it appears the entire T-shaped docking module (which includes the transfer tunnel and consumables container itself) was jettisoned prior to the trans-Earth-injection burn out of Mars orbit. I wasn't even aware that assembly could be detached, but I guess that makes sense if using the Mars Transfer Vehicle in an expendable mission mode since you won't need that docking port again if riding the forward-mounted Orion into Earth's atmosphere. Cuts down on total mass and bumps up the delta-V a little. As a result of this new information, I've created updated versions of my crew modules that feature detachable docking/service modules. This also allows different configurations for Munar or near-Kerbin asteroid missions, but I'm not really focused on those as the main goal of the EV-4 series. The primary design destination remains Duna, with secondary destinations to Dres and Eve.