Jump to content

Lisias

Members
  • Posts

    5,429
  • Joined

  • Last visited

Community Answers

  1. Lisias's post in Can't load vehicles in SPH was marked as the answer   
    Yep, the thing just borked on the next craft on the list, the Ships/SPH/BDAc_Test_Drone_MKIII :
    [LOG 01:11:10.419] [ShipConstruction]: No thumbnail image exists for Ships/@thumbs/SPH/BDAc_Test_Drone_MKIII. Attempting loading stock thumbnails. [WRN 01:11:14.675] [UpgradeScript]: JPLRepo ModuleDockingNodeFixed replace supports files from 1.12.0 and higher only! [EXC 01:11:14.686] NullReferenceException: Object reference not set to an instance of an object SaveUpgradePipeline.v180_ModuleControlSurface.ConvertControlAuthority (ConfigNode mNode, ModuleControlSurface module) (at <39c0323fb6b449a4aaf3465 SaveUpgradePipeline.v180_ModuleControlSurface.OnUpgrade (ConfigNode node, SaveUpgradePipeline.LoadContext loadContext, ConfigNode parentNode) (at SaveUpgradePipeline.UpgradeScript+<>c__DisplayClass17_0.<Upgrade>b__0 (ConfigNode node, ConfigNode parent) (at <39c0323fb6b449a4aaf3465c00ed3c8d>: SaveUpgradePipeline.UpgradeScript.RecurseNodes (ConfigNode node, System.String[] urlNodes, System.Int32 level, Callback`2[T,U] cb, ConfigNode pare SaveUpgradePipeline.UpgradeScript.RecurseNodes (ConfigNode node, System.String[] urlNodes, System.Int32 level, Callback`2[T,U] cb, ConfigNode pare SaveUpgradePipeline.UpgradeScript.Upgrade (ConfigNode n, SaveUpgradePipeline.LoadContext loadContext) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) SaveUpgradePipeline.SaveUpgradePipeline.RunUpgrade (SaveUpgradePipeline.UpgradeScript uSc, ConfigNode node, SaveUpgradePipeline.LoadContext loadCo SaveUpgradePipeline.SaveUpgradePipeline.RunIteration (ConfigNode srcNode, ConfigNode& node, SaveUpgradePipeline.LoadContext ctx, System.Collection SaveUpgradePipeline.SaveUpgradePipeline.Run (ConfigNode node, SaveUpgradePipeline.LoadContext ctx, System.Version AppVersion, System.Boolean& runS SaveUpgradePipeline.SaveUpgradePipeline.Run (ConfigNode node, SaveUpgradePipeline.LoadContext ctx, System.Version AppVersion, System.Boolean& runS KSPUpgradePipeline.Process (ConfigNode n, System.String saveName, SaveUpgradePipeline.LoadContext loadContext, Callback`1[T] onSucceed, Callback`2 KSP.UI.Screens.CraftBrowserDialog.pipeSelectedItem (KSP.UI.Screens.CraftEntry sItem, KSP.UI.Screens.CraftBrowserDialog+LoadType loadType) (at <39c KSP.UI.Screens.CraftBrowserDialog.ConfirmLoadCraft () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) KSP.UI.Screens.CraftBrowserDialog.onButtonLoad () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) UnityEngine.Events.InvokableCall.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0) UnityEngine.Events.UnityEvent.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0) UnityEngine.UI.Button.Press () (at <5336a8686ff14f17888ce9a9f44f29bc>:0) UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) (at <5336a8686ff14f17888ce9a9f44f29bc>:0) UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData even UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.Ev UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.EventSystems.EventSystem:Update() Interesting enough, I could load the SpawnProbe on my KSP 1.12.3, so the only logic conclusion is that there's something on your rig causing this problem.
    Frankly, I'm running out of options other than going nuclear on the damned problem.  
    This is a list of the remaining folders from your GameData:
    999_KSP-Recall
    AstronomersVisualPack
    AtmosphereAutopilot
    BDArmory
    Custom
    DistantObject
    EnvironmentalVisualEnhancements
    KerbalJointReinforcement
    PhysicsRangeExtender
    PlanetShine
    Scatterer
    ScattererAtmosphereCache
    Sigma
    TUFX
    TweakScale
    VesselMover
    Waterfall
    Remove items 2 to 9, then fire up KSP and see if the problem goes away. If it goes, then it's one of these.
    If the problem persists, put them back and remove 10 to 17. Check again, if the problem goes away, we know that the problem is one of these.
    If the problem still persists, hell, remove everything leaving just Stock and StockExpansion. Now the problem must had been gone - otherwise, you have a problem on KSP itself and should reinstall it from scratch!!
    Remember to do this stunt on that backup I mentioned above - removing add'ons this way will seriously damage your savegames.
    Now, assuming that one of the removal fest above solved the problem, out them all back, fire KSP to be sure the problem is back, and then remove half of that half, rinse, repeat. We are doing a binary search.
    For example, let's pretend that the culprit is Add'On number 15.  But we don't know yet, so we will do a binary search.
    First pass: Red the ones removed, Yellow the ones left on GameData: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
    This first pass didn't removed the problem, so let's try the other half (Green are the ones we know are innocent): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 
    Oukey, the problem is gone. So we know it's between 10 and 17. Lets split that in half in half and redo : 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 
    Oukey, the problem is still there, so 10 to 13 are innocent. Let's split that half in half and redo: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 
    By removing 14 to 15, the problem goes away, so we know that 16 and 17 are innocent! So 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 
    So now the options are 14 and 15. Removing the 14 the problem is still there, so we found the culprit, 15! To be sure, you put everything back and check for the presence of the problem. Then you remove 15 and check if the problem goes away - success!
    Of course, this was just an example. The culprit can be anyone of that 17 add'ons - so now you need to start probing like I did above, splitting in half the half that failed, and going on until you find the problematic add'on.
    Yeah, it's laborious, but I ran out of logical options - the only option left is brute forcing our way into the problem.
    Good luck!
     
  2. Lisias's post in Teakscale error. was marked as the answer   
    There's this new Modus Operandi on KSP.log since a few months ago where the Exceptions I need to diagnose the problem appears to be filtered from KSP.log.
    MechJeb uses to invert some logging somehow, so when MechJeb is installed, the first Reflection Exception is not the culprit, as the real troublemaker somehow is logged some time later.
    There're some add'ons that some people like to use to show Exceptions on the screen instead of the log, and so when something bad happens, the KSP doesn't have anymore the information I need. But you are not using any of the ones I know
    BDArmory used to cause some trouble in the past (some mishap on one of the dependencies), but it used to log a hint on KSP.log about, and there's none on yours.
    So we have no choice but going Combinatorial Analysis.  
    Remove the following add'ons from your rig and see if the problem goes away:
    B9AnimationModules v1.6.0.0 / vv1.6.0 B9PartSwitch v2.18.0.0 / vv2.18.0 B9-PWings-Fork v0.43.0.10 BahaTurret v1.0.0.0 BDArmory.Core v1.3.4.0 BDArmory v1.3.5.0 I have absolutely no evidence on the KSP.log that they could be misbehaving, but these ones already triggered this problem in the past, so it's a good bet to start with them.
    If the problem vanishes, we found where the problem is. So, install back them one by one until the problem happens again. The last one installed will be culprit, and then you will need to reach the maintainer for further help.
    Keep in mind that your KSP.log is littered with exceptions, TweakScale is only the one complaining about:
    [LOG 18:17:25.316] Load(Texture): BDArmory/Parts/ABL/texture [EXC 18:17:25.321] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.322] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.329] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.330] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.337] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) So you really need to solve this problem in order to have a stable KSP to play.
  3. Lisias's post in Teakscale error. was marked as the answer   
    There's this new Modus Operandi on KSP.log since a few months ago where the Exceptions I need to diagnose the problem appears to be filtered from KSP.log.
    MechJeb uses to invert some logging somehow, so when MechJeb is installed, the first Reflection Exception is not the culprit, as the real troublemaker somehow is logged some time later.
    There're some add'ons that some people like to use to show Exceptions on the screen instead of the log, and so when something bad happens, the KSP doesn't have anymore the information I need. But you are not using any of the ones I know
    BDArmory used to cause some trouble in the past (some mishap on one of the dependencies), but it used to log a hint on KSP.log about, and there's none on yours.
    So we have no choice but going Combinatorial Analysis.  
    Remove the following add'ons from your rig and see if the problem goes away:
    B9AnimationModules v1.6.0.0 / vv1.6.0 B9PartSwitch v2.18.0.0 / vv2.18.0 B9-PWings-Fork v0.43.0.10 BahaTurret v1.0.0.0 BDArmory.Core v1.3.4.0 BDArmory v1.3.5.0 I have absolutely no evidence on the KSP.log that they could be misbehaving, but these ones already triggered this problem in the past, so it's a good bet to start with them.
    If the problem vanishes, we found where the problem is. So, install back them one by one until the problem happens again. The last one installed will be culprit, and then you will need to reach the maintainer for further help.
    Keep in mind that your KSP.log is littered with exceptions, TweakScale is only the one complaining about:
    [LOG 18:17:25.316] Load(Texture): BDArmory/Parts/ABL/texture [EXC 18:17:25.321] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.322] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.329] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.330] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.337] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) So you really need to solve this problem in order to have a stable KSP to play.
  4. Lisias's post in Teakscale error. was marked as the answer   
    There's this new Modus Operandi on KSP.log since a few months ago where the Exceptions I need to diagnose the problem appears to be filtered from KSP.log.
    MechJeb uses to invert some logging somehow, so when MechJeb is installed, the first Reflection Exception is not the culprit, as the real troublemaker somehow is logged some time later.
    There're some add'ons that some people like to use to show Exceptions on the screen instead of the log, and so when something bad happens, the KSP doesn't have anymore the information I need. But you are not using any of the ones I know
    BDArmory used to cause some trouble in the past (some mishap on one of the dependencies), but it used to log a hint on KSP.log about, and there's none on yours.
    So we have no choice but going Combinatorial Analysis.  
    Remove the following add'ons from your rig and see if the problem goes away:
    B9AnimationModules v1.6.0.0 / vv1.6.0 B9PartSwitch v2.18.0.0 / vv2.18.0 B9-PWings-Fork v0.43.0.10 BahaTurret v1.0.0.0 BDArmory.Core v1.3.4.0 BDArmory v1.3.5.0 I have absolutely no evidence on the KSP.log that they could be misbehaving, but these ones already triggered this problem in the past, so it's a good bet to start with them.
    If the problem vanishes, we found where the problem is. So, install back them one by one until the problem happens again. The last one installed will be culprit, and then you will need to reach the maintainer for further help.
    Keep in mind that your KSP.log is littered with exceptions, TweakScale is only the one complaining about:
    [LOG 18:17:25.316] Load(Texture): BDArmory/Parts/ABL/texture [EXC 18:17:25.321] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.322] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.329] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.330] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 18:17:25.337] TypeLoadException: Failure has occurred while loading a type. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) So you really need to solve this problem in order to have a stable KSP to play.
  5. Lisias's post in Editor part duplicate broken was marked as the answer   
    Let me fill you about what's happening.
    On KSP 1.9 (yep, that long), something got screwed up and I think that Squad decided to workaround the problem by brute forcing data from prefab after loading the craft. This royally screwed up TweakScale and anything else that needs to change the part's attachment positions.
    Worse, as you detected, it screws up also Alt+Clicks (duplicates) and SubAssemblies once you try to workaround the Editor's workaround.
    Originally I had brute-forced my way on TweakScale, but by doing that I "solved" the problem for me but started to create problems for other people. So I decided to really understand the problem and tackle it down on KSP-Recall.
    What you are seeing is the consequence of a partial fix, as by some weird reason I didn't detected that parts on mirrors would be suffering from the problem (I applied the fix only for radial attachments!). I'm cooking a new KSP-Recall release with this fixed today.
    In the mean time, I have a reasonable work-around for the problem (to tell you the true, I'll teach you how to to trigger the Editor's bug): 
    1) Never start a subtree with a part without variant, unless it have a part with variant immediately attached to it.
    or
    2) Always start the subtree using a part with variant.
    In essence, the Editor's bug is that it's bluntly ignoring attachment's positions (and rotations, as I was recently told) when the subtree you are Alt+Copying or loading from a SubAssembly (or craft file) have as root part a part without variants followed by another part without variants. And this appears to be exactly the case you are suffering right now.
     
    Yep. I didn't forgot.  I'm working on it.
     
    — — POST EDIT — — 
    There's a new release for KSP-Recall with (hopefully) the correct fix for the problem.
     
    It's currently in "Early Access" because I'm not sure if this fix will really fix everybody problems. I kindly ask for people willing to try it in advance to report any mishaps.
    Cheers!
  6. Lisias's post in KSP 1.12.3.3173 Crashes on Load was marked as the answer   
    Hi, @Mangelhaft!
    This one is a new for me. From your logs, I found:
    Mono DLL loaded successfully at 'D:\Program Files\Kerbal Space Program\1.12.3.3173\MonoBleedingEdge\EmbedRuntime\mono-2.0-bdwgc.dll'. Stack Trace of Crashed Thread 5760: 0x000007FEE09BFAA4 (UnityPlayer) UnityMain 0x000007FEE09BD2BD (UnityPlayer) UnityMain 0x000007FEE0C17BF9 (UnityPlayer) UnityMain 0x000000006339B61A (UnityEngine.CoreModule) UnityEngine.Mesh.Internal_Create() ERROR: SymGetSymFromAddr64, GetLastError: 'The specified module could not be found.' (Address: 00000002BA47BE20) ERROR: SymGetModuleInfo64, GetLastError: 'A dynamic link library (DLL) initialization routine failed.' (Address: 00000002BA47BE20) What suggests some DLL is missing or corrupted in your rig. It appears to be a Windows native DLL, as problems with C# DLLs are logged using another format on the log file.
    I suggest you backup all your savegames and then verify the installation (if you are using Steam), or reinstall KSP from scratch (if not).
    If reinstalling, I suggest to do it on a new directory, check if KSP is starting fine on the new directory, and then copy the add'ons to the new folder, running it now and then to see if something gets screwed up in the process.
    Remember to keep the savegames backup'ed and do not load any savegames until you are satisfied with the new installment. When you load a savegame without installing all the add'ons it uses, the data used by these add'ons is wiped out from the savegame, and most of the time this render your crafts (including the ones flying) permanently mangled.
    Cheers and good luck!
  7. Lisias's post in (SOLVED)Parts disappearing when placed on my craft was marked as the answer   
    Now I have something to work with!
    I found two probable contributors to your problem (more about below):
    Textures Unlimited:
    [AddonLoader]: Instantiating addon 'TexturesUnlimitedDebug' from assembly 'TexturesUnlimited' (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Uploading Crash Report NullReferenceException: Object reference not set to an instance of an object at KSP.UI.Screens.ApplicationLauncher.RemoveModApplication (KSP.UI.Screens.ApplicationLauncherButton button) [0x00029] in <cd473063d3a2482f8d93d388d0c95035>:0 at KSPShaderTools.Addon.TexturesUnlimitedDebug.Awake () [0x000b9] in <d05d146f0f32458d9a30cf17e61f35a8>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelLoaded(GameScenes) AddonLoader:OnSceneLoaded(Scene, LoadSceneMode) UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode) and System Heat
    Uploading Crash Report NullReferenceException: Object reference not set to an instance of an object at SystemHeat.SystemHeatEditor.FixedUpdate () [0x0001a] in <faa8f438e27f4148b7041ce82be5b9c9>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) (Filename: <faa8f438e27f4148b7041ce82be5b9c9> Line: 0) CorrectCoL_Persistent.Start (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) KK: [KerbalKonstructsSettings] Start: Career Module Start Called (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) NullReferenceException: Object reference not set to an instance of an object at SystemHeat.SystemHeatEditor.FixedUpdate () [0x0001a] in <faa8f438e27f4148b7041ce82be5b9c9>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) They are not the ones directly causing you problems, I found a third one and I will talk about below. But it happens that once something throws up  an Exception, it breaks a chain of events because everything that was waiting to be executed after is not executed. This leaves a lot of things not correctly initialised, and then someone else trusting everything was correctly initialised borks and end up taking the blame!
    So the best way to proceed now is to backup everything and remove TextureUnlimited and SystemHeat from your GameData to see if the problem goes away. If it does, well, you will need to file a bug report for these two Add'Ons in order to have them fixed - to tell you the true, you should do it nevertheless. 
    If by removing them things are the same, then we can conclude that the Add'On I will mention now may be the problem:
    Adding default item(s) into seat's 2 inventory of part [Part:mk1-3pod (id=C4292261514)]: KIS.evapropellant (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) LiquidEngineLV-T91 added to ship - part count: 2 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Uploading Crash Report NullReferenceException at (wrapper managed-to-native) UnityEngine.Object.GetName(UnityEngine.Object) at UnityEngine.Object.get_name () [0x00001] in <12e76cd50cc64cf19e759e981cb725af>:0 at PreFlightTests.StationHubAttachments.TestCondition () [0x0003f] in <cd473063d3a2482f8d93d388d0c95035>:0 at PreFlightTests.DesignConcernBase.Test () [0x00000] in <cd473063d3a2482f8d93d388d0c95035>:0 at KSP.UI.Screens.EngineersReport+TestWrapper.RunTest () [0x00006] in <cd473063d3a2482f8d93d388d0c95035>:0 at KSP.UI.Screens.EngineersReport+<RunTests>d__49.MoveNext () [0x000bb] in <cd473063d3a2482f8d93d388d0c95035>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00026] in <12e76cd50cc64cf19e759e981cb725af>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) This exception is happened everytime you tried to add the LiquidEngineLV-T91 to the craft - and the part is vanishing because in the middle of the processing, this exception blowed up everything interrupting that chain of events I talked above, and some other code on KSP hits the "panic button" and get rid of the troubling part.
    The KIS Inventory module may or may not be related to the problem - it could be only an innocent bystander that was caught by the mess, or it may had contributed somehow to the problem.
    This Exception is weird because it's borking on UnityEngine.Object.GetName(UnityEngine.Object) what implies that the object the code is trying to get the name is no more - what suggests that the code believes it should exists, or perhaps the code should be dead by now (because its data is already dead) but someone forgot to kill it.
    And this is where that Exceptions above may have playing a hole on it - by blowing up their chain of events, they may be preventing things to be created, or preventing things from being cleaned up. Both hypothesis satisfy the working theory I proposed on the last paragraph.
    Well, so in a nutshel:
    1) File a bug report on Texture Unlimited giving this KSP.log. Then remove Texture Unlimited from your rig
    2) Do the same with System Heat.
    3) Remember to have everything backed up
    4) Try to reproduce the problem again.
    5) If the problem vanished, well, it was one of the two thingies above. Wait them to be fixed before installing them back - this can be a problem with System Heat.
    6) If the problem persists, then my best guess is KIS Inventory - reach KIS maintainer for help. But first get rid of Texture Unlimited and System Heat to make things easier for him.
    Keep me in the loop one way or another! Cheers!
  8. Lisias's post in Need help downloading Kerbal Foundries for KSP 1.11.1 was marked as the answer   
    Nice wallpaper!
    And I finally understood what's happening... You downloaded the wrong file (the -master thing means you download a dump of the GIT repository, not the actual release!)
    So, let's try to clear out the misunderstandings.
    you want to download Kerbal Foundries, the one maintained on this thread. You want to download the latest release, 2.4.8.16, from this page. Being specific,  you want this file. (KerbalFoundries-2.4.8.18.zip) You DON'T WANT the Source Code.zip neither Source Code.tar.gz. You are facing some problems on downloading things Since the Release zip should be somewhat smaller than the source tar balls, hopefully you will be able to download the correct file. But it is still ~54.3Mb.  So, try to download it using the "you want this file" link above, and if you don't manage to do it, I shove this file on the FTP of my server and I teach you how to handle FileZilla (an easy to use FTP cliente) to download it. FTP allows resuming files, so if anything goes wrong you can resume from where you were, instead of downloading it from the start again.
  9. Lisias's post in Tweakscale troubles-Please help!!!: What should my GameData and /or Tweakscale folders contain? was marked as the answer   
    Welcome!
    Since we are here, and since typing using only the left hand is something I'm getting used to  , let's go:
    Module Manager is a tool to allow us to patch some things on KSP.
    KSP was made using Unity, and Unity has a thingy called prefab where information about how to initialise Game Objects are stored (being a GameObject something used by the game, as a widget on the screen, a piece of code that handles that widget, etc). KSP adopted a very handy way to define the prefab for parts and some other things, the Config File. So, instead of compiling all the prefab into an asset file, KSP reads a bunch of CFG files and "compile" them at load time - and this allows us to virtually change almost whatever we want - and make no mistake, one of the reasons for the huge success in the past was exactly the extremely friendliness to modding.
    Additionally, Modules are collections of related code that implement a specific feature. By example, ModuleControlSurface is the module that implements the ailerons on the parts that we use for aircrafts and spaceplanes. TweakScale is another Module, where I shove my nose on every other module in existence to coerce them into scale things.  (TweakScale is a hell of a nosy guy, it's no surprise that when something borks, TweakScale gets some splash damage, as it's always around).
    Since changing directly the config files is a terrible idea (never touch anything you didn't wrote yourself when publishing things - unless there's no other way), in the beginning of time after the creation of Time and Light , one of the Founders created the Module Manager so people could write patches (receipts where you tell Module Manager what you want to change and how).
    TweakScale (and the kitchen's sink) needs Module Manager to add to the prefab the information it needs to run, as well to include it on the parts you want to scale.
    Without Module Manager, one would need to edit every single config file on the game to add TweakScale manually - about 730 on an vanilla game, and I'm not counting add'ons.
    I don't include Module Manager on TweakScale because distributing Module Manager on Add'Ons is a pretty stupid idea. You end up with tons of older, buggy Module Manager on the system, and now on KSP >= 1.8.0, multiple versions of Module Manager on the system is a terrible troublemaker situation (TL;DR : by a glitch on KSP and how ModuleManager's file is named, you end up running always the oldest version available on the system!!!).
    There're "integrators" around that built packages with some add'ons preinstalled - I don't have a problem with these, because the dude properly maintain the packages and issue a new release every time it updates something. But TweakScale is not a "bundle", it's a "feature package" and the only reason I include Module Manager WatchDog on it it's because everybody else shoves older Module Manager on the game all the time, and we need something to warns us about this.
    In the near Future I plan to build a "Bundle" myself, so people with complex installments and that don't like CKAN could have a easy first installation session (there're going to exist a lot of TweakScale Companions), but for now with the current cycle of releases, maintaining a bundle is too much of a hassle for me.
     
    Boy, it's only the most common mistake on having the Scale_Redist on the wrong place!!   
    Yes, it's plain terrible to have a GameData inside the GameData.
    Things appears to work at first, because some parts of KSP (and add'ons) don't care too much for where they are installed - but things start to get hairy when other things need to find your assets, as Module Manager.... By shoving the files on the wrong place, some things are not recognised by Module Manager, for example, and so they are not patched.
    It's the reason all my Add'Ons bark on you when they detected you installed them on the wrong place.
    (And, yes, I do it myself now and then too - a temporary brain fart, and you unzip the thing on the wrong place without being aware: it happens to everybody, so I coded the installment checks)
     
    KSP 1.11.4? Welcome, Time Traveller! How are things on the year 2022?? KSP2 was delayed again?
    Well, some things effectively beautifully borked on KSP 1.11.1 - frankly, I would recommend avoiding migrating ongoing savegames to it. Stay playing your current savegames on 1.11.0 , and only use 1.11.1 for new savagames. The 1.11.0 bugs are kinda manageable and some are even fixable (see KSP-Recall) - but there're some things on KSP 1.11.1 that it's plain impossible to fix without breaking forum rules (the "no reverse engineering" stunt).
    The problem I see with the deletion-fest is that most files are there for a reason, and removing the files that are borking also remove the features the files aim to implement.
    It's a pain in the SAS, but IMHO the best line of action for you is:
    Backup all your savegames There's a thingy called S.A.V.E. I strongly recommend everybody to use it (I do). Believe me, I break savegames all the time while testing new TweakScale features...   Rebuild your KSP 1.11.0 installment Or 1.10.1, if you skiped the 1.11.0 stunt After checking if everything is fine, KEEP IT SAFE. I never delete a working KSP installment, I still have my 1.4.5 one lingering here - just in case. And I still play 1.7.3 Now build a new KSP 1.11.1 one for the new savegames  
    Nah, I need to practice typing with my left hand!  
    (right arm is with a light case of tendinitis, so I'm preserving it)
     
  10. Lisias's post in RemoteTech configs applied without RT being installed? was marked as the answer   
    Wow, pretty extensive research, kudos!
    Found the problem:
    [LOG 20:00:14.231] Config(@PART[TrackBodiesTelescope]:FOR[RemoteTech]) REPOSoftTech/ResearchBodies/ResearchBodiesMMRemoteTech/@PART[TrackBodiesTelescope]:FOR[RemoteTech] [LOG 20:00:31.212] [ModuleManager] INFO: Applying update REPOSoftTech/ResearchBodies/ResearchBodiesMMRemoteTech/@PART[TrackBodiesTelescope]:FOR[RemoteTech] to REPOSoftTech/ResearchBodies/Parts/telescope/telescope/PART The file REPOSoftTech/ResearchBodies/ResearchBodiesMMRemoteTech.cfg is applying a patch with :FOR[RemoteTech], and so Module Manager thinks that there is, indeed, RemoteTech installed.
    Usually, :FOR is reserved to be used by that Add'On, but don't take it as an error for sure - I could think on one or two UseCases in which you need a patch to be applied at the same time that Add'On, as you don't know exactly when your patch would be applied using :AFTER and you need to be absolutely sure that everybody that would try to patch something on that part would have your patches applied first.
    Assuming this is the case, that patch should use :NEEDS[RemoteTech]:FOR[RemoteTech] I think. The :NEEDS would get rid of the patch if RemoteTech is not installed, and so the :FOR will not have a chance to run, and the RemoteTech symbol will not be created on the "add'ons installed" list.
    Otherwise, i think that :AFTER or just :NEEDS should be used.
  11. Lisias's post in Camera-tools doesn't appear on even earlier versions was marked as the answer   
    I'm using this one:
    https://github.com/jrodrigv/CameraTools/releases
    And it's working fine since 1.5 for me.
  12. Lisias's post in Craft Vibrates to Death on Separation was marked as the answer   
    Try using Austrut to GrandParent on every "spaghettied" part. It use to work for me.
  13. Lisias's post in Crashes upon reloading VAB/SPH/Launch excessively was marked as the answer   
    I'm a dumb SAS. Until now, I completely missed about this important piece of information besides being advertised ad nauseaum.  

    It's still a guess, but now a more informed one.
    Joysticks are not needed except on Flight Scenes. So, it's reasonable to assume that the XInput are "opened" when you enter the Flight Scene, and "closed" when you exit it/enter VAB, SPH, et all.
    It's also well known that our "friend" Unity just don't releases memory no matter what. And since it's well known its memory leakings, it's plain clear that memory footprint is aways on an ascent - what varies is the slop.
    So:
    User builds a plane/rocket. User enters Flight Scene XInput is "opened", and a memory buffer is allocated for it. User flies this toy Unity globs some more memory, raising the footprint a bit User goes to a non-flight scene (Mission Control, Tracking Station, whatever) XInput is "closed", and the current used buffer is released This memory is not under Unity's control User goes back  to flying XInput is "opened again". Since the previously used buffer was released and probably already reused for something else, a new buffer is allocated As the memory footprint grows, eventually this new buffer is allocated beyond the 4Gb boundary and then things goes KABOOM on 32 bits DLL.
    @Just Jim, I think we nailed down a deterministic Modus Operandi in order to reproduce the issue. A small custom part that "eats memory while flying" would speed up the process. Perhaps MemGraph could do the trick too.
  14. Lisias's post in (SOLVED)Crash when loading was marked as the answer   
    The X_Input is involveed on the crash log. There's a good chance that this thread can help you:
     
    @Just Jim, I think this may interest you.
  15. Lisias's post in KSP always crashes on opening was marked as the answer   
    KSP.log would help.
    But you probably installed that one too many mod (or a preexisting one was updated and used that one too much kilobyte more) and Unity blew up.
    Move out all mods from GameData (leaving just Squad* ones), and then move a few back each time while firing up KSP until it breaks again, and then you remove the last ones you tried and that's it.
    Move back in order of importance, so the least important ones are left behind. 
  16. Lisias's post in Module Manager 2.7.6 crashing my ksp (1.2.2) Please help immediatly! This is not false! was marked as the answer   
    I'm afraid you will have to find it for yourself.
    Open Source/Free (as in beer) Project developers rarely have financial resources to test the project on all the intended hardware targets - they rely on the user's feedback in order to do that.
  17. Lisias's post in Electricity Usage was marked as the answer   
    It's a wild guess, but perhaps the event in which the drill would be shutdown would be in the middle of that "100 secs deltaT", and so not detected. 

    Something like:
    In the simulation time 100000 (in game secs), you have 90 U of eletricity, your solar panels feed 5U por sec and your drill eats 6. So you will run out of E in 90 game secs You set warp to 1000. Now each tick is 100 game secs Now the physics will calculate the world for the simulation time 100100 You run out of E in 100090, but since this is "inside" one of that "dead zones" of deltaT, the event was not issued so the drill continued to work The game calculate the solar panel production, adds the E to the battery, and subtracts what the drill consumed But the drill theoretically had run out of juice in 100090, so it didn't subtract this 10 secs of consumption.  Congrats! You just earn 60 U of Electricity for free! :-)
×
×
  • Create New...