Jump to content

NonWonderDog

Members
  • Posts

    116
  • Joined

  • Last visited

Posts posted by NonWonderDog

  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:

    IOTOSFa.jpg

    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:

    Javascript is disabled. View full album

    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.

    BmXqN4x.jpg

    07mHiEr.jpg

    UWQozYs.jpg

    No, no, no! The flag's in the wrong place!

    0O03Ede.jpg

    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. I'm not sure I understand that bit, at least not the gameplay part: the LV-T45 seems to be balanced as a mid-stage engine with a lower thrust to weight ratio, but with thrust vectoring (which you need higher up as you can just use fins lower down). If the ISPs were reversed, you'd end up with a mid stage engine with no thrust vectoring, and a lifting engine with crappier thrust to weight.

    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. Out of curiosity, what actually IS realistic in this situation? I've always thought of the Terrier as an analog for the Apollo LM engines--would those really have been 75% less efficient in atmo? I know some engines are optimized for atmo and some for vacuum, but is the difference really that big? I'd have guessed more like 25%.

    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. Just to add, the real nerva had 333.6 Kn of thrust, 850 isp, weighed 34 metric tons when empty, and was about 10 m wide and 40 something m long. So maybe moar thrust for our tiny scaled down nerva wouldn't be unrealistic.

    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. 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.

  10. 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.

  11. My first was in the first experimental with the Mun, I think, but I have pictures of this one:

    Javascript is disabled. View full album

    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.

  12. Okay. Looks like too many things are tuned to deal with instant gimbals. I will remove that fix in the next download and see if there is another way to reduce SAS wobble. Until I can fix the download, please delete the EngineGimbalFix directory.

    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.

  13. Also the stats of parts moved towards realism as well. That went completely out the window in the name of balance. (e.g vacuum engines have the power of hair dryers on Kerbin)

    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.

  14. The ratio is all wrong of course, though (11:9, should be something like 1.8:1).

    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.

    As an example, the FL-T400 tank is (by specification) 1.25m in diameter, and I estimate it's length at about 1.875m (it's about 1.5 diameters long). That would give it a volume of roughly 9.2 m³ ; 9200 L. It's in-game volume is 440L. You could assume that as the tank is slightly narrower in the middle part (the ends flare out a bit), it would lose some volume, and also you could assume that the walls have some thickness to 'em and such, but that doesn't make up for the 20:1 discrepancy, unless the tank is a solid block of metal with just a tiny hole for fuel in it's middle..

    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.

  15. Wow, I've apparently been using RealChutes for so long that I forgot that the stock radial chutes didn't have any risers. Anyway, the parachute angle probably needs to depend on the mesh geometry somehow, because if you use parachute models with risers (i.e. Ven's Stock Revamp) they stick out at ridiculous angles. If that's not possible it's probably enough just to make the angle configurable.

    Even better if the angle would change between reefed and unreefed.

  16. I've had plenty of planes (especially if really over-engined) that would smoothly accelerate to Mach 0.5-0.8 as you would expect, and then accelerate from there to Mach 4 or 5 in about a quarter second, with the engine exploding along the way.

    I only noticed it on the J58, though. It's been a few months since I messed with it, but a small plane with two J58s would work just fine at high altitude and afterburner, and would work just fine at low altitude and mil power, but would produce near-infinite thrust at low altitude and afterburner. I'd have almost two seconds to reduce throttle from 101% mil thrust before the engine exploded due to high Mach, but MUCH less time at full burner.

    This is too far removed to really be a bug report, obviously, since it's been months since I fired up Kerbal. I just wanted to affirm that the issue is or was real, at least at one time, and in combination with who-knows-how-many other mods.

    Actually, I remember poking around the engine definitions and playing with the EngineSim applet a bit, and I seem to remember finding that EngineSim didn't include any modeling for afterburners except for the case of zero-bypass turbojets. That might be the root of it.

  17. @NathanKell

    If you configure the Exit Area for an engine right, it should perfectly reproduce the sea-level ISP of any real engine. It's just a matter of determining the right Exit Area (which the simplest solution is to geometrically compute, but for a 100% accurate solution you have to make some corrections for things like boundary-layer separation, so you can always tweak it for a given engine until the performance at full-throttle matches the real thing...)

    The the equation I posted above is the one that describes real engine performance at different ambient pressures and throttle settings in real life, so as a rule it *HAS TO* reproduce the real performance, unless there are major deviations like, as I said, boundary-layer separation, or drastic over-expansion of the exhaust stream...

    Regards,

    Northstar

    Your equation assumes 100% nozzle efficiency. Real nozzles don't have 100% efficiency, even without anything dramatic. And for any vacuum nozzle, you will have something dramatic (I think that's the equation that says most vacuum engines have negative thrust at sea level).

    You can put an efficiency term in there (really you need to define things in terms of pressure recovery first, but whatever), but then you have to know the nozzle efficiency of each engine you want to simulate. You're not going to find that data. The best you can do is estimate it from the chamber pressure, mixture ratio, and expansion ratio, given the published Isp. Or I guess you can assume it's an 80% cone rao optimum (about 97.8% efficient), which is pretty close for most US-built engines. But not Russian engines -- they follow a different profile, and are maybe (maybe not) more efficient.

    These details don't really matter for KSP, but you can't "perfectly reproduce" measured performance with that equation.

  18. Karbonite uses nodes like this:


    MODULE
    {
    name = REGO_ModuleResourceConverter
    ConverterName = LFO Mix
    StartActionName = Start LFO
    StopActionName = Stop LFO
    RecipeInputs = ElectricCharge,6,Karbonite,4
    RecipeOutputs = Oxidizer,0.275,False,LiquidFuel,0.225,False
    }

    RecipeOutputs isn't a number, so it can't be multiplied. You can use RecipeOutputs[2] in a variable, but maybe not as the target of an assignment? ":\([^,]*\),[.0-9]*:\1,0.3:" would be the way to replace the second field with 0.3 in Vim, but I don't know the equivalent Module Manager syntax or if it would be applied once or as many times as possible. Even so, I wouldn't want to change the second field, I'd want to change the first field after "Oxidizer". With a regex this would be something like ":\(Oxidizer\),[.0-9]*:\1,0.3:", but that still doesn't *multiply* the second field by a number.

    Anyway, this is all academic. I don't need to do this, because I'm not changing the LiquidFuel and Oxidizer ratios. If I was I'd rather write some kind of compatibility plugin.

  19. Yeah, a regex replacement is enough to change the names. I'm sure I can work out a regex to change the ratios, too, or I probably shouldn't be allowed to call myself a Vimmer. Something simple like

    @RecipeOutputs ^= :LiquidFuel,[.0-9]*:Kerosene,0.625:

    But I don't see an obvious way to modify the ratios in Module Manager, as in multiply one of them by 1.5. It might actually be impossible, but I'm willing to bet it can be done with enough regexes. Somehow.

    If you can save the result of a regex in a variable, and then use that variable in a regex, it should be pretty easy. But I don't think you can do that.

    Or if you could use a variable to index an array, and multiply an indexed variable by a constant, you could still get at it. But you can't do that either.

    I think you'd have to write a multiplier in regex (it's just barely possible, I think), assuming that nobody would use more than 6 digits or something. It might take fifty or so expressions, and there's really no excuse for not writing a new plugin at that point.

  20. Karbonite, for one, and Karbonite's resource converters are very difficult to edit with module manager (I haven't worked out a general way yet).

    Various IVA props by various modders use LiquidFuel and Oxidizer levels to show fuel gauges.

    I think there's a Station Science sub-mod that uses LiquidFuel to run science experiments.

    In general, I don't want to have to know about every mod that might use LiquidFuel and Oxidizer for something other than engines and write a compatibility config for it, nor do I want every other mod author to have to know about NearFuels and spend time writing the compatibility config himself. It's easier just to live with an imprecise name.

  21. Changing @Name doesn't alias, it replaces it with an entirely different resource.

    Yep, there's no way to add an alias. It could probably be done by building off of KSPAPIExtensions to take a guiName field for each resource, but you'd have to re-implement a lot of classes. I'm not familiar enough with the Kerbal API to even know which ones. You can change all the engines to use your new resource instead, but there's a lot more than engines that uses resources nowadays.

    For compatibility's sake, LiquidFuel is called LiquidFuel and is mixed with Oxidizer in a 55/45 O/F ratio (by units, not mass or, indeed, volume). Changing the mass of a unit will change Karbonite balance a bit, but I don't think it breaks anything. Changing the volume per unit definition (nominally 5 L/u) makes fuel tanks very confusing to set up, but doesn't have any other ill effects.

    So I have some leeway, but things are most straightforward if we stick to 5 liters per unit -- or at least the same definition for both LiquidFuel and Oxidizer. NTO/UDMH works great here since, in addition to being the world's most common storable propellant, it can be burned at a 55/45 volume ratio with decent efficiency (that's a 2.22 mixture ratio, whereas optimal is 2.5-2.7 but several spacecraft run at 1.9 so the tanks can be the same size).

    It would be kind of nice to keep LiquidFuel as fuel for jets as well as rockets, if only so that fancy IVA fuel gauges still work, but I don't see an easy way. NTO/Kerosene burns at a 70/30 volume ratio, while HTP/Kerosene burns at an 80/20 volume ratio. (Christ, 80% of your propellant would be high test peroxide...)

    The Oxidizer as HTP idea would require that HTP be stored at around 16 L/u, while Kerosene is stored at 5 L/u. A 100 unit tank would hold about 25+20 units instead of 55+45 units. I don't think the benefit is enough to make up for the annoyance.

×
×
  • Create New...