Jump to content

Streetwind

Members
  • Posts

    6,112
  • Joined

  • Last visited

Reputation

5,191 Excellent

5 Followers

Profile Information

  • About me
    Talks To Boosters

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The act of going from the status "under thrust" to the status "not under thrust".
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Yes, all antennas are omnidirectional at all times, regardless of vessel orientation or model shape.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. There's no issue with the game that needs fixing. The problem you're having is that you're building passively unstable rockets.
  14. 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.
  15. 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.
×
×
  • Create New...