toadicus

KER compiles all of its goodies into one library. VOID dynamically links to VesselSimulator.dll, which is my compile of just the bits of KER that I use. It's likely that there's no conflict in part because KER's code is all in one assembly: it never goes looking for the classes elsewhere, so there's no opportunity for conflict. I could probably write a wrapper that would resolve the KER classes I use at runtime and use the KER assembly instead of my compile when I have to. And, if you have big, heavily-modded ships out in flight with VOID up and a KER part attached, that might have some performance benefit. But, in my testing the KER code doesn't really slow things down all that much; KER intentionally throttles itself to avoid running more often than it needs to and to keep load down: if you build a big 3m launcher lifter under a Kerbal X (I call it the Kerbal XX! ) KER still does the whole pass in a <2ms on my machine. So, at this point, if they're playing nicely together, I'm going to leave that part alone. If someone notices a huge performance hit in the editor when both VOID and KER are installed, I'll think about it, though you could always just disable VOID's engineering calcs in the editor since you're using KER's anway.

You've got at least one inline, around the guided weapons pack, to http://kerbalspaceprogram.com/lazor-guided-weapons/

It's likely that no one can help you without more information. KSP keeps logs at those locations during every run, with or without crashes: if there is anything in those files, it may be more useful towards solving your problem than nothing at all. Thousands and thousands of people use ModuleManager every day without it crashing their games: if anyone is going to help you we need to know what makes your situation different, and "it crashes" isn't enough distiction. The only idea I have without more information is: do you have any .cfg files in your GameData folder that do not have any nodes (e.g. PART {} or @PART {} ) in them? KSP doesn't like empty .cfg files.

Just for kicks, I tested this: @PART[longAntenna]:FOR[MakingThingsExpensive] { @cost *= 20 } @PART[longAntenna]:FOR[MakingThingsInexpensive]:NEEDS[MakingThingsExpensive] { @cost /= 2 } No folders or dlls installed named "MakingThingsExpensive", but MakingThingsInexpensive does resolve its NEEDS and is applied.

In fairness to Squad, I'm pretty sure this bug/feature/"feature"/thing was actually intended to make things better for modders: in a completely stock game, such a functionality has zero use whatsoever. It didn't work out, but I have inferred from a few statements elsewhere that it's among the things they're addressing in the upcoming fix. Yes, it's frustrating for all of us on this side of the veil, but I don't think it's in our best interests to write them off just yet. On another note: I'm vacationing this weekend through next Wednesday! There won't be any support available from me during that period.

I'll think about it. I'm going on vacation this weekend through next Wednesday; I'll see if I can't pick a direction by then, and ask cybutek / let you guys know / whatever next week. I haven't ever tested it. I make a few custom tweaks to the KER code I license, but they're pretty minor and don't break the API... so, it's really up to how Squad's assembly loader resolves multiple instances of the same code. It might work well, but it might not. If you test it, I'm sure there's others here who would appreciate hearing your experience. So, tell you what. Regardless of what I decide regarding providing an editor GUI, going forward I will make sure that VOID and KER will play nicely in the editor. If I can find a "best of both worlds" solution that both cybutek and I are OK with, so much the better. But none of that will happen before next Wednesday. I might have a little unrelated update before I go, though.

So I'm pretty sure the relevant lines in that log are specificaly the "Setting FX Modules to [01]". That's Squad's antenna module manipulating the animation directly, IIRC. When I get a chance, I'll fire up my über logging and see if AntennaRange is doing anything in between "Settings FX Modules..." and "FX Module set"... but again, I'm pretty sure that I don't actually have anything to do with it. I just call ModuleDataTransmitter.TransmitData() and let it do its thing. That said, I'm vacationing for a few days: starting this Saturday, I'll be out of contact until Wednesday, so there'll be no support during that period.

Not entirely alone. It's not traditional, but I think it has a good "teaser" sort of feeling, and like that it's not the same as everything else.

I believe some of the more Big Time modders might have a more direct line to people who can do things about this than I do... but I may also be misinterpreting things. That said, if I can think of a good way to pose this without decompiling and quoting what I think is wrong, I will absolutely post a bug if no one else does first. First I'm going to try to help work around it though; we can turn out releases a lot faster than Squad can.

Procedural Farings do not use the stock decoupler modules. If the Procedural Fairings have the same no-force problem, that'll need to be addressed over there. Unless sarbian, in his great magnaminity, wants to code up a wrapper for PFairings to fix the issue. But that's up to him; I just talk a lot.

So, the two patches will things slightly differently: Patch 1 will apply ONLY to parts that have a ModuleScienceContainer but that do NOT have any definition for allowRepeatedSubjects (true or false; if they have any allowRepeatedSubjects = <stuff> line, they won't match). It will then modify the first ModuleScienceContainer on such parts and add the value allowRepeatedSubjects = true. Patch 2 will apply to ALL parts that have a ModuleScienceContainer. It will then modify the first ModuleScienceContainer on such parts and modify or add the value allowRepeatedSubjects, setting it to true. So, which is more correct depends on what you're trying to do. If you're trying to fill in some gaps, the former will do what you want. If you're trying to change the behavior of all parts bearing ModuleScienceContainers (except those for which allowRepeatedSubjects = true already; they'll match and the patch will apply, but since nothing's change you won't notice a difference), the latter is correct. I'm not 100% sure, but I think :NEEDS will match mods as defined by a) the presence of a plugin .dll with a given Assembly.Name, a mod name as declared in a :FOR[] block, or c) a mod name as discovered by the name of a directory child of GameData.

I think the answer to that is "yes". I've done a bit of testing and informed sarbian of my thoughts. Not fun, but still great? I'm hopeful we'll find a way around it, and further hoping that Squad fixes their fix in the upcoming fix-fixing update.

Does it consistently recur when you turn probe dependency back on? Because, honestly, turning the probe comms dependency on does almost nothing to the otherall functionality of the mod. The mod checks for connection every few seconds anyway when there's an icon to draw; all the probe comms dependency does is lock the controls when that check fails. Is it just your antenna animation, or does KSP slow down in general?

I don't know if we're technically allowed to REALLY know about Squad's PartModule reordering... but I'm pretty sure it's happening in Part.LoadModules and it definitely looks like it's just throwing Part prefabs to the wind and trying to rebuild the prototype modulename for modulename. And, I'd pretty confidently say that about 90% of the reports I've seen regarding TweakableEverything and sarbian's DecoupleForX64 have been directly caused by it breaking mod compatibility with old persistence/craft files. If you started fresh in 0.24 and don't use any shared or stock craft files, even with a heavily modded install you might not have noticed at all. If you tried to continue a save from 0.23 or use craft or subassemblies saved without your mods... everything might just be broken completely. I'm pretty sure that re-enabling ModuleManager's SaveGameFixer will work around the code by making all of the craft and persistence files look like the prefabs as loaded up by various mods and ModuleManager. Hoping to test that more tonight whilst sarbian sleeps.

So, while there is one little hint in your second trip to the editor that TweakableDecouplers didn't start up right, I'm going to guess that's a result of this bug. Too, you have a few other issues with your mods; ExLP (probably extraplanetry launch pads?) was screaming throughout your whole first trip through the editor, and Kethane and IR's Tweakscale library aren't playing nicely throughout. Actually, it looks like your ExLP problem is also to do with the bug I linked to above. The evidence is here: Attempting to replace PartModule 'ModuleTweakableReactionWheel' with 'ModuleAGExtData' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ModuleAGExtData' with 'ExWorkshop' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ExWorkshop' with 'ModuleTripLogger' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ModuleTripLogger' with 'FARBasicDragModel' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ModuleAGExtData' with 'FARControlSys' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ModuleDecoupleX64' with 'ModuleDecouple' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ModuleStagingToggle' with 'DecouplerJointReinforcementModule' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ModuleTweakableDecouple' with 'FARBasicDragModel' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Attempting to replace PartModule 'ModuleTweakableJettison' with 'FARBasicDragModel'(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Basically, Squad's new attempt to "fix" misordered craft files and persistence nodes actually breaks modded installations severely.

Based on super-preliminary "I'm at my desk at work" testing, it looks like re-enabling MM's SaveGameFixer probably does work around the new 0.24 "feature". Also, a few lines like this in Awake() ought to upgrade stock craft, so people can fly the Kerbal X in x64: char ds = Path.DirectorySeparatorChar; UpdateCraftDir(string.Format("{0}{1}Ships{1}VAB", KSPUtil.ApplicationRootPath, ds)); UpdateCraftDir(string.Format("{0}{1}Ships{1}SPH", KSPUtil.ApplicationRootPath, ds)); YMMV, IANASarbian, etc. etc. Seems worth looking into, at any rate. I think NathanKell might have been talking about something other than your question. If you still need an MM patch, it would look something like this: @PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[LazorSystemDockingCamera]]:Final { MODULE { name = LazorSystemDockingCamera } } "Final" is a bit deprecated, but for a personal patch you should be fine.

New MM patch: @PART[*]:HAS[@MODULE[ModuleDecouple]]:FOR[DecoupleForX64]:NEEDS[!TweakableEverything] { @MODULE[ModuleDecouple] { @name = ModuleDecoupleX64 } } @PART[*]:HAS[@MODULE[ModuleAnchoredDecoupler]]:FOR[DecoupleForX64]:NEEDS[!TweakableEverything] { @MODULE[ModuleAnchoredDecoupler] { @name = ModuleAnchoredDecouplerX64 } } @PART[*]:HAS[@MODULE[ModuleDecouple]]:AFTER[TweakableEverything]:NEEDS[TweakableEverything] { @MODULE[ModuleDecouple] { @name = ModuleDecoupleX64 } @MODULE[ModuleTweakableDecouple] { @decouplerModuleName = ModuleDecoupleX64 } } @PART[*]:HAS[@MODULE[ModuleAnchoredDecoupler]]:AFTER[TweakableEverything]:NEEDS[TweakableEverything] { @MODULE[ModuleAnchoredDecoupler] { @name = ModuleAnchoredDecouplerX64 } @MODULE[ModuleTweakableDecouple] { @decouplerModuleName = ModuleAnchoredDecouplerX64 } } This adds two patches that will not try to change TweakableEverything modules if TweakableEverything is not installed.

They are in the prefab, and ModuleManager does add to the prefab, as you say. Squad's new part loading code appears to disregard the prefab when it thinks it is wrong, and replaces the cloned prefab modules with new modules as stored in the persistence/craft file. That's what the "replace PartModule 'moduleName1' with 'moduleName2'" messages are in Obsessed's logs. It flies in the face of everything modders have been using for forward-compatibility in the past and, IMO, is a pretty big problem.

Are you loading a craft file saved before you installed DecoupleForX64? If so, it won't work. You'll need to rebuild the craft by hand, or at least remove and replace the decouplers.

Sarbian, in light of the KSP "feature" that replaces PartModules from persistence files by name, would re-enabling MM's persistence fixer work around the issue? Could it be applied to .craft files as well?

I don't change anything to do with the animations. I tried that once and it ended poorly. What I do know is this: The antenna animations works two different ways. First, they can be toggle directly using ModuleAnimateGeneric's Start/Stop/Toggle methods. Second, they can be moved to specific points along the animation using IScalar methods. When I looked in to tweaking them for TE, the Extend/Retract events called ModuleAnimateGeneric's methods, which just says "go" and then the animation plays at 1× speed. The "transmit" methods in ModuleDataTransmitter, however, actually move the antenna frame-by-frame using the IScalar methods rather than letting it move itself. Why? I have no idea. But they do. So, my guess is that Squad moved ModuleDataTransmitter actions from Update to FixedUpdate, or changed the Coroutine delay to depend on the physics frame time, or similar, and didn't rebalance the distance that the antenna moves per frame. That's a guess, but it's all I've got. Does the speed of the animation change at all if you timewarp after clicking transmit? If so, I'm probably pretty close.

It looks like this is causing issues loading .craft saved modless for basically any mod that changes modules via ModuleManager. Does Sarbian know? Is there a way to stop Squad's "fixer" from running? In the meantime I've added PSAs to my part-changing mods:

So I'm pretty sure you were both having the same issue, and I'm pretty sure Squad's new "fix mis-ordered PartModules" code is to blame, as NathanKell hints here. My understanding / conjecture is thus: User has a .craft file from an older version, or without mods installed. Mods use ModuleManager to replace a module on parts used in the .craft file. When loading the craft file, KSP detects that the modules referenced in the .craft file (e.g. ModuleDecouple) are not present in the part's prefab (e.g. having been replaced by DecoupleForX64 with ModuleDecoupleX64). KSP "fixes" the inconsistency At that point TweakableDecouplers has out of date information and fails to start up. I need to make it fail a bit more gracefully, but that notwithstanding it isn't going to work. DecoupleForX64 isn't going to work either; if you uninstalled TE, loaded that assembly and launched it, none of your decouplers would work. So, the moral of this story is: if you are using mods that change part functionality, especially if those mods use ModuleManager, you cannot use old or un-modded .craft files because KSP will break them. I'ma go put that on the first post. Credit where it's due: Sarbian wrote it, not me. All I did was contribute a couple fixes for the MM patch.

Yep, I found that bug as well; it's fixed internally. I'm working on a few last items before I can push a new version. Your request is one I've got several times, and my answer has generally been: I license KER code to do all the engineering calcs. Out of respect for the kindness of cybutek and his team, I am intentionally not competing in a few realms that really make KER what it is, and this is the big one. I know this isn't an answer many of you like to hear, but at this point I continue to feel like it is the right one. I may have another chat with cybutek about that at some point, and revisit my stance. But that hasn't happened yet. Thanks for the request, though!

I need a Debug log to help find the conflict or problem. Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log