RoverDude

Oh... I have plans for automated repair drones. Basically, a rework of proxy logistics. But then... who repairs the drones?

I'm already switching Karbonite to IntakeAtm and deprecating ScoopedAir. The only issue with using IntakeAir for, say, Karbonite, is that we'll suddenly enable stock jets to fly on Jool Not saying that's a bad thing... but it is a thing

Concur on point 1. For point 2, Ippo is more than welcome to request his resource be added to CRP, otherwise I'll go with a CRP resource.

Thanks for the info! I'll let nli2work address any engine things as he is our chief executive of all things that go boom. I'll tweak the intakes

Adding this to the pre-release. Are these good for final or do they have tons of weird testy-stuff in them?

So discussion time First... you guys are getting on-rails converters for the particle collector and the drills in the next release. Atmo converters don't make a lot of sense since these don't operate on rails, and rely on speed and atmo pressure. Second. A common area of concern is the fact that we have infinite resources, with your only variance being efficiency. Efficiency was annoying without rails, and becomes irrelevant with rails (other than extreme cases). One could argue this could be a concern for manned bases (life support limitations), but as of now, I could just drop a probe core and a drill, add a REALLY big tank, and just let it ride on the rails till my Duna team gets there a year or two later, all with zero penalty for hitting more or less efficient hotspots. Other mods have solved this through resource scarcity and a lack of on-rails support. I would like to propose a different approach. Extractors will wear out over time. Basically, this is a function of how many running hours the equipment has been online and processing. It will result in a static decrease in reliability and output, eventually dragging down to zero (and a 'Broken!' status). This can be repaired through Kerbal EVA operations. So now you have an inconvenient choice. You can still run stuff on rails (until such time as it wears out and falls over), but you have to consider yield and cost (i.e. if your gear is only going to last 2-3 years, you may want to drop it on a hotspot with significantly better gains). Alternatively, you can land on a crappy spot and increase yield if you're willing to constantly EVA and keep the equipment operating at top efficiency. Lastly, efficiency comes at a cost and requires ReplacementParts. These are not cheap, and have to be hauled in (or manufactured if you have MKS). The net result should be gentle encouragement to consider efficiency, but still allow players to throw efficiency and cost to the wind and just go mine stuff. Thoughts?

I know it's pedantic, but it's one of those really important details to a lot of folks, and while sharing is good - I want to make sure we share in a way that ensures folks get credit for their hard work

We are not GNU/GPL, we're CC

See below Not that I have heard of - can always PM Wave, he's pretty responsive, and on the cusp of a new release

Minor update - changing the keys back to default because I don't want a window of SCANSat going dark on us I'm bundling the MKS/Karb ones as those I control. I'll wait till Wave is ready for the KSPI ones. I expect the big question is whether or not any other resources (like plutonium, metane, etc.) are being deprecated in KSPI-Exp

I like the rep penalty. And I would totally love to see an MKS version of this as an option now that I'm breaking the tight coupling to TAC-LS

Awesome, thanks!

Quick update. The Google doc has been changed to include the notes thus far. CRP will go out in two packs: One with ORS maps, one without. The maps Will include Uranium (now mapped to NFT's Enriched Uranium) as this is harvestable in KSPI. It will also include Alumina - this is a KSPI-only resource, but easier to have it all in one pack, and that way it's something else for other people to use down the road. To prevent ORS conflicts with any existing installs, I will be using CRP_* for the ORS keys. That way we're not tied to releases, and eventually KSPI can bundle the CRP stuff as a dependency, no different than FireSpitter or Module Manager. CRP will have it's own GitHub repo and a much slower release schedule (probably rarely once the first set of resources is done). The first version will be rolling out this weekend and bundled in all of my pre-releases. With the ORS naming noted above, there should be no conflicts or issues. I'll make sure by dropping this on the latest KSPI-Ex version. Any other thoughts, consolidations, or changes you folks are thinking of?

Any word on the Github integration we were bantering back and forth above? I'm prepping for a bunch of releases and would love to add this in.

I have some videos on my list, but would rather do them with 0.20

SCANSat makes the most sense tbh, as it's useful well beyond Karbonite. RE other planets - the only way is to create new setups and maps for new planets.

This is what I have thus far from reading the thread, just as a recap - let me know if I have any misses in this: ORS Maps: MKS Aquifer/Water deprecated. KSPI Water/LqdWater deprecated. Both replaced by Water/Water Other resources KSPI Argon deprecated in favor of NFT ArgonGas Karbonite ScoopedAir deprecated in favor of KSPI IntakeAir ORS MW label changed to EC Karbonite MW/KW label changed to EC KSPI TH4 deprecated KSPI DepletedFuel deprecated KSPI UF4 deprecated in favor of NFT EnrichedUranium KSPI UraniumNitride deprecated in favor of NFT EnrichedUranium

Excellent. So really, ORS just needs to change MW to Kw when referring to EC/Second.

To hop into the EC/KW/MW/MJ bit. There's a lot of confusion and questions on this - specifically in translation of EC to KW or EC to MW. Are there any specific thoughts on this? I think establishing something consistent would be nice, especailly as this is relevant for displays on converters, etc. and right now I have a disjoint with Karbonite's generators and the KSPI generators. My understanding is that 1EC = 1KW, but how does that relate to KSPI and NFT? Is there a preference in terminology? And if we go with 1EC = 1KW, and a MegaJoule = 1000 EC (or 1MW) then where does that land us?

Please don't overwrite my files

Yeah, I think that unless any of that is being explicitly uses by KSPI, we ditch it. And if it is being used by KSPI, now seems the best time to discuss getting everything in line since Wave has a breaking change incoming anyway, so this is probably one of those rare chances we have for a reset.

I think this would be downright lovely. (Edit) Nertea, for my own benefit, what kinds of merges and changes would you be thinking of? I have both KSPI and NRS in my Community Resource Pack doc if that helps for reference

Sure, will do it once I'm back at my dev box. My thought is to send this one along with the removal of the default atmo/oceanic resources. That buys time for it to go with your release. After that, I plan to start a new repo with ORS only, and redo the generators, extend to more part modules, etc. as a stand-alone project without the direct tie to KSP-I as it is now, but bundle in the CRP stuff as an optional pack.

Just two. KSPI currently defines Water (ORS Key) -> LqdWater. Everyone else uses Water as the resource. What would be nice (and consistent) is Water (ORS Key) == Water (Resource), then I can deprecate Aquifer (ORS Key) -> Water (Resource) and that's one more common point, and one less set of maps (as the Aquifer/Water combo is part of CRP).

For today? use Wave's. This is subject to change, we're talking now. My preference is for me to take over ORS, he takes over KSPI.