Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Dunbaratu

  1. Unfortunately the web server that github provides for gh-pages only really serves up the most recent version of the html, and doesn't have a means to automatically let you select an older version. But, you CAN get access to an older commit of the HTML files copied locally onto your own computer, and have your browser render the local HTML files using a local file:/// url. First you have to be set up to be able to clone github repos (and that's a long topic in itself, but the information is freely available online for how to do that). If you are set up to be able to clone git repos, and
  2. Reading through the MandatoryRCS code on github, it appears that its nerfing of reaction wheels is done in a way that is problematic for other mods that also have an OnFlyByWire() pass like kOS. I say this because the order of events seems to be this: 1 - In its Update(), kOS queries the sum of all torque capability provided by all parts (RCS, reaction wheel, engine gimbal, etc). 2 - In its OnFlyByWire(), kOS uses that value to choose how it should set the pitch/yaw/roll controls. 3 - In its OnFlyByWire(), MandatoryRCS nerfs the reaction wheel capability now that it's too late fo
  3. I can give you access to a compiled kOS.DLL to test with to see if it fixes the problem. Send me a DM and I'll send it your way. If you report it fixes it I'll get the change into the next release. The issue is that kOS added an additional parameter to a method that kOSPropMonitor is trying to call, and although kOS did make sure the additional parameter is optional with a default defined for backward compatibility, in C# that still requires a recompile of anyone calling it because of how default parameters in C# work. The experiment to see if it fixes it is that instead of one method
  4. @JonnyOThan - I have a user giving a github issue on kOS that I think you might be better qualified to answer, as it's about kOSPropMonitor, which I know nothing about: https://github.com/KSP-KOS/KOS/issues/2861
  5. Never mind. It did work. I just was running the wrong version of my dll. (forgot I had it set to compile in Release mode not Debug mode, so I was copying the wrong DLL file.) Thanks for the info.
  6. I tried that and it literally had no effect. I also threw in setting bypassEffects to true and also ignoreListenerVolume to see if they made any difference and they don't either. The sound is still a lot quieter in vacuum than it is in atmosphere.
  7. Addendum - I can't DM you on Discord easily since I had no prev contact with you and you aren't in any servers I'm in. Instead I sent you the Discord link as a direct message here on the Kerbal Forums. Go check your user page to see it.
  8. I'm not sure. Discord has some differences between the web client and the desktop client.
  9. I'm having a hard time recreating what you're talking about here. I put Realfuels-stock and Mandatory RCS on, and while it puffs a bit much (because the stock RV-105 RCS blocks are a bit overpowered for such a small ship as in your example description), it doesn't look nearly as bad as what you're describing, and it settles in pretty quickly. Also, I don't even have an option to adjust the reaction wheels in the Mk1 pod because there aren't any there. With these two mods installed it seems to remove ModuleReactionWheel from the MK1 pod entirely, so "with reaction wheels enabled" isn't e
  10. My strong suspicion is Mandatory RCS is the culprit, but I'll be checking tomorrow to be sure and seeing if there's anything I can do about it. The change in kOS that might be responsible is this: This standard API call provided by KSP here was utterly broken and has been for years: https://kerbalspaceprogram.com/api/interface_i_torque_provider.html The value returned by KSP in that method in the case of RCS modules is totally random nonsense and some modders have known this for a while but I didn't. But kOS was depending on that information to tune the steering, and that's why kOS s
  11. Minor patch update available: v1.3.2.0: https://github.com/KSP-KOS/KOS/releases/tag/v1.3.2.0 A quick patch to v1.3.0.0 that fixes issue #2857 that would zero controls for just a brief single physics frame if raw control neutralize had been previously used or if a reboot had occurred while raw controls were in use. Most players won't notice a single physics frame of zeroed controls, but if you're using realism mods with limited engine ignitions, it would unfairly consume an engine ignition when the throttle zeroed for an instant. (Which was a disaster if the engine onl
  12. Not enough information to tell, but if it's RP-1 is there a chance the decoupling makes you lose an avionics part and now you are over the avionics limit and so it's refusing to obey controls?
  13. I maintain the kOS mod. I recently installed Rocket Sound Enhancement and discovered that it dampens kOS's sounds just like it dampens rocket sounds. (If you're not familiar, the sounds in question are meant to be UI sounds on a text terminal, like beeps and raspberries. The "computer" is a PartModule inside a Part on the vessel, and Rocket Sound Enhancements appears to be using that to decide its sounds are a physical sound effect in need of dampening.) Do you have any suggestions for what I can do to set up the kOS sounds differently so Rocket Sound Enhancement doesn't dampen them?
  14. Depends on the original program. if you have a long variable name and use it again and again, it can be crunched a lot. if you have short names, or if you don't indent much, or you do have long names but don't repeat them much, you don't see much help.
  15. This is my official request to rename my forum account to "Dunbaratu". Reason: I made my account in these forums long before I started doing things for the kOS mod including a youtube channel, twitch channel, guthub account, and discord server. For those other places I decided to go with a pseudonym so as not to directly "dox" myself (I mean, yes, you can do some digging around and figure it out but I didn't want it to be easy low-hanging fruit for zero effort). My chosen pseudonym for all of these other places has consistently been the name "dunbaratu", and that is the name people are mo
  16. kOS v1.3.1.0 official announcement (See First Post in this thread for links to download it.) There's a lot of small changes over the last year that have added up to a big release. This release supports KSP 1.10 and KSP 1.11. It has no specific KSP 1.11 changes but it has been tested and it does work with KSP 1.11. (NOTE ABOUT KSP 1.11 - If you want to put a kOS part into one of the new cargo inventory slots that came with KSP 1.11, you can do so but remember to FIRST attach it to the vessel in the VAB/SPH so you can adjust the disk space and boot file settings, then detach
  17. There is a new kOS that fixes this on the Github page. I won't put it on Curse or SpaceDock until it's been on Github for a day or two, just to be sure people have tried it and not complained about a major problem before I do that. (When I do that, I'll also update the first post of this thread and make it official. But until then you can try it and report any problems.)
  18. The "soft" release yesterday has a bug related to using TimeSpan in a few places where it should be using TimeStamp. Expect another update today or tomorrow.
  19. For the sake of modders, one thing I hope KSP changes about the UI/UX is to have a much stronger wall of separation between what is UI code and what is API code. So the UI's only job is to talk to the API that really enforces the rules, rather than the UI code itself doing it. I've run across frustrations in the past modding for KSP 1 where I've had to re-implement KSP's main rules again in my own code (which is an awful and not future-proofed at all way to do it) because when you talk to the API directly and don't click on UI windows, you are skipping parts of the rules that are done by the
  20. What makes this bug in the new contracts dangerous to players (and worth pointing it out here) is that it has a very large negative penalty for expiration, and none of the other contracts do this thing with a duration being too short for using the next Hohmann transfer window. People won't be in the habit of expecting to have to read the duration to see if an excpetional weird transfer is needed because literally none of the other contracts before now required doing that. It's the complacency of knowing up until now the durations have always "just worked" and never been a problem that causes
  21. The difference is that when taking multiple contracts to accomplish in one mission I'm going to launch but haven't yet, as I usually do, one of them can be "send science from" along with the others. That is not true for these new ones. Which is exactly the situation here. I was going to Duna to do 3 things in one mission: Retrieve Duna Stone, Plant a Flag, and Add a solar panel to a satellite. The two normal contracts did not expire on the way there. The new satellite repair contract did (with a very large negative "fail" value that overwhelmed any gain from the other two and killed the c
  22. While technically correct, literally no other contracts in the game expect the player to look at the duration to check if it might not let you do a vanilla Hohmann transfer in time. Thus my post here warning people. If you don't realize ahead of time that these contracts have buggy durations, you won't be in the habit of even looking at the duration ahead of time. It becomes "impossible" because you didn't even see that the duration is abnormal until quite a bit of time later after you've been time warping too much now to do it. If you don't like savescumming, that really blows to have the
  23. It's not similar. With the "send science data from..." contracts, the duration is clearly designed to let you do them with a fresh launch waiting for the next Hohmann transfer. You *can* do them faster and cheaper if you already have something there, or if you spend extra deltaV on a faster but less efficient trajectory for a new launch, but those things are not *necessary* like they are with these 1.11.0 contracts. There's clearly a major bug here. And yes it is worth warning people of this since none of the other contracts work that way and this one is an odd exception to the rule. The
  24. This post is to just let the other players know about this so they don't get burned by it in their career like I did. The only way the new repair/edit vessel contracts for distant destinations like Jool or Duna are do-able is if you saw the contract get offered while you coincidentally were already there for some other reason with a crew vessel that can do the contract. The new contracts don't seem to be varying their duration depending on destination like most contracts do. They're always exactly 2 years, fixed, no matter what. This is not enough time to launch a new vessel to go there fo
  • Create New...