Kerbas_ad_astra

Members
  • Content count

    1364
  • Joined

  • Last visited

Community Reputation

677 Excellent

2 Followers

About Kerbas_ad_astra

  • Rank
    bulkheadProfiler
  1. SMURFF adjust stock parts to have performance more like real rocket parts. However, this does not mean that a stock rocket that can reach orbit around Kerbin can reach orbit around Earth with SMURFF. Because of the logarithm in the rocket equation, even a 4x reduction in rocket dry mass (which is more-or-less what SMURFF does) has pretty strongly diminished returns (a 60% increase in delta-V capacity at maximum, but more like 40% in practice because there's more to a rocket than engines and fuel tanks), while the delta-V requirements to get around the solar system roughly triple. For a concrete example, it is possible (barely) to get into orbit with RSS and SMURFF by taking a Kerbal X, removing the ladder and legs, and doubling the upper stage fuel tank. It has just over 9500 m/s of delta-V. In stock, the same rocket has "only" 6800 m/s of delta-V, which is enough to land on Duna and return (with very careful piloting and exploiting aerobraking opportunities to their fullest). So, while SMURFF makes it easier to get into orbit (or anywhere else) in RSS, it is still much more challenging than in stock.
  2. I don't know about the Coxswain, but the survey scanner being stretched is a bad interaction between VSR and Indicator Lights. Some time ago, I made a patch to help them play nice (Snark bundled it up in a 'community extensions' patch release), but I haven't used Indicator Lights in some time, so I don't know if it still works.
  3. Looks like the DeployModuleIndex is off by 1. I'll test it and push the fix. It wouldn't be that much work (change "@PART[partName]" to "+PART[partName]" and add an "@name = partNameVSR" or the like), but since stock part overhauls seem to have stalled (the only word we have from Squad is the upcoming Making History expansion, which is a set of totally new parts), I don't see a reason to go nuts.
  4. Machine epsilon for floats is about 1e-7, so I don't think that would cause a 0.6% variation. I've confirmed this with HyperEdit and Kerbal Engineer -- popping a probe into the Moon's orbit, it does lag behind. Looking at the in-game info window, the rotation period of the Moon is 27d 6h 35m, which is the time that Stract measured, and which is almost exactly 4 hours shorter than the orbital period of the satellite placed in the Moon's orbit (27d 10h 35m). It turns out that adding the Moon's gravitational parameter (0.0123x GM_E) to the Earth's (as is the case for the true two-body problem) and running the period calculation produces the 27d 6h 35m value that we see in-game. I see that Kopernicus has a "FinalizeOrbit" method that recalculates a body's orbit using the combined gravitational parameter ("unlike stock KSP", says the comment), but I suspect that spacecraft still get the old central-body-only calculations. This is a true enough in low orbits, but less so in very high orbits in systems with a large secondary body, where the n-body properties start to matter.
  5. Delta-V capacity depends on fuel mass fraction as well as specific impulse. The Tiny is heavier than the Quadroodle, and because LH2 is less dense than LFO, when you use the same fuel tank, the fuel mass is less. For your spacecraft, this happens to outweigh the improved specific impulse. To overcome the mass and density penalty, you may want to try using larger fuel tanks (which may still end up being lighter than the small LFO tank, because LH2 is so fluffy, but they will almost certainly have to be larger). Alternatively, if you don't need a multi-km/s delta-V budget for your CSM, you are most likely better off leaving the NTR at home and using a lighter engine. This is also the case for stock engines, by the way -- the Nerv is only the optimal engine choice for very high delta-V requirements (the LV-909 is often the better choice even up to 3 km/s depending on payload mass). Check out this chart:
  6. Squad's model got revamped in 1.2, so it now uses different internal names for its transforms than Ven's model does. That can be fixed in the config file, but Porkjet's revamp also added a gimbal, which Ven's model lacks (it was made to imitate the old model -- technically I can sort of make the entire thruster swivel, but it doesn't respond very well to roll control inputs). Something else I like about Porkjet's model is that it actually looks like it 'ought to have' 20 kN of thrust -- the old model was barely larger than an RCS thruster, but was supposed to have 20x the thrust. Additionally, the O-25 large OMS needs some stat adjustments -- it claims to be 'more vacuum-focused' than the O-10, but its vacuum Isp is now worse, and its TWR is worse as well (when it looks like it should have a lower structural mass fraction). I think the best way to handle this is to leave the O-10 model alone. Since I like Ven's model, I'm inclined to modify that patch to split it out into its own part (the O-1 'Huff' thruster, 2 kN, 240 sec, no gimbal, 0.01 tons), and also give a balance pass to the O-25 (rename it the O-40, 80 kN, 260/90 sec, 0.35 tons).
  7. If you're talking about the parts I think you are, I added a "size25" icon (which RagingCaucasian used as his bulkheadProfile) some time ago. That said, it's straightforward to replace, rename, and rearrange icons.
  8. Thanks for the heads-up on the HG-20 and RV-145. I've made some changes to my repo accordingly. (I also squashed the RV-145's specific impulse to 0.001 seconds at 4 atmospheres, as the stock RV-105's is.) Regarding the CRG-02, its mass was based on a comparison with the Mk 2 CRG-04 cargo bay (which itself masses only 0.25 tons). FWIW, the CRG-02 also appears to have much thinner walls than the Mk1 Structural Fuselage. It appears to have a slightly larger canopy than the Mk12-R, so I've changed it to be 6 meters fully deployed, and tinkered with other statistics accordingly.
  9. I'm not aware of any issues with either, but I've never used them, so I don't know. Interstellar does its own rebalancing for RSS, and to my knowledge SETI is balanced to stockalike standards, so there shouldn't be any problems.
  10. Landertrons do decide when to cut out (essentially venting the remaining propellant all at once), but because KSP's physics run in discrete steps, it's not possible to exactly target the zero velocity point, especially if the engines have a high TWR. (XanderTek had the landertrons throttle to compensate, but charfa removed that behavior as it felt cheaty, and I haven't restored it for the same reason.) Of course, the 'fun' part is that the higher the TWR, the closer to a perfect suicide burn you get (and the less of a drop you have to deal with). Pick your poison! As for setting an altitude or velocity target, it's not a priority as it's been enough trouble getting these things to target zero/zero (which is still not perfect...). For targeting a particular altitude or speed, you may be better off looking at more advanced automation systems, like Throttle-Controlled Avionics or Smart Parts.
  11. I'm on travel right now, so this will have to wait until I'm back home, but yes please! I'm very interested in your tool. Next version will surely have a 'proper' texture for the G4-LK. Many thanks @Orionkermin!
  12. I've never encountered that issue; there's nothing special about that contract vs the others (save that it requires a stationary orbit, and has an especially high requirement for the antenna power). Can you get me a log with the failure?
  13. No more than it did before. There are a couple of gaps in stock that get filled (e.g. even though stock defines a crew report for "KerbinSrfLandedLaunchpad", the "default" report is what gets read out by stock KSP, and with Crowd Sourced Science, it's the first mod report that gets read out), but there's no cycling. Since the stock game includes some 'alternate' reports that don't get read out, I'll file a bug on the tracker.
  14. SMURFF version 1.6.2 "Kerbals Not Smurffs" is here! Exclude Kerbals from SMURFF patching. Add pure-LF IFS patch.
  15. It surely 'works with' Interstellar in the sense that they don't conflict, but I don't use Interstellar myself, and as it adds lots of resources to the game (and, judging by the pull requests I see on the Community Resource Pack, it is always adding more resources), supporting Interstellar would require more effort than I'm able to sustain.