RoverDude

Dude. No need to get snarky. Notice the giant glowing radiator things all over the ring? This is similar to an argument that engines should have separate parts for the nozzle, turbopump, hypergol manifold, heat exchanger, etc. - while I expect such a mod would be interesting, at the end of the day, it's all worked into the mass/cost/model of the part. Same here. The entire intent... like, every single design decision in making this, is that it has to be usable as a stand-alone mod with as few dependencies as possible (i.e. no dependency on CRP, MKS, NFT, etc. - it's only dependency is Regolith) - so the power number is low to account for stock levels and stock access. Radiators are built in because as noted, there are no stock radiators. Naturally, if stock ever decides to get nuclear reactors and radiators, that will change. But for now (and the foreseeable future), a significant amount of abstraction has to be worked into the mass and cost of the part.

Info may be a bit out of date it's rock solid even at extreme speeds, and has a proximity bit that will drop you out of warp if you get too close to an SOI (like, I dunno, warping into the sun )

I can answer #5. Use an MKS science lab to convert Uraninite into EnrichedUranium for use in MKS/NFT reactors.

The reactors and such are assumed to be part of the drive, and it's still a capstone part. It would not make sense to have it that early in the tree given there are less powerful drives beyond experimental rocketry. Also I expect those other nodes will be filled with parts sooner or later

I'd challenge you on that, and have in fact used both. Useability aside, the physics are pretty darn sound. Also, support for conservation of velocity as well as conservation of angular momentum are supported (via a switch in the VAB). Tho I expect Helaeon (one of the collaborators who coded the alternate conservation mode) probably sorts it out all best in this post. http://forum.kerbalspaceprogram.com/threads/100798-0-90-Alcubierre-Warp-Drive-%28Stand-alone%29-v0-1-0-2014-12-16/page47 Now. I totally get that you don't like me. Rock on. But if you are going to call out a mod that, by your own admission you have not even used (and by your own admission have not even used the one in KSPI), you should (by now) be prepared for a rebuttal. If you would like to discuss the physics behind my Alcubierre drive, feel free to post in the thread linked above, since we may as well not clutter this one as this is the KSPI thread, not the USI Alcubierre drive thread.

+1 for community stuff

We already have that today This drive is appropriately scaled for NFT/USI mods out of the box. It was released as a completely stand alone and independent alternative to the Alcubierre drive in KSPI. It's at the extreme right of the CTT tech tree.

Not practical from a code standpoint without some significant work.

I'm ok with a standard of 1ML as a third option specifically for very very tiny resources.

If the reference is to the kontainers, those ones are meant to have different colors per resource

Nothing personal, but I did not make this mod just to toss it over to KSPI. So while the license technically allows reuse, etc. I would prefer that you do not roll in one of my active mods. This was built specifically as an alternative to the KSPI drive, and I intend to keep it as such. So yes, the license allows a derivative work (though I expect the CC license may conflict with KSPI's), so it's not an issue of allowing things. But if you're asking for a blessing, the answer would be a respectful no, for the reasons noted above. Also, as I have stated repeatedly, if you want to do a KSPI config, that's fine - assuming all the user has is KSPI and is NOT using the NFT or USI constellations (these are both easy MM checks). But I would not want it interfering with NFT, etc. which use alternate power scales. Otherwise we're going to end up doing a battle royale of competing configs, and that's no fun for anyone. Granted, all of that may change if we land in a place where there's more of a standard for large-scale power, etc. but we're just not there yet. - - - Updated - - - @CaribouGone - I'd have to fiddle and see what's causing that config edit not to work for you. The bubble collapse artifact is just something in the initial animation I need to sort. @Helaeon - excellent points as always. Side note, doing some testing and such - I will send you a PM

If you need any help let me know. One thing that may help you is that you can override the bit that actually generates the ins and outs. It's how we use the same core code for drills, converters, and asteroid harvesters (just inherit from the BaseConverter class).

Regolith It includes a generator as well as harvesters - they all work off of the same base classes.

Nice work!

I agree we should have Methane and LqdMethane for consistency. Toss up some numbers so Nertea can tweak 'em

I believe it was TAC-LS causing new contracts to appear btw

No worries Just if in doubt try to get an answer from the MKS/OKS folks first. It's a pretty brisk thread (Edit) And in your case, turns out that one was weird in that it was an EL consideration (fuel flow) coupled with MKS having no_flow stuff. So that was more of a general statement not for you specifically.

And side not guys - do me a favor and any questions regarding an EL install with MKS/OKS alongside of it, ask in the MKS thread *first* so we don't pollute Taniwha's thread. It helps him with a cleaner thread, helps me spot any trends and provide you better support, and helps you because the MKS thread is going to have folks who are, poster for poster, better equipped to solve your support issue.

Your implication came off as quite different RE 'Rebalancing' note that there will be zero support for SETI in the MKS thread, you will need to handle it here.

That's only a little bit incorrect. MKS is required for MCM to function. And assuming you delete all of the MKS parts, etc, it's actually heavier than 0.22.9 given that MKS uses some pretty extreme texture compression techniques (0.22.9 shaves another 5MB of texture memory). To put this in perspective, you will have more RAM used up by MKS/OKS models and config files than you will textures. So... let's talk brass tacks. Space on disk aside (because that's a pretty lousy indication of space in RAM), I ran some tests. The test was to load the game, hit the space center, and measure RAM usage while in that scene over time and averaged it out, mostly because with KSP just being KSP, and doing things like garbage collection and object creation, you can easily have a 20mb swing in usage over time. With neither MKS/OKS or MCM installed, RAM usage was 1717.2 With MKS/OKS out of the box, RAM usage was 1849.7 MB I then deleted ALL MKS/OKS parts and textures (I am not sure which ones MCM reuses, so erred on the side of deleting too much). I then installed MCM, and RAM usage was 1850.2 So with either one of them, you're looking at a bump of 133MB of so. Note that this number on no way correlates to what each of our respective ZIPS are, nor their uncompressed size So yeah. RAM usage as a reason for MCM vs. MKS/OKS is pretty much invalid. Now - part catalog count is a valid reason (I do not nor will I support module functionality switching as the roadmap includes each bit getting a unique model), but RAM usage certainly is not And even with unique models, due to the texture reuse (and even more reuse the more bits of the USI mods you use), we'll still be landing in the same place (models are pretty cheap). So at that point, your tradeoff is part catalog count and aesthetic (assuming you prefer MCM looks to MKS/OKS looks). The downside is you're losing any kind of support for MKS as I do not provide support for MCM, or for any modified configs (again, I am cool with folks playing with the legos, just don't expect me to support you if you glue a tinker toy to it). Just wanted to clear that up and nip misinformation in the bud.

@Northstar - that doc is out of date. Use Nertea's from earlier in the thread. @Raptor831 I am fine with either, I'll follow whatever anyone else agrees to on that front.

Just bear in mind that MKS is more of a workflow change vs. a model change (and if you use them, pester me for your first level support). The IXS warp ship mod has some lovely models as well for docks

Side note. If at any point we are able to override ISRU flow modes, I have no problem moving fuels to STACK_PRIORITY_SEARCH and handling exceptions on the ISRU side. That will prevent RO from having to do anything funky, as my preference would be to have this encompass RF/RO/KSPI/NFT/USI Also Nertea - will ping you on IRC. I have an idea on power scaling.

But why? We're going through great pains as it is to sort this out - to include myself and Nertea having to essentially redo all of our tanks. I am confused why we can't do the same for antimatter to get it in line with our agreed to conventions for storage size? I think we all kinda threw continuality out the window when we decided to come together and sync things up Which is precisely why this version can't go live till 1.0 - so we all have time to sort out our respective configs, and since we're going to be dealing (all of us, or rather, it should be all of us and not just me and Nertea) with game breaking changes.

Define the side effects - Odds are Regolith took them out already - - - Updated - - - Side note - what I honestly would prefer to avoid is two versions of an active mod running around, because that's going to cause a lot of confusion (and headaches for me). Let's be clear - the license allows that. I make stuff open so people can play with the tinker toys. But part of the reason this mod exists is specifically for people who want an alternative warp drive. So if the intent (which I think is a good one) is to increase interop, then we're going to need to sort it where this works in KSPI-Land without essentially breaking my mod or transforming it from a USI-friendly thing into a KSPI-thing or breaking t's design intent. I'm all for collaboration on that of course, and I expect we can come to a place that makes everyone happy. The biggest thing to sort there is the power differential between KSPI and NFT. If we can unify on power, then at that point it becomes a design discussion where we're at least in the same ballpark. But requiring antimatter reactors is kinda a no-go, because USI and NFT do not have antimatter reactors If the intent for antimatter reactors is to push it up the tech tree, CTT already solves that, and I expect we can find some reactors that are on the high end in NFT (and I could add a USI analogue) that fit the bill. if the intent is to make charging difficult, we have some other (non-antimatter) levers we can pull that make sure things are consistent. Of course in the short term, a MM that turns off when it sees NFT/USI works until we can sort out how to get us all on the same power model. At that point, I'd be happy to collaborate and adjust the design in a way that helps it work stand alone, with KSPI, or with NFT/USI (which again is the entire intent of this specific mod).