Tonka Crash

I see a Reflection Error from EVE during loading that can cause weird hard to diagnose problems. I uninstalled EVE, Planetshine and Scatterer from my 1.10 game until this one is fixed. There are numerous texture errors from this mod, but I wouldn't expect those to be game breaking. Crashes to desktop is hard to diagnose since what's causes the problem typically isn't captured in the log. You need to go into the debug menu and on Immediately Flush Log File to Disk. Normally KSP buffers log messages, so when you crashed, nothing of interest had been dumped to the log yet and these were lost in the crash.

It's not ideal, but I really don't have a lot of experience yet to see how the limitations are hurting me. I also haven't committed 100% to using it. Below is the base where I'm using it. I'd think any mods that rely on background processing or a catch up mechanism would need to be aware of the SL resource sharing so they can access resources on other craft if SL isn't active. The Launchpad in the background is why I installed Simple Logistics, but it only needs to be active when the scene is loaded and I'm transferring using an RTS-1. One limitation I found I don't really like in SL is the craft with the the RTS-1 to must have storage for any resources you want to transfer. The RTS-1 can't see everything in the logistics network otherwise, so my launchpad has containers around it's perimeter for any resource used in my game. The RTS-1 can see them and transfer any of them in or out of a lander. Craft landing connected to an RTS-1 for transfer. Smallest size containers are a local cache that SL keeps topped up while transferring. So I can fill a 3.75m ore tank from a 1.25m size tank on the launchpad without delays. RTS-1 used for final connection to lander. My game "rules" assume underground connection between launchpad and base buildings, but someone still has to go out and manually connect a hose to transfer resources to a lander. SL has a mechanism for the lander to request resources from the network, but it's UI is still flaky in the version on CKAN. @zer0Kerbal was real gung-ho for a while, but has been mostly MIA the last several months.

@tinfever It's really a KIS bug not KAS. As for using them as anchors you'll find that nothing stays attached to the ground anyway.

It's a space game, everything is calculated relative to the center of the SOI of an celestial body, so a landed craft is in orbit around the center of the body that just happens to be moving at "close" to the same velocity as the point on the ground it's sitting. KSP calculates the physics for each part of every craft in physics range independently. It's why the game bogs down as part count goes up and why you can have floppy unstable rockets. The only fix is to fundamentally change how physics are done in KSP. I'm guessing KSP2 will try a different approach at least to solve the large craft problem and their bases look to be built into the terrain instead of sitting on it. No one has come up with a way yet. The ground tether is the closest I've seen without using launch clamps with Extraplanetary Launchpads.

Looking at the code the only way to get message KAS Joint in broken, unlink the parts is for core game to have decided the joint broke. I'm guessing it calculated the loads through the joint exceeded its limits. KAS is just smart enough to see this and log a message. The thing about KSP is your craft is never just sitting there doing nothing. Physics is always running. in this case the relative position between craft got high enough to increase the loads to snap the joint. Now to get a little technical about how this is not an "simple" problem to fix. In a previous job I wrote ground handling code for full motion flight simulators. The hardest part was getting the airplane to stay parked. The airplane was always in motion due to rounding errors and discrete sampling of the physics. The best I could do was to keep motion from being perceptible to the people in the simulator. The way most sim code works is you calculate the forces and moments on a vessel, from this you get accelerations that are integrated to the previous physics tick's velocities for a new velocity. These velocities are integrated to the previous position to get a new position. I haven't tried to research it, but this is probably in just one routine or a set of routines all called in sequence from a parent routine. Mods probably can''t affect something this core to the game without completely replacing the physios engine. How the MKS ground tether works is that it just resets the craft velocities to zero each physics tick, so instead of integrating from the previous velocity, you start from zero velocity each tick of physics engine. This still allows a little position change depending how much velocity can build up in the physics engine before the ground tether has a chance to zero it out. Usually these changes are pretty imperceptible, but I have seen craft with an active tether moving in the game. I've also been able to takeoff with a tether attached, because the tether only works for landed craft and in that one cycle of the physics engine I can move enough to no longer be considered "landed" but "in flight" so the ground tether deactivates automatically. When you use any KAS or KAS derived parts like MKS flex-o-tubes or KPBS flex corridors in a docked mode you are locking the relative position between the two craft and forcing the KAS tube to carry loads. if this load gets high enough joints break. This game I've started using Simple Logistics to share resources between buildings so I don't have to rely on rigid connections and manually use an RTS-1 undocked to refuel craft. Also when you 'dock' the loads are redistributed across all parts as if it were one rigid vessel instead of several discrete craft that support themselves. This redistribution of loads is a prime source of exploding landing gear and "hopping" as you dock and undock craft to a large base.

@blowfish Is there a syntax to do something after a mod only if that mod exists, but other wise work normally. I have a case where the patch contents don't change, but I need to delay only if another mod is installed. If I use :AFTER[myMod] and myMod isn't installed the patch is deleted by MM, so it looks like I have to duplicate patches one for if the mod is there and one without. I'd like to avoid this as the contents of the patches are identical. Right now the only way I can see to do it is have two sets of patches which I'd like to avoid: @PART[??]:AFTER[myMod] { do stuff } @PART[??]:NEEDS[!myMod] { copy of do stuff } I'm trying to sort out some compatibility issues between Missing History and ReStock/ReStockPlus for a PR to MH. MH creates several parts as rescales of existing parts. Currently these are all based on the stock models. What I would like to happen is for MH to wait until after ReStock patches in it's models, but only if RS/RS+ is installed. if ReStock is not installed MH can run normally. In my local install I just change the MH patches and add the :AFTER[ReStock] to each part, but this doesn't work for the case where ReStock isn't installed, so isn't suitable for distribution.

@darthgently I get what you are trying to do, I just don't understand why bother? It's you find it tedious to use a bunch of little containers, why not just use a bigger one? Or you could look at mods that build things on site instead of hauling parts around. (Extraplantary Launcpads or OSE Workshop)

I don't use MKS, so I don't know how it's implemented in that mod. I use a patch to add that function to all command pods and probes. For me it's just in the right click menu of any part with the module as Attach Ground Tether. // Add USI-Tools Ground Tether option to command modules so we can add the Toggle Tether next @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[USI_InertialDampener]] { MODULE { name = USI_InertialDampener } }

@GDorn Without a full log it's hard to saw one way or another what's wrong with your install. It could be the latest KER is not backward compatible, but with just a snippet from the middle of the log there's no way to check if there were any other errors leading up to this that might point to a different issue.

@DasSkelett @HebaruSan I have a feature request/bug report. I am using Drake. If you revert to an older version of a mod that mod uninstalls and installs the version you request. Which is good, but this also has a side effect of uninstalling mods dependent on the mod you change, but doesn't reinstall any of these.. Yesterday I updated ClickThruBlocker to latest. Found the new version buggy so reverted to the previous version. This had the side effect of uninstalling everything that had ClickThruBlocker as a dependency, i.e. (most of LGG's mods) But then didn't reinstall any of them.

You need a flex corridor on both sides of the connection. They only attach to each other.

@GDorn You need to post your entire KSP.log to a file sharing site like Dropbox or Google Drive and share a link to it here if you expect anyone to be able to troubleshoot this for you.

@bcqJC I've never seen a reference to __LOCAL as a "special" place for user patches. The Module Manager wiki has the following information Patches are applied in the following order: Nodes with no operator ('insert') are loaded by the KSP GameDatabase first. Patches for modname values in NEEDS, BEFORE, AFTER, LAST that don't exist are removed. All patches with :FIRST are applied. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied. For each item in the Unicode-sorted list of modname values: All patches with :BEFORE are applied All patches with :FOR are applied All patches with :AFTER are applied All patches with :LAST are applied All patches with :FINAL are applied Within each pass the patches are applied in alphabetic order of the directories in GameData. On Windows __LOCAL sorts to be first on my computer. I use ZZZ_PERSONALPATCHES for my local patches so it's alphabetically last. Using :FINAL is fine for patches you write yourself since you are the only one they will affect. In this case :AFTER[SimpleLogistics] should have the same affect without causing anyone to blow a gasket about seeing :FINAL in a fix being discussed.

I do have the 999_Scale_Redist.dll in GameData. Since I first posted I went and set up a stripped install Squad+Expansions, MM and TweaskScale. No other mods. I started a new sandbox game. I still get exceptions. On a new start (new game or loaded save) it does not start throwing exceptions until I remove a part from the craft. I can go into the VAB and start building a craft, add parts to it, right click a part and I get no exceptions. Once I remove a part then every change or right click throws an exception. Edit: I can leave the VAB and reenter and exceptions happen on first part. It seems the only time I don't get exceptions is first time into the VAB from start of KSP.

@Lisias I hate to bug you with this, but I am seeing exceptions in 1.10 from TweakScale 2.4.3.15 installed from CKAN. Otherwise TweakScale seems to work fine. I get an exceptions in the VAB: Placing parts Removing parts Rescaling parts Right Click a part. Log and MM.ConfigCache I do not have Recall installed since you indicated it was unnecessary in 1.10 and TS seems to work without it. I haven't had time to try isolating a minimal set of mods. I'm hoping you might see something from the log. This is from my fully modded game install that's was started in 1.7. [ERR 17:32:29.829] Exception handling event onEditorShipModified in class TweakScale:System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Behaviour.get_enabled(UnityEngine.Behaviour) at TweakScale.TweakScale.OnEditorShipModified (ShipConstruct ship) [0x00000] in <c3d11dd12519438cafd8dbec2a0a0668>:0 at EventData`1[T].Fire (T data) [0x000b0] in <c168e21ec56346b082f89043e76162e1>:0 [EXC 17:32:29.830] NullReferenceException TweakScale.TweakScale.OnEditorShipModified (ShipConstruct ship) (at <c3d11dd12519438cafd8dbec2a0a0668>:0) EventData`1[T].Fire (T data) (at <c168e21ec56346b082f89043e76162e1>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(ShipConstruct) EditorLogic:SetBackup() EditorLogic:<SetupFSM>b__195_29() KerbalFSM:RunEvent(KFSMEvent) KerbalFSM:updateFSM(KFSMUpdateMode) KerbalFSM:UpdateFSM() EditorLogic:Update() I think your Houston warning is also throwing errors, but these aren't a big deal. Unable to use a named GUIStyle without a current skin. Most likely you need to move your GUIStyle initialization code to OnGUI

I'm sorry you find my humor offensive or that providing a bug report and log from a minimalist install isn't considered helping. I have yet to play 1 minute since 1.10 dropped since I'm doing what I can hunting bugs and submitting PRs. They just haven't been on your mods. Tripping over the CTB bug was icing on the cake while looking for a bug in an unrelated mod where I needed NodeHelper and got this as a dependency.

You missed the point of my post. I do have my own way of doing it. But you also have a mod for that functionality so why duplicate the same function into multiple mods? Once a user realized they need the info they will either implement something themselves like I did, go find PartInfo or suffer from being uniformed. I don't see the point of duplicating functions.

My time is limited as well. If it doesn't show up on CKAN it doesn't exist to me. And yes I see the Input Lock button.

Why duplicate functionality into NodeHelper when the PartInfo mod is out there for people that want that functionality? I have my own MM patch for this because I see PartInfo as unnecessary bloat.

I understand exactly what it's doing. If the mod Partinfo is not installed, add this module. Which is throwing errors from the partcompiler because ModulePartInfo does not exist on my computer. I don't see it doing anything but being the source of thousands of errors.

1.10 or 1.9? No, it shouldn't change state.I haven't tried playing my save in i.10 yet. I keep running into mods with "issues" I use KPBS and it doesn't ask for docked/undocked on it's kerbitrail equivalent. They are always docked. But I have seen the parts flake on me and all of a sudden they were all giving me the docked/undocked toggle and showed undocked. I had to disconnect everything and exit the game then restart and reconnect to get everything back to normal. I haven't been able to recreated it. This was in 1.9.1. With MKS isn't there a logistics sharing system so you don't have to do this anyway? I don't do MKS, so my knowledge there is limited.

@Snark @RealKerbal3x I was premature, CKAN for my machine finally showed a new version of IL and I'm now seeing the problem. The fix is relatively simple, rewrite the entire IL half of the config and add a complete IL definition instead of assuming IL exists in the source part. The source part uses a mesh, so IL would add a model node and the full IL definition. In the old version this happened before MH but once IL added :FOR directives this all moved. The MH patch would try to apply scaling changes to the model node and light positions, but none of these nodes exist yet so these fail. The fix is to just add this info to the MH part definition. I create a PR for the fixed part From the MM wiki: Nodes with no operator ('insert') are loaded by the KSP GameDatabase first. Patches for modname values in NEEDS, BEFORE, AFTER, LAST that don't exist are removed. All patches with :FIRST are applied. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied. (This is where this reaction wheel is created) For each item in the Unicode-sorted list of modname values: All patches with :BEFORE are applied All patches with :FOR are applied (This is where IL is patching the source part) All patches with :AFTER are applied All patches with :LAST are applied All patches with :FINAL are applied

@linuxgurugamer It looks like there is a poorly designed patch in GameData/NodeHelper/Configs/NM_PartInfo.cfg It is adding ModulePartInfo to all parts if you don't have PartInfo, but the module is only found if you have PartInfo (which I have never used) This is the source of a Cannot find a PartModule of typename 'ModulePartInfo' erro on every single part in my game. :FINAL is also bad practice in distributed mods. @PART[*]:NEEDS[!PartInfo]:Final { MODULE { name = ModulePartInfo originalPartName = #$../name$ } } Is this patch even necessary at all? Doesn't PartInfo do this already? Why the need for another patch?

@linuxgurugamer First bug. On load into the Space Center for the first time you get the popup to choose functionality. If you select mouse follows click, you can't select any of the space center buildings. Second bug. This mod is now throwing exceptions on all scene changes. [snip] Reverting to previous cleared this issue. This doesn't really seem ready for release..

I can get that out of the log. I prefer the KSP.log