Lisias

It gets descaled to default settings! This can be quite entertaining on flying crafts... Backup everything and give TweakScale 2.5 Beta a shot. It appears to be your best option right now. — — — POST EDIT — — — @starfall22, the problems started at 2.4.6.19 . Download and install 2.4.6.18 and you should be right - at least, on my test bed, the problem didn't happened.

Well, it was doing the right thing before. Now it doesn't. I'm trying to figure out what and why, but at least I already know where. It's going to be a long night. There're more parts affected, but the strutCube is one of the most used. Statistics can bite our sorry SAS on the most unexpected ways. Yes. More than one, by the way: For crafts that does not have parts scaled, load them and save them on a KSP rig without TweakScale installed. This will get the TwealScale module section removed from the crafts, and when you load them again with TweakScale installed, things will be fine. A quick and dirty way to do that by brute force is to open the craft file using a TextEdit e do a search and replace for "name = TweakScale" to "name = TweakScaleFoo". When loading the craft KSP will complain about missing "TweakScaleFoo" module - just ignore it and load the craft anyway. KSP will inject back a new TweakScale section with current, problemless data. For crafts that does have scaled things, things are going to get a bit more complicated. One easy hack is to delete the "patches" folder from the new TweakScale and unzip the ones from the older TweakScale. You will use older patches, that are (probably) compatible with your crafts, avoiding to trigger the problem. These patches are old and I deprecated them for a reason but, hell, the whole meaning of this whole stunt is to have a nice KSP gaming session and you are not getting one right now. Screw that patches, use whatever will make things work for you now. For things that are unescaled, just rename the TweakScale module to any sillyness and KSP will get rid of them and inject back nice, modern values. Frankly, this is one of the things I was intending to prevent with a thingy called Stealth Save, where TweakScale modules would be omitted while saving unscaled crafts. But I had to deactivate that thing due issues with 3rd parties. — — — On a side note, I just realize that TweakScale 2.5 (BETA) doesn't presents the problem, only the mainstream branch (2.4 series) are problematic right now. I'm trying to figure out why Beta is working and Release is not. On the bright side, once I understand why Release gone South the fix will be obvious. What leads to a 3rd way to survive the problem: Install TweakScale 2.5 beta. This thing is bleeding edge, and it can bite you in the SAS because, well, it's in frantic development and I didn't properly tested most of the new code. But, hell, this thing is working for your use case. And you can revert back to TweakScale 2.4.6.21 later - I do it constantly on my test beds withuot any (noticeable) problem until the moment. (ping @starfall22 about the 3rd option)

Well, the blown up part in your screenshot is the "strutCube" (internal KSP name for the "Cubic Octagonal Strut"). So I gone through a fishing expedition on your logs. Found this: [WRN 03:11:51.698] [KSPCF:ModuleIndexingMismatch] Part "strutCube" configuration has changed. Synchronizing persisted modules... [LOG 03:11:51.698] [TweakScale] WARNING: Upgrading ScaleType! Craft 4283071424 had the part strutCube:FFE2A390 scaling changed from (TweakScale: default=100.000, current=100.000) to (stack: default=0.313, current=0.313) The entry for KSPCF is telling us that this part had the order of the Modules different from expected, and then KSPCF reordered it. This is not a problem for TweakScale (as long there's only one MODULE section for TweakScale on the part, and this is the reason TweakScale freaks out when it finds more then one). The second line is telling me that the original craft file had different scalings from what is defined on the TweakScale patches. From the ConfigCache, I got: UrlConfig { parentUrl = Squad/Parts/Structural/strutCubicOcto/strutCubicOcto.cfg PART { name = strutCube module = Part <....> MODULE { name = TweakScale type = stack defaultScale = 0.3125 } So this confirms that your patching is good, it's the same I get here on my rig. But your log is saying that TS had migrated the patching from a 100/100 to stack 0.3125/0.3125 - what makes sense, as some time ago TweakScale had the patches revamped and I wrote a migrating code to avoid screwing up people like it happened to you. So perhaps the migration code became broken somehow? So I created a test craft consisting of a Drone Core and an strutCube. The strutCube TweakScale section is: MODULE { name = TweakScale isEnabled = True active = True available = True currentScale = 0.3125 defaultScale = 0.3125 defaultTransformScale = (0, 0, 0) So I changed it to: MODULE { name = TweakScale isEnabled = True active = True available = True currentScale = 100 defaultScale = 100 defaultTransformScale = (0, 0, 0) To match what I think it's yours, and fired up my KSP. I got the same log entry as yours, and when I loaded the craft on Editor…. Yeah. The strutCube got gigantic. (sigh). Ok, confirmed. But now I have a problem - when I wrote that code, it worked. It was intended to survive issue #87 . I spent the whole year (Dec 2019 to Dec 2020) fixing things slowly to avoid breakage, and - damn - I had tested the damn thing. I don't know what changed (yet), but I'm working on it. https://github.com/net-lisias-ksp/TweakScale/issues/285 I already know exactly the code that it's borking, but I don't now yet why. Working on it right now. — — POST EDIT — — It worths to mention that on March, 2022 I made TweakScale to behave from migrating users from All Tweak. All Tweak is a hack to add a minimalistic patch to anything that is not patched with TweakScale by blindly adding "free" scaling on them. All Tweak was a head ache at that time as when someone writes proper patchings, parts that were using All Tweak misbehave exactly as this issue. Well, at least I know where to start to look for what changed from March 2022 to nowadays. Now I have a benchmark.

Damn. There's something happening on the field, and I don't have the slightest idea what at this moment. I can rule out Auto Scale and Chain Scale being wrongly triggered on Flight Scene as these things are handled by events that only happen on Editor. There's no way (known to me at least) that these features would be triggered on Flight Scene. Borked patches are a known way to cause these problems, and I could easily craft a patch to do this kind of damaged on my test bed. So I think I know what is happening, but I don't know why it's happening. And since you reproduce the problem using an old release of TweakScale, not to mention that newer TweakScale had given you a Warning about something fishy, I think that what remains to be known is who is applying these patches. Please send your KSP.log (you will find it on the same place where the KSP's exe file is!) using dropbox, google drive or by dragging it on a post on this issue on Github (you will need a github account for it). I would suggest you to zip the thing first! If you can find the ModuleManager.ConfigCache file (directly into your GameData directory) and the ModuleManager's logs (into <where_you_ksp_exe_is>/Logs/ModuleManager) they may be of help if the KSP.log doesn't have all the data I need (i.e., the patches were being loaded from the ConfigCache).

Sir, I managed to reproduce this misbehaviour by intentionally screwing up the default TweakScale patches. It's old knowledge, to tell the true, these things are happening since forever - people installs crappy patches on the the rig, and then blame TweakScale for doing what's it is expected to do: to scaling things using the patches applied. Your problem is not this "damn mod". The problem is the damn crappy patches you installed on your rig, and I strongly suggest you start considering carefully about restricting yourself from installing things on it without the proper care. I also suggest you to consider a good Backup practice - you stating that you had "fixed" the problem by manually editing the crafts leads to the conclusion you don't do backups at all (otherwise you won't had to edit them, a simple restore from the most recent backups would had done the job). I have almost 5 years of historical records of TweakScale, carefully documenting all the problems (including my own's) and anyone caring to read all that krap will eventually conclude what follows: about 80 to 90% of all support tickets are due something else screwing up things, and TweakScale is the one calling about the problem, not causing it. I understand your anger and frustration, this was exactly the reason I choose to adopt TweakScale at first place: It took me almost a year to correctly identify and workaround all the issues that leaded to this problem. From bad patches inducing TweakScale to calculate Zero on some part's mass (making them "stuck" on the 3D world, and everything attached to it started to blow up due the stress) to double patching, confusing TweakScale in using the wrong patch set on a time where the KSP Upgrade Pipeline didn't existed yet - you name it. (I still have that savegame, by the way - I think I will be able to retake that one still this year! ) I had my bad moments, no doubt - but on the absolutely majority of the time, the source of the bugs were, and still are, tracked down into 3rd parties' misbehaviours or problems on their artefacts. I suggest you to take a deep breath, calm down and then bear with me in order to diagnose the problem that screwed you. There's a very high chance that whatever had screwed you will screw up someone else again, and it's better for both of us to diagnose it and to have a fix for it as soon as possible. Please send me your KSP.log where the problem was reproduced - make a full backup of the thing as a disposable copy, install TweakScale back on the disposable copy and then when things go south, quit KSP and send me a screwed craft file and the full KSP.log (please send the KSP.log, not the Player.log - this one is almost useless to me). Good luck. — — POST EDIT — — A series of intensive testes (see the posts below) revealed that, this time, the problem is another completely different. It's uncertain if this is really TweakScale's fault, but it's not ruled out neither. This is a very weird one.

Damn it, you confirmed my initial guess. B9PS apparently needs KSP-Recall in order to work together TweakScale. I recently removed Recall from parts with B9PS due potential conflicts a user reported, but as it appears, it's better to keep B9PS under Recall's unbrella - a potential conflict is better than a carnage like this.

I need your KSP.log in order to try to check this. This is not TweakScale normal behaviour (of course), and this wasn't happened on any of my test beds. It's more likely a 3rd party interaction than anything else. What you describe may happen when someone screw up the default patches badly, confusing TweakScale into rescale the parts using a bogus defaultScale.

That's unfortunate, to say the least. Doesn't looks exactly as a TweakScale bug, because I could not reproduce the problem. Well.. First things first. I tried to reproduce the problem on a clean KSP 1.12.5 first, to rule out 3rd party influences. So I fired my "ACP" KSP test rig, with KSP 1.12.5 and the latest releases of Forum's Module Manager, TweakScale and some other Add'Ons I publish on Forum. If this is a inherent TweakScale mibehaviour, I would be able to reproduce it on this rig. So I fired up a new SandBox game, gone to VAB and : loaded the Stock craft Dynawing - a somewhat similar Stock craft to the one you used. Activated Chain Scale and Auto Scale on TweakScale's settings. Scale up the root part (the MK3 Cockpit) to 5m Nothing wrong happend. Saved the craft and load it back Nothing wrong happened Now I rerooted the craft into the Mk3 Cargo bay where the Hydraulic Detachment Manifold is plugged into Nothing wrong happened Now I rerooted the craft into the Kerbodyne S3-14400 fuel tank Nothing wrong happened I tried to reroot into the Hydraulic Manifold itself, but Editor didn't allowed. Saved and Loaded the craft a bunch of times while rerooting the thing into different parts. Nothing wrong happened Then I removed the boosters+tank from it, saved it Shuttle as Craft A Reloaded the original craft. rerooted and removed the Shuttle from it, and saved as Craft B Loaded the Craft A, then injected the Craft B as subassembly into it, rebuilding the original craft. And got royally screwed by AutoScale!!! So I tried again, but deactivating the AutoScale and Chain Scale from TS. Nothing wrong happened. Even the EAS struts reconnected to where they were. So this rules out TweakScale as being the cause of the problem. If it works on Stock, anything wrong on your rig is being caused by something else - where TweakScale can be, at worst, involved on the problem somehow. I will install Modular Launch Pads and try the same tests using the craft you mentioned. I will edit this post with my findings. Uh… Steam doesn't updates add'ons, and the last release for KSP is from January 11, just checked the SteamDB for the Manifests. I think you are meaning CurseInstaller or CKAN, right? — — POST EDIT — — I forgot to test merging the subassembly. Edited the steps above. No change on the results.

Welcome! Do you have firespitter installed? If yes, download and install the TweakScale Companion ÜberPaket, it will install TS support for it (and some others).

This new fork has them back. Right now, there's no much you will get over 4.1.2 - the only thing that may be of use on some borderline situations is the configuration option to set the maximum range allowed for lights (it's 150 meters on the code and also on the config file, but you can change the config file to a bigger number if you are bold enough - didn't made any studies about impact on performance, if any). But I have some ideas for small improvements to enhance the "immersion" - like the need to having EC available to make the lights work (right now they just lights up no matter you have EC or now). Cheers!

It's a long story, but in a nutshell: TL;DR: Install them both and let us work out the mess. There's a protocol on Recall to deactivate fixes when they are superseded, and it's used by KSPCF.

I'm planning to do what it's already being done with attachment nodes: scale it to the nearest size. Obviously, subject to further considerations. No, you concluded wrongly. By analysing your KSP.log, I found that TweakScale patched the part only once. The problem is that you have a deprecated add'on installed, remove GameData/TweakScaleMakingHistoryConfigs and things will be fine: [LOG 00:54:57.329] Applying update TweakscaleMakingHistoryConfigs/Coupling/@PART[Decoupler_1p5] to SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5.cfg/PART[Decoupler_1p5] Yes, it's "possible". But this was what cause so much trouble in 2019 on. my first year of tenure on TweakScale, so I won't do it. (and that's final). Double patching is terrible, it leads to confusions both on TweakScale as with KSP itself, as some PartModules doesn't cope too well with reindexings on the this.part.Modules, what can screw you whatever you use the affected parts or not. I had to deactivate features from TweakScale due this. So, in a nutshell: had I been allowing it, you would be using deprecated and unreliable patching with patches that are missing new attributes being added to parts since KSP 1.7 or 1.6 - not to mention possible misbehaviours on 3rd parties or KSP as explained by the issue I linked above. As a personal note, if you can live without some broken parts, my best suggestion is to remove them from the game instead of risking contaminating your gaming with problems that may or may not lead to game corruption by things beyound our control. Lots and lots of people had lost their savegames in the past because of this. note to myself: https://github.com/KSP-CKAN/NetKAN/pull/9544

If the part uses a Stock PartModule, the module is handled by TweakScale using the default ScaleExponents. About the Docking Node, the values are: TWEAKSCALEEXPONENTS { name = ModuleDockingNode undockEjectionForce = 2 acquireForce = 2 acquireTorque = 2 } Data from the Parts are handled by another, specific Exponent. There's something you think should be scaled and it's not? — — POST EDIT — — Yep, there're some missing attributes from the default Exponent for the ModuleDockingNode! There's already an issue for it: https://github.com/net-lisias-ksp/TweakScale/issues/270 And… scaling the nodeType will be a challenge... So, in a nutshell, scaling the Docking Parts are problematic for now on KSP 1.12...

ANNOUNCE Release 4.2.0.1 is available for downloading, with the following changes: Formal adoption of the thing. #HURRAY!! Updating it to use KSPe.Light Automatically patches the lights to be used with B9PartSwitch if available. Allows customise the Lights’s Max Range Use with care, too big values can ruin your visuals! OBS: 4.2.0.0 was withdrawn because, again, I tested the thing on a dirty development rig (intended to type 1.12.5.acp, typed 1.12.5 by muscular memory) and, obviously, it had a bug that the dirty development was masking… This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right Now, SpaceDock (and CKAN users). Right Now. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong.

Aviation Lights /L is the sequel for the venerable Aviation Lights, from @MOARdV. In a Hurry: Current Release: 4.2.1.1 for KSP >= 1.3 (2023-0802) It works from KSP 1.3.1 to KSP 1.12.5! Seriously! IMPORTANT Module Manager is needed for handling the patches. Read this post before updating! Downloads on GitHub (for early adopters and beta testers) on CurseForge . on SpaceDock . Description: There are two types of standard aviation lights: Navigation Lights ("Position Lights") are a safety feature on every plane bigger than an ultra-light. They indicate the orientation of the plane so other aircraft know which direction the aircraft is going. For that purpose, the international standard is a red light on the left wingtip, a green one on the right, and a white nav light on the tail. Example of the correct use in KSP: But, of course, this is KSP. You can just put them on where it looks cool. Warning Lights (both "Strobe" and "Beacon") are flashing lights to enhance visibility in bad weather and to warn air traffic and ground personnel. Beacons are typically mounted on the tip of the vertical tail on smaller planes, or in the middle of the fuselage (top and/or bottom) on larger aircraft. They're red, bright and flashing to indicate that parts of the airplane (engines) are moving or the airplane itself is about to move. Strobes are very bright, white, fast blinking lights which are mounted on the wingtips (next to the red/green navlights) and sometimes on the tail (next to the white navlight) on larger planes. They're so bright that they remain off until the pilot lines up on the runway, so the ground personnel won't be blinded if they stand right next to it. In addition to the standard navigation and warning light colors, there are amber and blue preset options. Localization: Aviation Lights supports localization. Currently available: en-us es-es fr-fr ja pt-br zh-cn Legacy: Found a nice craft file on KerbalX but it was made for KSP 1.3 and the old lights are not available anymore? We have you covered, Veteran! Aviation Lights /L has full support for legacy crafts made on the Old Days! The legacy aviation lights do not appear in the editor by default on KSP >= 1.4, but are available when running on KSP 1.3. If you do not wish to include the old parts in your installation, and you do not have any vessels currently using those lights, feel free to delete the AviationLights/Parts/lights folder - unless you are running KSP 1.3.x . On the other hand, if you want to use them even on modern KSPs, create a directory on GameData called AviationLights_LEGACY (or create a config file with a dummy MM patch defining the symbol AviationLights_LEGACY in a :FOR). B9 Part Switcher: Suport for B9 Part Switcher is now activated by default if `ModuleB9PartSwitch` is found. Support: I need help in order to proper help you. Open the spoiler for instructions about how to get support:

Thank you sir! I will reach you in private message for the details! Cheers! — — POST EDIT — — For people willing to use the new Fork. It's essentially the same release, but allowing configuring the Max Value for the Range in a Config File, and working from KSP 1.3.0 to 1.12.5 (what means the legacy parts are kept alive, allowing downloading crafts from KerbalX into 1.12.5!)

If no one better steps in, I would like to adopt it. It's one of my favorite add'ons for years!

This is off: [LOG 12:01:06.904] Applying update TweakScale/patches/Squad/Cargo/@PART[cargoContainer]:NEEDS[Squad,TweakScale] to Squad/Parts/Cargo/CargoContainers/cargoContainer.cfg/PART[cargoContainer] [LOG 12:01:07.097] Applying update TweakScale/patches/SquadExpansion/Serenity/Cargo/@PART[cargoContainer] to Squad/Parts/Cargo/CargoContainers/cargoContainer.cfg/PART[cargoContainer] I think you unpacked a new version of TweakScale on a very older version (see the ":NEEDS" thingy on Squad, but not on SquadExpansion?). If memory servers me right, the cargoContainer was moved from a DLC into the main game, and this double confirms what I said. Completely delete the TweakScale directory contents and then unpack the version you want to use.

Then you need to reach Toolbar Controller maintainer for help! I don't know how Toolbar Controller works nowadays. Post a message on the thread I linked above!

Ah, this! You need to install Toolbar Controller! Something that TweakScale needed to access tried to use this one, but since it wasn't there, it failed - and then TweakScale failed too!

Hi! There's something broken in your KSP - there's a bug inside KSP on a thingy called "Assembly Loader/Resolver", and when something triggers that bug, a lot of other things (including, but not limited to TweakScale) borks because they can't load their DLLs or do things called "Reflection". The only way to solve your problem is to locate who is triggering that bug inside KSP. Send me your KSP.log using dropbox or something, and I will check it for the culprit. On TweakScale's thread (here, usually the best place to ask for help related to TweakScale) you will find instructions for locating the KSP.log, reproduced here for convenience: Ping @cel

by overwritting the mass exponent from the Part module like this: @PART[FancyPantsPart]:AFTER[TweakScale] { @MODULE[TweakScale] { %TWEAKSCALEEXPONENTS[Part] { %mass = 3.25 } } } This part will scale its mass, from now on, using a 3.25 exponent (yep, you can use fractions on the exponents!). The :AFTER will save you from some race conditions - use TweakScale is the part is being patched by TweakScale, otherwise use the name of the Add'On that had patched the part - if this patch "runs" before the target add'on is able to patch the file with their own patches, it will fail. The first "@" will prevent the patch if the part wasn't patched yet (important to prevent double patching if things goes out of hand). The "%" will add or replace the respective data into the TweakScale's section - it's almost impossible to have TweakScale patched on a part without having also a TWEAKSCALEEXPONENT for Part, and this one having the mass exponent. But, better safer than sorry. Avoid exponents less than 1.0 - it's almost sure it will not do what you expect.

Neither did I!!! I had to quit KSP to do something else, and when I reloaded it later I was lazy and reload the craft instead of doing everything from scratch!! Well, right now, this is not happening to me, so perhaps the #282 ended up fixing something else by collateral effect. I just published 2.4.6.21 (github and curseforge are up to date right now as I already had people downloading 2.4.6.20 from them, on SpaceDock I will delay a few hours just in case…). But since B9PS is not Stock, if the problem persists it will be tackled down on TweakScale Companion for Fuel Switches from now on. It will be tackled down, rest assured. It only won't be by TweakScale. There's a chance that this would be KSP-Recall "restoring" that last known values for the Resources due KSP being known to squash the current one from values from prefab. Since KSP (from 1.11.x) is failing somehow to handle Symmetries from TweakScale, then these poor guys ended up not receiving some PartMessages (I confirmed that they are being sent by TweakScale), and since KSP-Recall rely on PartMessages from TweakScale (or any other interested party) to know when it should refresh its internal structures from new data, what you are describing can be a possible consequence. Anyway, since I was testing B9PS anyway, I checked if removing some PartModules from Recall when the part uses B9PS would cause any problem, and I realised that not. I'm publishing a new KSP-Recall release in the next hour reflecting this. I think this may solve this punctual problem from yours. There are no exceptions on TweakScale code, other than specialised handling of "Classic Parts" and "Parts with ModulePartVariant". And since B9PS get rid of every ModulePartVariant on the part, TS is surely using the Classic Engine for parts with B9PS - that are known to work fine together for years. So I'm reasonably sure that by fixing the problem for on part, we will fix it for all the other - unless KSP's Editor would be screwing something else besides Resources from 1.11.x and newer. Curiously, I the latest B9PS on KSP 1.10.1 , and it got screwed on it! I just fail to understand (or perhaps I don't?) why "new" TweakScale fails on 1.11.x and 1.12.x but works fine on everything else, why "older" TweskScale is working fine on everything, and why B9PS is working fine only from KSP 1.11.x . I think I will need to check B9PS historical commits since 1.10.1 to see what had changed in order to get some idea about what in hell is happening here...

Ah, this makes things easier. Tell forge to uninstall 2.4.6.20 and install 2.4.6.19 back. I'm working on .21 right now, it should be available to downloading in a couple hours. And thanks for the heads up, I need to update the Support instructions for Epic Store!

NOTAM Oh, yeah. I was caught with my pants down again. Further jokes about is not allowed by Forum Rules 2.2.c, d & g. This last 2.4.6.20 release marvellously blew up on my… face. That's the reasons: I forgot a development library as a dependency, allowing it to leak into mainstream I did that before on another add'on, and forgot to echo the fix on TS KSP 1.12.5 was recently released, and I didn't created yet the Acceptance Test test rig for it, so I ended making the smoke tests on a dirty development environment. Not one of my brightest moments. But it ended being for the best. A major bork on scaling Resources was detected by our fellow Kerbonaut @AccidentalDisassembly It was determined that TweakScale is not the cause, as the problem started to happen only on KSP 1.11.x (just have 1.11.2 installed at this point). But yet, it's something that needs to be tackled down somehow. Another bug on the Auto Scale (and Chain) were detected in the process (and this one is fixed now). Now, let's talk about what's bitting our SASes right now. On KSP 1.11.x something changed (again) on Editor that screwed Part Switches and TweakScale by messing up the PartModule's life cycle when the Part being configured have Symmetries Counter Parts. Apparently a PartMessage is not being issued somehow (or issued too soon or too late), and so a chain of events that was happening until 1.10.1 stopped happening (or do it on an useless timeframe) from 1.11.x and forward. Damn, this is pretty annoying. By some reason, that crappy code I got rid from TweakScale was masking this problem. I don't have the slightest idea what, where and why. I prefer not to think about too much, I'm still burnt by that AirplanePlus MonkeyPatching problem. In a way or another, I had nailed down the problem to KSP 1.11.x . The "new" TweakScale code works perfectly from KSP 1.3.1 to KSP 1.10.1. Another evidence that the root problem is Editor is that by saving the craft (or launching it), the problems detected on the Resources are "magically" fixed. Magically on quotes, because this is evidence that without Editor screwing it, TweakScale is working fine - otherwise things would be still screwed on Flight Scene. So, TL;DR: TweakScale is innocent, but it's up to me to cope with the mess nevertheless B9PS is also innocent, as it depends of TweakScale for knowing when to do its things, On the bright side, I discovered that at AttachedOnEditor and Attached Recall stunts are not needed when B9PS is installed on the part. Next version of Recall will withdraw itself from parts using it. Saving and loading the craft solves the problem. Again, this last info states clearly where the problem really is. I'm unsure if I will be able to fix this one, but since the impact is negligible - crafts are fine when launched, where things really matter - I will call it a day and release 2.4.6.21 with I have at hands now.