rudemario

Hey there, Igor! I hope all is well. I was wondering if you ever figured out what was causing this delay I mentioned back in May? I noticed that the ticket doesn't have any updates on it, so was wondering if maybe you made a discovery on it but hadn't documented it. I ask because I'm at a point in my save now where I'm using KIS/KAS a lot, and like we noticed before, placing/attaching etc has a large delay (and this delay seems to increase for me with additional mods from the 500ms to 2 seconds ) It's becoming a real pain. I understand I'm making it worse, of course, with the additional mods and all that, but maybe an improvement in the base 500ms jitter might solve my issue as well, considering it's the core of the issue. Also, did you ever get that Graphics card you were hunting for? Hope so. I can't imagine it's easier for you now with the Holiday season upon us. Did the EVGA Notification list treat you well? Thanks Igor! Just was wondering, don't mean to be a bother about the issue.

Sorry for the late reply. I'm not sure what you mean. Could you provide an imgur video clip or screenshot link? Maybe I could help you out better that way.

Hey there! I know this probably isn't the best place for this question but I only get this issue with Astronomer's. Using reflections with TextureReplacer, only a portion of the clouds show up. I'm not sure how reflections work in KSP, or how they interact with the game. Is there some atmospheric FOV setting that the shader involved in cloud rendering uses in Astronomer's maybe? Limiting reflection FOV render range for performance? Maybe these reflections for Astronomer's are just loaded through Scatterer and the problem might actually lie with some setting in there? Any ideas at all would be really appreciated while I try to figure out a fix. Thanks so much!

Hey there! I was wondering if anyone knew why my Astronomer's Visual Pack clouds aren't fully showing up in my visor's reflection? Is this a known issue? Would anyone know of any way to fix this? Thanks!

So I'm still playing on a supported version and have encountered a strange issue...maybe I'm just stupid. For some reason, when I freeze a kerbal, my EC goes wacky. After taking the 3000 to freeze the Kerbal, the regular drain rate (which should be about 10 per minute iirc) is at 0.03 EC (normal so far). After exactly 11 seconds, the drain rate suddenly spikes to 25 EC/s and increases steadily for the next 6 seconds up to 60 per second, before reverting back to 0.03 EC drained for the next 11 seconds. https://imgur.com/a/lAFbgAX Is this a known issue perhaps that I missed when going over the thread? Or is this likely caused by some incompatibility with MKS or Kopernicus or something? I'm willing to bet it's something I caused, so I made sure to try with and without BackgroundProcessing enabled and made sure everything was installed correctly. Just wondering if this is something that's been seen before or if it's something new and strange. Thanks!

That's okay, I appreciate you looking things over and confirming it's nothing obvious. I am using KSP version 1.10 and using a compatible KIS+KAS version for two reasons: 1, I built a modlist to explore EventHorizon's Gargantua system which is quite outdated in terms of official support but I have to explore since it's based off of Interstellar (2014)'s Gargantua system, and boi, the views from the planets orbiting the black hole are really something. 2, I prefer having KIS as my main implementation of the inventory system for now, and man did it take a while to assemble all these mods and learn them (MKS by Roverdude, I'm looking at you). In regards to your video, I had stuttering on place, not on grab. That could explain the reason things look so smooth for you. I was spinning the camera and clicking to place during my spin to show the jitter but I couldn't notice it in your video since you stopped moving the camera when placing. I tried watching the MET time in the top left and I think it did look like there was some delay or deviation from counting perfect seconds. I seriously only believe I was able to grab one was because here in Canada, the absolutely horrible reputation Canada Computers was offering the ability to backorder GPUs around the holiday months. They were also forthcoming with information about how many of each unit they've received in the last few weeks, and which ones they were having regular stock come in of. Originally I wanted a ASUS TUF 3080 since it happened to have the best cooler and best looks (to me), but that one was very rarely moving since it was a lower class SKU. The more expensive SKUs, the ones with factory overclocking and fancy RGB and better binning were what happened to be coming in stock regularly. I believe one company, might have been Asus, straight up cancelled manufacturing indefinitely of their MSRP cheapest 3080 and everyone went ballistic over that decision, since they had preorders going back months. I switched my preorder for the $200 more expensive EVGA FTW3 Ultra card, which was their highest sku, and even though I didn't like the looks of it very much I considered it the price to pay to get one (this was still MSRP of the card, just more money for the higher SKU). I waited 3 and a half weeks and I got the call it was ready to pickup. The RGB strip actually looks really cool and grew on me, it looks really high-class, not tacky at all. The 5600x on the other hand, man, that one took a month and a half to come in. But since then, Canada Computers at many locations have cancelled their backorders I believe because of lower stock refills. Longer waitlists with no guarantees probably doesn't look good for business. If I had to order a card like everyone else does by watching internationally exposed online stores like Amazon etc I would not have been quick enough to get one at all. Seriously, Newegg removing captchas and shopping cart reservations for a few minutes? I heard that for the US one of the surefire ways has been EVGA's step-up program, where you buy a lower tier card and they refund you the difference when stock is available to upgrade and you've got the cash. I'm not sure if they've continued doing this through the 3000 series shortage, but it was available to do back in November-January. Good luck on the hunt!

Are you not supposed to be able to freeze kerbals when using heat requirements on planets? Kerbin, for example, on the launchpad, has a temp of 31 degrees celsius. In space this isn't a problem, showing -81 or so degrees celsius. No matter how many radiators I throw onto the cryo pod I can't get the temperature of the part to decrease even the tiniest bit below 31 degrees celsius Is this a limitation of KSPs heat handling or a feature of the mod? I figured it would just be harder to keep Kerbals frozen on certain planets, not impossible. It seems that unless the planet has an ambient temperature below freezing, there is no way to reduce that. Like even an EC powered refrigerating function.

So, I tested out the difference in delay between a fresh install and my modded install since I wasn't able to get the delay to speed up after adding half of my mod list and figured I should see the difference between a clean slate and a modded one. I downloaded a new version and used a new sandbox game. I recorded a video and also got a log after toggling verbose mode and restarting the game before running the test in case verbose mode needed a restart to activate. <Unmodded> Video: https://i.imgur.com/buIqgMT.mp4 Log: https://www.dropbox.com/s/t1cqyjeg0nis7qp/Stock%2BKISKAS KSP.log?dl=0 Then, I did the same for the modded game. <Modded> Video: https://i.imgur.com/v8VU7OF.mp4 Log: https://www.dropbox.com/s/keapch4xjiu92d2/Modded KSP.log?dl=0 You can notice that the base game still has a delay, so I'm not sure what's up with that, but I understand that the delay is likely the expected delay and is considered normal, then. The modded game has more noticeable delay, but I won't speculate as to why until I figure out which mod adds the delay, but knowing that the delay is still present in the only KIS+KAS install of the game at least reassures me some delay is supposed to be present.

I've tried searching the thread and the Github issue list open and closed tickets but I can't find any mention of this. Has this been encountered by anyone before? I have an issue where when I drop or attach any part stock or modded the game hitches/stutters/freezes/lags for anywhere from 1-4 seconds. https://i.imgur.com/44JE9qY.mp4 Could this be some sort of conflict or is this a known issue? Thanks for the help! (KSP Log in case anyone wants it: https://www.dropbox.com/s/qg44dio0rlbcz8x/KSP.log?dl=0)

Ah, I see, and that's a good point. That's not something I would've noticed in my testing, as I haven't delved deep enough to explore bonuses. I understand why they moved away from the Seperator decision, then, since when combined with other systems it produces strange and detrimental consequences. Maybe I'll look into upgrading to at least 1.4 if things haven't changed too much. Although not even the pre-release constellation fixes the bug I was having earlier in the thread where Ranger parts when activated were having their total hab timers decrease instead of just the kerbals timers, meaning that I wouldn't be able to use those parts to make Kerbals have indefinite hab stays (over 50 years grants infinite stay, but as the hab total time value itself decreases, this pushes the total below 50 years and thus the vessel no longer has >50 years, removing the bonus. Also, it doesn't decrease 1:1, 1 year is like 20 years of hab for some reason). Thanks, I appreciate you sharing your experience with it! I saw bits of that, but wasn't sure how long it would take to learn Roverdude's Konstruction variant of shipyards and I wasn't sure whether or not it allowed true in-situ building. As far as I was aware, I believe there was a set of components that always had to be shipped from Kerbin, much like how GC required you to choose a blueprint and ship it over. I think it would be cool to largely no longer use Kerbin altogether except for VAB and SPH building. If the systems aren't that complex or aren't bleeding edge enough that they have little documentation to understand then I'd look into giving it a shot. Not against it, just would like to start playing instead of learning so much, and I've almost finally learned enough to start, lol!

MKS version v1.3 was the "current version" for 10 months. Does this mean drills were unfunctional for 10 months on the newest version? Based on my testing that doesn't turn out to be the case, which means that's not the answer. It turns out that Roverdudes comments about the drills are true and are not anywhere on the Functions page on the wiki. It appears that when you activate a second separator on the drill, it increases the thermal output to just the perfect degree to limit yourself to the same resource throughput as before. So if I was mining 9 dirt per second, adding a second separator of dirt will bring me down after the heat builds up to approximately 9~. This was only confusing as this was not mentioned on the wiki. It makes perfect sense that the Drills were previously setup in this way to simply allow you to split throughput between 5 resources by having a bigger drill, but the amount of resource mining is already chosen by how big of a drill you chose for the mission. Simply activating one bay is enough. This does not appear to be a bug or broken at all. It's just un-intuitive and not mentioned. Drill throughput is chosen by the drill size and adding more separator bays just splits the output between the amount of resources chosen. It just looks like heat goes crazy by accident, when it's a feature as a way to limit throughput. As to why I'm not using the latest pre-release: If something is a bug I don't expect support for it, I just want to know if it's intended functionality or not so I can understand MKS's mechanics so I can have fun.

So, the most productive drill setup would be 1 drill with 5 bays, but the thermals accidentally and unintentionally limit the performance, meaning 5 drills with 1 bay is more efficient? Edit: Basically, I'm just curious what the most or more efficient setup is for drills

I'm confused about drills and efficiencies. I searched the thread and found a user from a while ago that was using mulitple drills and noticed that if all bays were drilling versus just one of the bays drilling, his temperature was not manageable and this was not reflected in what the parts were saying for output. Roverdude replied this was normal and said that multiple bays could be used but the output will remain the same depending on how you want to split it. The wiki says this on Functions: This seems contrary to what RoverDude mentioned. If the output equal no matter how it's split, then the output would be 0.333+0.666=1. So, what results in more resources? 5 Drills with 1 bay set to Minerals and only that one bay active Or 1 Drill with 5 bays active on Minerals. Thanks for the help!

Does anyone know if it's possible to somehow reduce the cloud layer from space, and not change anything else like what a planet looks like from the ground or while flying into it? The one problem I have is I can't see where to land on Laythe! What looks like land isn't land, and I've had to look up the biome map and find a little piece of land way at the bottom and use that to extrapolate potentially where the piece of land I want to land is on. Anyone know how to turn down the cloud layer from space and make the ground more visible without severely altering the sunrise/sunset/cloud characteristics down below? Thanks!

Just more testing on the issue. Here, you can see, after 17 years of real MET time, the Hab number in location 2 hasn't moved an inch past the 55 years of hab it started with now that I've switched all of the converters to Kerbitat 3.75s. Seems that Kerbitat's work fine, the converters affected are the Ranger line.

Furthering this point, I noticed that on my 3.75m Kerbitat, if I enable it, my hab time doesn't decrease, like it's supposed to. So with the Kerbitat converter the bug doesn't happen, but with the Ranger Habitat module converter it does...hmm....

So, I decided to give this a shot. I turned the Machinery Wear Amount from the 0.000001~ number to 0, turning it off. Then, I launched my test again, making sure every converter was full with the 200 machinery required. As you can see in position 1, it has been zero days and I have 72 years and 313 days on this ship. After fast forwarding a bit after launching and turning all converters on: As you can see here, it's been 3 days in the MET timer, and in the life support status we are now down to 72 years and 298 days. That's 15 days of Hab in only 3 MET days. As you can see, with Machinery wear disabled, my machinery is still at the 200 value, due to no wear. So, this issue is with the parts themselves and not with the machinery wearing.

As far as I'm aware it doesn't make much of a difference when you're measuring specifically body-centric calculations like what happens when you're near the surface of the planet, and it removes the disconnect from the cross and the trajectory line, but no, I don't have it on. For example, here is the screenshot with it disabled: And after I enabled it to show: Any other ideas why? I appreciate the help.

Does anyone know why when I plan an Aerocapture maneuver on Laythe with my SSTO and I get the X to be directly on a spot I want on my manuever, it moves later? While set to Prograde in the descent profile at 0 Degrees it changes to be completely off mark when I'm just about to enter the atmosphere. I'm still facing prograde; I don't know what's going on. Am I missing something? X marks the spot here: X doesn't mark the spot here: veers off way before my target despite nothing changing and me facing the correct direction I had plotted for reentry (0 degrees from prograde)

Thanks for clearing things up guys, I appreciate it. The link was so small and wasn't highlighted in the main mod headings I didn't realize it was a thing. So, I went ahead and conducted some testing. Here, you can see I am on KSP version 1.11.2 These are all of the mod versions I've tested so far: As you can see I've tried the 1.3 versions 1.4 versions, December's Constellation, and March's latest pre-release Constellation. 1.3 and 1.4 were on 1.10, and both the December and the latest pre-release March Constellation was tested on the above KSP Version 1.11.2 as recommended to me. I conducted the test as follows: 1. Download a new 1.11.2 version from Steam. 2. Launch the game. 3. Close the game, add the Constellation pack. 4. Re-open the game, start a new sandbox save. 5. Build a ship using a 3.25 Kerbitat, 4 Inflated Ranger Habitation modules configured to reach 72 years of Hab, a recycler, 3 Kerbals, 2 Nom o Matics, 4 Gigantor solar panels (Craft file will be in save file I am uploading) 6. Send vessel to launchpad and Set Orbit cheat into Orbit around Kerbin. Now, from here, I will outline a new finding I noticed. See this photo here and the three areas of interest: This is the result when no converters are activated. As you can see, in number 1, it shows I warped 58 days and 2.5 hours from mission start. In number 2 you can see the Vessel Hab has 60 days and has not counted down one single day, and then in number 3 you can see the Kerbals after warping have 1 day and 3 hours left before their 60 days are up. This is all normal and expected behaviour. This was a new finding. I figured I'd give it a shot, and so it turns out that there's something going on with the parts specifically, since everything is fine when no converters are turned on. More on that later. So, now onto the normal issue at hand. I will revert the launch and re-set my orbit, and then activate all of my converters, solar panels, nom o matics and my recycler, etc. See here: Here, you can see a "clean slate" before I begin timewarping. This time, all 4 of my Rangers are turned on, and so is my Kerbitat, granting me 72 years and 155d of Vessel Hab time. Also, because this value is over 50 years, both Bill and Bob now also have indefinite time. Now, based on what we saw in the last photo, we should see the Vessel Hab time in location 2 not decrease a single day, and the timescale should remain 1:1 with the MET timer in the top left. So, what happens when we fast forward? Here: Here, you can see that we've fast forwarded 1 year and 70 days in the MET timer in location 1. However, in location 2, it says we've fast forwarded just shy of 20 years. In location 3, however, it still states we are indefinite. Our hab timers for our Kerbals should stop them from succumbing to home or hab. So, first issue. Our 1:1 timescale is gone. Hab is decreasing when it didn't before now that we've turned our converters on. Okay, now what happens when we fast forward some more so that the hab timer falls below the 50 year mark? So, now, we've fast forwarded 1 year and 102 days. Our Vessel Hab time has dropped to 49 years, that's a total of 23 years in only 1 year and 102 days. Now our Kerbals hab/home timers have decreased beyond 50 years and are no longer indefinite, seen in position 3. This could mean that the Vessel Hab time itself is decreasing and not the Kerbal's timers? This would explain why the Kerbals are being brought below the 50 year mark and losing their indefinite status even if the code mentioned earlier seems present and functional. So, 1 year is 20 years in the hab time with converters on, even when with converters off things behaved normally? And our Vessel Hab Time capacity itself seems to be lowering, which is why our Kerbals are losing their indefinite status? So, I decided to revert and try fast forwarding with different combinations of converters being turned on This is what I noticed: 1. I noticed if I turn on 0 converters the hab time at the Vessel Hab Timer (location 2) doesn't move at all and the Kerbal timers count down like intended. 2. If I turn on one hab-common converter then the hab time begins ticking down slowly and the kerbal timers go faster? 3. If I turn on one hab-common converter and one hab-quarters converter things reach a point where the timer ticks down faster than the days in the MET timer in the top left (faster than Kerbal days) This all leads me to believe there might be an issue with the Ranger habitat modules? Or something wrong with converters nobody has noticed over the years? This issue is present on MKS and USI 1.3, 1.4, December's Constellation and March's Constellation on KSP Versions 1.11.2 and 1.10.1. Could this be something that's been missed out for a long time? Because on a freshly downloaded 1.11.2, with a fresh deployment of March's constellation with no other mods, and a new sandbox mode with a new ship built from scratch the issue is still present. Here is a link to a dropbox that includes the craft file as well as a KSP.log of me turning the game on, launching the ship on the pad, launching the ship into orbit with the Set Orbit cheat, turning on all my converters and fast forwarding until indefinite disappears. https://www.dropbox.com/sh/qdxbyjs9n8ablt5/AADdEPo_-DoGn-nlqN1iCJWba?dl=0 Something is going on here.

I had no idea there was a separate branch of MKS called "Constellation", it's not on the https://umbraspaceindustries.github.io/UmbraSpaceIndustries/ page anywhere so I wasn't even aware it was a separate thing. I thought the mentions of "Constellation" was a name denoting a new version, similar to Androids approach to naming their versions KitKat, Marshmallow, Nougat, etc. What is Constellation? I thought MKS was already a pack of relevant mods. I see Constellation goes back many years, is it some form of definitive bundle of mods? How does it differ from MKS? Thanks!

1) I was able to get it to reliably reproduce on KSP version 1.10.1 with MKS 1.3.0 and USI-LS 1.3.0. I did not yet test it on 1.11, but will. 2) USI-LS does not activate the home/hab feature without MKS installed because there are no ColonySupplies or converters with which to consume them to roll back those timers. That's why I posted in the MKS thread. 3) I am not very familiar with the language this is written in, neither am I very good at code in general, but enough that I can understand that the feature is very clearly present on the line you listed in the source. Another observation I noticed was when the hab time remaining ticker counts down, for every 30 days of the in game T- mission clock, the hab time remaining ticker goes down years worth. At an orbit of 84 km it advances 2-3 days for almost every orbit, and I believe an orbit is only a few hours at that altitude. This was also confirmed on bone stock KSP so this doesn't have anything to do with switching to Earth days and not Kerbin days. So, I have a question then, as this looks like a bug that might never get fixed since it's in an outdated version. Does the 1.11 release 1.4.0/1.4.1 of MKS work for KSP 1.10.1? That would solve all of my issues I believe once I confirm this is no longer on issue on 1.4.0/1.4.1 of MKS. (Event Horizon is throwing a wrench in being able to update no-brainer style) Thanks!

I tried taking a look at .cfg file since I already posted my config in my second post up above, but to no avail. Everything is set as it's supposed to be, but there's also a note that this does nothing for existing saves. And here is the screenshot of the in game GUI settings menu from a few posts up: As you can see, things are normal here. I decided to try out setting everything up, heading to the tracking center and time-warping, and then coming back. When I time warped and displayed the Life Support Status window in the tracking center it didn't show the hab timer going down at all, so I thought it was a success. Then, upon loading up the game, after rejiggering itself and catching up to the current time value it gave me indefinite days and then dropped it for some reason. Then, for some reason, indefinite came back, but only for the home timer, not the hab one. This definitely doesn't look like intended behaviour. Thoughts?

In order for me to reach the 50 years and 95 days my ship has I needed to turn on every single habitat. If I missed even one the highest I could have gotten was 44 years. I designed it this way intentionally. I also ensured my nom o matics were enabled and loaded the craft up with batteries. If you watch the video linked in the post (here), you can see the ship being fast forwarded through 200 days or more and because everything is turned on none of my resources drop. If I had even one habitat turned off I wouldn't have reached the 50 years and 95 days I had before I started the video (closer to 44), and I wouldn't have reached the 50 years and 6 days before I hit the record button and fast-forwarded.

I can't suggest anything useful specifically to you, but while you're waiting for a response, you can copy and paste your KSP installation into another folder, making a copy of it, and then remove the mod folder for each mod one by one in order of "most changes/most advanced" and start the game each time to rule out if it's a mod conflict. You don't have to be careful or worry about anything, since you're not modifying your normal game, just this copied one. Make sure to launch from the copied KSP folder's KSP.64.exe launcher to be safe.