Jump to content

Streetwind

Members
  • Posts

    6,112
  • Joined

  • Last visited

Everything posted by Streetwind

  1. That is because engine plates are no longer decouplers like they were in KSP1. The "jettison" action detaches the engine plate's shroud. It does not decouple the node below it. That's why it is specifically not named "decouple", but rather something else. In order to decouple a stage below an engine plate, you must use a stack decoupler or stack separator. (Conveniently, both of them are hollow rings, so your desired setup will still work.) My best guess as to why that was done is that the engine plates with built-in decouplers in KSP1 were essentially "upside down" - the decoupler stayed with the stage it was attached to, rather than the stage that was decoupled. This went against all other ingame logic, confused the heck out of the Engineer's Report in the editor, and had the potential to mess with fuel flow logic in certain edge cases. It made sense to streamline them for KSP2.
  2. The theory about rocket stage types goes like this: Stage 1 is called the booster. Its job is to throw the rocket out of the atmosphere and give it just enough speed that the second stage can do its job. For this purpose, it is equipped with engines that favor raw power over efficiency - in particular because atmospheric pressure is a thing. Rocket engines behave very differently at sea level pressure than in a vacuum, and you can optimize for each end of the spectrum or try to strike a compromise. Therefore a booster stage usually comes in two variants: either it has one or more powerful engines optimized for sea level pressure; or, it has some powerful solid motors to get it off the pad plus some lower-powered, so-called sustainer engines, which are the ones that try to strike a compromise between atmospheric pressure and vacuum operation. Stage 2 could be called the orbiter, although few people do. Its job is to accelerate the payload to orbital velocity. Because it begins operations after the booster has thrown it out of most of the atmosphere, it can rely on vacuum-optimized engines to get a higher specific impulse and therefore use fuel more efficiently. However, it still needs to field a certain amount of raw thrust: the booster has thrown it onto an arc, and if it doesn't succeed in transforming that arc into an orbit before it runs out of arc, then it will fall out of the sky. Thus, these orbital engines will be slightly less efficient than they could in order to deliver a bit more power. (That also makes them suitable as landing engines on airless bodies, incidentally.) Everything that decouples from stage 2 is called a spacecraft. It begins operations full in orbit, and thus does not need to worry about falling out of the sky anymore. The deep space engines that it uses can be tuned completely in favor of efficiency over performance. This is typically also where you would see high-impulse engines with alternative fuel types make their entrance, such as nuclear rockets and ion thrusters. KSP2 helpfully sorts each of its engines into one of those four categories: booster, sustainer, orbital, deep space. The category is listed in a subheader directly below the engine's name in the part info window. So whenever you look at an engine, you can instantly see which role it is supposed to fill, and which stage it would traditionally be placed into. The Reliant is a booster engine, the Swivel is a sustainer, the Terrier an orbital engine, and the Ant a deep space engine. So far the theory. In practical application, however, launching from Kerbin is extremely easy. Kerbin is only one eleventh the size of Earth, so even though the gravity is the same, orbiting it requires a lot less energy. 2200 to 2300 m/s orbital velocity compared to Earth's 7500 to 7600 m/s. Think about it: an orbit is nothing other than moving sideways so fast that you keep missing the planet when you fall back to it. And if the planet is much bigger, then you need to move sideways much faster to keep missing it. Because orbiting Kerbin requires so little energy, you can frequently just single stage to orbit (SSTO), wherein the booster stage carries you all the way into a stable orbit. In such a setup, you don't have an orbiter stage at all - you just have a spacecraft that detaches from the booster. This is what you've been doing. And it is a completely valid approach, if you like playing that way. It is no more and no less correct than the typical two-stage to orbit method used on Earth. You may think that it is more mass-efficient to go two-stage, and you wouldn't be wrong; SSTO boosters tend to be very large and very heavy. On the other hand, though, using two stages to orbit will result in two stages which both have inefficiently low mass fractions, so you're not really getting your money's worth out of them... if, you know, you were actually spending money So what KSP players in particular often do is organize the stages a little differently: the booster stage will go most, but not all the way to orbit (fielding in the neighborhood of 2800 to 3000 m/s dV). Then you have a transfer stage, which completes orbit insertion but is essentially a spacecraft and uses deep space engines. Its job is to move the payload where it needs to go - for example, it moves a Mun lander into low Mun orbit, or a Jool exploration spacecraft to Jool. Then the final thing you decouple achieves the actual goal of the launch, such as landing somewhere. On crewed missions, sometimes the transfer stage is reused for the trip back to Kerbin, waiting in orbit for the lander to come back from the surface and re-dock with it. This leverages the high dV potential of deep space engines and allows the lander itself to be smaller and lighter.
  3. Not to my knowledge, no. Don't expect this anytime soon either. KSP1 took like 10 years of development to get around to it, and even then you needed to add a special part for it. You can, however, attempt to transfer it to a central tank where it won't affect your CoM as much, if there is an issue with that.
  4. Got slightly better performance in some situations. But my video card is still hopelessly out of memory, so unless the planned replacement of the PQS system with concurrent binary tree subdivision magically makes do with 30% less VRAM, I don't think I'll ever get smooth framerates. It's below the minimum spec anyway, so it's not like I have grounds to complain
  5. But how does the player plan the multiple burns? How is it represented in the UI, how is the new player taught to do it? This isn't an issue of being entirely unable to get where you want to do. This is an issue of the tool the game teaches you and expects you to use being actively counterproductive. Therefore, the tool has room for improvement. I mean sure, I can just eyeball where my apoapsis should rise towards for a successful Moho transfer, and manually periapsis kick it up there until I reach escape velocity, and then lower my orbit to around Moho's semimajor axis, target Moho, and fish for an encounter while burning in different directions. But then why do we have the maneuver planner in the first place? Might as well throw it out, right? No, of course not. It exists because it is meant to pre-plan these things. To give me a preview of my trajectory before I light my engines. So even if I, with a four-digit number of hours in KSP, can in fact fly a low-thrust probe to Moho without making a maneuver node, that doesn't excuse the maneuver planner from being unable to calculate this trajectory for all the players who don't have my experience. Acceleration under timewarp for low-thrust propulsion is one of the headline promises of KSP2. The game can't very well then turn around and not support it in maneuvers.
  6. While I agree that the maneuver planner is much improved, there is definitely room for more work. Indeed, there are large issues remaining with long burns, which go all the way to "the spacecraft burns retrograde on a node that only contains prograde dV". (Example screenshot) This is the "new" Dawn ion engine in 0.1.1, with 0.2 kN instead of 2 kN of thrust. With just 700-odd dV in the node, all of it prograde, the test probe simply deorbits itself instead of raising its apoapsis. The reason for this is that the spacecraft is required to burn at the maneuver in a straight line, while it is on a curved path. At the start of the burn, the maneuver marker is directly on top of the prograde marker, but with each second that passes, the spacecraft will "nose up" more with respect to prograde. After a quarter of an orbit, the spacecraft will be facing fully radial-out, and not burn prograde at all anymore. If the burn continues after that, the spacecraft will begin to turn retrograde and lower its orbit instead of raising it, which eventually causes it to crash. The correct strategy here is either a spiral trajectory, or periapsis kicking. Unfortunately, the maneuver planner doesn't just not support either - it actively interferes with both, because (a) you cannot plan any trajectory that doesn't follow the maneuver marker in a straight line, and (b) you cannot plan any trajectory that the spacecraft cannot execute in a single burn. As a result, any spacecraft which cannot reach Kerbin escape velocity in roughly 10-ish minutes cannot plan any interplanetary trips from low Kerbin orbit; they need to be manually piloted to escape velocity and enter solar orbit before maneuver nodes become usable once more. I'm currently working on a large, detailed feedback report which I will submit through the launcher; cross your fingers it won't get lost...
  7. It's not unusual to expect different systems to see different changes in performance after a patch. If the patch focused on addressing a specific bottleneck, for example memory usage*, then those people who were hard limited by available memory would see a significant improvement, while those who already had memory to spare would see only minor differences. Meanwhile, if shader processing efficiency was increased, then the people hard limited by memory would see little to no change, whereas the others would get higher FPS. So it always depends on a lot of factors how high exactly one single system's improvement will be. But averaged across the whole community, we will likely see a noticeable improvement. * Note, that was an example. I don't presume to know what areas the changes in this particular patch addressed.
  8. Great changelog! If future patches follow in this one's footsteps, that inspires a lot of confidence. Quick question to fellow players, since I need to go to bed and can't check for myself for a while yet: Is the bug where in-progress maneuver nodes reset on toggling in and out of map view still a thing?
  9. Sure. But what does that have to do with my post that you quoted?
  10. No one in the community can answer that. Even Mortoc probably can only estimate, not know precisely. He mentioned that it's a "medium term" project. If we define "short term" as "in the next couple of patches", and a patch cycle is three to four weeks, then medium term would be a minimum of three months and most likely quite a few more. My own blind guesstimate, based on nothing more than this, is Q3/2023 for previews, Q4/2023 for an initial release, and the first half of 2024 for bugfixing and polishing. But since I have no idea about the state of the project, it could come faster than that. or take longer. Who knows? Not me!
  11. Whackjob is a player who used to post about his construction efforts here on the forums. Not sure he's still active. His main aim seemed to be to find the limits of what could be built, and then designing ways around those limits. Try this thread on for size.
  12. Personal guess: because "now" isn't as late as you might think it is. The game clearly wasn't as far ahead as we thought it would be when it entered early access, and while I personally don't mind - I enjoy watching things develop - I also understand how other people may have come in with different expectations and feel disappointed. I don't know who decided to go public now, but it was too early. It's not a beta by any definition; it's deep in alpha territory. Meaning, the game is closer to the prototyping stage of development than we think, and Mortoc's blog post did imply that they went with PQS in the beginning to have something familiar to build systems off of. Maybe they did carry their prototyping setup a bit further than perhaps wise, sure - but it's not like they've built a finished product on top of it. It's far from finished. The fact that the team knows exactly what is wrong, and apparently knew it all along in the lead-up to early access, just confirms in my mind that someone in management pushed for EA too early, and we are now simply witnessing the "switch from prototyping implementation to production implementation" step in the development roadmap that would normally get handled away from the eyes of the public.
  13. You can take a page out of the book of the legendary Whackjob, and strut your rockets with modular girder segments
  14. Well, it was meant more of a summary of the state of things rather than an attempt to judge/critique game balance. I think it's decently fine where it is, for the stock game (bugs nonwithstanding). As a veteran I find it incredibly easy, but that doesn't mean it's not an adequate challenge for a newcomer. I can always add challenge with mods
  15. Maybe KSP2 doesn't auto-assign brakes to the action group like KSP1 did, and you need to do that yourself...? Just guessing though, I have no idea.
  16. No such thing has been announced. However, what is confirmed to be coming is a binary planet pair. Think Pluto and Charon, except much closer together. It will be located in one of the other star systems, and will use special tech to allow the player spacecraft to be affected by both gravity sources at the same time, creating unique challenges not found anywhere else. Theoretically this tech could be used to create barycenters elsewhere, but at least for planets orbiting stars this would not apply. Planets in KSP are "on rails"; they follow preprogrammed trajectories while ignoring any and all forces that might affect them. It would be extremely difficult to build a binary star system in which planets have their trajectories preprogrammed for an effectively infinite period of time while remaining even halfway realistic and believable.
  17. I enjoyed reading this devlog, many thanks. Good to see that what the profilers see checks out with what the community figured out - the high memory dependency and the crushing performance cost of celestial body surfaces. And by all means, fast-track the CBT and HDRP stuff as much as possible! The game already looks and plays well as long as no planet is in view, so things can only get better from here on out
  18. An easy piece of general advice: KSP2 loves memory. That includes both system memory, where you ideally want at least 16GB, and video memory, where you'd ideally bring at least 8GB for 1080p and at least 10GB for 1440p. The main resource hog right now appears to be celestial body surfaces, particularly in daylight. Being in a low orbit and looking down at the surface will absolutely murder your FPS. Even the most high-end cards, like a GTX 4090, will drop to a fraction of what they can do when the camera is simply turned the other way. (Note: that doesn't mean that a GTX 4090 drops below 60 FPS at any point - it doesn't - but it proves that this is an issue with the game, not with the hardware.) Outside of that effect, the system requirements are actually much more benign. I have an i5-4670 (a ten year old midrange CPU) and a GTX 1060 6GB (a six year old midrange GPU). Both are below the official minimum system requirements, and yet I get a comfortable 40-50 FPS in the VAB or in space with the camera pointed away from Kerbin. At 1080p. And I have a feeling the FPS would be higher if the card wasn't constantly out of VRAM. My ancient CPU is only like two-thirds loaded because the video card is spending so much time swapping data with system memory and disk instead of rendering frames. Unfortunately, by its very nature, KSP2 makes us look at celestial body surfaces constantly - for example, you have pretty much no choice in the matter when putting a rocket onto the launchpad. This means that until the issue is fixed on the game's end, almost no kind of hardware out there exists that will let you play comfortably in all situations. So... don't bother trying, IMHO. I really don't recommend dropping two grand on a video card and another on a system that can support it just to try and beat a software problem with raw power. Instead, consider something like a 3060 12GB, or a 3060 Ti 8 GB from team green. If you have time to wait, the 4060 series is rumored to be releasing in the summer months, and might have slightly more VRAM (or it might not, Nvidia has been stingy with it lately). On the side of team red, in the same price and performance brackets, there's the 6600 XT / 6650 XT with 8GB, the 6700 with 10 GB, and the 6700 XT / 6750 XT with 12GB. You generally want to err towards slightly more VRAM on AMD cards, but thankfully, they also tend to make it more affordable. And finally... on team blue, they're really trying with the Arc series, and the hardware is good, but the drivers still have real issues. I'm not sure I can recommend them right now, but if you're a fan, the 7xx series cards do have the VRAM and performance required to run the game. Note: none of the cards I mentioned will do 4K gaming well, KSP2 or otherwise. You shouldn't target that resolution if you're budget conscious. You can buy video cards used, but stick to reputable sellers. Shady people are still trying to offload cards that were beaten half to death in cryptomining centers until last year, and they're going out of their way to lie and hide the damage. Used AMD cards are particularly risky, as they were the most favored by miners. When building a new system from scratch, the budget king is likely the i3-12100F on the cheapest compatible mainboard available with 16 GB of DDR4 memory. If you're looking to spend a bit more, consider an i5-13500 (a great price for the number of cores), an i5-13600K (better for gaming in particular), or a Ryzen 7 5800X3D (even better for gaming in particular). The newer Ryzen 7000 series is harder to recommend, as they lock you into uncharacteristically expensive mainboards that only run with expensive DDR5 memory. A fresh PC build these days should also go for 32 GB RAM if you can fit it into your budget. That kind of hardware should handle KSP2 just fine outside of the broken planetary surfaces.
  19. You shouldn't really need to make a node for this at all, assuming you managed to go fast enough sideways during ascent. You should aim to reach a speed of 2000m/s by the time your apopasis reaches the correct height and you cut your engines and coast. You can still circularize without a node with 1900m/s or even less than that, but the lower you go, the more difficult it becomes. The general approach: coast until you are about 10 seconds before apoapsis, then throttle up. I recommend using the mouse to click and drag the throttle for this, as it offers unparalleled precision control. Try to figure out how high you have to throttle so that the time to apoapsis neither decreases nor increases. Once you have found that point, start backing off the throttle slowly and gradually. You'll find that the closer you get to circularizing, the less thrust you need. If you feel comfortable in your control, let the apoapsis come even closer, to just a few seconds. Then just hold it there with your manual throttle control until the periapsis has climbed up to where you want it. If you are going too slow, and have a weak engine, you may find that even at full throttle, the apoapsis won't stop coming closer if you start the burn at 10 seconds off. In that case, you'll want to start burning earlier. Use your judgement; you'll soon get a feel for how well your rockets accelerate after you've done this a few times. And, of course, going faster sideways during ascent makes this easier. meaning, tip over a little sooner/harder. Just be careful not to go too flat. Each individual rocket will be slightly different with how flat a trajectory it can fly without falling out of the sky. The more TWR, the flatter you can go. It also helps if you gradually throttle down the upper stage as your apoapsis climbs above 55km, thus delaying the point in time until you have to cut your engines entirely. Oh, additional info: the SAS Hold Maneuver mode is buggy, and tends to veer off the marker. If you use nodes, try following the marker manually, or just use SAS without any of the Hold X modes.
  20. "Lack of stellar exporsure" means a solar panel that doesn't receive sunlight. That's definitely not what's killing your vessel - or rather, it shouldn't be.
  21. Hmmm, that's a very general question. I can link you to this writeup I once did, which is admittedly meant more for newcomers, and also this one, which talks about optimal rocket stage design from a mathematical standpoint. I don't know if either is what you're looking for, but maybe you'll find something helpful. They were written for KSP1, but 99% of them probably apply just as much to KSP2.
  22. Ah, you have a spacecraft in solar orbit and can transfer whenever? I see. Well, beats me, then. Just pulling the node around should find an encounter somewhere. Have you tried saving and reloading? That seems to fix quite a number of bugs with the game.
  23. Are you sure you're in the transfer window? Because I don't think you are. In the first screenshot, at least, it appears like your AP at Dres' orbit is almost on top of Dres itself. Which means Dres will have moved well past that point during the time your vessel needs to cruise there. So of course you wouldn't get an encounter. In the second screenshot you're using more of a lead, which is the right thing to do, but it's not enough. According to this image, which shows the planetary alignment relative to Kerbin for each interplanetary transfer, you need to lead by more than a quarter of Dres' orbit.
  24. I've had a liquid fuel engine (a Dart) turn unresponsive one time, after alt-tabbing out and back in with the game in fullscreen mode. The engine was running at 10% output, exactly as I had left it, but when I tried to get it to shut off, nothing happened. Could change the throttle to zero, or to 100% - no effect. It completely ignored anything I did and continued burning at 10% output. I had to revert that launch.
  25. Go into the options, toggle the clouds to minimum, save, exit the options to confirm things have changed, then go and toggle them back to maximum. See if that makes a difference.
×
×
  • Create New...