jd284

Well, I tried initializing lastChange to vessel.lastUT, but that way ModuleLogisticsConsumer was done catching up before the converters even started running, and when they did the container emptied with no logistics to fill it back up. So there's still some desynchronization between converters and logistics somehow. At least in my case it was sufficient to slow it down to 1/20th of the catchup speed with the following: if (lastCheck < ResourceUtilities.FLOAT_TOLERANCE * 10) lastCheck = vessel.lastUT; var planTime = Planetarium.GetUniversalTime (); if (Math.Abs(planTime - lastCheck) < LogisticsSetup.Instance.Config.LogisticsTime) return; lastCheck = Math.Min(lastCheck+ _maxDelta/20, planTime); But that "/20" there is pretty arbitrary and probably only worked by accident. But persisting the field should be about equivalent to setting it to vessel.lastUT so I don't think that on its own will help. There's still the problem with converters only starting to run some time after ModuleLogisticsConsumer gets done with its catch-up (at least without that "/20" in my case). Another idea might be to use the actual converter's lastUpdateTime property if that is somehow accessible. Since if you get the delta time using that, you would definitely be synched to converters. At least for parts that have ModuleResourceConverter_USI...

Yes it fixed it logistics not running during catch-up, but had the same bad framerate as when I was having it check every tick. I believe it's now running up lastCheck from 0 to the current time and performing logistics every tick along the way. And then after a few minutes my framerate got better again, I guess it reached 16014157 then. So it's not quite fixed yet. I think you should probably add something to set lastCheck after loading. Though just initializing it to Planetarium.GetUniversalTime() broke logistics again for me...

Cool! Would you mind pushing the change to github so I can get this fixed without killing my framerate?

The tank capacity on both vessels is good for about 24 hours of production. It empties during catch-up and doesn't get filled again until catch-up is completed and normal physics resumes. The exception spam went away on its own for some reason, so disregard that. I also added some more info to the print statement I have as first line of ModuleLogisticsConsumer.FixedUpdate, and I think I found the issue. The FixedUpdate function is called with Planetarium.GetUniversalTime() already set to "now", not the time it's catching up. For instance, in my save the vessel in question has lastUT = 15879278 whereas now it's 16014157. So I'd expect it to step through this time interval (about 37.5 hours?) during catch-up. But the first call to catch-up is with Planetarium.GetUniversalTime()=16014156. So the logistics only get called every 5 seconds of "real time", which probably corresponds to days and days of catch-up time. As an idea based on this I just removed the "lastCheck" guard clause so that logistics would run every tick. And lo and behold, the container didn't empty, logistics worked, and everything was fine. It's not nice for the framerate though, I suppose. So is there a different time it should be checking instead of Planetarium.GetUniversalTime(), for it to work with catch-up where 5 seconds correspond to an eternity? Some other timestamp or a flag that allows logistics to run every tick during catch-up but only every 5 seconds during normal operation?

This seems to have gotten overlooked, so I wonder if I could get input from someone else if they have these same issues with local logistics during catch-up not working or if it's just me. And if you have these issues, do you also get the BaseConverter_GetDeltaTime exception spam in your log?

@RoverDude, I found a problem with scavenging and background catch-up mechanics of converters. Basically, ModuleLogisticsConsumer doesn't operate at all during catch-up so containers run dry and aren't filled from other nearby vessels until physics kicks in after catch-up. For instance, I can watch my kontainer get drained of its 20k MetallicOre in about 5 steps (which are 6 hour intervals right?), and then it stays empty for a few seconds. Then right after physics kicks in again, it fills up to about 12k MetallicOre. Meanwhile the other vessel's kontainer is full all that time until physics kicks in. I think the problem is that ModuleLogisticsConsumer does its work in FixedUpdate, which isn't called while physics is suspended during catch-up. At least, when I tried adding some debug print statements, FixedUpdate didn't get called at all until physics kicked in, and then only with the normal physics deltatime. I also got a lot of exceptions like [RESOURCES] - Error in - BaseConverter_GetDeltaTime - System.NullReferenceException: Object reference not set to an instance of an object at ResourceUtilities.GetMaxDeltaTime () [0x00000] in <filename unknown>:0 at BaseConverter.GetDeltaTime () [0x00000] in <filename unknown>:0 which may or may not be relevant... and if they are, what to do about them. The only other reference I found was in the KPBS thread, but I don't use KPBS. Is there anything I could try?

I'm playing RSS and on Moon (which uses the Mun template) I had 13.5 fps before, and 20+ fps with PQSMod_VertexVoronoi (Moon already had PQSMod_VoronoiCraters). It also didn't affect my base in any way, so I'm keeping this change. Thanks, this really makes a difference!

Roverdude fixed that bug in USITools a few versions back. Looks like it snuck back in.

The volume of the largest KIS container you have must be able to fit the part. So if you add a larger KIS container, you can build bigger parts. OSE itself has no limit. (It's no problem if the container isn't empty, then OSE will stall the construction until there's enough space.)

Thanks, the combination of airbrakes and the inflatable heat shield finally worked. Although it took a while for me to figure out that I was meant to use it as a parachute and not as heat shield... Still used way too much fuel, I didn't expect Mars landings to be so expensive. Any resupply missions will have to be planned rather more carefully.

I have the same thing on all vessels using the 2.5m cradle. It's only once a second though so it's not that bad and doesn't seem to cause any lag.

@Antonio432, you don't need a special config. Generally instead of bringing lots of supplies you'd bring enough Fertilizer and as many Nom-O-Matics as you need for your crew, for trips of more than a month or so that's usually less mass than the raw supplies you'd need instead. Also recyclers, you need one good recycler like the RT-5000 to set the recycling cap and then add small recyclers (RT-500) until supply usage doesn't go down anymore (about 1 RT-500 per crew, which is 10x lighter than spamming RT-5000). For hab time, yes you'll need to spam hitchhikers and cupolas. Or otherwise you need another part mod that is not just compatible with USI-LS but provides the hab mechanics as well. At the moment I only know of MKS (of course) and KPBS for this: I use MKS though so YMMV with KPBS, for instance I'm not sure if they have recyclers as well.

Does anyone have any tips on performing a Mars landing (only RSS, no RO) for a Mars base (~8t payload). It seems parachutes are useless because the atmosphere is too thin and even if I hack the minimum pressure they are destroyed because I'm still too fast. The re-entry itself is no problem, there's barely any heating. However there's also no appreciable aerobraking, even in the lowlands I still go 2000+ m/s when hitting the ground. Shallow entries don't seem to help since the atmosphere doesn't do anything until about 15 - 20 km altitude anyway, and when I go in shallower it has me leaving the atmosphere again. On the other hand when I attempt to brake using retro-rockets, the ship flips and becomes uncontrollable. Basically, not enough atmosphere to do any braking for you, but too much atmosphere to brake the hard way. So does anyone have any successful designs for landing and/or other tips?

That's true only for the fixed radiator panels (strictly speaking any radiator with "parentCoolingOnly = true" in its config). The MKS ranger heat pump as well as the folding radiators can pull heat from the entire vessel, up to each part's heat transfer capacity and their own maximum cooling capacity. The problem with cooling drills is a bug, I think, see issue #1198. Looks like it should be fixed in the next release.

1) You need to install Unity or a Mono 3.5 development environment like MonoDevelop. This is way out of scope for this thread, try reading the general KSP modding threads, wiki pages and other resources. Or petition RoverDude to make the blacklists a config option. 2) Yes the numbers are per separator, so with 5 of them (whether for the same resource or different ones) there'll be 5x as much output, heat, and EC usage. For heat, note the MKS heat pump ranger part, it's very powerful for landed bases and the VAB stats are way misleading.

I'm not sure about most iron being oxidized, that's true for iron close to the surface but I'd expect that most iron will be in planet's cores, where it's not oxidized but alloyed with other metals such as nickel. And yes, the game seed is basically a "universe number", so changing that moves you to a different universe with different resource distributions. If you find one you like it's easy to keep the same universe by changing it back in the savegame.

Any way I can help debug it? I have Konstruction 0.1.11 and USITools 0.8.16 from the 02/24 constellation, and only see the "EVA Items" from KIS, and then Rovers / Life Support / Containers / Kolonization / Logistics / Manufacturing tabs. No Konstruction, and the parts only appear when switching to module or tech level filters in advanced mode. So it's not that big a deal since I can still get the parts, just a bit more tedious.

Well, it was only half successful. Now I have the Rovers tab, but lost the Konstruction tab with the cradles in the process...

Huh. I was going to say that I did because I checked the CCK.version file and saw 1.2.2. But because the versions are so similar I saw the KSP_VERSION instead, which was also 1.2.2 ... silly thing. Thanks.

Did anyone else lose the "Rovers" tab in the VAB? I just wanted to add some sweet Karibou wheels to a lander but there was no tab. I could find the parts using the module filter for wheels, so they're still there and accessible, just no rovers tab... (using latest USI constellation). What could be causing this?

It prevents a ground base from sliding slowly, by forcing its velocity to zero even with small forces acting on it. It's not strong enough to stop a Kraken attack however.

Generally you just let the fuel processor fill a container, and then move the full container to the transporter. Just like you'd do in real life, you wouldn't shovel uranium pellets without a radiation suit... You can move it using KIS, docking ports, Konstruction equipment, etc.

That's actually a good idea, I'd like if it worked like that. Though on its own that wouldn't really change the gameplay, since they'd be tourists either way. There'd have to be a third setting for running out of both hab and supplies to really make a difference. Also the infinite hab mechanic should be suspended while out of supplies. As a side note, personally I'd actually want to be able to set it like this: Supplies run out: tourist during grace time. Grace time runs out: Dead. Hab runs out: tourist during grace time. Grace time runs out: Mutiny with vessel destruction. That seems the closest to what I would actually expect to happen.

Efficiency parts boost other parts exactly by their mass (with machinery). All efficiencies are based on part mass, so if an efficiency part is 10% of the part it's boosting, it will also boost it by 10%. Pretty simple and predictable actually! My first guess would be insufficient MetallicOre available, or Metal storage capacity.

This is really a topic for the USI Life Support thread, but it's probably this bug. It's only a display issue though, it incorrectly says expired during the grace period. Your guys should not be tourists though and work normally until the actual end of the grace period.