Lisias

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

Real-life is an issue for everybody, including me. Every hour one expend fixing something, it's an hour we doesn't expend playing with something else. Fixes can bork - usually we mess up one or two times until we got it. If the maintainer hasn't the time to fix the problem, would he has the time to fix the fix? This way we are doing know, when he find the time to update, he will gain the fixes implementated and validaded on the field. Ideally, more than one fix so he can even choose the one he likes more. Pull requests works both ways. He can merge back the code from anyone that had forked his own, he doesn't have even to ask - it's the Open Source way. And with us tacking down problems openly here, he don't have to search by himself neither: all the needed info is already consolidated to be analysed. :-)

Ok, boys. New toy - and this one is working. (I think). Release 3.4.0.1 for KJR/L here. It's advised (but not needed - the "bug" was harmless) to update KSPe to 2.1.0.2 here. And if someone is willing to know what happened, a PHD thesis about this mess can be found here: https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/issues/3#issuecomment-443509433 — POST — EDIT -- A new release was issued. No big deal, if you don't use Ground/Global Construction , you don't need to rush into updating from 3.4.0.1 (that was ditched) in time, this is the Saint Graal of this saga: [LOG 19:19:54.701] [KerbalJointReinforcement] INFO: Configuration file loaded.

The CSharp plugin for Eclipse is terrible!

That's why I eye ball everything I merge. And I failed on this twice. well, small commits are good commits. I will avoid merging large chunks of code at once in the future. about typos... I'm almost asking forum to be hosted on Github, so many are my editions on my posts. Jeez, would I had to earn a living by writing, I would starve to the death! watahell² ??? O.o I'm trusting automation too much. Anything changes, the scrips silently fail on me. I will fix this tomorrow. — POST — EDIT — Thank you very much for the heads up. Your hint pinpointed an error on my automation scripts, what leaded me to testing the wrong DLL while publishing a (probably) untested one.