Lisias

(sigh). It's a bit more complicated than that. TweakScale needs to run all the variants to scale them too. I found code already scaling attachment points for ModulePartVariants, but that code doesn't touches the baseMass - probably due being a bit old, as the message logs stated "stockTextureSwitch" instead of "ModulePartVariants". It's some time since I'm nurturing an idea to better cope with these things. Fixing things on demand and then issuing a new TweakScale every time any module changes is cumbersome and counter-productive. The next release will be in the works on the holidays due the considerable amount of energy this is going to cost me, but I intend to give this "mess" an end. It's going to be better, but first, I will reduce the scope of supported modules - what will be not exactly a problem, as things are broken now for such parts. Thank you very much for your efforts. It leaded to a proper issue just for this. https://github.com/net-lisias-ksp/TweakScale/issues/13

This can or can not be an issue, as different parts have different "densities". Stronger parts has more material on its super-structure, and so when scales down, has less space for resources - ending up having less mass. This is a part of the code that I didn't really looked on, as things were exploding (pun really intended) somewhere else. But if this is a bug, it's already covered by issue #9. Meno male. At least it's just one part to check what's happening. Now I have a clear, punctual situation to observe, instead of chasing my tail. Thanks!

Marvelous! So now I have two problems with identical behaviours! At least things start to make sense now. B9 Part Switch appears to be involved on the Zero Mass Effect, and this is the Negative Mass Effect.

YES!! Finally another evidence! Thank you! *THIS* was the bug that halted the development of my novel! I need you to make a test: deactivate B9 Parts Switch (move it out from GameData), and try again. Then bring it back, and see what happens. B9 Parts Switch is the "screaming victim" of this bug, something (I'm guessing it's TweakScale), somehow, when see B9 Part Switch, injects in it a bad behaviour, rendering a part with Zero or Negative mass. Negative mass is bad, but zero is worse, as the part became anchored on the 3D space and all that thrust is then applied to parts as they would be connected to a concrete pylon firmly anchored on the tridimensional space until something fails, and it's blowup fest. A known work-around is to do not scale parts using B9 Parts Switch, do not use B9 Part Switch (using a patch to add the feature on B9 parts that rely only on it) or use only B9 Part Switch. — — — POST — EDIT — — — Issues related: https://github.com/net-lisias-ksp/TweakScale/issues/12 https://github.com/net-lisias-ksp/TweakScale/issues/11

You know, there're some forum rules that prevent me to follow up this. Damn it! I'm feeding the competition!!!

I could not agree less. Most of the hacks you complained before was due Unity's ones at that time. Switching Unity version was unavoidable, Squad was already on a corner. Almost all of the breakage came from getting rid of the hacks they had to do to cope with old Unity's idiosyncrasies, but also from the hacks they have to do to cope with new Unity's idiosyncrasies. Unity is a hell. I agree. But… Don't think that the other engines are so that better. Unreal Engine has its idiosyncrasies, and you should talk to someone that works with Frostbite. The main difference between KSP and the others is that KSP is 'program driven software', where most games are 'project driven'. On a project, once a game is ready and kicked out through the doors, you close shop and that's it. New game version is a new game project, with a new budget, and everything can be rewritten from scratch if needed (and money allows). Try to run Quake2 mods on Quake3. KSP is a program, like Windows or MS Office. The dynamics are different. I can't run all of the Win95 programs on my Windows 7 - but I can run some. Looks similar to KSP? Well, it is. I have a proposition for you. Gather people, fork the mods you want to use on 1.3.1, and back port the bugfixes. The license of most of them allows. Create a parallel ecosystem focused on 1.3.1. It's possible, all you need to do is to hack into some code. You will see that most of the problems are not exactly from KSP changing something, but from KSP getting better and everybody that relied to work on a idiosyncrasy needing to rethink things. And some of that most wanted mods (as KJR) is working flawlessly with the same binary on every KSP version I tested it since 1.2.2 (yeah, the very same binary, not even a recompile). This is something to think about. Believe me. Squad is one of these companies you wish. And the problems you are facing are the exact consequences of that. You can't have the cake and eat it too.

I agree. And I think you nailed the reason: not enough resources are being spent. However, resources must be earned before being spent, and this is the reason I think things are this way for now. They need to feed the cash cow, so they can have the milk to feed Q/A. This is, still, an indie game I could not agree more.

You can't have the cake and eat it too. Had Squad stayed on the 1.3.1 code-tree, we would had a huge amount of performance leaks and unsolvable bugs. Leaking Abstractions and Interface Brakes are a pain in the SAS, I agree and recognize it, but that's it or freezing the product into a bugged, unsellable situation. Now that I have near a year of KSP overseeing, I have some ideas about the reasons they are doing it, as well about the objectives. And besides getting really angry sometimes with the breaks, now that I understand the reasons, the angry vanishes fast - it's that or loosing KSP itself, this forum and everything else. All of this costs money. They need to feed the cash cow, otherwise they capsize with everything and the kitchen's sink going kaput. They know it. And this is the reason that sometimes they take some not exactly best decisions, that back fires and blow up on everybody's faces. I'm a professional software developer by trade and by formation, first played 1.3.1 and immediately 1.4.0 came, and I saw things happening (what include things that for the user are invisible), so please give me some credit on this: their lives would be insanely easier if they choose to drop the support they do for mods. They need to sell KSP for new users, but yet they compromise with features they didn't sold neither maintain in order to do not jeopardize (too much ) the legacy. Not for the faint of heart. I agree. KSP is a memory hog. My advice is to monitor the virtual memory size or, better, the swapfile size. If it reaches about 10% of your physical RAM, you are abusing your rig and performance will be sad. It's a design decision that works for the stock game: due some Unity idiosyncrasies, it's better (and easier) for they to just load everything into memory. The game is a open universe, and they didn't wanted you to get lags when flying your vessels around. When you cheat your vessel to be in the orbit of any body, there're no loading time, because everything is already in the memory. Load On Demand is possible, but not with the same user experience. Games like Assassin's Creed can do it because you are on a open world, but only the visible fraction of it is needed - A.C. don't need to load anything else but what's immediately visible to you. On KSP, on the other hand, you can send vessels to any place in the universe, and switch to them, and even build telescopes to see bodies beyond the immediate sight. Loading on Demand would render these somewhat annoying. For the sake of comparison, Orbiter does the same: you need to build a scenario file where everything you want to use is declared, so it doesn't have to load anything else (but the "Universe", that must be loaded anyway). Some scenarios I made took some time to load… But yet, I didn't had to load everything and the kitchen's sink at once, since we don't build new vessels once the game is started. IMHO, what you are asking should be handled by the modders. At least, while Squad don't cook something for them - what will take some time, as the Stock are still being loaded in a reasonable time. What leads me to another issue: KSP supports XBox and PS4 too, where memory constraints are tougher and not negotiable. Until the moment, KSP had a manageable footprint on them, but with MH and possible new DLCs coming, this is going to change fast - so I expect they would be working on something sooner or later. But this will be a point of inflection for KSP ecosystem, as the whole GAMEDATABASE subsystem will have to be reworked somehow - I foresee a huge breakage on the legacy mods (that can or cannot be easily fixed). As I said, you can't have the cake and eat it too.

Oh, a business opportunity! I have a proposition for you: a browser plugin that would monitor the uncover button tag, and every time you click on it, it checks the owner to the post, classify it, and send a signal by HTTP to a Arduino device that would be controlling three different devices (so you can be properly punished by the level of aggrievement you have with the guy): one would be controlling a truck horn one would be controlling a servo, where a boot would be attached in order kick you in the SAS one would be attached to a power relay that would cut the power from your home I guarantee that this contraption would prevent you from uncovering such posts.

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.