Lisias

Both! He created his own extension for the UpgradeScriptFix. A similar stunt was made to help Atmospheric Autopilot to survive a problem on the control surfaces on 1.8. https://kerbalspaceprogram.com/api/class_save_upgrade_pipeline_1_1_upgrade_script.html Things are starting to make some sense now! Thanks for the suggestion!

Sounds like a plan. How I do that?

Check the Toolbar Control's dependencies. If they are not met, the plugin is not loaded besides being installed, and things borks the same.

We should never do any I/O on the UI-Thread, but yet Unity does. So if we have a lot of threads running, in need to do I/O that it's only safely done on the UI-Thread due the design of Unity (probably due legacy from the Unity 5 and earlier), you will need to take that hit. The solution @micha gave above appears to be the best compromise. -- -- -- POST EDIT 2020-1006 -- -- -- I WAS WRONG. Logging on Unity is thread safe, the dudes made it right. It's KSP that messed up somewhere, somehow on the logging into the screen stunt. In a way or another, some locking mechanism is still needed indeed - what happens is that locking mechanism need to be applied higher on the stack. -- -- -- POST EDIT 2020-1008 -- -- -- Nope. Logging on Unity is thread safe on 2019. On 2017 and Unity5, it is not. (sigh)

Send me a craft with the problem (and the KSP.log of the instalment). It sounds like something about surface attachments. Since TweakScale does not scales Struts and Fuel Ducts, perhaps something else can be interfering? Welcome. Give a try on the turbo-fans too. I have a lot of fun scaling the Junos. -- POST EDIT -- I gave a minimalist test session using a minimalist instalment: Inline Mk1 Cockpit, FT-L400 tanks scaled up and attached on symmetry. On KSP 1.9.1 + KSP Recall + TweakScale (both latest release - see KSP Recall thread, 0.0.3.2 is on the wild), I got this after reverting to VAB On KSP 1.10 + Tweakscale, but now I remembered to add the Struts: I found no evidences of misbehaviour on both tests. All DLCs were also installed on both test beds. -- -- POST POST EDIT -- -- I redid the 1.9.1 test, this time using also the Struts. No problems detected neither (image after launching and reverting to VAB)

ANNOUNCE KSP-Recall 0.0.3.2 is on the wild, all distribution channels were updated. Nothing really new, except that KSP-Recall will (safely and correctly) withdraw itself from parts when it is not needed. KSP 1.10 users that are migrating their crafts and savegames from KSP 1.9 with KSP-Recall will receive a complain from KSP about the "Resourceful" Module being missing. This is normal and expected, and no collateral effects are expected by going on - KSP 1.10 does not need Resourceful, and it would be a waste of memory and CPU cycles to having it installed. if someone knows of a safe way to suppress that pesky warning, please talk to me. Finally, it came to my attention that some people are telling users that they NEED to use an alternative fork of Module Manager to use KSP-Recall (or TweakScale). This is wrong at best (or just plain slandering at worst). Everything I publish on Forum is coded to work with add'ons published on Forum - if they work also on better alternatives not published here, it's just a bonus.

METAR It came to my attention that misinformation is being spread about KSP-Recall and TweakScale. This is wrong at best (or just plain slandering at worst). Everything I publish on Forum is coded to work with add'ons published on Forum - if they work also on better alternatives not published here, it's just a bonus. [snip]

[snip by Moderator] I'm sorry, but I need to correct you on this. Unfortunately, your knowledge (and affirmation) is far from corresponding to the reality and should be checked. Every Add'On I publish on Forum is tailored to work with others add'ons published on Forum. I don't break the user space. Similar things that would happen if you uninstall a fuel switch after using it on a part: the part became "defaulted". It only happens that on TweakScale things are dramatically visible on the spot:

Some days you just can't win. No new releases today, guys. KSP-Recall and the Companions will have to wait. The good news: I nailed down the bork on the TweakScale module's withdrawal. As long as I confirm how really I should do this stunt, I will update everything using it. The gory details will be published on the issue: https://github.com/net-lisias-ksp/TweakScale/issues/125 - once github is back online.

Yeah, this was a bork of mine when handling crewed parts. Since only crewed parts needs to have the crew count scaled, I only registered this listener when the part has crew seats. However, this dud sas writing you this post forgot to deregister the listener, and so a partless zombie module lingered trying to access a part that was already garbage collected. And as you load and/or edit new vessels, more zombie modules end up lingering on memory, spamming the KSP.log. However... This was already fixed. I just noticed that you are using an older TweakScale version: [LOG 17:52:28.994] [TweakScale] Version 2.4.3.15 /L So updating it will be the best option for you. I also noted a lot of Exceptions like this one: [ERR 17:57:30.836] Module TweakScalerFSbuoyancy threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an objec t at TweakScaleCompanion.FS.Buoyancy.TweakScalerFSbuoyancy.InitInternalData () [0x00042] in <9042ad2d21684961ba52e9c0c294474c>:0 at TweakScaleCompanion.FS.Buoyancy.TweakScalerFSbuoyancy.OnLoad (ConfigNode node) [0x00056] in <9042ad2d21684961ba52e9c0c294474c>:0 at PartModule.Load (ConfigNode node) [0x001ab] in <9d71e4043e394d78a6cf9193ad011698>:0 These are happening because the Helper I wrote for FSBuouancy had some design flaws that blowed up on my face once I updated TweakScale to cope with the new behaviour from Editor about surface attachments. This is already fixed, but I didn't managed time to publish a new version for the Companion for Firespitter. You may want to wait a bit before updating, because I'm finishing the (new) FINAL release of the TweakScale 2.4.3 series and so it will save you a new update. The FS Companion (and every Companion with Sanity Checks) will be updated next, hopefully before bed time (as now I know exactly what to do). Additionally... There're a lot of additional (hopefully unrelated!) exceptions on your log. Once you update TweakScale and the Companion for FS, I suggest checking again for Exceptions and call for help from the current maintainers of the add'ons involved. Cheers. (and stay tuned!)

It's unlikely that removing APIE fixes the Konstruction trying to access a method that doesn't exists. Removing KSPe will only mask the problem, as it will not be logged. It's not a fix. This log entry says that KerbalConstructionTime.KerbalConstructionTime.OnGUI is calling (or calling someone calling) a thingy called bool ToolbarControl_NS.ToolbarControl.LoadImageFromFile(UnityEngine.Texture2D&,string) , but this method does not exists on the loaded Assemblies. HOWEVER... You really detected a problem, just didn't pinpointed the right culprit. I will come back with a fix on the Welding tool in few minutes - don't have a clue if it will fix Konstruction, but it will fix the NRE on the WeldingTool. -- POST EDIT -- That fix on the WeldingTool would not fix any problem, that code only logs a fancy message about having ToolbarController installed or not, the code that really uses Toolbar controller is working. What you need is to INSTALL TOOLBAR CONTROL. Konstruction is borking because he is trying to use this method: // This function will attempt to load either a PNG or a JPG from the specified path. // It first checks to see if the actual file is there, if not, it then looks for either a PNG or a JPG // // easier to specify different cases than to change case to lower. This will fail on MacOS and Linux // if a suffix has mixed case static string[] imgSuffixes = new string[] { ".png", ".jpg", ".gif", ".PNG", ".JPG", ".GIF", ".dds", ".DDS" }; public static Boolean LoadImageFromFile(ref Texture2D tex, String fileNamePath) From this code of Toolbar Controller. But since you didn't installed it, it's borking. You will fix the problem by installing ToolbarControl. (don't shoot the messenger! KSPe is helping you!)

It's like @TranceaddicT said: Unity's developers, in their transcendental wisdom (this was an exercise of sarcasm), decided that everything would be an URL on its guts. But the rules for naming an URL are different from the rules for naming files, so you need to URLEncode and URLDecode the filename all the time. It sucks, no to mention the slightly penalty impose on everything that tries to read a Kraken damned file (urlencode, than "GET" it using the tcp-stack's "file://that-kraken-damned-file" into memory, and then using it). And yeah, this is another factor contributing to long loading times on KSP - when you have thousands to files to load, any extra 50ms delay per file became 50 seconds easily. So people here just give this not so nice piece of retangular paper the finger and opened files using the C# file library. But then we got a mismatch between the filename and the resource name, that people worked around by just avoiding anything that would be URLEscaped on the filename (as spaces, that turns to %20). On TweakScale specific case, and since the information I really needed was already on memory, I choose to just flag the parts loaded from files with "unholy characters" so I can easily get to them on the log if one of these parts gets flagged by an insanity or some other error. In order to really flag the part as unmaintenable (i.e., synthetically build into memory instead of coming from a file, and so how in hell this thing got TweakScale at first place?), I would had to URLdecode the resource in order to match the filename, but really interesting KSP instalment have a huge amount to parts to inspect, and any 5 ms of extra delay needed to be really sure about something that can or cannot be a problem would easily became 10 seconds of extra time taxing the user wanting to load his savegame and play the thing - so I ended up just flagging it as "unholy" to save the user a bit of burden. If you are authoring the parts, please don't use them. This forces you to use a name for the patch, and another for identifying the part on memory: # on a config file PART { name = my_fancy_part <yada yada yada> } # on a patch @PART[my_fancy_part] { <yada yada yada> } # On C# code: void myUnityHandler() { if ("my.fancy.part" == this.Part.Name) { <yada yada yada> } }

NOTAM Some time ago, I detected a problem on the mechanism used by TweakScale to withdraw itself from "insane" parts. I was right about the prognostic, but I was wrong about the diagnosis. It's not something on KSP, but a change on TweakScale itself that broke some invisible equilibrium and ended up failing the module withdrawal. What I got it right: it's possible to remove a module from the prefab as long it happens before some event (yet to be correctly detected). What I got it wrong: on the past, that event was happening after the DryCostWriter phase, and I wrongly assumed that such event would be loading or creating a savegame. The fact is that such event can happen at anytime after the Main Menu scene is fired. When I refactored TweakScale to cope with the new way Editor handles surface attachments, I broke that equilibrium I mentioned, and the side effect is that the "event" started to happen in a way that borked the Module withdrawal from the prefab. This behaviour is consistent down to KSP 1.4.1 (didn't bored further test below it) using the current TweakScale code, so it's a TweakScale flaw. This is important because, right now, parts that had TweakScale "almost" withdrawn this way I'm doing now cannot be attached to crafts, the part just doesn't "snaps". This opened issue #125. So, I gave up withdrawing and only deactivated the module. This solved the issue from KSP 1.10 down to 1.4.1, what again pinpoints TweakScale as the only culprit for this problem. I didn't tested enough, yet, which change on TweakScale broke that equilibrium that allowed the withdrawing to work on the past, but it's reasonable to think that such equilibrium can be broke by anything else (and this explains one weird issue I was never able to diagnose before). As long as I get some rest (had I mentioned that I spent the night in readiness on an infrastructure migration? it went flawless, by the way, I spent 95% of the time diagnosing a lot of issues here!), another glitch on the matrix will mysteriously happen and then TweakScale 2.4.3.18 will prevent a temporal paradox by being the FINAL release for this troublesome (really troublesome) 2.4.3 series. Oceania had always been at war with Eastasia, and TweakScale 2.4.3.18 was always the final release of the 2.4.3 series. KSP-Recall and all the Companions that does Sanity Checks will be also updated - I don't care if they already manifested the problem or not, the withdrawal mechanism (besides looking a good idea at that time) proved itself unreliable right now. Once this fire is off, I will leverage on the two years of knowledge acquired reading source code from a lot of add'ons (and the kitchen's sink), something that I hadn't yet when I first wrote the Sanity Checks, and will cook a new (and deterministically able to be proven safe) way of executing the Sanity Checks. Most of them does not need to be carried out on Main Menu and now I know better ways and places to carry on such tasks. The reason I insisted on the Main Menu stunt was due Making History apparently adding - or did added in the past - things on the prefab on Main Menu first appearance, and some of that things had borked on TweakScale at that time (it's the reason I count the parts on the prefab before executing the Sanity Checks, only going on after some frames without that count changing). TweakScale 2.4.4 will have this new mechanism implemented after being validated on the field by TweakScale Beta.

Oukey, a TweakScale Companion for Configurable Containers is being planned now. On the other hand, I just realised the reason I didn't had noticed the problem on the Craft Cost not being updated immediately on each change. I did regression tests down to 1.4.1, and noted that on KSP 1.5.0 the Cost stopped being updated when I change the Scale of the part. But I also noted that Editor Extensions Redux somehow "restored" the functionality - so it's something on KSP 1.5.0 that I missed, mainly because I always use Editor Extensions Redux on my gaming (where this glitch would had been easier noticed), and it masked the problem. [edit: false alarm, it was something that I missed, as now EER is not "solving" the issue anymore...]. Well, we solved three problems (mine, yours and another one) by the price of one (the regression testing I did due one of them). Cheers! It's a fuel switch that also affects the mass, cost and resources. FSFuelSwitch and ModularFuelTanks works because they are supported on TweakScale's code, and IFS works because TweakScale is supported by it. Now I need to work support for CC, and things will be settled.

I need also the KSP.log, ModuleManager.ConfigCache and also everything under <KSP>/Logs/ModuleManager. Without these files, I'm on the dark - it's unfeasible to install all the Add'Ons and trying to reproduce the problem by guessing, and the KSP.log will tell me exactly what I need to know when something borks, and will give me exactly what you have installed on the gamedata (including any custom patches you may have), and not only a list of add'ons that could be badly installed.

Ouch, it's my bork on Knes. Sorry. Some time ago, I leaked a double patch when I was writing the TweakScale patches for Knes. [LOG 17:55:54.570] Applying update Knes/Compatibility/Tweakscale/Knes-ATV_TweakScale/@PART[_Knes_STEAM_CrystalLab]:NEEDS[TweakScale]:FOR[Knes] to Knes/Parts/ATV/_Knes_STEAM_CrystalLab.cfg/PART[_Knes_STEAM_CrystalLab] [LOG 17:55:54.572] Applying update Knes/Compatibility/Tweakscale/Knes-ATV_TweakScale/@PART[_Knes_STEAM_CrystalLab]:NEEDS[TweakScale]:FOR[Knes] to Knes/Parts/ATV/_Knes_STEAM_CrystalLab.cfg/PART[_Knes_STEAM_CrystalLab] However, this is already fixed on the latest Knes, I just checked. Please update Knes to the latest. (I just refreshed the page and noted that @Azic Minar has already solved it for you.) I'm checking this right now, but on a wild guess I think you are running KSP 1.9 without KSP-Recall. By a lucky strike (or lack of luck) I'm running a lot of regression tests on the latest TweakScale and previous KSP versions, and I can say for sure that: On KSP 1.5.1, the problem didn't manifested On KSP 1.6.1, neither On KSP 1.7.3, nope. On KSP 1.8.1, nope**2 On KSP 1.9.1 (with KSP-Recall), nope**3 On KSP 1.10, I got something unexpected: it worked fine too. (I'm on the middle of a long night monitoring a serious infrastructure change on our biggest customer - please excuse my weird sense of humour at the moment ). The tests were made with a Minimal KSP Instalment (KSP, TweakScale, Module Manager and the minimal set of Add'Ons for my customised tools). I used an Inline Mk1 Cockpit, and attached a FL-T400 scaled to 1.875 fuel tank radially. Then I Alt-Clicked it 3 times, attaching the new tank on the previous one. Then I unattached the first tank, turned on the mirror symmetry, and attached it again. I ended up with a 15.100 Funds useless contraption on the Editor on all situations. I will need your full KSP.log and ModuleManager.ConfigCache (and also everything under <KSP>/Logs/ModuleManager) to figure out what's happening on your rig. You will get there. Thanks for the help! -- -- -- POST EDIT -- -- -- @Krazy1, I found a glitch however - When you scale an attached part, the vessel price is not updated until the next vessel change - any change, including switching the Variant. Saving the craft doesn't update the cost on the screen, but loading it shows the correct price on the screen. I think I need to fire up some event on KSP to have this fixed, but I really doubt this is the cause of your problems.

I found a strange way of detecting ModuleManager on the code, and fixed it. Thanks, @Braste , for the heads up. And you have one problem less too, as this fork works on KSP 1.4.0 to the newest flawless (1.3.1 is possible, but I need to tackle down something on KSPe first - it's there the problem, not on MM). Yes it does. Exactly as the Official fork, by the way. The reason for the problem described by @Braste is that I wrote a thingy called ModuleManagerWatchDog to prevent multiple installations of MM on KSP >= 1.8 (due a strange new behaviour on the way Assemblies are loaded now), and it happens that the current code assumes that anything starting with ModuleManager is MM, and the WatchDog ended up bitting my SAS on it. A pull request was issued for the current maintainer, and until a new official release is issued, you can use mine or plain delete GameData/ModulerManagerWatchDog.dll , keep using the official one and call it a day.

Already on the works. It will take a week or two, but it will be done.

Yes, it looks remarkably similar. What was happening on TweakScale is that something on Editor guts was kinda interfering on the OnClone handler, reseting the Resources setting to the prefab one (instead of cloning the Resources of the part being cloned). The KSP-Recall stunt of mine were essentially a new interference, interfering on the previous one to shove back the last known Resource settings (that was detected by monitoring the OnEditorShipModified). But this interference was fixed on KSP 1.10, so perhaps you should give it a try first? (it's a wild guess) In a way or another, @ElonsMusk, a craft file and a log file will be useful to further pursue this problem!

ANNOUNCE A weird and inexplicable glitch in the matrix happened, and one release of TweakScale vanished from this Existencial Plane due a rupture on the Space Time Continuum. Don't ask, I blame Einstein for this. It's recommended that all users of TweakScale download the new current Release to avoid a temporal paradox. Links on the OP.

There's a merge error on line 276 from the file <KSP_110>/GameData/SquadExpansion/Serenity/Parts/Robotics/RotorEngine_02.cfg: RESOURCE { name = LiquidFuel rate = 0.01 resourceFlowMode = STAGE_STACK_FLOW_BALANCE == </ HERE, this is line 276> } RESOURCE I wonder if this can be related to some issue on KSP? How KSP handles errors on the Config File? On the bright side, it appears to be the only syntax error on the whole set config files. Hey, @SQUAD, I made a python tool for checking and reading config files in a couple hours (adapting from the already existent source from Taniwha's io_object_mu), it's not hard and the time has already paid itself (and it works on anything that runs Python). I suggest implementing checks for every config file for obvious errors as a Unit Test before releases, typos and merging errors happens every time - mainly on teams running against the clock (this is not the first time, right?)

Humm.. Now I got it. Third Parties add'ons are not supported anymore on TweakScale! Everything that used to come (but Stock and DLCs) are now deprecated and will not be updated anymore. All third parties add'on support is now on the TweakScale Companion Program! Check there if this not already made, I have a huge amount of NF patches on tests right now.

I did. 3 Days without coding a single line on KSP. Spent them helping to diagnose a pretty harsh infrastructure problem that was affecting our customers - pretty nasty, and the fix was absurdly stupid. No. You can safely delete it. To tell you the true, you probably should. KSP will complain about the Resourceful module being absent from the system on first loading savegames and crafts. You can ignore this.

Soon(tm). I'm avoiding CKANing rushed releases too soon to prevent widespreading eventual mishaps. I realized it's safer to expose new releases for a day to early adopters and monitor my ears: if they start to burn, CKAN (and SpaceDock) and CurseForge are postponed. It will just waste a bit of memory, as the features will deactivate themselves when uneeded. You can force the activation of the module on a specific part, however. It may help on some pretty weird hypotetical situations - if you fix something new with this stunt, kick me on KSP Recall thread, I'm interested on hear about. (I want a lasagna now. ) acknowledged. this problem you detected is interesting and important. "hard core" moddings is where the real fun is, and not rarelly exposes problems on the laying framework itself. We manage to diagnose and fix this, we made things safer for everybody. We can have a solution to better compatibility (aka "no more toe stomping fests"), and people can spend more time creating and playing than fixing problems. Create a new savegame after removing ReStock and see what changes. Then install it again, and check for changes again. It's how I managed to fsckup my testbed. It's too soon to pinpoint a cause (and I think there's no cukprits this time, it's one of that weird situations in which everybody do everything right, but yet something does not cope well and BADABOOM.). Trying to. things are a bit hairy around here. I'm trying to stay calm and keep coding in the mean time.

Are we talking about this? [ERR 19:58:09.371] Exception handling event onEditorShipModified in class TweakScale:System.NullReferenceException at TweakScale.TweakScale.OnEditorShipModified (ShipConstruct ship) [0x00000] in <c3d11dd12519438cafd8dbec2a0a0668>:0 TweakScale.TweakScale.OnEditorShipModified (ShipConstruct ship) (at <c3d11dd12519438cafd8dbec2a0a0668>:0) Yeah, I borked beautifully on this one. @DefenderX1, it's fixed on the latest TweakScale, currently 2.4.3.16. 73. Q.R.T. over.