Lisias

Bad patches break stuff. It's some time since a bug on TweakScale was doing breakage. All the bugs I'm detecting were being Induced by mistakes on patches (or plain rogue ones, doing blind changes). Since V 2.4.0 TweakScale is doing Sanity Checks on startup to detect situations that would cause catastrophics failures on KSP, some of them somewhat nasty. When something is detected, Tweakscale withdraws support for the offendig parts. Check the KSP.log for messages, every offenfing part is listed, with the issue where the reason is explained. So it's more likely the other way around - it's TweakScale that must be detecting problems and mitigating them. Send me the KSP.log of a run where you think this is happening and let me check it. I already have some tasks for Kopernicus on the backlog, by the way.

Landings on the helmet. They forgot adding colliders to the helmet, I think, until 1.2.2 or 1.3 perhaps (pending verification). So you just can save parts by doing EVA once the reentry heat is over and fall into the ground heads down. Chutes? who needs parachutes?

Simulate a civilization on the Boötes Void!

Your lucky day. This add'on just added what you asked, A380 parts. It's on development, you will need to literally install it by hand. And updates can sometimes break your savegames as the developer can choose to change things. But it's promising.

My version is a personal fork that I'm working for a long time to cope with my own needs. However, it happened that it was also the only version working fine from 1.2.2 to 1.6.1 (and now for1.7.0) that also had some very interesting optimizations made by @Rudolf Meier and someone found my fork I don't know how and used it and started to ask questions and pinpoints bugs, and so I thought it would be a good idea to keep things running for while. What happened is that I don't play RO, and the RO guys don't care about my needs. So I just keep developing my fork for me and helping people using it. This is not a job. I'm not getting paid. I don't see the need to communicate someone for developing the things that I want - and the very same applies to someone else, no one needs to communicate anything to me. I'm thankful to anyone that choose to use my fork, you guys helped me as much as I helped you. The amount of useful in situ information I got here would be impossible without you. Thanks again. But it's also a relief that I'm not the only one supporting this anymore, as now someone else is going to properly support things and I will have time to spend on my own ideas without risking breakage on a lot of unattended users that just wanted a working KJR fork. For anyone still willing to use my fork, please fasten your seat belts while doing it and contact me the way it best fits you for help. I will do my best.

Update on the issue about Infernal Robotics.

Irrelevant. Until Ferram officially yields the name to someone else, the only "Official" Kerbal Joint Reinforcement is his. Point. Now I know. I checked it myself. Your error was claiming it as the new "Official". Now I agree. I'm not the only player on the town anymore. And I want to rollback my version as being "Experimental" only. Properly support an Add'On is a lot of heavy work, and I want to expend mine on developing my own ideas, not supporting other people's works.

The only official KJR is Ferram's one, or the one Ferram authorize as such. If the CKAN port are being delivered as it would be the Ferram's version (using the same name!), there's a very good chance it's a GPL infringement, as there's an explicit requirement that forks SHOULD NOT misrepresent the original work. Assuming Ferram didn't authorize the use of the name, and assuming CKAN is delivering KSP-RO using the same name as Ferram's, I would rethink some things... That's the reason I never claimed being the successor or anything. — — — — — POST EDIT — — — — — No. The new update is labeled KerbalJointReinforcementContinued. Not a problem. @pap1723, may I ask some more caution on the matter? Copyrights are serious business.

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?