Lisias

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!

This is not wise due reasons explained here: In a nutshell, it will wash the detectable symptom away, but the nasty bugs will by still there ruining savegames - and I will have to cook yet another sanity check to reach the same goal. What would made the whole effort useless.

Advise your users before updating. This will break the savegames of every user your Add'On that have scaled parts.

Essentially, we lost the control of the order and incidence of the parts being patched. We have some double patching happening on the wild, and this are triggering some unhappy events on the user's savegames. The problem is described on this post and its being handled by this issue.

I think that, probably, we should think about that idea of deleting all default patches from TweakScale in order to make things a bit more "friendly" to users, what do you think? Alternatively, someone on TweakScale thread hinted another possible way to cope with that, by deleting previous patches before applying yours (didn't teste it myself yet): @PART[<part_name>]:NEEDS[TweakScale] { -MODULE[TweakScale],* MODULE[TweakScale] { type = stack defaultScale = 1.875 } } source:

Yes, this is the main problem I need to solve since the beginning : the lack of ":FOR" on TweakScale Patches that would help to solve the ordering of the patches. It's what triggered all this checks, by way, as I realized early that this would cause some issues and started to implement the safety-checks. What caught me with my pants down is how widely these problems were already happening on the wild. I can't thank @Jammer-TD enough for the incredibly worthy help he did on the issue #42, by the way. I could had theorized the possible problems, but I was not aware of how much of them were indeed current until he hinted me about with his tests.

That is TweakScale's default patching borking. Will be fixed for the weekend. If you are absolutely sure you are not scaling MK4 parts, you can delete GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg . This will make the Alert go away by bluntly removing all Mk4 patches (the good and the bad ones). on a side note: I have a savegame with Mark IV parts scaled. I confess to you that I'm finding courage to check that savegame!

Fixed. Thanks for the heads up. I don't understand what is happening. By using https on the link, we get that weird red page. So I put http instead - that so redirects to a https URL equal to the link that was there before. go figure it out. Krakens.

Well, I don't know from where is that patch, but you found the problem yourself. There're two patches for smallwingConnectortip on this file. And for tbmProp too. The good news is that the patch being applied twice have the same content, so this is that single situation in which this issue is not a problem - so your savegames are not at risk for this. But I recommend fix the file (search for every duplicate, and delete it). Ideally you should apply the fixes to the upstream, but I didn't recognized the file content (it's way different from the TMasterson's one), and there're no identification on it. Well… But this part of your problem is diagnosed. That's what matters now. About the fatals on the MK4 parts, these are TweakScale's fault - and, yeah, these ones are the serious ones. Sorry. I will fix this on the next minor release, that will be issue in this weekend. I will do my best to have this being published Friday night so you people don't lose another weekend due this. Until there, don't use any MK4 with scaling on your game or we will have some trouble on your savegames.

Thanks. From your log, one of the problematic parts is smallwingConnectortip from AirplanePlus. However, there're no standard support for it (i,e., not from me neither from AirplanePlus maintainer), so I think that you are using TMasteron5's patches. However, your patches doesn't appears on the TMasterson5's original place, as we can see here: [LOG 09:19:19.017] Config(@PART[smallwingConnectortip]) AirplanePlus/TweakScale/@PART[smallwingConnectortip] Originally, it is expected to be on GameData/TMasterson5TweakscalePatches/AirplanesPlusTweakscale/tweakscaleConfigPatch.cfg . So I'm afraid I can't help no this for now. Can you confirm the source of the patch you are using? The following issues, however, are on me. I found that the MK4 patches from TweakScale are using wildcards, and are a potential source of problems. This will be fixed in the next minor release, that will be issued as soon as possible. Interesting. Appears to be something on one of the event handlers of the part. Yep, you are right - there's a good chance it's a bug on TweakScale's code. Opened a bug for it: https://github.com/net-lisias-ksp/TweakScale/issues/52 I will work on it for sure, but not for while. Please be patient. Thank you.