• Content count

  • Joined

  • Last visited

Everything posted by Snark

  1. Actually, for burn time, the math isn't the problem. In fact, it's almost laughably simple, just a bit of algebra tacked on to the rocket equation: You know the dV involved (i.e. the magnitude of the maneuver node). The rocket equation tells you how much fuel you need to use to get that much dV. Use engine thrust + Isp to calculate how much fuel per second your engine burns. Divide fuel-used by fuel-per-second. Bingo, there's your burn time. The fact that the math is so simple is why so many people underestimate the difficulty of the programming task. I know I sure as heck vastly underestimated it. The reason why it's hard, rather, is all the other stuff: keeping track of the ship state, finding all the engines, dealing with their various thrusts and Isps and orientations and so on and so forth. That's complex enough even if you just do what BetterBurnTime does. If you want to get fancier, like KER, and actually model staging and fuel flow and such, it really gets gnarly. So, it's not that it's "hard" in the sense of "have the brain of an Isaac Newton"... rather, that it's complicated because of all the infinite ways one can configure a spacecraft in KSP. So it's a labor-intensive, time-consuming job.
  2. FWIW, if you haven't already looked at it, I believe this mod does basically what you're doing there... perhaps could save you the paper chart? Yes, I know, we're kinda discussing "here's a shortcoming in the stock game", and therefore "there's a mod for that" doesn't really address the issue... just thought I'd mention it in case it might be useful. Disclaimer: I've never used the mod myself, so I'm just going by hearsay, here. However, any time the topic of "how do I keep track of the science I've gotten" comes up, seems to me that this mod is the one that I always see people recommend.
  3. Definitely a fair question. I note that you did in fact start the exchange with perfectly reasonable, matter-of-fact question in the beginning: To which I directly responded, in the same spirit, And then continued with illustrative examples and rationales, but it was basically all around the theme of "constructive feedback = helpful". If that answers the question, then great-- probably would have been good for both of us to just stop there. It also included my attempt to provide a more useful/relevant way of thinking about it (e.g. think "I'd like X instead of Y" rather than just "I'd like X"), since I've found that feedback tends to be more effective when one understands the situation that the recipient is contending with.
  4. Heh, sorry about that. But if you ask "why are things this way?", and suppose-- just for the sake of argument-- that the answer really is "because dev is hard"... what sort of a response would you find helpful? I'm honestly not trying to be sarcastic or dismissive here, I'm perfectly sincere. Don't mean to lecture, nor do I claim to have the One Right Answer-- just trying to provide some perspective on a seriously asked question, from someone who's been doing this for a living for a really long time. Take it for what it's worth. Anyway, in case there's anyone out there who does find it helpful, here's some more "omg dev is hard" lecture: No, I'm pretty sure I understand exactly what you meant. Here's my understanding of your position, please correct me if I'm missing something: You don't like that the feature's not there. You think that Squad should have fixed it, long ago, and that they were being derelict in their duty by not doing so up to now. You also believe that they're especially blameworthy if they don't do it henceforth, and just leave it in its current state. Does that pretty much capture the essence, or am I missing something important? Various rambling thoughts about that in a spoiler section, to spare folks the brunt of my verbosity. My rephrasing changes the point of the question, by design-- because the point of your original question, though perfectly reasonable from a customer's point of view, doesn't reflect the reality of how software development actually works-- at least, not in my experience over the past couple of decades of doing this for a living. It's perfectly valid to take a customer-viewpoint approach of "This is a flaw in the product; I don't like it, I'm never going to like it; I don't care what the reasons are". Totally legitimate. But if that's the case... it's hard for me to see the point of asking "why is it that way?" or "what should we do?" Sure, it's a "glaring hole." But all that does is reduce my original statement from "every single piece of software in the history of the universe" to "most software in the history of the universe." Lengthy explanation in another spoiler section, but the TL;DR is: often, releasing software with a "glaring hole" is actually the right thing to do (not just from a company-business perspective, but also from the customer's perspective, even if they don't know it). You go on to say, Sure! Absolutely, no argument there. But if you're comparing Super Mario Bros to KSP, you are comparing apples and oranges. More lengthy explanation in a spoiler, but the TL;DR is: "yes, of course it's different, because completely different situations produce different results, and Mario had the situational advantage in many ways." Moving on, Sometimes it works that way, yes. It would be great if it worked that way all the time-- certainly it would make my day job a lot less stressful. But, very often, it doesn't work that way, even for a company that's diligent and forethoughtful and trying to plan ahead. The fact is, there's always more stuff to do. And a "glaring hole" can legitimately go for a really long time-- perhaps indefinitely-- if there are always, continuously, bigger fish to fry. Which is, alas, all too often the case, in my experience. Heck, I've experienced this personally in my daily life on the job. In my current environment, on my current team, there's an ...issue. It's been around for over a year. Without going into details, it's a royal pain in the posterior, and everyone on my team-- me, my teammates, my manager-- would love to see it go away. But-- and here's the rub-- it would take at least a continuous week of my time, more likely two weeks, to fix. As in, "drop everything else and do nothing but work on this one thing for a solid couple of weeks." And guess what? Not once in the past year has there ever been a two-week window where it would be okay to drop everything. Because it's a pain point, yes, but there are other, more urgent pain points. So it doesn't get worked on-- and not working on it is actually the right decision in our case, since this other stuff is genuinely more important and urgent. I'm not trying to defend or apologize for Squad, here. For one thing, the lack of this feature annoys the heck out of me, as a player. For another, since I don't work there, I have no visibility into their internal workings and don't know any more about what actually happens there than you do. Heck, for all I know, you may be right, and maybe they are being derelict in some fashion and "it didn't have to be that way." But we don't know that. And looking over the past 20+ years of miscellaneous crises and fire drills, I gotta say that in my experience, the cases of "there are good reasons for what happened, even when everyone was making a good-faith effort to do the right thing" vastly outnumber the "whole organization is boneheaded or irresponsible" ones. So I'm inclined to give the benefit of the doubt. For example, and to make things a bit less abstract: Consider the SAS tuning in KSP. Remember how horrible it used to be? Remember how it would overshoot all the time and result in slow, agonizing oscillations? Remember how you'd tell it to "hold retrograde" or whatever, and the nav ball would start going in the wrong direction entirely? Remember how a vessel with overpowered reaction wheels would jitter like a crazed gopher after a triple shot of espresso? It was horrible. Certainly, for me as a player, it was a lot more impactful than the burn-time indicator. After all, the problems with burn time only affect me when I'm executing a maneuver node, but the SAS problems got in my face all the time whenever I'm trying to steer my ship. And it's not as if it's an insuperable technical problem. Non-trivial, sure-- I don't mean to make light of it. But certainly it's not any harder than solving the burn-time indicator issue-- easier, in some ways. But despite being arguably worse for players than the burn-time, and despite being (presumably) not any harder to solve... it lasted frickin' forever. They didn't get around to fixing it until 1.2! So... why do you suppose that is? Is it because they didn't know how to fix it? Clearly not. They did fix it. It's not rocket sci-- well, okay, it is, but it's well within the technical capabilities of the kind of dev who works at Squad. Is it because they don't know about the problem? Absolutely not. Everyone was complaining about this, for years, constantly and loudly. They obviously knew about it and were well aware of the impact on players. Is it because they simply didn't give a damn about the players? I strongly contend no. During the time leading up to 1.2 (though, alas, not any more), the Squad devs were very approachable, often online in IRC and/or posting here in the forums. They're clearly passionate, dedicated people who don't want to ship crap, take pride in what they do, and clearly want to give the players a good experience. So: given that they knew about the problem, had the wherewithal to fix it, and (presumably) really wanted to fix it... why the heck did it take so long to fix? There's only one answer that makes any sense to me, and that is: because they were busy with other stuff that was more important. And so it literally wasn't until 1.2 that they had enough breathing space to take care of that. Players were justifiably irate that they had to wait so long for such an important fix... but unfortunately, that doesn't change the practical realities of software development. Well, goodness knows I'm no marketer, nor do I claim to have a crystal ball. But if I had to take a guess? I wouldn't be surprised if the answer to your question is "no, there is no such configuration". Slowing down customer purchases would have sent the signal to the company "this is an unpopular product and isn't making as much money as you hoped." It would have reduced the cash flow which is the oxygen supply of any business-- it would have reduced their ability to hire and retain developers, and therefore the amount of engineer hours they can spend on the product. So taking a strategy like that may very well have backfired-- e.g. they may have just decided to pull the plug on KSP and go elsewhere. More rambling on this aspect in yet another spoiler.
  5. The short answer is: Provide frequent, good, constructive feedback, somewhere that the developers can see it. It's worth noting, though, that you're phrasing it wrong. Everything needs to be worked on. All the time. It's how software works. And it's an economic reality that there's never enough time, money, and people to do everything. Which means, invariably, there's going to be stuff that "needs to be worked on" and never is. So, if your complaint is about "software that has something missing that needs working on that never is", you've just described basically every single piece of software in the history of the universe, past present and future. The issue here is therefore not "they didn't give us X". The real issue is "they gave us Y instead of X", where Y is some other (hopefully important) feature or bug fix. So, with that in mind, here's what the real question should be: The answer is simple: We do it by providing frequent, constructive, vocal feedback about what we like (or don't). Such as this thread, for example , and others like it. This helps the software developer by letting them know what's important to their customers. (It's not always obvious, when you're sitting in the developer's chair). For example, if you went to them and said: "I really want a better burn time indicator. Please stop fixing bugs with the wheels and leave them broken, because I never play with rovers anyway. So please give me a burn indicator instead, it's way more important." And then a hundred people will chime in and agree with you. And then a hundred rover fans will join in with howls of rage, saying the exact opposite: "must fix wheels NAO, forget the stupid burn indicator, it's less important". And then a hundred other people will say they should be working on yet some other feature, never mind the wheels and the burn time. And then, one hopes, somebody at the company would pick through all the feedback and try to form some sort of coherent picture of what most players want, and then try to chart a course through the rocky shoals of Can't Please Everyone. Sure, if this is such a big deal to you that you honestly think KSP wasn't worth your money without it. But... really? I dunno about you, but that's laughably not the case for my own experience. I adore KSP, spent US $27 in exchange for literally thousands of hours of entertainment. I don't think I've ever seen that kind of value proposition from any product I've ever bought, software or otherwise. It could be shot full of a lot more holes than it actually has, and still be way way way on the "plus" side of the ledger for me. Does that mean I like the holes? No. But I keep them in perspective. It's a little indie game by a small team of developers sold at relatively small volume (compared with something like Starcraft), developed on a relative shoestring, so it's gonna have the kind of warts and imperfections you get when you buy, say, a hand-crafted mug at an art store instead of something cranked out by a mega-factory. So what do I do about it? When I see something I don't like, I provide constructive feedback here in the forums. If enough people do the same, and if it's not too hard to fix, often they actually fix the problem. If it doesn't make the cut, then it doesn't, and I pick up and move on with life. (And if the problems are too numerous relative to the value I get from the game, and if the developer seems too unresponsive, and it's making the game not worth my while... then I vote with my feet-- or, more to the point, with my wallet-- and go elsewhere. Fortunately for me, I've never gotten close to that point with KSP.) You'd be surprised how effective good constructive feedback (as distinguished from "yelling") can be. Speaking as a software developer: good constructive feedback is golden, and is a great way to influence developers. I know it seems sometimes like "this damn game is full of holes, they're asleep at the switch"-- but as with any software, for each high-visibility thing that isn't fixed, there are a hundred time consuming things that are, which may not even get noticed. (But would have, loudly... if they hadn't been fixed.)
  6. That's right. Because we have free time. Scads of it. Squad devs... don't. Whatever else one may say about them, I don't think anyone is proposing that they've ever been sitting around twiddling their thumbs without enough to do. My impression is that they've been frantically busy pretty much continuously, all the time, for as long as I've been playing KSP. "Able", yes. That doesn't mean the same thing as "it's the right development decision, given all the other priorities they have on their plate." It's not an "excuse"-- it's an exercise in workflow optimization. It's totally doable. But the fact that it's so complex means that it's a really expensive feature to deliver, which means it would suck a lot of oxygen out of the room for all the other features (and bug fixes) that are also really important. It's how things work in software development. Much as I'd like to see a 1.4, I wouldn't hold my breath. My guess would be that at this point, the core game is basically just in "keep the lights on" mode while they devote their real time and energy to working on "Making History" (and perhaps subsequent expansions that they can charge for). Pulling out my crystal ball for a moment, my best guess is that we may see a few minor 1.3.x type updates to the core came... but if we do, it'll only be for bug fixes, and/or any changes they need to make to the core game in order to enable particular features of future expansion packs. I could be totally wrong about that, of course. I don't work for Squad, and therefore don't have any more visibility than you do into their internal decision-making process. But I've been working in this industry for a long time, and I've shipped and awful lot of products from a lot of companies, and that's what my gut tells me. Let's be clear-- this is a major feature. So it's not a "polishing" kind of update, it would be a "major feature release" kind of update. Not in this case. The reason this is hard is not because "trying to work through the modding API is awkward", but because it's a fundamentally difficult design problem. So no, it wouldn't be even slightly easier for Squad to do this than it would be for a modder. Considerably more laborious, in fact, since they'd need to go through a rigorous QA / testing process, which mods don't. Oh, no problem, I didn't take it that way at all. Absolutely, expect more from the developer of the game. No argument there. And yes: if KER can do it, so can they. The problem is that "can" simply isn't even vaguely enough. Software development projects are always under the budget & scheduling gun. There are always far more things to do than there are time, money, and engineers to do them. Which means everything is a tradeoff. It's a zero-sum game. Doing one thing means not doing something else. And deciding what not to do... is really really hard. Speaking as a developer myself: deciding "which really cool, really useful feature do we cut" feels a lot like deciding "I can't feed all my kids, which one do I give up for adoption". It's difficult, and seriously un-fun. But it's necessary. The typical discussion that comes up whenever some feature is proposed goes like this: What's the benefit? (i.e. how badly do we need this? what does it gain? what does it lose if we don't?) What's the cost? (i.e. how many dollars and engineer-hours is it likely to be?) Put those two things together, then compare the various proposed features, bug fixes, etc. to see how they stack up, and that's typically how the priority goes. Yes, it's a glaring hole that KSP doesn't have a better burn time indicator. But there are plenty of other glaring holes, too. (Unavoidably so; finite resources, finite time, small team-- you can't do everything.) And there are other, formerly glaring holes that aren't there anymore, because they did get addressed. But at least some of those former holes wouldn't have gotten filled in, if they'd decided to give us a burn time indicator and/or dV display instead. So, if you're prepared to point at some other feature in the game of comparable complexity (i.e. "number of engineer-hours required to implement") that you (and a majority of KSP players) wish they would have cut in order to make room for a burn-time indicator, then that's a perfectly valid thing to do and we can have a discussion about that. But "add this extra thing" simply isn't something that happens. It's always "do this thing instead of that thing." I'm not saying that they necessarily made the right decision. Just that I don't know that they necessarily made the wrong one, either-- certainly I don't think it's a slam-dunk.
  7. Which is exactly what the stock burn-time indicator (that everyone hates, which is what this thread is about) already does. You're right, that's simple and quick. Which is presumably why it got done that way. But it has lots of problems with it-- see discussion in my post above.
  8. ^ This. Speaking as a professional software engineer who's had occasion to interview literally hundreds of job candidates... good people are really hard to find. These are good guys, I expect they'll land on their feet. No clue. However, based on my experience in the software industry, there's one very clear "ulterior motive" (if that's the right term) that every software company has: "Hire good people." It's difficult. They're hard to find. If you find a good one, snap 'em up. Heck, I'd love to have 'em where I work, and we're not even a gaming company. "These are tried-and-tested game devs, and Valve is a gaming company and needs game devs" is the explanation that Occam's razor tells me. Probably best not to read a whole lot more into it than that.
  9. Treating this as a rhetorical question: +1, I'm totally with you (and the other posters above) on this one. Would love to see a better burn-time indicator in the stock game. Treating it as an actually serious "why" question: Probably because it's actually a significantly big chunk of work to do it well, so it just never got high enough up the priority list for Squad to bump some other feature to make it happen. Calculating burn times is a lot more complicated than you probably think. ^ Tip: It's a lot more than a "couple of hours". Lots. I mean, astonishingly lots. When I first set out to write BetterBurnTime, I was thinking pretty much the same as most people probably do: "Well, this is stupid. It's a simple piece of math, it ought to be a trivial fix." I should just take an hour and write a mod to Do It Right™. Heck, I'm a physics major, I already know the math, it should just be a simple coding job, right? Well... yes, it's doable, but it took a lot more time than I expected, because there are a whole lot of issues that don't leap out at you until you go to actually code it. Here's a post in the BetterBurnTime thread where I describe some of the complexities that reared their ugly heads, for anyone who may be interested. And that's for the simple case, where (as I do in BBT) one chooses to completely ignore all staging and fuel-flow limitations. If you want to try to incorporate those, too (as KER does-- note Alshain's post above), then it really gets complicated (another BBT thread post discussing this). Not that I'm defending the lack of a decent burn time indicator in the stock game. I would love to have a better one. Just... it's a significant chunk of work that includes non-trivial design choices, and doing it would involve making tradeoffs with all the other things also demanding the devs' attention. So, having been a professional software engineer for a good long while and having seen the kind of ingredients that go into this peculiar sausage we call "software", it's not totally surprising to me that it could have kinda fallen by the wayside. Regrettable, yes. Surprising, no. ...and I'll assume from the tongue-smiley that the above is at least half-joking. To be clear to anyone reading: taking actual BBT code (or KER code, or any other mod code) for the stock game would probably be a bad decision, in terms of software development. Mod code is not the same thing as core-product code; it's almost never the right choice to try to integrate a mod's code (unless it was written by the game developer in the first place, and specifically designed for later inclusion). And in any case, if you were to want to integrate something... frankly, BBT's not a great poster child. It was one of the first mods I wrote, when I was very new to KSP coding, and I did a lot of things that were kind of... awkward... simply because I didn't know any better. I tidied up some of that stuff later on, as I learned more of the nuts and bolts of how KSP mods work; but there are other warts that are baked into the mod's DNA and aren't easily changed now. If I had it all to do over again, it would be written more elegantly from scratch. (And, speaking as a software developer, it still wouldn't be a good idea to try to just move it into the stock game.) Staging and fuel flow are really, really hard. (Discussion here.) It's a big part of why KER is such a gargantuan, complex mod (easily at least ten times the code of BBT, which is itself non-trivial). It's why BBT doesn't even try. It's why having a delta-V calculator in the stock game has also been an elusive goal. Again, not impossible, just... a really big design & coding job. ^ Gotta say I tend agree with regex here. Mainly because it appears (with the announcement of "Making History") that Squad is shifting resources away from core game development and seems likely to focus their time on expansions, going forward. They're a business, they gotta pay the bills-- and at this point, I suspect that packing more big, expensive-to-develop features into the core game, for free, is unlikely to generate any revenue for them. So at this point, alas, it's probably the right business decision for them not to. Would love to be wrong about that, of course. Not impossible, but I suspect it's really unlikely, for the above reasons. Pretty sure it's not. At all. Even slightly. I've seen no evidence in the game to indicate this, and I've also seen nothing in any of the modder-accessible APIs that I've tinkered with (and I've done that a lot, in the course of writing BBT). Certainly there's nothing in the stock game that would require this-- the only reason to have calculations like that would be for displaying them to the user, for the user's convenience. The game itself doesn't need any delta-V calculations. Engines define their Isp and their fuel consumption rate. You turn on the throttle, acceleration is applied as per thrust, fuel drains out. When the fuel's all gone, the engine stops thrusting. There's no concept of "calculate net delta V" there anywhere.
  10. Yes, you can tinker with your notification settings. It's highly customizable-- you can choose which things you do and don't want to be notified for, and also how you want to be notified. (How to find the above page, other than just following the link: there's an "Account Settings" item in the menu next to your profile picture at top right. Go there, then choose the "Notification Settings" link.)
  11. Why, yes, as it happens I do know that (y'know, being one myself). It lasts for your first five posts, then automatically goes away. Sorry for the inconvenience-- we know it's a hassle, but it's a necessary precaution against spambots. (If you're actually a cleverly written spambot, do us a favor and let us know so we can go ahead and ban you, okay? <-- joke) Anyway, the good news is that you're over halfway to five posts already.
  12. Hello, and welcome to the forums! Be patient-- you just posted it a couple of days ago. Also, bear in mind that the "challenge" forum can take time to acquire responses, unless you happen to strike gold with something that especially interests people. Bear in mind that not everyone is interested in the same activities; participating in a challenge means devoting a fair amount of personal time and energy, so folks tend to be a bit choosy. There's only a small minority of forum users that are going to be interested in any particular challenge, so it takes a while for such users to find and sign on. (Other forums are generally a lot quicker to respond; e.g. Gameplay Questions posts usually get an answer within minutes or hours.) So, just give it time, is my suggestion. It can take a while. (And there's no guarantee. The Internet is a fickle place.)
  13. Download links have been removed from the OP due to licensing issues. To be able to redistribute, either you need to show that the original mod had a license that allows you to do that, or else that you have permission in writing from the original author. Our understanding is that the original mods from Astronomer were ARR (all rights reserved), i.e. the most restrictive license, which basically doesn't allow doing anything at all (including re-hosting on another site). This prevents being able to publish this mod, unless you have written permission from Astronomer. Thank you for your understanding.
  14. Anyway, @capt: scarlet, the "materials bay" is this part, the SC-9001 Science Jr., as some folks have pointed out here: There are, alas, several KSP parts that have completely cryptic "chatty" descriptions in contract language, where they're referred to by names that have nothing to do with the actual part names. For example, calling the SC-9001 Science Jr. a "materials bay" in contract descriptions, despite the fact that neither "materials" nor "bay" appears anywhere in the part name, part description, or anywhere else except the contract itself. There is no way in-game for a player to be able to know this, unless they simply guess the answer or someone tells them. It's a pain point that has been remarked on before.
  15. No worries, we were all new once! Forum tip: If your question has been answered, you can mark it as such by clicking the gray "check mark" icon to the left of the post which you feel is the "best" answer to your question (perhaps Dman's post above, in this case). That will mark your question as "answered" in the list view, which can be helpful to folks who may be browsing for answers or for people to help.
  16. A really heavy, dense ship (i.e. an ore carrier) hitting Kerbin's atmosphere at Minmus-reentry speeds (e.g. 3000 m/s or thereabouts) is going to need heat shields or it's gonna go kaboom. Nice explanation from @bewing above. That said, you can totally make this work, as long as you have heat shields. Note that you don't actually have to have ablator, so you can still have a re-usable ship. The inflatable heat shields work great for this purpose: they're huge, so they do a good job of slowing down really massive ship. Here's an example Minmus-fuel-hauler ship I had a few careers ago: It's built around the biggest-size 5m liquid fuel tank from SpaceY. I'm transferring refined fuel rather than ore, but the same principle applies. This ship can aerobrake just fine, and repeat the cycle ad infinitum. Totally re-usable. Note the engines' slight outward angling, so that their exhaust misses the heat shield in the rear. The ship is nearly 400 tons when carrying a full load of cargo. It has to dive down to a Pe of only 28 km in order to aerobrake to LKO in a single pass. Gotta say that plowing 400 tons at 3000 m/s through atmosphere at 28 km gave me the longest aerodynamics-overlay drag arrows I've ever seen. Anyway, stick an inflatable heat shield or two onto your ship, and you'll be fine. The right altitude will totally depend on the mass and shape of your ship, though, so you'll almost certainly need some trial and error to find the right altitude for any given ship. F5 is your friend.
  17. Regarding KIS and KAS: Actually, you only need KAS (though KIS can be a nice complement to it). +1 to this, I do it all the time, it's my preferred way. Just to clarify for anyone not familiar with these mods: Kerbal Attachment System (KAS) is the one that has the "connector port" pieces that let your EVA kerbals hook things up with pipes. If all you do is to put these ports on your various base components and on your rovers and what-not, that's all you need . Kerbal Inventory System (KIS) lets your engineer kerbals dynamically attach and detach individual parts on-site using tools. It's a handy complement to KAS, but not strictly necessary. If you're going for "minimal mods", you can install just KAS. KIS does work nicely together with it, though. Things you can do if you install KIS, too: First, it lets you revise your bases; for example, suppose you have some ships which you launched, without the foresight to have connector ports in all the necessary places. You could launch a repair ship with an engineer who has some connector ports as "spare parts" in inventory; the engineer then attaches the ports on-site so that you can link up your craft. Second, KIS includes some additional parts that can make it easier to link things together in surface bases, such as a concrete "pedestal" you can install on the ground, to which you can then attach a pylon with connector ports. Makes things more convenient-- but not, strictly speaking, necessary.
  18. Great post, but I disagree with this one statement. Yes, Terrier is horrible at sea level. But you don't need to go anywhere near 20 km to get good use out of it. Terrier works great even at 10 km. Reason: what it cares about is "what percentage of an atmosphere do I have?" At 10 km, atmospheric pressure is only around 10% of ASL, IIRC. That means you're 90% of the way to a vacuum, and the Terrier gets very close to its vacuum Isp. So, absolutely don't use a Terrier on the launch pad, but once you get over 10 km it's fine. Even a little lower would probably be okay. That said, this discussion's a bit of a red herring where the OP is concerned. With a ship as described, I expect he'll be way higher than 10 km before the Terrier kicks in. And if he's not, then the real problem will involve that, rather than how the Terrier does after he starts it. @MoridinUK, what's your altitude when the Terrier starts?
  19. In general, when you have a problem in KSP such as not being able to make it to orbit, the problem will, broadly speaking, be one or more of the following: You're building it wrong. (e.g. inefficient design, or just not enough dV, or what-have-you) You're flying it wrong. (e.g. gravity turn not executed well) You could have one of these problems, or the other, or both; so to be able to narrow in on just where the problem lies, we'll need some more information. Thanks for the description, though it would help to have a screenshot (sometimes a picture is worth a thousand words). For example, how is this controlled? I don't see any mention of either a command pod or a probe core. (Or is the kerbal engineer a command component, like a probe core? I don't know, since I never run KER myself). For example, without seeing a picture of your ship, it's hard to tell whether it's aerodynamic or not, which in turn could affect how much of your dV you waste due to aerodynamic losses. ^ This. This right here. Try a launch, and note the situation when you hit 45 degrees. Specifically, what's your altitude? how fast are you going? The ideal shape of the curve will depend somewhat on your TWR, but in general you should be hitting 45 degrees somewhere in the 8-10 km range for most TWR ranges, and at that point you should be going 300 m/s (or significantly faster). If your gravity turn is too aggressive, you end up hitting 45 degrees too low and too slow. You end up flying sideways really fast through the thick soup of the lower atmosphere, and waste all your dV fighting drag rather than climbing to space. If your gravity turn is too timid, you end up climbing too steeply and don't hit 45 degrees until you're really really high up, which means you're not making efficient use of your dV-- essentially you're blowing a big wad of it in climbing mostly vertically to a high altitude, then doing a right angle turn to accelerate sideways. That can work, but it is making very inefficient use of your dV, and will require more dV to get to orbit than a well-executed turn would. Not necessarily. What you really care about is "how much dV am I losing to drag?"... and you should be aware that visual Mach and flame effects in KSP have almost no relation to how much drag you're actually experiencing, particularly in the upper atmosphere. In particular, when you're in the 25-45 km zone, you can have spectacular flame effects, even when the actual drag force is negligible. It's just eye candy, and harms nothing as long as you don't heat up so much that you actually explode. That doesn't mean that drag isn't real, or that you don't have to worry about it-- just that you shouldn't rely on "how dazzling the flames are" as a guide to "how bad is the drag problem". What really matters there is, 1. how aerodynamic is your ship (for which we'd need to see a screenshot), and 2. how fast you're going at what altitudes (for which we'd need more information about your trajectory). So, @MoridinUK, it would help if you could provide the following information: A screenshot of your ship. Also, what's your total ship mass? When your ascent hits 45 degrees, how fast are you going and what's your altitude? When your ship finally runs out of fuel, what does your trajectory look like? (A screenshot of your trajectory, in map view, would be most useful.)
  20. KSP career seems to break down fairly distinctly for me into three phases: early, mid, and late career. And my favorite one generally works out to be "whichever one I haven't done for the longest time." My career lifecycle generally looks something like this: I start a new career. Love the early career! Everything happens fast, it's simple, it's laser-focused on each individual mission, just getting to orbit is a challenge. Enjoy the heck out of it. After a while, the novelty wears off and I start wishing for something a little meatier. It's mid-career time! Yay! Hey look, I can do all this fancy stuff that I couldn't do in early career. Get out there and start launching lots of missions! Build a comm network, start hitting other planets to fill out the top end of the tech tree, set big wheels in motion to prepare the way for the Big Story Arc of late career. After a while, the novelty wears off and I start wanting to get to the real pay-dirt of late career where I can build big grandiose stuff (just what kind of stuff depends on the career-- I plan a different story arc for each one.) It's late-career time! Yay! Hey look, I can go anywhere and do anything. Now I can do whatever I want! Plow lots of blissful hours into setting up an extraordinarily elaborate system of mutually complementary missions to advance the grand story arc of the career. After a while, I've accomplishd the goals. "I want to go there!" has morphed into "Been there, done that". It's satisfying, but not exciting on a minute-by-minute basis, the way it was back at the start of the career. Go back to step 1. Basically, each time I move from early career to mid career to late career to starting the process all over again, there's an adrenaline rush of novelty. So I guess my short answer to the question "Which phase of KSP career do you enjoy most?" is: The next one. It's the circle of life.
  21. Moving to Add-on Discussions.
  22. Hello, and welcome to the forums! I note that you've posted this in the sub-forum for modded installs. The first thing I'd suggest checking is whether one of your installed mods may be causing the problem. Try running a plain-vanilla stock copy of KSP that has no mods at all installed. Do you still have docking problems, or not? If the problem goes away when you uninstall your mods, then that tends to point the finger at a mod as being the culprit. The next step would be to narrow it down to figure out which one. Even if you have tons of mods installed, you can narrow it down fairly quickly by doing a "binary search", like this: Run with half of the mods installed. Does the problem still occur, or not? This tells you which half contains the culprit (i.e. the currently-installed half if the problem occurs; the currently-not-installed half if the problem doesn't occur). Based on that, pick the half that presumably contains the problem, split it in half, and repeat the process. In this way, you can cut the list of candidates in half with each cycle, which means it'll pretty quickly narrow down to just one, even if you've got a hundred installed mods. The other thing that I'd suggest is to provide more details so that people can help you better. When you say "doesn't dock", meaning what, exactly? Does the magnetic docking field engage, or not? Could you provide a screenshot of two ships trying to dock, where you would expect docking to happen but it doesn't?