RoverDude

Less about being a '...' about it, and more about the OP violating license terms. These are kinda there for a reason.

A counter suggestion. If the intent is to help people avoid the pitfalls, etc. that you have gone through, a good step would be to lend a hand in the various mod threads and help assist people with install issues, etc. - many users already do this, and it makes our job a LOT easier. Helping out there would have a much larger net benefit than a modpack.

FYI still watching this discussion with interest. Side note - any change would have to account for more than just the Kerbol system, i.e. it should work regardless of the orbiting body in question. If someone wants to take a serious crack at this and has the formulas and code down to the integration point, let me know and we can work it in.

You are also violating several licenses by calling this MIT. Case in point, all of my stuff is CC 4.0 SA-BY-NC. MIT allows commercial use. These licenses are incompatible. A mod list is one thing... 'here is a list of stuff I know works, and links to the different mods'. Redistribution is an entirely different kettle of fish. To be perfectly honest, this post has no place in addon releases because it violates several rules.

Possibly. Considering some expansions to the concept, though it may not be quite as packable I'm just curious how many people field assemble vs. pre-assemble the packrat as that will influence the direction, etc.

Watch this video and ask me again Note: I had to TRY to flip this. Also note the climb angle from a dead stop near the end.

Pull request away - makes my job easier

Correct. 99.99% of all broken reports are KAS being KAS

Going to have mods close this one

FYI I'm reading all of the stuff here - side note, it's mostly an easy way to simulate the effect from a coding standpoint. But if someone a lot more clever than me has a pull request to change the physics, I'm game

This is because MKS replaces a bunch of the parts from EPL as we have equivalents. That's by design.

hm, I'll have to look and see.

Yep basically it would be configured as an interplanetary resource and the numbers tweaked accordingly.

Yep there are plans for a foldable balloon

Go look at a reactor from FTT. Link on the USI catalog page.

Yep basically it's a bunch of new tinker toys for modders.

It's tied to the harvesting part module, so it would be per part (and hence, per mod). Karbonite will not have it by default, but it could be changed with MM configs.

Theorycraft Incoming! So there are a few new bits being tossed into the next version. First, is depletion. Harvesters now have a depletion rate. This will result in a spot's abundance slowly reducing over time. This is expressed as a percentage loss, so every tick abundance drops by x% (these are generally very tiny). So while you cannot drop to zero, you can get stupidly small. Second, is harvest threshold. Harvesters will have a certain percentage at which point they will not work. This is mostly for drill differentiation. So a smaller drill might be more compact and have less of a depletion impact, while a larger one can drill deeper (work with lower abundance rates) but will also deplete that node over time. Third is scanner resolution. Currently scanners return a precise amount (i.e. 2.743% Karbonite). Scanner resolution will come in four flavors: Level 4 - Precise (2.743% - 5.267%) Level 3 - Nearest Percentage (3% - 5%) Level 2 - Biome Average (4%) Level 1 - Presence only (Y/N, no numbers) Default will be Precise (i.e. what SCANSat has today) but this will allow the API to support a variety of scanners at different tech levels, and even vary by resource. Scanner diversity for the win. Fourth is discovery. Scanners may be configured to not work at all until a biome is first explored on the ground. Once explored, scanners will display data for that biome. This is retroactive and not per resource - so if you add a new mod with a new resource, and explored that biome before, you will see the new resource unlocked. The gameplay goal is to really make resource harvesting feel more like exploration instead of just a probe and a time warp. This can be overridden by modders and combined with the other new features, so a use case might be one where a scanner only shows presence (yes/no) but unlocking via discovery is required to get access to more precise numbers. The default will be discovery required for everything unless explicitly overridden by a resource scanner. Anyway, thoughts and feedback are always appreciated

I make no warranties on earlier stuff whatsoever - odds are something will explode

Someone did a RT config up the thread - and if someone wants to log a github issue I can roll it into the next release.

I would not even try to mix these, and some of these bits are 0.90 specific as the API changed... Trickle charger is being deprecated so don't use this. A properly configured module should perform pretty much the same thing, just with the standard UI (in essence, all modules trickle charge - hence the load parameter). For parameters, look at existing modules. In your case, the reactors are probably a decent starting point.

You probably didn't install everything in the mod. You need it's latest version of USI_Tools

Sorry, sounds like you are asking a Module Manager question not a Regolith question? I really can't follow what you are trying to ask for help on. If you have a very specific and concise question WRT how Regolith generators work I can answer it, but cannot provide MM tech support.

If you backed into an active expand tube that's a known bug with the stock ARM claw. Hence why I specifically warn against it

RE height, show me an example, and note the requirement to NOT be in snap mode below. It should, make sure you are not in snap mode.