rudemario
-
Posts
44 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by rudemario
-
-
On 9/20/2021 at 5:21 PM, The Flying Kerbal said:
I can't help you with your question, but maybe you could help me with mine. Do you have a pink square appearing on or around your rocket as you launch it? Once the rocket reaches a certain height, the square flies off.
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.
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!
-
5 hours ago, IgorZ said:
I see some jitter in the video, but no log records can explain it. And I cannot reproduce it on my system. Checkout this video. I noticed, you're not using the latest KIS&KSP versions. It may or may not be the reason, I cannot verify the versions you're using.
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.
6 hours ago, IgorZ said:I also noticed you've managed to buy an RTX 3080, which I was hunting for more than half of an year with no success. Congrats!
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.
-
8 hours ago, IgorZ said:
KIS doesn't do anything that long after the action. It may postpone some things for a one or two frames, but definitely not seconds.
It's hard to say anything from the logs. Try enabling the verbose mode and capturing the log again. Check this out:
~3 minutes between the last KIS action and the other game action. Anything could happen in between, but we have no logs to get an idea.
All in all, I'd say we have a mods conflict situation here. I use KIS myself. Trust me, if there was a such significant freeze on each KIS action, I'd notice it and have it fixed. For the start, try a pristine game: no other mods except KIS. Then, start adding your usual mods until the issue shows up. Given what you report, I'd say it should be reproducible at the launchpad, which is easy to verify.
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)
-
7 hours ago, Gilph said:
That's actually good information that I wasn't aware of. Thanks
But, none of the above considers the bonuses problem, so just remember that if your drill, after bonuses, is running at 150%, you will need 150% of power and cooling per drill. That's the only thing that really got me. Sometime not levelling Kerbals to counteract the bonuses was my only option.
I have not used the pre release Constellation, but I am using 1.4 with the single bays for drills and manufacturing without any issues. Gameplay is roughly the same for everything else, and it's somewhat future friendly.
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!
7 hours ago, modus said:Yes, but in the prerelease there's Roverdudes own orbital shipyard that allows you to build ships in-situ...So you don't need EL or GC.
(but the choice is up to you ofcourse, not trying to tell you what to do
)
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!
-
1 hour ago, Gilph said:
The answer is, essentially, using the current version that only allows one resource per drill. You still have to watch out for various bonuses that may increase your drill output, which causes more heat.
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:
SpoilerMy job only gives me just a few hours some nights to play KSP or any game, that's if nothing else comes up, and I've spent the few hours over the last month slowly learning MKS's components so I can plan out a forward operating base to launch rockets into the EventHorizon mod which adds Interstellar (2014)'s Gargantua system, orbiting a black hole. I've spent many many hours learning the core systems and I don't really have much time, and I've already spent time learning how Extraplanetary Launchpads works, how long it should roughly take to build, how much MaterialKits I would need, how long it would take to mine 150,000 MaterialKits etc for a certain class of ship etc, how hab works, how the ranger stuff interacts compared to the tundra stuff. I don't want to spend another 15 hours over 2 weeks learning how Ground Construction was removed, if Extraplanetary Launchpads even still works with the MaterialKits/SpecializedParts patch, how the new balances to the resource gathering works, how the new WOLF system works, how 1.11's inventory system coincides with KIS/KAS. I prefer KIS/KAS's system but Roverdude deprecated support for KIS/KAS and have to relearn that system and find some other way to tether parts etc given how there isn't much documentation for the new 1.11 MKS system and other issues caused by 1.11, seeing how I'm almost ready to start playing my Gargantua mission after spending the last month learning how everything works and doing tests. It's simply because I've already invested so much time in learning so far and due to my limited hours I'd like to start playing MKS since I've only had the time to keep up with learning this version over time. (Also Extraplanetary Launchpads not working would be a problem since I prefer being able to build a rocket completely from scratch in-situ).
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.
-
2 hours ago, Kerbals_of_Steel said:
That's why the newest builds went away from having multiple bays on the drills. Stock thermal management is garbage.
KoS
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:
QuoteFor example, if an Industrial Refinery has one bay set to Silicon and two set to Metals, it will have a bay multiplier of 1 for Silicon and 2 for Metals. This means it will produce double the amount of Metals as it does Silicon.
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.
-
9 minutes ago, rudemario said:
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.
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....
-
4 hours ago, Terwin said:
Most USI converters slowly consume machinery and loose efficiency based on how much machinery remains.
If you have excess machinery, you can place an engineer in an assembly(?) module and have them re-fill the machinery in the converters with automated daily maintenance.
Alternately, you can turn off machinery consumption in the settings(effectively switching to MKS light).
At the very least turning off machinery consumption should allow you to verify that this is the source of your unexpected efficiency losses.
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.
-
14 minutes ago, dlrk said:
Do you have body fixed mode selected?
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)
-
4 hours ago, Grimmas said:
If you look closely, it's the first link on that page you linked. It's like a modpack with all of the USI mods and dependencies in one download. The latest pre-release is a 'beta' version from March and is the latest version you can get right now, short of cloning the individual project repositories and compiling everything yourself.
4 hours ago, Kerbals_of_Steel said:The Constellation download is ALL of the USI mods, including MKS, USI life support, half a dozen different rovers, sounding rockets, and a whole heap of other parts.
KoS
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.
4 hours ago, Grimmas said:You want to test this using KSP 1.11.2 and USI pre-release from here. MKS/USI-LS 1.3 and 1.4 as well as KSP 1.10 are already ancient history, you're on your own with those to be honest. It may well be that you ran into a bug that's been fixed already, in which case you'd have to backport the fix to the older USI-LS version if you want to keep using KSP 1.10.
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.
-
4 minutes ago, Grimmas said:
You want to test this using KSP 1.11.2 and USI pre-release from here. MKS/USI-LS 1.3 and 1.4 as well as KSP 1.10 are already ancient history, you're on your own with those to be honest. It may well be that you ran into a bug that's been fixed already, in which case you'd have to backport the fix to the older USI-LS version if you want to keep using KSP 1.10.
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!
-
On 5/6/2021 at 9:52 AM, Grimmas said:
I have a few:
1) Make sure you can reliably reproduce it in a stock (vanilla) KSP install (latest version) with the pre-release constellation from Github. This is a pre-requisite for the below steps. I would also try adding way more hab time than needed, try 2x or something.
2) As it is an issue with USI-LS you could try asking in the USI-LS thread.
3) If you are technically inclined you could try to debug the issue yourself. This is the fastest way to fix your issue but also the most involved.
4) If you are not technically inclined, or simply can't be bothered, then I would suggest opening an issue on USI-LS github repo. Attach screenshots, log files, reproduction steps, etc. But I would not count on a quick turn-around time.
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!
-
6 hours ago, Grimmas said:
Also check your config, because the perma hab time is exposed as a config variable.
I do see the code for freezing the timers - it's in ModuleLifeSupportSystem.cs around line 256. Haven't looked at it in detail but if you want to investigate for a possible bug I'd start there.
Edit: and another thing to try - does it work correctly when you unload the vessel (ie go back to the space center) and then time warp and then load the vessel later on?
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?
-
4 minutes ago, Grimmas said:
Quick question - are you sure that absolutely all of your converters/habitats/recyclers/etc/etc are all enabled? Just having them on the vessel is not enough for them to affect the timers, you need to click on every such part and enable the life support module through the PAW. Although I suspect that this is not the issue you're seeing, it doesn't hurt to check.
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.
-
1 hour ago, cinemagic said:
Help! my orbital Logistic window doesn't display anything, and when I open the window every window of other mods also glitched (cannot be clicked on).
For orbital logistic tab on kolonization dashboard, I can just close the dashboard, but for the the one opened from logistic modules, it stuck in center of screen. I can only close it by loading save or switching vessel.
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.
)
[Minimum KSP version - 1.12] Kerbal Inventory System (KIS) v1.29
in KSP1 Mod Releases
Posted
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.