linuxgurugamer

I don't support Kerbalism, it changes too much in the game Sorry

I have no idea, how about a log file?

Then try the earlier one I did for 141

You can try these two, I wasn't doing this for 1.3.1: https://github.com/swilbur/StationKeeping/releases

For those of you who are having the problems with the Lossless mode, I need to know the answer to the following question: Are you using the Lossless mod and then using the KSP Phys Warp as well? I'm not sure the two can/should be used together, I have a working version beta here for you to try: https://www.dropbox.com/s/b9ugo7mygij95wn/BetterTimeWarp-Beta-2.3.10.2.zip?dl=0

Are both command modules? Even if you had to add a small patch to fix that, it's more efficient to have one patch to remove the modules from an extra part than to create patches for all small command pods. One thing I didn't think about was the Mk1 & Mk2 cockpits, which are designed for airplanes rather than spaceflight. Either way, your decision, but could you include it as an optional patch (use PatchManager for that) if you don't incorporate it directly?

New release, 1.6.8 Fixed bug causing some parts to not be destroyed Removed max version from .version file Removed some log spam For people who haven't yet updated to 1.5.1, you can get a compiled version of the mod for 1.4.5 at the following URL: https://github.com/linuxgurugamer/TacSelfDestruct/releases/download/1.6.8/TacSelfDestruct-1.4.5-1.6.8.zip

I just looked at the log, which actually shows the error: InvalidOperationException: Collection was modified; enumeration operation may not execute. at System.Collections.Generic.List`1+Enumerator[Part].VerifyState () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1+Enumerator[Part].MoveNext () [0x00000] in <filename unknown>:0 at Tac.TacSelfDestruct+<DoSelfDestruct>c__Iterator0.MoveNext () [0x00000] in <filename unknown>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) [0x00000] in <filename unknown>:0 Sorry, I was busy yesterday getting ready for my stream. I appreciate what you did, both in posting the log and recompiling it to test your fix

Late at night, when I updated my previous message, some lines got deleted. I was made aware of this by some viewers in my stream, go back and read the previous message before yours, I've updated it

You hit the nail on the head, thank you. What's happening is that the next line does an explode, which destroys the part and messes up the enumeration. Unfortunately, what you did, while working, is subject to the same issue. The correct way to fix this is to either do another while loop, similar to the one above: while (vessel.parts.Count > 0) { vessel.parts[0].explode(); // Do a yield here in case something else (ie: Bob's Panic Box) needs to react to the part exploding yield return null; } I could also have done this: // Explode the rest of the parts for (int x = vessel.parts.Count - 1; x > 0; x--) { vessel.parts[x].explode(); // Do a yield here in case something else (ie: Bob's Panic Box) needs to react to the part exploding yield return null; } Either of these work safely, without any issue with parts disappearing from an enumerated list. I like the first one, it's a bit more efficient

(these line got deleted) I was coming back to mention that I was wrong. However, once stream viewers got me straightened out, I then realized that something else was odd. I understand that these experiments are intended to replicate the real-world experiments done in Mercury and Gemini, but it doesn't make sense that he includes a patch for only a few 1 and 2 person command pods. There are a lot of other mods which have 1 & 2 person command pods, so I wrote the following patch to add the experiments to all 1 and 2 person command pods. It's not too efficient, and I wrote it with the idea of not deleting the current patches, which is why there are three lines deleting the existing modules. If this patch were to be included in the mod (giving my permission now for that to be done), then those three lines can be deleted along with the existing individual patch files in the mod // Adds the Kemini_Module to all command pods with crew capacity of one or two @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0],#CrewCapacity[<3]]:NEEDS[NehemiahInc]:AFTER[NehemiahInc] { // First delete any existing modules, then add them back for all -MODULE[Kemini_Module] {} -MODULE[ExperimentStorage] {} -MODULE[ExperimentStorage] {} MODULE { name = Kemini_Module abbreviation = Kemini Science Experiment minimumCrew = 1 NE_LabEquipmentSlot { type = KEMINI } } } @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[1]]:NEEDS[NehemiahInc]:AFTER[NehemiahInc] { MODULE { name = ExperimentStorage identifier = Kemini 1 chanceTexture = false type = KEMINI } } @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[2]]:NEEDS[NehemiahInc]:AFTER[NehemiahInc] { MODULE { name = ExperimentStorage identifier = Kemini 1 chanceTexture = false type = KEMINI MODULE { name = ExperimentStorage identifier = Kemini 2 chanceTexture = false type = KEMINI } }

Was trying to find the Kemini experiments since I got contracts for them, but they aren't showing up in the Editor. Upon investigation I see that ALL the Kemini experiments have the Category set to "none", which prevents them from being shown: D5.cfg: category = none D7.cfg: category = none D8.cfg: category = none D10.cfg: category = none MSC3.cfg: category = none TEST.cfg: category = none Is this intended?

Would be helpful is a specific sequence of steps and vessel/parts could be provided for me to replicate. This is relatively minor, and I"m busy with another mod, I don't have a lot of time to look into this, but if I can get a good way to replicate it, I would be able to see what's going on

New release of NIMBY: 1.1.1.4 Fixed missing directory in the NIMBY folder Removed max version from .version file

I've already asked him, waiting for a reply

That's a bit problematic, it would most likely involve my having to do 6 releases, first the ClickThroughBlocker, ToolbarController & KRASH for 1.3.1, waiting until it gets indexed and then doing it all again for 1.5.1 The other possibility would be for me to create a new version of KRASH, with a different name, for 1.3.1,along 1.3.1 version of the ClickThroughBlocker and ToolbarController, and then adding them all to CKAN with a different name for 1.3.1, etc. Or I go through it and re-enable the stock toolbar code. I'll see if I can change all the #if false to something which will allow it to be recompiled with the stock toolbar code, but that's going to take a few days to get it done and tested

What I will do will not be available through CKAN, unless I create a new CKAN config for the older version. But I will provide you with a set of DLLs which can be included in RP-1 as an exception to my normal "No modpacks with my mods" rule

I'll see if I can get a 1.3.1 version out in the next day or so, I also need to recompile the ClickThroughBlocker and ToolbarController for 1.3.1

Just let me know when it's available, thanks

Create a directory called NIMBY\PluginData, then try again The directory is missing (was missing in the old mod as well), I'll get that fixed in an update

That is a bit much, but if you are willing to zip it all up, I'd be happy to look at it. This has happened before, I just haven't seen it, so am willing to download a big file if that helps me find it

I have been unable to replicate this issue. I need a specific series of steps from someone in order to replicate it, including a list of all mods, and preferably a copy of the save file as well Do you have the dependencies installed (ClickThroughBlocker & ToolbarController)?

New release, 0.6.16.2 Added lines for KSPI-E parts Removed max version from .version file

New release, 0.1.9.5 Adjusted some of the researchTime values, they were too high Removed maxversion from .version file

New release, 0.3.24.2 Thanks to @tjdeckard: Updated part configs to reflect changes made to converters in USITools Removed KSP_MaxVersion from version file