Lisias

NDAs and Sincerity are mutually exclusive concepts, sir. You can bet your SAS there're people dying to open their big mouth and tell us what's happening. But they can't, and I understand them - there're things I told here that at that time when I was working on some companies, that would render me jobless for life - and a nice law suit shoved up where the sun don't shines. There're some details that even nowadays I keep shut, and I won't even talk about the consequences about disclosing such things. Besides... Trying to figure out the internal politics of corporations are fruitless. It's perfectly possible that we could have some very good news in the near future and this tragic sequence of events we have nowadays are the less expensive way for them to reach that goal - or you can be right, and all of this is going belly up. There's a fifty-fifty here, we just don't know. Accepting the bad fifty is Game Over, so I prefer to keep bashing their SASes hoping for the other fifty. Our altercations here could end up being used as an argument for changing some goals and internal processes - corporations may be evil, but most people inside them are good. But it's up to us to react about. Corporations need money, it's all they care about (and for good reasons, they have a very expensive party to pay for). We manage to convince them they are going on very unprofitable path on the long run, they will change their ways - probably not exactly the way we want, but near enough to be profitable for them on the long run - and for us, as our profit is getting a good game to spend our free time. This does not need to be a zero sum game.

The stuttering I worked around with MOAR MEMORY and fixed Add'Ons (and GCMonitor) - I forked almost everything and the kitchen's sink to use on my 1.7.3 as time passed because the maintainers weren't supporting 1.7 anymore, and I think I detected and solved some memory leaks. But not all of them - but in a way or another, it ended up working for me. On KSP >= 1.8.0 I got some really bad memory leaks on KSP itself. My KSP starts up with less than 4G of allocated memory - but as I play, reverting to launch, then quitting to main menu and selecting another game, etc, the memory footprint grows up to 15G before my whole machine starts to stutter. I had memory leaks on 1.7.3 too, but not so severe (unless I shoved a lot of add'ons on it, on KSP >= 1.8 I have the problem on a vanilla or minimally modded installment). We need to remember that not everything is over Squad's shoulders - a huge lot of problems on the Unity 2016 era were due faulty add'ons - on the first year of my tenure on TweakScale I detected so many flaws and errors on everything that uses TweakScale in a way or another, some of that bad interactions leading to instant CTD of KSP (when lucky). It was that NaN and Infinity on the physics engine stunt - boy, that was a hell of a year until I managed to get things tight. We still have one or two severe memory leaks on add'ons nowadays, mostly due third party closed source libraries that are terribly coped with the C# runtime. And we have Unity - a serious source of problems by itself. Almost everyone that publish content, you mean. Most users limit themselves to the "What did you do in KSP today?" thread, and some others keep their own blog for KSP - and some of these last ones are running pretty older KSP installments, some even on 1.2.2 yet. Content publishers, at least the ones I attend now and then as time allows, don't have a long term commitment with the savegame - the goal is to produce a nice 20 to 30 minute video, not to have a longterm mission that would last multiple KSP releases. So the current bugs are easily avoided by not creating content that use them. Just my 2 cents, though.

Frankly... Nowadays I'm dreaming on 1.7.4...

Well... Anyway, I already had fired the thing. I loaded the Sample Craft called Bug-E Buggy and made some tests: Scaling things down too much will mess up the wheels coliders, but the thing didn't wandered away on launch. (I removed some non-scalable parts from the vessel). So I scaled up the thing (and had to add some auto-struts to it). And no drifting. On a side note, this last test hinted me there're something wrong on the scaling the colliders - so this test was not useless. Thanks! In a way or another, this is something on your installment. Mine works fine - I really need a concrete example from you so I can keep digging on the matter.

Oukey, now I'm the Good Cop. I'm way more conservative on updating: I never ditch a working installment - I still have my old 1.4.3 and 1.4.5 rigs with the savegames and add'ons installed as they were when I migrate to 1.7.3 (I jumped over all the other ones). Worst case scenario, I fire them up and start playing from where I left. The disk space is not too much of a problem if you compress the files (it also saves some time on loading). CD Project Red comes to my mind. Perhaps going nuclear would be the only way out of the mess the whole Software Industry had shoved themselves in. (oukey, perhaps not that good cop). That would work on an ideal World, but I'm afraid that the KSP's Revenue Model had shifted away from paying users. What would be the new Revenue Model, I don't know but, as always, follow the money and you will get your answer. Someone is paying for the party. I find it terribly heart-breaking - but I completely understand you. And I agree, had Squad issued a 1.7.4 release with some more pressuring bug fixes, and boy I would one of the most satisfied consumers even nowadays. When they finally got a grip on it, they changed Unity versions and had to start all from scratch again on 1.8.0 - and I find it, as I said, heart-breaking. Looking back, the 1.8.0 release should be exactly a ported 1.7.4 to the new Unity, with the whole 1.8.x series focused on fixing regressions. You can bet your SAS things would be way better if they started to create new things on the hypothetical 1.9.0 only. I don't necessarily agree that the re-skins are atrocious - they are pretty IMHO. But, granted, not exactly needed - they could shoved all of that on a DLC as far as I care, or perhaps someone could release a new Add'On called UnStock? I'm pretty sure some die hards would like to have the old look and feel (I like the old Mark1 Cockpit more than the new one, the way - but the new one is splendid for some civil aviation crafts I like to build!). Oh, and by the way, I would buy a new DLC called "The Barn" I hope there're more like me around - and that KSP would do it before someone else does (as by then, I will probably switch hobbies - there's a new guy on the block going Crimson Skies style that it's almost getting me on it). Nowadays KSP is prettier, it's faster, there're new and well polished toys to play with. It's ok to prefer the old ways (I do, by the way), but this doesn't means that the new toys are worthless - there's a place for them. Had Squad managed to allow us to choose the toys we want (instead of hardcoding support on KSP guts and forcing their hand on the matter), they would be handling a lot less heat. This does not need to be a zero sum game. This is where things get me absolutely mad about. Now they don't have even the new feature working right - and good luck trying to download 1.11.0 from Steam at least, as the last notice I had is that the depots were removed (as well as a huge lot of other historical ones, terrible - Those who cannot remember the past are condemned to repeat it! - George Santayana). Now I'm probably the only one that can check things on every KSP version ever released on Steam - and, believe me, this is way far from ideal. A release breaking the flagship feature followed by a terrible decision to prevent rolling back to the release where it was working - not exactly the best way to satisfy your users. (humm.. I'm a failure as a good cop...)

So KSP Recall will not help. Zip the thing and post it here https://github.com/net-lisias-ksp/TweakScale/issues/92 with a link to your post. I will check it. (I'm firing up my 1.11.1 test bed anyway, let's see what I get)

In which KSP version? The sliding happens when the vessel is parked or when it's running? If you are on [1.8.0 <= KSP <= 1.10.1] and the sliding happens with parked crafts (it affects Kerbals too) , then install the latest KSP Recall. It's a bug on KSP itself, and Recall kinda work around the problem. (I suggest waiting a few hours, I'm finishing an update with an important fix on a library it uses) Otherwise, please publish your craft file so I can give it a look - it's easier to look for problems with a concrete example on hands!

Not to mention some more tragic consequences, right Boing? I had worked on this industry in the past. Wrote a iPod stack (iPods were a thing at that time) for an auto-radio on my times as SiemensVDO/Continental/Schaeffler-Gruppe/God Knows who owns who nowadays. You make a mistake that drives away the driver's attention from driving and something bad happens, you are toast. You fail to do something completely irrelevant to withdraw you from a chain of events that cause an accident, you can be sued. It's hugely frustrating to know how things can be hugely better by doing simple and easy things - people do way better on hugely more demanding and complex industries due exactly these simple and easy things that nobody cares nowadays, as it appears. I let 10% of such amount of bugs I see here leak to my clients, and loosing my job is the least of my problems - I get sued my pants off. Simple like that. And more frustrated you get as you understand what's happening and how easy would be to prevent some of the most pesky bugs we had or have now.

Try installing this one : https://github.com/net-lisias-ksp/TweakScaleCompanion_SMCE . It adds up to date TweakScale support to Large Part Boats, and more are to come (now that I know people is still using it). Well, you state yourself the need to the current buttons: people just instinctively clicks on "OK", instead of coming here complaining. But by you coming here complaining, I could do something to fix the issue - see the link above. Most old patches will stop to work somewhere in the next releases, and this is a fact - as I fix and improve things on TweakScale, some things that used to work will not work anymore because I'm getting rid of the kludges made in the past to cope with odd situations from third-parties. Now these odd situations are tackled down case by case on the Companions - but failing to install the Companions will render your savegames inconsistent. There's no easy way out of the mess. I make your life easier the wrong way, I risk ruining your savegames - and once people's savegames are ruined, they will blame TweakScale (as it was done in the past) and not themselves by doing the wrong thing. And this will affect the add'on's reputation (as it did in the past). I can offer you the same I did for @Cochise - I customised, non supported, completely "rogue" compiling of TweakScale without any the messages on screen you don't like, but you will be at your own as no support will be offered by this custom version. Yikes.... Libraries are fantastic tools to save efforts by sharing code - until something goes wrong and all the tools break at once. Yep, but the strings themselves differ. The "not on" directory is missing a trailing Path.DirectorySeparatorChar. This should not be happening anymore, I already had preemptively tackled this down some time ago. Obviously, I missed something. I'm working on it. The need for this stunt is because, nowadays, when KSP finds another copy of a DLL, it shunts it to the first one it loads - but links it as it were the newest one. So you can have a older DLL code being running while the runtime reports being the newest one (this had bitten Module Manager's SAS beautifully by the way). Now, with TweakScale changing release by release, risking an older Scale.dll somewhere else on the system is just unacceptable - trying to diagnose problems with the runtime lying to you is plain suicide. Definitively, you should had asked. Thank you for the report, and apologies by the mistake (it's a bug - I reopened the issue where this should had been fixed in the past: https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 ). If more than one TweakScale is found on the system, you should not keep running the game or you risk absolutely unpredictable consequences (going from nothing bad to completely ruining every savegame you open right on the spot). Of course, it's not this case - the code that checks it is borking on you - I just need to know where and why. Yep, known issue. Not sure when I will tackled this down, however - the criticality of this one is very low. Once the first modal shows, ideally the user should abort everything and get here burning my years ears, and the KSP.log will have the needed information from the failed modal windows anyway. Well, I'm working on it. I also need to understand why this happened on Manjaro but not on MacOS and Gentoo (where this was already tested), as everybody runs the very same code by the way. Can you follow up on the https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 issue? I will need some more info about your rig... [Dont bother, I found where I forgot to add some things...]

I do! Nemo is my name? I manage to "downgrade" craft files by editing the file and manually changing the version value to the desired one. It's not perfect, sometimes you need to reconfigure a lot of thingies, and another ones you need to manually remove some modules or rename some parts. But it works most of the time for me. Obviously, do it with backups. Lots of backups

Not if the older version has anothet bug that you won't tolerate. That's the problem with the current development process: there's no stable release of the product, ever. Every new release solve some problems of the previous, but also shoves a lot of new bugs or misfeatures - and only some of them will be solved next release, when new bugs and misfeatures will be added.

I found a bug inside a bug. Essentially, two different codes were causing the very same misbehaviour - but both codes were cleared in the past because "fixing" one of them didn't solved the misbehaviour - it was needed a twist of fate (i.e., testing on my slower machine so I could see the misbehaviour in slow motion) to realize that I needed to change two different (and somewhat unrelated) codes in order to get rid of the misbehaviour. I made a lot of mistakes on coding in my live, but this one is a new.

I'm happy and somewhat embarrassed to tell you that the problem (apparently) was... humm.. overcomed [fixed]. It ended up that it was, indeed, a bug that I unadrevtidly introduced while trying to tackle down a problem on Chain Scaling - I tried to fix it on the symptom, instead on going straight into the root cause as I misdiagnosed the source of the problem. Well, I removed the "fix", and fixed the description of the issue what was handling it: https://github.com/net-lisias-ksp/TweakScale/issues/131 The Chain Scaling is now (yet more) broken on symmetries (apparently only on mirror!), but the thing was not working properly anyway - so the after math is positive. On the bright side, I also diagnosed the problem with the chain scaling (it is ignoring the symmetry of the parts, and so some parts were being handled more than once - one by the code, the additional ones by the KSP gut's echoing the changes over my changes). I will try to fix this too before a new release, but if I fail, at least your issue will be fixed on the next release tomorrow night. -- -- POST EDIT -- -- humm... I may have found something else that can negatively influence my proposed scheduling... -- -- POST POST EDIT -- -- There was a bug hidden inside the bug! https://github.com/net-lisias-ksp/TweakScale/issues/163 It's fixed. It will be published on the next release.

CTDs are diagnosed by analysing the Player.log, as this happens inside Unity's guts - out of the reach of the KSP's realm. Additionally, posting logs directly on Forum is not a good idea. It overloads the page, and makes it hard to browse the Forum on mobiles. I suggest you to remove the log from your post, and add links to some file publishing service as dropbox et all.

Now we have a problem, because these are the manifests I used to download it on December, and I just double checked the values on steamdb. This is less than desirable news, you now are locked up on 1.11.1 (and downgrading to 1.10.1 would break the savegames). CKAN is prone to crash even when you know what you are doing. Post a bug report on CKAN's thread and ask for help. Until there, your only way out of this mess is to manually install the add'ons you want.

Probably someone forgot to update the thing. It will be done sooner or later. Until then, you can use the console to download the depots directly. It's a bit cumbersome, but it works. open your browser type steam://nav/console This will open the Steam Client with a new tab, Console type: download_depot 220200 220204 6595377442804801725 download_depot 283740 283740 6300531123014751372 download_depot 982970 982970 3333344034773284668 These will download the Win64 version of KSP 1.11.0 and the respectives Making History and Breaking Ground. Then wait the Console print the message that the download is done. Pay attention to the pathname being printed, the depot will be available there Now you need to copy the folders to the target place. On a side note, it's usually a bad idea to mod the game under Steam's control. The best you can do is to copy the recently updated folder to some other place and play from there.

I was trying to build a Ore Train. Essentially 5 of that 4 wheeled car chained using Serenity Hinges - I need to play with these things a bit in order to understand how to scale them, but then I realised that I can't launch the monster due this bug. Using Vessel Mover to launch it kinda solved the problem, but then I realised that I cannot switch vessels when the monster was on the runway otherwise they would ICA the same. And since the problem kinda happened too with unscaled wheels too, these issues are unrelated - or perhaps not, but if they are related, "my" stunt suggests that the problem is on the KSP engine in both cases. (Boy, I would hate to be a test pilot on these things - poor Jebediah!) Well, now you have evidence to support your hypothesis. Depending on how you build the craft, the weight is being miscalculated somehow (I think it's going to infinity, due the way Vessel Mover is behaving at spawning that monster). It's absolutely logical that drag et all can also be failing on the same problem. I'm guessing that this could be related to using a octoStrut or even the strutCube? This last one has no physics relevance, I was told...

Welcome aboard, fellow (new) Kerbonaut! And remember: Theres No Such a Thing as a Too Big Of A Rocket!! (Elon Musk is our fault!) P.S.: Keep an eye on the thread below, lots of interesting things to see! (really, you need to check it! )

Could not think on a better place to post this than here! Beautiful craft.

Nice one. Technically, it may not be a bug , it's a technical debit already described on the KNOWN ISSUES (the variant stunt). If you use a part without variants (as the MK1 Liquid Fuel Fuselage), things works fine. But it appears to be a new symptom for the technical debit, it was my understanding that only parts with variants that changes attachment points would suffer from misbehaviours (as this specific code is not implemented yet), and I reproduced this problem using a FL-T400 that IIRC doesn't changes attachment points on changing variants - so I will not rule out a bug yet. But I will need some time to tackle this down, I have a considerable back log both on TweakScale as on my day job... and you have a work around for it. I will advise as soon as I manage to steal find time to check this. -- -- -- POST EDIT -- -- -- On Mirror Symmetry, the misbehaviour does not happen!! NOW I'm worried - if the damned thing was misbehaving the same both on Mirror and Radial, things would be way easier to understand and fix...

METAR I finally nailed he problem plaguing me and described on the last METAR. I ruled out TweakScale as a source or even a trigger for this problem. TweakScale is merely a facilitator (or enabler?) for this problem, it happens that TweakScale just made the problem easier to be triggered. What happens is that, under certain conditions, we cannot have a pretty heavy part (as a scaled up LargeTank full of ore) into a octoStrut, put some wheels on the strut (or in the adjascent one) and then have a SEQ9 and a Service Bay between the heaviest part (usuallly the LargeTank) and the root part of the craft! I managed to reproduce the problem only when the Mk1 Inline Cockpit or the Mk1 Crew Cabin are the root part, but I failed to detect the reason - probably it just happened that any part would trigger the problem and I didn't tested enough. I detected situations where rerooting the craft into the noseCone solved the situation, but in some other it did not. In all situations, rerooting the craft to the heaviest part solved the situation. So my verdict is that there's something borking up the code that finds the heaviest part starting from the root part - if there's some specific parts between them (and the heaviest part is really heavy, something only easily obtainable using TweakScale...), and you have Wheels on a pretty sweet (or bitter?) spot (apparently another octoStrut), we have ICA (Instantaneous Craft Annihilation). The whole story is on the https://github.com/net-lisias-ksp/TweakScale/issues/162 with the most interesting entries on the bottom of the page (the first ones are my failed attempts to zero in the problem). In a nutshell, the following crafts are OK on my tests: But these ones blow up on launch: And the only difference between them are the order in which they were built!!! The very same end result can blow up on ICA or just works depending on the order you place the parts on it. There are also some other unexplainable explosions happening that may be related to this problem! Now... HOW IN HELL I report this stunt on the KSP bug track??? o.O

Proper support is eternal work in progress. Ideally it should be simple, merely a new ScaleExponent and some patches on the parts. However....Cheese Happens. Sometimes, something inside KSP just refuses to collaborate or, worst, decide it's a good time to troll us. Right now I'm fighting to identify the reason by some imported crafts from 1.10 just ICA on my face on launch (ICA = Instantaneous Craft Annihilation) : https://github.com/net-lisias-ksp/TweakScale/issues/162 Robotics parts are proven to be tricky to deal with, and my experience from the Infernal Robotics taught me that there're numerous opportunities to summon the Krakens when scaling such things due the somewhat more complex physics involved - you overscale or underscale something, and the Rage of the Krakens are summoned on you. On a side note, the Serenity's robotics are still more complex than Infernal Robotics - as these things also have dampeners to care about! TS 2.4.4.x are somewhat more relisent to changes than 2.4.3 and older, because I resurrected the code that migrates scalings. If you have a part on your craft that was defined to have a defaultScale of 1.25, but later it was revised to 2.5 (a very common mistake), now TweakScale detects and rework the scaling to fix the craft. However, it only works fine when the scaleType is Stack. If the new definitions change the scaleType to free, the migration code will probably fail, and so you will probably have problems when updating Add'Ons that provides new TweakScale patches. Once you install All Tweak, you need to be extra careful when updating and installing add'ons with new or revised patches for TweakScale. In time, since TweakScale does not have ScaleExponents for Serenity, the scaling will be cosmetic only: smaller or bigger, the robotics parts will behave exactly as the unescaled one: smaller robotics will be absurdly strong, and bigger robotics will be unexpectedly weak.

Yes. Should it be a real problem (aka, missing DLL on the system), the victim DLL would just not be loaded (and another error would be logged on the KSP.log about missing dependencies), or an NRE would be issue if the code had tried to manually load an Assembly and use it without checking if the operation had succeeded,

Yes. But I think we will need the Player.log too, as the KSP.log doesn't have the crash report. You will find this fine on C:\Users\<USERNAME>\AppData\LocalLow\Squad\KSP\ The ADDON BINDER "errors" are just noise. Every time you ask the runtime for a unloaded Assembly, the AddOn Binder prints this error even if it finds and load the Assembly. I think the KSP's Asssembly Resolver was written on the KSP 0.2 times and perhaps this error made sense at that time, but nowadays these ones are just plain noise.

Good point. I initially thought on the upgradepipeline because it was used to fix up a bork with the control surfaces deploy position, that was playing havoc with Atmospheric Autopilot - so I jumped into the conclusion that if it would being used to fix something like this, it would also being used to do any kind of transformations. On TweakScale, I detected that whatever was shoving back into the craft data from the prefab (overwriting the ones read from the file) was being executed after OnLoad and before OnStart (where originally TweakScale had some migration code that suddenly became dead on the water), and this also hinted me on the upgradepipeline. Well, learnt something new today - rarely a bad experience. In a way or another, my last hypothesis was proven wrong. Since I have a craft file that explodes on launch, and the exact same craft rebuilt from scratch on 1.11 and that works, I'm KDIFFing the parts from both files looking for something weird and... Well, nothing is different to the moment. The parts that I identified as probable source of the problem (since changing them on the bugged file solved the issue) are the Mark2Cockpit, ServiceBay.125.v2 and cargoContainer - and these parts are virtually identical on both files, but small changes on the the fields: part persistentId pos, attpos rot, attRot, attRot0 link, attN And this is the last nail on the current hypothesis' coffin. So, being used to change values on crafts or not, the upgradepipeline is innocent on this one.