• Content count

  • Joined

  • Last visited

Community Reputation

70 Excellent

About OHara

  • Rank
    Spacecraft Engineer
  1. KSP has an option to make ports dock at discrete rotation-angles, but it is disabled in the stock game. The Module Manager mod is necessary to use it: If you use this patch, you have to align the ports in all three components of rotation (within tolerance) before the ports dock.
  2. Winglets, deployed at 150% in alternating directions, can slow a minimal lander to 400m/s, and full-size parachutes partially deploy at that speed on Duna. We can land on those winglets at 12m/s, whereas early-career landing legs are not stiff enough to protect the engine. Using the reaction wheel (with a pilot or probe-core that has SAS) is important to avoid tipping on the touchdown bounce. One could use the engines just before touchdown, but it is hard to judge distance to the ground when you are new at the game. This lander has enough delta-v to return to Kerbin, using six aero-braking passes to reach the surface. The engineer (or pilot, depending on the rules) needs to repack the chutes after use at Duna. Atmospheric pressure is only 0.07 atmospheres on the surface of Duna, so we do need the 'pressure' slider down to 0.04 atm if we want the parachutes to partially-deploy before their full-deploy altitude. A partial deployment reduces the g-forces on the pilot.
  3. Having a thread for this is a good idea. I am still (since April 2016) playing my first career game, in which I've had Kerbals land and return from every planet and moon except Duna. My Duna probe landed hard, and I seem to have never looked back to Duna.
  4. Stationary? or on the takeoff roll ? (You title did say stationary, but just being sure.) I tried your craft from kerbalx just now. Stationary, in KSP 1.3, with brakes on it remains stationary for me. I notice you set zero friction on the front wheels, which I though maybe would let them slide sideways, but I don't see it slide here. With brakes off it starts to roll (at the expected 1.4km / 600km × 9.8m/s² = 1.4 m/s /minute from the flat runway on small-radius planet) but doesn't seem to slide. On the takeoff roll with no input the wings took the weight off the rear wheels first, leaving just the front wheels pressing down (the 'wheelbarrowing' problem common to nosewheel aircraft if you forget to trim up for takeoff) and that rolling drag near the nose could make the plane unstable in yaw. It was not too bad, though. You might like to add yet another action group binding, to 'deploy' some or all of the canards when gear is down. That will pull weight off the front wheels when you are on the ground.
  5. The code in Kopernicus used a round-to-nearest on the ratio of total-years-to-date-length / day-length, but here you round down. That matters more now that you have an option to show the year change at the nearest whole day. Someone other than OhioBob will likely have more than a one-second error, such as a year 99.999 days long, and the 100th day will be in year-2 because a few seconds wouldn't fit into year 1. Also, both values of 'useLeapYears' use a variable number of days between the first of one year, and the first of the next, so one might think both cases use leap years. I can't think of a better name than 'yearMayChangeDuringDay' For the new option to change year-number on a day-boundary, I would like the mod more if you choose the closest day-boundary:
  6. I thought KSP simulated gravity for each individual part of a craft. That would make it easier to understand the fuel-pumping exploit, http://forum.kerbalspaceprogram.com/index.php?/topic/36949-fuel-transfer-exploits/ and the way orbits are not quite stable when running the full physics simulation http://forum.kerbalspaceprogram.com/index.php?/topic/138506-orbital-decay/ We could try a pendulum satellite and see if it responds to the tidal forces, though probably someone has done that already.
  7. No, MarkusA380 checked for you. He resolved the problem by removing the 1.2-compatible version of Scatterer As far as I know, the sun exploded 7 minutes ago; we'll find out in a minute.
  8. Heat: If you are using version 1.2.2, there is bug #13403 preventing core heat from leaving the drills (which makes them overheat outside of the atmosphere). In case you haven't signed yourself up to read the bugtracker, the fix posted there is to edit GameData/Squad/Parts/Resources/*Drill/*.Drill.cfg to make UseSpecialistBonus = false (being sure to change at least the /final/ of the redundant definitions of UseSpecialistBonus in those files). Given the name UseSpecialistBonus, you might worry that this change would prevent engineers from helping the drilling process, but in fact the change seems to have no side effects. While you are in there, you might want to change AutoShutdown =false, because the drills shutdown upon lack of electricity (not just upon overheating) and require manual restart. (The usual solution to this problem is to switch away from any solar powered drilling operation only during the day.) Throughput: I have also noticed that "Ore rate = 0.13 units/s" is not the current rate of drilling ore; "ore rate" × "load" is the current rate of drilling ore. The "load" is at best 5% in the absence of any engineer, further multiplied by 12% from being away from the optimum temperature in the case you showed us. So you have 0.13 units/s × 0.6% = 0.0008 units/s = 2.8 units/hour from each drill.
  9. On Koperincus' GetDate(), at


    // Current Year

    int num1 = (int)(time / Y.value);

      // Current Day

    int num5 = (int)(time / D.value) - (int)(Math.Round(Y.value / D.value, 0, MidpointRounding.AwayFromZero) * num1);

    based on the comment just above that code, I would have thought

    int num5 = (int)(time / D.value) - (int) Math.Round(num1 * Y.value / D.value, 0, MidpointRounding.AwayFromZero);

    so that you assume all the years before the current year have had enough leap days to sum to the number of days closest to the last change of astronomical year; then the first day after each astronomical year-change is day 1

    If D = 1000 and Y= 10'400 to have 10.4 solar days in a solar year, then

    time = 105'000   =>   num1 = 10years,  num5 = 105 - 104 = 1days

    ( instead of the current code's  num1 = 10years, num5 = 105 - 10 × 10 = 5days )

    1. Sigma88


      @OHara you are probably right

      I'll try to bug test this tonight :)

    2. Sigma88


      actually, it wouldn't be

      num5 = 105 - 10 × 10 = 5days


      it would be

      num5 = 105 - 10 × 11 = -5days


      so clearly there's something wrong

      I still need to test this more, as of now the results for time 1 would be Year 0 and Day 0


      but it should be Year 1 and Day 1 instead


      I'm not sure if the +1 gets added later or what (probably yes)

  10. Probably not. If it is 'fixed' by adjusting Kerbin's SMA to make the length of a year exactly 457 days, the position of Kerbin will change when for every save-game that is ported to the KSP version with the fix, messing up encounters on trips to or from Kerbin. The lack of leap-years is not obviously wrong. Some real-world calendars slip from the solar year. If I lived on a planet with no seasons, 0° axial tilt and no eccentricity of the orbit, I would rather let the calendar slip relative to the stars, than have leap days. Better to correct the wiki than change KSP. Kopernicus would make this more obvious, when the home planet has inclination or eccentricity. I see that Sigma88 wrote a GetDate() for Kopernicus that reports the solar year, slipping in a leap day as needed. (Edit: The code comment makes sense, but the code itself seems to increment the number given first day of the year, every leap year, so years start with day 2 for a while, then 3...)
  11. I agree with your math, that neither sidereal nor solar day neatly divides the astronomical year, and your conclusion that they would need leap days to keep the calendar synchronized to the sky. So does : So we expect the Kerbal calendar to drift away from the seasons (if we use a mod to give Kerbin an orbital inclination so we see the seasons) and the rising-time of stars to be different on the same calendar date as the years go by. Neither effect would be obvious in normal use of KSP.
  12. Nice. It is not easy to beat the results of the challenges from version 1.1.x If you don't mind switching between craft in the atmosphere to recover the first stage, and if you intended to allow vertical take-off jets in category 2, you might do really well with jets in the first stage. I started playing a bit with this in a single-stage lifter, because I didn't think it would be feasible to recover the jet stage if I separate it at 30km altitude.
  13. There have been similar suggestions. The original post in this thread efficiently expresses the core desire. A relatively new contributor made a nice mod for this I realize the purpose of the original post, and of the sub-forum, is to make suggestions for stock, and I agree that vessel sorting would be quite good to have in the stock game. I recommend ManeuverQueue for use now, and as a concrete demonstration of (nearly?) what is being suggested here.
  14. If each of the 12 rapiers was 0.5 rather than the stock 2 tonnes, that 18-tonne reduction in mass explains probably half of the craft's apparent advantage over stock. The discussion might go badly if people try to divine whether differences to stock were intentional or accidental. But it clearly helps the community to know that: no, a VTOL space-plane like that looks like that in stock parts is about 50% too heavy to do what is shown, so be inspired but don't feel bad if your performance is different. The moral of the story might be that we gotta be careful about leftover modifications when we participate in challenges.
  15. Sadly, no. I think I was correcting myself in an edit (more like 425/t) while you were typing. Keep using rockets to move cargo until you have better than panthers.