phoenix_ca

I can agree with Buckshoot on that sentiment. I've been avoiding doing any major builds (like a manned mission to Jool) for a while now, because I don't want to do it without this awesome that is full of awesome made of cake. Or something.

Thanks for pointing that out then. Please consider updating the wiki so it isn't misleading. @Jim: What about the placement of the parts? As I understand it, the cryostat that supplies the IR telescope must be connected directly to it (node-on-node). Manual balancing or something like TAC field balanced are required if you want to use multiple tanks. Edit: Sorry you said "while not looking at it". Haven't got a clue then. Something must be up if it's not working but fractal says it should. >.<

Well I whipped-up a cfg to do it just now as a "why not" sort of thing. Should be (roughly) balanced properly with MKS. @PART[bahaEPLsmAuger] { @MODULE[KethaneExtractor] { %Resource[Ore] { %Rate = 0.125 } Resource { Name = Minerals Rate = 0.125 } Resource { Name = Substrate Rate = 0.125 } Resource { Name = Water Rate = 0.125 } } } @PART[bahaEPLXLAuger] { @MODULE[KethaneExtractor] { %Resource[Ore] { %Rate = 1.333 } Resource { Name = Minerals Rate = 1.333 } Resource { Name = Substrate Rate = 1.333 } Resource { Name = Water Rate = 1.333 } } } More-or-less. I haven't tested that but it looks about right. Probably best to keep it optional though. Tweaking the ore rates down to be in-line with your mod would seriously reduce their effectiveness for people who also use EXPL.

It might be little, but it's one that goes under "little, but very, very, very annoying." I've gotta go with Banana on this. We should have a way to tweak the hotkey, or at least turn it off. Just like Banana, I don't see the point in having a hardcoded hotkey when there's toolbar integration.

Can you add support for BahamutoD's drills? They're originally intended for ExPL, but they're also based on Kethane. I'm assuming you could just add them to your KethanePartsMod.cfg so they extract minerals and substrate (maybe water too?), in addition to their ore extraction, without that actually creating a dependency (namely if you use the % operator but I don't have a clue how ModuleManager handles it if the part doesn't exist; I assume gracefully with a silent exception unless it's debugging). They're pretty big and power-sucking, so perhaps should work at a faster rate than the default Kethane drills.

I just want to point-out that my comments about MKS were based on the prior 0.13 models, which barely had any variation at all. 0.14 ripped-out a lot of almost duplicate parts (same model, different paint job, making lots of clutter and on top of that being very confusing). In that situation, this mod would be a godsend. But if you think it'd still be useful, more power to you. Maybe you can find a way to further reduce its part count.

As I understand it, you don't need a science lab for the deep field survey, only the direct planetary observation mission. I haven't really used them though. The fact that the wiki says they pretty much don't work when not the ship in focus, and lose all efficiency when you change to a different ship (meaning the computer core requirement doesn't matter because you'll need Kerbals there anyway to fix it), makes me think it's not worth the effort. Sounds like the only way they'd be worth-while is by sticking an ungodly number of them on a single ship with piles of He4 so that you don't need to run the game at high time acceleration for a stupid amount of time. Which is what I'd call kinda broken, since the science labs handle science gen much more gracefully. It's the Kethane scanning problem in a different form. Anything that must be in-focus for a long period of time acceleration, to the exclusion of all else, isn't really all that helpful if you want to manage more than one mission at a time.

Such excitement and anticipation!

There's something to be said for overdesigning craft. Even if it's just for the sake of saying "LOLS, lewk at all my panels!" Though more often because it can save you from a tight spot when everything goes wrong.

O.o Superstitious people are strange. Anyway, hope that curious bug is ironed-out easily.

Count me in too. Would be glad to help test.

That's not something that can be fixed with a cfg tweaking, is it... Well that explains it. I was trying to stack them without part clipping. Silly me.

I dunno. Try it with omghull's fixes. Maybe the odd behaviour when physics starts is on my end for some reason. I doubt it, as I took those in a vanilla test copy of KSP, but it's possible. Loppnessmosnta: That'd explain it. I got confused by the circular nobby bit at one end of the model. It looks to me like that's where it should attach.

Instead of explaining, I'll do one better. Pictures! Not all the parts have problems like this. From what I can tell the telescopic pistons don't but the attachment nodes look wrong to me (keep in mind that I've not used robotics since...erm...at least v0.19 or v0.20 of KSP, can't recall): Here's what the adjustable rail looks like in the VAB: And here's what it looks like after physics starts. You can see the rail moved (why doesn't this thing have attachement nodes anyway?): Other parts that do this (or something like it) include the closed and open powered hinges, the motor intended for VTOL engines and both washers. All of this is happening with omghull's version.

This is a lovely mod. But why the freaking hell does the F key open the window in flight? This makes EVAs a real nuisance when they shouldn't be. What's worse is that there's no way to change this behaviour either. I'm sorry but that's just a stupid keybind. (This behaviour appears random but is no less dumb for it.)

Yes, I imagine they'll fix their somewhat absurd load-all-the-things method with something more adaptive, eventually. At least I hope they do. I can understand why though. It's easier to get an idea of what the worst-case scenario for memory use is if you do that, and what's more, optimizing software before it's finished, in an alpha no less, is the wrong way to go about things. Well usually. It's not so bad if you know you aren't going to change whatever you're optimizing ever again but who can say that? If it's not done, you'll inevitably just go back and change the code you optimized so that it needs to be optimized again for the changes. Big time waster right there. Even with a simply Python script, doing that could waste many hours. Expand that to a game like KSP and...yeah. Lots of time potentially wasted. Performance boosts from multiple cores are usually quite small for games. You can thread it all you want, but as almost everything needs to be done in realtime, you'll still only be as fast as your slowest thread. Everything else could be finished to render a frame but hanging for a bit waiting for, I dunno, some physics calculation to process. Most processors today run so blisteringly fast too that really all you need for a game is two cores, one if it will launch with just one available. If you want performance gains for single applications, you need to get into overclocking and custom cooling to give yourself more room to overclock with stability. Multi-cores are for multi-tasking, not for gaming. When building a gaming PC, you're better off getting the fastest clock speeds you can get on the most recent architecture, with a modest number of cores so that the game and system/background processes don't step on each other's feet, as it were. The big benefit we'll likely see if Squad upadtes KSP to 64-bit the memory addressing issue being...addressed. Loading-up a pile of mods without out-of-memory errors would be nice. (I regularly get these. Running KSP I'm on the brink of CTD pretty much all the time at an average 3.1GB memory use. Quicksaves are my friend. Lots, and lots, and lots of quicksaves.) And it does have practical application for the devs and the stock game too. I don't know how affected Squad has been by the 32-bit editor but plenty of devs designing large projects have reported the Unity 4 editor as being intolerably unresponsive. The new editor should fix that, and any less headache for Squad when using Unity is always good news for KSP. That, and planets and other systems, all that, could be hugely expanded without that 3.4GB ceiling. Just think about Krag's Planet Factory. That thing only added what I'd call a rather modest number of new celestial bodies, but it eats RAM like mad.

Apparently I myself am one of those less savvy people. Editing the configs to fix the rotation and translation axis is easy. Fixing the odd translation of the moving parts that happens as soon as physics starts...yeah I'm lost.

Those less savvy should wait until an official release. I'm going to try to fiddle with this in my test install.

I'm pretty lucky in that regard. I just fired-up a new game for 23.5 so I've got none of those issues. (Typically I just play on the same version for a while and then start a new game anyway just to avoid these issues.)

But...if it works...

I think I ran into a strange bug with this part. My rocket was starting higher and higher from the pad for each subsequent launch (I'd launch, see I was a kilometer above the pad, revert, launch again, now 2k above the bad, and so on). When I went back to the VAB and removed the part, I launched at normal height again. Replacing the part after that didn't cause any problems.

Pretty much. You can simulate different payloads pretty accurately by shifting the part's position in the payload section with girders.

Doesn't make the absence of it any less sad. I'll just sit and hope. Unless a donate button materializes. In which case I'd pitch in some money. It's worth it. This mod is practically like it's own expansion pack for KSP, right up there with the level of game-changing awesome as Interstellar, B9, or FAR. Hell, I even subscribed to this thread. And I never do that, on any forum. Though I guess I can't say that anymore.

Yeah so I derped and accidentally glossed-over that link. Swamp needs to be given a cookie. Or a whole bakery full of cookies. You can have some cookies too.

My very first use of this mod was to save what would've been a complete disaster in stock KSP. I forgot to put solar panels (or any source of power) on my ascent stage for a manned mission to Minmus. Things would've been very, very dicey had I not been able to just swipe a solar panel and stick it on the ascent stage. So, thanks. For saving my ass. Jeb is also quite thankful I'm sure.