Streetwind

Members
  • Content count

    5848
  • Joined

  • Last visited

Community Reputation

3409 Excellent

4 Followers

About Streetwind

  • Rank
    Talks To Boosters
  1. Erm. This thread's entire purpose is to mock other people behind their backs... what did you expect? (Seriously though. I came here expecting funnies. I'm leaving greatly disappointed in more than a few members of our community.)
  2. I get that too - sometimes I need to hit space twice to stage. I don't know any rhyme or reason about it. Pretty sure others get it too. Little bug, perhaps, but you get used to it Congratulations on your successful Mun orbit, either way!
  3. ...Oh! Okay. I see what you mean now. That's due to the way Kerbal Space Program calculates trajectories. See, in real life space, there are dozens upon dozens of objects with significant gravity wells, all of which influence one another, while the whole bunch of them is also spinning around each other at different speeds. This royal mess is called, in mathematics, a "N-body problem", and it has no general solution. In other words, it is incredibly, incredibly complicated, and the tiniest difference in initial conditions can dramatically change everything down the line. And while you can solve a N-body problem for a known set of actors and initial conditions, such as the KSP solar system that always spawns the exact same way at game start, the devs still decided against doing it, for three reasons. One, it's very difficult to debug and fix if something goes wrong, because it is so complicated. Two, it takes a lot of CPU power to simulate with sufficient precision, especially when trying to fast forward. And three... because it is so complicated, it would be difficult to play in, especially for newcomers. Every orbit you assume with your spaceship would constantly change, and you would find your space stations randonmly deorbited or ejected from the system by subtle gravitational perturbance built up over time. What the devs did instead is use a simplification. Instead of simulating all the things in a N-body problem, KSP only ever simulates two things: your spacecraft, and the currently dominant gravity well. Thus it becomes a "2-body problem". And that is very easy to solve into very consistent and easily understandable results. However, it comes with an inherent issue: if you only ever calculate against the currently dominant gravity well, then what happens when which gravity well is dominant changes? When you get far enough away from one body and close enough to the other that the new one overpowers the old? This is where, finally, your dotted purple line comes into play. In order to be able to smoothly transition from one body to the next, KSP employs what is called "patched conics". The game has precalculated areas in which one body becomes stronger than another: the so-called "spheres of influence". If you want to transition from one to the other - say, to go from the influence of Kerbin into the influence of the Mun - then the game first solves the 2-body problem for your spacecraft with Kerbin, and then solves the 2-body problem for your spacecraft with the Mun (using the result from the former as the initial conditions for the latter). Now the game has two partial pieces of orbital trajectories ("conics"). It takes them, and "patches" them together where they meet, to form one full and coherent line. So the purple line you see sometimes is a different "conic". It's a part of your orbit that is colored differently because there was a SOI transition somewhere before it. And that's a good thing! Because they only show up when your orbit changes from one sphere of influence to the other... which is precisely what you want to do, right? You want to go to the Mun. And to go to the Mun, you need to travel into its sphere of influence. The purple line is exactly what you're looking for. It is the sign that you have found an encounter. In fact, it's probably already the third conic in the series - the part of the orbit you get after exiting the sphere of influence of the Mun again and returning to that of Kerbin. There's probably another differently colored one in between the yellow line going towards the Mun, and the purple one that leads away from it. That middle line is the segment of your orbit that is inside the Mun's SOI. That's when you have arrived where you want to go, and where you then have to perform a "capture burn" to stop yourself from coasting back out again.
  4. Yeah, honestly, just stockify BetterBurnTime and call it a day... if @Snark approves, anyway
  5. Welcome to the forums, @BattleReadyKen - but please keep in mind that a vertical flight is not a useful test case for rocket stages. Altitude is only a minor factor; the vast majority of fuel is spent accelerating sideways. Knowing how much fuel you need to lift a payload out of the atmosphere isn't very helpful if the second stage decouples with 0 m/s horizontal velocity out of 2300 required to stay in orbit. A typical first stage might pack around 1500-2000 m/s worth of dV, and decouple while still in the atmosphere but going sideways at a good clip.
  6. When your trajectory intersects the sphere of influence of the Mun, then the Mun's gravity will influence it. If you come up from behind and pass above it (from Kerbin's point of view), for example, it will accelerate your ship like a slingshot, causing you to leave the sphere of influence with more speed than you entered - this might even result in a trajectory that escapes Kerbin's sphere of influence later-on. Similarly, if you come up from behind but pass below it, it will actually slow your ship down. The magnitude and direction of this effect depends on your specific direction of approach, and how close to the surface you pass - it's even possible for your trajectory to be nearly completely reversed (but that would actually be a surface impact trajectory, since it requires you to be closer to the Mun than the Mun is large). Therefore it's hard to give a simple answer like "this always happens when you do X". But at the same time, there's no need to let it confuse you. The important part is that you get an encounter. Any encounter. Ignore what your trajectory does after the encounter, it is not important. Because of physics, you need to fire your engines when you get there later, causing your trajectory to change again anyway. Just try to execute the maneuver node to the best of your ability. As for making the maneuver node, there is an approach that always works for the Mun: 1.) Create your node somewhere. Anywhere is fine. 2.) Focus on Kerbin, and look at it from the top down, zoomed out far enough that you can see the orbit of the Mun as a perfect circle around it. 3.) Drag the green prograde marker of your node until your predicted apopasis touches the orbit of the Mun. 4.) Drag and drop the maneuver node itself around your current orbit. This will make your predicted apoapsis move, too. Move the node until you find an encounter. It should be roughly 45 degrees ahead of the Mun's current position.
  7. But then the parent body would be moving along its orbit around the Sun, and the orbiting body would not be able to occlude the same distant star more than once. So, less than infinitessimal probability - it's not physically possible at all. In order to be possible, it would have to be an object independent of the Sun that is traveling in such a way around the center of our galaxy that a satellite it possesses repeatedly and perfectly obstructs the line of sight between the same two random stars more than 1250 light years apart for many years in succession. ... I'm tempted to say that even Occam's Razor would prefer aliens at that point of probability
  8. @Kerbital - This is for you, RE: your request in the other thread: @PART[cryoengine-*]:AFTER[cryoEngines] { @MODULE[ModuleEnginesFX] { @maxThrust *= 1.0 @atmosphereCurve { @key,*[1, ] *= 1.0 } } } Told ya it was much simpler
  9. @K^2 - Tabetha Boyajian and others around her are very active on Twitter, if you want to talk to them directly. There's also a subreddit she links to, and probably is active on.
  10. It's intentional in the sense that this is how they have always worked, ever since Nertea first created them. At no point were they ever automated, nor was it a topic of discussion. It's pretty much only since Squad released fuel cells with their semi-automatic throttling that people started asking "hey, why are the reactors not working like that?" The answer would probably be: because they're at least two years older If you want auto-throttling reactors, though, have you considered USI Core? I don't think it's available as a standalone download, but you can probably extract it from a MKS download easily enough. They use the same stock module as the fuel cells IIRC, or at least one that acts the same way. EDIT: Wow, sniped! *fistshakes at DStaal*
  11. The problem is the sheer magnitude. If a planet the size of Jupiter would occlude roughly 1% of the light from that star, then an event that occludes 2.5%-3% is highly unusual. An object three times the size of Jupiter would be approaching brown dwarf status, and likely emit enough radiation to be detectable on its own. And now consider that we recorded two dips way stronger than that, one of which went down to 22% less brightness. Any single object of that size that isn't artificial or a singularity would be a star itself. So we're looking at two distinct events here, I feel. The lesser dips, which could potentially be explained with a debris field from a planetary collision... if two super-earths of considerable size collided. Like, both of them as large as you can possibly make a rocky planet, way larger than anything we have in our solar system. And it would have to be a very recent event, so the debris hasn't had time to spread out yet. But even then it would be a stretch. And then the greater dips, which still defy all explanation - and also haven't been observed a third time so far. But here's hoping, considering the fact that the star now seems to be under near-constant scrutiny. There's also an additional problem with the debris field hypothesis, which is that such a thing should distinctly show up in IR, because all that starlight caught by smallish particles would radiate off into space as heat. But we saw nothing of the sort. I'm giving it the benefit of doubt in the sense that Kepler wasn't equipped to make such observations in the first place, and this is the first time we have a chance to get actual spectra taken; but it's certainly not guaranteed.
  12. I can't comment on this because I haven't used newer versions of NF Construction yet, sorry. No, they do not auto-throttle. They require manual control, which is why the Reactor Control Panel exists. However, said control panel does offer a setting for an auto-shutdown under time warp. That's more a request to be made in the CryoEngines thread, no? I wrote that patch mainly because it's tricky to get right with electric engines, due to the way you need to modify propellant ratios, and the two custom engine behavior plugins in NF Propulsion that override some config values. But tweaking the values on standard chemical engines is much easier. You could probably pull it off yourself without too much difficulty. Maybe if there's a lull in my workday, I could whip something up, but no guarantees on that happening.
  13. So it wasn't a super-deep dip. It only went down ~2.5%. Still significant, but not what we were really looking for, I guess... However, the shape does match a previous Kepler event very closely: This could definitely be some sort of orbiting debris field IMHO. It doesn't feel like a single solid object could produce this shape, and a conjunction of planets would not repeat this precisely unless there's a super unusual amount of orbital resonance going on. (And even then we'd have to have seen partial dips before.)
  14. Looks like there's a lot of people who would benefit from making a new "Let's discuss nuclear missiles" thread.
  15. Followed up by a demonstration of what they mean with "high winds": ...yeeeaaaah, I believe that qualifies