Lisias

I think there's something cheesy (again) on Unity. The crash is happening on the DirectX itself... d3d11: attempt to lock null buffer d3d11: attempt to lock null buffer d3d11: attempt to lock null buffer d3d11: attempt to lock null buffer d3d11: failed to create buffer (target 0x1 mode 3 size 9040) [0x887A0005] Crash!!! Your Graphics Card is not bad, but I think it needs a bit more of VRAM GfxDevice: creating device client; threaded=1 Direct3D: Version: Direct3D 11.0 [level 11.1] Renderer: NVIDIA GeForce GTX 1060 3GB (ID=0x1c02) Vendor: VRAM: 2988 MB Driver: 26.21.14.4614 4GB is the best option nowadays due the new textures. But yet, you didn't installed any add'ons but QuickModes and KAC (besides Squad and the two DLCs), so this is not the problem for sure. In a way or another, without graphical enhancements add'ons as Scatterer et all, all you have running that could blow up the graphics driver is Squad's and Unity's code. Perhaps you found a new (mis)behaviour for the Unity Particles bug?

Dropbox is a service in which you upload a fiile, and then it gives you a link so you can send the link to people so they can download the file. It's like the service you used to upload that image, but instead of a imagem, you upload the KSP.log in full. I found this video, I hope it helps I know the feeling. About this subject, I will follow up on that thread!

Your mileage will vary, but usually you will have all the scaled parts reset to the default size, inclusive the living ones on Flight. Very entertaining on flying crafts - a shame that it also renders the savegame kaput beyound repair. There're some (synthetic) samples on Issue #137. Attention: utter carnage alert, opening the Spoiler is discouraged for the faint of heart!

I need the FULL KSP.log. The two liners you gave me tells that a part is broken, but I don't have any other information (what else is installed? How MM patched things? There're exceptions on some key parts of the game loading?). Please post the FULL KSP.log on dropbox or similar service.

There's nothing I can add to what @kcs123 already explained, you really should not use the KSP installment managed by Steam (or GoG, or anything else). And I tried, with really tragic consequences - spent 10 days fixing the damage (why do you think I'm so used to diagnosing these problems? ). But there's some hints I can give you: If you are on Linux, format a BTRFS partition for your games, including the ones managed by Steam. Then copy it with deduplication (cp --reflink source target). If you are on Mac, format a APFS partition for it. Then use Finder for the copying, as it automatically use reflinks on copies on the same volume On Windows 10, there's ReFS - but I have no (still useable) knowledge on Windows, so I can't help. Deduplication is simply the best thing one can have on a filesystem, better than transparent compression: it saves a lot os space for us, KSP heavy users. I have many copies of the same KSP with small variations due testing, and deduplication literally saved my SAS on this. If you use an SSD or M2 or something, the savings are even more noticeable, being the difference on doing the job on a cheap 240G one or having to sell your eyes (the three of them) for a 512 or 1Gb one. I'm on a personal crusade fighting this absolutely terrible practice. The GameData should be sacred land.

Announce TweakScale 2.5.0.29 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens. We are finally changing variants correctly when the part is scaled! #HURRAY. But... Now I'm struggling with Symmetries... So, we still have some issues. Please read the Known Issues file. Attention please: The problem on attachment nodes on KSP 1.9, obviously, still persists. I will update KSP Recall (where the problem will be mitigated) as soon as I manage to fix that annoying and persistent problem with the attachment nodes from parts with variants... Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!).

Probably, but with some reserves. You shouldn't have anything bigger than the Physics Range, or things start to blow into space in the most unpleasant way. The problem is that Unity is a game engine, not meant for scientific calculations. So, due performance concerns, Unity uses floats everywhere instead of doubles - and since floating points on computers have a problem with precision as the magnitude raises, sooner than later the Physics Engine can't tell anymore if a part is 1cm or 100cm from another - and this is where everything starts to blow up. Had Unity adopted doubles, we could have crafts the size of the Kerbol System - but by then the game would be 30% slower on the CPUs of that era for everything - KSP was born on the 32 bits era (as Unity, by the way). Do you want to hear something ironic? Doubles are faster on CPUs using X86-64 architectures. But since, on GPUs, floats are way faster than doubles, and since Unity is game centric, I think it's unlikely that Unity would ever refactor the Physics Engine to use doubles. So we have a hard limit about the size of a physics enabled part on KSP (it's the reason we can't built space elevators with standard parts on KSP, by the way). What you intent to do should be possible using statics and custom modules for the few moving parts.

Call me nuts (as nuts I am), but I have these musics on my head today. (Wondering if this have something to do with me spending the weekend playing Stryder on my old Mega Drive... )

And that was a hell of a good guess! @Adoelrome, KAX needs Firespitter for some functions, it's a dependency. Lots and lots of things depends on FSplanePropellerSpinner, FSswitchEngineThrustTransform and FSEngineSounds. (And, yeah, I would had noticed it faster and easier with the full KSP.log of the problem). The parts are not working as intended on your installment, by the way... You should really install Firespitter.

Interesting... Oukey, time to burn some time from the lunch and do a test. KSP 1.11 is on the corner already! -- hack hack hack - reboot! - hack hack hack -- Yeah, @boribori is right! @Adoelrome, this is an excerpt from my KSP.log from my KSP 1.10.1 test bed: No NullReferenceException! It worked fine on my rig. Cristal clear! Thanks for the heads up, @boribori! You saved me some debugging time! @Adoelrome, I misdiagnosed your case. Please send me the whole KSP.log so I can try to figure out what's borking your KSP instalment. It's not KAX for sure, but it may be something KAX uses - or something that changes KAX in a way that lead to the bork. In a way or another, I need the full KSP.log in order to diagnose the problem.

News from the Front. Hi, this is a report for the present state of affairs on TweakScale Beta 2.5. There's something cheesy on Variants with variable attachment points and/or model changing. The code I wrote appears to work fine when the parent part is a plate, but not when the parent is a cabin or a tube (and probably many more parts).[Edit: Cheesiness detected - dirty (unix) socks. ) More on the github's issue 42. On the (kinda of) bright side, that new rig of mine arrived Monday - however the dealer had shipped with the wrong motherboard and I had to return it. By the time it was (re)delivered, I got no more time to play hardware due RL, and everything is delayed... (sigh). Life can be cruel.

KAX is fully supported from KSP 1.3.1 to 1.7.3 . KAX is known to work fine from KSP 1.8.0 to 1.9.1 - at least, I didn't got any issues on the minimalistic tests I did. But since these tests were minimalistic, I refrain myself from advertising it as fully supported on these KSP versions. KSP 1.10 was currently unknown, until your report. Now I know it doesn't works. This will be tackled down as soon as I managed to kick TweakScale 2.4.4.0 through the door.

this is what I call old school!

Someone call by my (second) name? I'm sorry answering in English, but my Castelhano/Spanish is... uh... absent. Too much chances of writing something bad due false cognates due PT-BR being my mother-tongue. (google translate follows). There's a thing on TweakScale called ScaleExponent, where we teach TweakScale how to scale a Module. This is the "code" that tells how ModuleCoreHeat to scale. Problem, it's not working exactly as we think it should. There're more information on this post. There's a chance this is the problem affecting "radiadores no plegables". I'm currently taking a small break from R&D the Variants on TS 2.5 (there's a recent beta for who don't mind taking risks and are willing to help testing it), I can try to tackle down this one in the mean time. Can you please send me the smaller craft you can build with the problem for analysis? This will help me to diagnose that's happening, and so I can try a fix if it's something on TweakScale. -- -- -- ¿Alguien llama por mi (segundo) nombre? Lamento responder en inglés, pero mi Castelhano / español és ... eh ... ausente. Demasiadas posibilidades de escribir algo malo debido a cognados falsos debido a que PT-BR es mi lengua materna. Hay algo en TweakScale llamado ScaleExponent, donde enseñamos a TweakScale cómo escalar un módulo. Este es el "código" que dice cómo ModuleCoreHeat escalar. Problema, no funciona exactamente como pensamos que debería. Hay más información en esta publicación. Existe la posibilidad de que este sea el problema que afecta a los "radiadores no plegables". Actualmente estoy tomando un pequeño descanso de R&D de las variantes en TS 2.5 (hay una versión beta reciente para quienes no les importa correr riesgos y están dispuestos a ayudar a probarla), puedo intentar abordar esta mientras tanto. ¿Puede enviarme la nave más pequeña que pueda construir con el problema para su análisis? Esto me ayudará a diagnosticar lo que está sucediendo, por lo que puedo intentar una solución si es algo en TweakScale.

Announce TweakScale 2.5.0.27 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens. This is a maintenance release, fixing that stupid (but nasty) bug on Chain Scaling. We still have some issues, please read the Known Issues file. Attention please: There are still glitches on parts as the Mastodon when changing Variants after scaling. Detaching and reattaching the part solves it but hell, this is annoying. The problem on attachment nodes on KSP 1.9, obviously, still persists. I will update KSP Recall (where the problem will be mitigated) as soon as I manage to fix that annoying and persistent problem with the attachment nodes from parts with variants... Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!). Happy Scaling!

And I wonder if all of this has something to do with Star Theory being sacked...

These are harmless (and so I call them Warnings). As KSP changed in time, some features changed too with new rules to cope with. TweakScale learnt to identify some of these changes (and not only from KSP, to tell you the true), and withdrawn itself from these parts (as it would end in disaster). These situations were being tackled down in the last year, and this one is exactly what I'm working on these days. Variants are a "new" kind of mechanism (new on quotes, this stunt born on 1.4.1 and was revised on 1.4.4) that aims to cut down the pletora of parts on the game, allowing you to choose a part to attach and then a sub-model of that part, what some people find easier to cope than selecting from 3 discrete but similar parts from the palette. Problem is that this Variant thing broke a lot of flows and expectations that we had for granted until 1.4.1. Things that never changes after edited started to change, things you did started to be undone, and all of these affected not only TweakScale, but a lot of others add'ons - that, by their turn, affected TweakScale (as this nosy add'on fiddles with everything and everybody and if one of these borks, TweakScale borks together). Since unfortunately TweakScale when borks (or it's borked) leaves the craft on a inconsistent (or sometimes game endangering) state, at that time the only sensible counter-measure was to withdraw TweakScale from parts those configuration is known to bork TweakScale (as multiple fuel switches being patched on the damn thing - what rendered TS without knowing what fuel switch is the dominant one - this still happens nowadays, by the way, and this is something that TS can't fix). That's the thing: someone have to carry on the tasks, otherwise the job will not be delivered. In the past few years, too much people around here decided not to lose too much sleep on something - and the net result is that some others had to lose a lot of sleep to cope with the mess. It's a matter of commitment. I'm committed to deliver TweakScale in a useful and safe way, and if the only way to do it is to lose some sleep, so be it. I had put my name on it, after all. On the bright side, these late betas are tackling down the last really harsh problems left. Once I finally fix these ones, everything else will be way easier - (at least, until something drastically changes again on KSP...)

Announce TweakScale 2.5.0.26 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens. This is a maintenance release, further implementing applying Variants on scaled parts. We still have some issues, please read the Known Issues file. Attention please: There are still glitches on parts as the Mastodon when changing Variants after scaling. Detaching and reattaching the part solves it but hell, this is annoying. I found a new (serious) bug on Chain Scaling that can lead to a crash on older KSP and serious mishaps on newer ones. Some vessels, as the Stock Aeris 4A, are borking relentlessly on Chain Scaling. Some others work fine, as the Stock Aeris 3A. A fix is on the works, but until there use Chain Scale with... caution (and some prayers). The problem on attachment nodes on KSP 1.9, obviously, still persists. I will update KSP Recall (where the problem will be mitigated) as soon as I manage to fix that annoying and persistent problem with the attachment nodes from parts with variants... Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!). Happy Scaling!

Perhaps, but not only. Divisions by Zero, multiplication by Infinity or NaN, all of these summon the Krakens on the game. It's related to the Physics Engine, not to the choices made by Squad - any misbehaving Add'On can inject such anomalies on the Physics Engine, by the way - and besides Squad had closed some doors on it, there're many more. Unity has serious flaws, most of them created by inexperienced developers hired by Unity. Right now, KSP >=1.8 is plain crashing to the desktop due a serious bork on the particle systems on some newer GPUs (older GPUs, by some reason, are imune to the problem - oh, irony!!). It's fixed by now, but KSP needs to update the Unity engine to have it fixed for it. This was a pretty serious regression, that should not had reached the mainstream - the conclusion is that Unity's development process is... insufficient. And insufficient processes leads to bad products. It was I initially my thought. However, besides the inherent flaws from Unity, I think it is also one of the reasons for KSP's success - at least until the KSP 1.3 times. Unity is far from being the best Engine available (IMHO), but it's popular, it's easy and I don't think we would have so many Add'Ons available if people had to develop using Unreal and C++.

Joke aside, in the last 2 weeks I'm having a bad time on my gentoo based server (a lab for new distros). Some packages are being withdrawn in the last 2 years because "they are not receiving new releases", blatantly ignoring the fact that no new releases are being issued because no new bugs were reported - what's completely different of no having people using them (I was). It's pretty uncomfortable to maintain my own overlay to keep basic (but, granted, uncommon) things that I think should not had be withdrawn from the main repository without a good, technical reason. Otherwise, the error was in accepting such packages on the mainstream at first place.

The message is harmless. At that time, I was trying to diagnosing an issue (that ended up being a "new" feature on KSP) and shoved this message on the log to be aware when a part using TS was deactivated. Problem is that TS can be externally or internally deactivated (I deactivate TS when the part is not scaled, to save some CPU cycles - this is an "internal" deactivation), and when I fixed the original problem, TS lost the ability to tell internal from external on deactivation. Please ignore these messages. They will be ripped off on the next release. There're a lot of Exceptions on this rig, from different subsystems. Try to rip off Scatterer from the instalment, most of these exceptions appears to be related to visual effects. What I think that may be related is SimpleFuelSwitch: Exception handling event onVesselLoaded in class FlightBehaviour:System.NullReferenceException: Object reference not set to an instance of an object at SimpleFuelSwitch.ModuleSimpleFuelSwitch.OnShipLoaded () [0x00018] in <83adba40348745b29af7ae28ff479c61>:0 at SimpleFuelSwitch.ModuleSimpleFuelSwitch.OnVesselLoaded (Vessel vessel) [0x0001f] in <83adba40348745b29af7ae28ff479c61>:0 at SimpleFuelSwitch.FlightBehaviour.OnVesselLoaded (Vessel vessel) [0x00000] in <83adba40348745b29af7ae28ff479c61>:0 at EventData`1[T].Fire (T data) [0x000b0] in <c1858a3f77504bd1aaa946fdccf84670>:0 <cut> Module ModuleSimpleFuelSwitch threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object at SimpleFuelSwitch.ModuleSimpleFuelSwitch.OnStart (PartModule+StartState state) [0x0000d] in <83adba40348745b29af7ae28ff479c61>:0 at Part.ModulesOnStart () [0x00120] in <c1858a3f77504bd1aaa946fdccf84670>:0 This may be borking a chain of events, and some add'ons may not being initialised after this exception. Whatever is happening on your rig, is stomping toes on everybody... KerbalEngineer -> Exception // System.NullReferenceException: Object reference not set to an instance of an object at KerbalEngineer.Flight.Readouts.Surface.ImpactProcessor.Update () [0x007d9] in <df610534f02e44eabb2fe7c95c06a0aa>:0 at KerbalEngineer.Flight.FlightEngineerCore.UpdateModules () [0x0002d] in <df610534f02e44eabb2fe7c95c06a0aa>:0 As well KSP itself, apparently: ActiveJoint.Terminate Exception while setting drive mode: System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Transform.InverseTransformDirection_Injected(UnityEngine.Transform,UnityEngine.Vector3&,UnityEngine.Vector3&) at UnityEngine.Transform.InverseTransformDirection (UnityEngine.Vector3 direction) [0x00000] in <5aeafee3fea24f37abd1315553f2cfa6>:0 at ActiveJoint.getControlOrt (UnityEngine.Vector3 refAxis, PartSpaceMode mode) [0x000aa] in <c1858a3f77504bd1aaa946fdccf84670>:0 at ActiveJoint.applyCoordsUpdate () [0x00008] in <c1858a3f77504bd1aaa946fdccf84670>:0 at ActiveJoint.SetDriveMode (ActiveJoint+DriveMode m) [0x0010e] in <c1858a3f77504bd1aaa946fdccf84670>:0 at ActiveJoint.Terminate () [0x000a1] in <c1858a3f77504bd1aaa946fdccf84670>:0 And so goes on. From that point, PilotAssistant and TweakScale are, almost surely, just another victims from the root problem. Besides annoying, that Warnings from TweakScale are telling me that at least that parts are not involved on the mess, since TweakScale is deactivated on them - humm, this message ended up being useful after all. The last problems on the KSP.log, and I'm wildly guessing they could be the triggers for the crash, is a series of these messages: BoxColliders does not support negative scale or size. The effective box size has been forced positive and is likely to give unexpected collision geometry. If you absolutely need to use negative scaling you can use the convex MeshCollider. Scene hierarchy path "ServiceBay.250.v2/strutCube/model/cubestrut" I checked, and these parts have TweakScale deactivated. But, again, this can be completely unrelated - it could be only harmless messages (like mine "TweakScale deactivated" ones) that had the bad luck of be issued just before the crash. On the bottom line: Remove Scatterer (as there're a lot of exceptions coming from Effects related stuff) Remove SimpleFuelSwitch -- -- -- Humm... Remove EVE too. I think it may be involved on the mess because of this: The rationale is what follows: When KSP calls a handler for a callback, it usually does something like this: try { foreach (PartModule pm : GameEngine.GetModulesFromCurrentVessel()) { pm.OnSomeCallbackCall(parameters); } } catch (Exception e) { Debug.LogExpcetion(e, "Whoops, something borked here...") } When this happens, all the PartModules that would be called after the borking one are ignored (since the code was aborted), and the game enters into an inconsistent state (and so, something else end up blowing up later due invalid data, and taking the blame!). One way to prevent that is to shove the try catch inside the foreach loop, but that comes with a cost: the try catch stunt is expensive, as it creates a new context on the stackframe on enter, and destroy it on exit - and this will tax the frame rate. So shoving it outside the loop is the less worse way to detect problems and log them to be diagnosed later, when something blows up somewhere else. On every exception logged on your Player.log, you will note that it happened inside a Callback (OnVesselLoaded, etc). And on every one of them, something lke this can had happened, and so you could have a lot of inconsistencies on the KSP's internal data structures (some things were updated, others don't). And from that point, Kraken knows who will get ellected to blow up...

Are you using Steam or GoG? On Steam, the download and install process is seamless and it uses its own protocol. On GoG it's a big zip file, but GoG also handle things itself. Both intall things inside your home directory, so no admin rights needed. I don't know about the KSP Store, however.

Things started to go down the tubes here: [WRN 12:52:05.968] CelestialBodyTransform: Cannot find CelestialBody. [LOG 12:52:05.971] lcScatterList [EXC 12:52:06.036] Exception: Failed to load Body: Erikson Kopernicus.Configuration.Loader.Kopernicus.ConfigParser.Interfaces.IParserEventSubscriber.PostApply (ConfigNode node) (at <0882401b48d84227ad9c2bbcf4ce8401> :0) Kopernicus.ConfigParser.Parser.LoadObjectFromConfigurationNode (System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) (at <698cce273aaa41f09ce80d0801f868a2>:0) Kopernicus.ConfigParser.Parser.CreateObjectFromConfigNode[T] (ConfigNode node, System.String configName, System.Boolean getChildren) (at <698cce273aaa41f09c e80d0801f868a2>:0) Kopernicus.Injector.Awake () (at <0882401b48d84227ad9c2bbcf4ce8401>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) Kopernicus.Injector:Awake() 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) [WRN 12:52:06.062] DontDestroyOnLoad only works for root GameObjects or components on root GameObjects. And I'm guessing this can be the reason for Kopernicus borking on loading the GUI Ready thing: [LOG 12:52:26.571] [CM] Adding main icon to toolbar [ERR 12:52:26.575] Exception handling event onLevelWasLoadedGUIReady in class <>c:System.NullReferenceException: Object reference not set to an instance of an o bject at Kopernicus.RuntimeUtility.StarLightSwitcher+<>c.<Start>b__2_1 (GameScenes scene) [0x00005] in <0882401b48d84227ad9c2bbcf4ce8401>:0 at EventData`1[T].Fire (T data) [0x000b0] in <9d71e4043e394d78a6cf9193ad011698>:0 [EXC 12:52:26.578] NullReferenceException: Object reference not set to an instance of an object Kopernicus.RuntimeUtility.StarLightSwitcher+<>c.<Start>b__2_1 (GameScenes scene) (at <0882401b48d84227ad9c2bbcf4ce8401>:0) EventData`1[T].Fire (T data) (at <9d71e4043e394d78a6cf9193ad011698>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(GameScenes) <FireLoadedEventGUIReady>d__45:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) From that point, your log is filled with Kopernicus borking on the LateUpdate: [EXC 12:52:26.582] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () (at <0882401b48d84227ad9c2bbcf4ce8401>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) But I'm pretty sure this happens due something not being initialised correctly after Kopernicus borks on the UI Ready thingy. Try to remove Erikson from the planet pack to see what happens. If the problem "vanishes", we can try to figure out what's borking by looking on this planet files.

News from the Front. Hi, this is a report for the present state of affairs on TweakScale Beta 2.5. I have 95% of the tasks carried on, or almost done. But... That pesky 5% is getting into my nerves - the whole story is on the #42 Issue, specifically here, here and here. Currently, I'm finally being able to apply variants on a scaled part: But "unapplying" the variant still need some work... As I explained on the Issue #42, using my current rig for Research & Development for KSP is getting problematic, and this is the main reason I'm taking so much time to tackle down this one. However, I managed to grab a new rig on a affordable price, and that machine will speed up things a lot for me, so with a bit of luck, the next TweakScale will be released "soon". Cheers!

uh, not this time! I slept the whole day today. @Dat Kerbal Dude, are you around?