SkiRich

Ah, thats a great tip. Thanks.

I'm soliciting some advice here for what I want to become a long, very long term off world base. I made a science space station that can hold 20 kerbals for 8 years. What I want to do is put it in an orbit around a body and then make a base on the body below it. Assume Duna for example. My goal is to have a bunch of kerbals that live extremely long term on the base and may go back and forth between the space station and the base. The problem for that is always the Home variable. All the other things I can account for but Homesickness I cannot. What would be your best approach/strategy be to create a base that a set of kerbals will occupy for say 10-20 kerbal years without needing to come home and reset that counter? Which body would you do this on?

@Tokamak What ever happened with this? Success?

I need new glasses. Still not in the source thats up on git. Looks like there is a reference in one of the binaries I can just about read but it points to the authors local D: dropbox drive. From USITools. Which is where the logistics consumer CS file is. Probably best to just let the author tell us how this works.

@RoverDude Any chance we can get some clarity on the above posts for how ModuleAutoRepairer works. I dont see the source code for the dll's on github so I cant verify.

Sorry then I dont know yet. I havent set one of those up yet. I would test one thing. Those parts that started out with no machinery probably never became operational. Maybe try adding or hacking in a few machine parts to get them functional and then see if perform maintenance is an option.

Thanks. I suspected that would be it. It doesnt bother me enough to add another mod into the mix. I simply just decouple and move over a bit for cosmetic reasons.

The tundra workshop does not have the Resource Warehouse module which is a requirement for Logistics Consumers to take from nearby stocks. You could add a ModuleManager patch to add that module to the workshop if you really wanted to. It should work on saves as well (if it doesnt you may need to edit the save file and just add it to the deployed part). A quick ultrafinder search of the collection shows all the "tanks" and storages have this module, and only the Ranger and Tundra ISM's have this module.

I'm not sure but I thought there was a blurb somewhere where the minimum version of ksp is 1.8.1 to use the latest MKS. You might want to download an earlier release from the github page for 1.7.1 @Tokamak Simple solution would be to make a Medical Bay Rover. An Ambulance of sorts, with either a dock port or grabber claw, both of which allow docking transfers of kerbals.

Some more color ... I found out through some cheating and trial and error, you cannot have a craft with a JAW installed AND a squad stock grabber claw. No matter where I put the Stock Claw, whether on robotics or on craft they get moved off the ship and into a different spot. It seems there is a problem with having both types on one craft. The last test involved just having them on a craft but not armed, nor deployed. I am not sure where the issues are, whether jaw, grabber, robotics or asteroid. Suffice it to say, any craft with a Jaw on it should not include any grabbers or robotics to be safe.

I'm not sure if anyone is watching the ART forum or not, but I have posted a few things in there about ART mod. Some serious flaws.

Ok there is something terribly wrong with the JAW. The last test craft I made had 4 stationary claws and one jaw. All five were attached, looking good to the asteroid. Then I left the scene, going to the tracking station, and on return to the asteroid, the jaw was about 15m's off center not even attached to the craft and the craft was sunk about 15m into the asteroid. Not how I left things. Something is not right, and this is unplayable. I have to rethink this.

@RoverDude Some feedback ... I have a mining operation in full swing. My trick of altering the mass of the roid so I can move it and then returning it to what is was before works well. I have noticed a few oddities though. 1. Class C - The asteroid doesnt seem solid in some places as the jaw drill dives past the surface but eventually attaches. Seems related to density. Conversely if I pick a spot that is a depression to attach, the jaw attaches a few meters above the surface. If that can be repaired in some way that would be awesome. 2. I built a craft with 5 points of attachment. Jaw in the middle surrounded by five claws on pistons I extend out and around the craft, which keeps the craft from doing the pendulum effect. The problem is, if I leave the scene and go say to tracking center and return, the craft has shifted a bit and the 4 claws are off to the side seemingly not connected to the craft but in effect, they still are connected for physics reasons since the pendulum effect is kept in check. Attempting to release the craft will cause the 4 claws to blow up though, so once attached I need to stay attached otherwise all hell breaks loose. 3. If the effect of diving past the surface is not possible to fix, then a control panel button via blizzy toolbar would be nice to have, since hunting and pecking the asteroid to get at the PAW of the jaw is a pain. Thanks for the mod by the way.

I noticed that the resource this mod uses is MetallicOre, while the community resource pack already has a definition for MetalOre. Is there any plane set to make this mod use MetalOre or both?

@RoverDude I could use some advice here on asteroids and editing my save file. I run v1.9.1 of the game and in it has a flaw where all asteroids had 150 ton as their base mass. I followed the instructions to remove that line from potatoroid's part .cfg and I also edited the mass = 150 line out of the save for the asteroid. In 1.9.1 mass=150 meant - whatever the random mass was, multiply it by 150 Looking at the class C asteroid and confirmed by the save file, the mass is listed now as 180,998 tons, which is still terribly off so too late, I was already docked to it and the mass was written someplace else. I was docked to it, which i assume causes that issue and sure enough there is a module in the craft. I also have 16 of these in the combo vessel in the save, all with different values, some say zero: My questions: Did USI Asteroid mining set that ModuleAsteroidInfo, and if so, can I just edit the values to be in range of the class C asteroid? If I do the above, will the resources also change value. Do I need all 16 ModuleAsteroidResource entries considering they do not list what resource type? I assume this is in error but I dont know for sure. Edit: Found that Community Resource Pack causes all these, but still have not found out why they have no designated resource name. Thanks in advance.

Can someone point me to where in the configs I would edit the following? I have SVE with EVE+Scatter loaded. The line between light and dark as kerbin orbits and transitions to night is too sharp. I'd like to diffuse the edge point a bit so it doesnt look like a blanket of darkness is being placed over kerbin or a super storm is on the horizon. I know its a setting in either scatter or eve or both, but instead of tinkering trial and error, if someone knows the settings to touch, please share. Screenshot of the edge of night:

@Nertea I'm wondering if Near Future Aeronautics is compatible with 1.9.1? It says its 1.6.1 and you havent updated due to code loss, but that has been a while.

@allista Can you point me to a video tutorial (or any tutorial) for hot to setup a rocket to use TAC as an autopilot to precisely land at a base?

Can someone point me to the instructions on how to setup the B9 VTOL engines? I havent used them yet but played with them in the SPH. I am making an assumption those settings in the PAW map action keys or something but if a wiki or post has the details I would love to read about it first. I found some videos on youtube I'll watch in the meantime. Thanks for the mod, I use the parts extensively and just discovered the engines.

@Tidal Stream I can confirm the two errors reported above by @BeastlyBean and @NippyFlippers The nose cone is bugged out. No matter what size I select its always tiny and flat. Editing that part causes a freeze. The other parts seems to work fine, just the nose cone. Nothing in the logs specific to this mod or nose cone is throwing an error. I went back to 2.0.5 and all is fine. The 2.0.6 release says its a hot fix for NaN. I dont know what that is or if I am affected by NaN so I'll stay with 2.0.5 for now. I'll gladly test any new code you put out if you want me to.

There is a specific file dedicated to MKS called ... \IndicatorLightsCommunityExtensions\patches\IndicatorLights_MKS.cfg While its not directional in the sense of your patches per se, it includes the snap function with a forth led turned on when snap is turned on, so yeah its directional, but maybe not like the ones you built. Thats perfect. Thats exactly how that should work for the Konstruction ports.

@DStaal The MKS ports work fine. I posted that comment before actually trying this out. The screenshot I based my comment on from Tonka was posted but was old and not the current iteration of the patch. What I did find was StationPartsExpansionRedux stepping on the regular docking port directional patch. I fixed dockingPort2 with a MM patch, but in the process needed to modify the cfg from the community patch to exclude StationPartsExpansionRedux so no directionality for me on that one port. Thats on my list to fix as well, but at the moment I just want to play a stretch of the game before modding again. When I have some time I'll fork the patch and send a pull request to make it all work.

@Tonka Crash Digging a bit deeper I found that the original mod, Indicator lights, includes indicator lights for the SNAP functions of the Konstruction ports, so making indicator lights for MKS ports would be redundant. I did notice the orientation for the patch is correct once I did get in game, but also noticed it broke the lights for dockingport2. I do have one issue, the dockingport2 (regular clampotron) has no indicator lights at all. Just for testing I remmed out your patch to move the two bulbs but that wasnt it. A bit more testing and surfing the log and I found Station Parts Expansion Redux changes the model so dockingport2 can have multiple variants. I suspect the model is deeper and the indicator lights are just buried in the model and cant be seen. In any case the patch you use targets a model in the cfg by its index and not the name (which isnt set), so there was a bit of conflict there. I suggest putting in another MM qualifyer for dockingport2 :NEEDS[!Restock&!StationPartsExpansionRedux] to prevent the conflict or coordinate with Snark to add a name to the model module and then specifically target the modules. I'm going to try and decrease the depth of the original indicator lights to see if I can make that compatible with Station Parts Expansion. Just trying to be helpful, no complaints at all.

@Tonka Crash That was plan B. I figured it would be easier for you to do then for me to figure out the mechanics and make a MM patch, but if you dont plan on adding this then I'll customize my version. While MKS uses the exact same textures as stock, their modules are named differently, so technically yeah they are different and at the moment do not have any directional lights. Just plain lights. You got the Jr port right, but the regular and Sr versions are upside down. Those dark rectangles in the middle of the parts are windows and signify up.

@Snark @Tonka Crash Thank you for the direction indicators. Very handy. Where it would be better served is if you can add them to the MKS construction docking ports which use directionalality extensively for welding two ports together. While I havent seen this in action yet (just updated the mod) from the picture on the RegDocking port and the Sr Docking port above I'm guessing up or zero is the single green light while down or 180 is the three green lights. On the MKS ports that would be opposite. You may want to adjust that so there is consistency in all the ports.