RoverDude

Did you right click on the hatch?

I would say this RE parts - if a part price feels off compared to stock, then by all means do a patch. if it's cheap in comparison to a mod (say, NFT) let me know before submitting a patch (I may or may not want to be in sync with a mod). And as noted, for the MKS bits please factor in equipment costs as those are pricey.

Then I would suggest doing a separate thread, because I am really at a total loss as to what you want - ie. you obviously have *something* in mind and are asking people to make what you have in mind, but none of us are mind readers From my standpoint, the stock node's names and pathing are fine, so I (personally) have no reason to want a second structure. If you have your own vision for what you want (and given your evident frustration with tree node arrangement), then the best thing is to do your own tree, because you're the only person right now who has any idea (specifically) what you want. Granted, it won't be the one I use so it's going to, by it's very nature, require a ton of work on someone else's part - but there very well may be someone who wants to help you out with it. In either case, I'd say your request will get a better audience in the Tech Manager thread proper, and you might even find a volunteer to help you out.

You'll be fine - the UI will tick down but everything will catch up when you return focus. For MKS/OKS, one of my tests is to leave the ship unfocused for a few in-game years

Thanks Marce

@Wave - replaced with Uraninite maps (same thing, it's just one of the more common ores used to make refined uranium). @malkuth - good deal

Hey Malkuth - I had the same concern. There were two choices - ask Ippo to change his code, or change mine, so I chose the latter, just because it felt the most neighborly. btw - Kert is a really nice mod, I just owe Marce some generic part bags (maybe a toolbox model or something) he can bundle. I think if your mod is also doing repair type stuff, EVA makes the most sense (KERT helps with this). If you go that route and need a model let me know

@madlemur - I think everyone agrees that conceptually that's a great idea, but who's definition of sane? That's why it's out of scope for this project - this is just some sorely needed framework stuff.

@Cpt Kipard - sounds like you just volunteered to build the MM configs to support your technology tree idea. Should just be some MM files and a dependency on either CTT or another tree of your choice. I look forward to seeing your release thread. (Edit) and that was not meant to be snarky. Rather, it sounds like you are passionate about the idea, and feel it is not nearly as difficult as others have said. So I encourage you to rock on and start building this thing, and can't wait to see it come to fruition.

Should be perfectly fine - mining wise, I'm more inclined to add an asteroid ring to Dres.

@Kormer - decorative. @Cassonator - Not an issue with this mod as it doesn't use TweakScale. Suggest TweakScale thread.

Can you illuminate on the difference? @armytwin2 - I assume they would either use their own tree or stock. And I fully expect you will see new MM configs that move bits around, too. At the end of the day it's just plunking stuff in nodes.

FYI - I will be moving all of the USI mods to this tree, including Karbonite, etc.

multiple pods?

Having a default of stock is probably a good intelligent default.

Log a github issue Will also need to check it in relation to other Karbonite engines, as they are very smokey in general.

So a quick update. Still polishing off the new code - a lot of this is a completely new resource DLL. Basically asteroid mining, planetary mining, and a generator all rolled into one (where in the past we would have had the USI_Converter, DynamicTanks from ART, and ORSX). Basically a 'recipe' based system for resource conversion that's pretty generic. It will be released as a stand-alone library once complete. Oh... and here's a video of a mining laser (asteroids first, but will work for planetary as well).

Correct. Recharge them or you will be sad

ECLSS, assuming they moved on to using CarbonDioxide, will work with MKS out of the box.

falling through is likely a collider not being set to convex btw

Easy one - CRP uses ORSX configs now to avoid stomping on ORS atmospherics, etc., so right now your CRP version is out of date. But lots of easy choices and fixes: Switch KSPI-L to ORSX and use the new CRP ORSX resource maps and configs (I can't recall if you still use alumina, but we have the rest in there). Use ORS for configs, but leverage the CRP ORSX maps (saves people loading extra stuff). If they just use KSPI-L, they see ORS. If they use MKS and KSPI-L they see both ORSX and ORS. Use ORS for both configs and maps in KSPI-L, just use CRP for resources (downside is extra stuff is loaded, upshot is you can have different maps than CRP, though most are based or close to the KSPI ones). With 2 and 3 you lose the SCANSat and Resource Overlay integration. With 1 and 2 we have map sharing. 2 I think is a good option if you want to roll with ORS still. ORSX is mostly animations and continued harvesting when not in focus (no idea if Fractal ever rolled that into the root ORS), your downside is loss of mapping from third party addons. 1 gives you the maps, but pulls you off of ORS, which may or may not make sense for you. 3 helps if you want alternate maps. Full disclosure, ORSX will *eventually* be replaced by a clean room implementation with some new features, and include generator code. It will also be integrated with SCANSat/Resource overlay. (edit) The conflict would be if someone who used ORSX got a non-ORSX CRP or someone who used ORS got the newer ORSX-only CRP - the symptom would be no resources available. Not aware of anyone hitting this yet (if they merged the folders you'd just get double maps but it would work as there are no file name conflicts), but could get weird.

@ratchet freak - No argument. Nobody here is arguing how the license works So the solution is to restrict the license. And since we can't anticipate all things, ARR is really best. (Edit) Now carry that forward. Mod authors go ARR. Their wishes are preserved, and we have enforced how other modders can interact with the free stuff being provided. A modder gets bored, and moves on. Now you have a dead project that can only be re-done via a clean room implementation (see Planet Factory, Tree Loader, etc.) If this is what this community wants, rock on.

No worries Hopefully I can catch your show though it's in the afternoon for me. Just background - SpareParts (along with EnrichedUranium and some others) are that way because they come from other mods, and it made more sense to work with them vs. asking people to change stuff. Sharing is good.

How are we threatening users (well, let's cut to the chase, how am 'I' threatening users?) Sorry, last I checked we have folks offering a free service, so you really should not be surprised when that generosity is taken advantage of, that people are going to walk. If the community decides that we cannot police ourselves and maintain the same level of cooperation and general decency like what I saw when I first started modding, then modders are going to depart, or lock their licenses down. That's not a threat, that's simply a cold hard fact. If people are nice, they get nice things. If people are not so nice, they don't, and we do nice things for a different community. Now let's talk crayons. This is less a case of slapping someone's hand because they want to borrow our crayon, and more a case of us, as the provider of crayons, getting annoyed because little Veruca decided to break the crayon in half. I didn't think I had to tell people, when borrowing my crayons, that they should not melt them or break them in half (because now I have people complaining that I distribute broken crayons and that's not fair). So in the end it is easier to just not let people borrow the crayons. It's sad, but it's the truth. Was that a threat?

huh. And I was just about to make one of these too.