• Content count

  • Joined

  • Last visited

Community Reputation

189 Excellent

About jd284

  • Rank
    Rocketry Enthusiast
  1. It's not, there's an infinite loop in the code if a module has less than two bay configuration options. (Well I suppose you could add a placeholder configuration which does nothing, to workaround the bug using MM though.)
  2. Build bigger warehouses. Your storage should cover 6 hours worth of production for each intermediate resource. Otherwise at least background production will not work correctly, and with even less storage larger timewarp is affected too, as you've found. No, not with a complete rewrite of the converter mechanics. It would also break many legitimate use cases of the current system. So just add more storage.
  3. Oh yeah, I realized that, but somehow I thought multipliers stacked multiplicatively. Since they don't, the hab-quarters obviously benefits from an external multiplier a lot more than hab-commons.
  4. Is there ever a reason to configure the Ranger hab to "Hab-Quarters"? It seems to me like that's always a worse choice, because the 16.8 months times the multiplier of 6.2 = 104 is already better than the 83.6 months of the quarters, even if you have no other multiplier parts, and if you do the multiplier is still always better. Seems like something isn't properly balanced, either the multiplier is too high or the quarters too low.
  5. I don't think it being a root part or not, or the order, even matters. I've had my space station changed to "base" because I docked a lander with Konstruction cradles. I wish the game wouldn't change the vessel type at all after launch, there's just no good reason for it, and it's never changing it the right way either. (I made a ticket about that too.) Or at least never override something I changed manually.
  6. Huh, so you did, but somehow neither online nor in cmdline client did the changes show up till now. In any case though, that version still works fine for me. Logistics works during converter catch-up and everything is well. Thanks!
  7. Sorry I don't see any changes since an hour ago, did you push them?
  8. Both commits throw an exception during OnAwake. Seems like maybe part.vessel is null there? EXC 22:02:48.868] NullReferenceException: Object reference not set to an instance of an object USITools.ModuleLogisticsConsumer.OnAwake () PartModule.Awake () UnityEngine.GameObject:SetActive(Boolean) ProtoPartSnapshot:Load(Vessel, Boolean) ProtoVessel:LoadObjects() Vessel:Load() Vessel:Update() BUT! If I move the initialization of lastCheck to FixedUpdate instead of OnAwake and use "vessel" directly instead of part.vessel, everything is fine! Logistics keep updating while the converters catch up, the container doesn't empty, and Bob is happy that we'll never again run out of coffee on the Moon. Thanks a lot for the quick fixes! I guess that means local logistics only work for parts with USI converters during catch-up though.
  9. 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...
  10. 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...
  11. Cool! Would you mind pushing the change to github so I can get this fixed without killing my framerate?
  12. 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?
  13. 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?
  14. @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?
  15. 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!