undercoveryankee

Isp is proportional to the square root of the core temperature, with coefficients that are different for each possible fuel. If you mouse over a thermal nozzle in the VAB, you'll see the coefficients for all supported fuels.

Sounds like what happens when the Kerbin-side relays are targeting "active vessel." If you're controlling the vessel with its dish deactivated, then your "active vessel" dishes aren't targeting the active dish on the other vessel any more.

The code that I can find simply requires the vessel's launch time to be after the contract was accepted. So you can't launch a satellite for a contract that's available to accept, then go back and accept the contract. For me, just doing any unmanned launch is typically enough to get that parameter to show green. There should be no reason you couldn't reuse a craft file if it had all of the instruments that the new contract called for. Check the contract's notes for the list of everything that the customer wants you to have. If you have everything, and that parameter is still showing incomplete after you've reached the required orbit and gotten the "orbital elements" and "neutralize controls" parameters green, share a save file so we can check the numbers. Make note of any mods that change or remove functionality from parts that the contract requires.

Are there any plans for how to handle the case where a part has more than one instance of the same PartModule? E.g. I've seen solar panels with multiple ModuleDeployableSolarPanel to handle all of their animations.

Best way I've found to communicate at those distances is to use two dishes in the 88-88/KR-14 class, targeted on different relay satellites. If doubling up is prohibitive for you for whatever reason and you have to use a single relay satellite, second best is to put the relay into a high polar orbit so it's eclipsed for a smaller fraction of the time. If you expand the flight computer, there's a field where you can manually add delay to commands on top of any signal delay that RT2 is applying on its own. Put "open antenna" and "close antenna" on separate action groups so you can fire them regardless of the antenna's current state. Estimate when you'll be in position to reopen your antenna, add a suitable amount of delay, and send the "open" command. Then, while the "open" command is in the queue, set manual delay back to zero and send the "close" command.

AgP is also counted from the ascending node, so if your inclination is close enough to zero that the position of the ascending node is not well defined, any drift in that calculation will also show up in the number that gets reported for AgP.

Argument of periapsis drift is due to game inaccuracies. In an exact 2-body orbit it would be constant. Some systematic bias is possible depending on how forces and errors interact with each other in your ship, but the only way MechJeb would be contributing is if RCS was firing for attitude control and you didn't know it. Regarding LAN, the equinox reference direction is where Earth's equator crosses Earth's orbital plane. In KSP, where the equator and the orbital plane coincide, there's no clear "physical" reference for the zero direction, but there are coordinates that the game uses internally. Zero celestial longitude is probably "the direction Kerbin's prime meridian points at the epoch". MechJeb gets position information from the game in the coordinates the game uses and reports your LAN relative to the game's zero direction.

NEAR uses Mach 0/infinite speed of sound. A while back, some people had suggested a drag model based on raycasting, pretending that incoming air moves in a straight line until reflected off a part. Ferram did a proof-of-concept to demonstrate the limits of that approach. The raycasting approximation roughly corresponds to the zero-speed-of-sound/mach-infinity case.

Wave's next planned release of Interstellar replaces families of similar parts in different sizes with single parts with TweakScale support. That will break any in-flight ships that use the removed parts.

Except for drag chutes, which can be set to auto-deploy on touchdown, the chute won't fire unless it's armed (by staging sequence, action group, or right-click menu). If you arm the chute by action group or right-click before reaching the configured pre-deployment altitude, it will remain armed and deploy at the configured altitude. There's a setting in the RealChute config file that allows you to add the same arm-and-wait-for-deployment-altitude behavior to chutes fired from the staging sequence. In most cases where you would want auto-deployment, you can get it to work by arming the chute as soon as you're above its deployment altitude. "wanted speed at target alt" and "target alt" are used to auto-calculate the size of the parachute canopy. If the mass of the ship under drogue is roughly what the editor was using, then when you pass through the target altitude you will have enough drag to be at roughly the "wanted speed." Controlling when an armed chute fires is done with the pre-deployment and deployment altitude settings.

I'd always heard that all meaningful terrestrial supplies of 3He came from tritium decay. The difference in price comes from differences in demand and from the fact that 3He is storable once you have it, while tritium decays. If there were a massive increase in demand due to sudden deployment of fusion reactors, the tritium supply would catch up with demand faster because tritium can be bred directly from lithium, while 3He is available only after the tritium decays. Pre-First Contract, it kind of made sense to have to produce your own tritium and 3He, because some of the missions you could do with fusion would use more fuel than has ever existed on Earth at one time. At least if the decay calculations were reliable enough that you could breed tritium and let it decay while you were doing other things. Now that we have Funds, the better way to handle known-but-extremely-rare isotopes is to give them a cost where it's possible to buy them, but manufacturing or mining them yourself is a good way to earn Funds for other things.

Inclination tells you how far from the equator the target plane is tilted. LAN tells you which direction it's tilted. So when you've fully matched the target plane, both numbers will necessarily be equal. Any plane change you make is likely to change both numbers at the same time, so it's easier to just burn when you pass the node markers for the target plane than to worry about the numbers separately. Practice matching planes with moons or existing satellites. (Minmus is guaranteed to be handy.) If you target an existing object, the game shows the node markers on your orbit so it's easier to see when you're passing them. Once you can do that, hitting a Fine Print target orbit's plane is just a matter of sighting along the two node markers and putting a maneuver node where your orbit crosses that line.

All of the relevant paths are already in Squad.cfg. All I had to do was wrap them in an OVERRIDES {} node. I'll share the diff this afternoon.

The longitude of the ascending node changes any time you make a plane change at any location except where you cross the reference plane. If you match the target plane by burning at the marked ascending and descending nodes, that will be enough to put you at the correct LAN. (It can be hard to see how close you are to the nodes since the markers appear on the target orbit and not yours. A trick that I've found is to focus the map-view camera on the planet, rotate your view so the points of both node markers line up, then stick a maneuver node on your orbit where it crosses the markers.) If you would rather use MechJeb to set your LAN, converting from FinePrint's decimal degrees to MechJeb's degrees-minutes-seconds is pretty easy. Multiply the fractional part of the degrees by 60 to get minutes, then multiply the fractional part of the minutes by 60 to get seconds. And you're right: a LAN of 353 degrees east is equal to 7 degrees west. Since the planet is rotating and the orbit isn't, LAN is measured from a particular direction relative to the background stars. On Earth, the zero is the vernal equinox: one of the points where the plane of the ecliptic and Earth's equator intersect. In KSP, where Kerbin's equator is exactly in line with its orbital plane, that type of reference doesn't work, so there's no clear visual reference for the zero. It may just be the direction Kerbin's prime meridian is pointing at the epoch.

RT2 doesn't change the physics significance of the antennas. It'll be the same as stock.

I can confirm that the development builds are.

It's been reported that there's a "Laythe_Karbonite_.png" that needs to be renamed to remove the trailing underscore. Typo while migrating to the latest folder structure.

I've looked at your logs, and I don't see ModuleManager loading anywhere. Exactly where is your ModuleManager dll located?

Wave's experimental branch has existed for a while before 0.24. Fractal comes and goes, so Wave just happened to be around to update his branch before Fractal updated his. There hasn't been any permanent change announced, and Wave will probably keep maintaining his branch just like he did before even if Fractal emerges with an update. So, in a nutshell, "official" is in the eye of the beholder right now.

What version of FinePrint are you running? Have you upgraded FinePrint since you accepted the contract? There was an issue with detecting the cupola that was fixed a few versions ago. If the cupola objective continues failing in contracts generated by the current version, post a log and a save file.

That's why signal delay is optional. If you'd rather hand-fly, you can pretend that you're the local autopilot.

I meant to suggest just going by period if you have easy access to display the orbital periods in question (KER, VOID, MechJeb). Since stock doesn't tell you your orbital period directly, but makes you calculate it from the times to periapsis and apoapsis, I went on to suggest how you might calculate a resonant orbit using numbers that are easy to get in stock and only require you to watch one number at a time while doing burns. The whole Kepler thing is "if you need to play without informational displays" advice.

You need to set the bus's orbital period to an appropriate ratio to the target orbits' period. For a 2000km target orbit, the best deployment orbit would have apoapsis at 2000km and period 3/4 of a 2000km circular orbit. The best way to do this is with a mod that can display orbital periods, but a quick attempt at running the 3/4 ratio through Kepler's third law says a 2000x1092 orbit on the bus will be pretty close.

What is the target of the relay satellite's dish? This sounds pretty similar to what happens when the dish that was communicating with your mothership was targeting "active vessel", so it no longer targets the mothership after you switch away. I hadn't heard of an "active vessel" situation working until the mothership was unloaded before, but I wouldn't be surprised to see it work that way, either.

There are two main differences between RT and real life: in RL, ground stations are easier to deploy than satellites, so the DSN can reach any probe that can point a high-gain antenna at Earth, and there are more fallback options like lower data rates or one-way communication to allow the DSN to communicate with a lower-gain antenna, so total loss of the ability to send recovery commands is rarer. I don't consider it RT2's fault that it encourages players to attempt interesting station-keeping configurations and discover that the game doesn't like them, even if it does lead you to decide you would rather play with something simpler.