• Content Count

  • Joined

Community Reputation

13,130 Excellent

About Snark

Contact Methods

  • Website URL Array

Recent Profile Visitors

15,738 profile views
  1. Nothing wrong with discussing this project here in this thread... just a gentle reminder, though, that the thread is from nearly four years ago, so do bear that in mind.
  2. Well, sure, but if you're gonna go there, let's talk about how you could never get Dres in that stable position relative to Kerbin, or how it would be essentially impossible for the Mun to be in an orbit like that (and never mind the fact that it's probably past the Roche limit, and what its tides would likely do to Kerbin even if it's not). Or the impossibility of getting a planet spinning as fast as I've got Keelon doing, without disrupting its structural integrity. And so on, and so forth. And never mind the utterly implausible densities of KSP planets in the first place. This mod isn't even slightly about "realism", and never has been. It's about deliberately arranging things in a novel way to present some interesting navigational challenges and add variety to the game.
  3. Snark


    Hello, and welcome to the forums! Moving to Add-on Discussions, since that's better suited to this question. There are, of course, tons of good mods out there. Which ones are most appealing to you will depend a lot on your play style, what about the game bugs you or seems "missing", etc. Got any guidance on areas of the game you feel could use some improving or altering?
  4. I know, and I totally sympathize. I get that it's hard to understand this stuff, if you're not a programmer-- you'll recall that I pointed out that very concern at the start of all this. Executive summary is that "there are good reasons, and KSP 2 will have to solve many of the same problems that KSP 1 did, so it's not surprising that they'd have similar algorithms." Folks in the few posts above have already provided a lot of good explanation of why a lot of these things are the case. If you're having trouble following along, I'm sure folks would be happy to provide references for specific points that may be puzzling. Sure. Because the space colonies will likely only be on the order of hundreds of meters in size, not hundreds of kilometers, meaning that they oughtn't need new algorithms to model them. Because O(N2). Because it's a good optimization and is necessary unless you want to force people to have a supercomputer to run the game. Because it was a good idea when KSP 1 was written, and is still a good idea today. Computers have gotten more powerful... but N is also getting bigger, and the fundamental issue with O(N2) remains. Folks have already given a pretty good explanation of this in the posts above this one. If you're still having trouble grasping the concept, here's a handy reference. I recognize that that's a lot of technical detail to wade through, and I wouldn't blame you if you don't have the patience for it-- but if you'd prefer not to wade through it all, then about all you're left with is "people who have been doing this sort of a living for many years think it's a good idea", which I suspect would not be a very satisfying answer. Sure. And I didn't say that it would be "unbearable". Simply that it would require a lot of specialized UI that would only be necessary for skyhooks, and which they wouldn't have to implement if skyhooks weren't in the game. Implementing a complex feature is expensive. It's just how software development works. And resources are very finite, and there's never enough time to implement all the stuff one wants. All I'm saying is that this would be an expensive feature that wouldn't provide benefits to other, non-skyhook stuff, so it would be a poor use of their resources to implement unless it were a really important feature with extremely high demand. Which it doesn't appear to be. Because of the finite resource in software development, it's always really important to try to get a whole lot of "bang for the buck". And this feature would be a lot of bucks for not very much bang, that's all. I expect that it'll do better at optimizing a lot of places where KSP 1 has rough edges-- for example, improving the physics engine to run more efficiently, so they can support higher part counts. But the fundamental computational challenges remain the same, because 1. math, and 2. physics. Math is math, and physics is physics, and these things don't change with new software versions. That's why some of the basic simplifying assumptions-- such as patched conics for orbital mechanics, or the physics bubble-- will likely still be with us. Unless you have some suggestions about how to turn craft physics into an O(N) problem?
  5. So, the good news is that going to Duna doesn't require much more dV than going to the Mun, so it's not too difficult to build something with enough oomph. Short answer: Build a ship that's like a Mun lander, with just a bit more dV, slightly more powerful engine, and a parachute. Then launch it at the appropriate launch window with just a bit more dV than you'd need to go to the Mun. The overall process looks like this: Wait for a good launch window Launch to LKO (just as though you were going to the Mun) Do a single burn of around 1000-1100 m/s to head to Duna Do a small course-correction burn halfway there, to adjust for inclination and such Aerobrake and land. Details below: Waiting for a launch window This isn't an absolute requirement-- you can launch even when the window's not great-- but doing your launch fairly close to the ideal window will mean you need less dV, which makes building the rocket easier. For an optimum transfer from Kerbin to Duna, you'll want to launch from Kerbin when Duna is roughly 45 degrees ahead of Kerbin. Here's an interplanetary transfer tool that I find really helpful: There are other tools like it, but that one's my personal favorite because it's so easy to use, and I like the graphical display. Just put in where you're going from (e.g. Kerbin) and where you're going to (e.g. Duna), and tell it what's the height of your parking orbit above Kerbin (e.g. 100 km or whatever). Then you push the button and it tells you how big your burn will be, and also gives you little diagrams showing what the relative positions of the planets should be (i.e. the launch window) and what direction you should make your ejection burn from Kerbin. Launch to LKO This is the same as if you were preparing to go to the Mun or wherever. I'll assume you've already got this down pretty solid. Ejection burn to Duna Using the info you got from the launch planner (see "waiting for a launch window", above), drop a maneuver node at the appropriate place in your orbit (in the spot the tool indicates), and give it an amount of burn equal to what the tool suggests. Then zoom out until you can see Kerbin and Duna in the solar-system view. Hopefully at this point you should be able to see the closest-approach markers for when you'd get near Duna. Your goal is to tweak the maneuver node until you get a Duna intercept. Play around a bit with , and also try moving the node veeeerrrry slightly forward and backward in its orbit until you can get an intercept to show up. Once you've got it showing an intercept, you can go ahead and do the burn. Mid-course correction Once you've ejected from Kerbin, you'll want to fine-tune your path so that you'll hit Duna's atmosphere so you can aerobrake on arrival. This step assumes that you already have a Duna intercept from the previous step. Drop a maneuver node roughly halfway along the path to Duna. Doesn't really matter exactly where it is. Don't give it any dV yet. Still in map view, click on Duna and choose "Focus Here". You're now looking at Duna, and you should be able to see a trajectory line showing what your path past Duna is going to be. Probably this will be out somewhere near the edge of the SoI, unless you got lucky in the previous step. While still focused on Duna, rotate the camera around until you can see your maneuver node. Very gently, nudge that maneuver node to adjust the path past Duna. Give it a little bit of as needed to make the trajectory go past Duna the way you want it to. You want to get your Pe down to an altitude of 12 km or so. Note, this shouldn't require very much dV at all, just a little bit. It'll be a small burn. Once you've done that, do the burn when it's time. Aerobraking and landing It's really easy to aerobrake at Duna. Assuming you launched with a good launch window, you won't be arriving very fast from interplanetary space, and the combination of Duna's gravity and atmosphere makes reentry much gentler than at Kerbin. So if you launched with a good launch window, you probably don't even need a heat shield for this. (If your launch window wasn't great, you could be coming in a lot faster, in which case you might need a heat shield.) There are various ways to design a ship for landing on Duna. My own preferred approach is to just build a vacuum-lander type of ship (e.g. similar to what you'd use to land on the Mun), though with more dV and somewhat higher TWR to cope with Duna's higher gravity. Then give it at least one drogue chute, and one regular chute. Set the drogue chute's opening altitude to be as high as you possibly can, i.e. 5000 m above terrain instead of the default 2500. Set your regular chute's opening altitude to a bit higher too, say 1500 m or 2000 m instead of the default 1000 m. Having just a minimal amount of parachute means that the chute will slow you down a lot, but not enough to land safely-- you'll likely be descending at 30-40 m/s even after the regular chute opens. But that's fine, you can then just use a brief burst of rocket thrust just a second or two before landing, in order to slow to a safe landing speed. Note that that's not the only way to do it; it's just how I like to. You could, for example, spam a large number of parachutes, so that you can actually slow to a safe landing speed with parachutes alone even in Duna's thin atmosphere. It's totally doable. The reason I prefer not to do that myself is that it needs a lot of parachutes, and that mass adds up. The little bit of fuel I burn before landing (in the above-described technique) likely weighs a lot less then the mass of all the extra parachutes I'd have to bring if I didn't want to use the engine, so it's a savings. Another approach is to build something with wings that does an airplane-style landing, but that's pretty challenging on Duna (because the atmosphere is very thin), so my advice would be to leave that until later, when you're more of a Duna expert.
  6. @Terwin covers some pretty good points already, a few posts above. Trying to put something like this into KSP would open many cans of very gnarly worms. Building is problematic. How do players build it? To be useful it'll have to be extremely massive. Ship it up in pieces? How many pieces? Seems like the number would be extremely large, and given that KSP is based on the idea of simple ships with a "tree" structure, trying to assemble the thing would be problematic. Spatially extended structures are problematic. KSP treats ships as being small, specifically as being zero size. This is a reasonable approximation when you're talking about things that are spacecraft-size rather than thousands of kilometeters long. It allows KSP to use numerous simplifying assumptions that keeps the code and computations manageable. For example, a craft is either in the atmosphere, or out of it-- there's no modeling of "the top part of the craft is in vacuum, the bottom's in atmosphere". If it's in the atmosphere, the whole craft experiences pressure and airspeed uniformly, based on the values at a single point-- it's not as though "the bottom of the craft sees a different airspeed and pressure than the top of the craft". Gravity is uniform for the whole craft-- the bottom of the craft doesn't experience stronger gravity because it's closer to the planet. There's tons of stuff like that. Something like a skyhook would blow all of those assumptions out of the water, simply by virtue of being large, regardless of how it's modeled. Trying to solve all that will be ugly. Very large, floppy components are problematic. KSP is based on ships with a reasonably small number of components, connected by reasonably stiff joints. Giant structures like space tethers have some very complicated dynamics going on. Either you'll have to model it as some sort of giant monolithic object that gets special treatment (in which case it's pretty disruptive to the normal flow of gameplay) or else as an assembly of many subcomponents (e.g. segments of cable), and simulating the dynamics of the whole thing would be nasty. Physics engine conniptions. KSP only does active physics modeling of craft that are inside the "physics bubble", i.e. only the currently controlled ship and objects within a few kilometers of it. Everything else is on rails. It has to be that way because otherwise the game would bog down the CPU horribly, by forcing it to do huge numbers of calculations for huge numbers of objects, which would be a nasty O(N2) complexity problem. Running things on rails outside a small bubble helps to limit that, and turn it into something close to an O(N) problem, which is much more computationally tractable. However, having a giant thousands-of-kilometers-long structure would totally discombobulate such a system. You'd have to vastly expand the physics bubble, slowing your CPU to a crawl, or else you'd have to come up with some sort of jury-rigged kludge special case solution to make it work, which would unavoidably have other side effects on gameplay. Playability issues. Players have enough trouble trying to dock / connect things even when all the respective objects are in free-fall, moving at relative speeds of centimeters per second, and all the time in the world to adjust and maneuver. To use a skyhook would require precision docking within a window of seconds to a thing that's accelerating continuously at multiple gees and (at the lower end of its arc) moving at high speeds through atmosphere. There is no way in heck a player's going to be able to dock with that thing using "standard" KSP techniques; it will be impossibly difficult. The only way to make it work would be either to put intrusive "here, let me fly your ship for you" autopilot into the game, or to (again) put in some sort of intrusive jury-rigged kludge mechanic that just automatically teleports you to "docked" when you get within a few kilometers of the endpoint, or something. Yeah, you could try to spackle it over with a cutscene or the like, but it would be an interruption in gameplay, and wouldn't involve the player having to 1. design their craft skillfully, or 2. pilot it skillfully. And if you're taking both the design and the piloting out of it, why even bother? Might as well just give the player the ability to "launch to orbit" instead of "launch to pad" from the VAB. UI complexity. However it's implemented, players are going to have to interact with the thing in a very different way than interacting with everything else in the game. This means a whole new slew of UI affordances for dealing with all sorts of issues. To take just one example among many, if a ship wants to rendezvous with one end of a skyhook, how do you track that in map view? It's not in an orbit, it's continuously accelerating, which means you can't use the "closest approach to target" code that the rest of map view uses-- you'd have to have some sort of custom implementation with all the necessary UI widgets to deal with that. Ditto all sorts of other stuff. The devil's in the details. Doesn't mean it couldn't be implemented, but it would be a great big chunk of work just for all that custom UI, quite aside from all the other coding to handle the physics and so forth. Micromanagement. A real-life tether is going to have to either carry rocket fuel to regain momentum after it gives a ship a boost, or else it will fore the player to use it for down-bound traffic as well, and shift as much stuff down as up, in order to regain momentum. So the player's going to have to manage the momentum of the thing, which feels like a tedious housekeeping chore. It also means that when the player comes home, they can't just aerobrake as they do now (simple, quick, easy)-- no, they have to do another one of those rendezvous-with-the-end-of-the-tether things. If the game doesn't want to turn all of that into a tedious bore, it would have to add yet more custom mechanics to try to automate it enough not to be a burden, so yet more hassle. ...And all of the above is what occurs to me just off the top of my head. I'm quite sure that if one goes to actually design and implement such a feature for real, there would be scads more stuff like that, once one starts thinking it through to all the nitty-gritty nuts-and-bolts. The devil is very much in the details for this sort of thing, and a feature such as you're asking for has many, many details. It would be a great big honkin' ginormous feature to implement. And that's without even considering whether there's any benefit to it, i.e. playability, what fraction of the player base would like it, etc. I have my own concerns about this, which I could go into at length, but since it's just my opinion about what I like in a game (and my observation of what I think most players are into), I won't bore folks with it at length. The executive summary is that just personally, I think this would be a really badly terrible idea for gameplay. I think it would be intrusive and un-fun. I think it wouldn't add any new value to the fun of the game, while deflating much of the fun value of other aspects. I think some of the benefits it does provide, such as they are, are likely to be somewhat redundant anyway, due to the presence of orbital colonies. If it were present, I wouldn't use it, and its existence would bother me. And my impression of the overall KSP player base would be that the vast majority of them wouldn't have a good use for it, either. I just don't think this feature belongs in the game, period, even if one could wave a magic wand and get it for free. But all of that, of course, is just my personal opinion. If you like something different from me, great-- different people like different things. However, regardless of how much a given player would or wouldn't like such a feature, the fact remains that it would be a hugely expensive and complicated feature to implement, and as such would suck development time away from other things. Given how expensive it would be, and given its (I strongly suspect) limited appeal to the player base, I really can't see them implementing such a thing. A feature that expensive would have to be justified by a huge benefit for the player base, and I'm just not seeing it.
  7. Sure, but it would likely be one of those massive Walls of Text™ to which I am prone, and would take a while to set down. So it'd need to be later when I have time. IRL stuff beckons at the moment.
  8. Actually, my intention was to indicate that, I do have an idea of what I'm talking about, since 1. I am in fact a programmer (have been shipping software for a living for >25 years), and 2. I've got a fair amount of understanding of what makes KSP tick under the hood, since I've been modding it a fair amount for the last few years, and actually going into the reasons would likely be tedious, lengthy, uninteresting, and likely rather cryptic to anyone who's not a programmer, which I assume would encompass most of the audience in the thread.
  9. The other nice thing about it is that if you happen to have fourfold radial symmetry on your boosters, this technique makes a really nice Korolev cross.
  10. Several responses have been removed, due to descending into irrelevant bickering over what constitutes a valid argument-- completely derailing the thread in the process. Folks, please try to remember that we're all pals here. It's appropriate to provide comments on the topic at hand (e.g., for this thread, about cargo bays). It's appropriate to share your ideas about that. It's appropriate to respond to other people's ideas, as long as it's still on the same topic. What's not appropriate is arguing about arguing, or criticizing the fact that someone else has chosen to make a suggestion. If you like a suggestion, great. If you don't like it, you don't have to use it. You can even respond and provide your own alternate suggestion, if you like. But it's not appropriate to criticize people for making the suggestion in the first place... and if someone does do that, it's not appropriate to respond to them. There's nothing wrong with disagreeing with someone, but please try to think of all the other people in the thread, too. Folks who come to this thread do so because they want to read about cargo bay suggestions, not because they want to read extensive back-and-forth infighting about what sort of arguments one should or shouldn't make. Therefore, kindly try to stay on-topic, and leave the sanctimonious finger-wagging to the moderators. Thank you for your understanding.
  11. That sounds... wrong. Simply peeping out of Kerbin's SoI ought to be enough. The only "legitimate" (i.e. non-buggy) way for peeping outside Kerbin's SoI not to count as "orbit the Sun" would be if you came out of Kerbin's SoI with so much excess velocity that you actually are on an escape trajectory out of the Sun. But that would take a lot of dV, and in any case it looks to me from your screenshot that you're not even close to doing that. So, it sounds to me as if you've run into some sort of bug. The first thing I'd suggest would be to try saving and then loading the game. That's not supposed to make a difference, but I seem to recall that occasionally doing that can "un-stick" certain bugs. So, I'd suggest trying that first. If that doesn't work, and it still won't complete, then I'd say you've run up against a legitimate bug, which happens from time to time. If there's a contract for which you're really sure that you've legitimately filled the requirements (which I believe you have), and it's not completing, then it's the game's fault, not yours. In those sorts of situations-- which thankfully don't pop up often, at least not in my experience-- that's where I go ahead and use the Alt+F12 cheat menu to force the contract to "succeeded". I figure it's not cheating if I did the thing and the game's just failing to hold up its end of the bargain.
  12. What engines are you using, and what's the mass of your craft?
  13. There's not any sort of guided-missile functionality in the game. SAS does have a mode for "hold " that will keep you pointed directly at the target, but that's not good enough if you actually want to hit the target because you have to worry about your lateral motion relative to the target. There's nothing built in to the game that will give you that. There are, however, mods that are designed to support more military-style vessels, i.e. being able to target and shoot things. However, that would be a question better addressed over in Add-on Discussions, since it's not about the stock game.
  14. Hello, and welcome to the forums! Moving to Gameplay Questions.
  15. Yes, very. It's not the coasting to apoapsis that's the problem, it's the "going straight up" part. As @AHHans points out, it's a lot more efficient to do a gravity turn. Basically, what you do is to start your eastward turn practically right off the launch pad. Just a smidgeon-- how much is "right" will depend on what your TWR is. If you have a low TWR (e.g.1.5 or below), you only want a degree or two. If it's high TWR, like 2.0 or close to it, you'll want a bigger angle, like 5-10 degrees. Having done the initial eastward nudge right off the pad, you then just follow all the way up. No steering needed. Keep burning full throttle, staging when needed, until your Ap gets up to where you want it. Then coast up to Ap and circularize. Judging the "correct" angle to nudge it off the pad takes a bit of practice, but you'll find that you quickly develop a feel for it (especially if you tend to build your rockets with a consistent TWR). A good way to judge whether you've nailed it is, look at what angle from the vertical you are when you reach 300 m/s. At that point, you should be tipped probably about 45 degrees from the vertical. If you're much more vertical than that, your initial nudge wasn't big enough; if you're much more horizontal than that, it was too much. So, if you get to 300 m/s and see that you're way off 45 degrees, just revert to launch at that point and try again. (Also, note that there's nothing "wrong" with how you're doing it now, if you like it that way. It's just somewhat wasteful of dV, is all. A good gravity turn can save you several hundred m/s of dV compared with an inefficient ascent profile, so it's up to you how much you want to fine-tune your ascent.) If you're only 1 km apart, then for all practical purposes you might as well be in "flat space", i.e. you don't need to think about orbital mechanics, just treat it as if you were both floating out in deep space with no gravity involved. So you can just point your nose directly at the target and thrust to a reasonable closing speed that will get you there in a minute or less (say, 10-20 m/s), then take it from there. The reason that works is that with such a short separation, 1. there's not much difference in the gravity vector that the two craft experience, since the separation is tiny compared with the radius of the body you're orbiting, and 2. if the closing time is only a minute or less, you won't have orbited much of a fraction of an orbit in that time, so motion is pretty close to the classic inertial case. If you were significantly farther apart-- for example, if the target were 50 km away instead of just 1 km-- then you wouldn't want to do this; it would be better to take the orbital-mechanics approach, unless you're in a big hurry and have lots of dV to spare.