OHara

@Geschosskopf started two threads reporting another symptom of using Hyperedit to go directly to orbit around another body. Launch a vessel comprising a Pod, Decoupler, and Tank. Using Hyperedit's Orbit Editor to go directly to Mun orbit at 100km above the surface, then decoupling, zeros the orbital velocity of the Tank. A quicksave at that point writes a quicksave.sfs showing the Tank as "landed=true". Workarounds: 1) Use Hyperedit's Orbit Editor to go into Kerbin Orbit, then use Orbit Editor again to go to the desired orbit. (Quicksave at this point shows no obvious clues to what went differently, but the workaround results in "rTrf = mk1pod (Untitled Space Craft)" in quicksave.sfs while the quicksave after going directly to orbit around the other body has "rTrf = mk1pod" ) 2) Use the built-in Alt-F12 Set Orbit (quicksave.sfs after Set Orbit has the longer "rTrf = mk1pod (Untitled Space Craft)" and has an empty "displaylandedAt = " where the quicksaves after HyperEdit show "displaylandedAt = #autoLOC_6002112" with the autoLOC symbol is the dictionary entry for "Launch Pad"

In the thread you linked above, @Plusck says he did not use Hyperedit, and @bewing would probably use the built-in set-orbit instead. Try yourself without Hyperedit.

That's the problem. I cannot reproduce in stock, I can reproduce with Hyperedit. That is, decoupled parts hover stationary to the parent body, assuming that is what you mean by 'krakensbane'. Hyperedit recently had a bug appear involving coordinates not being transferred correctly to the game engine. Maybe Hyperdit's 'set orbit' feature is putting the craft in a state that is inconsistent according to the rules of version 1.3.1. By the way, you can set orbits now with the Alt-F12 menu. You can check craft mass in the VAB engineer's report and 'i' in the map view.

I had been avoiding the small converter, but just tried it now, and find it does not overheat as its documentation implies. It stabilizes somewhat above optimum temperature with 2 drills running. The converter stays cooler for me with a 5-star engineer than without one, even though it is producing 17 times the output with that engineer. I shut down the radiators to see what would happen, and it continued to work up to 3000K core temperature at which point its thermal efficiency reaches zero. I see no thermal shutdown in version 1.3.1. If our only problem with the converters were that we find some of the game-balance choices to be aggravating, we could change the rules to make the game we like. Unfortunately, their behavior is complicated and mysteriously documented and has suffered many bugs, some of which are fixed, leaving a system that is very hard know how to use. Now I simply include the mining equipment that I think is reasonable, and save-file edit the fuel tanks to full when I think mining should be complete.

Dihedral in the wings is the classic solution. First, though, if you have a large vertical stabilizer on the tail, you should try to reduce its size. and make sure it is above the center of mass so it gives a little bit of correction to roll. When the plane slipping to the side, there are forces that make it yaw into the relative wind, and those that make it roll away from the relative wind. If the yawing forces are relatively larger, you spiral. With the center-of-lift and center-of-lift indicators turned on the in SPH, you can select the root part and shift-A to yaw it 5°, and see how the moved center-of-lift is trying to turn the craft.

There is also the induced drag from the lift (the kinetic energy left in the down-wash of your wake, per unit length of wake) which is a separate entry 'L-I-D' in the aero-gui, just below your screenshot. At low speeds, the lift-induced drag is relatively higher. I think 'L-I-D' plus individual parts' drag adds to the displayed total.

No. AllisTa (who adopted the TCA mod and maybe others) investigated and found out that KSP now tries to put the seed in localized number format, which uses scientific notation for numbers larger than 7 digits. (Generally we do not want numbers in save-files to be localized, written 3.1416 or 3,1416 depending on user location, because they are primarily computer-read and we want to be able to exchange them.) @allista included a work-around mod in his utility package; see the bug-tracker entry for details (making yourself a login if needed) or his github. That work-around will preserve asteroids so long as you have a save un-corrupted by 1.3.1, or at least the seed. Note that I was wrong initially to imply that only old saves were affected. @Squelch's work-around above will not work in general -- save/load cycles in 1.3.1 continue to generate fresh asteroid shapes, until the random number generator happens to generate a 7-digit or shorter seed.

@fatcargo Waypoints are now integrated with stock KSP, so you can right-click on the waypoint in KSP's Map View to get the options { Activate Navigation / Delete Waypoint } @DMagic Now might be a good time to redefine the fields-of-view in the more standard way that KerbNet uses. ScanSat currently defines "field-of-view" as half the range of latitudes that a satellite will cover when at its "best altitude" over Kerbin. The usual definition, the full angle of the imaged region measured at the satellite, is used by KerbNet. Then the half-range of latitudes is just θ = FoV × h / 2 R, which scales the same as current ScanSat for altitudes h below the best altitude. This geometrical rule scales more strongly with R than the sqrt(R) in ScanSat's code, covering more latitudes on small bodies. You could put the sqrt() back in, but I would just let the upper bound θ < 20° take care of game-play balance; small moons have weak gravity so the orbital velocity is slow when you are high enough to hit the θ < 20° limit -- scanning small bodies is certainly not too easy in ScanSat. Looking at the configuration files, I see that the radar altimeter sees 50-km-radius from 5km altitude (!). If we want to keep that behaviour it doesn't fit the model of a specified angular FoV from the sensor very well. But the other sensors fit reasonably. TYPE Δθ min best max FoV MULTI ±4° 5km 250km 500km 20° RADAR ±5° 5km 5km 500km [90° with best alt. 10km] SAR ±2° 5km 750km 800km 3° ORE ±3° 10km 150km 500km 24° M700 ±5° 15km 150km 1000km 40°

I see the same problem with the tutorial. If I let the tutorial stop my burn from the Mun when my apoapsis is 100km, and then circularize near 100km above the Mun, then I get the Next button and can continue. So you could restart the tutorial and just let the tutorial auto-stop your burn (probably what the software testers did). Or, you could ignore the frozen instructions and re-enter without the benefit of instructions.

At least version 18.1 was being blocked under the label Trojan:Azden/B!cl but is no longer blocked by my Win10 system (which loads updates in the background). Edit: ScanSat 18.1 was functioning on my Win10 system when I made this post, but now Windows Defender quarantines SCANsat.Unity.dll and SCANsat.dll again under the same label as before. There is an option in Windows Defender Antivirus to exclude known-safe files from its attention.

Only if you include multiple types of probes. I remember you said you were avoiding game-play-changing modifications, but if anyone else wants to play by different rules, a more direct way to increase the detection rate is with a Module-Manager patch:

I suggest that you post here to tell people what works and what doesn't, and what you liked about it. Few people post about KerbNet here, so this thread is likely to come up if new players search for information. I suspect that no-one has used KerbNet to accomplish anything, or there would be more mention of the bugs:

There is a bug report for this.

ScanSat marks the anomaly locations precisely, except for those that are part of a group of structures. The mark for a group of structures is at the center the group. ScanSat uses data from the game, so I would expect KerbNet intends to show anomalies precisely as well. The few times I have used KerbNet, it showed the '?' within 50m of what I would consider the center of the anomaly, except all of KSC was one anomaly centered on the crawlerway. Beware the KerbNet bugs with large field-of-view. The '?' is projected wrongly, so as you approach an anomaly, the '?' on KerbNet approaches you, until you and the '?' meet at the anomaly. For what you are starting to do, the mod ScanSat seems worth installing. Instead of watching for anomalies that may or may not appear, with a roll-of-the dice once each day, you put a scan-satellite into an orbit that eventually sweeps the planet.

I was wrong to imply that only older save-files show the issue. Newly-created games also spawn asteroids with shapes that change. After a few saves/loads the asteroid settles into a stable shape. I put a pure-1.3.1 quicksave.sfs on the bug-tracker that gives a differently-shaped asteroid on every F9. Strangely, Squelch was not able to reproduce the issue using the steps I gave. Maybe something specific to Windows 10 or my localization settings ? It would give me peace of mind if someone else can confirm the bug using the safe-file on the tracker, or these steps : To reproduce:Scenario "Asteroid Redirect Mission 2: ready to capture" Screenshot asteroidQuicksave / ReloadNote asteroid shape has changed

No. The shape of the orbit determines how long it takes to complete an orbit, assuming that by 'orbit' you mean the free motion under gravity; to take the path faster of slower would require continuous thrusting. You will need to thrust forward into a higher orbit, which takes longer to complete, to let the target catch up to you ---figuring your much higher by trial-and-error, using the manuever nodes intercept marks in the game, or pre-computing with Kepler's law if you like --- and then slow back down when you meet it.

Yes. Asteroids from older (1.2-ish) save-games change shape in KSP 1.3.1, but these asteroids did not change shape in the 1.3.1 preview. https://bugs.kerbalspaceprogram.com/issues/16087

Good. With the canard on the cockpit, a similar layout has enough aerodynamic authority to hold 45° on re-entry, so you can use your fuel to get to Minmus.

The 2000-K temperature limit of the Mk1 cockpit makes it difficult to use at the front of a spaceplane, where it takes the shock heating. It is easier to reenter using the inline Mk1 cockpit, with some higher-temperature part at the nose. The 2600-K RCS port on the nose of an Mk1 nose-cockpit can help a lot, by making a shock cone that clears the cockpit, but only on the way up where the angle of attack is small. Aerodynamic surfaces, tilted a large angle to the airflow, help a lot to lose energy in something other than heat. I was happy once to arrange an Mk1 spaceplane with tail-fins that would deploy so far that the plane was stable at 120° angle of attack, coming down somewhat tail first. I think an angle of attack greater than 45° might be necessary to get a typical Mk1 plane to slow down without overheating. You might move the canard further forward, until the plane is near-neutral stability, and then use its 'deploy' button to deflect it 150% on re-entry. Splitting the vertical stabilizer into two fins, usually passive but deployable in opposite directions, could make a nice upper-atmosphere airbrake.

What you are doing makes perfect sense for finding the best interplanetary leg of the trip. What you might want to try next, is to leave a probe or even debris in orbit around the Sun, near Kerbin in its orbit around the sun. You can set a maneuver node on that probe to show the path to your next interplanetary destination (whether the probe has fuel to get there makes no difference for the planning node). Then when the planet Kerbin reaches the maneuver node on your probe, you launch your real ship into low-Kerbin orbit, and plan a burn from low orbit that joins up with the probe's planned interplanetary transfer. Boosting into the transfer trajectory by burning while moving at high-speed in low orbit raises the ship's kinetic energy to the needed amount with significantly less fuel spent -- the Oberth effect -- as Deddly pointed out. That probe was marking the transfer path and showing where Kerbin is at the 'transfer window', so when maintaining a probe in solar orbit becomes inconvenient, you will probably want to use an out-of-game transfer-window planner to find the right time to launch.

Same is true in the stock game. Outside a spherically-symmetric source of light, the flux should decrease as 1/r² with r the radius from the center of the source, but in KSP solar flux decreases as 1/(r - 262Mm)² so it is hotter in close than one would expect. The solar flux at Moho is 11% more than it should be so absolute temperature about 11%/4 = 3% warmer. Looks like an oversight, so this seems more of a minor bug report than a suggestion for improvement. I don't see one yet here.

At high altitude drag seems to be relatively more important, so the aerodynamic center moves forward despite the lifting surfaces in the back. I also noticed the shuttle tends to tumble around 20km altitude. Once you are stable again, SAS off, control surfaces limited to 30%, trimmed for nose about 4° above prograde, leftover monopropellant can stretch the glide somewhat, and the game is to adjust your path without turning so far as to be a draggy brick. After playing around with it, I don't think the atmosphere is too soupy. This shuttle might be easier with lower global scaling of low-speed drag coefficients, but then other aircraft will float even longer.

I think that earlier I had understood you backwards. I thought you meant you float down the length of the runway while slowing down to the strangely low stall speed of 30m/s (i.e., too much lift at low speed). Did you mean instead that drag decelerates you more quickly than you expected (too much drag) ? I found your SSM-X3 and tried it. It flew final approach nicely* at 90m/s on a 15°--20° glide-slope. The flare slowed me to 70m/s, then it slowed down very quickly and I couldn't float very far at all. That seems to be how a shuttle should behave, slowing quickly upon the steep nose-up flare. I do find it strange that 6-tonne jets in KSP lift off at 40m/s, 80kts, but I have to admit that the various numerically-unrealistic parts of game are reasonably balanced.

Now, be nice. The only way to feel the atmosphere is through the lift and drag coefficients, so one cannot tell if the atmosphere is too thick or the coefficients are unrealistically large. (I suppose one could use the debug menu and compute the density from the dynamic pressure and craft speed.) The discussion didn't suffer much from not mentioning whether kerbal airs weighs 1 kg/m³. Other aspects of KSP differ from real aircraft, notably the mass of parts (the 1-man cockpit alone weighing more than a Cessna 172)) and thus the wing loading. Light single engine aircraft have wing-loading about 70 kg/m²; airliners, 700 kg/m². I looked through my KSP craft and found from 260 to 1800 kg/m². The lightest KSP aircraft have numbers more like a learjet, 280kg/m². Stock KSP lets it takeoff and land at 35m/s, as a Cessna 172 would, but then at cruising speed it flies more like a learjet. It is helpful to discuss what 'feel' people would enjoy.