Entropius

Members
  • Content count

    281
  • Joined

  • Last visited

Community Reputation

85 Excellent

1 Follower

About Entropius

  • Rank
    Sr. Spacecraft Engineer
  1. That's probably because that feature wasn't always there. I believe they added it in version 0.23.5 (the patch that added asteroids). If you make use of that feature a lot, I recommend installing Precise Node. You can go into its settings and tell it to replace the ±1k second buttons with +Orbit and –Orbit. It's extremely convenient.
  2. Oh wow, people are commenting here. I originally posted this in 2014, and hadn't seen a reply in years, so I never bothered to check on the thread except for making occasional tweaks. Anyway, regarding the question of the docking camera: Chiron0224 is indeed right, those are docking alignment mods. They're not technically cameras though, although there is another mod for that out there somewhere. I don't prefer true camera mods because docking alignment indicators actually offer more information than a camera would. For instance, pitch and yaw alignment is much more precise with the mods I discussed (Docking Port Alignment Indicator & Navaball Docking Alignment Indicator). I personally prefer the former. Regarding the question of when to use each technique… I can offer some general guidelines (but don't take them as hard-rules either). Hohmann Transfers are a good default option for transferring from one circular orbit to another circular orbit. But as the starting or ending orbit becomes more eccentric, it gets more annoying/tedious as the maneuver's prograde ∆v must be repeatedly re-adjusted as you drag the maneuver node around. Orbit phasing techniques on the other hand seem to handle high-eccentricity rendezvous rather nicely so long as you can get the tangent-point lined up right. But Orbit Phasing's efficiency varies a bit more than Hohmann Transfer efficiency. Orbit phasing, if done very carefully and patiently, can be almost as efficient given the right circumstances, but can also be significantly worse. IMO, where Orbit Phasing really shines is when you want to rendezvous with another ship immediately upon arrival at another planet/moon. That's because capture burns typically put you into an eccentric orbit that gives you an phasing orbit with a long period to play with. Assuming the relative-inclination adjustment is reasonably cheap, the Orbit Phasing can basically be as just efficient as a Hohmann Transfer when arriving at a body. Regarding the choice between the two flavors of Orbit Phasing, if you can do the more efficient one, always do it. The less efficient one (the one with the radial burn) is just easier for beginners to setup the tangent point. There's really no advantage to it beyond that. Parallel Orbit rendezvous is arguably the most simple from a conceptual standpoint. Ships in higher orbits go slower. Ships in lower orbits go faster. If you get two orbits lined up inclination-wise, and have a tiny difference in altitude, very slowly drift near the other… eventually. You can also think of this being technically equivalent to a Hohmann Transfer with a very tiny transfer-maneuver. The major downside to this technique is that it's painfully slow. We're talking a rendezvous that can take literally days. So from a gameplay standpoint, I don't like this technique at all. It's only redeeming quality is that it's really useful for docking very low-TWR ships together. For example, docking with big, heavy, fully loaded fuel-tankers. It's nice for for that scenario because the fuel tankers can't really spin the ship around 180-degrees easily to burn the main engine for steering the final approach, so small precise burns are nice in that situation. If the difference between the initial orbits is small enough, final approach can be done via RCS-translation thrusters. Also some trivia: I totally made up the name of this technique. As best as I could tell, this technique is not used in the real world and thus had no name. So I made a name up. If anybody does find documentation of this technique having a real-world name, feel free to tell me. Regarding launching guides, I doubt it's necessary to diagram, it's trivial enough to explain textually: If your rendezvous target is in equatorial orbit, launch whenever you want to, it makes no difference. If your rendezvous target is in a significnatly inclined orbit you must launch your ship directly into the inclination of the orbit of the rendezvous target. You'll probably have to do a tiny inclination adjustment once in orbit, but hopefully not much. It's made easier by (1) double-clicking Kerbin (or whatever body you are launching from) in map view so the camera centers on it instead of your ship and then (2) zooming out your camera enough to see the target-ship's orbit. Then (3) while keeping the camera above the equator, orbit the camera around the planet until the target's orbit appears to become a thin diagonal line. In other words, you want the camera positioned exactly above where the target's orbital plane slices into the equator's plane. Then (4) wait for the body to rotate such that the launch-site lines up with the point the camera is facing. Then you just tilt the rocket northward or southward upon launch by the right amount. Kerbal Engineer lets you see your relative inclination, and keeping that number near zero helps you fine-tune the inclination as you launch.
  3. Oh hi, thanks for the name-mention! I probably should have noticed this post a month ago but I haven't been logged in for a while so I didn't notice it for a bit. >< It's always nice to see the old rendezvous guide helping people, although I should probably mention I maintain an updated version of it here, and it's significantly more refined, not to mention I added 3 more efficient alternative techniques alongside it.
  4. Okay, fair enough. I guess in all my years of GIS I've so rarely seen somebody deliberately choose 0-359 intervals in lieu of ±180 intervals, so I assumed it was a formatting error. But upon looking to it, there is some precedent for 0-359 intervals in the case of planets that are not Earth. Wikipedia: Planetocentric Longitude Anyway, I also thought I'd give you a heads up since I see you're calculating geodesic distances using the Haversine formula. If you ever get bad answers from that, it's probably because the points are antipodal, which it's ill-condiioned for. Vincenty's formulae suffers similarly. Meanwhile Spherical Law of Cosines is ill-conditioned for short distances. Karney's solution avoids any such problems, and suffers an error of less than 15 nanometers and calculates faster than Vincenty's (pdf). But with it just being a game and all, I'm not sure it's worth that much effort
  5. I think I've stumbled upon a bug. The KSP wiki and Kerbal Enginner Redux both list the space center's longitude as being around 74 degrees. But Waypoint Manager lists it as being about 285 degrees. I'm curious as to what could be causing this. Screenshot Player.log
  6. Has anyone else had problems making a stock interstage faring close when the part you're trying to close the faring against is the bottom of a PP tank?
  7. Can anyone tell me what I'm doing wrong, and why this doesn't work? @PART[radialLiquidEngine1-2] { @MODULE[ModuleEngines] { @atmosphereCurve { @key,1 = 0 335 @key,2 = 1 285 @key,3 = 9 0.001 } } }
  8. Ah, so there is a way to fine-tune the dry mass. Thanks! Also the suggestion to change the liquid-only and oxidizer-only tanks to have the same amount of respective fuels (rather than using the 9:11 ratio between the two) is more physical than what I previously did (not that stock tanks are totally realistic to begin with). Where I decided to depart from your suggestion is here: Rather than 0.1089 for the dryDensity (which gets PP tanks to be closer to stock, but not quite exactly there), I found a better value: 0.10864979. This gets the dry mass of a 1.25 wide by 1.875 long tank to be exactly the same as stock: 0.250 kg. And the jumbo orange tank and same-sized PP tank have the same dry-mass and fuel-units too. Anyway my new config looks like this: @PART[proceduralTankLiquid]{ @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[Mixed]{ @dryDensity = 0.10864979 // default=0.1089 } } } @PART[proceduralTankLiquid]{ @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[LiquidFuel]{ @dryDensity = 0.10864979 // default=0.1 @RESOURCE[LiquidFuel]{ @unitsPerT = 1600 // previously 1280 } } } } @PART[proceduralTankLiquid]{ @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[Oxidizer]{ @dryDensity = 0.10864979 // default=0.1 @RESOURCE[Oxidizer]{ @unitsPerT = 1600 // previously 1563 } } } }
  9. LiquidFuel and Oxidizer have the same density. They're just consumed by engines unequally (9:11 ratio). From http://wiki.kerbalspaceprogram.com/wiki/Liquid_fuel “Liquid fuel tanks contain both liquid fuel and oxidizer while fuselages contain only liquid fuel. Rocket engines using liquid fuel and oxidizer use a volumetric mixture of 9 units of liquid fuel per 11 units of oxidizer. All but the Oscar-B Fuel Tank store liquid fuel and oxidizer in this ratio. Jet engines use intake air in a volumetric mixture of 1 unit of liquid fuel per 15 units of intake air. Because all three resources have the same density the volumetric ratio is also the mass ratio.†The goal isn't realism balance. It's about conforming to stock. With the adjustments I proposed, PP tanks hold the same amount of fuel as stock ones. EDIT: Here's some before and after screenshots to illustrate the difference: Before: After:
  10. Problem/Issue: The FL-T400 holds 180 units of Liquid Fuel and 220 units of Oxidizer. The PP LFO tanks (1.25 diameter by 1.875 length), holds 180.4 and 220.5 of LF and O respectively. So PP and stock are pretty much in agreement given same-size tanks. The MK1 fuel tank holds 400 units of LiquidFuel. But a PP LiquidFuel-only tank (no oxidizer) only holds 294.5 units of LiquidFuel (not approximately 400). The tank only lets you carry 73% of what it ought to. Why are stock LiquidFuel-only tanks so much better than PP's? Solution: unitsPerT for PP LiquidFuel tanks should be changed from 1280 to 1739.13 (significant buff) unitsPerT for PP Oxidizer tanks should be changed from 1563 to 2125.603 (significant buff) unitsPerT for PP Mixed tanks should be changed from (720 / 880) to (718.2761 / 877.893) (negligible nerf) This will result in PP liquid tanks having the exact same amount of fuels as their same-size stock counterparts (although dry-masses will still negligibly differ). To temporarily test these recommendations, you can apply this cfg patch: @PART[proceduralTankLiquid]{ @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[Mixed]{ @RESOURCE[LiquidFuel]{ @unitsPerT = 718.2761 // previously 720 } @RESOURCE[Oxidizer]{ @unitsPerT = 877.893 // previously 880 } } } } @PART[proceduralTankLiquid]{ @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[LiquidFuel]{ @RESOURCE[LiquidFuel]{ @unitsPerT = 1738.375 // previously 1280 } } } } @PART[proceduralTankLiquid]{ @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[Oxidizer]{ @RESOURCE[Oxidizer]{ @unitsPerT = 2124.681 // previously 1563 } } } }
  11. Well there is at least one benefit from tying names to specialization: If a name appears between two different saves, they'll end up with the same specialization. Jeb is always a pilot, Bill is always an engineer, etc. That consistency is probably in-line with why they choose consistent planets rather than random planets between saves. In any case, I don't see names and profession being correlated as being a mutually exclusive issue. If you get unbalanced specialization in a batch of applicants, the game could just re-roll names until it is balanced. Anyway, I'll point out something that I just noticed: If you wait long enough (several days) eventually applicants roll off the list and get replaced by new ones. It can take a while though, so it wasn't immediately obvious to me that was an option. So this suggestion is probably less important than I originally thought, less of a "problem" and more of an issue of convenience.
  12. I realize an astronaut's specialization is tied to their names, and names are supposed to be random, but random isn't necessarily diverse. It would be nice if we could be ensured that this can't happen: http://i.imgur.com/oHbmfPx.jpg I'd rather not have to murder my Kerbals to get specializations I need. Maybe we should have separate tabs for hiring scientists/engineers/pilots, or maybe the list should just try to add new applicants of a specific specialization.
  13. I'll second what rasta013 said: I don't see any other issues. Once the two case-sensitivity issues get fixed it should be perfect. The new textures look great (especially the Titan III).
  14. Another issue I just noticed is that the Destiny texture was missing, and the cause is again related to case-sensitivity. In the config there's "Destiny_NRM", but the actual file is a lower-case "destiny_NRM.png". Changing the name in the config or of the actual image so that they agree gets the texture to show up again. Anyway, it's all easily fixable. Although I imagine a new release with both these fixes would be warranted so that new users don't have to fix it themselves.