Jump to content

Devoblue

Members
  • Posts

    19
  • Joined

  • Last visited

Posts posted by Devoblue

  1. A simple way I've done this before is have the deployable script count the KOSProcessors on boot, identify the S2 processor, and

        FOR eachModule IN SHIP:MODULESNAMED("kOSProcessor")    {
            LOCAL eachPart IS eachModule:PART.
            LOCAL tag IS eachPart:TAG.
            IF tag:STARTSWITH("mission/s2") {
                SET processorS2 TO eachModule.
            }

    }

    IF processorS2 <> 0 {

    WAIT UNTIL processorS2:PART:SHIP <> CORE:PART:SHIP.

    }

    The way that you have described involves CORE:MESSAGES - being a message queue and commands around that.  Useful if you want to invest in understanding everything around it, but more complex for your simple use case.

  2. On 4/11/2019 at 9:26 PM, Devoblue said:

    On a fresh install of 1.7.0 this mod (v2.2.2) doesn't work, but after copying the file \GameData\Trajectories\Plugin\Trajectories16.bin to Trajectories17.bin, limited testing indicates it still works fine.

    Same as before, while waiting for the 1.10 update, copy the 1.9 in place.

    Goto \GameData\Trajectories\Plugin

    Copy paste Trajectories19.bin.

    Rename the new file to Trajectories110.bin

     

  3. I agree that looks weird. Not being a Unity guy this one is perhaps beyond my expertise.  I've tried a high and low graphics settings, looked at using other shaders, I can't reproduce the disappearing cross.

    The cross being above the ground in map view is something that occurs in 1.7.3 with the released Trajectories 2.2.3, so nothing new here.

    It might be worth you doing some testing yourself.  Does changing your graphics settings fix the problem?  Does an install without any visual enhancement mods have the problem?

  4. I've created a pull request that fixes 1.8, but breaks earlier versions.  I suspect I can avoid the earlier version break.  It also fixes the ArgumentNullException

    Until that fix is merged or superseded, a work around is to install 2.2.3 and then download the 18.bin from the pull request on github and place it in GameData\Trajectories\Plugin

    https://github.com/neuoy/KSPTrajectories/blob/7c1ca247675d8bc4e649aaa63834d7f7fe9c682a/GameData/Trajectories/Plugin/Trajectories18.bin

     

  5. This is great, it wasn't exactly what I was expecting but I can see why you've done that and I can make it work.
    I need to bind Enable with Rotate Clockwise, and Disable with Stop - and then it turns out just fine.  Thankyou.

    In relation to making it better with kOS, kOS can interact with any of the events/fields/actions in the part menu.  This is all the information that we can get, so the better and clearer the information there, the easier it is to manipulate via code.  Although it is possible to read the "angle" field and parse it to guess as to what the port is doing, DockRotate would be a bit easier to manipulate in simple scripts if menu options were disabled when they don't make sense to be enabled, and the angle field was perhaps split into several fields.  For example, Stop Rotation only makes sense when the part is moving.  In continuous rotation mode, being able to see the Rotate Clockwise (+) when already rotating clockwise I think does nothing, so if it wasn't available it would be an easier indication of current state.  Take a look at a retractable solar panel for how the Status field gives useful information, Sun Exposure and Energy Flow are separate fields, and the Extend and Retract options are only available when they make sense.  If "angle" was replaced with for example "Current Angle", "Current Speed", and "Status" (Stopped|Stopping|Started|Starting) it would be simpler.  That said, none of this stops me doing what I want with Dock Rotate presently.

  6.  

    I have a brief kOS script that watches the craft throttle and changes the rotation speed of the rotors so that the rotor speed is effectively controlled by throttle.  This works fine for simple craft.

    But, now I have a more complex craft that has other engines, I want to be able to action group the on off so I can be throttling engines, or throttling rotors, or both.

    I could work around this by toggling the rotors through an action group via kOS.  This is not elegant as it means the generic rotate-by-throttle script now needs to be action group aware for the specific craft.

  7. Is it possible to toggle Rotation enabled/disabled via action group?

     

    Perhaps I should elaborate.  If I several parts that are rotating through an action group, I want to stop the rotation of some of those parts but continue to have the remaining parts respond to action groups.

    So If I disable rotation on a part that is rotating, I'd like it to come to a stop and not respond to further actions that rotate it until it is enabled again.

  8. I'm trying to make use of CraftTemplate:FILEPATH but I get suffix not found?  I hadn't tried using it before.  Is this a new problem related to the latest release?

    For my test vessel "aaa 3.1" which is in "aaa 3_1.craft" and also for "aaa" which is "aaa.craft"

    This works:

    PRINT KUNIVERSE:GETCRAFT(SHIP:NAME, KUNIVERSE:ORIGINEDITOR).

    This doesn't:

    PRINT KUNIVERSE:GETCRAFT(SHIP:NAME, KUNIVERSE:ORIGINEDITOR):FILEPATH.

    In any event, I was just looking for an escaped name to save a log file as, so don't need the whole path.

  9. Thanks for your work on this. Much appreciated.

    The first thing I noticed with this was that my ascent script progressively turned ksp to glue, slowing down the simulation so much that phys warp 3 was approximately real time by the time I was a minute into flight.  I guessed that this was because I was locking steering and throttle every pass through a loop, so I optimised these and performance went back to expected.  This was a gradual process of slowing down so I wonder if there is some loss or inefficiency in LOCK that worsens over time.

     

     

  10. The body lift on tanks has completely disappeared too.  It's not just space plane parts.  A 1m rocket that I used to be able to glide back to launch pad and steer (slightly, but enough) by tilting now makes no changes to its trajectory.  I can turn it sideways and it slows down to 60 m/s, but this makes no change to where it was going to land.  It lands where the boost back burn leaves it.

    There was no mention of this in the changelog.  I can only assume it was not intentional.

    Otherwise great update, but sticking with 1.4.5 now until this is fixed or I redesign my rockets to use the stock gridfins

×
×
  • Create New...