Lisias

Couldn't help but to share this here.

The darkest hour of the night is the point in which the morning starts to rise.

They are also being spared from all the breaks and crashes that the new versions are suffering due Add'Ons. You can't have the cake and eat it too. If you want a stable and reliable game (or the most close to that you can get), you need to use only what the Author of the program says he can guarantee to work. Try to imagine an add'on being updated and corrupting your savegame on the XBox - how you would rollback the add'on and recover the previous savegame?

I like to call them improvements, bug fixes and technical debits being paid. KSP has the complexity of a small Operating System. Something near Windows 95 or Android 1.0. To make things more interesting, the game engine it was choosen to implement the game is both their main reason for the success, but also the very culprit for the worst problems they had and have. Como dizemos por aqui, "Rapadura é doce, mas não é mole não". ("rapadura" is a food derived from the cannae, one of the steps before being processed into sugar: extremely sweet, but hard as a rock, you can break a tooth if you are not careful). It's hard to believe, but things are way better than before. We have some nasty issues to solve (landing gears and pads, as it appears) but things are really better nowadays. Try some playing with 1.6.1 and a minimal set of add'ons (I'm using KAX, AirplanePlus, TweakScale and Atmospheric Autopilot for now - I like planes a lot) and see for yourself. How about trying 1.3.1? There're some guys "doing it right this time", backporting everything to 1.3.1 . A considerable amount of the performance issues were on the add'ons, not only on KSP. Most Add'On authors here are not professional developers, they are hacking their way in on the trade. And they are way better on it nowadays (I see a brilliant future for some of them, by the way). Some people are backporting some new code to be used on the 1.3.1, and this will make a significant difference. I don't have too much contact with this niche, but I had noticed some mentions on the "1.3.1" on the github newstream. Perhaps you can get some info here: I'm going to be somewhat harsh on the following sentences, but I don't have in me the ability to make bitter things look sweat. I'm an objectivist by need of the trade. Do you know that scenes on Mad Max Thunder-dome, when Max reaches that kid's settlement? Or perhaps the "Lord of the Flies" novel? Now try to imagine that kids with a computer, a compiler and an Internet connection. Immature and/or uneducated people gathers together and manage to accomplish marvelous things. People at their best, I say. But sooner or later, their lack of proper preparation for the tasks starts to pullback their efforts, and since most of them doesn't have the proper knowledge to recognize the new "threats" and fewer have the maturity to consider that they need to learn more from who have such knowledge, it's unavoidable that all of that impacts negatively the status quo. We had some very good opportunities here on the recent past, but virtually all of them were wasted by ego and immaturity (to the point in which things can start to be legally dangerous). That "1.3.1 ecosystem" I mentioned earlier appears to be one of the first steps into the right direction - that Continuous Integration kraken-poop works for sites, not for product versions that need to be maintained for years. And no, things are not exactly 'bad". Just bitter (I like beer, by the way). I have some ideas, but right now… I'm focused on the tasks on my hand. Don't update! I skipped 1.5.x series entirely (besides some small features that I wanted to use on my novels), and I just adopted 1.6 because all the issues I have with 1.6 are also happening on 1.4.5 and need to be fixed anyway, and the performance enhancements (mainly, the VAB/SPH memory consumption being solved) were killing me on 1.4.x. You did the "right thing" - it's not broken for you? Don't update. Of course, you can't have the cake and eat it too. Now you have a new version that solves a problem that you have, and need a path to this newest version. The absence of a proper path is the problem to be tacked. Things are less ugly than it appears. I have virtually ZERO problems with any code that works on 1.5.1 and was tested on 1.6.0 , and just some things on meshes that started to misbehave in a way some other meshes did on 1.4.x - what means that Squad is dropping support for legacy things they don't use anymore (and believe me, this is a good thing - trying to embrace the World was, IMHO, one of the main reasons they flopped on 1.4.0). Moving things from 1.2.2 to 1.3.1 is, IMHO, the best first step. Of course, if we had automated tools to help on it things would be marvelously better. Some guys here have a huge knowledge base of every part ever developed for KSP since 1.0 (I think), and this guy would insanely help on the task. All I can do is to hope they decide to attack this problem, or at least open the database to ones that want to do that. Moving vessels between KSP Versions is renaming parts and replacing Modules (while converting data). Really, it's a data converter that is , really, a commodity on Service Buses. It's feasible. Moving savegames can be trickier, but in essence, it's still feasible - but would need a lot more understandings from KSP guts, what make the task harder to be tacked down without direct involvement from Squad, what can be impossible due N.D.A.s. Painkillers? #tumdumtss Ok, bad joke. Serious now. You are not alone. There a lot of people stuck on 1.3.1 considering migrating right now. Your first step is find this people and exchange experiences, and gather together to make your voice stronger.

I remember someone talking about a conversion script made in Excel. This can help to understand the changes and, perhaps, extend the idea...

I think you need a bit of historical background (damn, I'm that old already?) From 1.2.2 to 1.3.1, KSP was using a previous version of Unity (I didn't tested anything on KSP previous to 1.2.2, so I will not include them on my explanation). On 1.4.0 Squad made a bold move: they upgraded to a newer Unity version. Unfortunately, Unity is not known for consistency over releases (and, to tell you the true, few games engines are), and so a huge part of changes and adaptions had to be made - these were tackled from 1.4.1 to 1.4.5. Some changes were somewhat deep, other only cosmetics. But in the bottom line, some core business changed, from the PQS to Parts. And stock parachutes. And some parallelism on the guts. Oh, yes! Making History (that can make some Add'Ons as TweakScale to bork, as it also instruments GameData on Main Menu). 1.5.0 (the Abbreviated) and 1.5.1 focused on less drastic improvements (as control seats being able to be launched with Kerbals, and Kerbals being allowed to drop the Helmet and, I think, the collar - I forgot, I skipped 1.5.x entirely on my gaming). And added some more parts using the new VARIANT module. 1.6.0 (the Short Lived) and 1.6.1 also didn't added anything too drastic, and focused on bug fixing and performance enhancements. And one or two Parts being replaced by new ones (in reality, new parts with the same name and look, but completely reworked to use the new subsystems). So, really, your issues is due the changes on the 1.4.x era, when they started to pave the way to what we have today. Ubioweld I know very well , and the new Parts features will play havoc with it for sure - it's a lot of time since I mangled with that code, but from what I remember, Ubioweld will need some care in order to support the VARIANT parts (it's one of the things that bitten me on the SAS on TweakScale, by the way). One thing that you can try is to install 1.3.1, 1.4.3, 1.5.1 and 1.6.1, and then load and save sequentially from the oldest to the newest in order to take advantage of the automatic converter from the previous versions that KSP need to implement on each new version. You will need to have the latest version of your Add'Ons for each KSP version. And yeah, I know - it's a lot of work. Note that I'm suggesting 1.4.3 and not 1.4.5 due that PQS thingy that could brake some Add'Ons that handle statics, and since there're nothing on 1.4.5 that you really need (as you are aiming 1.6.1), you don't need to waste time with this. Oh, yes. You may want o install this: and pehaps this:

Yep, bull's eye: [ERR 02:16:45.809] AssemblyLoader: Exception loading 'TweakableDeployablePanels': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'TweakableEverything.ModuleTweakableDeployablePanel' from assembly 'TweakableDeployablePanels, Version=0.1.25.3, Culture=neutral, PublicKeyToken=null'. [....] [ERR 02:16:45.872] AssemblyLoader: Exception loading 'SuperKerbal': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'KIS, Version=1.16.6876.37464, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KIS, Version=1.16.6876.37464, Culture=neutral, PublicKeyToken=null' You need to install KIS for the SuperKerba add'on be able to work, and there're something wrong with the TweakableEverything.ModuleTweakableDeployablePanel's DLL that prevented it from being load, besides being there. Some add'ons are KSP specific, as they need something that are only available to newer (or, sometimes older) KSP version.Your mileage may vary, as some add'ons (as KJR) works fine com 1.2.2 to 1.6.1 - but in the bottom line, the mod's maintainers are the one that should keep track of this. The keywords to detect this problem are "System.TypeLoadException: Could not load type" . Every time you find this on your KSP log, you have DLL problems that need to be fixed in order to have everything working right. It's this that causes KSPe to bork, as there're a bug on the Mono's runtime that screws up Reflection, a thing that KSPe relies to work. Additional info: when you find "[ERR 02:16:45.872] ADDON BINDER:" on the KSP.log, this is not necessarily a problem. KSP's runtime always print this when some code looks for a DLL and it is not there. This is not the problem, looking for things that aren't there is ok. What plays havoc on that Reflection thingy is trying to load a DLL that it's not there, or cannot be loaded due something else. — MOAR ISSUES -- You have a lot of ModuleManager DLLs on your root. It's recommended that you delete all but the one you intend to use. I once had a problem with a add'on that had an module manager DLL forgotten inside its folders, and this was playing havoc with KSPe. I also found this: [LOG 02:17:01.090] MiniAVC -> System.IO.IOException: Sharing violation on path C:\Kerbal Space Program\GameData\000_ClickThroughBlocker\MiniAVC.xml at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0 at System.IO.FileStream..ctor (System.String path, FileMode mode) [0x00000] in <filename unknown>:0 at MiniAVC.AddonSettings.Load (System.String rootPath) [0x00000] in <filename unknown>:0 at MiniAVC.AddonLibrary.ProcessAddonPopulation (System.Object state) [0x00000] in <filename unknown>:0 This appears to be a bug on MiniAVC - this happens when more than one code tries to open a file for R/W at the same time. On the bottom line, I would recommend deleting all the MiniAVC DLLs (I do that) and use KSP-AVC. ZeroMiniAVC can help you on this. — MOAR MOAR ISSUES -- You need to install also ToadicusTools. *A HUGE LOT* of parts are borking on loading//using/flying due: [EXC 02:22:48.494] FileNotFoundException: Could not load file or assembly 'ToadicusTools, Version=0.22.3.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. PartModule.Awake () UnityEngine.GameObject:AddComponent(Type) Part:AddModule(String, Boolean) Part:AddModule(ConfigNode, Boolean) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>c__Iterator1:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

I'm using it without perceptible issues. Yeah, KJR/L is not being "activated". What's really borking is KSPe, that borks when Mono's Reflection support gets corrupted by a failed DLL's dependency (and this is really something I don't know, yet, how to workaround as the Mono's runtime itself is getting corrupted by this!). Your KSP installment is inconsistent for sure, and is a time bomb waiting to start to tick. Publish the while KSP.log, please, so I can pinpoint you exactly the DLL that is in faulty. This kind of stuff is a bit hard to detect, but usually easy to fix.

because some people only wanted to use the engines, some others (like me) just the fuselage and by splitting the Add'On the maintainer can… well… maintain the two "products" separately , each one with its own life cycle. This make things easier to develop and maintain.

Impressive. Would you consider a career with the Empire? We offer an excellent Health Insurance.

I suspect they are avoiding the subject exactly due the headaches! The fun fact about the situation is that there is an iRescalable interface that could be implemented by the Add'On authors to fully support the feature. Add'ons that use this are working fine. And this is the main reason I'm taking some more pain in order to avoid breaking these guys - it would be hugely unfair to do harm exactly to the ones that played nice since the beginning, Had everybody adopted this Modus Operandi, instead of blindly shoving support by brute-force using MM Scripts (I'm not criticizing the tool, but the use of the tool on this specific case), we would had avoided this marvelous messup. But since is unfeasible to convince everybody to support TweakScale, and yet users still want to TweakScale such parts, my solution for the problem is to resurrect the idea, but coping to the fact that the scaling support will not be implemented by the add'on developer, but by third parties. This, way, TweakScale doesn't have to play cat and mouse by guessing things that changes regularly, and any stunt that would be needed to support a new or exoteric part will not compromise the remaining working ones.

A bit less work than you think - the hard part is to do not break things. Other than that, the work is moving code around and creating interfaces. A rewrite from scratch would face the exact same problems the current code tree have - "the others" (Sartre feelings ). The real problem, after all, is Unholy Interactions between Modules (Kraken food). And this problem cannot be tackled using a monolithic, one size fits all solution. But forking TweakScale (or any replacement) to each possible situation is also unfeasible, as 95% of the core business of the thing would be the same for every one and any fix or update would need to be replicated everywhere. On the bottom line, any rewrite that would follow the current TweakScale M.O. would have the same bad results in a near future, when things start to change again. So, such rewrite would had to do something equivalent to what I'm doing now with the current Code Tree. And since we already have a working code tree, and I already have a architecture solution for the problem, rewriting all the code would only add more complexity and attack surface for bugs - not to mention the work to preserve support for the legacy IRescalable clients. Right now, I have all of this already solved for free. TweakScale itself is working fine, what's happening is it being improperly applied.

I had tried to patch the already somewhat big amount of patches in the code, but once I figured out a way to make a part to (apparently) work, something else became broken. It's not impossible that by persisting on the task I could pull something out of my hat that ended up working - but the time I already spent on all this mess was enough to really fix the problem properly, and that hack probably would break next time anything changes… So I gave up. What it's planned for the next weeks are: Somewhat drastic refactoring of TweakScale code to decouple the problematic, part specific, code from the TweakScale core business. TweakScale scales Weight, Mass, Forces (Thrust, Lift, etc), Resources (Consumption, Production and Storage), Size and Cost and this will be kept in the core. And I need to keep legacy code working - some parts had implemented support by realizing IRescalable in their plugin code. I need to keep these working, or I will make yet more breakage. This is about 80% done, by the way Part specific code (including for stock parts) will be delegated to third parties DLLs (yeah, Plugin's Plugins!). Of course, the current set of supported parts will be implemented by me, so in the end, we will have the same classic TweakScale functionalities working under a new code tree Each Plugin's Plugin will be very picky about the parts it supports - no more broad guessing. I still need to figure out how to keep CKAN users happy with this change. I have about 30% of this task done by now. From now on, new parts or changes on some parts will be confined to the respective Plugin No more uncontrollable collateral effects by fixing one code that someone else was also using for another part Neither modules deactivating themselves without TweakScale being able to detect it. So, yeah, now the heat will be focused on the real culprits, not on the Screaming Victims! Problems will be way easier to be localized and fixed. Or at the very worst, punctually deactivated so I don't have to repeat this stunt again. About your understanding from that saying, yes. It's exactly that.

Interesting! I will pass the word to the one that told me that.

Rest assured that you (and everybody else) are doing exactly that. Correctly stating the mess it was done on the status quo is also a help. Choosing the less painful way out of a mess is still a pain, and the feedback about these pains are important to me as a decision maker - otherwise, I will ending up taking the wrong decisions in the future. (and it's also possible that I made exactly that this time, right? Had I did it, I need to be informed!). We have a say here where I live: "Espernear é direito do enforcado". People that had their savegames tainted are in their right to complain (you should had heard what I said to myself when I realized what it did to mine!). And I should hear them, otherwise I will miss that "less bitter spot" in the future in the unfortunate event I get myself involved on similar mess. Good thing I'm a software developer, not novel writer. I was trained in which we call around here "instrumental English" - a minimal set of grammars to make myself understood in technical writings. Dealing directly to normal people was out of scope of that training. And, to tell you the true, I'm not working for a corporation since about 10 years ago. I lost the touch. As a fun fact: I once mistyped "analysing" to another, but unfortunately correct (so the spell corrector let it pass) english word. Dude, that was a riot….

The history I was told is that the music he (Eduard Khil) was going to sing was in english, and by some reason, the music were vetoed by this fact. So he just "trololo'ed" his way out of the problem!

Agreed (on both sentences). I'm not doing a proper job explaining the situation, so let me try again. Until recently, TweakScale had a very broad approach on "supporting" parts to be scaled. This worked fine for many years, but then things changed: some new add'ons with particular behaviours came around, and KSP itself added features that TweakScale never had to cope with before. This is normal business. It happens all the time, and the alternative to that is using a product frozen in time - try to imagine a World where everybody would still be using Windows 95 OSR2… Yep, same thing. Problem is: some of that changes on third parties modules (and I'm unsure if the new stock parts are involved too, as my time window for properly testing this had closed!) were leading to a system crash. Worse, not an instantaneous system crash, but one that happened hours after the launch. Worse yet, that was corrupting savegames if the user had the unhappy idea of saving his game once that timebomb started to tick. First time that happened, it was months ago and me, as everybody else is used to do, blamed Squad: "Damn, another crash? AGAIN?". I didn't managed to relate the problem to any other add'on until a lot of time later I left my vessel alone for some hours and this happened: Some time after this screenshot, the statics (buildings and other non moving objects in scene) started to explode, and the game crashed. NOW I had something to work on, because by plain luck, this was a new KSP installment [with a previous version that never gave me this problem] without any savegames besides that one. And the add'ons. However, since it took more than an HOUR (not always, but usually) for the bug be triggered, I was not being able to zero on the problem until someone else also had this same problem and report it. Obviously, Murphy was a prophet: a lot of issues were, also, plaguing KSP and TweakScale at that time, I just didn't know who was doing what. A lot of apparently related issues were also diverging my attention. And then, finally this happened with someone else: Note that i spent TWO MONTHS pursuing things until finally someone else noticed and reported something I recognized - if you look on my Activities, you will notice that I spent very little time playing KSP on that time period - I spent all that time debugging and testing things. And yet, I couldn't figure out the reason for the crash until Tonka's crash (pun not intended). By analyzing his log, I could figure out a minimum set of add'ons to start testing things (i.e., the ones that were present in both installations - luckily Tonka's gaming style is very different from mine, so we didn't had so many add'ons in common). And them I realized that TweakScale is not the "real culprit", but the "Screaming Victim" - it only happened that such Screaming were scaring KSP to death. I never figured out for sure the exact conditions in which the crash happened. I don't know what one (or ones) of the issues I closed was/were responsible for the crash - all I know is that once I closed that issues, the crashing is no more. And since I still have to work to pay my bills, I can't spare the few time I have trying to figure out exactly what fixed what - it's a waste of effort, in the aftermath, as I'm not choosing what to fix and what's not, I will fix everything as the time goes. But until I fix everything, I can't allow Squad to being blamed by the crashes. Im not "guilty" by the crashes, but I'm responsible for TweakScale actions - and TweakScale was failing on prevent that crashes. I want to make this perfectly clear : Stock KSP doesn't crashes with blowing statics, modified KSP does. And TweakScale was the trigger for that crash. I'm a professional on this trade. I do software for living. As a professional, it's utterly unethical to knowingly allow fellow colleagues to take the blame for things I'm responsible for, even (to tell you the true, besides) I'm not being guilty for the problem. We call this "Responsibility". Worse, is more than unethical on knowingly allow something under my responsibility to crash and corrupt savegames throwing dirty on KSP's public image, what causes direct prejudice to their incoming - they do KSP for living, the same way I do my software. That said, I understand your reserves about the actions I took. I have them too, my savegames were also affected. I just couldn't figured out what else I could do - sometimes, you just can't win the battle. All that remains to be done is to choose the less painful way to loose it - and survive to win the next one.

Perhaps too much sometimes. I had worked on multinational corporations in the past, and had a training about handling "conflicts" that, I'm pretty sure, infected my way of communicate in english. It's usual that I "switch to corporate mode" without being aware, and re-reading what I wrote, I think this happened again. I'm becoming an old fart, and the clock just refuses to stop to tick. Oh, well. Perhaps I have to admit you are not wrong. You can perfectly be not right on the matter. I really appreciate your offer. Thank you. Given the presented situation where uncredited files are being pushed into people's repositories (some even licensed by MIT, by the way!), and then being used to publicly calling for a license infringement (what, in Open Source licenses, usually leads to automatic copyright infringement), accepting money for this work is, at the present moment, unwise. About licenses and copyrights, when money walks it's usual that bullets fly. I.e. once monetary revenue (of any kind) is involved, you are a lot more liable to damages under the Copyright Act. At the very best, I could lose the Patronage (see "Copyright Infringement") - the fun thing about Open Source is that it's very easy to spot infringements - the code is all opened to the World! This is much bigger than some people's egos. We need to rethink things before someone gets hurt. It certainly spoils the fun - I, as any professional on the field, have very little time to spend on hobbies. And wasting this time handling bogus license claims is, definitively, not the way I intended to use such time.

Eternal!

hint: "Let see, let me check all my Add'Ons....Yup, every one has a license, all of which seem to say something about attribution in one way or another." hint2: https://github.com/linuxgurugamer/VesselViewer/blob/master/license.txt (committed here)- from what I know, PeteTimesSix could be the author of the file. Your name is not mentioned on the file, there's simply not a chance I could guess anything about it. And this file is on more than one repository. And since you are pushing this file into other people's project without the needed attributions, how in hell one could guess you are the original author of the file? Do you want to be recognized for your work? Correctly follow the attribution rules and add a mention on the file, by God's Sake! In time, this is a not an issue anymore from now on. I think this is a good hour to move this discussion to : @Vanamonde, could you, please?

Do you know what's also tacky? Copyright Trolling. I don't know if you are, indeed, the original author of the file, but YOU had licensed it under the MIT on some of your projects. I don't have the slightest clue from where I took this file, but since usually I'm picky about licenses, it was probably from a MIT or "Do What the <piii> You Want" project. https://github.com/linuxgurugamer/VesselViewer https://github.com/linuxgurugamer/VesselViewer/blob/master/VesselViewRPM/AssemblyVersion.tt] —— — Jesus Christ. The guy is claiming copyright on a T4 template? Damn!

Try using Austrut to GrandParent on every "spaghettied" part. It use to work for me.

It will be done - but I can't say exactly when.. Check the issues, and if your part is not already included on one of them, please open a new issue. https://github.com/net-lisias-ksp/TweakScale/issues

I think it's safer to manually edit the craft file. Is not that hard once you get used to. Make a backup copy (always make a backup! ), then look for all the occurrences of the old part and change the name to the new one. Don't bother renaming the links, just the part name is enough.

Are you using AutoStruts? AutoStruts to root and to heaviest part need to be recalculated on separation, and more than one time this recalculation induced this misbehaviour on bigger vessels, as not all the joints could be recalculated in a game clock tick.