DStaal

I'm not sure working with a 10-ton part that you’ve lifted overhead using an electromagnet running off of a battery is much safer... (My point is that I see it as 'place it with the lift, remove the lift, then fasten', I guess. Either way, I see your point and don't really want to argue. I agree I wouldn't want to work on it in real life.) I don't see a way to limit spamming the parts - though as someone who's actually tried adding this to parts before I will say it's not as useful as you might think. KIS calculates 'pickup distance' from the center of the Kerbal to the center of the part, and that distance by default is 3 meters. (And note the distance of the Kerbal actually doing the work is relevant to what range you can actually do things at - The guy with the wrench has to be at the location you're attaching/detaching.) So if you're lifting a Kerbodyne tank (the only stock parts larger than 20 tones, and nearly the only ones larger than 10), you need to be within 3 meters of it's center with your Kerbal. Given that it's radius is 3.75 meters, that's a tricky task. (There is some play in there - I've successfully lifted 3.75 meter parts. But you basically have to be right next to the center of the tank (not the ends) and be able to place it right next to you as well.) Of course, some of the full Kontainers have significantly larger mass that that - the 1.25 meter container in my images above has a mass of over 19 tones - but the point about it being of less utility than you'd think still applies.

I tend to think of what we're trying to simulate here as an abstraction - 'lift and place with equipment, then fasten down by hand.' I mean, there is only one Kerbal there, he can't run the forklift and his wrench at the same time...

Ok, everyone lined up and ready for testing? Hmm. Minor problem Huston; we seem to have missed one: Testing complete: So, things seem to work ok. Minus the one miss. I'd assume the forklift can probably lift quite a bit - should I set it at 20 tones or something like that? Oh, and taking a 20ton mass off of an Akita flatbed will shoot the Akita into the sky as the suspension releases. Not a major problem on Kerbin - it only went a couple of meters up and came right back down - but I could see that could be a major issue on Minmus or something... And as a suggestion direct to RoverDude: the Buffalo hitch is *very* useful in conjunction with these parts - the Akita parts especially. Any chance we could get a similar part designed to match these? (It's just a docking port, in a form factor designed for rovers. Best view above is probably the center pic, with one on both ends of the flatbed.)

Basically, yep. From what I understand. You don't always need to do steps 2 and 3, depending on the type of change. If you've used a version control system before, it's fairly straightforward. Either way, I’m going to take a look at it in-game (with my back-ported parts under 1.1.3...) and unless you say not to I'll do a PR of my own once I've done that.

That'll work - once I upgrade my computer. 1.2 upgraded to Unity 5.4 from Unity 5.2, which means the minimum supported version of OS X is 10.8 now. I found this out after a long night of trying different things and having to reboot my computer every time I tried to open KSP.

Just thought you might like to see an image of a use: This is my Kerbin-SOI tug, freshly returned from a station near Minmus (towing an empty crew ferry). It's got docking ports at both ends, and enough DV for a short-trip run to Minmus if needed. (Or for several runs back and forth before it has to refuel.) Of course, to help that it can areobrake when returning to Kerbin - as it did this time. It will need to be refurbished before going again, although it could swap ends and brake facing backwards. (Though the docking ports don't match - it could only do that with a pure cargo load, which would use the other docking port. It couldn't do it with this configuration, as the crew ferry needs to be shielded from all atmospheric reentry effects.) In this particular trip the ballute did nearly all the work - there was a small circulation burn after it exited the atmosphere, but it easily areobraked down to it's ~250km parking orbit in a single pass through the atmosphere, although it did dip down a bit lower than normally planned - it got to about 43km.

That the max? Either way: Looks good. Do you want to submit that as a PR to RoverDude, and hopefully get this into his next release? (Or should I double-check it and submit it myself?)

I got the impression he was more looking at using that model as a guideline for atmospheric (at high altitude) collection. And there's nothing fundamentally wrong with the Bussard Ramjet concept - it just doesn't turn out to be as useful as other options because of the speed limits. At least, not as an interstellar transport - I do have to wonder how well it would work as a steady-state arkship. (That is: Don't go into a stellar gravity well. Just collect and refine interstellar gasses to make up for any losses in your mobile world-ship.)

Thanks. One note: When I wrote this, I hadn't tried out 1.2 yet. Turns out, it dropped compatibility for my OS (OS X 10.7.5), so I'm stuck on 1.1.3.

For the first, my plan was to experiment: Send out a bunch of Kontainers with different weights, and see what it's possible to lift. That plan's gone by the wayside a bit because I can't run 1.2, but if you don't mind doing the bit of work, you could find out fairly quickly. As for the second: @PART[PAL_Crane]:NEEDS[KIS] { MODULE { name = ModuleKISPickup allowPartAttach = true allowStaticAttach = true allowPartStack = true maxDistance = 10 grabMaxMass = 10 dropSndPath = KIS/Sounds/drop attachPartSndPath = KIS/Sounds/attachPart detachPartSndPath= KIS/Sounds/detachPart attachStaticSndPath= KIS/Sounds/attachStatic detachStaticSndPath= KIS/Sounds/detachStatic } } I've tested this (with a different part) in 1.1.3, and it worked as expected, allowing me to move parts around. As I said: If you can get me the realistic max weights, I can work out the rest. I believe you could probably set those 'true' values to 'false', but I haven't tested yet - my test part is designed for orbital work, so I'm hoping for surface parts so I can test a bit better.

Beyond what Dr.Wolfram has said, I'd take a look at Extraplanatary Launchpads for building in-place - and just using the docking, mounting, and engine parts included in the set to launch and assemble the base.

I think you could just leave the keys as they are for that - if the Kerbal is on EVA, it can use a nearby part to help lift, and you don't need to have the keys available for a craft if the craft isn't the 'active' controller when using KIS. I am planning on doing the same, and sending in a PR with a completed config. I can leave that to you if you want, or if someone could give me good ideas on what are the max lifting capacities are for the various parts then I could write something up. (I was going to test that myself, but I can't run 1.2.) I could set some random max amount, but I think it'd be better if they can only lift the same amount via KIS as they could via their normal controls. (Same with range: Set it to their reach, instead of just some big number.)

'G' in that model is open trusswork, I believe... But yeah, as the scoop that looks interesting. (As for 1.2: I can't even run it. My OS isn't compatible. It locks up my computer the moment I get past the loading screen.)

Near Future Construction's trusses in battery configuration make very good batteries for a lot of large ships and stations. They are often my go-to if normal batteries aren't enough.

They've mostly been overloaded by the 1.2 release. The curse of hobbyist websites - poor resource availability. (Though if you have a machine you could add to their CDN...) (There was also a major attack on a backbone DNS provider recently - which may have impacted things as well.)

Main thing is the addition of capacitors. I'm not sure if there's something else - I've avoided that pack because it also changes how nuclear reactors work, and I like USI's reactors.

Anyone know of a mod that would allow you to raise/lower the thrust of your RCS units on a ship-wide basis? (Preferably via action groups to pre-set levels?) The use case I'm working with is that I have a few 'orbital cleanup' probes that attach themselves to various pieces of space junk and move them around - occasionally de-orbit them, but they might bring them to an EL recycler, or to get used for parts in a station of some sort. (Discarded final ascent stages make good pieces for a fuel station, for instance. Or I use MOLE's wet workshops to build something.) These probes then need two different RCS settings: One for when they are on their own, and one for when they are hauling something. I normally use MechJeb to handle things, and overpowering RCS in MechJeb results in widely inefficient monoprop use. Throttling down would help, but it's hard to maintain equal levels on 12 or more RCS units. Besides being time-consuming and boring.

Some of these exist, and some of them can't exist, because of KSP limitations. The space elevator can't exist, because of limits in the KSP physics model. For lights, there's one stand-alone mod I know of: surface-mounted lights. Some other packs have lights of various types (MOLE I know has some, and so does KSO), but they aren't main features of the mod. Bigger wheels and caterpillar tracks you'll need Kerbal Foundries - when they work out how to update to the new wheel system introduced with 1.1. At the moment it's non-functional. Batteries again are mostly scattered into other packs - NFC trusses, some MOLE parts, some Karibou parts, etc come to mind. Near Future Electrical is probably the most focused, but it also modifies a bit how EC works in the game. Energy/power consumption has a couple of mods for, depending on what exactly you're looking for. AmpYear's probably the best at the moment, but again it modifies how EC behaves in-game somewhat.

I haven't checked this in 1.2 yet, but I was noticing a couple of mods out there that define new occupations for Kerbals, since you can define that in MM patches now. (Notably Colonists who are low-level generalists: Can pilot, repair, and refit a rover, but can't do more advanced skills from any tree.) So a request would be to support careers as defined in the current install, if that's possible.)

Here's the thread you were looking for:

Here's a concept model someone put out: https://en.wikibooks.org/wiki/Space_Transport_and_Engineering_Methods/Resource_Extraction#Scoop_Mining Don't know if it looks all that cool though...

Note that all of these have replacements that fill the same roles and look fairly similar. For instance, the gangway's appearance can be achieved with the current corridors - but the current parts will be sleeker if you don't have something attached to all four sides, as the empty ends are hidden. If you're using the garage, the question is if you're using the *depreciated* garage - the current garage looks almost identical, but is sightly taller in proportion so that it fits most rover packs without modification. I wouldn't necessarily care if things are removed or not - but there is a small performance hit for every added part, and 1.2 apparently has some issue if lots of parts are loaded. Given that, I'd say remove them. You could offer up a download of depreciate parts (with the note that you won't be maintaining them) for those who need them.

On the other hand, their body proportions mean there's going to be a significant differential within their head - and that the distance from their hearts to the tops of their heads is proportionally larger than it is in humans, both of which could mean they are more susceptible to the differentials. I think further study is needed.

A good reference for this is this page: http://www.artificial-gravity.com/sw/SpinCalc/ It has a calculator that makes looking at various scenarios easy, using references from multiple papers (including the one on the Atomic Rockets page) as references for 'safe' limits. 1G isn't necessary - and may not even be desirable. 8 RPM is considered dizzying by all of them it's references - from playing with numbers for a 15m radius I'd probably aim for something like 4.5 RPM (or even 4.25) - it'll still be a bit fast, and you'll get a bit more tangential velocity than you'd like, but you'll be at a fairly comfortable third of G, and within adaptation tolerance limits for everything. (4RPM doesn't lower your tangental velocity that much - but it does lower your artificial G-forces to one quarter Earth-normal, which is getting a bit low.)

Ah, sorry. I'll admit I tend to avoid spaceplanes, but looking up what the issues are from the Atomic Rockets website what would be realistic would probably be a moderate sized scoop on the front of a very, very, long processor. Having a large scoop doesn't really help because unlike an engine (where you're sending the gas through), you're capturing the gas, which means your scoop will end up at equalization pressure to the atmosphere. The bottleneck is actually how fast you can cool and compress the gas down to process it - while doing an atmospheric entry...