RoverDude

Awesome! btw - go see my post RE Community Resource Pack, as there are some complexities to ORS that may cause sadness if we are all not careful.

PLEASE SEE RELEASE THREAD HERE I make a lot of mods. I also use ORS in the mods I work on, including Karbonite. Since all of these mods are pretty open to extension (and since I know folks are already extending them!), we are starting to see a lot of mods use ORS. This rocks. ORS was one of those gems of our community that deserved more time in the spotlight than it received, and I'm happy to be helping to change that. But with popularity comes conflicts and random mod-stomping, so I figured it was time for some cat herding. I am doing this not as some creepy 'control' thing - rather, it's because ORS gets REALLY SAD... I mean, we're talking mind numbingly sad, if you give two resources the same key in the ORS definitions. An excellent example is Water. In the original version of KSPI, the resource name is LqdWater, but the ORS Key is Water. So when I made MKS, I could not have a resource named Water and a key of Water (like I do with the other resources) because Water already existed as an ORS resource key. The result was infinite sadness (and this is why in MKS, we call the ORS resours Aquifer). Fast forward to more recent events. If a modder decides they want to extend Karbonite but use Ore for EL or MKS and they use the MKS Ore maps and resource definitions, these will collide, and our users will be lagged into oblivion. This, unfortunately, is REALLY easy to mess up. Add to this, folks sharing cool stuff back and forth. Like, say, Oxygen. One mixup in a config and you're suddenly changing the mass of ships, and in extreme cases may in fact cause things to be unleashed and children eaten. And nobody wants that. Thus, I submit to you both a proposal and a humble request. If we cannot all agree on what the proper density of plutonium is on Jool, can we at least agree not to break eachother's stuff. To facilitate this, I submit to you the Community Resource Pack. This is simply a stand alone kit for Modders to use (or not use, it's your call, but read on first) to avoid sadness. Both for ourselves and our users. It has two parts, and two very simple goals. Goal 1: Eliminate lag and crashes caused by duplicate ORS keys. To make this happen, CRP will include a consolidated list of distinct ORS keys and maps, and annotation of which mod is the curator or system of record for that resource. Or, simply put, if KSPI defines 'Uranium', and you decide to also make maps and a resource called 'Uranium' you will cause untold sadness and extreme lag to anyone who uses KSPI and your mod. Same with Karbonite, Ore, Substrate, etc. So our first goal is to have CRP be a clearing house for these. Since all current maps are under permissive licenses, if you want to use uranium, just include the KSPI ones. Want Ore? Grab them from MKS. Want your own thing called 'FluffyUnicornDroppings'? Rock on and make your own. Reuse what you can, do no harm. Let's be clear. If all this project does is achieve this first goal, I'll be thrilled. It means less issues for our users, better ORS adoption, and a growing library of ORS maps to use for fun and profit. This is 100% good, and 100% beneficial to modders. Because the alternative, and I kid you not, is to lag their systems down to 1fps if people can't play nice. Goal 2: Avoid surprising our users by stomping over resources. Some resources are defined by having ORS. Others are ones that a lot of us use. As someone who tries to play nice, I make it a point to see if any resource I make conflicts with someone else (hence why MKS and EL have the same resource definitions for Metal and Ore). We're going to take this general niceness a step further, and distribute a config file with all of the aforementioned ORS resources, along with a bunch of other ones that modders have agreed to consolidate on. Including ones from Karbonite and MKS/OKS (of course), TAC-LS, Universal Storage, KSP-I (Experimentals), Near Future Technologies, and others. And a few others will tag along where we've decided not to break their stuff, even though they are not (yet) active participants in CRP (kinda like santa claus handing out gifts). Examples includ EL (for metal and ore), and Biomass (for.. well.. biomass). If this goal is achieved, even for the few dozen resources we already have listed, I'll be double thrilled, as will users, since being nice is a lot more beneficial than randomly stomping on things. So if you're sold, head on down to the bottom of this post for links and goodness. If you are not sold, read on. "I am sad! you're trying to control my stuff!" Not really. I just don't want to break your stuff, and I hope you don't want to break mine. All of this is totally optional, if you don't wish to participate, then peace out and rock on. "There's no way this will ever work, people can't agree!" I dunno, I have enough already agreeing that I am pretty darn happy. If this achieves the primary goal of not having ORS crash, then I think we've landed in an excellent place. Anything else is gravy and just being neighborly. "But I don't want you mixing space cows in my ultra-realistic electrolysis sim!" Then don't use space cows. But maybe someone wants to have a nuclear-powered space cow RTG or something. In which case, you probably don't want them breaking your electrolysis sim. "But... you can't mix space cows and Plutonium-239!" Sure you can. Maybe you don't want to in your mod, or in the mods you select for your own ave game, but people are going to do all kinds of crazy stuff. And I expect you'd prefer it if your Plutonium-239 to not suddenly triple in mass mid-flight because SuPaKerBaL9000 modified the AAA_SpaceCows mod you downloaded for your kid's save to triple the mass of Plutonium-239. "What about disparities in resource density and atmospheric pressure, or gas compression?!" Here's reality. Most of us just want to play a game. Hence, CRP has no opinion on units, compression, cost, densities, etc. - that's up to the mod creators. And if something is good enough to be adopted by a couple of mods, then it's good enough to join the club. In the end, this is curated. But the only considerations on the table are ensuring stuff plays well in our space lego game together, not in nitpicking physics or chemistry, and most certainly not in dictating how stuff should be measured. "But what if I want my own resources?!" Go for it. CRP does not dictate what resources your mod has or how you use them, just that you don't create ones that conflict with ones already there in CRP. "But this is more work for me! I am sad!" Actually less. Just include a dependency like you would FireSpitter or any other similar mod. Shop for resources. Done. But hey, if you'd rather have SuPaKerBal9000 wreck your mod, rock on. "I'm still sad! I won't use this!" Ok that's fine too - peace out "Ok I'm sold.. how do I use this thing in my mod?" Just include the bits you want. At a minimum, include the resources config. But layer on that any ORS configs you desire (assuming you are using ORS, which is a separate download). Dont't change folder names or sadness happens. And please don't modify any of the configs you download either, as that kinda defeats the entire purpose, and is downright mean Lastly, don't supersede CRP resources with your own definitions for any of the included resources - that's almost as bad as modifying them. The whole point of the club is that we all play nice. If you want in the club, awesome! But please don't join th club just to trash the clubhouse Links and other stuff: The CRP working document CRP Repo at GitHub

dooooo it!

On purpose - Squad totally broke dynamic crew capacity so I have to figure out something new. Side note for the thread - current title is a working name. Suggest some names, WaRi and I will pick a bunch, and we'll do a poll

Not yet.. though I would say that Karbonite is not exactly known for it's stability and subtlety. Using it for RCS would be kinda like duct-taping a stick of dynamite to a sit-and-spin.

Probably easier to have the EL folks add compatibility to Karbonite - although there are at last count three or four community efforts to provide exactly this Common to ORS Oh.. and for whoever asked... we already have Karbonite-fueled rocket engines. They are terrifying.

hmmm.. if your right click menu on the asteroid showed no analysis that's odd. The asteroid itself will just have rock though. Right click on the probe and see what's up, it should suck in rock and turn it into a distribution of the three types. I'll look into the mass thing.. that should in no way be happening. If anything you're going to lose mass. Volume wise I'll redo some numbers. May be tied into your same mass issue. Let me know about the other bits. Also let me know if there's anything in your debug log. Oh! And before I forget and this is probably it... This will not work on old asteroids, it would be brand new ones that spawn so please check that.

Whoops! That's what I get for changing a mod name and a sig and checking for compatibility at the same time

Google KAS Keyboard Shortcuts

Whoops - missed that one, will have a fix tonight. Still works tho

Absolutely... down the road Yes. You will get weirdness as the other bits are updated, configs change, etc. and it will at some point cause an absolute headache when something does break. That's a KSP artefact - same kind that gives us random puffs of clouds in front of our rockets

DEV RELEASE IS UP! Watch the video... see the notes above. And yes, there's a mass driver. I just need to find a better particle effect. This is pretty much showtime code barring any bugs, possibly some small model changes. Go forth and have fun

Sit tight guys... pretend these are full of bees right now as Squad changed some rules on modifying crew capacity Will get back to this little guy as soon as I can, need to get all creative and stuff.

Oh... it gets better. DEV PREVIEW INCOMING! So here we go! After a ton of work (and a LOT of patience from my modding partner WaRi), we are pretty much code complete with the core features. This has been an absolute blast to code! So here's the rundown on how things work. Some slight variation from the video, but not much. 1. The probe when attached determines the asteroid composition. This is critical, gotta do this. What it determines is the presence of three kinds of rock: Frozen, Basic, and Enriched. 2. The Jaw converts mass into rock (plain rock). 3. The Probe automatically converts a tiny amount of plain rock into one of the special kinds of rock (frozen, basic, and enriched) based on the asteroid's makeup. Makeup is tied to the asteroid. 4. The converters take the specialized rock and turn it into stuff (fully configurable) such as ore, minerals, water, karbonite, etc. based on type. Yes, someone could cheat by moving a bunch of rock, but the type makeups are so close, and the cost so heavy that it would not be very possible. Plus you're stuck converting all three types whether you like it or not (if you try to move simple rock). So in the end, pretty much not worth the trouble. 5. The Karbonite converter can also convert plain rock into rock dust. This is fuel for the mass driver. the last two bits I am working on are the tank to hold rock dust, and the mass driver engine itself. The mass driver engine will be a higher thrust lower ISP ion drive, but not nearly the thrust of a traditional rocket engine. Basically in the same neighborhood as the nuke. Worthless in atmospheres, only work in a vacuum, and run off of rock dust. I'll post whatever I have done tonight - no promises on the mass driver, and I am pestering WaRi for a bit of model work

This is the risk of dev builds - even put in the notes that all of the part names changed as they were going from WIP to final form

Awesome! Hearing folks enjoy the mod makes it all worth it

Every indication points to something being installed that conflicted with a DLL, not a DLL issue (otherwise it would not work no matter where you moved it). Which makes sense given how KSP works. This is not a Unity issue, it's flat out a KSP and DLL conflict issue - I just don't know what that issue is.

There's already a tiny VTS sized tank and a larger radial one Looking good I can go either way - either a wide scoop with three vents (but make it appear as a piece with the three vents) or a rounder scoop with the one vent. Add in some side piping or hoses for greebling, and since I see a supercharger bit, add an animated fan that spins, that would be extremely sweet! Awesome, I will deprecate TweakScale once those come in Unity paths have no relation to where the mu ends up. I develop with all of my stuff in exactly the same place you see there. I'm sorry, but you have something else weird going on and I'm at a loss. To confirm: you have used a 100% clean KSP install, with just Squad and NASAMission in GameData, and have extracted the entire contents of the Karbonite zip, correct? No other mods?

huh.... good question. Actually... yes... So thanks for the catch The dynamic rates are being kinda a pain anyway so I may just launch with static rates to get something out there.

Non-permissive license unfortunately (no derivatives), unless that changed recently. I'm thinking radially attached ones that dynamically expand as fuel is added

What would be nice would be super-lightweight inflatable fuel tanks. Damn... I think I just talked myself into a new mod...

To be honest, that makes no sense - a graphics driver should not care at all about the pathing. Are you hitting a 255 character path limitation? That's a windows thing. So I really can't see changing the pathing for Karbonite and all of my mods, as there are a lot of shared components (hence the USI folder), and it would absolutely break some of them because of how KSP loads DLLs. A bigger question would be whether or not there are other folks in the thread using OpenGL and 64 bit who are NOT having the issue. i.e. it could be something completely orthagonal, since by moving the files you changed the load order (trust me, this matters - there is a VERY good reason USI starts with a 'U' - I had to ditch Green Mesa Industries when I started modding due to DLL loading issues).

Yep, just a config tweak. btw - the weight is part of what balances Karbonite engines - it's just not effective to haul around, at least not without the heavy thrust of a Karbonite engine. I guess my counterpoint would be that I find the idea that folks would mine a raw material, then launch a ship to orbit to process it, not the most efficient thing in the world. It makes sense in Kethane because there's no real difference, and better to leave it in a malleable form (i.e. why have a surface rig and all of it's headaches? Just deal with it in orbit). On the flipside, ORS removes the pain of finding a good spot or establishing a permanent base, so it needed a counterbalance otherwise Karbonite is a bit too much of an 'i win' resource. Hope that makes sense?

What I would do is just implement a small, radially attached, expandable ARM-Claw that could be used for fuel transfer. No muss no fuss.

hmmm... lemme noodle it over. The main rub is going to be controlling the darn thing