Streetwind

Been a long long time since I touched KSP1... but looks like my favorite mods are still alive and kicking. Feels like coming home

For what it's worth, I am not currently getting any errors when I load this together with USI-LS and MKS. I do get a one-time message that complains about the presence of incompatible mods when I create a new save, but only then. Future loading of the savegame or jumping around in different scenes ingame does not cause the warning to reappear. I expect this is just a part of Kerbalism and will always complain, though the amount of features disabled by the Science Only profile should result in a good chance of removing any actual incompatibilities in practice. Fingers crossed, anyway. I've not actually played yet, still setting up mods. But if/when I get around to playing for a while, I'll report back how it goes.

The act of going from the status "under thrust" to the status "not under thrust".

Could you guys check on your end if the landing gear does other weird stuff when this "physics kick" happens? Such as changing its extension length? I've had that happen to me. In fact, it's been a major headache because the legs always turn out way shorter in flight than in the VAB, frequently making stable landings outright impossible. If this is another face of the same bug, feel free to merge my report into this one.

Reported Version: v0.1.3.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i5-4670K | GPU: Nvidia GTX 1060 6GB | RAM: 16GB Severity: Medium (no known workaround other than not using the part) Frequency: Every time Description: Back in v0.1.2.0, I tried making the smallest possible rocket that could do a crewed Duna land-and-return mission. Upon its first test flight, I landed on Duna and things immediately went wrong, because my landings legs were too short. The craft sat on its engine bell and kept tilting/rolling uncontrollably. I was pretty sure I had aligned the landing legs correctly in the VAB, but apparently I must have made a mistake, and so I earmarked this craft for revisiting. But then I left the game be for a while, waiting for updates, and never got back to it. Now in v0.1.3.1, I finally went to look for my mistake. Lo and behold: in the VAB, the LT-5 "Bandicoot" landing legs were correctly mounted after all, and extend well beyond the engine bell (see screenshot 1). I even took them off and reattached them to make sure there was no weird holdover bug from a previous version. I then launched the thing into space, and extended the legs. At first, they faithfully extended to their full length (see screenshot 2). But just after reaching full extension, they suddenly jerked back into a much shorter state (see screenshot 3). At the same time, the whole craft got jolted out of alignment, until SAS brought it back. The craft file is attached. Then I built a simple test rocket (also attached) and yeeted it into space - the same problem maifests there. It happens reliably every time I extend these landing legs. (I did not test with other kinds of landing legs.) Potentially related to this bug report, but I'm intentionally creating a separate one because I am not sure. Landing gear in both cases, but the parts are different, the phenomenon is somewhat different, and it's planes versus rockets (which, as seen in the inline drag bug, can make a big difference!). Included Attachments: ...Welp, the attachments didn't attach correctly - guess I should have zipped them up right away, but it did allow me to add multiple files in the form so it looked like it would work... Either way, here's a zipped archive on my dropbox.

I've always wanted an engine between the Spark and the Terrier (even in KSP1, where I installed a mod to get one), so I'm gonna be all over the Cornet. The cool animation and high Isp are just a bonus.

Right... so, there are two things going on here. One, your center of lift is too far behind the center of mass. You want to have them roughly on top of each other, just a little bit behind. If it's too far behind, all the lift goes towards lifting your tail only, while nothing carries the nose. This makes the front of the plane flop forwards/downwards. Additionally, you have a single engine mounted on top, not in line with the center of mass. This means the engine thrusts past the CoM, thereby inducing torque that tries to turn the entire plane around the CoM like a jet-powered spinning top. In your case, that torque goes into the same direction as the plane's natural inclination of flopping nose down due to the misaligned CoL, so both effects add to each other and ensure you cannot ever pull your nose up. Take a look at this guide. It's for KSP1, so disregard any comments about the aero/physics model, but the basic design principles still hold true in KSP2.

Yes, all antennas are omnidirectional at all times, regardless of vessel orientation or model shape.

Since the commnet feature is not on any roadmap, it's hard to tell you to wait for it. We don't know when it'll get additional work done. It may take a long time, or it might not. It could be part of the science update. For the longest time, in KSP1, the only purpose of antennas was to transmit science results back home. Tying control to having a stable link back home came much later. And many of the antenna's stats, like bandwidth and power usage, remained only relevant to science transmission all the way to the end. But, again, it's not mentioned on the roadmap item for the science update. ...Come to think of it, I have no firm proof that Kerbin has 360° connectivity in KSP2 at the moment. I thought it did for sure, but then I remembered that I turned off commnet functionality in the difficulty options like two days after early access launch, because back then there was a bug where unmanned vehicles would lose connectivity and become dead in the water the moment the stage with the probe core in it became the active stage, even if you were right above KSC. And then I never turned it back on again. But this should be a really easy thing to test for. Just put a probe in LKO and see if it maintains connectivity across a full orbit. (And yes, the only way to test for whether you're getting a connection or not right now is watching your probe lose control.) Vessels do not occlude signals, only celestial bodies do. The game doesn't model anything like different frequencies or the like, regardless of how the antenna looks. It's all just a binary "connected" or "not connected", based entirely on line of sight, in which vessels are ignored. KSP1 did however have a config setting where planets with atmospheres were treated as smaller than they actually are for purposes of signal occlusion, to simulate bouncing the signal around the curve of the planet via the atmosphere. Not sure if any such effect is present in KSP2. Even further than that - I don't know if KSP2 even has this distinction or not. Maybe someone else already tested it and can say for sure, but as I mentioned I've turned commnet off.

Congrats on your space station and refuelling flights, looks great! But I need to quickly interject before you put a lot of work into something that'll only end in frustration. That satellite you've shown there? That may well not work for a communications network. I'm not 100% sure it won't work, but given the "sort of there but not really" implementation status of the commnet feature, the probability is high. You really need to run a test before you spend time deploying dozens of these. It's not that you made a mistake. Given the information available ingame, you chose antennas according to your needs. But if we assume that KSP2 just cloned the KSP1 implementation (or just copied it over wholesale and changed some range numbers), there may be additional factors to antennas that the editor simply isn't showing you. For example, you'll notice that for many ranges, there'll be two antennas - one of which will be significantly heavier than the other, despite there being no difference in stats whatsoever. In KSP1, that was because not all antennas could actually be used as a comms relay. There were "direct" antennas, which were light and frugal with power use, but could only talk to KSC. They could be bounced through a comms network, but they could never be part of one. There were also "relay" antennas, which had the same range but were heavier and required more power, and only those had the ability to act as relay stations in a comms network. The Communotron-16S you chose? Not a relay antenna. In KSP1, it wouldn't be usable in a comms network. (And yes, even though it is three times as heavy as the regular Communotron-16. It was an outlier. It had these stats because it was a strengthened variant resistant to aerodanymic forces, for use on planes or re-entering spacecraft, where a regular antenna might snap off.) Second point, antenna combinability. If you've read the relevant KSP1 wiki page, you may have seen that multiple antennas on the same vessel will add their strength together to increase the vessel's total comms range. Given the much higher ranges on antennas in KSP2, I'm not sure if you actually need to combine antennas for a Kerbin SoI commnet... but just in case this was something you were factoring in: the 16S, being an outlier, was the only kind of antenna that you couldn't combine. Ergo, having two of them on the satellite in the screenshot is just aesthetic, it doesn't actually improve the range. Third point, antenna strength. Any comms network you deploy around Kerbin will remain almost completely unused. That is because vessels prefer connecting to the strongest antenna they can see. And the strongest antenna around, by a very large margin, are Kerbin's ground stations. They are gigantic, and can draw whatever power they want - so they are orders of magnitude more powerful than vessel-mounted antennas. Any vessel that can see Kerbin will connect directly to Kerbin, always, completely ignoring any and all commsats in Kerbin orbit. The only time one of your commsats will be used is when a vessel cannot see Kerbin. Meaning, when it is in a Mun or Minmus orbit, and currently behind the moon, so it occludes Kerbin. As a result, what you really need is not a comms network around Kerbin, but rather one around the Mun, and one around Minmus. I mean... you can still build one around Kerbin anyway, for the challenge It just won't do anything. I recommend that you do a test run to see whether these assumptions carried over from KSP1 still hold water in KSP2. Specifically, you should test if your Communotron-16S equipped satellite can relay at all. To do this, put one in a high Mun orbit, and then have a vessel in a low Mun orbit where it will be cut off from connecting directly to Kerbin. See if it'll bounce through the satellite. Use an uncrewed craft for this, so the game will actually tell you when it loses connection.

Oh yes, there are numerous bugs with the dV display in the editor. For example, the mass of Kerbals inside cockpits is counted incorrectly (added only to wet mass but not to dry mass). Then, using multiple different engines on the same stage appears to cause the editor to report significantly less dV than there actually is (I had this effect with a Dart on the bottom of a couple tanks, to which I then added a pair of Thuds. Which halved the reported dV in the editor, but the vessel still made orbit just fine). You've just found another. And there are more besides. If you're ever unsure about whether the editor is showing you the truth, you can always sanity-check it by solving the rocket equation yourself. For a single stage, it's not even complicated. Detach everything below the stage you want to check, but leave everything above in place Note down the entire vessel's mass, let's call it m0 Empty all the fuel tanks that this stage is supposed to empty during its operation Note down the entire vessel's mass once again, let's call it m1 Bring up the Windows calculator (or equivalent tool on your OS of choice). You may need to set it to scientific, if it isn't already. Divide m0 by m1 Press the "ln" key once (that's the natural logarithm, if you're wondering) Multiply by 9.80665 Multiply by the vacuum Isp of the engine(s) on this stage The result is this stage's true vacuum dV The only part where this can get complicated is if you're mixing engines with different Isp values on the same stage. In which case you first need to calculate the average Isp, which unfortunately needs to be weighted by thrust contribution. So, for each individual engine, you would multiply its Isp by its thrust, and write that number down. After doing that for all engines, you sum up all these numbers, and then divide the result by the total thrust of all engines combined. If your own math is one or two m/s off, don't sweat it. That's an acceptable error. If your result is a two-digit number or more off, then something's fishy. Either with the editor, or with the math you used.

No way to see commnet connections, no. The system is borderline unimplemented. I'm honestly surprised it's working at all - it serves no purpose at the moment and wasn't mentioned on any roadmap.

The ranges are all given in proper SI units. 1000 meters = 1 kilometer 1000 kilometers = 1 megameter 1000 megameters = 1 gigameter ...and so on. And yes, you have to use math, because whether two satellites can talk to each other depends on the sending and the receiving antenna. Both matter ingame - just like it does IRL. Two satellites that each have a communotron-88 can be much, much further apart without losing connection than if a communotron-88 tried talking to a communotron-16. In that regard, the wiki for KSP1 is still relevant, because KSP2 reimplements most of KSP1's mechanics largely unchanged.

The editor should actually be able show you this in KSP2. There should be a button where you can activate the display. It's not the same, no, because center of pressure is about drag, not about lift. So CoP includes drag from parts that do not produce lift, whereas CoL doesn't. In KSP1 this was a bit of an issue because the editor could only ever show center of lift, and in some cases that meant that the indicator you got was in a different enough place from the actual CoP that it mattered. In KSP2, meanwhile, the editor shows center of pressure instead, even when building planes it seems. Though to be fair, I don't generally build planes. So I couldn't tell you if this was a big departure from the way KSP1 did it, or basically negligible.

There's no issue with the game that needs fixing. The problem you're having is that you're building passively unstable rockets.

Yep, that's correct. (Although KSP doesn't model reaction wheels quite that precisely. In the game they're just a force acting on the rocket.) There is no reason for your rocket to flip outside of the atmosphere, unless (a) it's a bug, or (b) some SAS mode is telling it to point at something behind it. I assume you mean the order in which tanks drain... but nope, that's not (yet?) a feature. Best you can do is use the resource manager during flight to shift fuel around.

You're touching on what's colloquially known as The Golden Rule Of Rocketry. Which is: heavy stuff at the front, draggy stuff at the back. Think of an arrow shot from a bow. It has the heavy metal arrowhead at the front, and the fletching feathers at the back. In technical terms, you're asking after the relationship between the center of pressure (the sum of all aerodynamic forces acting on the rocket) and the center of mass (the point on which the entire rocket's mass is balanced). Because a given body pivots around its balance point, you can quite literally think of the center of mass as a hole through which you drive a nail to pin a model rocket to a wall. The model rocket will hang there, until an external force makes it pivot around the nail. An external force like, say, you blowing a strong wind at the dangling rocket from the side. Imagine your model rocket has a set of big fins at the back, and nowhere else. The strong wind will push against all parts of the rocket. Because the fins are big surfaces that catch the wind, there are a lot more aerodynamic forces acting on the bottom end of the rocket than on the top. As a result, the fin equipped bottom end will be pushed away from the source of the wind. The model rocket pivots around its balance point, turning its nose into the wind. This is a configuration where the center of pressure is below the center of mass, and as you can see, this rocket really wants to fly straight into the airstream. The harder the oncoming wind blows, the harder the rocket sticks to flying straight as an arrow. We call this rocket passively stable, and we need to use active steering devices like thrust vectoring to make it change directions. Now, imagine instead that your model rocket has a set of big fins on the nose, and none on the bottom. Like SpaceX's Starship. Now, the wind coming from the side pushes the top end of the rocket more than the bottom end, and the model pivots around its balance point, going engine-first into the airstream. This is a configuration where the center of pressure is above the center of mass, and it creates a rocket that really wants to reverse itself at the first possible opportunity. The harder the oncoming wind, the more aggressively it tries to reverse itself. We call this rocket passively unstable, and to fly it, we need to constantly fight its urge to flip until we are out of the atmosphere. Starship's first flight test ended in the whole skyscraper-sized rocket doing cartwheels in midair in the most Kerbal fashion because it destroyed too many of its engines by shattering the launchpad, and thus had too little TWR, flew too shallow, started pointing away from prograde to try and correct, and subsequently reversed itself because it is passively unstable. When building rockets, you want them to have their center of pressure below their center of mass at all times, even as its fuel tanks drain. Then your rockets will be passively stable, and the atmosphere suddenly becomes your friend instead of your enemy. You want a heavy front, and you want a draggy rear. Which may seem like a tall order, given that the front typically features draggy fairings, and the heaviest part of the rocket - the first stage tanks and engine section - are all the way at the rear. But that is the challenge you, as a rocket engineer, must solve in order to succeed.

Oof, yeah, that would probably take a year's worth of dev time for a dedicated sprint team just for the planner, with additional work required across teams from all areas of the game The handling of potential edge cases alone makes my head hurt. But it would be cool. No question there.

This, unfortunately, runs straight into the problem described in the very section you quoted: The maneuver planner factors in the changing mass of the vehicle as fuel is expended. If you simulate expending more fuel than there is available on the vessel, you get a mathematically bogus result. Even if you draw that line for the player, and clearly mark it as being beyond the vehicle's capabilities, the problem is that the line that is drawn will be wrong. It is a false result. Any trajectory you plan with that cannot be flown. Any encounter you set up will be missed. Not just because you don't have the fuel - no, it will even be wrong if you turn on an infinite fuel cheat. Even then the result will be wrong, because you're simulating the vessel expending its own dry mass, which it can never do, even with cheats. If you push it too far, this can result in the vessel's mass becoming negative in the simulation, and then things really break. Therefore, drawing this line is of no use to the player, and I completely agree with not even bothering to draw it. However, I too would like some sort of means to plan flight paths independently of fuel load. One obvious solution would be to offer the player a toggle, which switches the way the maneuver planner works back to the way it used to work in KSP1: an instantaneous impulse maneuver. KSP1 never had the issue of needing to factor in a vehicle's changing mass, because all that mass change would happen in an infinitessimal instant, and thus, have no bearing whatsoever on the trajectory. That is why KSP1 happily let you make flight plans well beyond the capabilities of the active vessel, and those flight plans would still be mathematically valid and could be correctly flown with infinite fuel enabled. There were obvious downsides, of course - chiefly the fact that planning trajectories like this introduced an error that grew larger the lower the vessel's TWR was. Players learned to work around this by splitting burns, which then introduced its own problems for interplanetary transfers, such as there being no way except manual guesstimation to time your final ejection to coincide with the transfer window, or even to figure out in which direction to start raising your apoapsis so that it would line up with the ejection angle after Kerbin traveled some distance around the sun. And it completely failed at modeling constant thrust trajectories, because its very nature was that of instant thrust. But if we had a toggle, we could have the best of both worlds - we could switch between simulating long flight plans independent of our vessel's capabilities in instantaneous impulse mode, and planning actual burns in simulation mode. Not saying that this is necessarily the best solution, but it is one solution. There may be others.

The assembly anchor is what used to be known as the root part. It is the part that, when you click it to pick it up, will pick up the entire assembly instead of detaching something. The launch assembly is the assembly that will go to the pad/runway when you press launch. Workspaces can contain more than one assembly, so this distinction became necessary. However, as long as you build only one assembly in a given workspace, you can completely ignore this.

Because they're not scatter. They're part of the building assets of KSC.

There's still plenty of trees - but they are now ultra low poly models. Like, barely ten-fifteen triangles per tree. That's part of what I meant with "immediately obvious". You should see a significant improvement.

Some very pleasing developments on the performance front. I mean, it is immediately, visually obvious how the extra performance is obtained when you play on low settings. The reduction in visual fidelity is very significant. ...But then again, that is precisely what "low settings" are for. Previously, they barely did anything. Now they do a lot. And the impact on video memory is dramatic. Previously, even 1080p on low settings was all but maxing out an 8GB buffer; now, I encountered some situations where it only needed ~5. This disables the brutal memory bottleneck that made a bunch of perfectly serviceable video cards with 6GB VRAM borderline unplayable at any resolution. I'm seeing FPS gains of 50% and more, depending on the scene. Heck, I can switch up to 1440p and get slightly more FPS than I got on 1080p before, and because that's my native resolution, the image is no longer blurry from interpolation. Perhaps someone else can comment on performance differences at medium or high settings - I'm still stuck on old hardware for now, pending a full new PC build in the next month or two But I can guarantee that a lot of people with low-end hardware will appreciate these changes.

Could you help me find some of those benchmarks done by others? I don't doubt you, I'm just really curious about the details.

I'm not aware of any benchmarks to this end, so this is likely unknown at this time. Also see this discussion thread. EDIT: that thread has since received additional discussion, and the tentative answer seems to lean towards "yes, KSP does like cache".