Jump to content

NathanKell

Members
 View Profile  See their activity

  • Posts

    13,406

  • Joined

  • Last visited

 Content Type 

Everything posted by NathanKell

  1. NathanKell
    Dragon01: I'll try to get to it at some point. For now you can just use one of RO's nosecones, or if you need something sharper the HMX one from NovaPunch Beatmaster Hank: weird. So, is anyone else experiencing that issue? If not, I think it's probably an install issue.
  2. NathanKell
    jrandom: Cool! Try with the utilization value. See if anything breaks. If not, just use it. (They're an issue with autofill, I think, but it may not matter in practice).
  3. NathanKell
    There's a bug where an SPU on the same part as a crewed ModuleCommand will refuse to recognize local control. I filed an issue about it. For now you need to make sure your SPU is not in the same part.
  4. NathanKell
    Here is a beta of v7. https://www.dropbox.com/s/jugq79z6qdtiw6e/StretchySRB_v7.zip v7 == \/ == *Fixed balloon tank to no-surf-attach, lowered crash tolerance *Added Service Module super-stretchy *Added new conic tank by e-dog *Added technode-based radius limits by e-dog *Added nodeSizeScalar to support Realism Overhaul *Fixed node issue, where it was not set properly on load (affected procedural fairings and KJR). *No longer changes shader when KerbPaint present *Added new nozzles for the Stretchy SRBs by Tiberion
  5. NathanKell
    NotMyRealName: The way g tolerance works is in the readme. Basically, I track cumulative G damage. Relevant section: What's happening is that though your Kerbals can survive 13Gs for some time (~20 seconds probably), they've been at at lower G level for a while, so their cumulative damage has built up. Now, you subject them to 13Gs for more than a few seconds or so, and they conk out, because they've already suffered damage at lower G levels. We can get capsule lift: use CoMOffset = 0, 0, X in the part.cfg, where X is some small number like 0.06 for the Mk1-2 pod (play around and see what you get). Presto, ballast. For the 4m-size one in RO, I'm trying CoMOffset = 0, 0, -0.192
  6. NathanKell
    I'm very happy to change the ablation model. Here are the inputs: part temperature shockwave temperature degrees C applied to part per second (based on density), whose formula is: (shockwaveTemp-partTemp)^temperatureExponent * density^densityExponent * heatMultiplier Since DRE does not care about part size or mass or anything like that (at present), it deals in temperature (and temperature change), not heat flux. So. (1) if you have a formula for heat flux, that would be great. I can calculate frontal area by checking with FAR, and also ballistic coefficient. (2) with that, I guess I can switch to a different modeling of ablation, where there's a minimum ablation temperature and after that, check temperature change between frames and modify based on your rules. How slightly is slightly? Does it vary with shield material?
  7. NathanKell
    Fixed, thanks! Yes, I see what you mean: I guess frizzank decided to extend the side tunnels' lengths. Not getting what you mean about the decoupler though.
  8. NathanKell
    Ok, *that's* weird. I will check. Last I saw on mine it worked, but maybe I changed something else somewhere.
  9. NathanKell
    ferram: thanks! Will do. Yes, the model is correct: the retropack is tiny but the spacecraft adapter goes between booster and the max width of the capsule, and the Atlas did have different-length sides.
  10. NathanKell
    Look up ProgCom here. Does this, basically, IIRC.
  11. NathanKell
    That's not in stock Gemini. I added that because the SAS/RCS ring is now (per real life) the retro, and thus can't decouple itself from the pod, the pod has to decouple it.
  12. NathanKell
    ferram, can you take a look at the FASA Mercury? Especially the strap/decoupler for the retro pack. It seems to add a TON of drag, to the point where a built Atlas has a crazy-high CoP. I'm using this config, by me and Dragon01 (WIP): https://www.dropbox.com/s/89h5824hby2xsei/FASA.cfg But it'll probably still exist for the unrescaled part too.
  13. NathanKell
    The 10x increase meant a factor of 1.5 increase in Kerbin's atmosphere. Other planets are...other planets, and more different. The scale heights for all bodies are basically correct (Earth's is closer to 8.5, but 7.5 means the actual pressure at altitudes matches reality better). If you want a straight-up 6.4x rescale of the Kerbol system, I suggest multiplying stock KSP scale heights by ~1.25 maybe? That will still leave Duna with a far too small (and far too dense) atmosphere, for example, but it'll be an extrapolation of stock KSP in proportion to Kerbin's. You'll DEFINITELY want to comment out the Epoch line and all the MeanAnomaly lines
  14. NathanKell
    Posted. Again, NOTE: Be careful if you have craft on transfer orbits. If you do, and don't want the planets to move, comment out the Epoch and the MeanAnomaly lines.
  15. NathanKell
    papics: care to share? Those look really, really good.
  16. NathanKell
    Oh! And I forgot to say I fixed the solar panel issue. It only affected those with the 5.3 prerelease, I believe, but it's now fixed in the current prerelease above.
  17. NathanKell
    Changelog is: *Changed atmo editor to ALT-G *Fixed Mean Anomaly to be Mean Anomaly at Epoch, fixed handling of it to actually work *Added new root-of-config property Epoch, for setting starting date. Now, KSP year 0 is 1950. NOTE: If you have craft on transfer orbits, they may no longer be. Anything captured by a planet is fine though. *Support enabling/disabling atmosphere *Used metaphor's planet config changes *Added ability to change science parameters for all bodies (thanks to Medieval Nerd) *Fixed SOI not respecting minimums
  18. NathanKell
    5.2 has an issue, in that setting Mean Anomaly doesn't actually change anything (KSP reads it only on orbit initialization, and uses ObTAtEpoch ever after). I finally have that fixed for 5.3, which you can try here: https://www.dropbox.com/s/wmf25fyg35ju3ya/RealSolarSystem_v5_3.zip and which I will be officially releasing tonight, probably.
  19. NathanKell
    For coolz, obviously. And boy is it cool.
  20. NathanKell
    SOI does exist in real life. Though obviously real life has n-body physics, not me+1 body physics. http://en.wikipedia.org/wiki/Sphere_of_influence_%28astrodynamics%29
  21. NathanKell
    It's by HoneyFox. HoneyFox and I are working to make sure it will work with, or be integrated with, Modular Fuel Systems. But yeah, don't worry about this stuff--good luck on finals!
  22. NathanKell
    Cool! Less work for meee! That makes IACBMs 2m parts, which is right for the CBM, I believe. I was originally planning for 8m modules, actually, given what would have been launched from a Saturn-derived SHLLV (bwahaha). But 4m is right for ISS-class stuff.
  23. NathanKell
    jrandom: I thought consumption for TAC (like ECLSS) was in units per second? That's why your numbers were like that. You also might want to look at the excellent Atomic Rockets: http://www.projectrho.com/public_html/rocket/lifesupport.php SFJackBauer: that's for freeze-dried food, where ~1kg of that water is used to reconstitute it, IIRC. So, jrandom, you might want to do 1.62 and 3kg? Meh, who knows. You can easily back-calculate those numbers: WasteWater should be a bit more than water, CO2 should be a bit more than O2, and SolidWaste should be a bit less, such that sum(rate*density) for each resource for waste equals sum(rate*density) for each resource for consumption. Unless these astronauts are kids and still growing, they'll excrete what they take in, more or less
  24. NathanKell
    Afraid that's asked and answered upthread (IIRC): Mu has to fix something Squad-side for that to work. That was, actually, why I asked for the feature. But the root of GameDatabase is read-only.
  25. NathanKell
    Looking good! Dragon01 has some great suggestions above.
×
×
  • Create New...