Gotmachine

Just a reminder that I gave you the easy (and side effect free) solution two weeks ago, and warned you that what you are currently doing is a hacky mess.

My mistake. In the gist I posted, on line 99, the two "> 0.0" conditions should be "!= 0.0".

Might not be that, but make sure you set the layer on every gameobject. Also, from memory, you might need layer 5, not 9.

There it is, a better solution, "now", that took me 2 hours to make and doesn't have any performance impact (contrary to your solution) nor unpredictable side effects : https://gist.github.com/gotmachine/bb8f840eb36809a9f74b626eb8ccbfbb Here is the dll download for testing : https://oshi.at/Lfimhc

Yes they will. ProtoPartSnapshot.moduleCosts is recomputed every time the craft is unloaded. It is how recovery costs were computed pre 1.11. And nothing has changed on that side, the KSP 1.11 issue is because when refactoring the recovery code to account for recovery costs of parts stored in inventories, Squad just forgot to apply it. That's my point. Your are reinventing the wheel for nothing. Stock already does it correctly, the result is readily available for you to use in ProtoPartSnapshot.moduleCosts. That's my other point. Your solution is intrusive and messy. I've given you a code stub on github that fixes the issue in a much more cleaner way and that doesn't rely on any reverse engineering or reflection use, I don't know why you keep insisting on that. Your solution has much more potential for side issues and unwanted interactions. If that where true, nobody would be able to mod anything. That rule is silly. We have almost zero documentation on what the KSP publicly available classes and members are doing. Doesn't matter how you do it. Be it by analyzing and experimenting, or by decompiling the KSP assembly, in the end the act is the same : you are figuring out the KSP code inner working, which is an act of reverse engineering. This being said, this rule exists for valid legal technicalities, we all understand that, and can be smart about it and do whatever we need to in private to make great mods for our beloved KSP.

This is quite questionable, as are you other points. I understand perfectly that you already have a working solution and that you don't have the time to revisit it. Still : You are spamming a partmodule on every part in the game for (I assume) getting modules costs and converting that into your "recovery" resource. Module costs are already saved in protoPartSnapshot.moduleCosts, you don't need to do that. You are spamming a resource on every part in the game for refunding. You only need to do a Funding.Instance.AddFunds() from the the proper gameevent. Adding a custom widget to the recovery dialog is also not that hard. If you want to use the resource trick instead (which can be justified if you don't want to dig into how to add a custom widget to the recovery UI), you can simply add it to the root part from GameEvents. OnVesselRecovered() instead of having it on every part. These solutions don't involve any reflection use (which, BTW, is forbidden by the rules you are talking about), would be much cleaner and don't involve spamming resources and modules on all parts, which has a small but still present performance impact.

This is a really ugly hack. See a proposition for a better solution here : https://github.com/net-lisias-ksp/KSP-Recall/issues/12#issuecomment-803686490

That plugin is useless in the case of a hard crash, anyway. And I have serious doubts that there is a single extra line in Player.log vs KSP.log. KSP.log is just an extra callback for the default Unity log handler. The only extra stuff in Player.log are the stacktraces, which are discarded for the "Log", "Assert" and "Warning" logging levels in KSP.log (but not for the "Error" and "Exception" levels).

Because contrary to KSP.log, that folder is never cleared, so it can (and will) become huge and full of irrelevant logs from mods that might not even be installed anymore. Also, Kopernicus has the bad taste to dump a ton of stuff in there (including a copy of the KSP.log and modulemanager.configcache, etc) and also generate a zip containing those in there, that's why I only get the body configs dumps from Logs\Kopernicus, not the whole folder. I really don't understand why modders feel the need to do some separate logging. I find it counterproductive, as it is critical IMO to be able to replace a log entry in the execution flow of everything else. KSP.log has the timestamps, the [ERR, [EXC, [WRN prefixes, is much more readable and has the stacktraces on errors/exceptions. Does a stacktrace on a random log entry really help debug anything ? If you need a stacktrace for your debugging needs, I personally use the following helper method : [Conditional("DEBUG")] public static void LogDebugStack(string message) { System.Diagnostics.StackTrace stackTrace = new System.Diagnostics.StackTrace(); UnityEngine.Debug.Log(message + "\n" + stackTrace.ToString()); } Anyway, the issue is that player.log is often huge (100mb+ compressed player.log aren't that uncommon), which is a problem for being able to share those reports.

KSPBugReport Issue and bug reporting plugin for KSP players This small plugin adds a "bug report" menu to the KSP debug menu (opened with ALT+F12). That menu provide a way for players to create a zipped bug report containing the KSP logs and game database dumps usually needed by mod authors when they need to troubleshot bugs and issues. It also include an option to automatically upload the bug report to an online file sharing service. Dowload and installation Compatible with KSP 1.8+ KSPBugReport is available on CKAN (recommended) For manual installation : Go to the GitHub release page and download the file named KSPBugReport_x.x.x_KSP1.8+.zip Open the downloaded *.zip archive Copy the KSPBugReport folder found in the archive into the GameData folder of your KSP installation. How to use Try to reproduce your issue or bug, in order for KSP to log information about what happened. Press ALT+F12 In the Bug Report section, click on Create report. This will create a zip archive on your desktop. You can open the location of that zip file in your file explorer by clicking on Open report folder. If you want to add screenshots to your report, open/position what you want to show and click on Add screenshot to last report. The debug menu window won't appear on the screenshot. You can add multiple screenshots. To upload the report to a file sharing service, click on Upload last report. Once uploaded, the download link to your report will be copied to the clipboard and you can paste it elsewhere (forum post, github, discord...). In case you loose the copied link, you can copy it to the clipboard again by clicking on Copy last upload link to clipboard. Disclaimer This plugin will upload information about your computer specs, your KSP install and your current game on the internet, on public file sharing services. The KSP logs don't contain any sensitive information. However, be aware that : The KSP.log file contain the path to your KSP install, which can contain the user name for your computer (for example C:\Users\MyUserName\...\KSP\). This is usually not a security issue, but if you want to avoid that, move your KSP folder to another path (for example C:\Games\KSP\). The KSP.log file contain everything that is logged by your mods/plugins. An ill-intentioned mod author can potentially access any file on your computer and dump sensitive information in the KSP logs. Your savegame is included in the report, with everything that you can write and save in KSP (vessel names and descriptions for example) Notes : Bug reports will contain : The KSP.log file The modulemanager.configcache file, or if not found a Configs.txt file generated from the live game database A *.sfs savegame generated from the currently loaded game (if any) The Logs\Kopernicus body configs dumps (if present) Available upload services : Primary : https://oshi.at (90 days retention, unlimited downloads) Secondary : https://0x0.st (30 days minimum retention, max 1 year depending on file size, unlimited downloads) Tertiary : https://file.io (14 days retention, file deleted after the first download) Zip compression is done through the System.IO.Compression mono library as provided in the Unity 2019.2.2f1 editor download in Editor\Data\MonoBleedingEdge\lib\mono\4.5 License MIT

@Beetlecat There is indeed an issue when Kerbalism + CrewR&R are installed. This happen when the root part is both crewable and crewed. I opened a detailed issue here : https://github.com/linuxgurugamer/CrewRandR/issues/14 I doubt that the issue is caused by Kerbalism directly, my guess is that it is revealed by Kerbalism querying crew information on the part, causing CrewR&R to somehow enter a state where it reset the root part crew every frame. A workaround is to re-root your vessel to a non-crewable part, or simply to remove the assigned kerbals in the crewed root part.

You technically can do it, but radiation, stress and failures will quickly get in the way. ISRU is limited to "realistic" options, so apart from a few specific places, you won't escape resupply missions . Kerbalism isn't very well balanced for the "space colonization" gameplay style and the experience is a bit frustrating IMO, but there are people enjoying it.

Okay... Well, the only real answer I can give is that MandatoryRCS was never made to behave correctly when a non-stock attitude controller is used. Reading the code you linked and re-checking the MandatoryRCS code, I fail to understand how the stock non-nerfed stock could be returned by your method while having the actual torque being consistently different. The RW torque is set in a single atomic operation, so the only way that could happen if is MandatoryRCS is applying full torque in a step, then zero in the next one, and so on. Which could maybe be triggered in case vessel.Autopilot.Enabled is also flickering. Well, as I said, I more or less stopped maintaining that plugin actively a long time ago. It might indeed be broken is some way in recent KSP versions.

@garwel@Dunbaratu In the posted chain of events, there is no step 5 : the stock RW torque is never restored. Therefore, the worst that can happen from the kOS POV is that it, in case the torque doesn't stay constant, the available torque that kOS uses for it's attitude control PID will be the one from the previous step. With MandatoryRCS, this mainly happen if the stock SAS is active. From what I understand (am I wrong ?), kOS rely on it's own attitude controller and disable the stock SAS. So I have some doubts that there is actually any torque change happening while kOS has the attitude control in its hands. However, what will definitely happen is that while kOS is in control, the RW torque will be locked in the very heavily nerfed one, essentially providing next to no effect. From some experimentation I did a while ago, I remember that most KSP attitude PID controllers (stock, kOS, mechjeb...) have a very hard time achieving stability with only RCS. The PID parameters are often quite aggressive and that doesn't play well with RCS, which are always at least slightly unbalanced, which is especially an issue when the RCS available torque is high. Which would explain why reducing artificially the PID aggressiveness by forcing it to see only 10% available torque get ride of the oscillation issue. Easy way to test that : disable the RW nerf in MandatoryRCS settings, reload the craft, set all the craft RWs torque to zero through the stock PAW slider : does the craft also has trouble stabilizing ? All this being said, as a general rule, MandatoryRCS doesn't play well with non-stock attitude controllers (kOS, MechJeb, TCA...), as the whole nerf is made to work in conjunction with the stock SAS state. This has always been a major issue. And TBH, that plugin is in zero effort maintenance mode, and I have a very low motivation to work on it. If I were to decide to work on it again, I would likely rewrite it from scratch (the overall code quality is... poor). I have a few ideas that would make it work a bit differently, and would allow much better compatibility with other mods.

Because the convention in the modding scene is that "LiquidFuel" is not hydrogen. The density doesn't match, the ISP and general engine stats don't match. It's much closer to kerosene or methane, and consequently the ISRU options are those of methane. Hydrogen is widely used in major mods as a distinct fuel, with corresponding engines and fuel tanks. You can do ISRU in Kerbalism to produce hydrogen that you can use in those engines. If everything could produce LF, there would be no point in having somewhat realistic ISRU chains instead of the basic stock Ore -> LiquidFuel conversion. That's a known issue. In general (not only for storms), radiation exposure is inconsistent depending on the timewarp rate. That cannot be fixed easily and likely won't be fixed anytime soon. You can have breakdowns at any stress level. You can change that in the difficulty settings.

So, just to be clear, as the OP seems to imply, the plugin read a pre-computed dataset for a specific body and duration (1 year / 5 years), right ? So what happens when the duration of the data is elapsed ? It cycle back to the beginning ? Also, you mention specific data at the KSC launchsites. What does that mean ? What is the difference between places that have this (more precise, I assume) data, and those that don't ? Regarding performance, took the liberty of quickly profiling this (1.0.2 lite version, ~50 parts ship in atmo) : You're consuming about ~0.25 ms per update, which is a bit high for something that just read a bunch of data, but acceptable in the grand scheme of things (the whole game update has a theoretical 20ms budget) Maybe you could avoid the ~0.10 ms of WxUnityGui.FixedUpdate() when the UI isn't shown ? Also, that same method seem to be quite part-count dependent (getting ~0.30ms with a 150 part ship) However, you're allocating 6.4 KB every frame in KerbalWxClimo.FixedUpdate(), which I see very little justification for. While GC pressure isn't as much an issue as it was before KSP 1.8, avoiding allocations is still very recommended. Finally, maybe there is some justification but I'm still seeing a significant usage when in space with the UI closed : same CPU usage for WxUnityGui, about half the CPU usage / allocations for KerbalWxClimo Side note 1, I get a bunch of errors/exceptions in the main menu, when creating a new game : Side note 2, OnGUI errors when clicking some of the main UI buttons (FLIGHT/WIND, etc) :

Far from it. The code that handle comms was rewritten nearly from scratch for Kerbalism 4 The commit you linked was a quick and dirty fix in the middle of that rewrite, after that I rewrote the RemoteTech support entirely (it was either that, or dropping it altogether). It should be possible to backport the new 4.x comms implementation to 3.x, but even assuming you know you way around C# code, this isn't a trivial task. Those aren't minor, and the 3.x support code is borked in many ways (and TBH, the whole 3.x comms implementation is an ugly mess). That's why I rewrote it from scratch. Also note that while I tested that new code a bit, it hasn't been extensively playtested (so it is likely to have bugs), and there is also a complete lack of support configs for correctly balancing the RT antennas data rates (like what we have for stock CommNet). If you don't know programming / C#, there is way too much for you to learn before you can do that by yourself... This is quite a lot more complex than making a KSP config file. Plans, yes. Time and motivation, no, unfortunately.

The orbital survey data is a bit misleading in that it doesn't account for the atmospheric density, which mean that in reality you get 0.06 % of 12% -> 0.72%. Also note that this definition comes from CRP, not Kerbalism, and that the CRP abundance is generic for all atmospheric bodies, and can vary from 0.1 to 50%. IRL, Mars atmospheric water content is more in the ballpark of 0.02%. Regardless, last time I checked, the consensus on atmospheric water extraction on Mars (aka Duna) is that while it is theoretically feasible, it would be extremely inefficient. To get any meaningful amounts of water you would have to use huge electric powered compressors, and even then the quantities extracted would make this viable only for small scale applications like compensating a closed loop ECLSS losses. This being said, some of the other IRSU options we have are as questionable from a realism standpoint, so maybe it would make sense to have that one. However, even if we do, like some other options, this will be so inefficient and limited that you likely wouldn't be able to use it for anything else than ECLSS needs. Given that we have a recurrent issue of people thinking they can refuel their ships like in stock just because those inefficient and small scale processes exists, I'm a bit reluctant to add more of them. For example, see the recent discussion in this thread about the molten regolith process. As far as I can tell this is something that people often get frustrated about. We should probably better advertise that the ISRU options are based on what is possible IRL, that large scale offworld operations are quite challenging and that you won't be able to build massive refueling bases like in stock.

Which, like the content of your other posts, tell me that your making zero effort in searching for answers before spamming this thread. I don't really care and I have nothing against you, but don't expect me to make an effort answering you. And yes, the documentation and the mod aren't perfect. Far from it. This isn't a product, this is a very time-consuming hobby contributed by whoever has the courage or skill to help and share their work for free. We value people giving feedback and are usually open to discussion and accept contributions if they wish to help, but as I said, this thread isn't the preferred communication channel.

1. Most of your questions have answers on the github wiki. 2. Personally, I don't check that forum often and I don't think regular Kerbalism users come here often either. If you want to chat about Kerbalism, the Kerbalism Discord server is much more appropriate. Regarding you comments on the automation triggers, see https://github.com/Kerbalism/Kerbalism/issues/638 and https://github.com/Kerbalism/Kerbalism/issues/643

Not 100% sure. They might work in the latest version as a side effect of the B9PS support I added for NFS. Pretty sure they won't work in previous Kerbalism versions. If someone is willing to test if the EC production rate is consistent in the planner / in flight / in the background, we could get a definitive answer.

There are exceptions depending on what parts you are scaling, but as a general rule Kerbalism is not very compatible with Tweakscale. The habitat module is incompatible, and almost all modules we have some background processing for won't account for the tweakscaled values. The core issue is quite fundamental and while we could partially fix it for some modules, it would require a lot of effort. Moreover, our current development path will make support outright impossible in the future. This being said, we should probably have a support patch that remove the Tweakscale module from all parts that have an incompatible Kerbalism module. This way, end users would still be able to use it for other parts (structural, tanks, etc...) while preventing the (not very obvious) issues.

Try keeping "Kerbin". If I remember right, with Kopernicus, the home body internal name is always Kerbin.

You assume wrong. We consider ore to be generic regolith (because it is available everywhere). The carbon content of regolith is usually ridiculously low. Less than 100 ppm on the moon. There are potential localized source of carbon rich minerals on mars, but we simply ignore that. Also, while there are some studies that estimate a small energy efficiency advantage (with the whole system considered: ISP, storage requirements, etc) at doing methane instead of hydrogen for propellant production from regolith, both paths are too energy and infrastructure intensive for any kind of large scale operation. IRL, the main expected application of the MRE process is oxygen (and metal) production. In fact, if we wanted to be more rigorous, it shouldn't have a CO2 output at all. The only realistic fuel production options are hydrogen electrolysis from direct sources of water (water ice) or methane production from atmospheric CO2 + some hydrogen, also produced from water ice. Those are the only viable paths IRL, and the ones we provide in Kerbalism. It's difficult because it simply isn't made or balanced for that, on a variety of levels. There is no large scale parts fit for the purpose. As you already noticed, making 500+ parts vessels doesn't work well. Also, mixing life support and other EC demanding processes on the same vessel won't end well, especially if you are relying on solar power. You're free to do as you wish, I'm just warning you that what you are trying to use the mod for is basically unsupported and known to be a bad experience.

And Kerbalism explicitly re-balance that. How realistic our numbers are will always be debatable. The point is have an order of magnitude that result in relatively realistic possibilities with current technologies. I'm not sure what you are arguing for exactly. Our premise is that regolith is basically useless for any meaningful propellant production without industrial scale operations. If not due to power requirements, for the mass/volume of the equipment that would would be required to process it in those quantities. The molten regolith process is balanced as something that you can use for producing LS resources in situ (oxygen and carbon for the greenhouses). Again,the numbers are debatable, but they are in the ballpark given by various real world studies. Again, if your goal is to make large scale off-world operations, Kerbalism isn't the right mod for that. Kerbalism is aimed at reproducing the current space challenges, with the current technologies, at the current operational scales. While there are some provisions for going a bit beyond that, the mod doesn't really allow that in practice. If you try anyway, you're just bound for a frustrating experience. The simple fact that you are new to the mod and planning a 12 kerbals Jool mission tell me that you haven't even tried to do a single long term manned mission, let alone an interplanetary one. The planner numbers are ideal conditions. Things will go wrong, trust me.