Jump to content

Skystorm

Members
  • Posts

    129
  • Joined

  • Last visited

Posts posted by Skystorm

  1. There are a couple of mods you could use to do this.

    Kerbal Attachment System would allow you to connect two vessels and transfer fuel, resources, and crew using a pipe.  You can add the connectors to existing ships while on EVA easily then link them together.  Additionally, with Kerbal Inventory System it allows you to do quite a bit more including replacing, adding, and removing parts in-situ, and more.

    Kebal Inventory System allows you to dynamically attach connectors for linking ships while on EVA.  This will allow you to attach the connectors to existing ships so that you don't need to add them before launch.

    EVA Resource Transfer is a simpler, more limited mod that just allows simple transfers of resources between vessels.  If you just want simple fuel transfer then this may be the one to try.  Note that the mod page has multiple small "modlets" so you will have to scroll down a bit to see it.

    I have used and can recommend both of these mods.

  2. @blowfish I believe I have tracked down a nasty little bug in v1.4.0.  I've had some problems with parts exploding instantly the moment I placed them on the launchpad.  It seems there was a bug introduced in the following commit related to managing crash tolerance, except that you are accidentally setting maxTemp instead.  Additionally, it appears that the same problem may exist for skinMaxTemp just above it.

    Github Commit: https://github.com/blowfishpro/B9PartSwitch/commit/717d81dcf48c66559adf2aa96816535ae97af85a

    Look at lines 492 - 495 (shown below) in method UpdatePartParams() of file ModuleB9PartSwitch.cs:

    if (CrashToleranceManaged)
    {
        part.maxTemp = (CurrentSubtype.crashTolerance > 0f) ? CurrentSubtype.crashTolerance : part.GetPrefab().crashTolerance;
    }

    I'm figuring this should say "part.crashTolerance = " instead of "part.maxTemp = ".

  3. @tater I must say I was a little surprised by the following statement you made.

    2 hours ago, tater said:

    Sorry, but if the current unity version is incompatible with landing a spacecraft (I don't ever use aircraft/spaceplanes, but for those people it sounds worse than my legged landers), then 1.1.2 should be "pre-release" and not released until that is fixed.

    I've made several planes since 1.1.2, one of which is a 2 crew, 12 passenger, SSTO shuttle that runs tourists up into orbit for lots of cash and reputation.  I'm not even sure how many times I've taken off and landed this plane, but I know it is in the dozens, and I have never had a crash or other problem with the plane or its wheels.

    I do think that the wheels seem to need a bit more stiffness and damping, but they work fine for me just adjusting the values to the maximum using the existing sliders.  I think the wheel configuration could also do with accepting a wider range of values for stiffness and damping.

    The exception for me seems to be the smallest gear, in particular the nose gear (I think its the LY-01), which seems to always veer off the runway for me no matter how I configure it.

  4. @NathanKell The biggest differences I've noticed regarding orbits between 1.0.x and 1.1.x are the following:

    1. Orbital "wobble" vs. "decay":  In 1.0.5 I would see the orbit "wobble" where the AP would go either up or down slowly and the PE would always go the opposite direction.  Periodically AP and PE would reverse their directions always remaining opposite one another, and the orbit would always remain basically the same.  However, in 1.1.2 both the AP and PE seems to always be decaying for the active vessel and eventually cause the vessel to de-orbit.
    2. The rate of the decay in 1.1.2 seems larger than the rate of wobble in 1.0.5 but that's just my opinion.  If there is any wobble in 1.1.x then I would have to say I agree with you that wobble in 1.1.x seems greatly reduced now compared to 1.0.x.
    3. I have only ever noticed orbital wobble (1.0.x) or decay (1.1.x) for the active vessel in either version and never for a vessel on rails or in time warp.

    I recently had a newly built ship (not imported from an older version) in about a 73km circular equatorial orbit around Kerbin.  I left it in a stable orbit and went to watch some TV and within about 30 - 45 minutes I heard the sounds of re-entry heating.  The ship had decayed completely out of orbit and was down to nearly 40km altitude in what would have been no more than 1 - 2 orbits.

    The crew survived though; I caught it in time.  I hope this helps.

  5. Speaking of resource transfers, you can also use the EVA Resource Transfer mod without needing to dock the vessels.

    Kind of works like a KAS pipe but more limited and without the docking aspect.

  6. Now that I think about it, I've become pretty religious about doing a few things to just about every craft.

    1. KAS/KIS Supplies - I generally add the following in varying quanities to every craft.
      • 1x Electric Screwdriver per crew member
      • 1 KIS Manual
      • 10x Connectors
      • 10x Struts
      • 1x EVA Propellant per crew member
      • (Optional) 5x Explosives
      • (Optionally) Some extra parts, winches, antennas, lights, etc
    2. Standardized usage of action groups.
      • Custom1 - Main Engine: On/Off
      • Custom2 - Main Engine: Switch Mode (Used for dual mode engines like the CR-7 Rapier)
      • Custom3 - Secondary Engine: On/Off (Typically used for VTOL operations)
      • Custom4 - Solar Panels: Extend/Retract (Or just extend for fixed ones)
      • Custom5 - Decrease Flap Deflection (Flaps Up)
      • Custom6 - Increase Flap Deflection (Flaps Down)
      • Custom7 - Airbrakes
      • Custom8 - Unused
      • Custom9 - Specialized Lightning: On/Off (Such as docking port or cargo bay interior/exterior lighting)
      • Custom10 - Aircraft Navigation Lighting: On/Off (Red & Green Beacons, Plus 1 - 2 White Strobes)
    3. Shuttles almost always have an array of OX-STAT-XL panels on the top surface of the main wings.
    4. Shuttles generally at least have a small probe core hidden in the tail boom to grant full SAS even to non-pilots.
    5. Science experiments usually are arranged around the hatch or ladder to require minimum effort to reach them.
    6. I do a full flight control check before I take off in any aircraft/shuttle.  Prevented quite a few issues this way, particularly with something in the editor breaking my action groups.
  7. @Ilya I notice that you are also at nearly Mach 1 (~300 m/s) by the time you hit 6km, and that is probably quite a bit faster than you should be going at that altitude.  I would suggest you stay under 250 m/s until you are at least over 10km and keep your starting TWR around 1.25 - 1.50 instead of  the 3.0 I saw in the video.

    From my experience, the more akward or draggy the vessel is the more important it becomes to keep your velocity from climbing too high until you get up into the thinner atmosphere.

  8. @regex I'm not sure what you are spending on day 59 for Duna because the first low deltaV transfer I remember is around day 223 for about 1,610 m/s of deltaV.  How much deltaV are you spending on day 59 for that?  Seems like you are way off the optimal transfer window ... unless you are talking about Earth time instead of Kerbin time.

    The very first transfer window in game that I recall is for Moho around day 40, but that is fairly early very expensive in terms of deltaV for a new career game.  Plus it has no atmosphere so it has a high insertion deltaV and no aerobraking possible.  It can be done though, and I did it once, but it leaves very little time to prepare a crew and ships for the transfer.

    I don't recall a low deltaV transfer for Eve until after Duna sometime in early year 2.

  9. @awsumindyman I think perhaps you missed a few tidbits in the original blog post.  You may not need to build your own DSN on the easiest difficulty levels, but you probably will on the harder modes.  Plus they have said that it will be configurable in the settings.

    Quote

    Another area we’ve made more approachable is the default implementation of a built-in deep space network, where Kerbin has an ever-increasing inferred relay network, similar to what we have on Earth. The range of this network will be decreased if the player is on ‘Hard’ mode, effectively requiring the player to set up their own deep space network. On ‘Easy’ mode, relay, and antennas operate as they do today, with your only limitation being the power constraints and packet size of the antennas themselves. Furthermore, the settings will be exposed in the difficulty settings so they can be toggled in Custom Difficulty.

    The emphasis above is mine.  Here is a link to the original article for your reading pleasure.

    Daily Kerbal Bonus Article: Development Relay

  10. @Nich What do you mean when you say that you cannot set when the fuel cell turns on?  I haven't noticed that this is broken.  You should be able to alter the FillAmount on the ModuleResourceConverter module to change the threshold.

    One thing I have noticed in the past though is that FillAmount seems to only work relative to the fuel cell's charge percentage and not the vessel's overall charge.  The default value for FillAmount is 0.95 which means 95%.

    Here is an example module manager file to update FillAmount for the regular fuel cell:

    @PART[FuelCell]
    {
      @MODULE[ModuleResourceConverter]:HAS[#ConverterName[Fuel?Cell]]
      {
        @FillAmount = 0.25
      }
    }

    I personally change FillAmount to 0.25 (25%) so that my satellites will use their battery first instead of draining fuel every time they go around the dark side of the planet they are orbiting.  I only want the fuel cells to kick in if the stored charge drops too far.

    Is this what you are looking for?

  11. Interestingly, there are still many issues and yet the code builds just fine.  It seems many of the old references still exist but they no longer function.  Here are a few items that needed to be updated.

    TimeWardDecorator.cs

    Remove the following lines:

                // Put the draw function to the DrawQueue
                RenderingManager.AddToPostDrawQueue(0, Draw);

     

    RTCore.cs

    Add a call to TimeWarpDecorator.Draw() at the start of the OnGUI() method in RTCore.cs:

            public void OnGUI()
            {
                TimeWarpDecorator.Draw();

                GUI.depth = 0;
                .
                .
            }
     

    ActionGroupCommand.cs

    Update the reference to Staging with StageManager on the following line:

    Staging.ActivateNextStage(); => StageManager.ActivateNextStage();

     

    RigidBody References

    Not sure how much effect this one really had but the conversion notes indicate that references to Part.rigidBody should be updated.  See the following post for more information.

    http://forum.kerbalspaceprogram.com/index.php?/topic/135179-info-on-how-to-convert-your-plugin-to-ksp-11/

     

    You should be able to restore references to TimeWarpDecorator.  Does not completely fix the UI yet but connections should work again and vessels can now be targetted.

  12. I'm unable to relay through other satelites.  Direct connections to mission control do work.  I am not seeing the connection status and flight computer panel under the MET display in the upper left corner.  The UI for settting dish targets opens but none of my other ships or satelites appear in the list.

     

  13. I found some other mods that seem to be using it for 1.1.  Are you missing a using or assembly reference?  I'm only seeing references to just the following in other code that references UIManager.

    using KSP;

    using KSP.UI.Screens;

    KSPUtil.dll

    UnityEngine.dll

    UnityEngine.UI.dll

    Could be they moved it into another namespace or assembly.

×
×
  • Create New...