SpacedInvader

It's not that I was disinclined to believe you, its that the responses didn't seem to clearly indicate one way or another until your most recent response to @Valkyria90. Because we only had the information window to work with and not a better understanding of the underlying processes, and because of the discussion about the lack of proper background processing, it was easy to believe that it wasn't working correctly. When you clearly stated that the parts will be working in the background, even if the information window doesn't update, that changed the information we had to work with. I will still probably test it of my own accord, but at least now I know what to expect. EDIT: I will also point out that things don't need to change in order to break when moving from one version of KSP to another, so there were / are justifiable grounds to be concerned about broken functionality.

I will have just TST and KRASH in for that install. I will say though that I use SETI parts (specifically the procedural probe core, but others as well) on literally every probe I launch and don't have the problem with SETI parts.

I will look into those, though, unless they are offshoot mods that were split out from TACLS in the last year, they are not what I'm thinking of. I will have to research TACLS functionality some more before opening my mouth again, but I'm just wanting to be sure I don't go through the effort of building a vessel or station which relies heavily on recycling components to stretch the life support duration, only to find a bunch of dead kerbals when I come back to it because the recycling parts weren't working in the background.

I stand corrected then . That said, this brings the question @Valkyria90 asked into more importance. I know that in the past there were ways to make ships / stations / colonies self sufficient, or at least able to dramatically increase their resource duration through the use of recyclers, scrubbers, greenhouses, and other such parts. I don't know if these used any form of background processing, but I do clearly remember them working just fine while you were flying other ships, allowing you to set a long range vessel on its way and not need to return to it for some time. Is this still possible, or do all of these processes suffer the same limitations as EC?

Question in title.

Sure, might be a few though.

I finally had a chance to test TACLS installed as the only mod (with MM at least) and I'm seeing the same behavoir. The info window doesn't update correctly, but it appears that its not really relevant as the contents of the craft take precedence. I launched a small craft with solar panels and a year's supply of consumables and then fast forwarded until the EC monitor had shown -1 day... plenty of time to kill a kerbal, but jeb was alive and kicking just fine, so at least it seems to be an issue with the info window and not the underlying process.

Ok, so I did as requested and got the same result as before. Installing TST and removing IR did not fix KRASH. This was in career mode. Here is the NRE thrown in the log when I try to use simulate under these circumstances: NullReferenceException: Object reference not set to an instance of an object at KRASH.LaunchGUI.setLaunchSite (KRASH.LaunchSite site) [0x00000] in <filename unknown>:0 at KRASH.KRASH.OnLeavingEditor (EditorFacility facility, KRASH.LaunchSite launchSite) [0x00000] in <filename unknown>:0 at KRASH.KRASH.Activate () [0x00000] in <filename unknown>:0 at KRASH.LaunchGUI.LaunchSim () [0x00000] in <filename unknown>:0 at KRASH.LaunchGUI.drawRightSelectorWindow (SelectionType type) [0x00000] in <filename unknown>:0 at KRASH.LaunchGUI.drawSelectorWindow (Int32 id) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1) Here is the craft file: Google Drive Link Here is the KSP.log: Google Drive Link Here is the output_log.txt: Google Drive Link

Correct me if I'm wrong, but this is a newish (within the last 12 months since I last played) development. I clearly remember getting visual indications that my craft's EC consumption and production was working while I wasn't focused on it and warnings when it became too low / ran out. In the new system, how does TACLS track the power output of your vessel to determine if your kerbals are alive or dead? Does this same method carry over to the other consumables since they are all able to be produced as well as consumed? EDIT: I ask this last part because if it is not background processing the rates, it is also not polling the craft for its current status, allowing all rates to decline without any sort of warning, and when the information is checked, it says its last polled when I last visited the ship.

Going to add that I'm excited to see this making the transition to 1.1.x, being my favorite life support mod and all. That said, I've already run into a bug in that background processing of EC apparently isn't functional in the provisional build. I've got a huge number of mods, so I've yet to determine if the issue is with TACLS or with a mod conflict, but still something to be aware of.

No worries, take your time and get it right

So do you still want me to try pulling IR and re-adding TST?

I'm pretty sure there were these, but I'm not 100%: I do remember being worried that it was IR, PN, or TACFB as I consider all of those to be must haves. Please note that TST seems to have appeared in the CKAN export list above, but it was manually deleted from my GameData folder.

This going to be of somewhat limited usefulness as I've got well over a hundred mods running, but here is the current list: With everything here installed, KRASH works 100% of the time. As for TST, I was able to narrow it down fairly quickly to that as it stopped working after installing 5ish mods, so it was a matter of removing one at a time until it worked. I will say that TST isn't just a parts pack, but also comes with a DLL to let its telescopes function within the game, so thats where the conflict might have appeared.

I was experiencing a 100% failure rate (i.e. no sim at all while TST was installed), but I only had it in place for a short while, so I can't call it a large enough sample size to be certain.

Just a heads up, the new update seems to have removed the stockalike configs from CKAN. It sounds weird, but I've got no config folder anymore, and the configs are not applied (i.e. it didn't get moved), but CKAN thinks they are installed. Will need to manually install them until its corrected.

Moving to thread of mod conflict.

Haven't seen anything from the OP in a couple of weeks, wondering if the autostrut issue is being actively worked on?

Looks like you were right on both counts... Was a little worried because the error text made it seem like the contract was already deleted because of the error.

Good to know

I'll give that a try... didn't realize it was updated... is there anything special I need to do to preserve the contract?

So, just loaded up my save after updating to the newest CC version through CKAN and was met with the following error, along with the instruction to copy it and share it here: Exception occured while loading contract 'RemoteTech.RT_KerbinRelay_4sat': System.Exception: No ContractRequirement with type = 'CelestialBodyCoverage'. at ContractConfigurator.ContractRequirement.LoadRequirement (.ConfigNode configNode) [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfiguredContract.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 This contract was apparently working before the update as my last play session is when I accepted it.

This makes me happy!

I've been running into an issue with an inability to set station keeping fuel properly, as has been mentioned earlier in the thread, I get a notification that its been set, but then when I try to activated it, I'm met with a message that there is no fuel for station keeping. Based on the updates since those mentions, however, I believed the issue was fixed. I'm running version 1.3.2, on a stock KSP install. With what you've said in the above quoted text, I'm wondering if I should uninstall until you've had a chance to work on the stock compatibility for the mod?

Ok, that's what I figured after we had that conversation about pressure fed vs ullage last year, I just wanted to confirm. EDIT: Forum doesn't want to let me quote what I want to quote for some reason...