Lisias

Whoops. I was writing a helper for it, but then I realised I would not be needed for the beta releases and forgot about it. Fixed. The APUs I completely missed that. They are on the right place because I'm mimicking the target add'on internal structure to easy maintenance, and these parts are defined inside a Utility directory. But the behaviour will be added on the next build. Thx!!!

No. @OnlyLightMatters authored the ReStock+ ones, and I'm publishing it under the Companion brand. Yep. Since Airplane Plus does not introduce new modules (as KIS, KAS, Firespitter, etc), it's unlikely that a TweakScale patch would do any harm. Rogue patching is the concern here. Classic Add'Ons , obviously, are way more prone to this problem. Lots of personal customisations published in the past, tons of potential toe stomping fest's on the wild! Proceed with caution, I would not risk any ongoing savegame yet. I didn't really tested the thing yet, essentially there're no warnings or errors on MM log but I may had did a mistake on the patches myself and then it would inject problems on the savegame (KSP now shoves new prefab data into living crafts, so a mistake of mine on a patch would mangle everything when the savegame is loaded).

2.4.4.x is work in progress, it lives only on my machine for now. It will be released, ideally, together KSP 1.10 in a few weeks. The beta 2.5.0.x (a development road map where everything is tried first) is working fine with every Companion, but since that thingy is beta, it's risky to use it on long term gaming. BUT, some Companions may work on the current 2.4.3.14, what's happening is that I don't have the available time to give support for it on 2.4.3.x series (as these ones as EoL and I'm running to finish 2.4.4.0 in time for KSP 1.10), and, frankly, it's the only reason it's still beta. Try it on discardable KSP savegames just in case to wet your feet on it first - if nothing weird happens now, nothing weird will happen on 2.4.4 for sure. I'm just worried a bit about deprecated and unmaintained patches on the wild that could silently break the Companion parches (and vice-versa), a nasty situation where savegames get compromised. That's the reason I need to issue 2.4.4.x, that will provide support for the Companions to detect these incompatible patches and issue a Houston when this happens.

I took some time to understand, at first glance the thing was working - but then I noticed what you mean - an additional chance of recovery ends up being added when you remove and replace a scaled part. I added a new step on your How to Reproduce: if I scale the part back to default, the problem vanishes. So, yeah - TweakScale is the trigger for sure. If Stage Recovery is borking or being borked on the issue, it's still to be determined. I need to study that code first. It's fortunate you raised the issue here, I just found that Stage Recovery had induced some weird issues on a personal fork of an add'on of mine, and I need to diagnose this (unrelated) issue too. I will study the problem as time allows and I will come back to you opportunely. Got it. And I found the problem, it's again our old friend : [LOG 01:19:39.329] Config(@PART[S2Structural]) TweakScale/GameData/TMasterson5TweakscalePatches/AirplanesPlusTweakscale/tweakscaleConfigPatch/@PART[S2Structural There're two problems here: The Add'On is installed wrongly. TMasterson5 is not being recognised by Module Manager as one would expect, so :NEEDS[TMasterson5TweakscalePatches], :AFTER[TMasterson5TweakscalePatches] and :BEFORE[TMasterson5TweakscalePatches] would not work and any attempt of a fix would fail. TMasterson5 itself is terribly outdated and, worst, it's a Non Derivative add'on. I can't fork and fix it (at least legally, but please remember Forum rules on the matter) and he's not around for some time already, so there's no one that can fix the problem. TL;DR: I have my hands tied on the matter, there's nothing I can do to fix it under Forum rules (not to mention Laws) and so I will not. BUT I can at least provide you with some work arounds. The ideal solution would be get rid of TMasteron5, as these set of patches are outdated, unmaintained and unmaintainable. All Tweak may be a better solution for you, as it aims to do something equivalent and it's actively maintained. It's not flawless, now and them something doesn't work as expected, like any other Add'On (TweakScale included, see above) but the maintainer is available and he is fixing the problems as they happens. BUT... Your ongoing savegames will probably resent the change. So perhaps you should migrate to All Tweak only on new savegames. So we need to cope with your current savegames. I modified that patch above to brute-force a correct patch into the part: // // Adding TweakScale by brute force to workaound a messy patch from TMasterson5's // // I suggest to drop this patch on a file on GameData/__LOCAL/TwealScale/WorkArounds/AirplanePlus-kerbalaviator.cfg // so you can easily remember it to be deleted and avoid breaking new patches as you install new Add'Ons @PART[S2Structural]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = free } } It's the same thing as I said before, copy and paste that "code" on notepad and save the file on the place I suggested (can be anywhere, but that place is better for it, trust me). Just remember to save it using a ".cfg" extension, otherwise KSP will not load it. Let me know if you need further help. Cheers!

Announce Pre Release 0.0.1.0 for TweakScale Companion for Airplane Plus BETA are on the wild. Download on the OP or in https://github.com/net-lisias-ksp/TweakScaleCompanion_APlus/releases . TweakScale 2.4.4.0 will be the minimum supported release, and it's working fine on the TweakScale 2.5.0.x Beta, but you can try on TweakScale 2.4.3 - no guarantees, however: i didn't tested it on 2.4.3. And use S.A.V.E. just in case. This thingy is Beta! Known Issues: Users of All Tweak and TMasterson5's TweakScale patches will probably have serious problems by installing this thing. Please backup everything first before installing, so up can rollback if needed. Ping @kerbalaviator, @AccidentalDisassembly, @Commodoregamer118, @xD-FireStriker, @Acid_Burn9, @Vectorv12, @Mathrilord, @TranceaddicT! I think you may like this (but, as I said above, proceed with caution , try it on backups!)

Hi, @blackheart612. I'm writing TweakScale support for AirplanePlus, and so ended up reviewing some info on the A+ parts and realised there're two S2 parts with the bulkheadProfile set to size1. Not big deal, this would affect only the part filtering on the Parts Palette, but since some automated tools are seeing the limelight recently, keeping the parts accurate will be of great value: it will allow us to automate some harsh tasks while maintaining the patches as time goes by! I applied a pull request with the fixes here. Cheers.

Interesting. I swear I wrote something about - but apparently, somewhere else. I will fix this. The Module Manager logs lies on <KSP>/Logs/ModuleManager folder. Zip the whole shebang and sent it do me. Send me also the <KSP>/GameData/ModuleManager.ConfigCache file. I will need them, your KSP.log tells me you have a very spartan instalment, I cloned here easily but didn't found any problems. Open the nodepad, copy and paste that code on it and save the file as GameData/__LOCAL/TwealScale/WorkArounds/AirplanePlus-kerbalaviator.cfg You must remember where you put that file, otherwise you will lose the scaling for that part forever when I fix the problem. The filename must end with .cfg (dot cfg).

ugh, I missed that completely. Well... It's another guess, but this time an educated one: since a pathname for a song was on the stack when the thingy crashed, I think it's a good guess to pinpoint this as a possible trigger for the problem. Remove temporarily SoundtrackEditorForked from your instalment and see what happens. If the problem vanishes, put it back and see if it happens again. Then advise here.

Waked with this music on my head today. Yes, for sure. I used to hear it on my car when autoradios with cd players were a thing. The OST from Mega-CD's Batman Returns was another one - very good too.

AirplanePlus is not (yet) supported by an "official" TweakScale patch, so its something else stomping your feet for sure. I need the full KSP.log and ModuleManager's logs in order to help you - I will check every single patch that touched this part and will get into the rogue patch in a minute (as long I have the files I'm asking you). See the bottom of the first post (Support), open the Spoiler box and read the instructions about where to find that files! In the mean time, you can use this patch to remove TweakScale from that part and be able to play. But please give me that files first, fixing the problem for good is the best option for everybody: // // Removing TweakScale from a messed up part to allow safe gaming (besides not being able to scale that part) // // I suggest to drop this patch on a file on GameData/__LOCAL/TwealScale/WorkArounds/AirplanePlus-kerbalaviator.cfg // so you can easily remember it to be deleted when I fix the problem @PART[S2Structural]:FINAL { -MODULE[TweakScale], * { } } On a side note, it's the third time this week someone talk about AirplanePlus and TweakScale, so this hinted me that it's time for a new Companion. I will work on it by night (but this will make your games using All Tweak useless, so this may be not for you).

There'n an additional Crash Report on "C:/Users/chris/AppData/Local/Temp/Squad/Kerbal Space Program/Crashes", if it's text it would help us to pinpoint the reason and perhaps file a report on Unity's bug track. Crash!!! DynamicHeapAllocator out of memory - Could not get memory for large allocation 14530461! A crash has been intercepted by the crash handler. For call stack and other details, see the latest crash report generated in: * C:/Users/chris/AppData/Local/Temp/Squad/Kerbal Space Program/Crashes Could not allocate memory: System out of memory! Trying to allocate: 14530461B with 16 alignment. MemoryLabel: WebRequest Allocation happened at: Line:77 in C:\buildslave\unity\build\Runtime/Utilities/dynamic_array.h I think this should be a Unity glitch, failing to cope with Windows intrinsics (Unity had born on MacOS a long time ago, a BSD Unix derivative). On the crash report, I found this: [ ALLOC_DEFAULT ] used: 40492695519B | peak: 0B | reserved: 40971792871B [ ALLOC_TEMP_JOB_1_FRAME ] used: 0B | peak: 0B | reserved: 1048576B [ ALLOC_TEMP_JOB_2_FRAMES ] used: 0B | peak: 0B | reserved: 1048576B [ ALLOC_TEMP_JOB_4_FRAMES ] used: 0B | peak: 0B | reserved: 52428800B [ ALLOC_TEMP_JOB_ASYNC ] used: 0B | peak: 0B | reserved: 1048576B [ ALLOC_GFX ] used: 3016644672B | peak: 0B | reserved: 3110942176B [ ALLOC_CACHEOBJECTS ] used: 816440828B | peak: 0B | reserved: 1100832548B [ ALLOC_TYPETREE ] used: 2820120B | peak: 0B | reserved: 5242880B [ ALLOC_TEMP_THREAD ] used: 0B | peak: 0B | reserved: 3047424B The process had died due an attempt to allocate about 14MB of memory, besides still having 456MB available on the current allocated memory pool. However, I'm assuming that WebRequest calls use the ALLOC_DEFAULT pool. It's a terribly wild guess, but the ALLOC_TEMP_THREAD pool has only 3Mb of size. Since the dying call is a WebRequest, I'm guessing this call would use the temporary's thread pool and the request wants about 5 times the available memory for this pool. But, and again, I'm wild guessing. Interesting enough, I'm seeing this a lot on reports about the late Windows Phone (that had an incredibly tight memory constrains, obviously) and one specifically about a crash on WebRequest about downloading a 1GB file on Oculus <something> using Client.GetObjectAsync(). Since the only thing that changed was an update on Spectra, I downloaded it to check it - but I think Spectra was just the Screaming Victim on this, there's no code on it - or perhaps, the straw that broke the camel's back. -- -- POST EDIT -- -- GetObjectAsync appears to be an AWS's library call... I also found a link saying something similar had happened once with someone downloading a flawed JSON object somewhere...

I think this will be of interest here. Ping @Daniel Prates ! There's a new TweakScale Companion for Firespitter, adding long due support for some parts currently banned from TweakScale (as the floats from SXT). It's still on Alpha status, so please use it with caution (and use S.A.V.E. just in case). Please report any problems (and problems you will find) on the TweakScale Companion Program thread. Also read the Known Issues to avoid reporting things that I am already working on.

Announce Pre Release 0.0.1.0 for TweakScale Companion for Firespitter ALPHA are on the wild. Download on the OP or in https://github.com/net-lisias-ksp/TweakScaleCompanion_FS/releases . This Companion fixes the long due problem with parts with FSBuoyancy. #hurray This only works with the latest TweakScale 2.5.0.x Beta. TweakScale 2.4.4.0 will handle this Companion correctly. And use S.A.V.E. just in case. This thingy is still Alpha! Known Issues: The original PAW Control giving the raw value for buoyancy had to be deactivated, and a new one using Percentages was added on its place. The raw values (current and max) are displayed below the new Control. When you drop a new part into the craft, the code that initialises the Module is failing and you ended up with a huge negative value on the current Raw Buoyancy. Just manually set it and from this point things appears to work This will be fixed in the next release - I run out of time for this Companion and decided to release it as is in Alpha status so people can test it.

Nice catch - I had some problems when some parts are scaled when they are root - but completely forgot about. https://github.com/net-lisias-ksp/TweakScale/issues/86 Recall will not help, because it doesn't handle attachments, only Resources (at least, by now - I may implement an Attachment Pool on it due this #86 problem, thanks for the heads up!)

It's a pretty wild guess, but had you tried KSP-Recall? On KSP 1.9.x , you need it to preserve the Resources (Fuel, etc) from being overwritten by the Editor. If you don't have it installed and are on KSP 1.9, you should install it. At least one of the fix works for every Add'On out of the box (TweakScale is only one of the Add'Ons KSP Recall tries to help). Parts with variants also triggers some info overwriting fest, but this one Recall cannot work around because it is logic dependent - to tell you the true, is not a big deal, the Add'On just have to reapply itself every time ir receives a GameEvents.onEditorVariantApplied (see this post for a full disclosure). I expect this to play some havoc on Add'Ons that customise stock parts, as it did on TweakScale - suddenly, a lot of info (attachment nodes, to mention what broke TweakScale) is not there anymore or are bluntly reset and Null Reference Exceptions start to fly on the KSP.log due that.

Yep. People is used to ask for help here, not only on TweakScale but sometimes to not directly related issues. And they get help most of the time. I have this behaviour when Add'Ons throws exceptions on the Start, Load or Copy KSP handlers. Yes. To publish the KSP.log (and the Player.log) so people can help you diagnosing the problem.

"In Space, no one can hear you farting..." Kerman, Jebediah.

Just watched the most recent release of Within Temptation and, boy... Not sure if it would be allowed here! So I decided to publish this one.

4 Years later, and another one bites the dust. I'm facing this exact problem - but I had found that what's happening is the prefab data being shoved back regularly on the ui_control. By changing the value using Reflection, I managed to get the new Min and Max values working for some time - but as soon as you change scenario, the values are reset again and, curiously, they become imune to the new changes from the code (i.e., trying to restore the data using OnStart, OnCopy or even Update is useless). Curiously, this appears to do not affect the Resources controls - i.e., I can mangle the Min and Max values for a Resource control.

Just installing Add'Ons is not enough. The Add'Ons need to support each other. I don't know about BDArmory, but Airplane Plus doesn't have support for TweakScale and until the moment nobody had wrote such support. SXT works with TweakScale because someone wrote support for it. -- POST - EDIT -- @theKSPnoob I wrote APP support, and it's currently in Beta (i.e., it's being testing and can have bugs, besides I think there's none left and there are people are already using it). You can download it from here.

Well, just to mark the support, this was answered on the GitHub issue #13. (so I don't try to answer it again in a few days ).

I'm not pushing it here. And pushing it on elsewhere is not a problem at all. Language barrier. I was not counter-attacking neither. But I stand by what I wrote nevertheless - there's a place for each approach, but people should have the choice to opt for what approach suits them better, instead of being locked up on the whims of someone that don't care about his/her needs. So, instead of continuing fix things again and again everywhere, I choose to pursuit the simpler path: fix what's really broken, instead of fixing working things to cope to what's broken. It's how I keep some of my Add'Ons working fine on multiple KSPs, from 1.4.1 to 1.9.1 - and some few of them even working on 1.3.1: you will see some of my Add'Ons (official or not) working flawless from 1.2.2 to the latest KSP 1.x with the same binary, mark my words. And it's with this spirit that I choose not to push a change on the @girka2k's Official fork that would just deactivate a pretty useful feature (auto reloading parts), or shove some code that would introduce risk of creating maintenance headaches - Module Manager already have the feature, and it was open and being in use since 2014, so why changing it for worse in a way or another? I choose the simpler path. It's working. It's legally available to those who prefer the simple way. Our concepts of "Right Things" are fundamentally non convergent, as it appears... I'm already doing the Right Thing™ on all my works: I'm following Forum policies when such works are published here, and I'm following the host's policies when they are published somewhere else (not to mention the proper legal licensing terms). Every single fork states clearly it's a fork of mine, and it pinpoints the Upstream on the References. And this should be more than enough. But... It's always possible to make things better. And yes, it's working on KSP 1.4.0 to 1.9.1, have all the fixes (and some minor ones of mine too) and it is working with the @girka2k's fork right now on the spot without the need of changing the WeldingTool code - and this is the only reason I'm posting this here. I think that this is our last post pertinent to this Thread. Perhaps we should move any further discussion somewhere else?

TL;DR: Check: change, the last change before, oldest mention of the file before a internal refactoring, and the first time MMPatchLoader was extended with LoadingSystem. This first LoadingSystem commit was made in 2014, so we have 5 years of a public class being served this way!! Source. But the maintainer dismissed the report, so there's nothing it can be done on the official fork. So I decided to solve it on mine. It's good that someone would step ahead and fix all the Add'Ons on the wild to cope with these gratuitous changes that happens now and then - but I found easier to just fork a few things and fix them, and then everything else would just keep working.

The official MM doesn't works on 1.3.1. Mine does. Being the reason my forks are not advertised on Forum neither goes to CKAN or Spacedock. Open Source is not about being forced to use broken things because one developer decided you don't matter.

And that's the reason I decided to fork ModuleManager instead, and avoiding having to change every single other Add'On. My forks are working from 1.4 to 1.9 (some of them 1.3.1 too)