Lisias

I once hacked some parts to be Ox only. It was intended to be used on Reusable Liquid Fuel Boosters for a cargo space place - the fuel was internal to the craft. Yeah, I know. But it made sense at that time. I also use MFT regularly, but I also use the Community Resource Pack . With tons of new kinds of resources, the default ratios now and then are not enough. But… I'm using CRP, it's absolutely not a stock feature.

And yet more interesting. Are you talking about line 600 of the file Scale.cs (at v2.3.9 release tag)? Transform trafo = part.partTransform.FindChild("model"); (it's currently "Find("model")" on line 590 as FindChild is deprecated since God knows when, this post is from 2013!). I think it is, as the commit message says "get "model" transform by name instead of assuming that it is the first" You have a hell of a memory, dude - I can't remember what I had for lunch yesterday (if I had lunch yesterday, I forgot! ). Well, we are talking about KSP 1.0.x to 1.1 transition here. And, guess what… On 1.1 Squad updated the Unity from 4.x to 5. So.. Yeah, blame Unity on that. But yet you brought some good insights. It's an idea to test this problem on previous KSP versions to see what happens. This can be something that gone unnoticed for years, or something that happened recently and checking the release notes of the first KSP that shows this misbehaviour should trimm down the scope of the hunting down. (assuming this is not something done by me, of course - some serious digital archeology is on the way)

Because I need to calm down, decompress and get ready for a hell of a tough week.

We are on the same page now. Look for log messages mentioning "[ERR hh:mm:ss.mmm] [TweakScale] " or, if you are lazy as my, with the string "/issues/" This is a practical example from my last test run: [WRN 23:55:54.957] [TweakScale] Removing TweakScale support for FSfloatEnd. [ERR 23:55:54.957] [TweakScale] Part FSfloatEnd didn't passed the sanity check due using FSbuoyancy module - see issue [#9]( https://github.com/net-lisias-ksp/TweakScale/issues/9 ). Every time you see a "Removing TweakScale support" on the log, that part is one that would bite you if you use it on a existing save game. In time, the next TweakScale release, 2.4.3.1 (to be release soon, but I don't know how soon yet ) will be somewhat helpful about these issues. https://github.com/net-lisias-ksp/TweakScale/issues/57 (I'm almost there. )

I gave some thoughts on this again, and realized that perhaps what follows could be a better idea, as supporting ranges of KSP versions would be cumbersome (i.e support from 1.3.1 to 1.7.1). How about adding also KSP_OLDER_<MAJOR> KSP_OLDER__<MAJOR>.<MINOR> KSP_OLDER__<MAJOR>.<MINOR>.<PATCH> KSP_NEWER_<MAJOR> KSP_NEWER__<MAJOR>.<MINOR> KSP_NEWER__<MAJOR>.<MINOR>.<PATCH> to fullfil that use case? I think this stunt would cause the less impact on the MM code - besides being somewhat ugly.

I think this is not a bad idea at all (while we already have some Add'Ons that do that). But I think this should be restricted to the SandBox only - or perhaps available on the Career and Science as a Cheat.

No (unless you was using some other problematic part). The screw up just happens when the savegame is using a badly pacthed part - the unfortunate thing is that usually we just realize the problem after loading the savegame and by that time, it's already cripped. Please backup all your savegames just in case. I'm afraid we have a misunderstanding. The whole mention on this forum if from you. Sorry. However, if we are talking about this stunt: TweakScaleDisabled = "Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section." Then yes, once TweakScale detects a specific kind of problem, it salvage the day using this trick. However, this is related to whole MODULE[TweakScale] being duplicated - when the dupes are inside the same MODULE, it's a completely (but equally nasty) problem that is will be proper workarounded on TweakScale 2.4.3.1 (still to be released). The KSP.log, however, are already logging up these problematic parts, so at least you can be aware of this. — — — — ANNOUNCE — — — — For you, brave Kerbonaut that laugh on the face of the danger and giggles at savegames corruption, a new BETA, UNSTABLE AND POSSIBLY DESTRUTIVE BETA Release 2.5.0.2 is available on the github issue #42. Please use this stunt only on disposable KSP installments (i.e., you duplicate the whole thing somewhere, install this thing and once got fed up on testing it for me, plain delete everything including crafts and savegames).

Firespitter using TweakScale to trim the size. Note that this aircraft is unbalanced - onde the fuel tank is depleted, the CoM will change somewhat. I think I should had added a new one between the front wheels to keep it balanced as fuel is consumed - or perhaps just clip the current one on the truss between the wings?

HUmm… I'm a dud SAS. Craft Manager does that. I will check the Craft Manager source for part of the problem! https://kerbalspaceprogram.com/api/index.html https://docs.unity3d.com/2018.4/Documentation/Manual/ (I think KSP uses an older version, but it's better than nothing) On a side note, I would love to have access to the previous versions of the KSP API. Ok, I can use reflection on the older ones - but that information was already available before.

Yet more interesting! So apparently the problem hits only a root part when scaled? C# Development on MacOS and Linux is far from being a pleasant enterprise, if we can take CKAN as the rule of thumb. [Installing and using Mono runtime on MacOS was a nightmare, and when I managed to do it, the GUI was terribly formatted]. If an external tool is the way to go, I'm inclined to try Python if I can. I had very good results with Pyinstaller in the past (successfully 'freezed" a GUI/TUI application to run on Win32, Win64, Linux and MacOS before). However, I had an idea this afternoon. If this stunt sticks, it would be the definitive solution for the problem!

There's a Hook in which I could register a code of mine to intercept the loading of a savegame in order to check for something and if something bad is detected, I could abort the loading process to prevent the savegame to be ruined? And for a craft? To prevent a damaged craft to be loaded without warning? Yeah. I'm talking about a McLisias' Anti Krakens!

Problem is that by opening a mangled savegame on a sane KSP it will be too late. By the time I could check it, the damage would be already done and you would need to kill KSP by brute force (kill -9 or the windows equivalent) to prevent it to write back before quitting. This must be a tool outside KSP. A hell of a work to be done under a week. Not to mention the potential bugs on new code...Hummmm... Perhaps not.... I would have to break a lot of rules by accessing directly the savegames while still on the Main Menu, and I can do a regular expression search, I think I don't need a full parser. And I would need to be somewhat unfriendly as I would need to prevent the user from entering a game while processing. The current behaviour of the Fatal message already give this to me, so part of the problem is kinda solved already... But this would "burden" all the users no matter he/she have or not the problem. I need to find a compromise to avoid hammering everybody undistinguishably...

Do not start new games until the 2.4.3.1 release, with the patches fixed. The old savegames are safe for now, and on the next release you will need to use the "Breaking Parts" patches to keep them ongoing. (they will be included on the ZIP file) If you want to start a new game right now, download manually and replace on your installment the following patches (click on the "Raw" button: B9_Aerospace/B9_HX.cfg (https://github.com/net-lisias-ksp/TweakScale/blob/dev/emergencial/2.4.3.1/GameData/TweakScale/patches/B9_Aerospace/B9_HX.cfg) Squad/Squad_Engines.cfg (https://github.com/net-lisias-ksp/TweakScale/blob/dev/emergencial/2.4.3.1/GameData/TweakScale/patches/Squad/Squad_Engines.cfg) MarkIVSystem_TweakScale.cfg (https://github.com/net-lisias-ksp/TweakScale/blob/dev/emergencial/2.4.3.1/GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg) These are the patches where things are fixed (but can play havoc with old savegames that use the broken parts). New savegames should be using the fixed patches (and the new TweakScale will complain loudly every time something is weird, so users can be always advised to check things when new Add'Ons are installed and the messages are triggered). — — — — Hummm… I'm considering releasing a intermediate TweakScale relase, identical to the current one, in which the only purpose would to alert every TweakScale user about the problem, and after one week, release a new release again with the proper fixes. A lot of users just update via CKAN or other automatic procedure, and do not read this forum or the Release notes... Thoughts?

If the following parts are being scaled on a savegame, there's a patch to revert the fixes in a controlled and deterministic way to keep the ongoing savegames alive: SXTWingSmall (Mk0B Small Modular Wing) SXTWingLarge (FAT-460 Super-Lift Aeroplane Main Wing) SXTInlineAirIntake (XM-600 1.25m Air Intake) SXTOsaulNoseCockpitAn225 (Kn-225 "Osaul Payload" Cockpit) SXTOsualRadCockpit (Mk.P-Yavka Radial Cockpit) SXTtruckbox (Truck Box) I strongly advise to do not use the following patch on new savegames, the purpose of the patch is to allow you to keep playing your current savegames. This patch will make your vessels not compatible with future releases of the Add'Ons. The patch can be downloaded from this link (and on future releases of TweakScale), and you can place it anywhere on your GameData - I suggest dropping it on a folder called __LOCAL (i.e.: <KSP>/GameData/__LOCAL) to be easily found and deleted when not needed anymore. For any doubts or support on this, please kick me on the TweakScale thread. No savegame will be left behind. Thank you. —— — — POST EDIT — — — I found this AddOn that would help a lot to prevent problems on these transition times! If anything goes wrong, the last backup can be restored and then the patches mentioned applied.

The 2.4.3 version is warning you about something that is already happening. Unfortunately, rolling back only get rid of the message, not from the problem. My best advise to you is to do not install or deinstall anything from your rig until the next 2.4.3.1 version. Some problems happened due an interesting interaction between two or even three Add'Ons, and if anything changes you can get your savegame mangled. It can be salvaged - just keep backups so, if anything goes wrong, we can fix the last working savegame. The 2.4.3.1 will still have this message and a few more (that ones, only warnings and not a show stopper like this one), and a full list of parts that were being affected by problems until the moment will be published as well optional patches that will "break them again", this time on a deterministic and safe way. These optional patches will be released to keep savegames using the broken parts ongoing, so no savegame will be left behind.

News from the Front. Real Life stubbornly insisted on getting on my way, but I managed to accomplish the needed tasks for 2.4.3.1 . It's currently under tests. I will not set a deadline however - last two times I did that, I botched . But it will happen soon. For the curious: https://github.com/net-lisias-ksp/TweakScale/tree/dev/emergencial/2.4.3.1 https://github.com/net-lisias-ksp/TweakScale/milestone/7

Interesting. Apparently drag is not being scaled down. Could you please test if it scales up?

"Wildcards on patches"

More or less. The ConfigCache is how things will be on the prefab. Then, after MM data injection, on the Main Menu a lot of Add'Ons are triggered, and they do some specialised changes on the GameData. SscanSAT, KAS, Mission History, and more, do that. And now TweakScale. The net result is that the GameData doesn't reflects anymore what ConfigCache have in its records. TweakScale, however, appear to be the only one that undo some things when it detects a problem. It plain withdraw any TweakScale support from problematic parts, so the problem is not even saved on a craft file (and savegames) with TweakScale support, preventing triggering problems on older TweakScale installations. What caught me with my pants down is KSP insisting on using prefab's TweakScale module information from a part that have the info on its MODULE node. If such data is on the craft, what's the point on trying to use the prefab data to overrule the craft data? And if the prefab data is meant to overrule craft data, why such data is saved on the craft file at first place? In a way or another, it's unfeasible to expect KSP change this (be it a mistake or a valid change that fixed some other problem), so it's up to me to deal with it.

Hummm .. So this is what happening. I didn't understood the first time this was reported https://github.com/net-lisias-ksp/TweakScale/issues/41 Yeah. Somehow, KSP is using both prefab and craft data to instantiate something. Now that I have a deterministic way to reproduce the problem, I can test it and try a fix. On a wild guess, I think I should instrument TweakScale to detect these issues and shutdown itself for that part.

Statistically, perhaps. But don't undervalue a good hint given by someone outside the machine room where I'm living from some time. We usually narrow our mindset when solving problems, what sometimes lead us to take a not so good decision. Not to mention learning a new trick or two from people that knows better some details (yeah, I learnt something too!).

The cannonical way is to fork the project, hack the changes, commit, push and from the GitHub site issue a pull request. It's easier than it looks, but is usually a bit cumbersome for non developers. But you also can publish the file using pastebin or something and publish the link here. We can compare the fixes, sometimes we miss things. --------- On a side note, I expect to release a new version tomorrow. Real Life got into my way about releasing something today.

(moved from the wrong thread!) Yep. There's TweakScale, the MODULE, and there's TweakScale, the "stock" Patches. It's not Module's fault, it is doing exactly what it's being told to do. I'm "teaching" it to detect some bugs, but there's a limit on what can be done automatically. About the Patches…Well. Some of the problems are on me. Some of the TweakScale stock patches have the problem too, and to tell you the true I completely forgot to check my own patches before doing the release. Until the moment, not a single report was due only the Stock Patches, but yet they are there. On my defense only my Career game (still on 1.4.3 , the mainstream version on the last time I really played) detected these problems now that I fired up with the newest TweakScaçe, but as I said, it's more exactly ONE YEAR since I fire up it since the last time!!! (dude, it was running one of my first "unofficial" compilations of TweakScale yet!) Somewhere else on this forum I said that would be a good idea having more developers playing more the game in order to foresee in advance some possible consequences about the decisions they make. Guess what? It applies perfectly to me too. Once TweakScale 2.5 goes gold (the Milestone I'm slowly pursuing through the 2.4.* series) I will take a break on this and go back to my Career. No Kerbal should be dragged away from his game for that time! There's a possible compromise on this. Until the moment, almost every single rogue patch was trying to "overcome" the default behaviour. These ones, once everything is fixed, will still be the dominant ones - with the additional benefit of not risking ruining games when Add'Ons are installed, updated or even removed - destabilising the brittle balance that is allowing things to work at the moment. There're some others that are applying the same patch twice. These ones are 'almost' harmless - but since they are applying themselves twice, they will be being applied twice even if something else tries to overrule them. And then we would have a new instance of the last problem. The nastiest problems, however, is when different patches are applied by error on the same part. This is a serious game braker because these patches are not only changing things in a unattended way (the others were doing it on purpose to get a new, predefined behaviour), ruining the current game, but they also are "vengeful" as they also ruin the game when things are fixed! This is not safe, as some rogue patches ends up acting only under determined circumstances. Anything gets different, the savegame is ruined as the brittle balance that were reached is broken and the chain ends up with different results. So we need a set of deterministic, custom made patches, that would allow these savegames to carry on without being at risk. This is the reason I'm asking people to send me their KSP.log and MM ConfigCaches - to be able to detect if these Doomsday scenarios will be a reality and then, when the TweakScale 2.4.3.1 is issued, I will be able to provide custom parches that would mangle the parts back to the wrong behaviour (saving the game), but without the risk of things going through the tubes due rogue patches going straight.or something. EXACTLY!! Backup everything and kick my up. Once I detect exactly where thing are wrong, I can handcraft a patch that would "break things again", but this time in a deterministic and safe way. What makes me think that I should "mark" these parts somehow and tell TweakScale to remember the user, regularly, that he doesn't should start new games using that installment. Good brainstorming, @zer0Kerbal . This is what the good software feed on! Thanks!

It's not TweakScale, it's the Patch. TweakScale patches are made of building blocks, and the default ones can be found in the ScaleExpoents file: TWEAKSCALEBEHAVIOR { name = SRB MODULE { name = TweakScale TWEAKSCALEEXPONENTS { name = ModuleEngines minFuelFlow = 3 maxFuelFlow = 3 maxThrust = 3 -ignore = ModuleEngineConfigs } } } So you can create your own TweakScale Behaviour, using the scales that suits you. And then just apply them to your parts as it's done on the "Stock" Patches: @PART[LaunchEscapeSystem] // Launch Escape System { #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } This makes TweakScale extremely flexible. Of course, I'm just explaining how things can be done. By no means I intend to do nothing else but to explain TweakScale inner workings.

Whoops. I posted on the wrong thread, moving the post to the right one!