RoverDude

Screenshot of your GameData and USI folders please

No answer if this is happening on every ship

Upgrade FireSpitter.

You should be fine, unless you did something silly to the door colliders

ORS provides the resource maps but no parts. Karbonite leverages ORS and adds a lot of extensions to ORS, as well as all of the parts. I am almost done teasing out all of the bits of Karbonite that I can make generic into the USI libraries and my own ORS extension library. So your end game is that the toolchain goes ORS->ORSExtensions->Karbonite. So assuming you can make all of your own models, configs. etc. you would not need Karbonite. Just a bit of forewarning - ORS is a bit weird right now. We use Wave's 0.1.2 version in all of the USI products, This is incompatible with the new 0.1.3 version Fractal put out (as Fractal's version does not yet incorporate the community changes in 0.1.2). So one of two things will be happening. Either ORS under Fractal will be updated in a way that allows mods to play nice, and is independent of KSPI, or I will create a fork to base all of my extensions off of. A decision one way or the other will occur and roll out with 0.25 (testing different options in experimentals now so it is ready for day 1).

Heads up. First - CRP is not compatible with the latest KSPI. Also, Fractal jumped a version without integrating our changes, so really 0.1.3 is further behind than 0.1.2... which is confusing. I expect these will fall in sync soon (either that, or I'll say screw it and fork and be done with it).

Ironically... a clamp o tron jr docking port

Yep, crustal resources are our current bone of contention and I agree that it would be best if the work done on guard clauses, etc. was integrated if it has not already been done.

Kinda defeats the purpose of an Open Resource System if it's not really open Say for example someone wants to play with KSPI and MKS at the same time... they won't be able to unless we're in lockstep. Then if someone else wants to include a mod that added spice harvesting to Duna... well, it gets weird.

Yeah that would be bad because it would break lots of stuff You would create money faucets by launching and recovering life support parts due to how cost works.

So if anyone is taking charge on a community tech tree we can share let me know - would love to use it

That would pretty much defeat the entire purpose of CRP To put it a different way. I can count, 100%, on the cost of oxygen. Or water. I build tanks with costs based on this. If these suddenly change, it breaks things and this makes me sad. If you are not using CRP, you can do whatever you like. If you are using CRP, then the agreement to be allowed on the playground is that we don't change anything so we have a dose of sanity. But I am curious... what costs do you want to change and why? Figure there's always a deeper reason in there somewhere

One way to correct this in the case of ORS would be to have the unique key be a combination of ORS key and package, and not really care where the configs are. So I can continue to keep my ORS version in the USI folder, and my configs in the CRP folder without stomping on KSPI or vice versa.

I'd anticipate and expect that mod authors are going to break things randomly, duplicate keys, and not play nice Cover that case and anything else is gravy.

Sure, as long as it only loads one then that takes care of that particular issue. What about planetary resources though? The dup key issue is the current showstopper. Will that follow a similar pattern where only one planetary resource file is loaded? The only issue I see with having a specified folder is that it's confusing to users if they have two mods that have ORS definitions (thus making it a bit less open). Why not just handle it via dropping any duplicate keys that hit? So if a user installs both CRP and KSPI, they get the net of both packs, but in the event that both packs define water, only one gets loaded? (EDIT) ORS as a whole is going to have to be robust enough to handle multiple mods using it simultaneously and by folks who do not care to be in the same playground and who will absolutely duplicate and stomp over keys. Thus duplicate checking and multiple mod support from a config standpoint is pretty critical.

All things are possible... but why not just use a clamp o tron junior? It's already the right size

Odd.. yet your drills work... So I think this is a CRP issue. Reinstall CRP from the link in my sig, also make sure you have ORS 0.1.2 in your USI folder - let me know how that works. Better to refine it in situ since you can just buy it in the VAB or mine it on Kerbin. Your English is better than some Americans I deal with Every resource other than Karborundum can be harvested on the launchpad in limited quantities, or tweaked So no need for changes. Karborundum can be bought in small lab sample containers.

MKS has that built in with orbital logistics.

KospY - if you ever need models, ping me I'd happily donate some

The weird bit is we have two forks - an ORS 0.2.1 that is actually further ahead (things like duplicate key detction, better SCANSat integration, etc.) than the 0.1.3 branch. And yep, couple that with some flat-out incompatibilities in resource structure (MKS and KSPI-L use CRP, Fractal's KSPI uses it's own thing), we're in an odd spot until I see how things shake out. And for the record, I really can't do another breakage of MKS - the pain was enough the last time.

You can power it with enough gigantors In the interim, NFT has good stuff and the models are gorgeous

MKS (or any mod that uses CRP, which includes a few outside of my constellation) are not compatible with KSPI at this time, other than the current version of KSPI-L (which uses CRP, just like MKS does).

Two questionsns Any decisions RE ORS, the various pull requests done in your absence in Wave's branch (specifically the handling of duplicate ORS keys), and sharing resources? For now I've been having to turn users away at the door as we are incompatible due to duplicate ORS keys. Were you going to use the seismograph model I had made for KSPI-L to avoid the conflict with the accellerometer experiment? If so, awesome. If not, no worries, I would just then release it under a separate pack. But in either case I'd hate to see the model go to waste.

Lemme play with their intensity vs. range, they should be more ambient

Hopping in Ping me if you want to collaborate on an official, fully integrated MKS/Karbonite/EL pack with new models and other goodness. I have ideas