Lisias

Bicho, Paulistês arcaico, pra ser mais exato (I have a heavy accent from São Paulo from the 80's - gone live in Amazon as a kid, and lost contact with people around here, so I ended up "stuck' talking how people used to talk when I was a kid!! )

KJR/L works fine from 1.2.2 to 1.70, KSPe.dll too. The bug is not on KSPe, I did everything by the book, following C# specifications. And this is the problem - would be something I was doing wrong, I would had fixed it by now. The problem is your installment, where a dependency from something else is borking, and this triggers a critical bug on Unity's Mono implementation. But besides the problem being something else in your installment (probably a missing dependency), this problem is not a bug - it's just a mistake. The real bug is on Unity's Mono Implementation, that leaves its internal data structures in a inconsistent state if anything goes wrong! It's weird that such a stupid bug was left alone on a paid product for so many years, but yet… It's Unity. We need to get used to it. I'm currently reevaluating my options. Handing over Reflection (that thingy that I'm using and that's bugged) would forces me to reevaluate all my design - literally, almost everything would be thrown through the window. I made some small improvements on KSPe that would make just but faster on some functions (cache), and by collateral effect, would help to rely a bit less on Reflection - once the first try works, it's remembered and so when something else borks later, it will only affects new clients, and not the previous ones. Not a fix, but this can make some things work for a bit longer. But it's not a fix, and I out of time for playing KSP for these days - so, I'm not properly testing that release on a "production KSP" (my games), and so it would be dangerous to release this new KSPe now. Currently, only a few users with corrupted installments are unable to use it. I do something wrong on the new release, all of them will be unable to run the thing. My best advise is to fix your installment, solving all the ADD-ON BINDER Errors that are being issued with a following Exception (the ones without exceptions are safe). Being unable to do that, on the short term you need to avoid KSPe and anything that use it - so my second best advise to you would be use KSP-RO's fork.

Sharing violation is not a access rights issue, it's a code issue: more than one thread is opening the same file for writing at the same time. If the code really needs to be able to write to the file, then the code should use some locking mechanism to solve the dispute. If the code doesn't needs to write to the file, when it should open it on READ/ONLY mode. Of course, revoking writing rights to the file would workaround the problem as long as the library used fallbacks to read/only automatically (weird, but not impossible). But the problem are still on the code - by opening the file in R/O, or preventing more that one thread to open the same file you would fix the problem for good.

It's not cleat at this time what code is really suffering or causing the problem. There's a chance that the code would be all right in the algorithm, but is suffering a float point idiosyncrasy . See my previous post. Probably. But we could do a good educated guess, and then try a workaround on the code to overcome it. One thing that I think TweakScale lacks is a metadata that would tell the code when a number should not be negative, not zero, etc - and his happening, plain refuses to scale the part and that's it. It's essentially that Sanity Checks I'm implementing on the DryCostWrite on the prefab, but on runtime this time. But without metadata, such stunt can cause as much harm as the problem. Still thinking on this specific problem, by the way.

NaN can be issued by division by zero. Check first anything that is being used to divide something. My guess is a rounding error somewhere. Too small numbers can suffer underflows, and they are very common when using floats instead of doubles.

Perhaps a new feature on MacOS? GPU with automatic datamoshing! It appears to be related to something on Safari - only certains sites when opened triggers this. And it only affects 1.7.0, 1.6.1 and older are glitch free. Well… It's probably some bug on memory management on the MacOS X's OpenGL. Sometimes, the image being displayed is something from the browser.

You probably right, I don't play kopernicus often, and I missed this one . A patch should be trivia. Hopefully. i will update my task list when in home.

Your attention please!! Users of TweakScale that are also users of Infernal Robotics are advised to read this notice carefully. A unusual and weird condition was found on a very specific situation where a craft with some key parts under a determined scale crashes KSP. The crashes apparently does not corrupts the savegame, as long you quit immediatelly KSP and restart it. Recover the vehicle from the track station to prevent triggering the problem again (it happens when the craft us unpacked - loading the craft on the Editor has no issues). However, extensive tests are still needed to be sure on the matter. I tested this down to KSP 1.4.3 and the behaviour is consistent. This problems is triggered by scaling at least some parts to the size "Small -" (small minus, the smallest of them). It's not certain if this happens only under certain circumstances, or if the thing happens all the time. I never used the 'Small -" scale on my vessels - so I need more time to test the thing. Sorry for that. https://github.com/net-lisias-ksp/TweakScale/issues/39 — — — UPDATE — — — It's known for sure how the problem works. Thanks, @Rudolf Meier, for sharing the info with me. It's really a very specific issue that Infernal Robotics induces due the nature of the complicated things it does to accomplish its goal - not something that most parts would do. Being not exactly catastrophic (savegames are not being corrupted and can be easily salvaged), and being very rare on the wild (only Infernal Robotics is known to have to cope with this), it was not decided yet if a fix is feasible (or needed) by TweakScale. Since I already have the idea for a Runtime Sanity Check (and not only on the loading phase), I will keep this issue alive while I make my mind. Other than that, move on! There's nothing (more) to be seen here! — — — UPDATE — — — Infernal Robotics/NEXT fixed the problem. It's something inside the guts of the Physics Engine, the IR/Next now is checking against this issue. It's unsure if this can be prevented from my side, but I will study the @Rudolf Meier's solution and then I will try to figure out if it's possible from my side, and if positive. if it's feasible.

Ok. It's bug. It's a Unity glitch on a MacMini 2011 with shared memory GPU, that probably has a glitch too. So both glitches renders this bug. I totally understand it. But yet... THIS IS FUN AS HELL. I really need to learn how to do it on purpose!!! — — — POST EDIT — — — I found the source of the glitch! It's something on Facebook, that "3D Photos" new thing. if I open facebook with KSP running, the 3D photos became a complete madness, with some other window's graphics being used as textures. And then KSP got some weird texturing too!

@iGGnitE, as we talked on the KJR thread, this is the place to discuss the TweakScale problems I found on your KSP.log. Check the following issues, if you are curious about what's going on: https://github.com/net-lisias-ksp/TweakScale/issues/36 https://github.com/net-lisias-ksp/TweakScale/issues/37 https://github.com/net-lisias-ksp/TweakScale/issues/38 — — — — @Einstein_Cross_X1, your report will be handled on the reopening of the issue #11. https://github.com/net-lisias-ksp/TweakScale/issues/11#issuecomment-485591220

Igniting your fuel at launch. All of it. At the same time.

Today, is this one. I have some old pals in my friendship network! Nice. But I like the singer of this one more:

On this specific issue, that DLLs are borking right on the spot, so it's not related to MM for sure. Only wen you find a thingy called "Exception" inside Module Manager's guts, trying MM3 first can (but not always) help. AT-Utils is a Add'On from Allista: https://forum.kerbalspaceprogram.com/index.php?/profile/99885-allista/ I can't help on it for now, as I never dug on that code and so, I don't know what can be happening. Currently, I'm not using anything that uses AT-Utils neither, otherwise I could try something on my KSP to see what's happening. If you need AT-Utils, some Add'On you installed depends on it (there more than one), perhaps someone on that Add'On thread can help you too. If you use CKAN, you can try asking some directions there - that guys know better than anyone who depends on who around here.

Yep. Language barrier on the rocks! Nope. MM4 main feature is the ability to patch things at the same time the textures and meshes are being loaded. This saves some time, but bow and then something breaks. They are nailing down these glitches (if any is left), so it's still a good idea double check this before reporting problems. Other than that, MM3 should behave identically to MM4. TweakScale mangles some really critical parts of KSP. So, when something else confuses TweakScale, we risk letting things half done, or done wrongly. And when this happens, a lot of nasty things happens in consequence. Crafts that make KSC parts to explode at launch, parts that "anchors" the whole vessel on the spot and then by applying thrusts that part explodes due stress, and even living crafts on the savegame suddenly having the scaling reset. About At Utils, if you have them installed and yet they are borking, you need to ask support on their thread. I can't help as I don't know that code. Sorry.

There's a tutorial on the Wiki: https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Installing_Addons About the Add'Ons you need for sure: Multianimators and AnisotropicPartResizer are part of the AT-Utils https://github.com/allista/AT_Utils/releases You may also choose to rollback to Module Manager 3. MM 4 new way of doing things faster sometimes make something else to gasp - it's very rare, but usually when you see MM throwing an Exception, you should try MM3 first. If MM3 works and MM4 don't, then you file a report on MM thread - otherwise, it's almost sure that the problem is some rogue Add'On. The following are things that I also detected on your KSP.log, that wasn't related to your issue, but you probably want them fixed too: DynamicBatteryStorage is a [optional] dependecy for Kopernicus, and you need [may want] to install it to fully enjoy Kopernicus: https://github.com/ChrisAdderley/DynamicBatteryStorage/releases About TweakScale, initially I was thinking that you was using a older version but then I realized that I borked the DLL compilation. So the problem I found in your Log about TS is a new one, and it's serious. For now, just check if your engines (rescaled or not) have negative mass and avoid using them as the plague. After updating your KSP, please publish everything again (obviously, with new data! hehe) on TweakScale thread, as this is now TweakScale issue and we don't want to pollute KJR's one with unrelated data, as describe in the following threads: The Module Manager's cache is on the KSP/GameData/* and the files have ModuleManager on the name. Just shove everything but the DLL on a zip and publish it, I will find my way on it later.

I understood. I'm not feeling singed out, as myself suggested that move some time ago. Maintainability. From a Software Development point of view, mixing user data, application data and application code is just plain wrong. If you do a check on the vanilla KSP, you will see that Squad never did that - the savegames have their own place, the settings have their own file, etc, outside the GameData. Mixing everything is a receipt for disaster (who used MS-DOS and Windows 3.x knows that). You just can't update your Add'On without risking losing your custom configuration data. And by carefully updating only the files that are not user configuration, you risk missing some new options implemented on the newest version. It's a plain nightmare. I don't have this problem. An update for me is always a delete from GameData, followed by a clean unzip on it. All my configuration is safe outside. This makes backups insanely easy too: just backup the PluginData, and you are done. ------------ oh, yes. KSP API Extensions... KSPe is a subcomponent of mine, where API Extensions is the whole shebang. I'm playing with some really old Add'Ons, and it was easier to update it than to update everything else. I found no reason to create yet another Add'On for the same task, so I decided to develop the new Extensions I mentioned above on it.

While I disagree that unzipping two files into KSP root is convoluted, it's nice to have something what copes better with corrupted instalments - the only situation where KSPe + KJR/L is known to Bork. Keep in mind that I support only my fork. ;-) What's make me consider moving my fork from the current file system position to be inside a "vendor directory" (KSP_ROOT/net.lisias.ksp/KJR), otherwise I risk having this other fork stomping on my feet (and vice versa) , as they are adding changes on the config XML file. Any thoughts?

Learnt something new today. Space is not limited by speed of light. Only matter and energy are. How gravity would be affected by this? https://www.forbes.com/sites/startswithabang/2019/04/20/ask-ethan-how-can-a-black-holes-singularity-spin/amp/

Well, I want to register this somewhere, but I don't know where. So, since I was working on TweakScale, why not here? Someone, somewhere, is adding a "rogue" config into Squad's folder. I found what follows on my 1.6.1 test bed: macmini:GameData lisias$ find . -name "*.cfg" -exec grep -l "name = adapterLargeSmallQuad" {} \; ./Squad/Parts/Structural/adapterLargeSmallQuad/adapterLargeSmallQuad.cfg ./Squad/Parts/Structural/stackAdapters/adapterLargeSmallQuad.cfg ./Squad/zDeprecated/Parts/Structural/adapterLargeSmallQuad_v1/adapterLargeSmallQuad.cfg Well… "Gato escaldado…" So I deleted my test bed and took a fresh one from my local repository and redid the tesst: macmini:GameData lisias$ find . -name "*.cfg" -exec grep -l "name = adapterLargeSmallQuad" {} \; ./Squad/Parts/Structural/stackAdapters/adapterLargeSmallQuad.cfg ./Squad/zDeprecated/Parts/Structural/adapterLargeSmallQuad_v1/adapterLargeSmallQuad.cfg Usually, I would pinpoint myself as the culprit on a unattended drag and drop, but this would move the file, not copy it. And the file contents on the "stackAdapters" were vastly different from the other two ones. So if I did it, I did from another completely unrelated place - unlikely, but not impossible. Since it's my test bed for 1.6.1, until recently the KSP mainstream, this poor installment had some really bad times on Add'Ons testing. So I'm placing my bets on a rogue Add'On mangling Squad's territory. Some more research work is scheduled for this week. This need to be solved, such rogue config is messing up the default parts. I will, of course, check first if it's something I did by accident, and then I will pursue whatever did this and report a change request to the maintainer (assuming it wasn't me. )

It's the same from my side. We will have to agree on disagree on this matter. Respectfully, I have the impression you doesn't fully understand some Software Development concepts. Not meant to be rude, just trying to express an opinion. LGG is an important Maintainer on this community, but it's not wise to behave as he would be the only one. Things we do affect other people's lives. Saving a minute of mine at expense of many minutes of many other maintainers is not exactly team work on my book.

People will use what serves them best. On Open Source you just can't force them to something they don't want, as they will just fork the thing and you will see your users going away. Yes, they are paying nothing to you - we usually rely on donations and patronage. However, if people fork your project and start to use the fork because it serves them better, you will see that the same people will have less reasons to keep supporting you. You also forget that we, Add'On Authors and Maintainers, are players too. We do play KSP too. Non authoring players are not the only one being beneficed by the works. And we, too, want to expend less time fixing things that are not broken without a good, compelling reason - as this would hinder our free time to expend it on the really pressuring issues - as showstoppers bugs and new features. Or plain playing KSP. Some fixes are worst than the problems they aim to fix. This is probably one of these for the majority of the cases (but not all, as I had tested and proved on my Experimental forks).

I jumped from the bed , this error is a serious showstopper! So apparently you managed to find a new way to get this error. I will check the log with care. I just checked your log, and you are not using the latest . The latest, 2.4.1, fixes some more issues, and I think yours can be one of them (the hint being some non scaled parts also triggering the Anger of the Kraken). Please update and check again the same crafts. Publish the new KSP.log and Module Manager caches too, if you find the error again.[You are using the latest, I borked on the DLL version info!!!] Assuming I detect a new problem with your current KSP.log and MM caches, and/or you report he same happening on 2.4.1, 2.5 will be put on hold and I will issue a new 2.4.1.1 just for this fix the fastest I can. Thanks, dude. I really appreciated. I can't always respond as fast as I wish due pressuring issues on Real Life (tm), but we (not just me) do whatever we can to keep you flying safe. (or as safest as it would be fun to fly!! )

Simple answer: serving a good service, without promoting unnecessary breakage. It's already harsh when you promote a needed breakage - you do it just because, and you start to loose users. There's no need for a Maintainer for Add'Ons that no one wants to use.

Jesus Christ! Something like this issue? https://github.com/pellinor0/TweakScale/issues/83 Yes, this is somewhat serious, as this error propagates into the launched vehicles and "contaminates" your savegames. I urge to stop playing this savegame now, and send me your KSP.log as soon as you can, as well the Module Manager caches. All of them (just in case). Are you using the latests TweakScale? (2.4.1.0) If not, please update as soon as you can. See the OP for details, read all the read notices and links. Backup everything, as the code isn't aways able to correcly fix the issues it find, and manual intervention ends up being necessary to salvage your savegame. Load and save every craft before using them again with the latest version. Crafts with this problem will sooner of later induces the near statics to blow up, due the propagating of NaNs related to a badly instrumented Part with variants with mass. There's no other safe measure than to update to the newest and take the hit of such parts having their TweakScale support withdrawn (savegames with parts using these "contaminated" parts will have the parts reset to default, so backup your savegames). This is unhappy, but it's the only safe option until the release of TweakScale 2.5, currently being cooked.

KJR/L is dependent of KSPe, and KSPe is known to bork due a serious bug on Mono's runtime, when a DLL is loaded as dependency of other, and it fails by some reason (usually, by not be installed). And this is 99% of the reasons people ask for support on KJR/L and, well, there's some of there problems on your KSP.log: [LOG 18:52:32.184] AssemblyLoader: Loading assembly at C:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\[x] Science!\[x] Science!.dll [LOG 18:52:32.208] AssemblyLoader: Loading assemblies [ERR 18:52:32.249] ADDON BINDER: Cannot resolve assembly: 001_AnisotropicPartResizer, Culture=neutral, PublicKeyToken=null [ERR 18:52:32.249] ADDON BINDER: Cannot resolve assembly: 001_AnisotropicPartResizer, Culture=neutral, PublicKeyToken=null [ERR 18:52:32.251] AssemblyLoader: Exception loading 'MultiAnimators': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly '001_AnisotropicPartResizer, Version=1.2.0.4, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: '001_AnisotropicPartResizer, Version=1.2.0.4, Culture=neutral, PublicKeyToken=null' and: [ERR 18:54:35.625] [ModuleManager] Post run call threw an exception in loading 002_MultiAnimators, Version=1.1.0.2, Culture=neutral, PublicKeyToken=null [EXC 18:54:35.626] ReflectionTypeLoadException: The classes in the module cannot be loaded. System.Reflection.Assembly.GetTypes () ModuleManager.PostPatchLoader+<Run>d__16.MoveNext () UnityEngine.Logger:LogException(Exception) ModuleManager.Logging.UnityLogger:Exception(String, Exception) ModuleManager.Logging.ModLogger:Exception(String, Exception) ModuleManager.<Run>d__16:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) The previous problems appears to be the root cause (until the moment, only exceptions that follows a "[ERR hh:mm:ss.mmm] ADDON BINDER" style are confirmed to break things). Install the Add'Ons that provides that DLLs and you should be good. The following ones (until the moment) are not confirmed to be problems (usually, fixing the above ones solves for good). But you probably would want to fix them, as you installed the Add'Ons for a reason : [EXC 18:52:33.029] TypeLoadException: Could not load type 'System.Runtime.Versioning.TargetFrameworkAttribute' from assembly 'DynamicBatteryStorage'. System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) System.Reflection.Assembly.GetCustomAttributes (System.Type attributeType, Boolean inherit) Kopernicus.LogAggregatorWorker.Awake () UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>c__Iterator1:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>c__Iterator0:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>c__Iterator0:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) In time, apparently ModuleManager is taking some hits from the same problem. I suggest you confirm this with the MM guys; [LOG 18:54:35.539] [ModuleManager] #### BEGIN MODULEMANAGER LOG #### [EXC 2019-04-21 18:52:39.949] System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at ModuleManager.ModListGenerator.GetAdditionalModsFromStaticMethods (IBasicLogger logger) [0x00000] in <filename unknown>:0 [LOG 2019-04-21 18:52:40.001] Checking Cache I also found some more on the Log, and these ones are "safe". I'm posting them here to document them - you can ignore them unless you decide yo want that features. [ERR 18:54:35.763] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null [ERR 18:54:35.763] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null [ERR 18:58:31.700] ADDON BINDER: Cannot resolve assembly: RecoveryController, Culture=neutral, PublicKeyToken=null [ERR 18:58:31.700] ADDON BINDER: Cannot resolve assembly: RecoveryController, Culture=neutral, PublicKeyToken=null Finally… (sigh) I found a Exception on the prefab phase of TweakScale (and this one I support directly). I noticed that you are still using TW 2.4.0. I recommend you to use the 2.4.1, that added a few small features and fix a nasty problem. If after updating this exception persists, please kick me on the TweakScale thread. [EXC 18:58:04.469] NullReferenceException: Object reference not set to an instance of an object PartModuleList.Contains (Int32 classID) PartModuleList.Contains (System.String className) TweakScale.PrefabDryCostWriter.checkForSanity (.Part p) TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) This exception, by its nature and location, it's a clear example of Kraken Food (see my signature ), but chances are that the changes I did on 2.4.1 would be beneficial to you. (Faith programming, dude! ) — — — POST EDIT — — — — I just came my attention that I borked beautifully on the DLL versioning. (sigh). You are using the latest, my apologies. Please be in touch on TweakScale Thread about this specific issue. There's a new bug in town, TS 2.4.1.1 will be issued soon.