swjr-swis

If the choice is to go with this overall design for one of the hab modules, might as well pick Johnster's. Although in my opinion, the can design costs too much for the capacity and function it offers. So I guess my actual suggestion is to not use either one of these, but you guys make your decision. These were just examples really on what can be done at less cost, but like I said, feel free to use them as is if you wish. I did go and retouch them to remove the DLC tanks and uploaded them to the following links (under different names): KCSS-Hab-1: https://www.dropbox.com/s/vfe6adjc5zlmgza/KCSS-Hab-1.craft?dl=0 KCSS-SpaceBnB-1: https://www.dropbox.com/s/f0iqztdb6xp0hjq/KCSS-SpaceBnB-1.craft?dl=0 Both can be lifted comfortably together to a 125km orbit by the Kerbal XM, with a custom fairing. Which means the tug on the Hab-1 is superfluous and can optionally be left out, to save mass, parts, and cost. And since the SpaceBnB already includes a cupola, there really isn't need for a separate module for that - more funds saved. That still leaves a good bit of payload room to take up on that same flight, to make the most of it. A core module perhaps, to make the station operational from the very first launch? At least for tourism, which could start making some money while finishing the station. As for participating: I don't think I'm needed. I'm also having some scheduling issues due to workload. I think I'll watch this unfold. But I make no promises that I won't do this as an individual challenge.

Shouldn't need to wonder: at distances that make solar panelts irrelevant, a small tank of LFO and a fuel cell wins this every time.

Likely, something like: Specifically, the part:

A few things to consider: Take a critical look at the price and weight of parts you decide to include in your module. Some parts, while very pretty, carry a heavy cost in funds and mass. It is worthwhile to 'shop around' and see what alternatives there are and how much can be saved. example 1: the Atmospheric Fluid Spectro-Variometer looks very nice as a greeble for an EVA or airlock module. At 6500 a piece, that's an expensive greeble though. Replace it with a Surface Scanning Module, admittedly a little less impressive looking... but you save a lot of money that can be put towards another module, a bigger lift vehicle, or the development fee for a Sky IIIA if we really need to. example 2: Do we really need a heavy and expensive Mk1-3 pod / lander can combination (with lots of fuel and engines) for an emergency evacuation from a relatively low orbit? Requiring us to send it up with a very expensive large lifter. Or can we suffice with a solution using cheap and light Mk1 crew cabins with just sufficient fuel to deorbit, a heat shield, and a few chutes... and allowing us to lift it on a much more economic vehicle? Also, I see almost every proposed module including a relatively huge tank of fuel and LFO engines. Why? Other than a small tug for orbital assembly and a station-keeping module with limited fuel/thrust capacity, a station does not require engines at all. The modules should be rendevouzed near enough to the station to suffice with RCS for docking, or be within range of the one station tug to fetch. Consider using 2.5m fairings for the main truss functions. Fairings offer a lot of benefits for station constructs: they can be of almost arbitrary length, can vary seamlessly in diameter as required, and provide multiple attachment nodes to firmly attach docking ports, all within a single and relatively cheap/light part. Consider grouping functions into a single module. You seem to be thinking of modules in terms of separate functions, but the rules do not forbid to combine functions in one 'module'. A module should be defined in terms of what can be made to fit on a single launch (mass and size-wise). So if the core module can already fit a few seats, some basic comms, an airlock and an initial docking pier... why make those all separate payloads? Alternatively, when you think of launching payloads, think of how to make best use of the payload capacity of a vehicle. If one module pushes us slightly over mass budget and we have to use the next bigger lifter, what other module can we add into that launch to use the remaining payload budget?

Just a quick heads up: the proposals I posted here were just that, proposals, to give you good folks something to think about. I was seeing (and still see) a lot of excess cost and weight being submitted for a challenge that kinda requires heavily optimizing on both of those constraints. But if you guys are serious about wanting to use my proposals as is, I will look later today at removing the spurious DLC mono tanks (which were there to conform to the design drawing) and/or see what other modules/vehicles I can come up with.

Or... post a craft file and maybe one of us resident nutcases might build a working lifter for it. Some people here are pretty good at launching contraptions that have no physical business whatsoever trying to make it to orbit.

So, what you really need is something that can go up on a Sky III (payload limit 16t) and be as cheap as possible. Could've said that to begin with. The starting budget is a rather heavy constraint. You folks need to design your modules much more with that in mind. How about an alternative design for the hab module that weighs in at just over 15t and costs 24.6k, and offers a 16 seat capacity (8 researchers or 4 tourists)? With just a slight modification, this could be transformed into a fully ready tourism module to start getting extra funding for the remainder of the station. Just over 18k and 11.5t for up to 4 tourists at a time: And still just over 5t payload room left on a Sky III launch. Place one of each of the above and you have enough habitation room for a steady stream of tourists (and funding), while still having plenty of room for researchers (who will require labs to be added). Something to consider.

500 m/s is very close to getting into a minimum altitude orbit around Mun. You could blast away all your lander fuel into suborbital, then get out and push...

You are quite specific in your drawing, so not sure why this requires help. But I have to say, the design leaves so many questions. If you really mean the RCS blocks to be placed at the 90 degree points of the top and bottom cans, one of the thrusters is going to end up on top of the cans' ladder rungs. Why not at the 45 degree points? Same for the two radiators - the way they are drawn, one of them will be on the ladder (assuming the small circle on the cans means one of the windows and not the hatch). You don't draw any solar panels on the hab module. Is that intentional? Do you really want just one set of 3 large batteries under one of the center can window? Or do you mean them to be placed in symmetry under both windows? You don't specify which RCS tanks to use for the center can. Looks like two Stratus-V Roundified placed together? Why not a single Cylindrified instead (more capacity and less parts)? And why 2x2 instead of 1x4? The antenna placement (a Communotron 16 I presume?) is a bit subobtimal for stowage in a cargo bay or fairing. Why not a 16-S instead (same range, same mass)? Why a decoupler on the tug, instead of a matching docking port? It doesn't save any mass, and it only limits the reusability of the tug. No antenna on the tug? How are you going to keep contact with it to control it once it decouples? You ask for RCS tanks (DLC round?) on the tug, but no RCS thrusters. What is the RCS on the tug for? You draw panels only on one side of the tug. Is that really what you want? You ask for 'small engines' (?) in 3-way symmetry on the tug, but don't specify which engines. Correcting for some of the issues mentioned above, is this what you have in mind: Craft file: https://www.dropbox.com/s/8v4n0fvlygy8imv/Rover6428-HabModule.craft?dl=0

The flight recorder will show these transmissions from right before that screenshot: Jeb: "Mission Control, how long before the recovery crew gets to us to open the hatch?" MC: "We estimate about two hours, Jeb. Conditions are good and they're making good time." Jeb: "Yeah... we're gonna need them to hurry up. That last batch of snacks I had before reentry had passed its expiration date, and is now bound to make a violent reappearance in the next 15 mins..." Bill: "Arghhhh Jeb, you idiot!" Jeb: "I was hungry!"

I think the part library and the texture variant schemes could be very usefully combined to make cross-section sizes immediately clear: Decide on a primary/default texture set for each cross-section size to identify parts of that size. Create if needed (probably will need a couple extra texture sets to do this). Make sure all same-sized parts have a default variant in the chosen identifying texture. Here's the trick: make the part library thumbnails show in the identifying texture variant for each cross-section. ... Profit. I mean, Voilá: instant recognition of each size part set. The 'primary' texture variants don't need to be exclusive to a cross-section (some players will still want to create craft with a unified look). As long as each cross-section has its own primary/default, this should help players to quickly identify the parts.

We need to let (EA, Paradox, Dovetail Games, any other game company/publisher making most of their income off DLC) know about this, they all obviously missed the memo...

Good stuff. Agree on the general comments about reorganizing the UI so it minimizes vertical screen space used. For those suggesting the text can be much shorter, please keep in mind localization variations - some of the other languages need considerably longer words for the same thing.

KSP 1.3.1, pure stock - just under 20 seconds. KSP 1.6.1, pure stock - just over 20 seconds. KSP 1.6.1, with DLC - just under 38 seconds.

This is a trick question, yes? But I'll bite. Here's what I can think of (aside from things already mentioned above): Part pressure limits Part G-force limits Variant themes (the textures) - offers a lot of promise of quickly giving entire ships a specific look... but would need more consistency, and variants would need to be rolled out over many more parts Part variants (the models) - lot of promise here too, and it's slowly being fulfilled with the revamps, but still a lot of untapped potential Part variants (what they don't do but everyone hope they would) - fuel switching, the big absentee Most part cross-sections miss at least several types of parts (and somehow never the same) - it's like we got a few samples of each size, just to get a taste of what's available, and then we never got the rest of the sets Tech tree - seriously, isn't is about time to sit down and take a good hard look at letting this make just a lil more logical sense? Ore/Mining/Resource system - it's too slow for mid-trip refueling (unless we're all ok with wasting tens of years on 'refueling' to continue a trip), but there's no point to it for long-term stay either. It needs an overhaul or a purpose, probably both. Practically featureless celestial bodies - they need some more reason to (re)visit. The barn - Yes, I said it. Bring it back. Optional if need be, but make it happen. Facility progression really needs a step or two more to make sense. The mythical missing planets Easter egg storyline - really wish they'd write up some sort of 'ending' to this; almost anything would do at this point Signs of life at the KSC: we see the (optional) ground crew and vehicles when in the SPH and VAB... when do we get to see them while in the space center view or flight scene? It is still very weird to see all the activity from inside that goes completely dead when outside. Signs of life on Kerbin in general - all those kerbal recruits must come from somewhere, there's some dead archeological sites... it's really missing at least a couple of spread out population centers. And more landing/launch sites.

Would love that too, but I've been told by people with actual modding skills that PAW buttons for which no module is preexisting require coding - iow it can't be done with a simple MM patch.

Hush. It was right after the holiday feeding frenzy, and Valentina is still touchy about the subject.

It does indeed. Good job. Speaking of the slickness of RV-105 blocks: will you also take a critical look at the drag box values of these? Perhaps lowering the drag of these to something a bit more reasonable for such tiny parts...

We can't trust kerbals with such things. You know where this will lead. Minmus-flavoured icecream-ball catapults and cannons, that's what. There will be war, kerbals will deplete Minmus, there'll be dead fat kerbals lying helpless everywhere groaning with indigestion, and it will all be your fault for suggesting such parts in the first place. Are you happy now? Are you?

A poll asking for a next op from someone named Triop... and it ends at only two options. I am disappoint. But I will help. It has to be fitting with the other two, of course. You have highest, and deepest... how about right in between? Challenge: find the stretch of (barely) dry land where you can drive the longest distance in a perfectly straight line while maintaining a constant altitude of 0m. Stock altimeter accuracy will be accepted. Become famous now. Say no to elevations and descents. Accept your inner ASL. Make that zero-point drive.

A long time ago in KSP 1.1.0, Valentina used a single Kickback SRB to get to LKO... Full album: https://imgur.com/a/7Q0pt (not sure if this works anymore, imgur seems to have killed the albums feature since yesterday.)

Crispier texture and the glow looks good; right amount of detail for a part this size. Animated gimbal will be a nice addition. The model change I'm not sure about though. It looks considerably less aerodynamic than the old one. I really hope the drag box values are not worse - the Twitch is most often used in tiny craft on which small changes in drag have a proportionally larger effect. It also looks like we're losing a gimbal axis with this new model, seeing as the hinge at the top would only allow rotation in a single plane - again, really hope that is not the case, as it will kill pretty much every craft/assembly I've used this engine in. It looks like the thrust vector will be changing from the old to the new version, from slightly angled to straight down. We'll have to see how that affects old craft.

The last 'vessel' I planted over the Kraken was basically an Mk1-2 pod, a TVR-400L stack quad adapter, with 'legs' made of two Kickback SRBs stuck end to end and rotated out 45 degrees from the quad adapter. The Kraken fit under and inside this pyramid-like cage. It should give you an idea.

This poll misses at least one more option: add chronological sorting as one of the possible options. I do think sometimes chronological sorting is handy. Other times though, I need other sort options, like alphabetical, when I'm searching for saves of which I know the name but not when I saved them. So useful yes, but only as part of several sorting options that we can switch as needed.

The usual problem is having SAS on. SAS basically overrides any trim settings with its constant adjustments. To use trim, you have to fly with SAS off.