Numberyellow Posted January 17, 2019 Share Posted January 17, 2019 lol....yeah, i can see where a typo like that would be absolutely hilarious, especially given the context.. So that saying of yours " Espernear é direito do enforcado " Roughly translates to "Kicking is the right of the hanged man"? If it's wrong, i'm not surprised, lol I don't speak ANY portugese, and it took 5 translation sites to piece together THAT crude translation. But yeah, if the translation is good enough, then i get what you're saying. we're right to be upset about our saves getting nuked. This is all nice...but i feel we're straying off topic again...and i don't wish to be smote by the forum gods.. what (if anything) can be done about the problem? Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 17, 2019 Author Share Posted January 17, 2019 (edited) 1 hour ago, Numberyellow said: what (if anything) can be done about the problem? I had tried to patch the already somewhat big amount of patches in the code, but once I figured out a way to make a part to (apparently) work, something else became broken. It's not impossible that by persisting on the task I could pull something out of my hat that ended up working - but the time I already spent on all this mess was enough to really fix the problem properly, and that hack probably would break next time anything changes… So I gave up. What it's planned for the next weeks are: Somewhat drastic refactoring of TweakScale code to decouple the problematic, part specific, code from the TweakScale core business. TweakScale scales Weight, Mass, Forces (Thrust, Lift, etc), Resources (Consumption, Production and Storage), Size and Cost and this will be kept in the core. And I need to keep legacy code working - some parts had implemented support by realizing IRescalable in their plugin code. I need to keep these working, or I will make yet more breakage. This is about 80% done, by the way Part specific code (including for stock parts) will be delegated to third parties DLLs (yeah, Plugin's Plugins!). Of course, the current set of supported parts will be implemented by me, so in the end, we will have the same classic TweakScale functionalities working under a new code tree Each Plugin's Plugin will be very picky about the parts it supports - no more broad guessing. I still need to figure out how to keep CKAN users happy with this change. I have about 30% of this task done by now. From now on, new parts or changes on some parts will be confined to the respective Plugin No more uncontrollable collateral effects by fixing one code that someone else was also using for another part Neither modules deactivating themselves without TweakScale being able to detect it. So, yeah, now the heat will be focused on the real culprits, not on the Screaming Victims! Problems will be way easier to be localized and fixed. Or at the very worst, punctually deactivated so I don't have to repeat this stunt again. About your understanding from that saying, yes. It's exactly that. Edited January 17, 2019 by Lisias (sigh) typos.But you already knew it. Quote Link to comment Share on other sites More sharing options...
Numberyellow Posted January 17, 2019 Share Posted January 17, 2019 Sounds like a lot of work. What's more work: this, or a complete rewrite, from scratch? Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 18, 2019 Author Share Posted January 18, 2019 12 hours ago, Numberyellow said: Sounds like a lot of work. What's more work: this, or a complete rewrite, from scratch? A bit less work than you think - the hard part is to do not break things. Other than that, the work is moving code around and creating interfaces. A rewrite from scratch would face the exact same problems the current code tree have - "the others" (Sartre feelings ). The real problem, after all, is Unholy Interactions between Modules (Kraken food). And this problem cannot be tackled using a monolithic, one size fits all solution. But forking TweakScale (or any replacement) to each possible situation is also unfeasible, as 95% of the core business of the thing would be the same for every one and any fix or update would need to be replicated everywhere. On the bottom line, any rewrite that would follow the current TweakScale M.O. would have the same bad results in a near future, when things start to change again. So, such rewrite would had to do something equivalent to what I'm doing now with the current Code Tree. And since we already have a working code tree, and I already have a architecture solution for the problem, rewriting all the code would only add more complexity and attack surface for bugs - not to mention the work to preserve support for the legacy IRescalable clients. Right now, I have all of this already solved for free. TweakScale itself is working fine, what's happening is it being improperly applied. Quote Link to comment Share on other sites More sharing options...
Numberyellow Posted January 18, 2019 Share Posted January 18, 2019 OK, fair enough. Hopefully, one day, Squad will decide to incorporate this mod into the game as well...then the headache will be theirs, lol Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 19, 2019 Author Share Posted January 19, 2019 (edited) On 1/18/2019 at 5:18 PM, Numberyellow said: OK, fair enough. Hopefully, one day, Squad will decide to incorporate this mod into the game as well...then the headache will be theirs, lol I suspect they are avoiding the subject exactly due the headaches! The fun fact about the situation is that there is an iRescalable interface that could be implemented by the Add'On authors to fully support the feature. Add'ons that use this are working fine. And this is the main reason I'm taking some more pain in order to avoid breaking these guys - it would be hugely unfair to do harm exactly to the ones that played nice since the beginning, Had everybody adopted this Modus Operandi, instead of blindly shoving support by brute-force using MM Scripts (I'm not criticizing the tool, but the use of the tool on this specific case), we would had avoided this marvelous messup. But since is unfeasible to convince everybody to support TweakScale, and yet users still want to TweakScale such parts, my solution for the problem is to resurrect the idea, but coping to the fact that the scaling support will not be implemented by the add'on developer, but by third parties. This, way, TweakScale doesn't have to play cat and mouse by guessing things that changes regularly, and any stunt that would be needed to support a new or exoteric part will not compromise the remaining working ones. Edited March 20, 2019 by Lisias tasting my own medicine :) Quote Link to comment Share on other sites More sharing options...
Virtualgenius Posted February 6, 2019 Share Posted February 6, 2019 Is there any news on the code upgrades Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 9, 2019 Author Share Posted February 9, 2019 On 2/6/2019 at 5:53 AM, Virtualgenius said: Is there any news on the code upgrades Waiting the next local holidays, as this is no small business. It's not something that you take on a lazy 2 or 3 hours of a Saturday. In the mean time, critical issues that would still be lingering will be handled by emergencial patches on the current code tree. Quote Link to comment Share on other sites More sharing options...
JadeOfMaar Posted February 11, 2019 Share Posted February 11, 2019 @Lisias It's about time I came to this thread and scrubbed a bit to see what's up. I'm not aware of any releases since 1.6 (according to KSP AVC) and I don't mean to put pressure on you but I'd like to mention that it seems the new stock parts (including those which have a subtle part name change and their previous known form still exists as a deprecated part) do not get a Tweakscale module, namely the 2.5m protective nose cone Mk7, the Poodle, the fuel-bearing Kerbodyne adapter and (unless this is from a mod) the 0.625m "small blunt nose cone." Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 11, 2019 Author Share Posted February 11, 2019 48 minutes ago, JadeOfMaar said: @Lisias It's about time I came to this thread and scrubbed a bit to see what's up. I'm not aware of any releases since 1.6 (according to KSP AVC) and I don't mean to put pressure on you but I'd like to mention that it seems the new stock parts (including those which have a subtle part name change and their previous known form still exists as a deprecated part) do not get a Tweakscale module, namely the 2.5m protective nose cone Mk7, the Poodle, the fuel-bearing Kerbodyne adapter and (unless this is from a mod) the 0.625m "small blunt nose cone." There're a lot of parts not supported by now. Worst, I had to actively withdraw support for some parts to prevent crashes on KSP (really nasty stuff, that tainted my savegame at that time - apparently the trigger for the problem happens way before the problem, and it ends up being persisted on the savagame, assuring a crash afterwards). (see this issue on the legacy fork) You can oversee what I'm doing on my issues: https://github.com/net-lisias-ksp/TweakScale/issues . I have (almost) all the needed tasks there. My next time window (with enough time) to work on it in our Carnival, scheduled to 4,5 and 6 March. This will give me 5 days (Saturday 2 to Wednesday 6) to deep dive on this. Krakens know I will need every minute. Quote Link to comment Share on other sites More sharing options...
Nicky21 Posted February 12, 2019 Share Posted February 12, 2019 How do I confgure tweakscale to scale the production of extraplanetary launchapds componets with scale? Everybody tells me that resizing the component will fit more engeners in it but that is a bad solution, as resizing number of crew slots in a componets always leads to problems. For reference the variable that needs rescaling is: MODULE { name = ELWorkshop ProductivityFactor = 0.05 } Can someone tell me what should i add to my tweakscale config file so this is scaled acordingly ? Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 12, 2019 Author Share Posted February 12, 2019 (edited) On 2/12/2019 at 9:11 AM, Nicky21 said: How do I confgure tweakscale to scale the production of extraplanetary launchapds componets with scale? For reference the variable that needs rescaling is: MODULE { name = ELWorkshop ProductivityFactor = 0.05 } Can someone tell me what should i add to my tweakscale config file so this is scaled acordingly ? TweakScale doesn't know about custom modules, unless the Add'On author implements the IRescalable interface . Unfortunatelly, ELWorkshop doesn't (I just checked). TweakbleEverything doesn't support this module neither. Until I finish that "Big Refactoring from Krakens" (tm) next month, and someone implements a plugin's plugin for Extraplanetary Launchpads, your best bet is editing the craft file yourself to change the value manually. If the value is on the Module's config, usually works, as you can see on the absurdity on the spoiler below (it's this way I test things before writing code or configs - it's easier and faster to reload a craft than reboot KSP!). Spoiler ship = Untitled Space Craft version = 1.4.1 description = type = VAB size = 2.00498533,2.13884354,2.00498533 persistentId = 2624263394 rot = 0,0,0,0 missionFlag = Squad/Flags/default vesselType = Debris PART { part = mk1pod_4294722296 partName = Part persistentId = 738861761 pos = 0.0103500411,15.7858973,-0.0308292359 attPos = 0,0,0 attPos0 = 0.0103500411,15.7858973,-0.0308292359 rot = 0,0,0,1 attRot = 0,0,0,1 attRot0 = 0,0,0,1 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = -1 resPri = 0 dstg = 0 sidx = -1 sqor = -1 sepI = -1 attm = 0 modCost = 0 modMass = 0 modSize = 0,0,0 link = radialRCSTank_4294503824 link = omsEngine_4294092004 link = omsEngine_4293969854 link = omsEngine_4293969780 link = omsEngine_4293969706 link = omsEngine_4293969632 link = omsEngine_4293969558 link = omsEngine_4293969484 link = omsEngine_4293969410 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleCommand isEnabled = True hibernation = False hibernateOnWarp = False stagingEnabled = True EVENTS { } ACTIONS { MakeReferenceToggle { actionGroup = None } HibernateToggle { actionGroup = None active = False } } UPGRADESAPPLIED { } } MODULE { name = ModuleReactionWheel isEnabled = True actuatorModeCycle = 0 authorityLimiter = 100 stateString = Active stagingEnabled = True WheelState = Active EVENTS { } ACTIONS { CycleAction { actionGroup = None } Activate { actionGroup = None } Deactivate { actionGroup = None } Toggle { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleColorChanger isEnabled = True animState = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = Light } } UPGRADESAPPLIED { } } MODULE { name = ModuleScienceExperiment isEnabled = True Deployed = False Inoperable = False cooldownToGo = 0 stagingEnabled = True EVENTS { } ACTIONS { DeployAction { actionGroup = None } ResetAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleScienceContainer isEnabled = True stagingEnabled = True EVENTS { } ACTIONS { CollectAllAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = FlagDecal isEnabled = True flagDisplayed = True stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = ModuleConductionMultiplier isEnabled = True stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = ModuleDataTransmitter isEnabled = True xmitIncomplete = False stagingEnabled = True EVENTS { } ACTIONS { StartTransmissionAction { actionGroup = None active = False } } UPGRADESAPPLIED { } } MODULE { name = ModuleLiftingSurface isEnabled = True stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = ModuleTripLogger isEnabled = True stagingEnabled = True EVENTS { } ACTIONS { } Log { flight = 0 } UPGRADESAPPLIED { } } RESOURCE { name = ElectricCharge amount = 50 maxAmount = 50 flowState = True isTweakable = True hideFlow = False isVisible = True flowMode = Both } RESOURCE { name = MonoPropellant amount = 10 maxAmount = 10 flowState = True isTweakable = True hideFlow = False isVisible = True flowMode = Both } } PART { part = radialRCSTank_4294503824 partName = Part persistentId = 1588260174 pos = 0.0103500411,16.5858974,-0.0308292359 attPos = -0.0872260407,-0.0449123383,-0.0233721007 attPos0 = 0.0872260407,0.844912529,0.0233721007 rot = 0,0.707106709,-0.707106829,-8.44551948E-08 attRot = 0,0,0,1 attRot0 = 0,0.707106709,-0.707106829,-8.44551948E-08 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = -1 resPri = 0 dstg = 0 sidx = -1 sqor = -1 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } RESOURCE { name = MonoPropellant amount = 14000 maxAmount = 14000 flowState = True isTweakable = True hideFlow = False isVisible = True flowMode = Both } } PART { part = omsEngine_4294092004 partName = Part persistentId = 1678399645 pos = 0.0103499871,15.5054007,-0.643863976 attPos = 0,0,0 attPos0 = -5.40167093E-08,-0.280496597,-0.613034725 rot = -2.30471251E-08,0.99690026,-0.0786757544,-3.49632558E-07 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -2.30471251E-08,0.99690026,-0.0786757544,-3.49632558E-07 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4293969854 sym = omsEngine_4293969780 sym = omsEngine_4293969706 sym = omsEngine_4293969632 sym = omsEngine_4293969558 sym = omsEngine_4293969484 sym = omsEngine_4293969410 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } PART { part = omsEngine_4293969854 partName = Part persistentId = 2398181505 pos = -0.423131019,15.5054007,-0.464310169 attPos = 0,0,0 attPos0 = -0.433481067,-0.280496597,-0.433480918 rot = -0.0301079322,0.92101562,-0.0726869181,-0.381497592 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -0.0301079322,0.92101562,-0.0726869181,-0.381497592 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4294092004 sym = omsEngine_4293969780 sym = omsEngine_4293969706 sym = omsEngine_4293969632 sym = omsEngine_4293969558 sym = omsEngine_4293969484 sym = omsEngine_4293969410 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } PART { part = omsEngine_4293969780 partName = Part persistentId = 1542305659 pos = -0.602684617,15.5054007,-0.0308292191 attPos = 0,0,0 attPos0 = -0.613034666,-0.280496597,1.67638063E-08 rot = -0.055632174,0.704914689,-0.0556321405,-0.704915166 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -0.055632174,0.704914689,-0.0556321405,-0.704915166 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4294092004 sym = omsEngine_4293969854 sym = omsEngine_4293969706 sym = omsEngine_4293969632 sym = omsEngine_4293969558 sym = omsEngine_4293969484 sym = omsEngine_4293969410 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } PART { part = omsEngine_4293969706 partName = Part persistentId = 632174080 pos = -0.423130929,15.5054007,0.402651787 attPos = 0,0,0 attPos0 = -0.433480978,-0.280496597,0.433481038 rot = -0.072686933,0.381496906,-0.0301078875,-0.921015918 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -0.072686933,0.381496906,-0.0301078875,-0.921015918 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4294092004 sym = omsEngine_4293969854 sym = omsEngine_4293969780 sym = omsEngine_4293969632 sym = omsEngine_4293969558 sym = omsEngine_4293969484 sym = omsEngine_4293969410 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } PART { part = omsEngine_4293969632 partName = Part persistentId = 3542424412 pos = 0.0103501491,15.5054007,0.582205474 attPos = 0,0,0 attPos0 = 1.08033419E-07,-0.280496597,0.613034725 rot = -0.0786757544,-3.93208438E-07,2.64861519E-08,-0.99690026 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -0.0786757544,-3.93208438E-07,2.64861519E-08,-0.99690026 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4294092004 sym = omsEngine_4293969854 sym = omsEngine_4293969780 sym = omsEngine_4293969706 sym = omsEngine_4293969558 sym = omsEngine_4293969484 sym = omsEngine_4293969410 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } PART { part = omsEngine_4293969558 partName = Part persistentId = 3607904701 pos = 0.443831176,15.5054007,0.402651668 attPos = 0,0,0 attPos0 = 0.433481127,-0.280496597,0.433480918 rot = -0.0726869181,-0.381497651,0.0301079378,-0.92101562 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -0.0726869181,-0.381497651,0.0301079378,-0.92101562 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4294092004 sym = omsEngine_4293969854 sym = omsEngine_4293969780 sym = omsEngine_4293969706 sym = omsEngine_4293969632 sym = omsEngine_4293969484 sym = omsEngine_4293969410 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } PART { part = omsEngine_4293969484 partName = Part persistentId = 82403673 pos = 0.623384714,15.5054007,-0.0308293272 attPos = 0,0,0 attPos0 = 0.613034666,-0.280496597,-9.12696123E-08 rot = -0.0556321405,-0.704915166,0.055632174,-0.704914689 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -0.0556321405,-0.704915166,0.055632174,-0.704914689 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4294092004 sym = omsEngine_4293969854 sym = omsEngine_4293969780 sym = omsEngine_4293969706 sym = omsEngine_4293969632 sym = omsEngine_4293969558 sym = omsEngine_4293969410 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } PART { part = omsEngine_4293969410 partName = Part persistentId = 1343060632 pos = 0.443830907,15.5054007,-0.464310408 attPos = 0,0,0 attPos0 = 0.433480859,-0.280496597,-0.433481157 rot = -0.0301078744,-0.921015978,0.072686933,-0.381496727 attRot = 0.258819044,-3.23224736E-09,4.21838076E-09,0.965925813 attRot0 = -0.0301078744,-0.921015978,0.072686933,-0.381496727 mir = 1,1,1 symMethod = Radial autostrutMode = Off rigidAttachment = False istg = 0 resPri = 0 dstg = 0 sidx = 0 sqor = 0 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = omsEngine_4294092004 sym = omsEngine_4293969854 sym = omsEngine_4293969780 sym = omsEngine_4293969706 sym = omsEngine_4293969632 sym = omsEngine_4293969558 sym = omsEngine_4293969484 srfN = srfAttach,mk1pod_4294722296 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleGimbal isEnabled = True gimbalLock = False gimbalLimiter = 100 currentShowToggles = False enableYaw = True enablePitch = True enableRoll = True gimbalActive = False stagingEnabled = True EVENTS { } ACTIONS { ToggleAction { actionGroup = None } LockAction { actionGroup = None } FreeAction { actionGroup = None } TogglePitchAction { actionGroup = None } ToggleYawAction { actionGroup = None } ToggleRollAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False stagingEnabled = True EVENTS { } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } UPGRADESAPPLIED { } } } HINT: Set the rigidAttachment to True on the part you are tweaking (and everything else to False), and the search for "rigidAttachment = True" on the craft file using your favorite text editor. This helps a lot on finding the correct part. If you are using KOS, using the naming feature also is a plus. Edited March 20, 2019 by Lisias tasting my own medicine :) Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted February 14, 2019 Share Posted February 14, 2019 (edited) Wondering if anyone else has this issue - I suspect it's some kind of mod interaction, but don't know which one would be interacting with TweakScale... On command parts such as the HECS probe core or the 1.25m or 2.5m remote guidance units, which all have "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" in their patches, the apparent size of the part in the editor (as well as apparent size of its nodes, and also the direction of attachment the stack nodes allow) are all messed up. In addition, they have two tweakscale sliders (see image - shows scale problem and slider, but not nodes): Seems to be OK in flight scene, weirdly. In any case, removing the "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" also seems to fix the issue. Is this a thing? Or have I borked something somewhere? EDIT: 1.6.1 with Making History, latest (I think) tweakscale. Edited February 14, 2019 by AccidentalDisassembly Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 15, 2019 Author Share Posted February 15, 2019 (edited) On 2/14/2019 at 8:56 PM, AccidentalDisassembly said: On command parts such as the HECS probe core or the 1.25m or 2.5m remote guidance units, which all have "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" in their patches, the apparent size of the part in the editor (as well as apparent size of its nodes, and also the direction of attachment the stack nodes allow) are all messed up. In addition, they have two tweakscale sliders (see image - shows scale problem and slider, but not nodes): [...] In any case, removing the "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" also seems to fix the issue. Kraken food! (see my signature) Some add-ons can be blindly adding support via MM to parts, disregarding if such support is already there. Other than your perceived glitches, appears to be harmless - I have a installment with this glitch that I'm letting this glitch to linger to see what happens, and until the moment, it's almost harmless (only once the scaling settings were reseted when one of the duplicates vanished - what's interesting, usually the first occurrence of the module in the craft file is the dominating one). (some time later….) Properly checking for the absence of the module before patching up the part (avoiding duplicates) is the right thing to do, but guess what.. TweakScale default patches doesn't do that neither, so I guess I'm part of the problem. Since were are the reference for TweakScale (me, pelinnor and biotornic) we didn't bored to check by ourselves, who would add TweakScale support for a part that we had already added support? But then things had grown beyond our expectative, we added support for a lot of new parts and there's a chance (this was an understatement ) that, now, I'm the one stomping on my feet on this. Thank you for your research. You saved me some research work, I was (naively) looking for the trouble source everywhere but on the right place (my garden). You also confirmed my hunch that the New Breed (hopefully to be worked out next month) should not include patches to broadly add support to unknown parts (ideally, such wildcard patch must be run by the last, when everybody else had the chance to do it - how to accomplish this is something I need to do some research - at the very worst case, I will do it by code). Well… New issue on the block, Thanks for the report. — — — POST — EDIT — — — I could not reproduce manually the problem. This IS NOT a patch problem. See below. Edited February 16, 2019 by Lisias Post edit Quote Link to comment Share on other sites More sharing options...
pellinor Posted February 15, 2019 Share Posted February 15, 2019 6 hours ago, Lisias said: what's interesting, usually the first occurrence of the module in the craft file is the dominating one The module disables itself if it is not the first one:https://github.com/net-lisias-ksp/TweakScale/blob/master/Source/Scale/Scale.cs#L750-L757 Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 15, 2019 Author Share Posted February 15, 2019 (edited) On 2/15/2019 at 5:13 PM, pellinor said: The module disables itself if it is not the first one:https://github.com/net-lisias-ksp/TweakScale/blob/master/Source/Scale/Scale.cs#L750-L757 Yep. At least once I got a craft with the scaling of one part reset due the first TweakScale data on that part "vanishing". I didn't managed to figure out what's happened, it didn't happened again. Ideally, the dormant copies should be prevented from being saved into the craft file - I fooled a bit on the Atmospheric Autopilot that is mangling the ModuleControlSurface to a SyncModuleControlSurface, what's playing havoc when exporting crafts [nowadays, it worked in the past]. I managed to force that SyncModuleControlSurface to save itself as ModuleControlSurface, what should had worked as I read here, however it didn't worked (four years is a lot of time, things change). But that bork apparently took me to the right place - the very same "glitch" that hurt me on AA, can be twisted in our favor on TweakScale - once deactivated, that TweakScale copy will be prevented to save his data at all (or at least, mangle the info so it's ignored when the craft is loaded again). That's a way to save the day easily, and can be done in a couple hours [yeah... Right...] - what I intend to do by night or tomorrow morning. — — — POST — EDIT — — — Ha! I finally understood why my craft was losing that settings! Yes, the first module copy is the dominant one, the remaining copies get disabled. However, all of them are still being persisted on the craft file. Now things get interesting. If you fix your installment, you will not get duplicated modules consuming the config sections anymore. In this situation, only the last module's section are read (due ConfigNode's specification on duplicated entries being read as a singleton one), and the net result is that the previously working data is overwritten on memory by the last disabled module's data (that was written after the dominant the last time there were more than one module in memory!), that have only default values [or, worst, empty ones!] Literally, by fixing your installment, you lose configuration data. And by exporting your craft files to third parties (as using KerbalX), people with sane installments will get a corrupted craft , besides all the data still being there. So, the only safe option is, indeed, to prevent disabled modules to persist their data on the craft file. This is Work In Progress now. Spoiler DANGER, WILL ROBINSON, DANGER! DO NOT fix your installments with duplicated TweakScale support on parts, or your craft will get corrupted! Wait for the next minor release of TweakScale, where I will "fix" the issue without losing the settings for the part! Edited February 17, 2019 by Lisias MOAR INFO! Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 15, 2019 Author Share Posted February 15, 2019 (edited) On 2/14/2019 at 8:56 PM, AccidentalDisassembly said: Seems to be OK in flight scene, weirdly. In any case, removing the "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" also seems to fix the issue. Is this a thing? Or have I borked something somewhere? EDIT: 1.6.1 with Making History, latest (I think) tweakscale. Could you please try to "break again" a copy of your KSP,, and then send me the KSP.log? I'm not being able to manually reproduce the glitch. All my attempts to force a second module instance on a part using a MM patch failed, all I could do is to duplicate entries on the single TweakScale entry. I even tried to mangle the MM cache manually to force the issue, but it does not triggers the "duplicate module" message on TweakScale. We can see on the following excerpt from my testbed's KSP.log that I managed to apply the patch twice, but a second TweakScale instance is never detected on runtime (the TweakScale doesn't complains about a duplicate, and the craft file doesn't have a second TwakScale section). [LOG 21:26:56.791] Config(@PART[Mark1-2Pod]) TweakScale/patches/Squad/Squad_CmdCtrl/@PART[Mark1-2Pod] [LOG 21:26:56.791] Config(@PART[mk1-3pod]) TweakScale/patches/Squad/Squad_CmdCtrl/@PART[mk1-3pod] [LOG 21:26:56.791] Config(@PART[mk1-3pod]) TweakScale/patches/Squad/Squad_CmdCtrl/@PART[mk1-3pod] [LOG 21:26:56.791] Config(@PART[mk1pod]) TweakScale/patches/Squad/Squad_CmdCtrl/@PART[mk1pod] [LOG 21:26:56.791] Config(@PART[mk1pod]) TweakScale/patches/Squad/Squad_CmdCtrl/@PART[mk1pod] [LOG 21:26:56.791] Config(@PART[mk2LanderCabin]) TweakScale/patches/Squad/Squad_CmdCtrl/@PART[mk2LanderCabin] I will probably need your Module Manager's cache files too. NEVERMIND! I managed to reproduce something similar (but not exactly equal yet)!! I'm getting there!!! Edited February 16, 2019 by Lisias moar files Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 16, 2019 Author Share Posted February 16, 2019 (edited) (sigh). This is old news. Biotronic had already handled something like this in 2014-0628. I also confirmed that this is not necessarily a problem on every KSP version. The oldest I cared to test was 1.4.1, and on that KSP, this is not a problem. The glitch is there (I hand crafted the glitch on the MM cache), but it doesn't causes the problems we are facing now. But as we can see above, it once affected TweakScale on the past. The same procedure (hand crafting a duplicated TweakScale entry on the MM cache) causes this problem on 1.6.1 . So it came back from the Closed Issues' Hell. The way it affects craft files make this somewhat critical - it's "corrupting" craft files. The user cannot "fix" his installment neither export the craft file to Kerbal-X - as the net result will be a broken craft. Seriously broken, as some fields goes to "0" - not exactly a desirable thing when you scale things (think on multiplies, now think on zero masses, now think on crashes due division by zero). "Fixing" the patches is not enough. This would prevent the TweakScale stock patches to mangle a already patched part only if someone already had patched it. If someone patches it after TweakScale's patches being applied, we will have the problem again. This is not something that one Add'On author can solve alone - unless this Add'On author is the one applying the patches. (sigh). I foresee some interesting times ahead. This is not affecting only TweakScale. Virtually every Module is vulnerable to this glitch. I will publish soon a Workaround to the problem under our nose so at least I can save TweakScale users from losing his crafts (due TweakScale at least), but a proper fix is beyond TweakScale. People err. People will always err. We still use seat belts on Tesla cars with autopilots for a reason. We need safety belts on KSP Add'Ons scene. Edited March 20, 2019 by Lisias tasting my own medicine :) Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 16, 2019 Author Share Posted February 16, 2019 (edited) ANNOUNCE. Release 2.4.1.0 is available for downloading. See OP for the links. THIS IS A *URGENT* UPDATE. An Unholly Interaction between Add'ons (also known as Kraken food) that occasionally duplicates the TweakScale instances on the prefab was detected, leading to the following situations: TweakScale detects the duplicity and disable itself on the duplicated instances. Other than you seeing some duplicated "Scale" scalings on the UI, this is harmless However, by persisting the craft (and the savegame), such duplicates are persisted too. Apparently, no harm is done as only the dominant TweakScale instance will be active and using his data. But now things can go through the tubes: once the duplicated instances on the prefab are fixed, all your crafts and savegames gets corrupted on loading, as the code that loads Config data gives preference to the last instance persisted, not the first. How the prefab gets the duplicated TweakScale instances? By the same means it got the first one: code, patches or manual editing of the Module Manager's cache. This means that you can install an add'on, get the problem and then all your savings will get mangled. And then you delete, update or add some other add'on that fixes the problem by side-effect, and now all your savegames and crafts are kaput. Nasty. This Release prevents the loss by further mangling the duplicated instances in a way that once the prefab gets fixed, the duplicates does not overwrite the canonical instance anymore. So your savegames and craft files are still usable on sane KSP installments, including yours once the problem vanishes without notice. So, yeah, this is a urgent release and every TweakScale user are urged to update. Additionally, support for Stockalike Station Parts Redux was added. Courtesy of @Speadge. And the 1.875 scale is now officially a Stock Scale, as suggested by @Tyko. Please keep an eye on the KNOWN ISSUES file. I will keep it updated regularly. — — — — -- This Release will be published using the following Schedule: GitHub , reaching first manual installers and users of KSP-AVC. CurseForge - by Sunday night SpaceDock (and ckan users) - by Monday night The reasoning is to gradually distribute the Release to easily monitor the deployment. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Hit me here if that happens, I can help. Edited February 16, 2019 by Lisias Hit "Save" too soon. Quote Link to comment Share on other sites More sharing options...
Tyko Posted February 16, 2019 Share Posted February 16, 2019 Great work solving that issue Thanks!! Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted February 16, 2019 Share Posted February 16, 2019 3 hours ago, Lisias said: ANNOUNCE. Release 2.4.1.0 is available for downloading. See OP for the links. THIS IS A *URGENT* UPDATE. An Unholly Interaction between Add'ons (also known as Kraken food) that occasionally duplicates the TweakScale instances on the prefab was detected, leading to the following situations: TweakScale detects the duplicity and disable itself on the duplicated instances. Other than you seeing some duplicated "Scale" scalings on the UI, this is harmless However, by persisting the craft (and the savegame), such duplicates are persisted too. Apparently, no harm is done as only the dominant TweakScale instance will be active and using his data. But now things can go through the tubes: once the duplicated instances on the prefab are fixed, all your crafts and savegames gets corrupted on loading, as the code that loads Config data gives preference to the last instance persisted, not the first. How the prefab gets the duplicated TweakScale instances? By the same means it got the first one: code, patches or manual editing of the Module Manager's cache. This means that you can install an add'on, get the problem and then all your savings will get mangled. And then you delete, update or add some other add'on that fixes the problem by side-effect, and now all your savegames and crafts are kaput. Nasty. This Release prevents the loss by further mangling the duplicated instances in a way that once the prefab gets fixed, the duplicates does not overwrite the canonical instance anymore. So your savegames and craft files are still usable on sane KSP installments, including yours once the problem vanishes without notice. So, yeah, this is a urgent release and every TweakScale user are urged to update. Additionally, support for Stockalike Station Parts Redux was added. Courtesy of @Speadge. And the 1.875 scale is now officially a Stock Scale, as suggested by @Tyko. Please keep an eye on the KNOWN ISSUES file. I will keep it updated regularly. — — — — -- This Release will be published using the following Schedule: GitHub , reaching first manual installers and users of KSP-AVC. CurseForge - by Sunday night SpaceDock (and ckan users) - by Monday night The reasoning is to gradually distribute the Release to easily monitor the deployment. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Hit me here if that happens, I can help. Awesome! I've read your posts on the issue, and I'm not sure that I've understood everything you're working on - so this may be a useless comment: just to clarify, as far as i could tell, there were not two instances of the TweakScale module being applied to that command part. I checked this by looking for the part's name everywhere in gamedata (in all cfg files, pretty much) - the part name only appeared in the part file and the (one) TweakScale stock patch config file. The only thing I changed to get it working correctly again (correct visual size of the command parts in editor, and correct node sizes and orientations) was removing the following from the MM patch that adds TS to the probe core parts: #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } I left the rest of the MM patch (adding the module, setting the scaletype and size) unchanged. Does that mean that there were two instances of #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } somehow being applied to the same part? Or something like that? I'm afraid I don't actually know what the TWEAKSCALEBEHAVIOR thing does... Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 17, 2019 Author Share Posted February 17, 2019 (edited) On 2/16/2019 at 9:53 PM, AccidentalDisassembly said: Awesome! I've read your posts on the issue, and I'm not sure that I've understood everything you're working on - so this may be a useless comment: just to clarify, as far as i could tell, there were not two instances of the TweakScale module being applied to that command part. I checked this by looking for the part's name everywhere in gamedata (in all cfg files, pretty much) - the part name only appeared in the part file and the (one) TweakScale stock patch config file. That's the catch - on the GameData, things are not changed. Everything is applied on memory, with Module Manager using a cache file to fast load things when nothing is added/deleted/modified on the GameData. This saves a lot of time, by the way. The place you should look for the duplicated entry is on the MM cache - it's the only place, besides KSP' memory, where the mishap can be detected. You should find something like this. I didn't bothered to really check this specific source of the trouble - once I finally understood where things were going wrong, one trigger between hundreds is so good as any other. So i kind of ignored the trigger that are affecting you and gone right to the spot. On 2/16/2019 at 9:53 PM, AccidentalDisassembly said: The only thing I changed to get it working correctly again (correct visual size of the command parts in editor, and correct node sizes and orientations) was removing the following from the MM patch that adds TS to the probe core parts: #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } And that is what made things "interesting". The problem is not on the config file. The problem is not on some other config file. The problem happens when two or more config files, some how, interacts in a very specific way in which the net result is two (or more) instances of TweakScale' module on the prefab of some part(s). It can be some mishap made by a third-party Add'On on his config file, but can be also two or more perfectly valid config files that work fine individually, but together blows up something by a unforeseen condition by some add'on (or even Squad's) developer . Could be even a bug on Module Manager itself - this exact behavior can be the outcome of two producers trying to feed a consumer at the same time without controlling concurrency (a "race condition" on the consumer), and MM recently introduced concurrency on its guts to make things happen faster. (I'm brainstorming, I don't have any evidence of any of that, besides the glitch I detected and workarounded). On 2/16/2019 at 9:53 PM, AccidentalDisassembly said: Does that mean that there were two instances of #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } somehow being applied to the same part? Or something like that? I'm afraid I don't actually know what the TWEAKSCALEBEHAVIOR thing does... Not necessarily. Could be another config file trying to inject another behavior, or plain injecting TweakScale itself in any other possible way (as code). Can be anything, literally. It's a chain of events, and by eliminating any one of them you break the chain and the problem simply cease to exist. By deleting that TWEAKSCALEBEHAVIOUR, you just broke one of the links needed to that chain to exist. This doesn't means that the problem is on that specific link - to tell you the true, we need this specific link in order to accomplish the intended feature. The real trouble-maker link is something else. But whatever that link is, it's out of scope of TweakScale's realm. Being a rogue config file, a glitch on MM or anything else, it's beyond me the detection and the fix. So I just stopped looking for it, and realized that *my* problem is not the TweakScale being duplicated in the prefab - this was only the trigger. My problem is that TweakScale users were getting their crafts and savegames corrupted once that trigger engages. So I cooked a way to prevent the problem to happen once that trigger engages - and it will engage again, you can be sure. — — — — — I just realized that I talked about everything and the kitchen's sink, but not fully answered the guy. Let's talk about that "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" thingy. It's a preset, and you will find them on the ScaleExpoentes.cfg file on the TweakScale's root dir. There're a lot of presets, one for engines, another for science, etc. It's a way to avoid repeating ad nauseam the same settings for parts that need the same group of settings. If I understood correctly (MM's syntax can be somewhat confusing sometimes, even by someone that's digging on that code), when you put a string between "[]" you are restricting the patch to a node (I called them "sections" on my previous posts) with the atribute "name" set to that string. An "@" tells you to edit an existing node, a "%" to create or edit such a node (@ fails if the thing doesn't exists). So, the following excerpt: @PART[mk2DroneCore] { #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } Means: Edit the existing (@) part those name is "mk2DroneCore", take the MODULE named TweakScale from the preset TWEAKSCALEBEHAVIOUR named "Science" and PASTE it (#) to that part. If I remember correctly, the @ before TWEAKSCALEBEHAVIOR says that this thing must exist, and should not be created if not. Then edit or create the MODULE node named "TweakScale" adding that "type" and "defaultScale" attribut…. Huummm…... I need to check something. — — — — some time later — — — — — Yeah. I had some dirty on my garden, hidden under the grass. The support for Better Rovermattes didn't had the "%" command before the MODULE, so the default behaviour "ADD A NEW" was being used. This is one of that many possible sources for the problem I described above. I had patched the patches and committed it to be included in the next release (not need to rush, this problem is not critical anymore), but then I realized that that PASTE (#) thing was injecting a MODULE node for TweakScale for sure on everybody else, being the reason the following MODULE has a # - to edit the MODULE node injected by the # command. So I concluded that this change to Better Rovermattes was pretty useless as everybody else on this add'on are creating a new MODULE node and that's it. In a way or another, my fixes for the problem stands. As the need for the TweakScale New Breed. Edited March 20, 2019 by Lisias tasting my own medicine :) Quote Link to comment Share on other sites More sharing options...
Tallinu Posted February 17, 2019 Share Posted February 17, 2019 (edited) How do you know for sure if you are affected by the problem? That doesn't seem very clear to me. None of the craft files I have saved recently seem to have any duplicated TweakScale modules, but when I hunted through my ModuleManager.ConfigCache file I found some parts where this was the case, matching what you showed on the GitHub issue even down to the duplicated type and defaultScale settings in the first module. Spoiler This example was taken from near the end of the part M3X_CLEAVER from Mk3Expansion, looking through the file further it seems like many of that mod's parts have the issue: MODULE { name = AYA_Engine } MODULE { name = TweakScale type = stack defaultScale = 3.75 type = stack defaultScale = 3.75 TWEAKSCALEEXPONENTS { mass = 2.5 } } MODULE { name = ControllingRecoveryModule } MODULE { name = SensiblePumps } MODULE { name = TweakScale TWEAKSCALEEXPONENTS { mass = 2.5 } } MODULE { name = ModuleB9PropagateCopyEvents } I also found this slightly different-looking but also not quite right version in RLA_Reborn's small_decoupler_stack: MODULE { name = TweakScale type = free TWEAKSCALEEXPONENTS { mass = 2 } TWEAKSCALEEXPONENTS { name = TweakScale DryCost = 0.5 } } The affected parts don't seem to include any that I have actually used in my craft so far. And as I said, I didn't find any evidence of this issue in my saved .craft files. Does that mean I don't have to worry, and once I install this TweakScale update, there won't be any problems if these corrupted extra modules do get added to things in the future? I actually don't use TweakScale very often, funnily enough. I'm usually able to do everything I want without changing part scales. The only thing I can really remember doing most recently is increasing the size of the micro landing legs one time when I needed longer legs for a lander but only had those legs unlocked, and that craft was recovered a long time ago. Edited February 17, 2019 by Tallinu Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 17, 2019 Author Share Posted February 17, 2019 (edited) 12 hours ago, Tallinu said: How do you know for sure if you are affected by the problem? That doesn't seem very clear to me. Ok. Allow me to try again, I think I understood your question sideways. (sorry for that!) The easiest way to detect the glitch is to look for duplicated entries of TweakScale on a part on the MM cache. The MM cache itself is not the problem, it's only one evidence you have to check if the misbehaviour is active. The "best" way is by code checking things at runtime. "Best" because it's where things really happens, the MM Cache is just a storage. Only the part with duplicated entries are affected, not the whole shebang. And if you don't scale a part, when the problem kicks, you don't perceive it. However, since some scaling data goes to zero, and since that scaling is used to mass, if you later scale that part once the misbehaviour is reverted, you will have a zero mass part - and then you will have divisions by zero somewhere - one of that nasty stuff that I blocked last Release. So, even by not perceiving the problem, you are prone to suffer some nasty consequences, suddenly, from nowhere (and this is the reason I consider this critical - you won't be able to track down the problem!). Since you are able to look on the MM Cache, you can also fix it. Just delete the second entry on the offending parts and reboot the game. Your KSP is now sane until the MM cache is rebuilt (assuming the triggers are still on the GameData - if not, the rebuild should end up sane, unless we have a MM glitch). Since you don't really use TweakScale, once you fix your MM Cache everything will appear to be fine. But make no mistake, from now on, every "living" part on your installment that once had this mibehaviour is now using that second copy of the TweakScale data, probably with null or zero key attributes. So, from now on, any scaling on an pre-existent part is now a game killer in potential. Manually fixing the MM Cache, and then manually deleting every second (or more) instance of the TweakScale module's node on every savegame and every craft is the proper and definitive fix for the problem. If only we have a automated too for that, uh? (I'm will talk to Kerbal-X guys. They can help on the craft file thing). The less desirable way to get rid of the problem (and I tell you this with my heart broken), is to uninstall TweakScale. This thing happens due a chain of events, and breaking a single link is enough to prevent all of the nasty stuff I'm talking about. It's like an airplane: the best way to prevent a airplane crash is to keep it on the ground. Since you don't really use TweakScale, deleting it is a way to prevent the problem. And once you decide to install it back, please use the latest version. Keep in mind, however, that TweakScale is just one of the Modules that can be affected by this. Since TweakScale is somewhat popular, its exposition to the problem is broader and so, it's usual that an TweakScale user ends up being affected by this. But the misbehaviour potentially affects all the Modules on KSP. All I did is to prevent it to "kill TweakScale users" - but if you use any other module (and of course we all use them), there's a chance that this can bite you in the future nevertheless. It will just happen that TweakScale will not be in that chain of events. — — — — — Unrelated babbling. — — — — — Because it affected me in the past month, and I was chasing my tail on the problem until AcidentalDisassembly's report . I got duplicated Scale sliders on some parts, and got my vessel "corrupted", by the Scaled parts going to default, once. I didn't related both misbehaviours to the same problem until trying to explain to AcidentalDisassmbly what's happening to him. Bells ring on unexpected times. With the knowledge I acquired mangling with AA, a ring bells on my head and I gone to try to reproduce the problem from the bottom up. Once I managed to reproduce the problem, I gone to figure out the ways the problem could be created: code injection (unusual), rogue DLL (easily ruled out, I deleted them all), rogue MM Patch (easily done - copy and paste a patch twice on a file, and you got it) or a glitch on MM itself (but that was a long shot, and I made that clear). In every case, the MM cache ends being the smoking gun. The cycle closes, it fits. 12 hours ago, Tallinu said: None of the craft files I have saved recently seem to have any duplicated TweakScale modules, but when I hunted through my ModuleManager.ConfigCache file I found some parts where this was the case, matching what you showed on the GitHub issue even down to the duplicated type and defaultScale settings in the first module. The interesting thing: this is not necessarily a problem on every KSP release! Feeling bad by the breakage my last Release did (but still, it was the less evil of evil choices), I decided that I don't want to be responsible for another one, and then obsessively tested the thing on different KSP versions, from 1.4.1 to 1.6.1. Since I'm prone to apply the binary search algorithm on my efforts (it works for humans too! ): I tested 1.4.1 and the misbehavior was there but it didn't was a problem. Then I tested 1.6.1 , and the problem was there. So I concluded the research - some KSP versions tolerates the glitch, others don't - and that was enough information for while. So I wonder if this had happened in the past, but Pellinor had already saved me the trouble of looking for it myself ("gato escaldado", as we say here! Thanks, Pellinor!). Looking into the project's history, I found what appears to be the first time this problem was handled (a commit from Biotronic in mid 2016). So, by crossing the historic from different projects, I could reach to my conclusions about how the problem was happening, since then it was happening, and how I could cope with it. Again, your mileage may vary: there're versions of KSP in which this is not a problem, and there're versions in which this is a very nasty problem. 1.4.1 is ok, 1.6.1 is not, and I don't think further research is needed as the current mainstream, 1.6.1, is affected and that's enough to convince me to act. (yep, I'm obsessive! ) 12 hours ago, Tallinu said: I actually don't use TweakScale very often, funnily enough. I'm usually able to do everything I want without changing part scales. The only thing I can really remember doing most recently is increasing the size of the micro landing legs one time when I needed longer legs for a lander but only had those legs unlocked, and that craft was recovered a long time ago. Theoretically, this affects absolutely any Module. TweakScale is somewhat popular, so my exposition to the problem is somewhat broader. But this can happen to any other Module. Really. I discovered some intrinsics of the Module loading changing over versions while mangling with Atmospheric Autopilot (that extended ModuleControlSurface) — AA was my first guinea pig for this series of experiments, and my workaround was primarily intended to be used on AA (to reach the exact opposite results - that failed there, but that failure saved our sorry SAS here!!). So.. I did not fixed the problem. I workarounded it for TweakScale users (and only for TweakScale users). A proper fix is beyond me due: I'm not the boss of anyone here. I can't just tell people what to do. People err. People will always err. So even if I was the boss around here, sooner or later someone will bork. Including me. I can't, by myself, apply this workaround on every Add'On out there. It's too much of a work! So, I'm not the solution for the problem. But I can be part of the solution. Think on it as my contribution to make things less worse until a proper solution for the problem is cooked. Edited February 18, 2019 by Lisias Whopsy… My technical english bit me! Sorry!! Quote Link to comment Share on other sites More sharing options...
Tallinu Posted February 18, 2019 Share Posted February 18, 2019 Okay, I believe what you're telling me is that if any of my active craft (the ones saved in the persistence file and any quick saves) contained parts which suffer from this module duplication issue, "fixing" the duplication before installing the newest release of TweakScale would have caused the affected parts to experience issues like zero mass and other nastiness, regardless of whether or not their scale had been changed (simply the presence of the broken duplicate module is enough). Is that an accurate summary? Assuming that is true: Since I have not used any of these parts (the parts in which I found module duplication in the cache file) in any of the craft I've launched so far, none of my existing craft should experience any problems, regardless of what I do (because none of the parts they contain have duplicate modules saved). But now that I have installed the new version of TweakScale, it will prevent the duplicated module in those parts from eventually corrupting any craft I might launch that use those parts, because it renames the extra module to something else which won't overwrite the correct settings in the first instance of the module. Therefore, with the new version installed, I should be able to safely use any parts which are affected by that duplication, without having to try to manually fix hundreds of lines in the cache file every time I install or remove or update an mod (which happens frequently enough that it isn't really feasible). Correct? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.