Jump to content

Gotmachine

Members
  • Content Count

    288
  • Joined

  • Last visited

Community Reputation

412 Excellent

About Gotmachine

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I already explained it. There is a single line of code missing from KSP causing this refund bug, you don't need to rewrite the whole refunding code to make it work. My piece of code add that missing line where it should have been in the less intrusive way possible, and add the same UI feedback as yours by doing UI code without having to spam resources and modules all around. If you don't understand how it work, you know what you have to do, we also already had that discussion. As to why your solution is worse, the amount of issues that are popping in this thread speak for themselves.
  2. How so ? I made a small mistake that prevented the UI info from showing when the recovered sum was negative, and gave the fix a few posts earlier. My solution doesn't need to exclude anything. You are fixing issues that you created yourself.
  3. 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.
  4. My mistake. In the gist I posted, on line 99, the two "> 0.0" conditions should be "!= 0.0".
  5. Might not be that, but make sure you set the layer on every gameobject. Also, from memory, you might need layer 5, not 9.
  6. 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
  7. 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 giv
  8. 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
  9. 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
  10. 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).
  11. 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 re
  12. KSPBugReport 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 :
  13. @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
  14. 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.
  15. 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.
×
×
  • Create New...