Gordon Dry

@Bishop149 want more confusion? I use TR 3.2.0.0 with the shaders.windows from TRR that was named "temporary fix for the pink visor reflections in 1.4.2" and I don't find that anymore - I guess the post was edited ... But it works, no pink visors.

@linuxgurugamer same

@linuxgurugamer ok, well then, I can do. (oh Unity, so much time)

@linuxgurugamer A brand new issue I never had before ... I use https://github.com/linuxgurugamer/Kerbal-Joint-Reinforcement/releases/tag/3.3.3.4 for some time now and today something weird happened. First I launched a vessel without issues and did a successful reentry (FAR, RSS, SMURFF, DeadlyReentry, RealHeat). Then I went to VAB to build another vessel. As soon as this is loaded on launchpad, BANG, it just explodes, I'm under the surface several thousand meters, BANG ... And this is kinda spammed to the log then (it appears multiple times with a lot of stuff inbetween): Exception handling event onVesselGoOffRails in class KJRManager:System.NullReferenceException: at (wrapper managed-to-native) UnityEngine.ConfigurableJoint:INTERNAL_get_angularXDrive (UnityEngine.JointDrive&) at UnityEngine.ConfigurableJoint.get_angularXDrive () [0x00000] in <filename unknown>:0 at KerbalJointReinforcement.KJRManager.UpdatePartJoint (.Part p) [0x00000] in <filename unknown>:0 at KerbalJointReinforcement.KJRManager.RunVesselJointUpdateFunction (.Vessel v) [0x00000] in <filename unknown>:0 at KerbalJointReinforcement.KJRManager.OnVesselOffRails (.Vessel v) [0x00000] in <filename unknown>:0 at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) NullReferenceException at (wrapper managed-to-native) UnityEngine.ConfigurableJoint:INTERNAL_get_angularXDrive (UnityEngine.JointDrive&) at UnityEngine.ConfigurableJoint.get_angularXDrive () [0x00000] in <filename unknown>:0 at KerbalJointReinforcement.KJRManager.UpdatePartJoint (.Part p) [0x00000] in <filename unknown>:0 at KerbalJointReinforcement.KJRManager.RunVesselJointUpdateFunction (.Vessel v) [0x00000] in <filename unknown>:0 at KerbalJointReinforcement.KJRManager.OnVesselOffRails (.Vessel v) [0x00000] in <filename unknown>:0 at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(Vessel) Vessel:GoOffRails() OrbitPhysicsManager:LateUpdate() (Filename: Line: -1) The vessel, the save, the logs and stuff: https://www.dropbox.com/s/dwxuwgpia60uxhj/2018-10-14_2 KSP.log and stuff.7z?dl=1

The paradox is: RO devs say"we wait for official FAR" FAR thread says "perhaps there will never come an 'official' FAR from Ferram" (so it's a community project now) ... So ... Ferram doesn't say anything, so who knows.

@Kitspace well, with "normal" MJ relases incl. devs I never even managed it to have the PEG enabled ... perhaps my install is always-borked. (But wait, I'm one of the best beta testers, I use mods). With the lamont-granquist versions I managed it really easily - with a well balanced craft (which is historically same-alike as real) I even managed it to recreate historic launches like Sputnik-2 with same parameters (but the date and time). And last but not least - I have read comments here and there that just said "the PEG in releases is non-functional" - when you say it works then you're lucky. Perhaps you don't use many mods.

That one does only work with the builds from lamont-granquist - who actually commited a lot to the main mechjeb repo within the last 12 hours or so. This means there will be a total overhaul of MechJeb coming soon I would say... correct me if I'm wrong But first comes first: https://github.com/lamont-granquist/MechJeb2/releases The "normal" releases habe a non-functional PEG, but here you can find latest devs: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/

... but how can an unmanned probe core with ModuleCommand fail the check and have IsRTPowered = false in the ModuleRTAntennaPassive that I patched in? The ModuleSPU got IsRTPowered = true btw.

@Manwith Noname perhaps it's just conflicting with "Vandest Shiny Stock Parts" so I remove that config folder and see then ...

Oh, sorry, I just have seen this in the MM cache and then assumed it: UrlConfig { name = parachuteSingle type = PART parentUrl = Squad/Parts/Utility/parachuteMk1/parachuteMk1 PART { ... Should have read that further ...

I added a decoupler shroud to a decoupler below a heatshield which was rescaled with TweakScale (the decoupler was not rescaled). On decoupling this was written to the log: Jettison called on DecouplerShroud of decoupler.ftr.small (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) NullReferenceException: Object reference not set to an instance of an object at DecouplerShroud.ModuleDecouplerShroud.Jettison () [0x00000] in <filename unknown>:0 at DecouplerShroud.ModuleDecouplerShroud.onShroudedPartChanged () [0x00000] in <filename unknown>:0 at DecouplerShroud.ModuleDecouplerShroud.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1) btw the decoupler was not automatically, I decreased the height of it to fit better.

@Manwith Noname in daylight (no direct sunlight in this case) the whole part is really dark, in a dark environment there is no reflection of the skybox at all (red gas clouds) and so it's pitch black. @Manwith Noname turned around, direct sunlight gets a reflection:

btw the Parachute part is solid black in flight scene after rescaling ...

I have a suspicion: When using TU_Stock and TU_Extra together with TweakScale, this can happen: [TweakScale Warning] Exception during stockTextureSwitch interactionSystem.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.ScalePart (Boolean moveParts, Boolean absolute) [0x00000] in <filename unknown>:0 TweakScale.Tools:LogWf(String, Object[]) TweakScale.TweakScale:ScalePart(Boolean, Boolean) TweakScale.TweakScale:Setup() TweakScale.TweakScale:OnLoad(ConfigNode) PartModule:Load(ConfigNode) Part:LoadModule(ConfigNode, Int32&) ShipConstruct:LoadShip(ConfigNode, UInt32, Boolean, String&) ShipConstruct:LoadShip(ConfigNode, UInt32) ShipConstruct:LoadShip(ConfigNode) ShipConstruction:LoadShip(String) FlightDriver:setStartupNewVessel() FlightDriver:Start() (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) The part in question is the stock NPV-06 Parachute which I scaled down ... and set to "All shiny". (craft in linked archive below) Perhaps this is also triggered by the same reason, perhaps it's something totally different: (I don't use RF or MFT actually) [TweakScale Warning] Exception during MFT interactionSystem.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.UpdateMftModule () [0x00000] in <filename unknown>:0 TweakScale.Tools:LogWf(String, Object[]) TweakScale.TweakScale:UpdateMftModule() TweakScale.TweakScale:CallUpdaters() TweakScale.TweakScale:Setup() TweakScale.TweakScale:OnLoad(ConfigNode) PartModule:Load(ConfigNode) Part:LoadModule(ConfigNode, Int32&) ShipConstruct:LoadShip(ConfigNode, UInt32, Boolean, String&) ShipConstruct:LoadShip(ConfigNode, UInt32) ShipConstruct:LoadShip(ConfigNode) ShipConstruction:LoadShip(String) FlightDriver:setStartupNewVessel() FlightDriver:Start() (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) Full log and stuff: https://www.dropbox.com/s/0i3o5k0qjvdfulf/2018-10-13_1 KSP.log and stuff.7z?dl=1