Jump to content

Dunbaratu

Members
  • Content Count

    3,832
  • Joined

  • Last visited

Community Reputation

896 Excellent

3 Followers

About Dunbaratu

  • Rank
    Capsule Communicator

Recent Profile Visitors

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

  1. Well, it sort of does... but ... the reference frame SHIP:RAW that all the velocities are returned in is the reference frame the main game uses, which is centered around the active vessel's current Sphere of Influence body. In other words, if you are currently orbiting Kerbin, then you are getting Kerbin's velocity relative to itself, which is why it's zero. If you want its velocity relative to the Sun, you can just not care what's the reference frame it's using and just explicitly subtract one velocity vector from the other, like so: print "Kerbin is orbiting The Sun at " + (ker
  2. LaserDist v1.4.0 for KSP 1.10x. and KSP 1.11.x The only real change here is compiling against KSP 1.10.x DLLs and support for putting LaserDist parts inside the new KSP inventory system. The parts are defined to have a very small volume, in keeping with other very small parts in Stock that are about the same size. The KSP 1.11.x updates added an EVA inventory system for parts and they require parts have a new "ModuleCargoPart" section added to its Part.cfg files to use it. This release also works on the previous KSP version, KSP 1.10.x too, but it may cause a startup comp
  3. Go to the github page and see the "releases" link. It should have older versions there.
  4. Not automatically, but you could write your own wrapper function that does something like this: function warn_message { parameter text, col, row. hudtext(text, 5, 2, 20, white, false). print text at (col, row). }
  5. I can't comment about the MFD, as I don't use Rasterprop monitor, and the kOSPropMonitor mod is done by someone else. But I can answer this: kOSProcessor is the type returned by the bound variable CORE. So for example: print "The core is currently " + CORE:MODE. print "The core's boot filename is currently " + CORE:BOOTFILENAME.
  6. I can't imagine how it could be. exceptions thrown in kOS tend to get caught and just ruin kOS, not the whole game. And even if they're not, the stock game itself tends to catch exceptions mods throw, in general. But it's impossible to prove where it crashed without a post-mortem crash file to load into a debugger, and try as I might i have *never ever* gotten debugging to work right with KSP. (As in, trying to look at the kOS code in the Visual Studio debugger.) There were some instructions how modders can attach the debugger to a running process of KSP, but following them led to ... not
  7. While probably not related (since your thread spans several days you probably already did this by now) I found that in 1.11.0 (haven't tried 1.11.1 yet) all rover repair contracts required me to save and reload from the save before the rover would be controllable. Switching to the tracking center and back again would also fix it. Basically the scene had to be reloaded somehow to break out of the bug.
  8. I wonder if it would be helpful, as a mandatory field in the bug tracker, to make people have to tell you *both* the KSP version they're playing on now *and* the KSP version their campaign started with. Some bugs may require going through the version upgrade path to exist, and don't exist on games newly created from scratch. Such bugs would be impossible for the devs to re-create (and thus impossible to solve) if the reporting user never mentioned the crucial fact that it happened on a game that spanned a version update.
  9. You have a zillion mods installed, if I remember. Can you reproduce the problem on a stock install with just kOS and no other mods? It would make it a heck of a lot easier for me to look at. I spent a heck of a long time with people who using all kinds of realism settings and play in RO/RP-1 to get the new steering to work for the case of heavy ships that only have RCS for rotation and they've reported much improvement over the old steering. You're the only one who said it got worse than it was before. There's got to be something different about your test case from what I was test
  10. Since it's talking about plugin configuration in XML format it's probably talking about having trouble loading this file: GameData/kOS/Plugins/PluginData/kOS/config.xml That file contains your global kOS settings that are not savegame-specific (mostly the stuff you see in the toolbar panel for kOS). There might be something corrupt in that file. Have a look at it. If you can't figure it out you might be able to just wipe that file with a new copy taken from the kOS ZIP file (it will lose your kOS settings but you should be able to put them back like you had them after that)
  11. That might be my fault, indirectly. I complained about how a spambot was able to deface someone's issue (not just append a comment or make a new issue, but actually wipe out and replace someone else's existing issue report with an ad.) This turned out to be because ALL users had permission to edit ALL other user's issues, so any rando account a spambot makes could do it too. It seems they might have "fixed" it by making so that now NO users have permission to edit ANY issues, even their own.
  12. Dangit I had a long reply but lost it because of the forum's editor. (It pulled focus out of the text area for some odd reason, changing the meaning of backspace to the browser's default "prev browser page" meaning instead of the textarea's "remove a letter" meaning.... grrr.) Anyway, the gist of it is this - regardless of WHY, the fact is that when kOS queries the reaction wheels for what torque they are able to provide, the answer they get back is the stock value, and this is at the core of why kOS is steering all wrong in this case. Whatever MandatoryRCS is doing to change the reaction
  13. 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
  14. 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
  15. 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
×
×
  • Create New...