DStaal

Just wanted to do some cheering on: I love this mod, and I'm looking forward to it in 1.1 whenever it gets completed. Know that people are enjoying it, and waiting (semi-)patiently for you.

Also interested to know... and do you have your patched files available someplace? I use those antennas a lot as well.

As a thought/request: Could you add an EL spawn point to one/some of the T404's? They'd make good spacedock bays. (An interesting one would be to have a spawn point inside a T404 'hold', with a side that opens up. It'd be a decent place to build small probes/landers, and the idea of building 'inside' another ship would be fun.)

Rovers would often end up underground or partly underground for me - until physics loaded and fixed things. (And if I wasn't focused on the rover when physics loaded, it would stay in an odd state.)

Given that the standard advice when something happens from RoverDude is to uninstall the CKAN version and install manually, and see if the problem persists, I'm not sure this is great advice. CKAN is great when it works. It doesn't always work correctly. Knowing how to fix it then is a good idea. The official download from GitHub includes all needed dependencies, in the correct versions. If you're having trouble, start with that. @Goat Master, if you put up a pic of your GameData and UmbraSpaceIndustries folders, we can check to make sure you've installed it correctly.

The algae farm is really more Ore into fertilizer than mulch, but it needs a bit of mulch as well. (.002 Ore + .00075 Mulch) Which makes some sense, in the context of algae.

Just wanted to say: There are no struts in the first ship in my post. There are some fuel lines, however. The transport ship has a fair amount of struts, as I'm not sure how strong all the parts and connections are. (And the two sections of 'let's do four fuselages for a bit, then back to one' would be great in real life, but I'm not so sure that they'll work as well in KSP. So I strutted fairly heavily through there.) Glad you like the design. I spent entirely to much time on it. (About two weeks of gameplay...)

Sorry, forgot to grab it in the VAB, will on the launchpad do? (http://magehandbook.com/screenshot15.png) Yes, the reaction wheel is way out of place - probably a factor in it's wobbling - but I didn't really have anything else that fit the form factor. (And the smaller version that I have that lifts a 3.75 Kontainer has it's reaction wheels just above the container, without issue.) I could add more fins, of course, but it'd start to look a bit odd. (And I'm not sure how many I'd need - this already has 8 main fins and 8 grid fins...) Also, I mentioned my Duna-transfer vehicle, so I'll show it off as well (I hope these images work...), since it relies quite a bit on this parts pack: (http://magehandbook.com/screenshot11.png) It's envisioned as a reusable interplanetary transport vehicle - It's using USI's FTT pack for a lot of parts, including the cargo holders. It's configured to carry up to 8 dropships, satellites, cargopods, etc. The intial configuration includes a comm net for the Duna system (to go with AntennaRange), a ScanSat tri-level scanner, an Orbital Logistics satellite (sticking out to the left - it doesn't actually fit in the cargo holder), an orbital science pack, a lander, an autonomous science rover (and lander), and a MKS Pioneer module. Most of those will be left behind in the Duna system. This was a prototype build, not intended to be launched, just built to make sure all systems worked as intended. The first production version is currently being constructed in orbit using EL.

I was talking about the radial decouplers - the model surface didn't appear to match the visible model, and things went a bit weird using your decouplers. I went with the stock TT-70 and S5 parts instead in that particular ship. (I mainly needed d/v, not TWR, so smaller engines were ok as long as I could mount a good size fuel stack on them.) And gimbals are good if you're thrusting hard, but I've been using the Gravity Turn mod for automated efficient launches, and it reduces thrust dramatically once the gravity turn is underway - 20% is the 'normal' minimum, but it'll cut thrust entirely if the apoptosis reaches your desired height, which means you're usually coasting most of the last 40-50k to your 80k initial orbit - that's when fins are most useful, to keep things aligned for the intermittent burns needed to overcome drag losses during your coast. Not that I've had any failed launches due to lack of control, but I've had some porpoising and altered inclinations. I'll see if I can remember the ship that had the biggest problem with it. Give me a bit to think about it - my Kerbals have been busy lately with massive projects in the runup to a Duna launch window. Oh - and if you were thinking 'supply depots' with the clusters, I'll have pull up my Duna mission ship. It uses it to mount 20 'Poodle' engines for the main transfer burn. (Giving me a TWR of around 2.5 IIRC, and nearly 3,000 d/v. Ideally enough for a round trip, but it'll be carrying a miner dropship which can be used to refuel.)

A couple of comments, as I'm starting to build more ships that actually use these parts: It's hard to attach the decouplers (and tanks to the decouplers) to the multi-tanks. (Yes, I needed a larger engine block than 5 behemoths...) Could we have some fins? The standard fins are fine up to around the 3m size, but they don't really give much flight control at your larger sizes. But - very fun and nice parts. I have no idea how I'd have built a couple of ships without them. (At least, if I had to fit them in the VAB.)

It's also worth noting that there is a Module Manager config in EL that gives most parts the ability to be a low-quality workshop. If he's got good engineers, that may be enough. Just check stats in the VAB info display to see how good a particular part is. (And there are also other mods that include smaller workshops. USI and Civilian Population come to mind...)

Working on it from the config side can be confusing. Look at it from the readouts in the VAB and in-game. But basically: Kerbals need space to live in. Every 'seat' is assumed to be a set amount of space - unless specified otherwise in the part config. Some parts (like the cupola) make the Kerbals happier, making the space they have last longer. If you coup up a Kerbal to long, they'll get unhappy with the space they have, and stop working, or whatever your hab requirements are set to. Hab time is how long they are comfortable in the ship they are currently in. Larger ships mean they are more comfortable, and they can hang out longer. Smaller ships mean they are cramped, and start getting grumpy sooner. (And certain parts - again the cupola as an example - can make smaller ships feel bigger.) That's based on habtime and habmultiplier. It resets the moment they change ships. Homesickness is how long they are comfortable away from Kerbin. If they've had room to stretch and move around in the past, they can go quite a while before they get to missing Kerbin - even if the ship they are currently in is smaller. The same things come into play for it, but instead of tracking just how long they've been in this one ship, it tracks how long they've been away from Kerbin, and what the biggest ship they've been in is. Both of these start counting down the moment you leave Kerbin. Both can be countered to an extent by larger ships with more hab time. Hab time can be completely reset by changing ships, while homesickness cannot - the coundown can only be extended by putting them into ship with more available living space.

That docking structure is from Planetary Base Systems. It's actually two hangers, bottom-to-bottom. (In fact, most of that space station is from Planetary Base Systems.)

By 'ahead' I mean maybe a day or two, using transfer window planner to find a solution that gets me to Duna ahead of the main ship. I've got a plot going using that and Maneuver Node Splitter so that I'm not trying something dumb like doing a burn for more than a full orbit. Basically, it should get there first, from a separate launch. Hopefully. And I thought about doing a smaller first mission - just a couple of robotic probes, doing an initial survey - but that would put my long-term plans so far in the future I don't want to deal with it. This game is slow enough as it is - typically my progress so far is less than real time, so spending thousands of days getting this done doesn't sound like fun. NASA spends time because they have to, but this is a game and I don't want to spend super-huge amounts of time on it.

Thanks all for your answers. @Badsector, I do already have Transfer Window Planner, and it's very useful. I was asking about d/v for the plane change transfers, so I could compare them to the other options where I already have the d/v. (From Transfer Window Planner and the KSP system map.) However both you and @Geschosskopf make a good point: For a small extra d/v investment, I can launch the scansat satellites ahead of time direct from Kerbin. I am somewhat experienced with injecting directly to polar orbit - I've been doing that for scansat launches to Mun and Minmus all along. (And I've been doing more of those satellites than I'm planning for Duna, as I would tend to launch as new scanners became available. The Duna satellite will be a 3-in-1, for the different needed altitudes, but it will have a full compliment of scanners.) So, my current plan is to launch a Duna scanner sat ahead of the main ship, using ion drives. (The main ship will use either chemical or nuke propulsion, to make possible a refuel on Duna if needed.) The main ship will carry a second 3-in-1 block, intended for Ike, but it can be used as a backup in case something goes wrong with the Duna scanners. This simplifies the planning, and avoids the mid-transfer separation (which sounds easy enough, but makes me nervous), and gives me the experience with larger ships that I want for future missions to other planets.

I'm in the midst of planning my first mission to Duna, and I was hoping for some advice on mission design - or, more specifically, what amounts of d/v I am going to need for a few sections of my planned mission. (And how to best allocate that, maybe.) The mission is going to be semi-ambitious: ~6 Kerbals, autonomous mini rover, lander, and return trip. All of that is fairly straightforward to plan though. The question I have is about my ScanSat probes. I'll need a couple to take along, to map out the planet before I actually land, but they of course should be in a polar orbit. I'll be entering on a near equatorial orbit from the epileptic, and I'll want to keep that so I can eject back out on it for the return trip, so I'll need to transfer the scanners to their orbit. Thus far, I see several strategies: Separate the scanners before entering Duna SOI, and have them enter directly to a polar orbit. Downsides are the possibility of needing simultaneous burns - everything becomes very time sensitive. Transfer directly from equatorial orbit to polar orbit. Downside of high d/v use. Transfer to polar orbit via Ike rendezvous. More complicated, may not actually save d/v. Perform initial scans from equatorial orbit, gradually changing to a polar orbit. Doesn't actually save d/v, but may save time on finding a landing site. (As I don't intend to land at the poles.) So I come here asking for advice, on what more experienced Kerbonoughts have thought. Importantly for me, I'm not actually sure what the needed d/v for a 90 degree plane change around Duna would be - making it hard to compare the options. (I do have the d/v map for the KSP, so I know the d/vs for transfers between Duna and Ike and so on, but I'm not sure on plane change.) I'm running US-LS, so I will be time constrained, so that is a factor to think about - I need to scan, land, get my initial survey done, and get back to my interplanetary craft in time for the next transfer window to Kerbin, or I'm likely to run out of supplies/habitation. (I haven't worked out exactly how long that window will be, but I have the tools to do that.) So, thoughts? Suggestions?

Useful chart, but it's slightly confusing: Is the planet I'm going to on the horizontal or the vertical axis? (From discussion, it's the 'leave from vertical while going to the horizontal', but it's hard be sure from the chart layout.) Perhaps a heading line above ('To') and to the left ('From') would help?

And that option seems to be missing with 1.1 and the latest Firespitter, from what I've seen in the other threads. Reverting to the previous version of Firespitter has been said to fix it - I'm not sure what other implications that might have. (This from someone who's not running 1.1, but has been following many of the USI threads, where this same issue has popped up a couple of times.)

Um... I wasn't aware that you could post images from Imgur to this forum. I see links to Imgur in a lot of threads, but I never see any images embedded into the posts.

But then they'd block the whole site, not just the images. In general, I prefer if a site host's it's own content itself, as it tends to minimize issues with 'this part of the site works, but that doesn't, but only from this location/computer' types of problems. (As well as the whole legal issue thing.) As long as they aren't overloading their bandwidth, keeping the site together is a good idea. Also, I hate sites (like this forum...) that rely over-heavily on javascript for things that can be done in simpler ways. My computers are slow enough, without webpages bogging themselves down further. And my first impression of that mockup posted a few posts up is: 'Ack, that's horrible, I hope they don't go with that.'

Wish I had time to fire up KSP right now to take an image, but I have a recent science return probe design I love - less than 2 tones with fuel, about 2 minutes to build using EL, and can return from Mun or Minmus with a large number of science samples. It heavily uses USI's Exploration and Sounding Rockets packs, but it needs an antenna for probe control - mass and cost mattered a lot when designing, so it's got minimal everything, but it performs it's function perfectly. All it needed was a Com-16, so that's all it's got. (Actually, it's got a nicer looking equivalent from an antennas pack.) Those constraints don't always matter, but they sometimes do, especially if you're designing a special-purpose probe. Oh, and as for the ec-cost-per-time issue - it comes up for me all the time. I have several mods that add repeatable science experiments that I can re-run over and over, getting a bit less science each time - and running my batteries dry from sending science home isn't uncommon for them. The DTS-M1 can send far more science home before I need to wait for a full recharge, and I can put in less solar to do so. You're thinking big ships, probably manned, with an abundance of everything it needs. I tend to build special purpose ships with just enough for the tasks at hand most often.

Well, there's the fact that it costs nearly twice as much as the Comms DTS-M1, and it has five times the mass as the Communotron 16. Oh, and it uses ten times the electricity per second than either at the 'base' rate. (Which will be adjusted by the range, of course.) So, it's not automatically the best choice for everything.

Yes, I know about that, but does the code actually use the mass, or just the supplied number from the part's configs? Quick example: Let's say I have two hab parts - one with a mass of 10 tones, one with a mass of 5 tones. Both have been set to have 3 Kerbal Months of habitation time. (I know - obviously someone isn't designing the parts correctly. But that's a different issue. ) Does the 10 tone one actually give more habitation time than the 5 tone one? I didn't think it did - I thought they would both have 3 months hab time, because that's what's in the config. Now, obviously they should have different hab times - and the part author should be using the mass to help determine that - but I didn't think that the part mass itself was calculated in by USI-LS.

I don't think mass actually comes into play for habitation, as I understand it. Although it's suggested as a good default for the modifiers, the 'base' habitation is by crew size alone, I think. On the crew capacity for the recycler I'm very sure: It's not a multiplier, it's a 'processing capacity' stat. A recycler can recycle RecyclePercent of the supplies for *up to* crew capacity. You get full recycling for all crew under that, you get no recycling for all crew over that. (So a 90% recycler with a crew capacity of 3, on a ship with 4 crew will give you a supply consumption of ((0.1*3)+1)*0.00075 per second, or 84.24 per day, which is 21.06 per Kerbal overall - but if you get rid of one crew member it would go to 6.48 per Kerbal. Assuming I've done my math right.) The point being that you can have a tiny recycler that's incredibly efficient at what it does - but you can't shovel 20 Kerbal's worth of waste into it. It just can't process that fast.

I'm enjoying this mod, so keep it up. (Though, if you're making a nearly 4m octagon, could you match the size to the USI parts? The Freight Transport Technologies Honeybadger and the MK-III adapters (the MK-III modules themselves are slightly bigger, but have ends that match that size) are very close to that size, IIRC, and it'd be nice to have them fit together. (I think they are 3.75m, so they may already.)) My other part request would be a combined reaction wheel/monoprop storage part in the 3.75 round form factor and the T404. I find them very useful, and while I have several in smaller sizes (and USI has two in the 3.75 octo form factor), I'd like a good one in that size range, and it would make sense for Kerbodyne to be the ones making it.