Lisias

One time I was asked, another I asked and a third I saw an opening and applied for it. [ In all the three, I already had an Unofficial fork with some bugs fixed and even features being tested and aparently working fine ] That's not what we are seeing here already? Coordinated cooperation, however, needs common interests. No one works for free on things he/she/it is not interested somehow. I want a bugless, easily maintainable KSP installment. And that's all what I want. Who wants the same, can work with me. Who wants something else, can work with someone else.

It works fine to LGG mainly because he became one of the busiest maintainers in History. And, frankly, had not he stepped forward for this, a lot of add-ons would be stalled and forgotten - I'm seeing a proportionally low quantity of maintainers nowadays, these guys are awfully overloaded! However, this time we have at least another two at least equally competent guys also in conditions to adopt KJR besides me, and both of them had done a lot if heavy lifting too. Should we have, so, three different threads with each one deviating to his own way? Should all of them be on CKAN? Hard to tell - I opted to make CKANed only the mods those Official Maintainer's explicitly transfered the rights to me exactly to prevent messing up the mainstream: I make only the very few naming changes to make clear the mod is under New Management, but nothing changes in practical ways: it's perfectly possible to receive an update on CKAN and just realized the new management when reporting a bug! Now try to imagine all the three of us (that I have notice) doing the same and behold Apocalypse Now (Kerman's Cut).

He's logging regularly. I can't explain why he's silent, but he is not away. You can check on his profile. I think the other way: by splitting the thread and redirecting everybody that come here to the other thread we are essentially pushing ferram4 away from the spotlight. What's not what I want. I agree that sooner or later something will have to reach CKAN in order to get used by the orphaned userbase, but right now what I'm doing is not ready for mass consumption, so this is not a problem anyway. Yet. "It" . This would be trivial to implement, nice idea. Dude, the last 24 hours were a riot around here. First, after 30 years of use, I discovered that the cache Midnight Commander uses for SSH and FTP virtual file systems are also used for ZIPs, TARs and the others archives, besides the View option working right on the current file. So, you can essentially view a file but use another older one when opening and extracting the contents!! Man, what a mess I did due this!! Not happy, Real Life stroke me with a series of routing problems on the slightly big city where I live (São Paulo), what cut me out from half the Internet - AWS saved my sorry SAS, I fired up a proxy on my site and could at least have some work done. But that was not enough! This morning, I'm facing a lot of power outages on my neighbourhood (perhaps the reason for the routing outage - the power outages could be affecting the local backbones). I'm glad I had delivered that job upfront, or I would had it delayed by now.

I'm restraining myself to creating a new thread because I'm just fixing KJR, not exactly adopting it. I don't know what's going to happen from now, it's up to ferram to decide.

Just an example.

Yet Another New Toy, boys! And, hopefully, this one will go "gold" (unless someone else manage to find another mishap of mine!). KJR/L Pre-Release 3.4.0.3 (hard dependency KSPe Pre-Release 2.1.0.4 - update to the most recent is mandatory). This one introduces (yet another one) change on configuration files. As @AccidentalDisassembly correctly stated above, config.xml is not exactly a user settings file. It has standard, "stock" settings that should be managed by the maintainer, and the user adding his own settings on it would render updates a hell. So I put back the config.xml on the /GameData/KerbalJointReinforcement/PluginData , and this file from nowon is not user servicecable anymore. On /PluginData/KerbalJointReinforcement you will find a file named user.xml, with the very same syntax from the config.xml. Anything you put here will be merged over the config.xml in memory. Currently, there's no way to "delete" something from the config.xml, just to replace or to add. I'm not being too much smart on this "merging over" thing, as duplicated entries from the lists (exemptModuleType and decouplerStiffeningExtensionType) will be duplicated in memory. Not a problem, just a bit of waste. A proper INSTALL file with detailed instructions are available on the zip file and here. — — — I didn't had the time to a proper throughout test - only the basic tests where done: running KSP with and without KJR installed using a reference vessel known to horribly spaghettify without. It's appears to be working fine now. Thanks for your patience.

Ouch, I missed you. My apologies. Anyone. But you will need to tell KJR the modules it need to ignore to avoid your parts being stuck. To tell you the true, you can't autostrut them without a lot of care (believe me, I needed to autostrut a Infernal Robotics part, and had to learn how to do that). If you use any kind of extensions that add mass autostrutting, you need to remember to manually fix the autostrutting on infernal robotics parts. In the following minutes I'm publishing a new release of KJR/L where user will have its own file to edit, allowing you to keep the "stock default" values alone. A way easier to install new updates, as @AccidentalDisassembly hinted to me above. When you manage to update to the new release, ping me again and we will see how to proceed. I use Infernal Robotics too. — POST — EDIT — There's a chance that merely using the "exempt" section would not be enough. Problem is: you can autostrut Infernal Robotics parts. What you can't do is to grand parent autostrut something into it, what's essentially what KJR does (with steroids). (note: autostrutting things on root and heaviest will, obviously, render the servos useless - don't use this on anything that you expect to be moveable - but the grand-parent can be used as long nothing got strutted on the servo itself) If this happens, some feature coding would be needed, but yet, we need to have an easily changeable configurable file to test things. If this happens, I will need your help by installing highly experimental packages on your KSP - i.e.: backup your toys before every use.

Try this: (I'm also asking moderators to move this to a proper place. Don't be surprised when this is moved to a new thread)

I'm developing/fixing/bug-hunting mods. So... Yeah. I think your math is not too far from the real figures. EVERYTHING I use have the userdata there. It's the reason I forked most of the projects at first place. if you care to look on my project on Github, you will find how I do it. Backups. It's damn easy to backup KSP/PluginData. It's damn hard to hunt down where every add-on save theirs. [config.xml is user serviceable. You can set the debug level, as well to add parts to the exempt section - a fellow Kerbonaut wanted to have snappy wings] [no more - a better solution was worked out]. Squad did exactly the same thing by putting the savegames out of GameData. I just followed suit.

Almost a point of inflection. From the knowledge I got from here, I now have some ideas about where things can go down the tubes and now I can think on counter-measures. People are inventive, it's really hard to foresee what can go wrong. However, I have two really serious (unrelated) issues to check and fix (including on others mods, one of them I'm officially maintaining), so this will have to wait some weeks. Welcome to the bleeding edge. It has this name for a reason. — POST — EDIT — Managed to make a deliver upfront, so I had some time to deal with this!

@linuxgurugamer already answered it, but I want to reforce it: NO WAY. This is experimental stuff. It can be stable, but it's still experimental stuff. And we don't send experimental stuff to mainstream. One perfect example for avoiding messing with the mainstream happened a few days ago. I borked beautifully on a very stupid thing, another fellow Kerbonaut borked in another very silly thing, and we ended chasing out tails for days (almost two weeks). This kind of group borking is really common, and should be detected and somehow prevented before putting the thing on the mainstream - or we will end up with hundreds of people borking in the very same way. One angry Kerbal we can manage (or flee from). A hundred? I'm poofed!

Yes. It's being worked on for some time now, but "Real Life can be a Drag"(c) 2018 LisiasT . Please be patient.

The only real change is that "my" KJR doesn't kills itself anymore after checking the KSP version. I deactivate this code, and realized that the same binary is working flawlessly since 1.2.2 (the oldest I bothered to test). The move of the config.xml happened due my frequently delete, downgrade e upgrade of add-ons while testing things. This made my life hugely easier, so almost everything I use I do this. Yes. But not due KSP, but for some bug fixes on the merging process. This release was tested on 1.4.5, 1.3.1 and 1.2.2 too - so it's almost "universal". Yep. This is probably the sensible thing to do, and not only for KJR. My next releases on everything will have it.

Working on it. There's a strange issue too on KJR, so this can help me too there.

THIS information can be useful to me. If it yields, but a third part add-on insist on calling B9 (as TweakScale) when B9 decided to yield in favor of another add-on, I'm guessing that such add-on can end up messing something.

I deleted the previous post, as I had misunderstood the problem. @mankeez, please post your KSP.log file in this issue. This can help to to trim down the possibilities. https://github.com/net-lisias-ksp/TweakScale/issues/11 By the way - absolutely fantastic bug report, you enumerated the mods and the versions. Thank you.

I swim as a tin soldier, and run as a rock (you have to roll me downhill). I think my lineage ends with me…

Looks like an excellent place to test some Kerbal designs! Damnit. It's feasible! Not such much…. How bitcoin miners cope with stuttering?

I'm going to need it!! Thx!

USI-LS has an interesting resource: waste. It's created constantly by living Kerbals, and then stored for recycling. If the waste tank is full, the waste is vented (I.e. Just disappears). Perhaps youn can use this MO for your engine space resource? Just create this resource on a rate bigger than the engine can.consume, and throw away the overflow. Make the "ISP".stupidly high, so you can make such rate minimal and so minimize any concerns about weight and balance.

Yes. But some clients use this piece of expensive poo, so I have to have one In order to support the thing. Curiously enough, most of them is virtually paying to avoid going to Mojave. I wondering if that would not be the reason for Apple cutting down the download for High Sierra and below for users that installed Mojave.

Nope. I can't install previous versions on my machine since a firmware upgrade. I tried to downgrade to El Captain, but the machine refused to boot El Captain! Them I tried to upgrade to High Sierra and… Man, it borked! High Sierra is unusable, at least on my machine. So I'm stuck with Sierra. And that's it. Sublime is just a little better than a toy. It can be useful, but not for me - I need more professional tools. And I already use Notepad++ and TextWrangler for the roles Sublime would be useful. Calling MonoDevelop "professional" is something that makes me shrug - but so is the Life.

(KAX, FireSpitter, TweakScale - for 1.4.1 to 1.7.0 Kerbal Aircraft Expansion /L - Under Lisias Management, forever THE pack of selected vanilla-inspired parts for your aircrafting needs! In a Hurry Release 2.8.1.1 [2024-0704] Announce. Download CurseForge (yay!!!) SpaceDock GitHub Issue Tracker Documentation Yes, it works with KSP 1.12.5 YES, it works with KSP 1.7.3 (with Making History and Breaking Ground) YES, it works with KSP 1.3.1 too!!! Project's README Install Instructions Change Log Known Issues TODO list Description An Add'On for Kerbal Space Program Originally created by Keptin, then maintained by SpannerMonkey and the SM Industries team, and now under Lisias' Management, KAX is a pack of select vanilla-inspired parts for your aircrafting needs! Included Parts: Turboprop Radial Engine Radial Engine Long Cowl Electric Propeller Helicopter Main Rotor Helicopter Tail Rotor Heavy Landing Gear Jump Jet Engine 2M Aircraft Cockpit 2M Fuselage (jet fuel) 2M Structural Fuselage (empty) 2M Tail Boom This Add'On Requires Firespitter and Module Manager to enable all the features. Project Directives This Management (Lisias) had agreed to oblige himself to the following directives for this project: KAX will remain KAX it will not be rolled into another Add'On it can be expanded expansions must be in keeping with the tone of the Add'On it must be vaguely (as much as possible) stockalike. This project aims to preserve the stock a like compatibility and versatility of these parts, and any subsequent parts will be designed with that in mind. The goal is that any new part will blend seamlessly with the current parts and add to rather than detract from the Add'Ons functionality. Acknowledgements Powered by Firespitter, special thanks to Snjo for his plugin. Additional Models by @SpannerMonkey(smce). Stockalike textures by Doctor Davinci. Greetings to @TheKurgan for his helpful work on the SMCS's add'ons (including this one). See LICENSE for the formal legalese. Please note the copyrights and trademarks in NOTICE. References SpannerMonkey(smce) -- Previous Maintainer Forum GitHub Keptin -- Original Author Forum Curse Forge

"all your base are belong to us"

Sure thing. In a few hours. This is why we fork things: we can try and bork without messing with the mainstream. :-) The surviving developers[code] go Official, the masochists[people that enjoys bleeding edge] have fun and everybody wins! — POST — EDIT — Done. New release (I ditched the previous one) https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/releases/tag/RELEASE%2F3.4.0.2