DStaal

I mentioned it because I know his new gas turbine design resulted in him writing a new module to get it to work. (Based on ModuleResourceConverter.)

Just as a note: If you're talking to Angel-125 on Wild Blue Industries stuff, note that he has several generators as well - including a new one he just announced but hasn't released. I haven't tested all of them with this, but if you're looking at his stuff you should probably make sure you get all of it.

Which is an argument for that part - or for LS. This is true, it's a possibility. Good point. My basic thoughts are, that for industry we have four phases: Drilling. The current three K&K drills, with switchable drillheads. (Probably distributed between the three of them, just because we do have the three models.) Refining - use the current ore converter as model. Mostly automated. Beginning manufacturing - use a two-part system, using the current EL parts. One part being extremely low efficiency, the other being a high efficiency booster to bring things to normal total efficiency. This stage should be semi-automated, whether that means the Kerbaled part is the efficiency part or the other way around is an open question. Late manufacturing - again, two-part system, current EL parts, this time the other way around. So it's mostly manual, with some automation. This is a slightly different split than USI's breakdown, so which productions are in which of those phases isn't fully worked out. The main concern on workability however is that spamming efficiency parts could raise production to huge levels - whether that's a problem in practice is an open question, as there are limiters. (Heat, for one.) Also, if for example MaterialKits are being produced in a workshop and boosted by a machine plant, spamming machine plants would make it feel fairly automated - they don't have Kerbals in them. And it's not like they are small on mass. Good point. And an argument for different tags. I *did* think about it. My thought is to rebalance that part in this stage including some efficiency converters. (Probably not the high boosts, but some additional pieces.) How many bays and how boost per mode much is still an open question.

Those configs in CRP define *where* the resource is found. The actual definition of the resources is in CommonResources.cfg - which has Rock.

There's a node helper tool for that... Drop the part someplace else, attach the node helper tool to the node you *don't* want to use, then pick the module back up and move it into place. Then you can remove the node helper. Alternately, you can use one of the static adapter parts instead of the built-in adapter, and attach the module to the adaptor part.

I'll admit I got lucky. And you'll notice the extended landing gear pointing upwards - that's a rollover recovery feature. (And the folded up wheels are uneven terrain recovery features.) Between the two, as long as Bon Voyage doesn't put me half-off a cliff I should be able to recover from most situations. (The rover's intent is to be a recover and redeploy for a grand tour of the OPM system. Reliability needs to be bullet-proof. The above is a test design that's being sent to find Kerbin's anomalies. There have been revisions to improve the design since.)

(Since I know your English isn't great - he was making a pun. The end of the project - that he's getting close. And the back end of the ship. Your comment added on top feels like an upskirt joke...)

Ahem. You can just make the rover out in the second pic - but it's on the platform. There was no manual driving. Just Bon Voyage with the help of ScanSat to pick the target.

Ok, question for thought/debate: Should the K&K parts work as efficiency parts for the USI line of parts, or should they be separate? The first has the advantages of interoperablity, while the second allows us more flexibility on design. This can be by part to an extent: Any part can get efficiency boosts from one set of efficiency parts, and efficiency parts can switch between being efficiency modes. One thing to note is that the idea of a two-part industrial setup (going back to the diagram I posted at the beginning of the thread) probably requires that we separate the efficiency lines, at least for that set of parts. So one option would be to have separate lines for industry and interoperate with the USI efficiency line for LS.

Not quite the same words, but the general style is the same, especially in the normal monthly reports. The fail report...

Older players? XCom 2 came out a year ago! (Ok, so that's the sequel to the remake - but the quote above fits the remake as well.)

1.27 isn't a very high TWR for a gravity turn. It's enough, but just barely. And you did tell it to go to an apo of 100k - that's not the default destination height. Also, you've played with the Hold AP Time values - sorry I didn't notice that in the previous screenshot. That alone can be causing your issues. (You're telling it to climb *steeper* as you climb higher.)

Also: The 'evt' filename tag doesn't appear to work correctly: It *always* says the screenshot was 'timed'.

I'd be interested in knowing what the TWR is after the first ~40s of flight, when you drop those four booster engines... Anyway, try setting the start m/s to 100 and seeing if that helps. (I'm thinking you actually have a very low TWR, once you get to just your main stage.)

It tries to zero in - but it's making guesses, so it has to get it wrong a few times along the way. Can you show a pic of the rocket on the launchpad? Preferably with KER or something showing TWR - my guess is that you've got either a lot of solid rockets and a high TWP (no throttle control, so it reaches the set apoapsis very early) or an extremely low TWR. (Not enough thrust to actually preform a gravity turn.)

Thanks, I'd seen that on the ModuleEfficiencyPart but had been looking at ModuleResourceConverter_USI for the pairing, and hadn't thought to check MKSModule. Hmm. Interesting ideas here - I wonder if you could make Kerbals able to collect Rock on their own, at a small pace? (Or just add the resource extractor to the Konstruction counterweights.) The idea being you don't 'mine' it exactly - you pick up whatever's loose and laying around.

What parts do you have that support it? (It doesn't do anything by itself, it just provides abilities that modders can enable in their parts.)

On an unrelated issue: @RoverDude, how do the efficiency parts pair with the other modules? I'm trying understand how to create my own, and know how to say which part grants bonuses to which converters. What I was hoping for is that I'd be able to declare 'this part is an efficiency part for X, Y, and Z other parts/converters', but it's looking more like there's classes of efficiency parts and converters, and each class of one pairs with the appropriate class of the other - but neither are actually defined in the config files as far as I can tell. So how does it know which class each is in, and what are the possible classes?

A possible bug report: my first test case was a set of comm-net sats I already have in orbit - just clean them up, as it were; they've been operating fine so far, but will eventually drift. But I get told I don't have the required resources, despite them still having quite a bit of xenon left. I note however that the mod claims it needs an *infinite* amount of EC to do the circulization. The sats have quite a bit of both storage and generation, but infinite is a bit much. The sats are entirely using parts from this mod, in case it matters:

The 4-1 isn't really designed to re-enter in the first place... It's designed as a station or interplanetary transport command center.

BTW: I created a new 'branch' on github to hold promo images. https://github.com/DanStaal/KPBStoMKS/tree/Promo-Images

Depends entirely on what the characteristics of the world it's designed to operate on is. Probably not the best design for an atmospheric world, but with no or low atmosphere I don't see why it couldn't be made with real engines. (Especially on lower-gravity worlds.) So far I'm liking @DDay2021 and @CSE's ideas. As an extension of the latter: with a bit of care, you could also make the base able to expand radially. If the outer edge of a module is an even multiple of the inner edge and the angle is such that the same multiple equals the same percentage of the next outer radius, (for instance: If one module is a sixth of a circle, and is three times as wide at the outer circumference as at the inner, if three modules side-by side were a sixth of the next circle. So you have six in the inner circle, 18 in the next, etc.) you could build both up and out.

If you search through your KSP.log, you should be able to find every MM patch that touches that part.

Konstruction from USI is worth a look - it's a bit less general-purpose than IR, but it has a couple of manipulator arms that can grab a part and move it someplace else. Note that it only can move it's own parts - you can't build an arm from joints or anything like that.

Here's the log: http://magehandbook.com/KSP/KSP.log What I'm seeing is that the parts are different parts, identical to the standard batteries except for name, that are visible in the editor. Doing a quick look at the MM config cache, I see that while they're not assigned to a category, they do have a TechRequired. Which leads me back to Filter Extensions being why I can see them: I never look in the 'standard' electrical category, I use FE's extended one, with sub-categories for batteries, generators, solar panels, etc. And it doesn't care what category the part's been assigned to, it just checks that the part's been unlocked and that it has the correct modules. I believe the normal move for depreciated parts should be the correct one here: Set TechRequired to 'none' or something, so that it can't be unlocked. Any existing ships will still have the part, but the part will stay locked. (Note that the part might stay in both places for those of us with games in progress.)