Lisias

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.

Unlikely. FSBuoyancy implements it's own buoyancy logic and removes the part.partBuoyancy thingy, and so TweakScale can't scale it as it is not found at runtime (but it still can happen on Editor time - something to investigate about). public void FixedUpdate() { if (!HighLogic.LoadedSceneIsFlight) return; if (vessel.mainBody.ocean && part.GetComponent<Rigidbody>() != null) { if (part.partBuoyancy != null) { Destroy(part.partBuoyancy); // <-------- HERE!!!! --------- } Source. But since your Add'On is a set of configs, of course RationalHydroDynamics is only the screaming victim of something else's bork. In time, anyone using TweakScale and Firespitter should install TweakScale Companion for Firespitter - as Buoyancy is only handled with it now. Cheers!

Did you see any Exceptions or misbehaviours while playing it? If you find something, let me know. Until the moment, there're no known problems on TweakScale while playing Career or Science - other than allowing you to scale things beyound reasonably limits. If you are concerned about spoiling a Career or Science save, let me know - the latest TweakScale has features to selectively (and safely) deactivating Support for arbitrary parts, without compromising existing savegames and crafts.

Double patching. Something is shoving TweakScale twice on this part. Check the @FruitGoosehint first, if you installed manually, completely remove the TweakScale folder and reinstall it (assuming you already hadn't did that). If this doesn't works, publish the KSP.log and the MMPatch.log (you will find this one on <KSP_Root>/Logs) so I can inspect it and check where is the double patcher.

That will not help so much, as the Unity's Physic Engine is monolithic and mono-threaded, so it will be as much a bottleneck in KSP2 as it's on KSP 1 nowadays. I had read about multithreaded physics engines, and I think I kinda found a way to... simulate... something like that on a mono-threaded physics engine - so perhaps the KSP2 guys can find something similar (but that works! ). On the other hand, just by removing business logic from the Turing Damned UI Thread will be a huge relief, believe-me - things are already ugly by themselves, we don't need to make them worse by screwing up the UI thread.

Apparently yes. Not every log entry is an error, some of them are just informative to be used in the case something weird happens later. I use and abuse this thing on Recall and also on TweakScale, but I have a advantage - I can shove everything on a Debug conditional, and then only distribute the debugging code as needed (essentially what I did recently on Recall). KSP cannot do that, so they need to allow that informative thingy to go on Release. There's yet a new problem to cope with. Unity's GUI system was a (bully) joke on the 3, 4 and 5 times. I remember getting some really older version of UBioWerding with a full reimplementation of a Event System for UIs (pretty similar to what we used to use on Windows 3 times), but that code was long deactivated. Peskying people around, I was told that KSP implemented the UI by using the Update as "clock tick" and doing things as we used to do on DOS (mouse GUI on DOS were very allergic to multitasking!!!), and this horribly overloads the FPS too. On my machine, when the machine gets overload and the FPS goes down, clicking and dragging things is a pain in the SAS - the action now and then are only detected 1 or 2 seconds after I click the mouse button. If you use the GUI events to trigger code, and that code is run inside the event... Boy, you have a problem. I know of code (and not only on KSP, this is happening everywhere!) doing I/O on Mouse Clicks (or Touch) Events, by Turing's Sake! It's probably the reason why my Android programs are borking all the time when the data is moved into the SD Card. In a way or another, since Unity 2017 multithreading is way more feasible than before, so you are right on this: there're a lot of opportunities for optimisation on KSP for sure.

Interesting.... If my memory serves me well, it will maximize your contract achievements. You will get all the milestones as fulfilled (First Launch, Tower Buzz, etc). If I'm right, we may had found what the trigger is triggering... We must start to consider the hypothesis that this may not be exactly a "bug", but a feature implemented without optimisation (assuming it would be possible to optimise the fature, obviously). A non functional enhancement, if you like. Apparently, something on the TechTree is constantly looking for achievements (IIRC, some achievements would give you in advance some parts you didn't researched yet on Tech-Tree, so I think the Tech-Tree code is constantly rescanning the Achievements looking for them). Perhaps this constant rescanning (assuming my guess sticks) is a self-defense measure for add'ons that change the TechTree or the Contracts at runtime? Yep, I found these ones too on my KSP.log. -- -- -- STOP THE PRESS ! I THINK I REPRODUCED IT!!! -- -- -- I started a new Career Game, then cheated me a lot of Science, then researched things as follows: Start (already researched) Engineering 101 Survivabilty Basic Science Space Exploration On this point, I was not being able to do more research because my facilites were not up to the task. So I cheated me a lot of funds and upgraded the R&D one level. When I came back to R&D, my FPS raised from ~14 to ~15.3 on my MiniCrap. It's about 9% increase on the fps (your videos shows a FPS increase of 23 to 30% more or less). Checking your first video again, I noticed that you had upgrade the R&D first then executed the test. Why changing the point in which you upgrade the R&D affects where the fps impact happens I don't have the slightest clue, but it supports my current thesis of being just some code (over)loading the critical path of the frame. On a blind guess, perhaps using FixedUpdate instead of Update would be a good enough workaround for this problem? There's no simulation happening at this point, I'm pretty sure we can drop the checkings per second count to 2 or 3 (and, again, assuming I'm right o my guess above).

It's a wild guess, and I'm not being able to reproduce the issue here is not helping - but I think we have some missing initialisation somewhere on KSP, and it ends up fixed by "accident" when you unlock the RobotArmScanner.S1 on the Tech Tree. Apparently you need a beefy machine in order to reproduce this in a perceptible way. I managed to get ~15 fps on my MiniCrap by deactivating VSync and AntiAlias, but the it dropped to 13.35 once I upgraded the facilities to be able to research Advanced Exploration, where the RobotArmScanner.S1 is... Why this was triggered by the mere presence of the Recall DLLs (even by not being patched anywhere...) is something that only the KSP developers can answer (at least, without someone breaking some rules). I'm afraid I can't be of much more help anymore - with this thing happening without the need for Recall running at all, and without access to KSP source code guts, all we can do is keeping guessing in the hope something yells by being hit. I think we have one more test o be done before trying to find a way to report the thing on KSP's bug track (where it will probably be forgotten, but anyway...). Remove the file GameData/SquadExpansion/Serenity/Contracts/contracts.cfg . Since the robotic arm is part of the Breaking Ground DLC, perhaps the problem is on this DLC's contracts. Of course, by removing Breaking Ground at all the issue should be "solved" too, as the whole thing is going to disappear from your rig, Or perhaps not? It may worth a shot to check if by removing Breaking Ground the issue "moves" to another place (i.e., the FPS still goes down, and it's only fixed by unlocking something else...). Again, not being able to reproduce the thing on my rig is not helping too much, as this is something I could had tried myself easily...