Jump to content

AlexinTokyo

Members
  • Posts

    517
  • Joined

  • Last visited

Posts posted by AlexinTokyo

  1. Not certain it's your issue, but I've found that lights absolutely murder the frame rate I get.

    As in, I can have a 30-odd part rover which putts around fine, but turn on the lights and the physics engine can't keep up and I go into yellow-clock slow down.
    I notice you have all the cabin lights on in the second station pic, so I wonder if that has something to do with the problem?

  2. @Philae_Rosetta2021
    Are you using a laptop of some kind?  Many laptops replace the standard function keys with 'useful' functions not normally available on the keyboard, which has the unfortunate side effect of making the F-keys unavailable to any other software that might want to use them.

    Usually, there will be a 'Fn' key somewhere which allows you to access the 'normal' function key by pressing them in combination (e.g. Fn + F4).
    You can also change this behaviour in the BIOS (usually) so that the F-keys default to being F-keys, and you need to push Fn + FX to change the volume/brightness/whatever your laptop manufacturer thought was more important than providing standard functionality.
    No, I'm not bitter about this, why would you think that?

    Check the user manual for your machine for details on how to change the BIOS setting.

     

  3. Oberth still applies retrograde, so you lose more kinetic energy the faster you're going.

    From the Wikipedia entry (the expample is a prograde burn, but it's easy enough to reverse it:

    Spoiler

    A rocket works by transferring momentum to its propellant.[3] At a fixed exhaust velocity, this will be a fixed amount of momentum per unit of propellant.[4] For a given mass of rocket (including remaining propellant), this implies a fixed change in velocity per unit of propellant. Because kinetic energy equals mv2/2, this change in velocity imparts a greater increase in kinetic energy at a high velocity than it would at a low velocity. For example, considering a 2 kg rocket:

    • at 1 m/s, adding 1 m/s increases the kinetic energy from 1 J to 4 J, for a gain of 3 J;
    • at 10 m/s, starting with a kinetic energy of 100 J, the rocket ends with 121 J, for a net gain of 21 J.

    This greater change in kinetic energy can then carry the rocket higher in the gravity well than if the propellant were burned at a lower speed.

     

    To illustrate, here's a simple Mun encounter.
    At SoI entry, with a hyperbolic periapsis of 20k, it would take me 305 m/s Δv to capture into a 20 km / SoI edge orbit.  This burn requires a radial-out component, otherwise the periapsis will be several km below the Munar surface.

    IV1aKQT.png

    Capturing into the same (or at least a very similar) orbit at periapsis requires only 74 m/s

    aC5mRbk.png

     

    4 hours ago, Irihi said:

    On a Laythe landing mission, I dropped down to Kerbin through a 100km tylo swing by with just 500m/s or so, so I just assumed I could get a solid kick from the mun at half the altitude, but I guess it's a pretty small body.

    Yeah, Tylo is great for gravity assists (you can capture into Joolian orbit for just the cost of the course correction to set it up and no additional Δv), because of it's high mass.  The Mun... not so much :)

  4. 8 hours ago, Irihi said:

    1. That's a great point and idea. I think I could split up the burn into 3 or so. What is the maximum number of nodes one can pre-program?

    There's no limit as far as I'm aware, but since they're going to be in roughly the same place it can get kind of difficult to manage.  Since you can never have a (combined) Δv for the non-escaping burns of more than 950m/s (or you will escape), the most common way would be to use three burns total, on of about 450m/s, the second to go right to the edge of the SoI, and the third for the remainder of the burn.  Of course, it will be difficult to work a Munar assist into this, which brings me to point 2

    8 hours ago, Irihi said:

    2. I think I could make my munar slingshot push my apoapsis close to jools SOI with just a few hundred dv in course correction, especially if I do it 50km over the munar surface. The problem I have is that I'm not getting course projections after I leave Kerbins SOI. Is there a way to get the map screen to project the course after more than 3 SOI entries/exits?

    The Mun doesn't really have enough mass (in the stock game) to make it worthwhile using it for a gravity assist.  If you are going to do it (and it is definitely fun to do so), then try to make the burn as close to the surface as you can, to get full advantage of the Oberth effect (although it is much less pronounced at The Mun than at Kerbin, due to the lower mass). 

    You can increase the course plot by changing the CONIC_PATCH_LIMIT setting in the config file (settings.cfg).  This can be done in game using the PreciseNode mod (or it may be possible in stock in more recent versions, but I don't know where that setting might be).

    8 hours ago, Irihi said:

    Id never heard of the oberth effect before. Thanks for that. 

    I understand that prograde burns should happen at periapsis when possible, what about retrograde capture burns? Would those be more efficient far away (and slower) from the hyperbolic focus/periapsis?

    If you are trying ro raise or lower your apo- or peri-apsis, then it is most efficient to burn at the opposite apsis (so at perapsis if tyring to raise apoapsis so as to escape from orbit).  Since in a capture burn you want to lower your apoapsis (from infinity), you should burn at periapsis.  This also gives the most benefit from the Oberth effect.

  5. Are those wheels tilted out of the perpendicular?

    I'm pretty sure that KSP wheels only have a valid collision mesh for applying power at the "bottom" of the wheel (the part that would touch the ground if mounted "normally", and having any other point in contact with the ground makes them incapable of movement.  They just spin and do nothing, exactly as you have described.

  6. OK, let's do some maths.

    With a starting mass of 211 t, and a Δv of 1348, you have:

    Δv = g0.Isp.ln(m0/m1)
    m1 = m0/e^(Δv/(g0.Isp))
       = 211 / e^(1348.0 / (9.81 x 800))
       = 177.7
    
    Δm = m0 - m1
       = 211 - 177.7
       = 33.3
    
    Ft = g0.Isp.mbar
    mbar = Ft/(g0.Isp)
         = 60 / (9.81*800)
         = 0.007645

    So each engine will consume 7.6kg (0.0076t) of fuel per second, and your total mass change is 33.3t (in fuel consumed).

    This gives:

    t = Δm/(mbar*engine_count)
      = 33.3 / (0.007645 * 4) = 1088.94 (18m 9s)
      = 33.3 / (0.007645 * 6) =  725.96 (12m 6s)
      = 33.3 / (0.007645 * 8) =  544.47 (9m 4.5s)

    So these are the expected burn times for 4, 6, and 8 LV-N engines.  I'm including all three, because I'm now confused as to which times from screenshots above refer to which version of the craft and therefore number of engines.
    Note of course, that the starting mass will (I assume) be slightly different for the differing variants, so the above will not be fully accurate for all iterations.

    So if you're seeing figures wildly different to these for the Burn Time indicated on the nav ball, then the game is having a problem correctly calculating the times.  Using the above method, you should be able to calculate exactly the time required, then (as has been said) split it 50/50 before and after the node time.
    Since you're using KER, note that it has a burn time calculator (I think in the Vessel menu???) which I have found to be more accurate than the KSP native one.  Maybe see what that says and if it agrees with KSP or with the values above.

     

    One thing that I noticed hasn't been mentioned: I don't suppose you are dropping into the atmosphere at any point during the burn (as you're starting off pointed well below the horizon)?

  7. To give what @FruitGoose says some visual reference, here are some explanatory images:

    Or3bKOp.jpg

    This is the default burn-time indicator.  It shows the time to the node (T - 8 minutes), and the duration of the burn (Burn Time of 2 minutes).
    As in FruitGoose's example, you want to split the 2 minute burn so that about 50% (i.e. 1 minute) is on either side of the node.  So, in the above expample you would start burning in 7 minutes (1 minute before the node time of 8 minutes)

     

    NxsdEaM.jpg

    There is also an "Extended Burn Indicator" (this image) which displays a countdown to the start of the burn ("Start Burn in") as well as the above node countdown and burn duration.
    In this case, you can simply start burning when that countdown reaches 0.  You can activte this extended mode from the in-flight settings menu (Esc menu) as below.

    d5YDBB1.jpg

     

    Note that both "Node in" and "Start Burn in" are count downs, while "Burn Time" should not change once you have fixed the burn Δv.  If the "Burn Time" is changing, then either your ship is experiencing some acceleration (engine on at low thrust?) or there's something strange going on.
    When you start burning, the Burn Time does count down; you can stop the burn when it reaches 0, at which time (in the above example) the "Node in" countdown should be at about T + 1 minute.

  8. This seems to be a known issue that was supposed to have been fixed but apparently hasn't been for everyone.

    Forum thread: 

    Bug report thread: https://bugs.kerbalspaceprogram.com/issues/26944
     

    It seems originally there was an issue with mods that used non-standard EVA propellant not auto refilling (are you using any such mods?) but it also appears to affect stock users in some cases.
    As far as I've read, no one seems to know what the trigger is for this bug to occur.

    "Persisent Kerbal Loadout" shouldn't be the cause, and certainly hasn't affected EVA prop in my current 1.11.2 Career save. (That setting is designed to set the Kerbals' inventories to the same as the last time they flew, and if off will revert to EVA pack and personal parachute each time.

  9. Pictures of the craft (VAB, pad, and in flight) will help, but here are a couple of (possible) ideas:

    • What's connecting the station payload to the fairing base?  I've found that that connection can be quite tenuous, and needs lots of care to prevent shennanigans from occurring.
    • Are you using any form of autostrutting?  If so, what to what?

     

    Edit: In response to FG's ninja, I'm focusing on the wobble here, rather than the flip (which I kind of assume is a result of the wobble).

  10. Sounds like you want to play the way I do; lots of missions going on concurrently in appropriate timeslots without a lot of warping around.

    First thing (as @Curveball Anders says) is to get and learn Kerbal Alarm Clock - this will give you the ability to jump out of a mission part way through and come back at the next important time (even if that is 180 days away).  As a side benefit, you can also set Earth-time alarms, so you don't forget to sleep :P)
    The other mod I use a lot for this is Transfer Window Planner. This implements the functionality of Alex Moon's Launch Window Planner in the game (and should be similar to Mechjeb's porkchop plotter, but I have never used that, so I can't comment) and also has the ability to sync directly to KAC, so once you've found a transfer you can save the details directly to a KAC alarm.

    With these two, you can both plan ahead and find transfers that are possible even if not optimal, and jump between missions as required, so you can have a Jool probe on the way when you launch your Duna mission at the optimal launch window.

  11. The deployable seismometer doesn't passively gather science; you have to crash something into the body to get measurements.
    The more massive and faster the object is moving the more science you get, also you will get more the closer the impact is to the sensor.

    So you'll need to, Apollo-style, crash your transfer stage into the Mun, or send a dedicated lithobraking impactor.

  12. 1 hour ago, TanoPrime said:

    I'm definitely interested, and saved the .cfg file manually.

    Thanks.  Let me know if you think I'm wildly out with any of the volumes :)

     

    The old parts are still included in the mod (for backwards compatibility) but are restricted somehow from appearing in the tech-tree / part selector.  I imagine it would not be too difficult to add them back (probably another CFG patch could do it), although I have to admit that I have no idea what values you'd neeed to patch in.

    That said, I agree with Grimmas that it's not too difficult when you get used to it.
    Essentially you have the following scanner types:

    • Radar (2 tiers) - gets you low-res altimetry data
    • SAR (3 tiers) - gets you high-res altimetry data (and biomes for the tier-3 scanner)
    • Multispectral (3 tiers) - gets you low-res visual data, biomes, and (except the tier 1 version) low-res resource data
    • Visual (3 tiers) - gets you high-res visual data and (except the tier 1 version) anomaly data
    • Resource (3 tiers, plus the two stock components if you disable stock resource scanning) - gets you high-res resource data
    • BTDT - this is the same as the previous version; short-range detection of anomalies and Breaking Ground surface features.

    In general, the higher-tier scanners have wider fields of view, higher operating altitudes, and greater power consumption.

    To be honest, the biggest thing to get used to, I think, is that the resource, multispectral, and visual scanners all require the surface to be in daylight in order to scan, which makes the choice of orbit a little more complex.  Although I believe you can disable this restriction in the settings.

  13. Welcome to the game and the forums, and congratulations on your first orbit :D

    The Δv required to launch into Kerbin orbit is highly dependent upon both your craft and your launch flight profile.   As it says on the Δv map (I assume you mean this one), "More/less efficient ascents are likely, depending on ascent profile, TWR, and aerodynamic effects."
    So if you have a small, aerodynamic rocket and fly a very efficient profile you can definitely get to orbit for less than 3,400 m/s.

    That said, it's more likely that you were seeing the atmospheric Δv of your ship in the VAB, while the map uses vacuum Δv exclusively.
    This difference, which can be quite large, is caused by the fact that rocket engines (especially those designed to work in a vacuum) suffer an efficiency penalty (represented by a lower specific impulse - Isp and commensurately lower thrust) under atmospheric pressure.  So it's likely that you had significantly more vacuum Δv than the 3,100 m/s displayed.

    I use KER (a mod) for my vehicle information readouts, so I'm not familiar with the stock game's Δv data in the VAB, but there should be an option to switch between vaccuum and atmospheric values.

    Ninja Edit: What HebaruSan said :P

  14. 3 hours ago, king of nowhere said:

    on every planet there is a single green monolyth, generated at random in a different place for every new game. finding it gives a free tech. to find it, you have to use the kerbnet and scan for anomalies. it's easier to do it than to explain it. finding one gives a free technology.

    anyway, it's quite an uncomfortable way of getting a tech. just landing and getting all science from the biome is worth more

    Wow, I did not know that.  I might have to do it before fully unlocking the tech tree in my current save just to say I've done it.

×
×
  • Create New...