• Content count

  • Joined

  • Last visited

Community Reputation

66 Excellent

About OHara

  • Rank
    Spacecraft Engineer
  1. 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.
  2. 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)

  3. 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...)
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 1. 260per crew, in a plane with an early-tech docking port 2. about 325 425/t, replacing the crew cabin and docking port a long mk2 cargo by, if you can fit a useful 5t 4 tonnes in there, but it's not much fun to fly.
  10. That approached worked for me just now. 175m/s is the rotational speed of Kerbin, so the probe under its parachute is moving much slower relative to the atmosphere (The speed relative to the center of Kerbin is arguably the right thing to show in map view.) The inconvenience is that I need to stay within 22.5km of the probe until it reaches the ground, which takes a long time. If I go further than 22.5km from the probe, KSP switches to simplified physics (dropping simulation of things like parachutes) and lets the probe follow its orbital trajectory, which is a free-fall into the ground. You can find that number 22.5km in your install directory in Physics.cfg under VesselRanges::flying::unload (probably the value that PhysicsRangeExtender lengthens, among others). KSP is nicely configurable. Notice that 'flying' has a longer 'unload' distance than all the others, presumably to allow recovering boosters on parachutes in the style you tried for probes. Once the probe is on the ground it is 'landed' and physics freezes until you switch to the vessel to see it settle on the ground. (The stock ship 'Stratolauncher', however, does not work so well. http://forum.kerbalspaceprogram.com/index.php?/topic/137917-how-to-recover-a-stratolauncher/ The in-game examples and training in KSP are a relative weakness.)
  11. A lighter-payload spaceplane. I thought the economies of scale would be significant, because volume for cargo, and the engines and fuel to accelerate it to orbit, increases as length cubed while parasitic drag increases only as length squared. In practice, though, a single 1.25-meter stack (craft file) saves so many draggy adapters that it comes out more efficient than the 12-Rapier version of the same concept. I usually set docking ports to engage only when roll is aligned, and was surprised how difficult it is to align the wings by hand within 1° before the docking ports grab. fuel budget k320 for 400u LF giving 3074m/s air-breathing (allows ~1000m/s loss to drag) k460 for 1000u LFO giving 890m/s with rocket k780 The rather lucky and clean ascent in the photo series above came in under budget (21,645 cost - 20,920 recovery) / 10.5t = 725 / 10.5t = 69.0/t
  12. Good idea, because the efficiencies of scale tend to push designs for best cont-per-ton in the same direction. More creative solutions will be needed to be efficient with a lighter payload. First, though, I had to finish my original plan to get below 75/t with a spaceplane, so I updated my entry two posts above.
  13. Taking @Wanderfound's mk3 concept to the logical extreme, I replaced the cockpit and the cargo bay with fuel, and strapped the payload to the sides, as if it was carrying a pig under each arm to market. I was surprised how much wing it required. It couldn't build up enough speed to take off on the runway, so I added a solid-rocket sled that was recovered from the water just past the runway. (KSP seems to require a probe core on recovered craft, to count money back from recovery.) The result looks similar nefrum's heavy-ssto entry but much uglier (craft file). My plan was to take 8 ore tanks under each wing, 272t, at 75/t, giving a fuel budget of k20,000. The first attempt could only lift 14 tanks (http://imgur.com/a/AHNE4, 20,074 / 238t = 84.34/t ) but switching to round tanks rather than mk3 where possible, and making the nose more pointy, got all 16 ore tanks to orbit under budget: (209,001 cost - 181,136 recovery - 8,488 booster-recovery) / 272 tonnes = 19,377 / 272t = 71.24/t
  14. It flies nicely hands-off, but the ailerons roll controls are reversed so SAS fails to control roll. The automatic assignment of controls sometimes gets confused, and in this case I don't see an easy way to un-confuse it. This plane flies nicely, though, if you have each control respond to just one of pitch/yaw/roll, and reverse the control-authority on roll to compensate for the error.
  15. Waypoints do seem a little more convenient for the KSP runway: + you avoid the 175m/s offset in indicated airspeed, that appears 60km away when the navball switches to target mode + you can put them right on the runway, whereas flags or rovers need to be 30m or so away so they don't count as vessels on the runway - but you need to have a probe core on the rover to set the waypoint Directly targeting the base stil seems more convenient to land at bases on other bodies: + you get anti-target and retrograde markers, so you can aim a lander with its control-part oriented so the nav-ball points to the sky as usual + you get AN/DN markers that can help align your orbit to the base - you just have to remember to set the nav-ball back to surface mode, when it switches to target mode 60km from the target Interestingly, if we go within physics-loading distance to a landed target, which corrects the indicated velocity to the target, and then move away beyond the unloading distance, the velocity remains correct... until the next quicksave/quickload. I couldn't make good use of this quirk, though. A module-manager patch to increase the physics-loading distance: