Jump to content

Dunbaratu

Members
  • Content Count

    3,845
  • Joined

  • Last visited

Posts posted by Dunbaratu

  1. "Why" as in "What is the mechanical difference in how the game implements them?" or "Why" as in "What was the reason for choosing the implementation that has this limitation"?

    I can answer the first, but the second is harder as that requires dev insider knowledge.

    The mechanical difference is that Gilly, being a moon, is modeled as a kind of CelestialBody, while asteroids are a type of Vessel, much like flags are a type of Vessel and Kerbals floating in their EVA suits are a type of Vessel.

    The game does not calculate the effects of a vessel pulling on another vessel due to gravity, since most of the time a vessel's mass is so small that the effect isn't worth the computing time it would take to bother. Also, when you go into time-warp mode, the game doesn't *really* use Newtonian gravity from a celestial body to pull on the ship anymore, it instead just uses Kepler's ellipse formulas to decide where along the orbit path the vessel would be at time=t.  To do that in the stock game model requires that the body you are orbiting be your sphere of influence center point.

    So that answers the first kind of "why".  As to the second kind of "why", now I have to speculate about what was in the dev's heads.  But I'll do that.  I just want to throw the caveat that at this point I'm trying to read their minds and this is not definitive:    So here goes: To do gravity with asteroids using the stock system, those asteroids would all have to be modeled as tiny planets with their own little spheres of influence.  The sphere of influence model really breaks down at that point, as you have to be SUPER close to the asteroid before it's gravity is strong enough to treat it like its own little pocket reference frame that ignores perturbations from the sun.  I suspect they didn't bother because it's an organizational mess to have that many asteroids being modeled as planetary bodies instead of as vessels, especially when for the smaller ones their spheres of influence wouldn't even be above their ground altitude.  Imagine if it treated them as planets what the map view would look like with all those little orbit lines.  I think before it becomes even possible to do it well, the game would first have to leave behind the sphere of influence model and use an N-body model like Principia mod does.  And a change like that is *massive* and breaks some other parts of how the game is meant to be simple for players.

  2.  

    On 4/2/2021 at 3:42 PM, Dunbaratu said:

    I don't know yet why the torque values being reported are clearly weird, and I'll have to examine that in detail, but for the time being this seems to really help with that design, as a workaround:

    set steeringmanager:pitchtorquefactor to 0.25.
    set steeringmanager:yawtorquefactor to 0.25.
    set steeringmanager:rolltorquefactor to 0.25.

     

    @garwel I had some time today to look at the problem and I think I know what's wrong.  I don't know how to fix it yet, but I know the cause of the problem.

    The problem also occurs in stock, not just restock, BUT  it is slightly exacerbated by restock.

    But what *is* relevant is that the problem is caused by changes in KSP 1.11.x versus KSP 1.10.x.  It was correct before KSP 1.11.0.  Specifically it did this:

    1. KSP RCS part modules have an array of all the rcs thruster transforms (position plus orientation) for the part.  i.e. the one-nozzle RCS thruster has just one thrust transform for the one nozzle, but the 4-way block has 4 thrust directions one for each nozzle.
    2. kOS calculated the torque capability of the RCS part by iterating over these thruster directions and summing up the torque they can give based on where they are relative to center of mass
    3. KSP 1.11 introduced the new feature that RCS parts have variants.  For example you can use the version of RCS block that angles the nozzles slightly out, or the variant that has them straight.
    4. To implement the variants in KSP 1.11, the superset of *all* possible nozzles across all variants are defined in the array mentioned in bullet point (1) above.  Presumably there exists a place where it's specified which of them are actually present.
    5. kOS didn't "know" about this change  so it was still assuming all the rcs nozzle definitions in the array are all present at once.  So it was calculating torque as if all the nozzles for variants other than the current variant will be thrusting too, and thus getting values much too high.
    6. It's a bit worse with Restock because it apparently defined more variants.  (There are 9 variant nozzle positions in KSP 1.11 stock RCS 4-way blocks, and 18 variant positions in restock RCS 4-way blocks).

    The fix will have to involve me finding out where in KSP it defines which of the variant rcsTransforms are the ones currently actually existing in the part, and ignoring the ones for other variants.

  3. 9 hours ago, John007qwe said:

    I'm getting a bunch of errors in the ksp.log

    
    [EXC 15:22:26.836] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
    Parameter name: index
    	System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
    	System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
    	kOS.Screen.Interpreter.IsWaitingForCommand () (at <3ccb18ebae2a49929054690a1a176760>:0)
    	kOS.Screen.TermWindow.ProcessUnconsumedInput () (at <3ccb18ebae2a49929054690a1a176760>:0)
    	kOS.Screen.TermWindow.Update () (at <3ccb18ebae2a49929054690a1a176760>:0)
    	UnityEngine.DebugLogHandler:LogException(Exception, Object)
    	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

    Log: https://www.dropbox.com/s/cgysg9a20jdxzug/KSP.log?dl=0

    This seems to be only happening during scene setup, and only with people who have lots of mods.  Once scene setup is done the messages stop.  I don't know the cause but it is harmless at the moment.  It seems kOS is being told to start running FixedUpdate() before the scene is done being set up, so kOS hasn't initialized everything yet. It may be a race condition that only occurs when there's a lot of mods so scene setup takes longer than normal.

  4. 13 hours ago, garwel said:

    Sorry about that. I haven't played KSP for a few months, so I forgot it got updated meanwhile.

    Okay I had a look at this today.  First I started by recreating your vessel in pure stock without Restock, to see if Restock was doing anything funny to it.  I got the same thing in pure stock that you were getting.

    Also, you didn't tell me the reason it was taking 40 seconds was because it overshot the setpoint and kept oscillating back and forth across it.  That's relevant.  The picture I had in my head was that it was taking 40 seconds to turn agonizingly slowly toward the target, not a mere 3  seconds plus another 37 seconds wavering around before settling down.  That's a very different kind of problem, generally caused by kOS thinking there's way more torque available than there really is.  (So it thinks it can stop in an instant when it can't.)

    I don't know yet why the torque values being reported are clearly weird, and I'll have to examine that in detail, but for the time being this seems to really help with that design, as a workaround:

    set steeringmanager:pitchtorquefactor to 0.25.
    set steeringmanager:yawtorquefactor to 0.25.
    set steeringmanager:rolltorquefactor to 0.25.

    This tells kOS "pretend the vessel's torque capability is only 1/4 as big as it's being reported to be, and act accordingly."

    How I know the values are bogus - the R1-IX thruster should be doing 0.1 kN of thrust.  In any one rotation axis the best case is having 4 of them helping push that rotation (i.e. pitch by having two at the bottom push one way and two at the top push the other way).  The entire vessel is only about 5 meters long, so if we assume a Center of Mass halfway between one end and the other, that's a torque of 4 * 0.1kN * 2.5m or about 1Kn*m.

    But the torque it was *claiming* was about 2.5to 3 Kn*m.  So something is probably wrong with the kOS TorqueProvider replacement code, and I'll have to look into that.  But that's a long term thing.  In the mean time, try the 3 lines above (put them somewhere temporary you can remove later if a future release of kOS fixes this).

     

  5. On 3/31/2021 at 2:59 AM, garwel said:

    You can test it out yourself with this save I've made: https://mega.nz/file/eyJ2mBIY#iblUThD75r7nQX98JbwNurpCRT0RUX11uQU_OAjhPrY

    Mods used: kOS (v1.3.2), ReStock, ReStock+, Module Manager. KSP 1.11.1.

    I had a brief window of time to test this today but this information wasn't true.  The save file is for KSP 1.11.2, not 1.11.1 so I have to re-download a fresh copy to perform the test on KSP 1.11.2, and that means I'll try tomorrow.  (I barely had an open window of time today and having to prep a different install of the game with the right mods etc pushes me over the time limit.)

  6. 17 hours ago, garwel said:

    It's me again, and I'm going to talk about the same issue: latest version of kOS' handling of RCS.

    I've done some testing with a simple vessel with RCS controls and no reaction wheels. With weak RCS (I used 8 ReStock's 0.1-strong RV-1X thrusters), stock SAS turns the sample vessel into the desired position in 6-7 seconds using just 1 unit of monoprop. kOS with cooked control takes about 40 s and 3.5 units of monoprop for the same maneuver.

    If you install stronger RCS (8 RV-105 thrusters, 1 kN each), things get even worse. Stock SAS works just as quickly and just spends a bit more RCS fuel. kOS, however, never really managed to completely stabilize and spent at least a minute and 15 units of monopropellant to at least get close to the desired direction.

    You can test it out yourself with this save I've made: https://mega.nz/file/eyJ2mBIY#iblUThD75r7nQX98JbwNurpCRT0RUX11uQU_OAjhPrY

    Mods used: kOS (v1.3.2), ReStock, ReStock+, Module Manager. KSP 1.11.1. Vessel R1-105 uses strong RCS thrusters, vessel R1-1X uses weak ones. I tested by setting SAS to prograde and by using script that did "LOCK STEERING TO PROGRADE." (and a wait loop).

    I am pretty certain things didn't look so bad in the older version of kOS steering. I used it extensively and the only problem I had was too small corrections when near the desired direction (and IIRC these mostly happened when the vessel was in the atmosphere). So far, my attempts to play with PID parameters haven't brought any good results.

    Is it a bug or WAD? Is there a way to revert to the old system?

    I don't see this when I try it in stock so I'm going to have to try your exact mods and your exact save to see if I can reproduce it.  I'll try that tomorrow.

  7. 8 hours ago, JebIsDeadBaby said:

    Dang, you're right on the money. Your trick does work. 

    That makes me wonder if it would be worth it to have kOS spend a few clock cycles copying the vectors it receives into a normalized form when doing LOOKDIRUP() and VANG().  With VCRS() and VDOT() the magnitude is relevant so it can't do it there, but for LOOKDIRUP and VANG the magnitudes don't matter.  (VXCL() could do it to the first argument (the normal vector of the plane being projected onto) but not the second.)

  8. 3 hours ago, JebIsDeadBaby said:

    I dunno if I'm again having trouble understanding frames of reference but can someone explain to me why do I get results like on this picture:

    Clipboard01.jpg

    I want to get a direction pointing along body's rotation axis with up direction set to the Solar Prime Vector. I use BODY:ANGULARVEL to get the direction of the axis. As you can see both Kerbin and Mun return some proper vector. However I get very different results when plugging both vectors to LOOKDIRUP, while they should be almost identical. 

    The vessel is in Mun's SOI in this case and I use JSNQ. 

    That is really strange.

    Can you try this experiment: normalize the m and k vectors into unit vectors first, before you pass them into LOOKDIRUP().  Is the mun one still zero if you do that?

    LOOKDIRUP() is letting Unity do the heavy lifting under the hood, and a lot of Unity's stuff only uses 32-bit floats.  It might be that the mun angular velocity is just too small to survive  the floating point error in the underlying Unity call.  As a rule of thumb, if you are doing an operation where you don't really care about the magnitude of your vectors, only their aim, then getting your vectors normalized before passing them through operations like lookdirup, vcrs, vdot, vang, etc, can help with precision. 

    (Sometimes even when you *do* care about magnitude, you can make things more precise by first memorizing the vector's original magnitude, then normalizing it and running it through the vector operator, then multiplying the result by a scalar afterward to restore the proper magnitude.)

  9. On 3/16/2021 at 10:19 PM, Krauzer said:

    It's been a long time since the 1.11 update, but I ran into a problem. I accepted the contract to attach the part to the satellite and it was not credited to me. None of the 2 points. Although the engineer was on board and successfully attached the part. Maybe I did something wrong, but I didn't find any information about how to fulfill this contract anywhere, so I think it's a bug.

    The new contracts introduced in KSP 1.11 were quite bugged.  They keep consistently having contract parameters with weird wrong values for the ID number of the parts and vessels you are supposed to repair, so that when you repair them it doesn't recognize that as being the correct vessel that went with the contract.  Here's 3 issues in the bug tracker about them:
     

    https://bugs.kerbalspaceprogram.com/issues/27308

    https://bugs.kerbalspaceprogram.com/issues/27203

    https://bugs.kerbalspaceprogram.com/issues/27020

    It would be entirely justified to pull open the Alt-F12 menu and cheat the contract as "finished", since it's literally impossible to finish them with the ID mismatches they have.  (Alternatively you could risk trying to edit your save file to make the ID numbers match so the contract becomes possible.)

  10. 6 hours ago, Stone Blue said:

    Also, it seems a user wont know this stream of exceptions is even happening when launching craft, unless they have on screen logging enanled, or come across it when troubleshooting or digging into other issues, as game behaviour can seem normal, otherwise.

    I get this with every single kOS part.

    If anyone else would like to try to confirm, they can see them right after launch, by opening the Alt-F12 menu, or just enable on-screen log messages using it. Just chec the "Show all log errors onscreen" & "Show all log exceptions on screen" boxes.

    Thanks for the information.  I'm taking further conversation to the github issue about it.

  11. 6 hours ago, JebIsDeadBaby said:

    Hi, 

    why KERBIN:VELOCITY:ORBIT = V(0,0,0)? If thought it should return orbital velocity of Kerbin around it's parent body, which is the Sun. 

    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 " + (kerbin:velocity:orbit - sun:velocity:orbit):mag + "meters per second.".

     

  12. 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 complaint (which it is safe to ignore) in the logs on
    KSP 1.10.x when it sees the new "ModuleCargoPart" section in the config files.

  13. 6 hours ago, Emilienj said:

    Hello,

    Firstly thanks for this beautiful mod. 
    i want to know if is it possible to have the same function as the function « at » does for « print » but for the function Hudtext ? If yes how can i do this ?

    thanks 

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

     

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

    4 hours ago, stephm said:

    I trained to access the "kOSProcessor" module, but on the other hand when I look at the doc KOS there is 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.

     

  15. 6 hours ago, JebIsDeadBaby said:

    Hello again.

    while docking two ships I get CTD with no error messages about one second after successful connection . These are the last entries in the log:

    
    [LOG 17:08:55.939] 2/4/2021 5:08:55 PM,kOS-IRWrapper,Attempting to Grab IR Types...
    [LOG 17:08:55.952] [FAR v0.16.0.1]: Updating vessel voxel for Space Station-2
    [LOG 17:08:56.360] [FAR v0.16.0.1]: Voxel Element CrossSection Area: 0.00980822366822485
    Std dev for smoothing: 3 voxel total vol: 167.724347110611 filled vol: 32.2048617377845

    If I remove FAR the last entry is kOS, I just wanted to show that kOS is not the last mod trying  to do something on this newly merged ship. I can't remove kOS for further testing as there are kOS cores on merging ships. So I just want to ask you if in your opinion, whatever kOS is trying to do here, may be a cause for CTD? 

    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 ... nothing happening and no error messages explaining why so.... I just gave up.  Meaning, I have a hard time proving anything about a crash that won't show any messages in the logs.  Also look at KSP.log, as it may be more low level than player.log and might say something more.

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

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

  18. 23 hours ago, garwel said:

    I removed the MandatoryRCS DLL, but I still have the oscillation. I think the problem arises when you have no or very weak reaction wheels: kOS can't stabilize the vessel only using RCS and the engine. Strangely, it worked reasonably well in the past (although sometimes it used too much monoprop for preventing roll).

    I noticed that it gets better when I manually turn off RCS about halfway between towards the target orientation at every oscillation. Then I manage to reduce the amplitude and have the (more or less) needed orientation. So my idea is that the PID just keeps firing RCS thrusters for too long. It may cause any issues when you have strong reaction wheels, because they'll eventually stabilize the craft, but with weaker (and more realistic) RW, you are doomed to have this endless swinging.

    I'm not very good with PID settings, so I'm wondering if this is something that can be addressed in scripts (other than using more stronger reaction wheels).

    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 testing, and I need to find out what it is.

  19. 4 hours ago, klh1228 said:

    Hey all - No idea how this happened but every time my game saves now, I am getting a console error:

    https://1drv.ms/u/s!AnWBehSzp6LgmBrGGMzccURNQjt-?e=VEDXYB

    The game seems to be saved OK, but the message appearing constantly is pretty distracting.  I've tried various things, including uninstalling and reinstalling the KOS mod, to try to get it to go away, but with no luck.  I can't figure out what the root cause (no pun intended) might be.

    Any ideas on how to track this down, and eliminate it?    Thanks!

    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)

  20. 43 minutes ago, dok_377 said:

    This one somehow didn't get a fix. I wonder if NAN and infinite orbits after the satellite separation are still a thing. Probably is. No point in updating then, it still has some critical bugs. 

    Oh, and by the way, please fix your bugtracker. I can't even update my own bugs anymore. 

    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.

  21. 1 hour ago, Gotmachine said:

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

    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 wheels' behavior, kOS isn't seeing it when it queries them.

    I also turned on a feature in kOS that has the steeringmanager dump a lot of stats on the terminal screen while it steers (set steeringmanager:SHOWSTEERINGSTATS to true.)  Using this I was able to prove that if I use a stock install without MandatoryRCS, and suppress the reaction wheels myself with the stock toggle button on the PAW, kOS is capable of steering with the RCS alone just fine, and the stats on screen correctly reflect that the reaction wheel torque is missing from the sum of all torque, with just the torque the RCS supplies remaining.  But when using MandatoryRCS, and *it* suppresses the reaction wheels, that same stat shows the full stock value, even though when steering manually with WASD keys instead of with kOS, I can't make the vessel turn at all when RCS is off and I'm relying on the reaction wheel alone (conclusion, the reaction wheel actually provides zero torque, as one would expect MandatoryRCS to be doing, but the query kOS sees is still claiming it's working at full stock magnitude and is not disabled.)

    (The reason a false reporting of how much torque the wheel is capable of providing causes kOS to steer all wrong is that kOS is predicting how many seconds it would take to stop rotating from this information.  When the value is reported higher than it really is, kOS thinks the vessel is capable of stopping rotation quickly when it really isn't, so it keeps overshooting the target facing.)|

    I should say that older versions of kOS *did* have the problem you mention where it was bad at steering with RCS alone.  But the latest version is much better at it (because it now rolls its own GetPotentialTorque() like all the other autopilot mods had to resort to doing because the stock one is all wrong when it comes to RCS thrusters).  With older versions, what you say would have been true (that even without MandatoryRCS, the kOS mod is just bad in general at steering by RCS alone), but with the latest release it's not anymore.  Now it's only got problems when it's MandatoryRCS that's disabling the reaction wheel instead of doing so through stock means.

    I should also point out that the user who reported this to me was installing MandatoryRCS on a KSP 1.11 install even though MandatoryRCS is only *advertised* as being good up to KSP 1.8, so perhaps that has something to do with it?  I don't know.

    Do you know of anything I could query from kOS's side  to discover whatever it is that MandatoryRCS does to suppress reaction wheels so I can report the proper number to myself when querying the torque?  Our Torque calculation for reaction wheels is this: https://github.com/KSP-KOS/KOS/blob/d308fae5a92eaf834013fbfaf8259f4889fc9aab/src/kOS/Control/SteeringManager.cs#L733

×
×
  • Create New...