Lisias

He kept his reasons to himself - or at least, didn't shared them to me. Most of his Add'Ons are all ARR, no one are allowed to legally keep them going. Sorry to be the one to tell you - I'm terribly sad myself, I'm a great enthusiast of the Maritime packs (it was the reason I was toying with KJR/L and ended up helping people with it recently). What can be done are 'meta-add-ons' - Add'Ons from third parties that, once the user has downloaded the original and installed them, you install the former over the later to fix things - as long the "meta-add-on' doesn't have itself any ARR material from anyone else as the Author, this is legal. On the long run, however, someone else will have to rewrite a replacement from scratch, as it's being done with Kerbin Side Remastered.

:FOR[TweakScale] means "I am TweakScale", and allows proper use of :AFTER and :BEFORE by clients what would solve some problems for people willing to change the Tweakscale behavior on some parts. (but will cause some other problems to old Add'Ons that does that by relying on luck!) I remembered this post, it explains very well how this works:

As weird as it appears, appears to be correct. At least up to 1.6.1. Things appears to be changing as per Version basis. My previous findings suggests the problem is not exactly KSP, but something related to the Mono's JIT, or at least to the Unity's Mono. Windows doesn't makes sense. What happens is that Windows uses a kind of "bridge" to allow 64 bits code to call 32 bits code, It's a hack, but apparently they had to do it as they can't just recompile the World to 64 bits as Open Source guys can do. The very weird thing is that, by some unreachable reason, the Unity's code that calls the X_INPUT (and not only the 1.3, the thingy falls back to 2 or 3 different versions of the DLL - it's a plain hell) appears to be attached to a C# code that translates to 32 bits far-calls when calling native code. Yeah, yet another bridge - from de C# Land to Windows Native Land (were there're bridges on the 64 bits land and the 32 bits land). Things works fine while your memory footprint allows the JIT (a thing inside Mono's that compiles in runtime CIL - the Mono's bytecode - into x86 machine language) to place binary code in a place where it can reach the X_INPUT code in a 32 bits far call. Stock KSP usually allows that, but once we shove Add'Ons into KSP, the memory footprint pushes the free memory away from the X_INPUT code in memory, and sooner or later the JIT compiles something into a memory beyound the reach of a 32 bits far-call - and this is when our crashes happens. My current guess (I have about two a year! =P ) is that somehow, by using a 32 bits X_INPUT dll, the JIT tries harder to use memory that is not beyound that 32 bits far-call reach. However, things has changed on 1.7 - this postulate of mine appears to do not cope very well. Until I grasp a Windows machine again, I'm on the dark and depending of third parties reports. What makes me remember: could you send me the material you have?

ANNOUNCE. Release 2.4.2.0 is available for downloading. See OP for the links. And yet another *Unholy interaction between modules* (Kraken Food) was detected when rogue patches apply twice the same property on a part. Unfortunately, one of that rogue patches were being delivered on the TweakScale Releases. We apologize for that. Be advised that a new situation was detected that demanded withdrawing support from some parts at runtime due rogue patching. No breakage is expected this time as such parts are rendered useless and you could not use them anyway, but take precautions on installing Add'Ons on your installment as some older ones are prone to induce this misbehaviour. Issues that would mangle your savegames and crafts still persists. Things still work until the problem is fixed (by installing, deleting or updating an add'on!) when then your KSP installment will be sane but all your savegames and crafts with TweakScale parts will get reset to defaults - yeah, you can't fix the problem or things get worse. This version of TweakScale "mangles further" the affected crafts and savegames so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then is later fixed. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on here for help. As usual, this version still drops support in runtime for some problematic parts. Any savegame with such problematic parts scaled will have them "descaled". This is not a really big problem as your game was going to crash sooner or later anyway - but if you plan to return to such savegame later when TweakScale will fully support that parts again, it's better to backup your savegames! Currently, only EnginePlate1 to 5, and Tube1 to 4 are being affected due using ModulePartVariants with mass. It's an annoyance, but not a really heavy impact on gaming. I'm trying to figure out coding time to fix this on TS 2.5.0, the next major milestone. On the bright side, it Default support for Near Future Aeronautics, thanks to our fellow Kerbonaut Red Stapler. Please keep an eye on the KNOWN ISSUES file. I will keep it updated regularly. — — — — — This Release will be published using the following Schedule: GitHub , reaching first manual installers and users of KSP-AVC. CurseForge -online SpaceDock (and ckan users) - by monday night The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Because KJR/Next works faster, taxing way less the CPU for the most part of the flying (some hiccups happens when the craft explodes). It also solves some bugs by eliminating the situation where such bugs would happen instead of mangling the parts that would suffer it. It will also work seamlessly with some other Add'Ons (as Infernal Robotics) instead of demanding user editing on config files. I think that by now you should had the picture. And now you can use your recently discovered free will to test both on your machine and decide what of them will work better for you. Caveat Emptor.

You could just autostrut the thing. I managed to use moveable (big) wings with the Classic Infernal Robotics using AutoStruts to Grand-Parent on everthing those grand-parent would not be a moveable part. By adding a auto-strut on it, the motors weren't enough to move the thing.

I found some inside TweakScale itself last revision, it's not impossible that I have some left. I will double check them, and then install the above Add'Ons and check it again. The lack of :FOR on TweakScale is partially to be blamed for this, and I didn't published a new revision using :FOR yet because I found some patches that were borking when TweakScale used them, and I'm mapping them to fire up change-requests when I release it. In time, when doing clean Stock checks, be sure to really get a clean one. I lost some serious time recently because apparently some Add'On shoved a patch inside Squad (or SquadExpansion? I forgot) and that one was playing havoc - but I just realized it when I got mad on the issue and brute-forced some checks on the Squad's folders too. From now one, I plain delete all my testbeds and reinstall from scratch every new Test Suite run. Faster than doing integrity checks everytime. — — — — — POST EDIT — — — — Confirmed. TL;DR: It's already fixed, but I didn't released it yet!! My apologies!! — — — — POST POST EDIT — — — — New release was rushed with the fix in the change log.

I need your KSP.log and Module Manager caches (all of them). This is [almost ] always related to rogue patches and/or unsupported configurations. There's nothing to be done but to plain drop TweakScale support to the affected parts when this happens, and this is what the latest TweakScale is doing. If you are not using the latest, please do it - but be aware that the affected parts will plain lose TweakScale support, including crafts already flying. If you are using the latest, I need the mentioned data to identify the new situation and properly implement a Sanity Check for it. — — — POST EDIT — — — I found your KSP.log here: I'm checking it - there're something very weird here, TweakScale appears to being summoned to scale parts without TweakScale support! I'm not aware of any situation where this would happen, I'm on it now. https://github.com/net-lisias-ksp/TweakScale/issues/41

Sorry, you are wrong. There's at least one member on this forum that is not helpful and kind. Me. I'm just helpful.

Problem is that B9PartSwitch when detectes MFT yields the fuel management to it, but keeps accepting requests from TweakScale to scale the fuel capacity - so TweakScale ends up scaling zero fuel tanks, leading to division by zeros and other accidents that ends up crashing the game. B9PartSwitch is the only code that knows what's happening, so the only safe solution for TweakScale is to do not touch parts where MFT and B9PartSwitch are both present. Unfortunately not, I would had fixed it already if it was. It's a patch problem. There're rogue patches injecting twice the same property without checking if it was already patched.

And a even bigger one to ones that know how to appreciate a good prank! (that last one? I'm still laughing!)

IMHO, Moon. And by plain practical reasons. There's a lot to be learnt and relearnt about space travelling. We have a lot of more knowledge about staying at space than before , but we lost something on landings - see the mishap on Beresheet. Or even SpaceX recently. And not to mention the human condition, see Boeing and the utter fiasco called MCAS, and the recent news about NASA wasting two rockets 10 years ago due falsified quality reports from a supplier - that were doing that for 10 years!! All that's needed are two generations to definitively loose a technology for good. And it will be exactly these two by the time we land on moon with our own feet once more. We have to start all over from scratch. Again.

Following suit:

local supermarket. And this was the first case in 2 or 3 years - perhaps a bit more. I was used to drop the eggs on a bow of water before using them - if any part of one floats, it's bad for sure. However, after a couple years (at least) without finding one, I got lazy. Goose eegs are something else, by the way.

I second that. They are sick, dude. Almost as sick as me…

This is the tragic and painful history of a developer that didn't checked his inputs while breaking a egg to scramble it over the pan. A rotten egg . Developers of the World, listen to me: VALIDATE YOUR INPUTS!! (If you think that rotten eggs stink, try to fry some!)

I was trying to sleep. Then…

As was EXPLICITLY said on the original fork: THERE`S NOT AN OFFICIAL VERSION FOR AN ADD'ON. Choose a provider that you trust, and stick with he/she. The license is the rule that applies to everyone, and Forum Policies are the one the rules us here. CKAN's entry for "Kerbal Joint Reinforcement" is under Ferram4's copyright. It would be a misrepresentation pinpointing "Kerbal Joint Reinforcement" to any other thread than Ferram4's one, unless he explicitly authorizes it. And he didn't. And this would make the license NULL and VOID to the fork's maintainer, what would not only be a serious legal problem, but by Forum Rules would make this thread deleted/blocked/whatever. "Kerbal Joint Reinforcement Continued" is pointing this one, right? It's enough. — — That said, how about avoiding polluting this thread with unrelated issues? This is about "Kerbal Joint Reinforcement Continued" - an "official" fork so official as mine, by the way. I just choose not to publish it on the Forum as there's a better man available for the job. I would recommend to transfer all discussion unrelated to "Kerbal Joint Reinforcement Continued" to another thread - perhaps that one about Copyrights? But it's up to the thread's owner to decide.

Yes…. But it will not work as you expect... Yet.

This thread is old as hell, but it was on my search results while I was on the same quest so I thought it is a good idea to publish the solution I found. Try Archive.org. I found them there: https://archive.org/details/kspckanmods?and[]=stryker&sin= There's also something on CurseForge: https://www.curseforge.com/kerbal/ksp-mods/strykers-aerospace-restored-cockpits/files Everything terribly outdated, but at least the license allows a revival.

The rumours about this Add'on's demise have been greatly exaggerated. Impressive. Most impressive. Had you ever considered a position on the Dark Side? We have a excellent health insurance!!

Are you sure? This post has less than a week by now...

I usually would post this on the Rants thread, but unfortunately it was locked due misbehaviours - what's ironic at best. So I will rant here, as it's TweakScale related. THE WORLD IS ENDING HERE, it's the new Biblical Flood! The rain is so heavy that some public infrastructure is blowing up (I can hear from here), and I got a power outage (after a surge!) for some seconds, what played havoc on the first day I really reserved to work on TweakScale in weeks. Well… Rant's over. I guess I will need to dig some time on the week to redo the work. Power is back, let's check what's fried around here. — — — Yeah. It's raining again. =/ I will read a book or play on the PSP. — — — I think I got "lucky", way less trees had fell this time. Two months ago, was way worse. 900 was the count as far as I know. — — — Not too much damage. Some fuses blew on the power stabilizers, and a somewhat nefarious file system corruption - what's not a problem, as everything is backed up or is a git repository. The only loss is the day's work.

Opa! Deu tudo certo? Conseguiu rodar?