Lisias

Hi! Got it: [LOG 13:36:00.423] [TweakScale] INFO: WriteDryCost Concluded : 2571 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 16 Show Stoppers found; 0 Sanity Check failed; 779 unscalable parts. 16 FATALities, all from NFS.. Humm.. I think I now what happened... [LOG 13:17:46.227] Applying update TweakScale/patches/NF/NFS_TweakScale/@PART[solarpanel-blanket-1] to NearFutureSolar/Parts/Deprecated/solarpanel-blanket/solarpanel-blanket-1.cfg/PART[solarpanel-blanket-1] ... [LOG 13:18:06.053] Applying update TweakScale/Deprecating/patches/NF/NFS_TweakScale/@PART[solarpanel-blanket-1]:FOR[TweakScale] to NearFutureSolar/Parts/Deprecated/solarpanel-blanket/solarpanel-blanket-1.cfg/PART[solarpanel-blanket-1] You forgot to completely delete older TweakScale before applying the new one. And since the second patching was using :FOR , I'm presuming you did give TweakScale Beta a try. My best advice when installing TweakScale new versions is to always delete all the previous contents before applying the new version. TweakScale does not (and never will) store any significative personal settings on GameData, you can (and should) delete everything on GameData/TweakScale when updating. Corollary: never do it yourself neither: if you want to add your own personal patches on TweakScale, the best place to do it is on GameData/__LOCAL/TweakScale/your-patches/ so you don't risk loosing them on a update (it can be any directory you like, but using __LOCAL make it a pattern and will help a lot on diagnosing problems later, believe me!), not to mention making it easy to do backups as all your customisations will be on the same place! Cheers!

ANNOUNCE Release 2.4.3.14 is available for downloading. This new version have the following changes: Issues Fixed: - #110 Revert to Vehicle Assembly and Loading Craft are mangling the part attachments. See OP for the links. Highlights KSP 1.9.x Support VAB/SPH Editor KSP 1.9.x Editor introduced a glitch that was rendering parts with ModulePartVariant displaced on loading. Crafts being instantiated on LaunchPad/Runway (as also living craft on the Universe) are not affected. This is what I know until this moment: KSP is shoving back prefab data into living crafts on savegames (and on loading crafts on the Editor) since 1.6 or 1.7, and recently started to obliterate the resources customisations made by Modules. You already know that, KSP Recall was born due it. The novelty is that, somehow, surface attachments are, now, also affected - but not exactly as the Resources, and this is what caught me with my pants down (and what made me bork the 2.4.3.13 release, already withdrawn): Parts with variants are getting surface attachments mangled on Editor, but parts without variants are not! Attachments points apparently are being mangled too, but I did't did a full testing on the matter - proceed with caution Attachment points with parts are also reset, but are preserved on classic parts. Boy, what a mess... This, probably, could be also solved by using the GameEvents.onEditorVariantApplied, but since KSP still mangles with TweakScale business in other situations (including on Flight Scene), I would need to split the survivorship logic in two different places now - so I opted to keep the current Event handling for while until I fully refactor (and validade) the code. Surviving different KSP Version's idiosyncrasies are taxing badly the codetree And I'm firm on my commitment to keep TweakScale (core) compatible with every KSP still em use - expect TweakScale 2.5 to be useable down to KSP 1.2 (KSPe already does it, by the way) - so I will be able to backport every fix and enhancements to people that choose to stay playing older KSP versions. The after math is that I'm still using Unity's Update callback to handle the first Scale Back event, needed to survive KSP manglings. For some time I considered using KSP Recall to handle this situation, but since Scaling is the TweakScale's Core Business, and I don't intend to tie KSP Recall to TweakScale in any way (it must be a generic solution for everyone, not just for me), I rolled back any change on it. Please also note that there's a lot of glitches on KSP 1.9 Editor not related to TweakScale (or any other Add'On). Drain Valve The FTE-1 Drain Valve is being scaled, however not properly. Mass and size scales fine, but the drain rate is not. See Issue #102 for details. Resources KSP 1.9.x is known to replace any Resource customisation made by custom modules with default definitions from the prefab. This affects many Add'Ons, being TweakScale only one of them. So a new Add'On called KSP Recall was created to specifically handle KSP issues that would affect everybody. Users of KSP 1.9.0 and 1.9.1 are urged to install KSP Recall. Future KSP releases may or may not fix the glitches KSP Recallaims to workaround - but until there, you need KSP Recall to use TweakScale on KSP 1.9.x . Misc Keep an eye on the Known Issues file. — — — — — 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 the Release to easily monitor the deployment and cope with eventual mishaps.

This is already happening since Kraken knows when - my testing had demonstrated this problem is happening since KSP 1.3, I think (didn't tested beyond that), including with TweakScale versions of that time. Something is missing on some scaler apparently, and this is scheduled to be fixed (or at least researched) when time allows (right now, I need to tackle down KSP 1.9.1 before July, when a probable new Version will be released with a new DLC). Yep, I had this behaviour documented here.

Publishing BETA versions on the GitHub's Release had bitten me in the SAS painfully in the past - even by marking the thing as Pre Release and warning about being not stable, some people installed it nevertheless on production KSP instalments and, boy... (at that time, the :FOR thingy was playing havoc on most third parties' patches, the stunt did cost me some nights giving support.. ) So I came to this stunt on Issue #42, where I must direct people to there when appropriated - did you noted that the link is buried on the bottom of a long and scaring text?

Are you sure? I just downloaded the ZIP from the #42 (using this link to be more specific). And it's everything there...

Hi. It's not exactly the same problem solved by KSP-Recall, but it have the same root cause: a bug on handling Cloning (OnCopy KSP callback). However, KSP Recall need to be used by third parties in order to work. Just installing will not solve anything without Add'Ons calling it when they want to preserve the current Resources state (it's what TweakScale is doing, by the way). And since the amount of a Resource on the part is handled usually by a Stock Module (that knows squat about KSP Recall), the sad true is that KSP Recall will be never notified about you changing the amount of the resource on the part, and so it will behave similarly - it will restore back the Resources configuration it knows about (the last updated received from someone), and not the source part's one. How bad this is hurting you? I just had an idea that may help (essentially, mimicking a stunt already being done on TweakScale). With a bit of luck, I can try a solution for this!

News from the Front The infamous Revert to Vehicle Assembly and Loading Craft are mangling the part attachments, mentioned here, was transferred to be handled on TweakScale, as it revealed to be something to be handled by TweakScale's scaling routines - and trying to solve it here would hurt the KSP Recall main purpose: being a generic solution to be used by third parties to solve similar issues from KSP 1.9 (and perhaps other versions). In time, It took me a while, but I think I nailed it now. Check this TweakScale post - I may had solved this issue, as apparently this was TweakScale related.

NOTAM TweakScale 2.5.0.12 Beta is available for testing on Issue #42. I think I finally nailed the problem from the KSP 1.9's Editor (as well realising yet more bugs on it... #sigh). Please note that you will need to install the latest KSP-Recall in order to use it on KSP 1.9. It's also highly advised to use S.A.V.E. - but I would not use this on your "production" savegames yet. TweakScale 2.5 is getting stable, but there's a lot of changes that weren't proved on the field yet (and I need the 2.4.4 series to pave the way for the migration). Again: This can break your KSP, ruin your Windows, kill your pet, offend your mom and poison your kids. Don't use it on "production" savegames, only on disposable ones! What I know to this moment follows: KSP is shoving back prefab data into living crafts on savegames (and on loading crafts on the Editor) since 1.6 or 1.7, and recently started to obliterate the resources customisations made by Modules. You already know that, KSP Recall was born due it. The novelty is that, somehow, surface attachments are, now, also affected - but not exactly as the Resources, and this is what caught me with my pants down (and what made me bork the 2.4.3.13 release, already withdrawn): Parts with variants are getting surface attachments mangled on Editor, but parts without variants are not! Attachments points apparently are being mangled too, but I did't did a full testing on the matter - proceed with caution Attachment points with parts are also reset, but are preserved on classic parts. Boy, what a mess... So I borked because I naively believed that the "one size would fits all", and didn't customised the scaling process to handle different rescaling measures (one for parts with variantes, other for parts without). TweakScale needed to be heavily refactored in order to cope with this new situation. So the need to proper testing this thing first, before shoving the stunt into the Mainstream! This, probably, could be also solved by using the GameEvents.onEditorVariantApplied, but since KSP still mangles with TweakScale business in other situations (including on Flight Scene), I would need to split the survivorship logic in two different places now - so I opted to keep the current Event handling for while until I fully refactor (and validade) the code. Surviving different KSP Version's idiosyncrasies are taxing badly the codetree And I'm firm on my commitment to keep TweakScale (core) compatible with every KSP still em use - expect TweakScale 2.5 to be useable down to KSP 1.2 (KSPe already does it, by the way) - so I will be able to backport every fix and enhancements to people that choose to stay playing older KSP versions. The after math is that I'm still using Unity's Update callback to handle the "first Scale Back" event, needed to survive KSP manglings. For some time I considered using KSP Recall to handle this situation, but since Scaling is the TweakScale's Core Business, and I don't intend to tie KSP Recall to TweakScale in any way (it must be a generic solution for everyone, not just for me), I rolled back any change on it. Please let me know any side effect cause by this. Please also note that there's a lot of glitches on KSP 1.9 Editor not related to TweakScale (or any other Add'On).

ANNOUNCE Release 2.4.3.13 is available for downloading. This new version have the following changes: Closes issue: #110 Revert to Vehicle Assembly and Loading Craft are mangling the part attachments. YES, the parts with variants are not being displaced anymore when loading the Craft into Editor. I decided to give the lingering 2.4.3.x series yet a new minor release due the importance of this fix (the next 2.4.4.0 is not ready for production yet...). Users of KSP 1.9.x MUST install the latest KSP-Recall. Downloads on OP. This release were made in a hurry, so I will postpone CurseForge and CKAN until tomorrow night - there's also a chance I had borked due fatigue, this last weekend wasn't a breeze. Scale Safe! POST EDIT. This released was withdrawn due new problems detected - now I have parts attached into attach points being displaced too. https://github.com/net-lisias-ksp/TweakScale/issues/110

Sorry to hear that. IMHO CKAN needs, urgently, a rollback mechanism.

Announce We are now in Release status! It appears that this stunt is working fine, after all! KSP Recall 0.0.3.0 is available for the brave Kerbonauts willing to risk their SAS with these stunts. Exercise prudence - this thing is still not completely tested with Fuel Switches. Use S.A.V.E. just in case. Good Luck! This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge, by Friday night SpaceDock (and CKAN users), by Saturday night. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Well, a new case of Double Patching. Let's crack this nut: [LOG 22:25:26.788] [TweakScale] INFO: WriteDryCost Concluded : 4053 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 69 Sanity Check failed; 1908 unscalable parts. Well, no FATALities. That 69 Sanity Checks failing are already known issues being handled by withdrawing TweakScale from them - nothing can be done at the moment until I implement whatever that parts need to be implemented. It's an annoyance, I agree - you can't scale that parts. However, there's no trace of Double Patching (that ones are FATALities, it would be listed). However... I got a huge amount of Exceptions on your log, some of them borking TweakScale! [LOG 22:30:40.970] [TweakScale] ERROR: Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object There's also a huge loot of missing textures, something is pretty wrong on your instalment! If you use ReStock, you will probably need help from them in order to create WhiteLists for the textures these add'ons are trying to use and are not finding them. Everything on the spoiler is unrelated to TwakScale. You need to get help from the Add'On maintainers, I can't help: Well, I'm sorry but this is too much. I can't help from here, too many problems (none of them related to TweakScale - I don't know where to start the diagnosis). There's no other way out but to remove all the add'ons and bringing the back in chunks, checking what ones are the ones triggering this formidable sequence of Exceptions on your KSP. Sorry.

I need the FULL KSP.log in order to diagnose your problem. Please publish your full KSP.log on DropBox or something and link it here so I can help. I will probably need also ModuleManager.ConfigCache and will not hurt to send me your Logs/ModuleManager content. See this post to see how to get them.

Update to the latest TweakScale too (if you didn't did yet). Please remember to completely delete the older version before update. Keep an eye on the TweakScale Companion thread for news on new and improved support for third parties! Welcome!

I will need the Full KSP.log for diagnosing this. In time, the TweakScaleCompanion_NFS is no more. By Real Life™ pressures, I decided to merge all NF support into one single Companion, TweakScale Companion for NF. Please completely remove the old one before installing.

Well.. After some weeks away from here, I'm back. I was reading this week about some preliminary designs for the Space Shuttle, and boy.... What wonderful source for ideas. So I came to this, something 100% reusable launching from the runway (with help) and able to ferry 36 Kerbals (4 crew, 32 PAX) and 120 tons of cargo into LKO. And, obviously, the unavoidable ending for this mission: The thing is not working exactly as it should (the landing is just the pinnacle of the mishaps! ). You can get the full story (and moar pictures, with better resolution) here: http://ksp.lisias.net/screenshots/2020/05/15-Orbiter-One-Dev/

Not exactly... In order to reach 0.625, one need to be able to reach first 1.875, and to do that, you need "Advanced Light Materials" too. You unlock ALM, you get 1.875. You unlock PT, you now get 0.625. You unlock PT and not ALM, you don't get any of them. I would need a small intervention on the current requiredTech code to implement this kind of limitation (ie, you can scale only to the nearest unlocked tech), but other than that, I think it fits both the need and the current implementation. I will reread your posts tomorrow morning, I'm too tired for now to give it proper attention. -- -- -- "Tomorrow Morning" -- -- -- It's not you the "problem", the subject is pretty harsh and I have too few "useful time" on working days to give this a decent thought. I kinda understanding the problems you see, but I think I already have solutions for it - assuming, of course, I correctly understand the problems at first place. I will come back to this later - I have some medicine hunting to do today (supply chain is problematic around here, besides still working). -- -- -- POST "Tomorrow Morning" -- -- -- You have a point. I think it's possible to make things simpler, and yet, do what I was meaning originally - with some little adaptations, hopefully satisfying both sides of this discussion. Thank you for your efforts, you started a chain of events that will make TweakScale way better on this subject. I will post a new proposition soon, so we can double check it.

I will give it another try on the WeekEnd. I don't get it exactly why this system would be more practical than the one I'm proposing, but I really didn't a good try on it yet - it's a bit hard to "enter into the zone" late night, when I'm usually have time to KSP on working days. One thing that I noted is that you are assuming a linear progression on the tech nodes needed. Perhaps this is where my mind is "refusing" to accept, as it's not how I see technology evolving - by experience, multidisciplinarity is way more applicable on generating new technologies than using an "academic approach", i.e., a linear path from where you start to the goal you aim. So, using my FUSELAGE_2_5 example: in order to scale it down to 1.875, I need to develop first a way to obtain "Advanced Light Materials". But only that is not enough to get 0.625 scale, because I would need to develop too "Precise Tooling". With Precise Tooling I could theoretically scale down to 0.625, but if I don't have "Advanced Light Materials", that scale is still unreachable because I don't have "Advanced Materials" yet. The nice part of this proposal is that they are not locked into Fuselage. The Precision Tooling would be useful on Robotics also, and so perhaps the user would prefer to develop it first and "sacrifice" scaling down fuselages for while.

Bad patching. You just can't have two fuel systems on the same part. B9PWS tried to survive the mess by detecting and deactivating itself when MFT is also installed on the part (you can have both fuel systems on the same game, you just can't have both on the same part!), but there's no interface on Scale_redist.dll to probe if the module is active or not - so the only safe measure at the time was to withdraw TS from the part, what by its turn was kinda of throwing a pile of pieces of retangular papers in the turbofan as was the norm at the time to kill the messenger. One could argue that B9PSW should be aware of its deactivation on its the Scale_redist handler , so it could take the ideal measures (being it not trying to scale its resources, or just returning the call after doing nothing), but since the root cause of the mess was, indeed, bad patching, the real solution for the mess is fixing the patches - so I settled up with the Sanity Checks and didn't bothered any module author with bug reports or pull requests. IMHO, this is not something at fault neither on B9PSW, MFT or even TweakScale. It's just something that happens on the field and need to be coped somehow by third parties willing to have them all on the same savegame. The easiest way out was to remove MFT from the parts with B9PSW, but there're people (me included) that prefers MFT for handling Resources. For these guys, a smarter patch removing Resource support from the B9PSW module would be the best approach.

Yeah, I'm getting it. The problem is that we have fundamentally different views about how to handle the TechTree. When a think on TechTree on TweakScale, this is more or less what I see (tech names are fictitious): TWEAKSACEBEHAVIOUR[FUSELAGE_2_5] { defaultScale = 2.5 scaleFactors = 0.1, 0.3, 0.625, 1.875, 2.5, 5, 7.5, 10, 20 techRequired = techAtomicWelding, techUltraFineCasting, techPreciseTooling, techAdvancedLightMaterials, techWhatever, techAdvancedFrames, techHeavyTooling, techHeavyMachinery, techTitaniumWelding } And this would be applied to any fuselage (with resources or not) those defaultScale would be 2.5 - techWathever would be some very basic tech from the current TechTree. This is what I already have on TS (exception made by the possibility of rigging the system scaling to the nearest value close to a forbidden scale). What you are proposing is: TWEAKSACEBEHAVIOUR[FUSELAGE_2_5] { defaultScale = 2.5 ScaleUpTechs = techAdvancedFrames, techHeavyTooling, techHeavyMachinery, techTitaniumWelding ScaleDownTechs = techAdvancedLightMaterials, techPreciseTooling, techUltraFineCasting, techAtomicWelding } What's only another way to write the same thing, I still have 4 techs on scale up, and 4 techs for scaling down, and I still need to adapt it to fuselages with defaultScale of 7.5 Of course, Engines would need a new set of techs. Give a peek on the problems while developing the R-3350 Duplex Cyclone or the R-4360 Major Wasp engines (used on the Super Constellation). Heat dissipation is only one of the problems they had.

Perhaps I had jumped into conclusions too hasty - had I mention that currently I'm on coffee withdrawal? Exactly. I realised it the harsh way. And you are one of the lucky ones! I got parts anchored in the 3D space and exploding due the stress of the whole craft compressing it, followed by the statics around going on the Kerbal way to space. That was a riot... Now I get it. You are trying to salvage the savegame. On the KSP 1.4 era, when the Zero Mass stunt blew up on my face, KSP was not, yet, reinjecting the prefab on living crafts. What you did worked because KSP now reinjects prefab data into crafts on loading - stunt that can be useful on certain situations (as yours) but surely broke my legs a lot of times - to the point I had to write KSP Recall when things started to get nasty again. Well, it was once. It's the reason I published a patch removing MFT (my favourite FS, by the way) at that time, as it was the safer way out before KSP 1.7 (I think, I didn't played 1.6 at all, so perhaps the stunt started there) because once you remove info from a living craft, it was gone for good. Only now with the prefab being reinjected back your patch is safe. Good to now, thanks for standing your ground on this - I would had missed some pretty interesting insights! I have mixed feelings on the subject. Of course I would prefer having a easier life with TweakScale on the subject, but... I would not have MFT and some others interesting things as FAR available if Add'On authors had decided to refrain themselves due it. So, having some trouble on TS is kinda a small price to pay for them, mainly because TweakScake users are engaged and help me a lot on the task! As you did, by the way, giving me some light about the reasons some things had happened.

I finally got it. (Not being able to take coffee makes my life a misery!! ) I see your point, but I'm not convinced (at least yet) that your way is the best way for the most parts - but, granted, if people were willing to use only the most common parts there would be no need for Add'Ons. Well, let's keep this brainstorming ongoing. It gave me some ideas. I think this is were you got it wrong. TWEAKSCALEBEHAVIOURS are only "macros" defined somewhere, it's a way to inject snippets of patches into parches. So, you in this case, you don't need a SCALETYPE for every combination of engines and tech required. You need a BEHAVIOUR for every tech required, and then inject the proper behaviour for that part . Pending further tests, you can inject more than one BEHAVIOUR on a part - as long you write the second behaviour properly. You will need a lot of thinking on the process - but usually good thinking render better results than brute force solutions, so I think it's the way to go. I have a problem with this approach: theres no real hard limit for the number of defaultScales a part can have - I choose to shove the same bunch of defaultScales for every part to keep things easy to be used, but one Add'On Author can choose to overrule me on this (to tell you the true, some indeed do it!), so we end up with a problem: there's no guarantee that the defaultScales will be standardised on different parts - think about the Steam Engine eras, when similar parts made on UK and on USA had different scalings, besides doing exactly the same thing. So, a default scale of 5.0 can be the middle one, or can be the initial scale for some parts, of the last usable scale on others. In each one of these situations, you would need different ScaleDownTechs and ScaleUpTechs the same way. So this approach , using ScaleUpTechs and ScaleDOwnTechs, will have the same problems it aims to solve - it only happens that such problems will not be noticeable on TweakScale standard patches. However... Your idea gave me another idea: unlockScaleDownTech and unlockScaleUpTech. In order to scale a part, you need to get both the unlockScaleDownTech and the requiredTech respective to the the new scale you want on the part. FreeScale would have to obey only to the unlocks, and the part would scale towards a defaultScale only if the respective tech is already opened (so one would not be able to rig the system by scaling near the locked scale). An additional trick is to have requiredTechs predefined for each default Scale of a part. And with that unlock* thingies and predefined requiredTechs on additional behaviours, I think we get the results you aim on a more flexible approach.

The problem is that B9 deactivates itself when Modular Fuel Tanks is installed, but doesn't ignores TweakScale callbacks, and so things go through the tubes. I didn't figured out a way to detect an inactive B9PSW in order to suppress the callback neither. So the only solution from TweakScale point of view is to withdraw itself from the part when more than a (known) fuel switch is detected. I published a patch last year removing Modular Fuel Tanks when B9PSW is also detected. I priorized B9PSW exactly due the problem you detected, you lose too much functionalities. One must carefully remove only the fuel switching code - and then flag the part with an ISSUEOVERRULE so TweakScale doesn't touch it. Every Fuel Switch (except IFS, that just overun stock resources handling and rewrote one for itself) will have its toes stomped by the Editor, unless it sends a KSP Recall event every time it changed something. I think I have fixed a fork of mine, but didn't had the time to test it yet. Other than that, perhaps some Unity objects being created or called on the wrong place - also easily fixable. Few Add'Ons are so "invasive" and overarching as TweakScale (pretty noose this one), and that's makes it a perfect Miner's Canary : if it works, then it's usually easy to fix a Parts Add'On that broke; if TweakScake breaks, boy... We have a problem.

Incredible Armenian girl. Really impressive!

Hummm.. tricky to understand, I think I did it - but not exactly sure. But I see your point, at least... It looks more like a flaw on the code when limiting things. Since Tech Tress were never effectively used before, I can fix this behaviour with little to no fuss on the status quo. One can only freeScale towards an already unlocked scaleFactor. How about a Tech allowing to freeScale the part? The techRequired would unlock the diameter, as you specified. And another Tech would be required to allow freeScale between the diameters. That would include a handicap also on parts that are already freeScale. Or specify behaviours for groups of parts. The problem you are pinpointing appears to be already solved, besides not specifically to the Tech problem. You can even specify different Techs for different parts - scaling a Engine would need a different set of Techs than scaling a Wing. -- -- -- I will give a another look on the rest of the post later, it's after work now and I'm somewhat tired of thinking. Tomorrow morning I will reread this, with a fresh mind, and retake from here.