Lisias

KSP is not known to tackle down all the bugs of a major release before issuing the next - it's exactly the opposite. Once a bug happens, you can expect it to linger for years without being correctly handled. So, unfortunately, every bug that happened in the past cannot be considered completely fixed and need to be considered a probable suspect when coincidences are detected on 'new bugs' (that, not rarely, are only different side effects of a root cause that was not tackled down). So the thing is specific to Mk1 Illuminator? That makes things easier (or less hard) to replicate. I will give it a try, now that I know where to look. One thing that the other types of light have different from Illuminator Mk1 (and Mk2!) is that Illuminator is not stackable, while the other lights are. I failed to detect any other meaningful diference while looking the CFGs. Since we are here, try this stunt: @PART[spotLight1_v2] { @MODULE[ModuleLight] { %stackableQuantity = 2 } } This will make the Mk1 Illuminator "more like" the other lights (of course, do it on a disposable installment, we are mangling with the KSP's stock parts!). If the problem goes away, we found a trigger. Knowing for sure about the trigger, we can try to zero into the problem from there. Dude, we have a problem. I can't set the MaxAmount to a "reasonable" value, or the part of KSP that is working fine will nullify the Refunding stunt by deducting the "total value of the Resource" on recovering. I.e., if you fire up a vessel with 200 Units of Fuel, and on recovering it has 10 Units of Fuel left, then KSP will deduct 200*FuelCost and will refund 10*FuelCost. On this example, MaxAmount = 200 and Amount = 10. So I need to keep MaxMount on 0.0, so KSP is fooled on the deduction I depicted above. I didn't managed to find a solution to this yet (my last attempt, setting MaxAmount to 0.00001d fired backwards). I may need to just remove Refunding support when MAS is installed.[Naaah... I tested the wrong binary! ] So I tried a stunt - I set MaxAmount to be pretty small (0.0000001d) so it would get round down by KSP on recovering, but yet would give a non 0 value to MAS play with. Please check this on your rig (I have little to no time to play KSP this week). https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.2.0.0 In time - I checked the MAS code, it's not trying to handle hidden resources as I imagined. It's calculating the current mass of the PART, and so it really needs to take hidden resources into account.

Now I got it. The problem is not about Storage in the sense of Cargo or Inventory, but about the Resource's MaxAmount. My initial approach was to shove the Refunding Resource on everything at startup and then setting the thing at Editor as needed (tried freezing the amount to 1 and then set the price per unit as the Refunding, between other stunts), and so I had to convince the Editor to never "filler up" the part - so the MaxAmount was set to zero. I remember seeing a Resource like this somewhere, but I forgot from what Add'On. But, then, to comply with new use cases I ended up creating the Refunding Resource on flight time when needed only - and since the Refunding is now a hidden Resource, the user cannot "cheat" by transferring Refunds between parts as they were Fuel or ElectricCharge. So I think I can set the MaxAmount to be equal the Amount at runtime - this will make MAS happy, I think. On a side note, ideally I would create the Refunding Resource only on recovering the Craft - but I realised that this would work only when recovering the craft under focus at the moment - crafts on rails would fail. I tried removing the Refunding everytime the craft gets the focus, and then adding it only when the craft goes to rails, but then I realised that KSP don't issue the recover event when the craft don't have the focus, but yet it's on the physics range of the focused craft - (sigh) had KSP did that, all these problems would just no be able to happen. On another side note, I think MAS should not be handling hidden Resources - they are set to hidden for a reason. [Nope. See this comment.] In a way or another, I will set the MaxAmount to the equal the Amount today by night and see what happens - I think this change will not cause impact on the expected behaviour, and it should make MAS happy. Thanks for the heads up!

You are probably right, since MAS aims to provide information about parts. However, how MAS behave with the Ablator Resource? I modelled refunding using Ablator exactly due the use Ablator have on parts - it's something that will vary with use (but, of course, without being "refilled" normally), and there's not storage for them. The only difference is that Ablator has some density, while I choose to go the ElectricCharge way on it to avoid taxing the physics of the part. Understanding how MAS handles Ablator can help on creating a solution for this on my side. That Quick&Dirty patch of mine (giving 0.0001 density to Refunding) will trick the MAS into behave, but it will affect the physics of the part (very slightly, but will).

I think you found something wrong on KSP. These messages: [WRN 22:50:22.613] [Part]: PartModule indexing mismatch at seatExternalCmd, index 2. Node 'ModuleTripLogger' found in loaded data, but 'Refunding' is defined in prefab. Looking for ModuleTripLogger in other indices... [WRN 22:50:22.613] ...ModuleTripLogger module found at index 3. [WRN 22:50:30.276] [Part]: PartModule indexing mismatch at seatExternalCmd, index 2. Node 'ModuleTripLogger' found in loaded data, but 'Refunding' is defined in prefab. Looking for ModuleTripLogger in other indices... [WRN 22:50:30.276] ...ModuleTripLogger module found at index 3. Are scattered on your KSP.log, and it means only that the index of a module on the savegame is different from the index of that same module on prefab. This happens when you add or remove a Module (by MM patching) between the time you saved that craft (on a file or on a savegame) and the time you load it again. This happens all the time, so it's not a surprise that you locate these messages near nasty exceptions, as they happens when there're no exceptions too. What are really happening on your game is this: [EXC 23:06:43.190] NullReferenceException: Object reference not set to an instance of an object ModuleInventoryPart.PreviewLimits (Part newPart, System.Int32 amountToStore, AvailablePart slotPart, System.Int32 slotIndex) (at <06f13185617646e5bc801baeab53ab75>:0) ModuleInventoryPart.Update () (at <06f13185617646e5bc801baeab53ab75>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) And this suggests there's something wrong on the ModuleInventoryPart itself. It also worth to mention that Lights were recently involved on another set of bugs too, so perhaps we have some more unfixed problems on KSP itself? The KSP bug fixing is not known for hunting root causes, but for merely patching the effects where they are found - so perhaps this could be a missed effect from an old problem that it's arising now that the previous effect on the chain was patched? Without knowing how ModuleInventoryPart.PreviewLimits works, I can only guess - but by looking on the parameters of that function, it appears to be simulating what would happen by storing this light on a part with Inventory. It worth to mention that TweakScale do not touches the ModuleInventoryPart neither ModuleCargoPart, so it's very unlikely it's playing a role on this problem. Refunding, theoretically, could be a trigger as it adds Resources at runtime and badly written code would bork on it. You can check this by deactivating Refunding on the lights and trying to reproduce the problem.

How MAS do about ElectricCharge or Ablator? It appears to be a bug on MAS, because I modelled the Refunding stunt to be like the Ablator - but "weighting" like the ElectricCharge (no weight at all). I checked the code, and I don't see where it tell one thing to another... And I don't even understand why this check is there at first place... Parts with Ablator has this same problem? At first look, it appears that yes, it should be complaining about the ElectricCharge too... Well, a quick&dirty workaround for it is to give some weight to the Refunding Stunt. It will fool the code I mentioned above, but it will affect your part's weight slightly - so it may affect the performance of your craft. It may even unbalance it if by some reason the counter-part on a symmetry gets a different refunding value. Shove what follows somewhere in the GameData (I suggest __LOCAL, to make it easier to locate later): @RESOURCE_DEFINITION[RefundingForKSP111x] { @density = 0.001 } But, and again, it should not be a problem - I failed to see why MAS is wasting time doing this check again and again (this thing is called on FixedUpdate, it appears) and why this should be a problem to it. Ideally @MOARdV should be reached and asked why this check is there at first place, so I can at least understand why this would be a problem.

If the warnings are being issued every time you boot KSP, you have errors on the MM patching process. TweakScale stops emitting the non fatal warnings once the MM cache is one hour old, and the MM cache only gets built when the patching process is completed. Publish your KSP.log and I will see what can be done. Patches can only be made when I know they need to be made.

you have a problem with DRM, not with (just) Steam. Buy DRM free games on Steam and you are done. The problem with GOG is that I can't easily download older versions of a game - what's on KSP is a necessity. And on Steam this is a breeze. And it's I do on Steam - only DRM free games. But I do GOG too, most of my games are bought there - but usually older games that are not updated anymore and have all eventual problems already tackled down.

Missed by a tad! Perhaps @Just Jim is around?

I could not manage to find a solution for this problem, I'm sorry. There're some limitations on CKAN that I can't work around, and the CKAN guys are satisfied with the current solution - so I can't further help on this. Any further discussions about CKAN should be redirect to CKAN thread. Cheers!

Not a problem. May I redirect future requests from users to this thread so?

If someone writes the patches for it, it will probably work. The problem is not incompatibility, it's lack of support - I didn't had time to write and test patches for the Robotics yet.

More or less... It's not a funcional problem, because Recall behaves and only activate what's needed on the host KSP version (so it doesn't even wastes CPU cycles), but some users (and I'm one of them) really hate installing things that are not needed (bloatware ). The problem is that Recall is an indirect dependency for some add'ons on some KSP versions, and this relationship is tied to the KSP version, not to the add'on only. For example: Any Add'On that customizes Resources needs Recall on KSP 1.9, but works fine on everything else Any Add'On that customizes Cost needs Recall on KSP 1.11, but works fine on everything else Some (few) Add'Ons have parts that blow up fiercely on spawning on KSP 1.10, but work fine on everything else. And it's a soft dependency - Recall works behind the scenes. You only note it is installed because the problem goes away. Installing KSP Recall on everything is an acceptable solution, but only installing when really needed would be an optimal solution (and this is whats being requested at the moment) Ugh... Well, I think this is a good time to bump the versioning for 0.2... Thanks for the heads up!

No. The complain is that Recall is needed on KSP 1.11 and 1.9 due bugs on KSP itself, but not on 1.10 - the version the user is using - where none of the bugs affects TweakScale. No. KSP Recall aims to fix or work around problems on specific KSP versions, something completely out of scope for TweakScale (that only aims to scale parts) as well any other add'on affected, as B9PS, FSFuelSwitch, Pay for Play, ODFC and the list goes on. The problem is that different KSP versions break different Add'Ons differently - so Recall may be needed when you use a set of Add'Ons on 1.9, but not on 1.10 or 1.11, while the set of add'ons that need Recall on 1.10 and 1.11 are completely different than on 1.9 (or between 1.10 and 1.11). Moreover, it's pretty dangerous to have more than one add'on trying to solve the same problem by themselves - or you will have the workaround being applied multiple times (something extremely undesirable when fixing the Refund problem on recovering vessels on KSP 1.11). All I can do (and I'm doing) is to code warnings on TweakScale prompting the user to install KSP Recall on the KSP versions TS needs it - but I can do anything about Recall being installed when TS doesn't need it (please remember that Recall may be needed by another add'on, even when TweakScale doesn't need it on that KSP Version). Yep, pretty messy. No if we have the "fallback" netkan (the current one, that would accept being installed anywhere) for new installs. The replaced-by would not solve the problem? Once a new KSP version is released, the TweakScale-for-1.11 netkan would be updated with the replaced-by pinpointing TweakScale-for-1.12 . And since both TweakScale-for-1.11 and TweakScale-for-1.12 will be tagged to work only on that expecific KSP versions (using ksp_version_strict), we would have a solution for this problem - assuming these features work as I expect.

KSP have some fixes for KSP 1.10.x too but, granted, they are not as critical as the KSP 1.11.x ones. KSP 1.9.x on the other hand has also a pretty nasty flaw affecting all add'ons that customise resources (this one affecting all game modes) and so KSP-Recall is needed by TweakScale on it. Problem is that CKAN doesn't have support for "KSP Versions specific requirements" - it's everything or nothing. However, I agree with you, you should not be forced into downloading a dependency you don't need, and I had engineered TwealScale and Recall to allow such flexibility. I'm working on a possible solution for this problem. That's the problem - on this specific use case, Recall was marked as a dependency because there was no other way to guarantee having Recall installed for KSP 1.9 and KSP 1.11, where the Recall absence would play havoc with a lot of add'ons, TweakScale one of them. There're really no need for install Recall on 1.10.x due TweakScale, the work arounds it provides are targeted at things completely unrelated to TweakScale and that will not bother a significantly portion of the user base. Had CKAN a way to choose dependencies based on the target KSP version being installed, I would be using it but since it's all of them or none of them, we had to pick up this stunt from our hats. Now with things settled up (the Refunding stunt has stuck, apparently!), I have time to consider new solutions for this problem. Let's see what we can do about. -- -- -- POST EDIT -- -- -- People interested on this problem are invited to follow this thread.

Hi, @DasSkelett, That's the thing: some people (not unsurprisingly) are complaining about the need to install KSP-Recall even by not requiring it. Since CKAN currently don't allow targeting specific versions of KSP for dependencies, how about different netkan files for the same add'on targetting them? Using TweakScale and KSP-Recall as examples, how about three different netkan files: TweakScale for 1.11.x, locked on KSP 1.11.x and requiring KSP-Recall TweakScale for 1.9.x, locked on KSP 1.9.x and requiring KSP-Recall The current TweakScale would so be the fallback option, targeting anything above 1.4.0 and only suggesting KSP-Recall (or not even that). This is feasible? Would CKAN allow such a solution?

Now I understand. Yep, you found a serious incompatibility - UbioWeld cannot be used on KSP 1.11.x...

AN-225 . Ruskies on the Kerbal way!

I just gave this a run on 1.11.2, and... Well, it worked for me. I must have a typo on the XML file or something. This is how it must look on the file: <?xml version="1.0" encoding="utf-8"?> <ModuleAttributeLists xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="KSP-Forum"> <Vector2CurveModules> <!-- Yada yada yada --> </Vector2CurveModules> <Vector4CurveModules> <!-- Yada yada yada --> </Vector4CurveModules> <SubModules> <!-- Yada yada yada --> </SubModules> <ModulesToIgnore> <!-- Yada yada yada --> <ModuleAttribute AttributeName="WeldedFlagDecal" /> <ModuleAttribute AttributeName="ModulePartVariants" /> <!-- ------ HERE!! THIS LINE!!! --> </ModulesToIgnore> <!-- Yada yada yada --> </ModuleAttributeLists> Check if the line emphasised above is inside a <ModulesToIgnore> block, check if it's correctly terminated, or if there's any other problem on it. Also keep in mind that this stunt just squash all the parts to the default variant, ignoring any current settings on the time of the welding.

There's none. The problem IS NOT some incompatibility with TweakScale. It's a bug on KSP itself that was miscalculating the funds on recovery, and this problem affects all add'ons that change cost, not only TweakScale. KSP-Recall doesn't fix any add'on, it works around these KSP problems so all add'ons that change cost can work fine on KSP 1.11.x - as they were working fine on KSP 1.10.x and previous.

@Ben J. Kerman, I remembered you on FB today! (somehow this was posted on my timeline!)

It must be some mistake, I just checked SpaceDock (where CKAN monitors the Recall releases) and the latest it's there. (I failed to correlate this to any update made in the last 5 minutes , I'm pretty sure you experienced some temporal misalignment on the spacetime fabric - please file a bug report to Albert Einstein Institution ) . Thanks for the heads up - this was a really tough week on RL™.

I think yes, but I was not sure. Until now! Consume in MODeration!!! #tumdumtss

Jesus Christ, I ended up forgetting about your report! #facePalm https://github.com/net-lisias-ksp/TweakScale/issues/92#issuecomment-804548359 I will give a peek on it this weekend! Sorry!!!

The warning is about Recall, but looking on the problem again (now that the dragon is tamed), I think I should issue the warning only on loading or creating Career saves. People using only Sandbox don't really need to install Recall, as Funds are just not an issue on it. Now I understand!!! This problem is a mishap inside KSP itself, not TweakScale related - and to tell you the true, it affects every single add'ons that changes the cost of the part somehow (fuel switches, damage or wearing, custom cargo, etc). So I didn't associated it to TweakScale itself! So, yeah - by installing KSP-Recall, the problems on recovering Funds are worked around (at least, on the use cases we could detect it - if you find something new, yell for help on KSP Recall thread being TweakScale related or not!).

Interesting. I had played Career on the 1.4.x era using TweakScale (it was how I got involved on this), and I don't remember problems on it (other than the problems I was getting everywhere, of course). We had a lot of problems on 3rd party patches, some others on TweakScale itself, we had used TweakScale to diagnose some bordeline situations inside KSP itself (as the zero ou negative mass problem) and for a lot of time my focus was hunting down these rogue patches and borderline situations and cook safety-measures to help on this task. But once the patching is successful, no misbheaviour were detected on Career. (there're some technical debts on TweakScale, of course, but they don't affect Career specifically, the misbehaviours are consistent on all game modes) What we have is a lack of support from Custom Tech Trees - TweakScale is available on Career the same way it's available on Sandbox - if you have access to a part, you can scale it at will - no restrictions applied.