Lisias

Some code improvements and optimizations that @Rudolf Meier did once and made a push request to Ferram's. At least for me, it was terribly faster and slightly more reliable (probably by being more efficient and imposing less load on the physics engine). Some pages ago I published 3 videos recorded on my MacPotato benchmarking IR/Next without anything, with @wolderadowolderado's compilation (the Ferram's pure code without the version lock) and mine. You will see strengths and weaknesses on both approaches (Ferram's one, and the new one from Rudolf). Of course, Ferram must had his reasons to rollback the Rudolf's push request, but yet Rudolf's one made the thing usable on my machine. I also have a pet project, KSPe, that aims to make a lot of things every Add'On needs to do in a simplified and standardized way, and the simplicity and some internal characteristics made KJR an excellent candidate to test it. So I forked Ferram's, made my changes, installed it on my machines and forgot about. I didn't even knew that some other forks where deleted when someone reached me asking for directions on the thing. About TweakScale, it's a symbiotic thing. A lot of things I learnt taking care of KJR helped me on some harsh decisions I had to take on TweakScale. And vice versa. Scaling things overstresses the physics engine on some really big and small factors, and tweaking KJR helped me to figure out (or near it) what's happening. So, yeah. My work on TweakScale would be somewhat more difficult if I never had forked KJR. My lack of time, currently, is due Real Life issues. Researching is not the same as building. I usually spend 1 to 2 hours until I finally "get into it" and start to get productive - it's like you playing KSP, had to stop for half a hour doing something else and when you are back you don't know exactly what you was doing anymore. But somewhat worse. without about 4 hours to spend on it without being interrupted, it's not worth to start to work on some things. And my weekends were somewhat busy on the last months.

Because you choose to never fix the problems that were affecting KSPe. There's a long history on the backlog and on this thread. Feel free to check how many times people got here taking about KJR and I pinpointed other Add'Ons borking the Mono's Reflection. People that did what I said got it working, people that didn't, didn't. There's no black or white indeed. There're people doing what's needed, and people don't.

Blind guess, but perhaps some extra modules added by RO need to be patched too. TweakScale knows nothing about what it's doing, it mechanically applies "receipts" into GameData: "here, take that datum called mass and multiply it for this scale". You tell it to scale mass to a small enough factor, you got a number being rounded to zero and then something blows somewhere inside the physics engine. You tell it to scale to a negative scale, you get a craft thinking it's a nuclear reactor going China Syndrome at room's temperature. You forget to add a receipt for something else, this something else is not scaled at all and Krakens count the deads. The solar panels on Kopernicus apparently are suffering from this last problem. They had to switch the generator module for another one that finds the nearest star for light, and nobody told TweakScale about this new module.

I finally decide it's time to play Dante's Inferno on PSP. dude... Nice work. Need to find a second hand copy for PS3. this game deserves 42" and DTS.

According to the Author, 5m parts is tricky and unlikely to be added to the Add'On as they overloads the physics engine somehow and became prone to Rapid Unplanned Disassemblies events.

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: