Kerbas_ad_astra

Members
  • Content count

    1341
  • Joined

  • Last visited

Community Reputation

633 Excellent

4 Followers

About Kerbas_ad_astra

  • Rank
    bulkheadProfiler
  1. Alright, with energy conservation, the vehicle now starts firing shortly before the deadline. Be advised that, as solid rocket motors cannot throttle down for a soft landing, they will bring the vehicle to zero velocity several meters off the ground, so be prepared for a bit of a drop! Bring airbags, girders, or something crushable to land on... (The Landertron Box behaves the same way, but if it cuts out more than a meter or so above the ground, it will rearm itself and perform another landing burn at the appropriate time.) My goal is to have this released next week.
  2. I found in testing that, while a lander with four SuperDracos (TWR 4) fired too late, it fired right on time when there were twenty (TWR 14). Additionally, in the 4SD case, the impact velocity on the ground was ~25 m/s or 2.5s * g, which is about the burn duration. I think there's an issue in the way that the soft-landing handler accounts for gravity (which would have a greater impact on longer burns, which is exacerbated by increased altitude or reduced number of engines). The handler doesn't ignore gravity, but it accounts for it in a different way from Kerbal Engineer (essentially, it bookkeeps gravity as a penalty to TWR, whereas KER uses conservation of energy), so I'm going to tinker with that to see what comes of it.
  3. Can you post a craft file and describe more precisely the situation? (E.g. the orbit state at reentry.)
  4. Yes, you can add "SMURFFExclude = true" to them in a Module Manager patch. I'll put that on the list for the next release of SMURFF.
  5. SMURFF doesn't work by part names; it works based on the resources and modules that a part has. The inflatable heat shield doesn't use the same ablative heat shield material or module that the others do, so the patch doesn't apply. (Nor should it -- the LDSD was 5 meters wide and weighed 3 tons, though much of that was surely taken up by the motor assembly.)
  6. I don't use KW rocketry myself (though if it's balanced like stock parts then SMURFF will handle it just fine), but the others I do use and like (and to some extent support with SMURFF -- e.g. Near Future's lithium and argon fuel tanks). For your consideration, I'd suggest looking at HGR or MOLE, for 1.875m parts. The jump from 1.25 to 2.5m parts is pretty steep, and it's nice to have an intermediate size. For RSS in particular, I've found size "1.5" parts are great for launching small payloads into orbit without producing excessively long rocket noodles (being squatter than size 1). Here's a rocket I've made for landing a seismometer (from the Impact! mod) on the Moon:
  7. Testing and cost-balancing is complete! I am proud to announce CommNet Relays v2.0.0! Renamed to "CommNet Relays". Because it uses the new CommNet system, it is not backwards-compatible with pre-1.2 versions of KSP or 1.x versions of AntennaRange Relays. Backend logic overhauled to use new CC antenna parameter. Specific parts are no longer required to complete contracts. Adjusted some of the contract parameters to reduce duplication and increase available choices. Max/min apoapses adjusted to CommNet balance. Adjusted RSS patch. Added OPM patch. Added new "Super DSN" contract to build enormous DSN relays. Why? Because we can!
  8. Version 1.6.1 "B9-C" is out! Another tweak to the CryoTank patch, to avoid stepping into B9's CryoTank patches.
  9. Thanks for the heads-up -- I need to be more particular with that patch in calling out CryoTanks's tank type, and not the similarly-named B9 cryo tank type.
  10. The best way to do that is to learn how to use git and GitHub. That's exactly what revision control is for -- contributors can make forks of the main repository, make changes, comment on each other's revisions, and then merge updates into the primary release branch to produce releases.
  11. I recall a "Start Countdown" action in the context menu -- that's what it's supposed to do, start a ten-second countdown to fire so there's time to switch to the craft. I saw it in your livestream (the edited recording of it, anyway); did it not work?
  12. You're always welcome, but I've understood it to be better Git etiquette to accept PRs (if they're making changes that you want) rather than duplicate the changes and commit them on your end. Because Git runs on line-by-line comparison, it sees that we've changed the same lines, and thinks there's a conflict that requires manual resolution, which prevents automatic merging when I update my repo from yours, which in turn makes it harder for me to contribute future fixes. Or you could make your mods perfect the first time and not require any fixes from me.
  13. MFT does its tank mass calculations independently of whatever the part's "mass" number is, so there's no point in using SMURFF with it, and you probably shouldn't use both MFT and Procedural Parts at the same time.
  14. He logs in regularly, and he accepted my last batch of changes a few weeks ago. Since that one had a problem with drag cubes, I don't blame him for waiting until I'm well and truly finished with this set before accepting and releasing it. (Which I do think it's ready for.) If he doesn't feel he has the time to keep managing VSR, we'll cross that bridge, but he surely aten't dead.
  15. Since I've updated the legs on both of my installs with no issues, I've pushed the re-revamped legs to my KSP_1.2 branch.