undercoveryankee

We don't know exactly what causes SoI jumps, beyond the obvious fact that the code that determines what SoI a ship is in doesn't always agree with the code that checks future orbit patches for SoI crossings. The self-captures are probably because the jump took the satellite a fair distance inside the SoI boundary. You said in your mission report that an object that enters an SoI has to either exit at the same speed or impact. That's true if it enters at the actual boundary; the orbit is either hyperbolic or elliptical with an apoapsis outside the SoI, and either case is an escape. If it appears deeper inside the SoI, then it is only guaranteed to return to that altitude at the same speed, so if it ends up on an elliptical orbit an apoapsis between the appearance location and the actual boundary is possible. I have a hypothesis that phantom SoI hops happen because when the game checks a ship's location, it is checking the Mun's position after the current world update against the ship's position before, or vice versa. If so, the danger zone is approximately the distance traveled in one update at the highest warp level encountered. Mun and anything co-orbital with it have an orbital speed of 542.5 m/s. Assuming that positions of planets update on the "max physics delta time" setting and not on the constant 0.02s FixedUpdate clock, the tick is likely to be in the neighborhood of 0.04 s. 0.04 s * 542.5 m/s * 10,000x warp = 217 km that a ship could teleport into the SoI from outside due to update skew. As an idea of the scale, that's about halfway between 1 Mun radius and 10% of the SoI radius. Do you know how many kilometers outside the SoI your satellite was before it jumped?

Took me three tries to get a probe into Mun orbit. The first attempt I forgot to set the control surface tweakables. Runaway roll oscillations kept the vehicle from executing the intended pitch profile. Lawn dart into the ocean on Kerbin. Second attempt made it out of LKO into an impact trajectory, planning to adjust for a polar insertion just after SOI change. I didn't notice that the entire trajectory from before SOI entry to impact was in darkness. Ran out of power before the planned course correction and Mun dart. And to add insult to injury, the Interstellar seismometer didn't process the impact, apparently because I had renamed the probe with the seismometer on it.

I was a little surprised to see the mass driver and rock tank show up with techRequired = start. Is that planned to change down the road?

I noticed that I had an OpenResourceSystem_1_1_0.dll in my SCANsat folder (v7rc4). It seems to be fractal_uk's last release, and not the one by WaveFunctionP that everyone is using on 0.24. Is that safe to remove if I have ORS installed?

Downloaded and installed 1.4. The title of the settings window still says version 1.3.4.3.

I've seen roll oscillations fairly regularly. I think it's because a typical rocket has a smaller moment of inertia in roll than in pitch or yaw, so the same deflection of the control surfaces is enough to produce a lot more angular acceleration. On anything with reaction wheels in it, I just disable the roll axis on the fins entirely. Sluggish roll response is better for a booster than oscillations.

If you lock steering to ship:velocity:surface, you can't recover if something perturbs your heading to one side or the other. Maybe not a problem for what you're doing, but it gets annoying once you start trying to launch to a particular inclination. Here's the gravity-turn part of an auto-launch script I was just working on. I calculate the angle between ship:velocity:surface and up:vector, then lock steering to a heading() with a fixed compass heading and the calculated pitch angle. The numbers are for stock-size Kerbin with FAR. set initialPitch to 84. set targetAoA to -1. lock velPitch to arcsin(vdot(up:vector, ship:velocity:surface:normalized)). wait until ship:airspeed > 35. print "Initial turn". lock steering to heading(90,initialPitch). wait until velPitch + targetAoA < initialPitch. print "Maintaining AoA". lock steering to heading(90, velPitch + targetAoA).

In addition to WarpPluginSettings.cfg, you'll probably want to make the change in the ORS definitions and change or delete the LqdWater tank.

Spaceport was already unpopular when I started playing in February, so I got used to finding a mod's forum thread as the first step to finding where it was hosted and whether it was up-to-date.

As far as I can tell, the last released version of KESA assumes the "1 unit = 1 kerbal-day" density of Water from TAC 0.8 and below. If you're using it with TAC 0.9, you'll want to remove any lines that touch density, tank capacity, or consumption rates.

As of the TAC 0.9 prereleases, Water has the same density as Interstellar's LqdWater, so a simple search-and-replace in the WarpPlugin and ORS .cfg files should be enough to unify. I've been meaning to do the same conversion myself, but I haven't tried yet so I don't know how many files will have to be overridden.

I've seen Landed at the Water biome around the island airfield.

Easter egg in Toolbar.

Pu-238 is what RTGs use. Suspect that definition is in there from a time when Fractal was planning to add RTG depletion.

How important is it that the green reactors run on UF4 and the Sethlans/Akula series run on uranium nitride? Using the name EnrichedUranium would suggest a more abstract resource that represents uranium in whatever chemical form is appropriate to the reactor.

The only real use I know for running the reactors on ThF4 is to get unupgraded fissions to run hot enough to compete with the LV-N. If I care about that, I'm probably using a Sethlans/Akula reactor anyway because it's lighter and its max core temperature is even better than a green reactor on thorium.

My understanding was that tracking terminal velocity balances drag and gravity losses and is the most efficient way to do a vertical ascent as long as drag is mostly proportional to v^2 throughout the speed range of interest. It's not necessary for reference area to be proportional to mass. That result just becomes a lot less useful if you can pitch over early instead of slowly climbing straight out of the soup first.

Switching out KSPI's hydrogen and argon should be a .cfg-level search and replace, because the plugin uses whatever resource is specified in WarpPluginSettings.cfg and checks the density of the selected resource at use. Just scale the tank capacities by the ratio of densities. Since KSPI has only the one inconveniently-sized argon tank, I'd probably unify on NFT's argon. Hydrogen is a closer call because I'd like to be able to electrolyze water in KSPI's refinery and run chemical engines on it. Given a decent selection of chemical rockets that would use LiquidHydrogen, I'd switch KSPI to stop using LiquidFuel.

If you look at the Vernor's config file, ModuleRCS accepts a resourceFlowMode value that apparently overrides the mode set by the fuel's definition. The Vernor is indeed configured to draw fuel using the STAGE_PRIORITY_FLOW mode that monopropellant uses. MODULE { name = ModuleRCS thrusterTransformName = RCSthruster thrusterPower = 12 resourceName = LiquidFuel resourceFlowMode = STAGE_PRIORITY_FLOW PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True resourceFlowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = Oxidizer ratio = 1.1 resourceFlowMode = STAGE_PRIORITY_FLOW } Currently, all of the stock RCS parts have their fuel flow modes defined on the part. None of the engines that operate on engine controls have local flow modes set, so all of those engines (both O-10 and conventional LFO engines) draw fuel based on the fuel's settings.

Right. On the old versions of SCANsat that required a part to read the map, the button wouldn't appear unless you had the part. If you have the button, you have the functionality.

All I know is that SCANsat as of 7rc4 allows any vessel to use the map. No requirement for a part or communication device. The SCANsat maintainers haven't suggested an in-universe explanation. I'd go with "any command pod or probe core is capable of storing maps. You start with a copy of whatever was in the file at the time of launch, which is updated whenever communications permit." SCANsat doesn't try to keep track of what individual vessels know and always shows the current state of the map, so the explanation only really works if your vessels usually have access to communications. I sometimes leave the actual antenna parts off manned ships that aren't planning to transmit science, but in-universe I would say those ships still have voice-only radios and can ask KSC to look at the map and suggest coordinates.

Check out your network. If you're using high-orbit relay satellites, I wouldn't be surprised to see an extra half light-second of path distance over a direct-to-ground route.

2.2.2 is a real release. Just isn't in the first post yet, but it's in the thread a few pages back. Biggest change is hiding the GUI until you do alt+shift+F11.

The E is how scientific notation is represented in floating-point literals. So the real speed of light, defined as 2.99792458x10^8 m/s, would be written as 3.00e8 (or however many decimal places you want to use). Most languages will accept the E in either upper case or lower case, and will allow an optional "+" before the exponent (where the "-" would be if the exponent were negative). My freshly-generated RemoteTech_Settings.cfg has SpeedOfLight = 3E+08, so the real c is already the default.

You can add PhysicsSignificance = 1 to any part's .cfg file to remove it from mass and stock drag calculations. NEAR/FAR have to take the shapes of physicsless parts into account because of oddities like the 3.75m decoupler, and I don't think they give you any way to mark a part as dragless.