Z3R0Gravitas

Ah, handy. I didn't know those config files existed. Pretty useful to reference. :-) I've done some quick testing and found: In flight at any altitude (in atmosphere, sub-orbital, whatever) counts for dispensing with the 0.1x Kerbin surface multiplier. In the water (splashed down) counts as landed (with same 0.1x multiplier). Kerbin still gets the +10% bonus data conversion factor for being on a surface. (Check by returning with high value experiments from Ike.) Confirmed +25% bonus for being in same SOI as experiment's origin (regardless of surface or orbital location). Yes, so, for processing on a (non Kerbin) surface, bonus multiplier = 1.1*1.25 = 1.375. (For experiments taken on or around that body.) One minor thing I don't understand is why the game sometimes rounds fractional amounts of data (e.g. [something].5) up or down, seems inconsistent. Not overly important though. Haven't checked up on asteroids at all, as yet... Thanks for the replies, people. I also made a post in general discussion asking for people to check my major changes to the MPL wiki page, so if anyone here is able to give any feedback on the rest of that, there, that'd be great too.

Hi there. I feel like a little bit of a community outsider, as I was new to the game at the end of last year, but over the last month I've been trying to update some of the Wiki's most lacking pages, hear and there. After seeing an edit to the Mobile Processing Lab page (by @EsterbanLB), I realised how wrong/outdated much of the info there was, so set about rewriting or adding it. I'd appreciate any suggestions of major things I've overlooked, or mistaken. One part I made from scratch is the engineer level research rates table (as shown below). I just made careful observations, so I'm a little wary that it might not be perfectly accurate to 3 significant figures, and I certainly don't have a nice neat equation to explain the numbers, either: I've made major edits to a bunch of other pages, including the experiment storage unit, all the radiators, and have also been trying to resolve all the thermal behaviours of the drills and convertors (wondering about heat management at different engineer levels, etc, as I asked about here). But I thought the MPL was a fair place to start trying to solicit some sanity checks, for a start. I hope I've not bulked out the test tooo much, but this part has a particularly large number of features and nuances.

Are you sure of this exact multiplier, across the board for all experiments processed to data on Kerbin? (Regardless of where they originated from, etc.) I rewrote and augmented the MPL wiki page the other day, so will add this figure in too (especially if you can reference the figure, or demonstrate it well). Do you know of any other similar processing multipliers that should go in this section: http://wiki.kerbalspaceprogram.com/wiki/Mobile_Processing_Lab_MPL-LG-2#Data_Value

I updated and added a bunch of information and data tables to Wiki's pages on radiators, the other day. perhaps this is helpful?: http://wiki.kerbalspaceprogram.com/wiki/Radiator#Function I don't know anything about any mods, but could it be possible that your reactors are using up most of the radiator's core "Core Heat xFer" capacity (see wiki page above)? I think a single large (fixed) panel radiator should be enough, on it's own, to cool a single Convert-o-tron 250, when running only one fuel conversion. Try having that type of local cooling radiator attached to a tank that the 250 is attached to, while making sure all other core heat sources (only drills, in KSP vanilla, I think?) are greater than 2 part connections distant. I've not managed to update the actual Converter pages fully yet, but their production rates (and EC use) scale up with the highest level of engineer aboard your craft, as with drills: http://wiki.kerbalspaceprogram.com/wiki/Resource_harvester#Ore_extraction_rate However, I think I've not yet managed to pin down entirely, for sure, if (or how, exactly) heat production and it's management scales with engineer level. My detailed question (to @RoverDude) has not yet been answered in any detail: Of course I'd appreciate any knowledgeable input on my questions from other members here. :-)

Hi, sorry to ask even more awkward questions again, but I've not been able to search up any definitive answers, or yet figure out for myself (even from the copious thermal debug info) what exactly is happening under all circumstances, here. This Reddit thread did a great job of fathoming the equations and figures for drill's surface harvesting mode (with different level engineers on board). I've confirmed them myself, experimentally, and re-arranged the relevant wiki page a little. I've also expanded the information on the wiki about radiators, regarding their core cooling stats, adding a table of the core cooling requirements of the 4 ore processing parts. I've observed (experimentally, in game) the differences in the time it takes to warm up a drill core, quicker with higher level engineer, when surface harvesting. E.g., using the setup shown below, for a good little demo, with table showing results: Engineer Level Drill Junior Warm up time (s) None 156 0 70 1 41 2 30 3 24 4 20 5 17 I was originally thinking that the drill cores produce additional heating, in line with their additional charge usage, and so there must be additional cooling bonus provided too, since the number of radiators required stays the same, but I couldn't make anything out in the debug stats to support this. (1) Does heat produced by drills in surface harvest mode vary by engineer level? (Or is there only some kind of warm up bonus added...?) Further, with the asteroid harvesting mode: I found that the ore production rate scales up with the engineer level, as expected, but the electric charge used remains a flat rate (0.3EC/s for Drill Junior). (2) This flat EC useage is a deliberate decision on mechanics, yes? Further, with engineers of level 3 or below, it wasn't possible to cool the drills to optimal level with any amount of radiators. So I'm thinking that the drill's "max cooling" stat is being modified by engineer level (although, again, I can't see any read-out that confirms this directly). Or, the drill's heat produced is being scaled *up* for lower level engineers (I think I observed the drills warming up quicker for lower level engineers, which would support this)... (3) What's happening with drill's thermal stats during asteroid harvesting (by engineer level)? (4) Some other nuances I've observed that it would be nice to clarify (if all desired behaviour): Drills will not detect insertion into asteroids, if already extended, when moving the whole craft into position and grabbing asteroid. (And can not drill asteroids not part of the same craft?) Drills report "100% load", only with level 5 engineer (otherwise "operational"). Does this indicate load scaling from engineer bonus? Minor bug: drill status continues to show "no storage space" after the ore tank(s) have been re-enabled for fuel transfer (and ore is in fact flowing in). And continues showing "100% load" after EVA-ing level 5 engineer. Until stopped and started again. My expectation, from last time, is that @RoverDude would be the best member/dev to talk to here, given these mechanics stem from his work. So I'd be much gratified of any input again (thanks). P.S. I also plotted a graph of drill's thermal efficiency verses core temperature... ... But there's no way to embed this in the wiki (with "migration issues", still). (5) Any chance this wiki situation will change, or any way around embedding images (editing templates, etc)?

I was just trying to do this too, getting confused and then frustrated. Seems like there is no fully functional work around currently, since I couldn't transfer crew reports manually (from a Mk1 lander can) to a storage unit. (And the units ignore cross-feed restrictions, that might have been a handy fix, connecting units via couplers.) In my opinion, "collect all" should not take experiments from other storage units at all. This function very quickly creates a jumbled mess that can take a lot of time to figure out. Also, there is a dedicated function for transferring between them anyway, so I'd call that the 'bug', rather than just changing the priority of checking.

Hey, thanks for the reply. Sorry my little question's got a bit out of hand, heh. So are the Convert-O-Trons based on a (old) mod then? (That had separate converter units?)

Well, from a logical point of view, having parallel production hardware for each type of output makes sense (arguably). But space grade tech that has two entirely redundant pipelines for oxidiser and fuel seems kind of excessive. The ISRUs (that aren't called ISRUs anymore, except when they are) are confusing in general, though, and I wasn't sure if this was somewhat deliberate, to give expert players something complex to figure out (and a big boost resulting from that). I mean, in the VAB/SPH, the Convert-O-Tron info-tips talk about engineers increasing their "efficiency", but their input-to-output ratio is locked (at 100% for the 250 and 10% for the 125), while it's their rate that is modified. Then, of course, there's no mention of how big those engineer rate bonuses are (or just how much worst the 125 is compared to the 250). And the statistic numbers (e.g. "-Ore: 0.55/s", "ElectricCharge: 30.00/s) relate only to a "100% load" status (of an individual converter mode), not to the base rate, or any of the engineer bonus related rates. Those are all (far) lower than that (at 100% 'thermal efficiency'), except with a 5 star engineer, when the convertors can operate at 125%. Long ramble short - might the Convert-O-Tron component tool tips be clarified or simplified at all? (Or are they a deliberately abstruse aspect of the game?)

....Wah. That's a pretty massive bug to have gone unnoticed for so long by anyone on the team... Never accidentally having started a different mode without stopping another first? 4 ISRUs for the price, size and (most importantly) mass or one. Makes a rather big difference as to the component composition of all of one's (mining) basses, from mid-game onwards, surely? Or, I guess most players just hit fast forward and don't think twice...? Anyway, I have (created an account and) added it to the bug tracker, normal priority. That likely to be seen (and possibly be dealt with)?

I'm talking about when using a single convert-o-tron unit. It can have multiple modes running at once, without them impacting each other's production rates. Is this expected? See Gif:

Sorry, what is? I don't track... That the convert-o-trons produce in parallel is down to the presence of an engineer? Should they not produce in parallel? I'm running stock and seems like it's not only me. If you put a unit on the launch pad, with a 1 star engineer (with a full ore tank and space for fuel to go) do you not see different consumption rates (when switching additional modes on), too? (Thanks for reply.)

Ah, well found, the last couple of comments there (1, 2), from 18 months back. So whether or not it changed in between, it used to do this too. Ok. On the subject of Convert-o-trons, when trying to figure out their production rate (relative to drills), I found that basically all the specific info on their Wiki pages are totally wrong (the 250). E.g. they *do* now receive an engineer bonus (like the drills). I removed the counter-claim from that page (to see if it would spur an experienced contributor into action), but the numbers and mechanics involved are still too fresh and complex for me to be sure of updating it all myself, as yet. Think any experienced players might be motivated to update it? It must be misleading/confusing a lot of new players. It doesn't seem like the only outdated info there, I guess the original contributors have mostly moved away from it...?

New to the game, starting at 1.2.2, I found it surprising that they worked like this (when I tested the 250 on the launch pad). Lf+Ox mode supplemented the output rate (and ore consumption) from the individual Ox and Liquid fuel modes. (The referenced control window, for clarity.) A friend who's been playing KSP for longer said this definitely didn't used to be the case, and thought it a bug. So is this deliberate, accidental or other...? Thanks.