Jump to content

NonWonderDog

Members
  • Posts

    116
  • Joined

  • Last visited

Reputation

62 Excellent

Profile Information

  • About me
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You don't even need to be doing something odd to have the problem come up. The control axis of the landers is upwards, which works fine until you go to "yaw" (roll on its axis) from IVA and find that the rudder is reversed. Almost every time I try to do an IVA landing in one I end up crashing because at some point I forget that my twist-stick is backwards and I panic. Control directions need to be more configurable in general. Not just the navball direction, but which axis counts as roll or yaw and in which direction. Changing the lander control axis to forwards would solve the IVA controls issue, but then the navball wouldn't be very useful as a landing aid. The Plane Mode mod helps a lot with aircraft (it swaps roll and yaw for anything built in the spaceplane hangar), but it only solves a narrow range of problems.
  2. What's everyone's problem with the 0.9375 m docking ports? That's the ring diameter on the stock docking ports -- these just don't have the flared base to bring them out to 1.25 m. In fact, I would have hardly batted an eye if you had just flat-out called these "1.25 m docking ports". See: They don't actually mate that way in game, though, since they're set to dock to 0.625m ports instead of 1.25m ports (a mistake?). You can fix that, of course: @PART[Tantares_DockingMechanism_A|Tantares_DockingMechanism_B]:BEFORE[AdpativeDockingNode] { @MODULE[ModuleDockingNode] { @nodeType = size1 } } Going in the other direction -- if you have AdaptiveDockingNode installed, this config will make the male and female ports dock only with each other. In this case they won't dock with androgynous ports any more. @PART[Tantares_Port_A|Tantares_DockingMechanism_A|Alnair_Port_A|Agena_Port_A]:AFTER[AdaptiveDockingNode] { @MODULE[ModuleAdaptiveDockingNode] { %Gender = male } } @PART[Tantares_Port_B|Tantares_DockingMechanism_B|Alnair_Port_B]:AFTER[AdaptiveDockingNode] { @MODULE[ModuleAdaptiveDockingNode] { %Gender = female } } Use both configs, and 0.625 m probes only mate with 0.625 m drogues, and 0.9375 m probes only mate with 0.9375 m drogues. Personally, I vote for banishing the 0.625 m docking ports entirely -- a Kerbal can't fit through them. There are a lot of parts to change, though... And while I'm making wishes, I wish for a 0.9375 m duplicate of the Advanced Grabbing Unit that looks like Kontakt.
  3. To celebrate the new release, I took a cue from HGR and added some stock fairings to the Soyuz escape tower and the TKS docking module. Soyuz is almost perfect now: All I need is a part that flares to just beyond the radius of the service module to attach the fairing to, and it will be perfect. Perfect except, of course, that I can't fit the solar panels in the fairing and the Soyuz boosters smoke constantly on the launchpad. Here's the config: @PART[Alnair_LES_A]:FINAL { @category = Utility @stagingIcon = SOLID_BOOSTER @MODULE[ModuleEnginesFX] { !atmosphereCurve {} atmosphereCurve { key = 0 215 key = 1 245 key = 7 0.001 } } } @PART[TLV_LES_A]:FINAL { @MODEL,0 { %scale = 1.25,1.25,1.25 } %rescaleFactor = 1 @category = Utility @stagingIcon = SOLID_BOOSTER @node_stack_bottom = 0.0, -2.0, 0.0, 0.0, -1.0, 0.0, 1 MODULE { name = ModuleProceduralFairing nSides = 32 nArcs = 2 TextureURL = Squad/Parts/Aero/fairings/fairings_diff panelGrouping = 3 pivot = 0,-1.5,0 axis = 0,-1,0 baseRadius = 0.3125 maxRadius = 2 capRadius = 0.3 snapThreshold = 0.05 xSectionHeightMin = 0.05 xSectionHeightMax = 2 edgeSlide = 0.15 edgeWarp = 0 noseTip = 0.6 UnitAreaMass = 0.03 UnitAreaCost = 6 ejectionForce = 50 } MODULE { name = ModuleCargoBay DeployModuleIndex = 0 closedPosition = 0 lookupRadius = 0.75 } @MODULE[ModuleEnginesFX] { !atmosphereCurve {} atmosphereCurve { key = 0 215 key = 1 245 key = 7 0.001 } } } @PART[Alnair_Crew_B]:FINAL { @MODEL,0 { %scale = 1.25,1.25,1.25 } %rescaleFactor = 1 %stageOffset = 1 %childStageOffset = 1 MODULE { name = ModuleProceduralFairing nSides = 32 nArcs = 2 TextureURL = Squad/Parts/Aero/fairings/fairings_diff panelGrouping = 3 pivot = 0,-0.05,0 axis = 0,1,0 baseRadius = 1.26 maxRadius = 2 capRadius = 0.375 snapThreshold = 0.25 xSectionHeightMin = 0.3 xSectionHeightMax = 5 edgeSlide = 0.15 edgeWarp = 0.00 noseTip = 0.5 UnitAreaMass = 0.03 UnitAreaCost = 10 ejectionForce = 50 } MODULE { name = ModuleCargoBay DeployModuleIndex = 0 closedPosition = 0 lookupRadius = 1.25 } } I put some slightly more realistic Isp numbers on the escape towers to help the burn time, fixed the staging icons, and put the LES in the utility category, but that's not important. The fairings work without that. The tricky part is that stock fairings only work with parts at rescaleFactor=1, so I had to add some model scaling. To make the fairing stick with the abort stage instead of separating you have to launch, revert to editor, and detach and then reattach the service module. It's a weird bug, but a useful one sometimes. An aside: shouldn't the 0.9375 m docking ports be "size1"? They match the other size1 ports perfectly, but definitely not the size0 ports.
  4. Today, I used quicksave and quickload. A lot. No, no, no! The flag's in the wrong place! The control tower took forever because the gimbal solver apparently didn't like my design. It wouldn't roll in a hover, and trying to roll made it yaw in the opposite direction instead.
  5. At least building big pointy rockets, thrust vectoring is most important in the first stage. Especially strap-on boosters need to gimbal, since otherwise you don't have any roll control. In the second stage the rocket's just following prograde, and rarely needs to steer at all. If you're using just 1.25 m parts you can do things pseudo-Soyuz style with an LVT-30 core surrounded by LVT-45 strap-ons. An LVT-45 sustainer surrounded by LVT-30 boosters looks worse, has no roll control, and doesn't have much directional control. It's hard for me to find any real use for a powerful non-gimballing rocket engine at all, but it's worst as a first-stage lifter engine. With all the magic torque in the game, though, it sort of works on lighter upper stages that can turn themselves. That said, asparagus staging and moving fins on launch vehicles seem so weird and silly-looking to me that I usually don't even consider them if I can solve a problem traditionally. Those change the picture a lot. In any case, I think "better vac Isp" vs "gimballing" is a more interesting trade-off than "imperceptibly-greater thrust and marginally lower weight" vs "gimballing AND better vac Isp".
  6. The Apollo Descent Propulsion System had a chamber pressure of 100 psia, had an expansion ratio of 47.5:1, and ran on a 1.594 mixture ratio of N2O4 to Aerozine 50 (50% UDMH, 50% Hydrazine). Pop those numbers into Rocket Propulsion Analysis Lite using the default efficiency coefficients and you get a vacuum Isp of 316 s. That's only a couple percent better than real life, so so far so good. The predicted sea level Isp is... -925 s. What's going on here? Well, there are two components to thrust. First is the momentum thrust, massflow * exhaust velocity. Equal and opposite reaction, etc. The second is the pressure thrust, (exit pressure - ambient pressure) * exit area. (These terms are actually inversely proportional, and max thrust (greatest Isp) is when the pressure thrust is zero.) In a vacuum the flow expands to fill the entire nozzle, and the nozzle exit pressure of the Descent Propulsion System is only 0.01 bar. If the flow expanded to fill the whole nozzle at sea level, the pressure thrust would overwhelm the momentum thrust term, leading to negative thrust. Literally the naive prediction is that the rocket engine becomes a gigantic vacuum cleaner that sucks itself backwards... by blowing in the same direction. Obviously, this doesn't actually happen. The flow separates from the nozzle, like the flow over a wing separates near stall. The result is the effective exit area is much lower, but a lot of the energy of the propellent goes into turbulence in the nozzle. This is bad, by the way. The flow is unstable and the thrust goes off in random directions. It might even shake the nozzle to pieces and cause an explosion, or burn a hole in the nozzle wall and cause an explosion. RPA Lite includes a simple flow separation predictor, but this case is a bit too extreme. It still predicts a sea level Isp of -95 s. So how much thrust would the Descent Propulsion System produce at sea level? Very little. It might not even light off. At 5 km it might have an Isp of 60 s or thereabouts. Compare that to 308-311 s in vacuum. I really like the new engines, by the way. My only real complaint is that the Isp values on the LVT-45 and LVT-30 are swapped. They make a lot more sense realistically, visually, and gameplay-wise the other way around.
  7. Made a Kerballed Mun landing using just two "Spider" engines the other day... initial Munar TWR of 0.9. I wanted to see how far I could push it, and that turned out to be just about the limit. It landed with a TWR around 1.25. It was a 9 minute full-throttle burn from low Mun orbit to the surface, but it was high-precision and nerve-wracking enough not to be boring. So that's my recommendation for long burns, I guess. Heightened Mortal Danger. I'm not sure how generally applicable that is. (Actually, it took something like 40 minutes factoring in all the quickloads and Kerbal death...) More seriously, I just have two monitors. Run KSP with the "-popupwindow" command-line argument and it's perfectly happy to run on one of them in a full-screen window.
  8. Common mistake: you're quoting the numbers for an entire Nerva-driven rocket stage, including a hydrogen tank the size of the space shuttle's. The bare-bone engine would have been more like 7t. Not only that, but there wasn't really anything like "the real NERVA." There were about a dozen completely different ground test engines, but they never built a free-standing flight-weight version. The weight you sometimes see quoted for, say, NERVA XE-Prime (18 tonnes) apparently includes a good amount of mounting and support structure, tankage, instrumentation, and extra-heavy radiation shields. Flight weight was supposed to be around 7-8 t for the 245 kN, 847 Isp, 2.6 m diameter final design. BUT, I have no idea if the 7-8 t includes radiation shielding. I think the ground shields for testing were 4.5 t, but any flight shield would be much lighter. Modern alloys are lighter. The 25 klbf PEEWEE-derived engine in the NASA reference Mars mission was supposed to weigh something like 3.3 t, produce 111 kN of thrust at 900 Isp, and have a 1 m thrust chamber (and a 1.7 m diameter engine bell). That's perfectly Kerbal-sized, but nothing like that was ever actually built. Sources are hard to come by, but here's a 20 year old NASA review: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19930017729.pdf
  9. Does SAS-Reset actually do anything anymore? As far as I can tell all of its functionality and more is now stock. It even switches to stability control if you fall below a threshold ground speed (to prevent flipping during landing in retrograde hold). All the mod seems to do is prevent the "Launch our first vessel!" contract from completing.
  10. I definitely prefer the new liquid engines, if only because Squad is finally using realistic Isp numbers. The engines are all right in a believable range for LOX/kerosene or NTO/UDMH rockets, which makes balancing mod parts much easier. But they really need to do something about solids. They were always worse than they should have been, but they hardly even have a purpose now. You can buy model rocket engines with better Isp. Kerbal liquid engines vs. some close real-life matches: | Engine | Thrust | Mass | Sea Isp | Vac Isp | | ------------------------ | ------- | ------ | ------- | ------- | | LVT-30 Reliant | 215 kN | 1.25 t | 280 s | 300 s | | LVT-45 Swivel | 200 kN | 1.50 t | 270 s | 320 s | | RD-0110 (Soyuz) | 298 kN | 0.40 t | ~260 s | 326 s | | ------------------------ | ------- | ------ | ------- | ------- | | RE-M3 Mainsail | 1500 kN | 6.0 t | 285 s | 310 s | | RD-275M (Proton) | 1833 kN | 1.26 t | 285 s | 317 s | | ------------------------ | ------- | ------ | ------- | ------- | | LV-909 Terrier | 60 kN | 500 kg | 85 s | 345 s | | SpaceX Kestrel (Falcon 1) | 30 kN | 52 kg | -- | 320 s | | SpaceX Merlin 1D Vac | 800 kN | 500 kg | -- | 340 s | In general, Kerbal liquid engines (like all the other parts) are super-dense to balance them against the tiny, super-dense planet. That's fine. It's actually hard to find anything comparable to the LV-909, because most real-life rockets in that thrust class are solids. The Poodle and Terrier are similar enough to LOX/methane rockets that one might conceivably build for Mars Direct, though, so I have no problem with them. My only complaint is that the Isp numbers on the LVT-30 and LVT-45 are backwards. The LVT-30 clearly has the bigger vacuum nozzle, and should make more thrust because of that, and yet the LVT-45 has lower sea level and higher vacuum Isp. Kerbal solid engines vs. stuff in the ATK catalogue: | Motor | Thrust | Mass | Burn Time | Isp | | ----------- | ------ | ------- | --------- | ----- | | RT-5 Flea | 192 kN | 1.2 t | 5.7 s | 150 s | | RT-10 Hammer | 227 kN | 3.0 t | 15.7 s | 162 s | | Orion 38 (Various) | 32.7 kN | 872 kg | 71 s | 287 s | | Orion 50 (Pegasus) | 115 kN | 3.35 t | 75 s | 290 s | | ----------- | ------ | ------- | --------- | ----- | | BACC Thumper | 300 kN | 6.0 t | 26.5 s | 180 s | | Orion 50XL (Pegasus XL) | 158 kN | 4.3 t | 71 s | 291 s | | Orion 50S (Pegasus) | 467 kN | 13.4 t | 75 s | 292 s | | ----------- | ------ | ------- | --------- | ----- | | S1 SRB-KD25k Kickback | 670 kN | 23.25 t | 52.1 s | 190 s | | Orion 50S XLG (GMD OBV) | 583 kN | 16.11 t | 69 s | 272 s | | RSRM (Shuttle) | 10811 kN | 569.4 t | 122 s | 268 s | | ----------- | ------ | ------- | --------- | ----- | | Sepratron I | 18 kN | 72.5 kg | 5.0 s | 154 s | | STAR 5CB (Titan IV) | 2 kN | 2.4 kg | 2.7 s | 256 s | | STAR 8 (MER) | 7.5 kN | 5.1 kg | 4.3 s | 273 s | | STAR 17 (Delta/Atlas) | 10.9 kN | 79 kg | 17.6 s | 286 s | | Estes E-30 | 33 N | 45 g | 1.0 s | 189 s | Solids are balanced completely differently from liquids. Kerbal solid rocket motors have similar masses to real-life solids, but they have laughable specific impulse. That's probably a decent balance trade-off for first-stage boosters, but it makes solids completely useless for anything else. If you have to lift it, you need better Isp than 150 s. The thrusts are somewhat higher than real-life solids of the same size, but the real-life ones are engineered with specific grain patterns to keep thrust down. We have tweakables for thrust, so I have no complaints there. The Orion 50 series are 50 inch diameter (1.275 m) solid rockets, so are pretty closely comparable. The Pegasus is an air-launched vehicle, though, so the motors have oversized nozzles. The ground-launched versions have an effective Isp around 270 s. The Kickback is half-again as long as the ORION 50S XL, and taking that into account it's a very realistic thrust and weight. The Isp just sucks. The STAR 5CB is a real-life stage separation motor. It's puny. A trio of STAR 8s each were used as the landing motors for Sprit and Opportunity. The STAR 17 is an old apogee kick motor that weighs as much as our sepratron. The Estes E-30 is a $16 model-rocket motor. Even the Estes motor has better Isp than the Sepratron. Heck, it has better Isp than any Kerbal solid rocket motor bar the Kickback.
  11. Okay, there's a massive bug with the plus component of ModuleControlSurfaceFix. I'm not sure what the conditions are, but ailerons placed on a traditional planform aircraft are almost always reversed. Elevons on a delta wing seem mostly fine. It's particularly weird if you fly the stock Stearwing A300. The ailerons at the ends of the wings are reversed, but the inboard and mid-wing roll control surfaces work as normal. The result is that the wing flexes, but there's no roll control at all. With "plusEnabled = False" in ModuleControlSurfaceFix.cfg the problem is gone.
  12. My first was in the first experimental with the Mun, I think, but I have pictures of this one: Using the first (?) release of the KW Rocketry pack, I think, and at about 6 fps the whole way. Unfortunately, this attempt ended in tears and four little Muns rolling sedately along the surface of the Mun. No quicksaves back then, either.
  13. It seems this is mostly just a problem with the chosen speed, not the gimbal speed limit in the abstract. 2 degrees per second is unrealistically slow and eats up too much stability margin in the controller, but with it set to 10 degrees per second I don't really have any issues. It certainly looks better than instant movement, too. You should also probably use the '%' syntax so module manager doesn't add the keys twice if another mod adds these first. i.e.: @PART[*]:HAS[@MODULE[ModuleGimbal]] { @MODULE[ModuleGimbal] { %useGimbalResponseSpeed = true %gimbalResponseSpeed = 10 } } Although as this is a bug fix mod, all the module manager configs should probably be tagged ':FIRST' anyway. The '%' or not doesn't really make a difference then.
  14. That part, at least, is much more realistic than it used to be. For an engine with a 100:1 bell on the end, a sea-level Isp of 50 or less is perfectly reasonable. In order to gain an extra 40 Isp in vacuum you pretty much have to give up any possibility of operating in atmosphere. The visual models of the engines don't match that at all, unfortunately. Also, THANK YOU devs for finally making engine thrust vary with Isp.
  15. It's not, really. NTO/UDMH mixture ratios vary from 1.9 to about 2.7 by mass, which is 1.0 to 1.45 by volume. Although the individual masses are wrong, the 1.22 volume ratio fits right in the middle of the range. I don't think anyone actually runs a NTO/UDMH rocket at a 2.3 mixture ratio (what we have), but whatever. (Capsules and top stages sometimes use 1.9 so they can use the same size tanks for both propellants. Launch vehicles run as close to max combustion temperature as they can (around 2.6-2.7) since the engines are easy to cool and NTO/UDMH doesn't really burn all that hot compared to the alternatives.) As an average value the Kerbal mixture works out, and mixture ratio generally doesn't make more than a few percent difference in rocket performance anyway (design-wise, that is -- mixture going wrong during a mission is about as disastrous as you can get). You probably can't run a jet engine on UDMH, but UDMH and kerosene are near enough the same density. We can just assume that "LiquidFuel" is whatever parts UDMH or Kerosene you need to run your rockets or jets for as long as you end up running them. (You can actually build a kerosene/NTO rocket, but you end up needing something like 70% NTO by volume -- so that's not it.) It's a bit more of a stretch, but an LFO tank with no Oxidizer in it gives us a fuel density close-ish to methane for the nuclear engines, too. The showstoppers for realistic masses are the everything-elses, not the fuels. Capsules, cockpits, structural parts, and fuel tanks weigh 2-3x as much as they should. The fuel tanks are the easiest to compare: dry fuel tanks in KSP weigh 11% of their wet mass, while the tanks on most real-life launch vehicles (Ariane, Proton, and Soyuz at least) hover around 6%. Stuff like Atlas V and the Shuttle Super Lightweight External Tank are down to 3.5%. Except it's worse than that. Kerbal masses were balanced to make the rockets "look right" taking off from tiny super-dense Kerbin, but the balance of each individual part is completely ad-hoc. You can't really divide all the masses by 2.5 and have something reasonable, especially once you start thinking about all the mod parts out there. Check your math here, it's pi*r^2*h. If a unit is five liters, the FL-T400 volume (400 units) is pretty spot on. 2000 L capacity out of ~2300 L total volume.
×
×
  • Create New...