• Content count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Z3R0Gravitas

  • Rank
    Bottle Rocketeer
  1. 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)?
  2. 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.
  3. 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?)
  4. 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?)
  5. ....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)?
  6. 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:
  7. 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.)
  8. 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...?
  9. 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.