Lisias

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...

I made the mistake of opening this link, now I'm with this music on my head the whole day. I warned you.

The first time ZeroMiniAVC runs, KSP still halts because by the time ZeroMiniAVC manages to get rid of the oldies, they were already loaded. Restart KSP and see what happens. If even by that your rig still halts, publish the new KSP.log again and I will check what happened.

It's exactly how to proceed, thanks! (there's a link somewhere on Forum about this, but I forgot to mention it) Your log is huge, something is borking on a loop on your rig. Usually it's an older version of MiniAVC, and you have it borking on your rig: [EXC 10:17:36.517] UnauthorizedAccessException: Access to the path "C:\Program Files (x86)\Kerbal Space Program stock\MiniAVC.log" is denied. System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.IO.FileOptions options, System.String msgPath, System.Boolean bFromProxy, System.Boolean useLongPath, System.Boolean checkHost) (at <ad04dee02e7e4a85a1 There's 56.525 occurences of it on the file. Fortunately, things are way less scary than it appears. Install ZeroMiniAVC and things should be fine: On a side note, if you don't use CKAN, you may be interested on this thing (it helps to keep your installment updated): Cheers!

Hi, Fellow... ClueLess?... Kerbonaut! I need your KSP.log file, and since it's MM related, all the MM logs too. Zip KSP.log (on the same place where you will find KSP.exe) and everything inside the Logs folder on the same place and send it to me. This will help me to locate the point of failure and then try to reproduce it here to see what's happening. I'm without time for exploratory tests these days due Real Life™ obligations, so I can't spare the time to do too much testings.

That's rule out Refunding being the problem by colateral effect. Without being patched into a part, there's no way for Refunding to be screwing your FPS. Good catch. You know what? Appears to be the already known M.O. of failing to initialise things from KSP. It was what was blowing up some older things on 1.11, ChillingPut just shoved some zeros for some frames on some key values of a module at launch, and that fixed the problem. Oh well, let's see where is the problem so - on the PBC or in Stock. Scrap that, PBC has no C# source code, there's no way it could be a problem on its source code. :) So, we are facing something smelly on Stock. Why this is happening when installing Recall is beyound me, but the problem is there nevertheless. So lets' attack the Main.cfg file to see what we get. This file has the following top level components: @Contracts { <yada yada yada yada> } CONTRACT_CONFIGURATOR { <yada yada yada yada> } AGENT { <yada yada yada yada> } CONTRACT_GROUP { <yada yada yada yada> } This test is destructive, so don't do it on savegames you care about. What you need to do is to delete one section of that file, one by one, and then try to reproduce the problem: Remove the @Contracts section. Fire up KSP, try again Remove the CONTRACT_CONFIGURATION section. ditto AGENT CONTRACT_GROUP On the very instant the problem vanishes, we will know exactly what is the trigger - and so we can try to look for similar things on Stock trying to find what's different nowadays and then adjust PBC to do the same. But, on a side note, I'm still concerned about the mere presence of the Recall's DLLs being able to trigger this. The Helpers won't work without spamming the KSP.log (on DebugMode), and the only piece of code I found that could guzzle your CPU without spamming the log just don't works without being installed inside a PART. Anyway, baby steps. #houseMd

This one is slightly different, Recall was loaded on SPACECENTER scene as expected: [LOG 16:34:11.035] [HighLogic]: =========================== Scene Change : From MAINMENU to SPACECENTER (Async) ===================== [LOG 16:34:11.293] [UIMasterController]: HideUI [LOG 16:34:11.940] [AddonLoader]: Instantiating addon 'CustomConfigsManager' from assembly 'ModuleManager' [LOG 16:34:11.941] [AddonLoader]: Instantiating addon 'SpaceCentreHelper' from assembly 'Refunding' [LOG 16:34:11.942] [KSP-Recall-Refunding-FlightHelper] TRACE: Awake on SPACECENTER <yada yada yada> [LOG 16:34:33.738] [HighLogic]: =========================== Scene Change : From SPACECENTER to MAINMENU (Async) ===================== [LOG 16:34:33.785] Game Unpaused! [LOG 16:34:33.950] [KSP-Recall-Refunding-FlightHelper] TRACE: OnDestroy But no exception or any other signal of life, it was motionless the whole "yada yada yada" phase. Nothing, Refunding remained silent, it was not invoked one single time. However... I finally found something that MAY be causing some trouble, but I need one more test to be sure: Shove this on your KSP's GameData instead of that other one: @PART[*]:FINAL { -MODULE[Attached],* { } -MODULE[ChillingOut],* { } -MODULE[Driftless],* { } -MODULE[Refunding],* { } -MODULE[Resourceful],* { } } This will remove Recall from everything after MM has applied them. Try to reproduce the problem with this patch. It it solves the problem, then I have a good idea about what could be happening and can try a fix for you.

Yes, it makes. I forgot to add the "@" on the patch when I hit "Save". I fixed the patch, it's working now - sorry for that. Please use the edited patch on my previous post (it have the "@" before the PART, and an "?" before the S1).

It's not that hard most of the time. Read this and this for a Crash Test Course.

Still didn't found anything, sorry. You entered and exited the savegame twice, as it appears, but I found no evidence of Recall doing something - no surprise, as you didn't used the DebugMode one... [LOG 13:11:12.460] [KSP_Recall] Version 0.1.0.8 /L running on KSP 1.11.2 But yet, aside the absence of Recall's log entries (and from exceptions from MiniAVC), I found no significant differences between your log and my last one. No exceptions, no strange warnings, nothing. So, whatever is happening on your rig, appears to be "just" code dry running when it should be inactive instead of burning your CPU cycles. No significant difference was found, sorry. Since on R&D scene (SPACECENTRE as it appears) none of the Helpers are even loaded, it's not something triggered by an event for sure. So, the only way in which I can see `Refunding` screwing up your fps is by something constantly OnStarting and OnDestroying parts all the time, as this is where Refunding do some computing. Even the FixedUpdate is guarded against improper use, as this handler actively disables the module when called (and so, it's called only once - unless someone activate the module, something I do only when strictly needed - I really give the FPS impact a lot of thought...) I appreciate your efforts on reporting the problem, you are giving to it some serious work - but I couldn't reproduce the problem on my rig. Other than the timings, the "M.O." of Recall on your log with the DebugMode is pretty similar to mine, so no obvious mistakes (if any at all). But, yet, you provided concrete and unquestionable evidences about the problem - so it exists for sure. I'm a bit baffled on this one... Well, let's try something out of the box. You also stablished where things stop to happen, the RobotArmScanner.S1 part. Let's remove any traces of Recall on this specific part and see what happens. At this time, I'm completely out of ideas, so with some luck this test will render something that could give me some light about what could be happening. Shove this somewhere on your GameData (I like to put these on GameData/__LOCAL - easy to find later to delete the stunt): @PART[RobotArmScanner?S1]:FINAL { -MODULE[Attached],* { } -MODULE[ChillingOut],* { } -MODULE[Driftless],* { } -MODULE[Refunding],* { } -MODULE[Resourceful],* { } } This patch will eliminate any possible patch possibly applied by Recall on the part you detect is "fixing" the fps. Let's see how your FPS will behave now while executing your Test Case. Let me know the results.