Entropius

I really like the parts in this mod. That said, I noticed that whenever I use an OPT J Deployment Bay and try to launch from the runway, it seems the spaceplane doesn't spawn on the runway, but rather 1000 meters above the ground (which thus far has been relatively catastrophic, albeit amusing ). Has anyone else noticed this?

Is it just me or do the buttons that are supposed to snap the maneuver node to the Ascending Node and Descending Node not always work when you're targeting a moon? I can target Minmus, and the DN Precise Node is snapping to is not the one indicated by the DN marker. (I'm guessing it's using the absolute-DN rather than the relative-to-target-DN?)

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.

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.

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.

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

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

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?

That fixed it, thanks!

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

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

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:

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

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.

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.

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

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.

Can anyone figure out why the latest version of FreedomTex textures isn't working with the latest version of PP? EDIT: Nevermind, rasta013 figured it out in another thread. Apparently it was a case-sensitivity issue.

I'm seeing the same problem. EDIT: Rolling FreedomTex to the previous version seems to work with the latest Procedural Parts.

In a previous incident, in another thread, I was told this should never be necessary and to always use the version of KSPAPIExtensions.dll that is bundled inside a mod, and to only update the dll that is at /Kerbal Space Program/GameData/KSPAPIExtensions.dll. But with that being said, disregarding that advice has fixed a problem for me one time in the past (in my case an old KSPAPIExtensions.dll inside another mod was breaking stuff). The other time I attempted this, I actually froze KSP on the startup screen. So I'd advise against it unless you're out of options. You shouldn't necessarily expect the trick to work.

From the log it appears that your Procedural Parts might be out of date, as well as KSPAPIExtensions. It's PP version 1.1.3, and in PP 1.1.4 it's internal copy of KSPAPIExtensions was updated. I've seen version issues related to KSPAPIExtensions cause those parts of the action-menu vanish in previous versions of PP, so maybe that's it.

For anybody who's curious, I found a partial solution. I had to delete Tweakable Everything (which CKAN was not autodetecting), launch CKAN, Refresh, quit CKAN, delete EVAManager.dll, relaunch CKAN, refresh, then tell CKAN to install EVAManager.dll itself and Tweakable Everything. I think the problem might boil down CKAN crashing whenever you manually delete an auto-detected mod that's a dependency of a CKAN-insalled mod. Others may want to verify this. I'm also trying to figure out how to delete my auto-detected Module Manager so that I can have CKAN manage it, but manually deleting Module Manager and refreshing CKAN doesn't seem to be noticed by CKAN, and it seems to still think it's there. Any help on that would be appreciated. EDIT: I'm also finding that removal of auto-detected BahamutoD Animation Modules crashes CKAN too. But I can't figure out how to work around that one.

CKAN was autodetecting EVAManager.dll. So I decided to remove /GameData/EVAManager.dll and refresh CKAN. Unfortunately CKAN crashes on Refresh every single time. If I put EVAManager.dll back where it was, crashing stops. So basically CKAN won't let me do what I need to, to get it to manage this mod for me. Is there something I can do to fix this short of having to remove all my mods, and reinstall them again with CKAN?

Thanks for the answers Captain Sierra & RoverDude. In regards to this: Does that mean all other parts besides the NERV have some default-threshold they use to by virtue of not having an explicit threshold in their config? (if so, what is the default-threshold?) Or that radiators just ignore all other parts?

Some questions regarding Stock radiators versus Heat Control radiators, which one is... More or less difficult to manage? Or does it vary by situation? More or less realistic? Would real radiators only have access to the heat they immediately attach to, or is it also realistic to assume you could have a network of cooling pipes that can bring heat from any part of the ship to the radiator? Are both realistic, but just different? Which is more powerful in terms of raw heat-removal? Is there even a significant difference? Or do they both prevent explosions equally well in practice? I ask all this because I think it provides some much needed perspective on the whole A,B,B1,C question. Also if both are merely different, yet equally realistic and powerful, then I think it might slap some perspective into people who are getting too invested in the stock-vs-HC debate. It might not be as big a deal as some are making it out to be. How significant are the in-practice consequences of one system versus the other? Also, I think answering these questions would help some players figure out if they even need/want to use HC given the stock options now. A lot of us were brought to HC by sheer necessity to avoid engines exploding. And some people try to balance their functional needs with RAM consumption. Nertea's models are great, and I love the insulator parts and heat pipes, but if stock radiators prevent explosions just as effectively, it would be nice to know.