rudemario

In my video linked in the post, I start the timer off at 50 years and 6 days. When I launched the ship, I started with 50 years and 95 days before fast forwarding to 5 years and 6 days. This is a screenshot from the video. While a little blurry, you can see the timer there. When I fast forward, the timer keeps counting until they no longer say indefinite. This isn't what is supposed to be happening I don't believe. Also from the Wiki: Functions-(Habitation) under Habitation and Homesickness, right before the example. "The hab/home timers can also be paused indefinitely if habtime per kerbal exceeds 50 years or 1 year if the kerbal is a pilot/scout, or is on a planet with a kolonisation rating of over 500%." It looks as though either the Wiki is wrong or I'm encountering some bug? It says the only requirement for pausing the hab/home timers is if hab time exceeds 50 years for all kerbals aboard, or if they're on a planet with a kolonisation rating of over 500%. I have met one of the criteria but it's not working. You can see in my photo above that my ship was at 50 years and 6 days of habitation time before I began fast forwarding in the video in my second post. Also, my ship started with 50 years and 95 days before I fast-forwarded to set things up for the video I took. I really hate to be that guy, but, @RoverDude, am I missing some requirement not listed on the wiki or is this a bug? I'm sorry to invoke you, but the behaviour in my game goes directly against the Wiki and what some people have said in the forum.

Am I misunderstanding something here? You said that all Kerbals are immune if these values are over 50 years. In my post I showed the values of my ship in the video were at 50 years plus 5 days, and before I recorded the video the value was at 50 years plus 95 days. It wasn't until I got below 49 years and 400 days that the hab/home timer showed "49y" instead of "indefinite" which I showed in the video. My screenshots showed only the threshold point of before indefinite expired and just after. But in my second video it shows that the timer still counts down even though all crew members show "indefinite", and then once below 49 years and 400 days FROM 50 years and 90 days they switch to "49y" If I fast forward all the way until their expiry, they do actually become tourists, and my pilot, Jebediah, doesn't, so he's functioning like normal. What happened to me goes contrary to what you're saying. What could be the issue? I might just be missing something here.

This is what puzzles me. I created a ship for testing purposes to illustrate the issue, and then I warped it up to Kerbin's orbit with the Set Orbit cheat default. As seen here: my ship has all the normal requirements. I'm not below the home altitude. All of my habitation modules are turned on and I wouldn't need colony supplies because pilots who are indefinite don't need colony supplies. I have enough battery to last throughout the dark side of the planet, recycler for 3 Kerbals, supplies, enough Nom-O-Matics to meet demands, fertilizer, enough power generated via the solar panels to feed all of the habitation modules, as well as having all of the habitation modules turned on and deployed (I encountered an issue before with habitation modules functioning while uninflated but this was unintentional, causing unexplained bugs). In another video here: you can see that with my ship starting at 50 years and a few days, that after going around Kerbin a few times you can actually see the timer tick down in blue: "hab for x:y ." After a few go-arounds, when the hab time reaches below about 49 years and 400 days, the indicator on the right switches from "indefinite" over to "49y". Now, the Pilot is unaffected. If I time-warp all the way down below 1 year, he is fine and functions normal. Everyone else on the other hand doesn't get this treatment even though they're above 50 years and say "indefinite." Here you can see my config settings and you can see everything is set to default as normal and the default time for regular Perma-Hab is set to 459000000 which is the default 50 years. I'm not sure what's going on. Any ideas?

Hey Terwin, would you happen to know whether this "indefinite hab/home" feature is still present in MKS? I have a ship that has 50+ years of hab/home for my 3 kerbals, but the scientist and engineer switch from "indefinite" to "49y" after a few days in orbit, obviously after enough days have passed to fall below the 50 year mark. Maybe there is something I am doing wrong or this feature has been removed. I replied to your post since I saw you addressed the issue in August as quoted and might know more about it.

I have read that having a ship with greater than 1 year of habitation will result in Pilots having their habitation and home requirements met indefinitely, and having a ship with greater than 50 years of habitation results in other specialties gaining the same habitation/home needs met indefinitely bonus. This seems to function properly for me with Pilots, where no matter if a ship has been out in the field for 60 years, if it has a hab capacity of more than 1 year it fulfills that need indefinitely. But when I launch a ship with Bill and Bob as well, the trusty old original Engineer and Scientist specialties, I notice that the hab timer still ticks down, and even though it says "indefinite" for Bill and Bob, when the timer reaches enough days below 50 years, say, 49 years and 300 days, the timer kicks back in to showing "49y" left instead of "indefinite" Am I missing something? Thanks!

I played around with this yesterday a little, but it was getting late. I saved your post in my notes for future, the "capture and go" technique as Brikoleur called it, so I can definitely give it a try and confirm it actually behaves as I think it does (same as flyby but delayed). Thanks for the detailed writeup!

See, this I already knew, but This is interesting to keep in mind. It's something I haven't thought about before, and even though it doesn't help with this specific issue, because I use a life support mod, it does actually help a lot when time is important. You're right. If I have to lose time, this does help save time over other riskier options. Thank you for this, interesting to keep in mind. This is by far the coolest thing you mentioned. I never thought of something like that. A flyby where you get captured? Does that even result in the same effect? It's really interesting, because you still gain the speed from being captured, but you're storing it for a later date. This is actually really cool and something I haven't even thought of. Honestly, this just might be crazy enough to work. You still gain the speed of the secondary body when you're captured I believe, so that means you must still gain an assist when you leave it. Or maybe this is wrong, and being captured doesn't actually result in an assist. But, if you look at the example of explaining a gravity assist with the Train method, i.e What happens to a ball thrown by a person standing next to an oncoming train? If the person throws the ball at 20 km/h, and the ball hits the front of the train and bounces off at 20km/h, what happens to the ball? Does it still go 20km/h? or does it go whatever the train was going plus 20km/h? In that example, if we take what you mentioned, I think it would still be true. It's just that instead of the ball bouncing off at 20km/h, it sticks to the train until the ball leaves later. The problem is the ball loses it's momentum, so maybe the energy comes from the person throwing, and that would be lost (getting captured instead of flying by). Or maybe the energy comes from the train, and spending a little to leave the train (just enough to burn back and get uncaptured again) it results in postponing the "bounce off the train." This is really cool, and something to think about. This might make the issue a little easier, I will give it a try. This is neat as well, I'm also going to try burning around periapsis to change my resulting orbit and see what that does. I've tried before, but I know more now, so maybe this might result in more success.

Exactly this! Honestly. When you get enough speed to get low enough to Duna, you're not anywhere near it because you're no longer ejecting towards solar retrograde. Then, when you manage solar retrograde, you don't have enough energy. So you try again. Now you manage to get both down, and you don't end up making the window and now you can intercept. Now it's been 1 hour and 45 minutes and you've basically done nothing. You start over at an earlier date to make the transfer window plus maybe using a radial burn in deep space to make up for the difference but now you can't even get any of those lined up. Now it's been 3 hours and you've literally done nothing. You can repeat this for however many times I've tried to develop a consistent strategy for making this work. I still genuinely think it's possible, so that's why I keep trying.

Encountering Tylo right is literally the entire battle. if you could just Hohmann transfer to Tylo that would be easy. A hohmann transfer does not contain enough kinetic energy that when bent around Tylo at 10km and ejected towards solar retrograde doesn't get you a low enough solar periapse. So you burn more energy than required for a hohmann transfer. This makes your rendezvous more narrow. Everything compounds. Someone suggested to me to use KSP Trajectory Optimizer Tool; In it is a tool called "Multi-Flyby Maneuver Sequencer. This tool only allows you to plot flybys of bodies of the same parent. There is no way to plot Laythe>Tylo>Kerbin in this tool because Kerbin is not a child of Jool. Hmmmm... This isn't getting any easier.

A note I took before says: With just 3 nodes and as little as 745 dV (80+81+579) I had an initial transfer of 579, as shown in the image, and then I created a node halfway along to adjust radial and inclination I believe. The final one might be a burn at periapse like you mentioned. It has been a few months since I took this screenshot, and I'm currently at work, but I do have a saved quicksave with this exact maneuver I believe, so I will post what you're asking after I get off work. I'm not sure the three nodes I used are that important, though, because yesterday I got the transfer to work with just a single node I believe. I think it only reached Kerbin just barely though, and it wasn't in the transfer window because I was just testing. This is what makes me believe it's possible to get this consistent and easy to repeat. A parking orbit or even just an eccentric orbit like you mention (resulting in anywhere from 1-40 rotations around Jool or Laythe) should eventually produce more options. It's just it's hard to then line these up with the proper exit trajectory AND enough magnitude. Seriously, if someone were boot up the game and try to do what I'm doing (Parking orbit around Jool or from Laythe) and tried to do this twice—two separate instances—I would bet they would have problems replicating it and taking the same amount of time (or less) to plan the manuever. I'm talking I either get it in half an hour, or two hours, and some days I don't even get it at all. Maybe there is something I am misunderstanding about planning gravity assists?

I'm sure we're all familiar with the "Tylo flyby to perform a Joolian Capture" For whatever reason, this is extremely easy to perform. I suspect this has to do with the orbital period of Tylo. Any longer and there's a solid chance we'd end up missing it sometimes (if I'm correct) Now, how about the opposite? Using Tylo from Laythe to boost yourself down to a Kerbin encounter? Now, I want to preface this by saying I've accomplished this 2 times before, so I know it's possible–people have mentioned to me it wouldn't be possible before. See here for an example of a successful demonstration. And here's the resulting solar orbit. I am also able to add about 0.5m/s at Laythe and reach Eve as well, if I wanted. Now, how about the opposite? Using Tylo from Laythe to boost yourself down to a Kerbin encounter? Now, I want to preface this by saying I've accomplished this 2 times before, so I know it's possible–people have mentioned to me it wouldn't be possible before. Theoretically, it's completely possible, and I have proven I can do it. The issue comes from the compounding variables involved. If we don't enter a parking orbit around Jool, we're tethered to Laythes orbital period. We need to perform a minimum magnitude of a maneuver to encounter Tylo with enough energy so that when we eject solar retrograde out of the Joolian system, we end up with a low enough periapsis that we can encounter Kerbin. The problem begins to compound here. We have to encounter Tylo such that our ejection angle if we were to lower our periapsis of Tylo to around 10,000 or slightly higher (for greatest affect) results in a solar retrograde ejection. In order to do this, we have to change our magnitude and maneuver time in order to adjust this. But we cannot go below a certain magnitude. As you can see, this has resulted in me (over the course of a few months) spending hours and hours (sometimes 8 in a day during the summer) fiddling with maneuvers and getting what is basically chance encounters with Kerbin. I have been searching for a way to make this consistent, but have not been able to. Mainly, I end up restarting and eventually I end up choosing a good enough place and amount of orbits to start my encounter and things go smoothly. If I restart, I can't usually replicate it for a while. This maneuver will take me more than an hour to plan because of this, if I'm lucky, I might get it in half hour. I thought maybe a parking orbit would make things easier, but that adds extra Delta V to the requirements of the maneuver and results in me getting less Oberth effect bonus. (But you can lower your orbital period to add more opportunities/more accuracy) This is all before, by the way, lining up the maneuver duration to actually make the transfer window. This is complex and adds to the issues, but I feel this can be optimized once a consistent method for planning the maneuver setup can be achieved. Some people have said to me this is too specific to even be possible. But others have casually mentioned the ease of execution of a Tylo>Kerbin. I am at a loss. I spent another 4 hours yesterday after work trying some different methods, and I found Bradley Whistance's video on Gravity Assists. He states that step 2 is to achieve the magnitude required to "place your apoapsis" by adding prograde and then moving the maneuver forward in time to continuously add energy into the maneuver. But this hits diminishing returns with Tylo (since it seems I need an apoapsis between Tylo and the next moon Bop in order to get to Kerbin) and I haven't been able to even get close with his method (he used the Kerbin system for this demonstration) If anyone else can provide some help on the issue, that would be greatly appreciated. I definitely need some other opinions right now.

They 100% copied the whole volume/bringing items with you/using an engineer to attach it that KIS and KAS has offered for a long time. How does the mod creator/maintainer feel? I hope you guys were at least contacted/consulted on this before they added it and announced it.

Is there a way to remove the 1 hour timer for EVA life support on Laythe? (Since you can take your helmet off and breath the salty air. Yum.)

Who took my ground? Landed on Laythe with an SSTO and this happened. Very strange . Any ideas? Or is this a known missing piece of Laythe, lol.

Thank you for the explanation on hab timers and medbays; it seems I simply didn't notice that the only thing that puts kerbals into a permanent catatonic state is the home timer, and the other timers just need to be brought up from whatever their negative value is at the time of resupply (because the timers still tick) Now I think I fully understand the system. In regards to the mods, I tried slowly over the course of 2 hours to try various combinations of files. First I tried removing a few mods (bettertimewarp, etc) one by one, no change. Then I tried manually reinstalling the USI mods from their github pages. No luck. Then I tried stripping everything away until I just got down to MKS and USI-LS one by one, and still no luck, I'm still able to use the uninflated converters. So then, I tried getting rid of all mods, no avail. Then, I tried a full fresh clean install of 1.8.1 and ONLY installed MKS and USI-LS. Still able to activate the converters. At this point I was stumped and concluded it was a bug, and by extension this would extend to my other base on the Mun (but which was unmanned), but moving onto damerell's comment I inflated the modules shown and the ones on my SSTO pre-launch and tried to leave the scene, and things function as intended. Converters stay on upon scene reload. So either converters being toggleable is intended behaviour because the nature of the game and modding it prevents them from being disabled when uninflated or something, or this is a bug. They work perfectly fine minus a few days/months of hab for habitation modules when uninflated. This seems to me like unintended functionality. If I were to conduct a flight without resetting the scene I could exploit this to make it to Jool without the punishment of a larger craft. Thank you guys so much for the help. I thought I wouldn't be able to continue building bases but it just turns out I was fooled by unintended functionality. This means I can still play and build a base to explore the new planetary system added by EventHorizon and keep the accretion disk provided by INSTANTIATOR. Much appreciated guys. I'm excited that I can still use all my mods and continue.

I've been using the search function and different combinations of keywords for an hour straight, and I can't find an answer, so I do really apologize if this has been answered before. I'm playing on 1.8.1 with USI Core, USI Kolonization Systems, USI Life Support, and USI Tools installed. I also have Event Horizon installed (Interstellar Black Hole Planetary System added) and Extraplanetary Launchpads along with some QOL mods. I can't play on a newer version of KSP due to EventHorizon's dependency on Kopernicus. I love SSTOs optimized to fly into the airstream so fast that going straight towards the horizon is how they reach 70-80k to circularize. So I've spent a while learning how to make a USI compatible SSTO (learning the mod core concepts and applications) I used two Ranger Habitation modules and one Ranger Agriculture module. These modules are uninflated because for some reason this mod allows the full functionality of converters to work when uninflated, rendering Tundra Kerbitats and Duna Habitation modules woefully out-classed in portability, weight, etc., and being an SSTO, I need to save on space and weight. Any time I left the scene, whether it be loading a quicksave, returning from KSC or Tracking Station, or reopening the game, all of my kerbals decided to (T) pose and become #grumpy. This is a problem. After an hour of narrowing it down, it turns out it's because all of my converters except for my Recyclers all turn off whenever the scene is loaded again. Turning my converters back on brings them back to work, which also confuses me because I thought that whenever a kerbal (T) posed they MUST have a medbay treat them before they return to work. I guess that's broken too? This cannot be intended functionality since having any more than 3 converters makes re-toggling them all a pain, which is exactly what a real base would have--not to mention the kerbals constantly dying and all work being brought to a halt every single scene load. What's going on here? Maybe it's a mod conflict? Here are my mods from CKAN and my Game Data folder in case any other mods are here, and not in CKAN, besides EventHorizon.

Sadly, its Laythe I'm most interested in, and that was added in 1.10 like you said. I suppose I'll just have to deal with it for now, since I don't believe Stock Visual Terrain goes up to 1.8.1, and wait for Kopernicus to slowly make its way to 1.10. Thank you for the help though!

Maybe there's a way to copy chunks of the games core files into the older 1.8.1 install? Like maybe modifying individual planets files is not possible but a transplanting of "planet asset" or even "game asset" directories could work? Apologies for the limited knowledge

So I began playing KSP again recently after a few years of hiatus on version 1.10, and was amazed by the new textures SQUAD had added. Some of them look really good. It's to the point that going back is like playing Pong on Colecovision. Interstellar is my favorite movie of all time, and a random encounter with a steam screenshot led me to downgrade my current game to 1.8.1 to play EventHorizon, a spiritual successor of a mod adding in the Gargantua System from Interstellar. With the announcement that VABs on other planets would be available with the Colonization addition in KSP2, I have toyed with the idea of building a new "headquarters" on another world as a "new Kerbal home". There was no point to doing this in stock game, but after looking around at MKS Colonization, ULS Life Support, ExtraPlanetary Launch Pads, and noticing the SUBSTANTIAL amount of Delta V required to navigate the Gargantua system (Named Murph in EventHorizon) it has inspired me to build a new "home" and launchsite on Laythe! (I may need to look into Near Future Technologies though with these kinds of dV requirements...) I was only able to find a forum post discussing someone attempting this with version 1.1? I believe, and since there was a Unity version upgrade, that this would be incompatible completely. If I'm not mistaken, there was a unity update before the planetary textures were updated. Would it be possible to copy the Laythe (and other planets) textures over to a 1.8.1 install of the game? I don't believe 1.8.1 was before any Unity overhaul before the textures were added, AND a lot of mods are still on this version, so it might be a welcome addition to many community members! Thank you for helping me out with this