cyberKerb

Do you have a sample save I can try? Also what was the roll force set to / was it disabled?

I suspect you're too far from Minmus for the LB10 beacon to operate. Worked fine for me. However, I checked around the orbits to see what did and didn't work and found it does have a maximum range as well. This isn't surprising seeing as it's built for in system transfers If you continue to use the LB10 - can you try a Minmus Orbit between 15K - 534k and activate there? The max distance is probably a function of the mass of the ship the beacon is attached to, so that 534K is probably a very subjective figure. Side Note: If you add (and activate) a Gravitational Mitigator part to your ship, the max orbit goes out to about 1,819k which would still be under the 2000k orbit you've been testing at. Having said that, I also checked the LB15 device for the same orbits around Minmus. The LB15 operating orbit range around Minmus goes from 15K - 955k with NO Gravitational Mitigator. With the GM, it's range is past the Minmus SOI - so it would cover anything around Minmus so long as you were above 15km. Here might be a good place to suggest @Booots add a few extra error messages to the Beacon initialise process. It seems the "Activation Failed! - No Electric Charge" message is catching a few exceptions rather than just no electric charge. Here's my suggestions for a few extra error messages to help people troubleshoot their issues: Orbit too high: There is already a error message for when a ship is too close to a body, could we get a separate specific message "outside of operating radius" or something when the beacon is too far? Above example of being in a 2,000K orbit around Minmus with a LB10 when it wont activate unless the beacon is below ~534k depending on ship size. No Karborundum: It seems that Karborundum needs to be on-board for the beacon to startup, could a specific error message be added to indicate that was the reason the beacon didn't activate? I did find an admittedly old update (for KSP 1.1.3) where it mentioned that Karborundum was no longer required on board to initialise a beacon. I'm using ESLD version 0.81 and I can only start the beacon when it has Karborundum in a tank somewhere. I chked the rest of this thread and missed / couldn't find any mention that it was a requirement again. Also, I can't see anything in the Beacons cfg file that allows for configuring this requirement. Is it in a different file I'm not looking at? Or did this requirement never get removed/re-added in a later update?

Thanks for the info - I'll check as well. I've never noticed any torque with roll force at zero (and I kind of don't expect it either) I do know that the angle setting has no effect if the snap setting is off. I think I remember @RoverDude adding that button for exactly that effect no long ago. I rechecked it just now on a career save and it's still working that way. Snap off = no specific angle docking - ie normal clamp-o-tron expectations.

Hey @Kobymaru - thanks for your work on the wiki. Just wondering if my understanding was correct for these "most-case" situations I use the ports in? (Also - I hope the info might help others still working it out) NB: Images show docked orientation Docking Expectation > Clamp-o-tron "a-like" functionality (dock any angle) - Set Snap = Off on both construction ports - Roll Force = 0 on both construction ports Docking Expectation > Clamp-o-tron "a-like" functionality with restriction to a single specific angle - Set Snap = On on both construction ports - Angle = 0 on both construction ports (orientation of ports match) - Roll Force = 0 on both construction ports I use these settings mostly for specific orientation docking - only docks one specific way. Docking Expectation > Clamp-o-tron "a-like" functionality with restriction to a single specific angle and rotational torque assistance - Set Snap = On on both construction ports - Angle = 180 on both construction ports (expected orientation of ports is upside down to each other) - Roll Force >= 1 on both construction ports (add more force for bigger parts) I use these settings mostly for station construction and assisted docking other ships, as the rotational torque helps get the exact angle I want. I'm specifically not using the "Compress Parts (Rotate)" due to the bug / reported issue you mentioned and only using the "Compress Parts" to compress in the docked orientation.

If it's the old bug you're suffering - check this forum link to see if it fixes it

Oh I'm very happy at the moment as I received my first ever package from Mexico today Note: I've also hidden the photo in case you want to keep the surprise

This would be harder than seems at first glance.... If you took the current orbital height as a percentage of the Apoapsis that would give you a nice relative range to determine how much particle effect to add to the komet. Only question is how this is calculated after an SOI change to a body that isn't Kerbol.

Maybe the giveaway was the papercrafts themselves. (I know the OP said otherwise but... *shrug*) I'm not beat up about it as it was a bit of fun over the holidays. If it does turn out to be something, then all the better

Same here - just the PM asking for shipping details. Here's my attempt in KSP using Nebula Decals for the wallpapers

Could I get some clarification? Which edit did you use as there was two mentioned? UseSpecialistBonus = false or radiatorCoolingFactor = 100 Or were you recommending both?

Changing just 'trait' isn't enough to fix it. So long as you remember their profession before they were set to permanently tourist - change these three things in your saves persistent.sfs file: Under the LIFE_SUPPORT_SETTINGS module - find your Kerb and set this value to their profession(Pilot, Scientist, Engineer, etc...) Example: OldTrait = Pilot Under the ROSTER module - find the same kerbal, change 'type' to Crew and 'trait' to the same profession as you set above Example: type = Crew trait = Pilot Once you save the changes and reload it should be fine for that Kerbal

Ah I see what I missed now - thanks @RoverDude. Yes I forgot about the Emergency hab having two seats, so it would of course add 7.5days for each seat after inflation. As for the other bit I don't understand - I pretty sure this is just me at this point. What I'm not understanding is how the CFG file value KerbalMonths is translated into the VAB. I understand the BaseKerbalMonths value is a direct view from the CFG file that then appears in the VAB. But the KerbalMonths value is the figure that seems to get transformed somehow and I can't work it out. - Shelter has 1 seat, CFG KerbalMonths figure of 1.2 and VAB shows 1 Kerbal month hab time - Karibou Rover Cab has 3 seats, CFG KerbalMonths figure of 1 and VAB shows 4 Kerbal month hab time Note: These are the ONLY two parts to have a >0 KerbalMonths value in the CFG file. All other parts in the USI constellation using habitation use the BaseKerbalMonths value.

I had a couple of questions around habitation. I'm trying to get my head around the difference of these two parts now that the textures show they are different. (I thought they were the same part in two categories) Please let me know if I've misunderstood how these calculations work. Happy to learn the correct way and would greatly appreciate any responses. Karibou Emergency Hab Description: This emergency shelter can provide two Kerbals ample room for either a shorter-term mission, or emergency habitation on a long-term mission while they await rescue. Suitable for twelve months of habitation at full occupancy. Mass: 0.24 Tons Habitation: 1.2 Kerbal months (1.2 Kerbal months = 36days = 216hrs) Crew Affected: 10 Multiplier: 0 Replacements Parts: 320 After deploying - option to Start Converter and this adds more hab time (At no electricity cost) Coupe of Questions: I figured most of parts descriptions are just flavor text, but this one initially seemed informative seeing as I'm comparing this and the MKS mini hab. Can someone advise how the description of "Suitable for twelve months of habitation at full occupancy." make sense? Is it only talking about this part? Isn't the hab values dependent on all hab parts in the vessel and there's no way to get 12months is there? Or am I reading too much into the description? Is there a rounding issue in the VAB Life Support Status screen where it only shows integers for the Extratime values? I took a Mk1 Capsule (7.5 days hab) and added the Emergency Hab (should it not add +36 days hab (1.2months) for a of total 43d 3hrs?) The Extratime value only showns "1" (not 1.2) so it only adds a flat 30 days (1 month) to the calculations for habitation. Taking this craft out to the launchpad, it starts with the expected 7.5days (7days, 3hrs) from the Mk1 capsule. Before deployment - Should the "Start Converter" action be visible if this shelter is NOT deployed? After deployment and retraction, it disappears, so I'm guessing it's supposed to only be visible when deployed. Deploying the shelter changes the Hab timer to an even 22days (+15days in additional to Mk1 Habitation). No hours? EDIT: Just worked out why - it seems to rounds the hab figure to days when >=21 days. (nice addition!) Using the "Start Converter" action on the hab, changes the from 22days to 52days (+30days over deploying and Mk1 hab values.) Separate question - after deployment, what is the "Start Converter" action doing? There isn't anything about converter in the Right click VAB part info for this. I'm wondering if it's a mistake or am I missing a mechanic that USI-LS does? I'm expecting hab timer of 43days 3hrs (43d actual seeing and the status page rounds the hab to days when it's over 20d 5h) - 7.5days for Mk1 +36days for deployed Hab shelter with a 1.2month hab benefit. However I'm getting 52days - 7.5days for Mk1 +14days 3hrs for deployed Hab shelter +30days for converter What am I missing in trying to work these figures out? For my own game, when I compare the emergency shelter (add ~1.2months) to the MKS Minihab (adds 10months) the same size part seems off. Is there any plan to change the size / part? The emergency shelter seems awkwardly large for the single month hab benefit when you could get a 10month benefit for the same sized part and a bit of EC. I think I'll modify my games cfg file to change the rescaleFactor to 0.5. Seems like it would just it 2 kerbals inside at 0.5. Not sure is this change would want to be adopted for the actual mod though seeing as the part asset was build to fit neatly on the side of the Karibou parts. Maybe the 10month mini hab could be bigger instead of shrinking the 1month shelter?

I found a closed 2014 Github Issue #6 for this exact issue. Should I lodge a new issue or add the above comments to that issue? Issue #78 lodged under the survivability pack & Issue #116 lodged under the Exploration pack I've honestly confused which repository I should of lodged that against. Survivability has the code but I've seen that it's combined into Exploration. But Exploration is where it gets released. Sorry for the duplicate issues. Does anyone know where I should of lodged this so I can close the unnecessary extras? I don't want to add extra work for @RoverDude just to keep Github issue list clean because of my lack of understanding.

I tired to retest and found that the reactor numbers seem to work for when the reactor load is at 100% continuously. Easiest way to do this was to stack a ridiculous amount of Z-4K batteries, and use hyperedit to empty pretty much all the charge, so the reactor is recharging a million plus battery. While at 100% load, even at high/highest warp, it takes 3 and most of the 4th days for 0.01 units of EnrichedUranium used. This is also correct when warping in the tracking center and the vessel is unloaded. After I returned to the ship from the tracking center after <4 days of warping and it loaded in the flight scene, it had used 0.01 EnrichedUranium to recharge most of the massive battery I had on the test ship. When I originally tested, I had drills AND batteries as the dummy load and found that something screwy happens from the 6th warp speed. Specifically, for the load I was using the Reactor load dropped massively after 6th warp from 61.37% down to 0.39% and got as low as 0.33% for my test rig at the highest warp. I figured this was why it took 400+ days for the first 0.01 unit of fuel to get used. I just put it down to something screwy with the stock game order to calculate the multiplications of charge+discharge rates and the order those things happen all within a highwarp timeframe. That and the fact that Drills are the worst dummy load to test with seeing as they have their own load % and that makes it harder to work out the calculations. Best test rig I used that allowed high warp (can't use engines obviously) 0.625 Reactor [+30EC/s] bare in mind slight delay for reactor to get to 1000 operating temp OKTO Probe core set to hibernate on warp [0.0002EC/s or 2EC/2nd highest warp] (highest warp give weird results) 12 x MKS Range TCS Heatpumps [Total of -30EC/s] 12x Z-8K batteries to cover the EC loss due to the probe core in hibernation. I've since learned to live with it figuring that the it's roughly right except I can't get the math right when warping at the highest 3 speeds for drills (ie 1000x 10,000x & 100,000x) Having said all that, I'd be happy to be wrong if someone finds something specific that can be corrected for those high warp issues.

Still mulling this mod over. Especially since the 1.2.2 release that added extra function I need to work out how to handle (specifically that funky "Collect All Data" button on the new Science Container) I do need some advice from the community I think... Getting ahead of myself, I need to work out how much complexity to add which directly affects mapping textures to biomes identifiers e.g.(MunSrfLanded) - specifically how many? Type? Colours? etc... Here's a summary of the range of details I'm thinking. Easiest Option: (2 textures + Empty) = 1x Rocks + 1x Liquid Downside: No variation per planet / moon. Blue liquid from the explodiumSea isn't that great. Upside: Low texture file count Easy Middle Ground: (15 textures + Empty) = 1 texture per Planet/Moon Downside: No variation per biome. (eg IceCaps vs Canyons) Upside: OK amount of variation, can distinguish the different Overkill Option: (161 textures + Empty) = One for every biome including a few splashed & landed varients (not counting planet expansion packs) Downside: Huge amount of texture files Upside: Novelty of "gotta collect 'em all" / look nice for those players that want decorative pieces around stations / large crafts Another element that adds to this complexity is where to get the textures from. I figure there isn't a way to easily tap into the planetary textures from the base game. I'm guessing my only option is to add new files for each one added for this mod.

if it helps for reference / code, @Elowiny did a Kopernicus pack mod (Chani Planet Pack) that included a planet (PIGGE) like the Vulcan you described located in a one million kilometer orbit from the sun (Moho is at around five millions kilometers at the time)

Does the "Evacuate" action available on the DERP inflatible excape pod currently work? Maybe I'm using it incorrectly or is there a known mod to interfere with this process? My only other guess is that the "Evacuate" action is from the (old?) USI survivability pack when I should only be looking at the USI exploration download where it might not be available? Not sure as I can't find where to view the exploration source code. In testing, I'm using 3 parts; Mk1 Command pod (containing a Kerbal) DERP Service ring mounted to the top node of the pod (so there is something to decouple) DERP Pod mounted directly on top of the service ring. I linked the DERP Pod action Evacuate to the "Gear" action group and when loaded to the launchpad, hit "g". The debug menu gives three lines upon using Evacuate: Inflating Evacuating! Could not find any crew to move Looking at the code on the SrvPack Github repository (SrvPack/Lifeboat/LifeBoat.cs) I found the line that evaluates to no crew. Is someone who knows the API better than I able to advise why this ends up as null? var source = vessel.Parts.First(x => x != part && !x.Modules.Contains("LifeBoat") && x.protoModuleCrew.Count > 0); Let me know if you want me to log a GH issue and I'll do that. Just wanting to run the prob via the forum is case it's just user error.

Is there any intended relation between the capacity of a container and the number of slots allowed? Just wondering what the original thoughts were around those numbers. I've installed a few mods that have additional storage containers and I want to align their capacity a little better but I'm looking for some guidance. I know it make no difference either way and I can change the cfg to anything, I was just hoping for some conceptual starting point to apply my ideas to.

Thanks - I've made the wiki modification to add a little info on the Scout. Only bit I wasn't 100% sure about was the Crew Skills To Function Table so I added a "Hab/Home Timer Immunity" function and hoped it would make sense to someone else reading it for the first time. Not quite sure if timer immunity qualifies as a function, but it seemed the right place for it.

But that's awesome! I'm early on in my MKS game and only just landed on the Mun, but I'm currently working contracts to scrape enough unlocked HAB benefits together to launch my Minmus mission. I'm going to have to hire a scout tonight and start that mission NOW! Any reason the Scout isn't one of the new skills added or that just something that was overlooked? The pages says 9 news skills for a total of twelve (Scout now being one of them). Scout is only mentioned in the "Crew Skills Breakout Table" part of the wiki page. I can submit a wiki page edit if that helps, or should I leave that to those who have had experience with the GitHub wiki formatting?

I've been going over RoverDudes list of new Kerbals and Skills. Are you able to advise what benefit a Scout gives / when you'd use them? I checked the list of Skills on the wiki and there's nothing about the ExplorerSkill that the Scout has.

I still remember how people would still add the suggestion over the years KSP has been around. Awesome work for making that feature a reality! I hope you continue to give people this surprise for a while longer as people like myself still try out mods without needed to read the full forum thread because all your great work and effort allows this to "just works as it should"

Thanks so much for making my day! I laughed at the screen at the shock it gave me after running into a tree. I'm surprised something like that isn't mentioned on the OP - or is that on purpose to give people the surprise?

Is it this mod that makes the terrain scatter solid? It's the only thread that I've found where someone mentions it somewhere on page 7