swjr-swis

You did ask for a comparison 'factoring in both ISP and TWR', yes? I guess I could've ignored that the ratios between the engines correlate almost perfectly to the number of bells, and make my little analysis that much more difficult to follow by referring every time to a 'generic totally-not-based-on-an-approximate-Vector unit-of-engine'. I'm not sure that would've helped any. I agree; that was rather my point. The Twinboar leaves them way behind in the league of cost-effectiveness, even when adjusting for the differences, as shown. Hence the not-so-surprising dominance of that engine in the Eve 3000 challenge, or any situation scoring for cost. Well, at least you do recognize the underlying reason, if still denying the extent. Small steps. Note though that I in no way argue anywhere that the Twinboar is either more efficient or has superior performance, in any other way, other than cost-effectiveness (although adjusted for engine mass by recalculating through a totally-not-based-on-an-approximate-Vector unit-of-engine <breathe>, its TWR is slightly better than either Mammoth or Vector). Anyway, I don't really want this to turn into some type of argument. You expressed puzzlement with certain outcomes, and I know how annoying it can be to have the answer to something dangling just out of my reach, so I did some numbers to explain why those outcomes are not so surprising, since it seems perfectly obvious to me. That's all. I hope you find your answers.

It's called Time Dilation. It is especially noticeable when traveling interstellar distances at relativistic speeds.

Which effectively is saying the same thing...

Decouplers with integrated fairings would be nice indeed. I would be willing to sacrifice the automatic shroud option of engines to get this, because it would not longer be necessary. And I say 'fairing' and not 'shroud', because I would want it to also cover for the cases where the top is not the same diameter as the decoupler. Let us shape the shell to fit each case in the best way.

I'm a bit lost at this argument, unless you're making fun of me and I'm missing it. There are so many ways to trivially solve the 'lacking' bottom node that I have to believe you are making a joke. A radially attached truss piece (25 funds) or empty NCS cone (256 funds) comfortably offset between the engine bells, for example. Or if you want to be fancy about it: an upside down fairing on the top node, offset to move its top interstage node below the engine, for a few hundred more. Or since the context is about a lifting stage large enough to push 3000 ore to Eve orbit, the bottom node would be provided by the core return vehicle the Twinboars will be radially attached to, for zero net cost. What are we talking about here? In more general terms, since we were comparing cost-effectiveness of top-tier TWR lifter engines, there is no function (and thus no worth) for a bottom node at all - these engines are supposed to be the first to light up. If we're going to calculate net worth based on a general list of pros and cons, I still don't see the Twinboar losing: Mammoth doesn't have a bottom node either, plus it's not radially attachable (Twinboar is). Mammoth and Vector are heavier per engine than the Twinboar. At less than half the price per engine of either Mammoth or Vector, the Twinboar already comes with an integrated and filled Jumbo tank of LFO. Let's not forget this one particular little point. We'd have to penalize its cons in a very biased manner compared to the pros to really make the Twinboar lose out on any calculated net worth.

It is exactly as cheap as I said. Stock game, all default settings: Twinboar - 17000 funds wet, 14062 funds dry. Even without adjusting for the (dry) cost of the integrated Jumbo fuel tank this is already down to 7031 funds per 'engine'. Dry cost of a Jumbo is 2812, subtract even a fraction of that from the dry cost of the Twinboar, and as I stated, its price per 'engine' drops to under 7000 funds. I'll concede that the raw Isp is lower than either, but I did say 'comparable', not equal. I disagree at calling a 5.0-5.3% difference 'way way worse' in any kind of comparative or numerical analysis. Now, in the specific case of optimizing for cost, seeing how cheap fuel mass is compared to engine mass (a factor of roughly 19-28!), the massive 60-75% difference in cost per 'engine' between the Twinboar and either Mammoth or Vector becomes an overwhelming factor, relegating the marginal Isp advantage of those two to a side note. Look at it from another angle: the price difference between the Twinboar and either Vector or Mammoth buys the Twinboar a margin of roughly 1.3 Jumbo tanks of LFO per 'engine'. The Twinboar could guzzle fuel like there's no tomorrow and still come up on top. That price gap all by itself makes all the difference when optimizing for cost.

Corrected this for you. The conclusion is valid for that particular challenge, because it focuses on cost. The Twinboar is simply a ridiculously cost-effective engine in a lot of circumstances, Eve just being one of them. When it's all about bang for buck, the Twinboar is way out of the stock 'balance', there isn't really any competition. Corrected for the fuel and dry mass of the included Jumbo tank, it's less than 7000 funds per 'engine', but with a comparable TWR and ISP to the much more expensive Mammoth or Vector. Nothing even comes close to that RoI in stock.

Still would want it to be optional, because all of the above cases could still be valid bases/craft/constructs in certain circumstances. @Dfthu A base needn't be more than 5 parts - all one really needs is a crewed part and a command part... and they may even be the same single part. If we want to be 'realistic' and insist on power generation, antenna, and some form of docking, we're still only at 4 or 5 parts. @The Aziz Why would anyone want to have a surface base anywhere in KSP? Exactly, but people do anyway. People place surface bases either for roleplay reasons, or to fulfill contracts, and both of those can be just as valid for Kerbin as any other CB. Also, some people like to start their games without the extra groundstations on Kerbin and build/place their own - that would constitute a base too. I did also assume that OP does not strictly mean 'recover' only, since the Tracking Station is mentioned - the Terminate button to get rid of craft/debris works anywhere, even in orbit. @Pacca KSP and I don't always agree on what constitutes 'debris', so I don't trust it to automatically make the correct decisions in such matters. Sometimes accidentally (unexpected partial disassembly), but sometimes quite on purpose, a permanent surface structure ended up without a command part, and for what I needed it was not really required. Yet KSP immediately labels it 'debris'.

Unknown, because Squad is annoyingly silent on the issue. This last 1.6 patch they decided to increase the range of the suspension/damper sliders, apparently as a workaround. They haven't explained how that is supposed to help though, and it contradicts earlier statements that extreme values for those sliders would make matters worse. So hopefully there's still some actual fixes in the works for the intrinsic problems with the wheel system (legs in KSP are internally handled as a type of 'wheels'). A small source of hope is that it didn't use to be this way. Landing legs were once very useful - pretty reliable and actual shock-dampening suspensions and all that, and we used to be able to 'lock' their suspension too for more stability once landed. There's also mods that replace the wheel code with something that works. So the possibility for a fix exists. We're just waiting for it to actually happen.

A hard landing right next to a functional base may quickly change your mind, unless this was entirely optional. So yes please, but optional somehow.

Since it's all about player votes, I'd say that the public opinion has spoken, plain and simple. KSP has entered Steam awards before, so it's not like this community doesn't 'do Steam'. They've just not voted for KSP this time. We can all have opinions about why that is, and no doubt it will be hotly debated, but bottom line KSP has only itself to blame for not being up there this time. On the other hand: I have looked at the games that ended up on the different categories, and mostly just shook my head and shrugged at most of the nominations. GTAV for Labor of Love? Seriously? So, maybe we should be glad KSP didn't get named alongside... other games.

Landing legs have been... let's put it mildly... a bit 'touchy' for a few versions of KSP now. Regardless of what you do, there will be spontaneous explosions at touchdown. Eve is especially prone to cause such explosions, because the gravity is significantly higher, which exacerbates the problem. Theoretically, and logically, the answer should be that you look at the 'Stress Tolerance' value of the parts, and compare that to the weight of your craft (adjusted for local gravity). This number should indicate how much weight they can handle, or how many legs you need for the calculated weight. But as you can quickly notice, that value has already been raised to an absurd number in the stock game, and legs still explode anyway. So the most practical answers are: If you still want to use legs anyway: however many legs you use on Kerbin, times 1.7x, plus a safety margin of about 25-50% to allow for a few legs to explode. Legs are going to explode no matter what you do, so try to think in terms of 'how many legs do I need to have left after the inevitable explosions for my craft to remain stable'... and go with it. Use something other than legs. Ironically, just about any part not meant to be a landing leg is more reliable to land on than landing legs. The whole concept of 'suspension' is practically useless at the moment with how buggy it is, and KSP physics do not penalize sudden stops, so you may as well just pick parts with the highest crash tolerance (other than actual legs) that look like they'd make pretty legs and use those. Just keep your velocity under their crash tolerance and your craft will be fine.

About time you left LKO! Thank you for the time you shared with us. May the solar winds favour all your travels and explorations, and may your trajectory take you to interesting places.

Wouldn't mind seeing this corrected as you mention... but only after we get landing legs that work like they're not composed entirely out of nitroglycerine, and a few sets of legs large enough to use safely with the larger engines and cross-sections.

The last column of 'New Kodiak' seems to contradict itself: it is coloured green as if it's an improvement compared to 'Current Kodiak', but its entry cost is more expensive.

Your explanation contains a lot of truth and insight... but have you looked at the video I posted? I explicitly sent the pod tumbling into reentry with SAS off, to show that when placed correctly (ie. with CoM as low as possible towards the bottom of the service bay) the craft will reorientate itself correctly, without needing SAS.

With wheels the way they are in KSP at the moment, the only rule of thumb that is 100% guaranteed to be true is: if you drive a wheel over your thumb, it'll hurt. In a properly working game, the default settings should cover most of the logical use cases without problems. But wheels in KSP are still not working properly, since a Unity engine update a few versions ago broke them. Expect unpredictable behaviour, regardless of any claims by anyone of specific values being better. That said: Spring and damper - I don't bother changing these from the defaults unless the vehicle starts bouncing spontaneously at loading (which does happen with some regularity). Even then, there seems to be very little logical correlation between the settings and the behaviour. I just keep trying different settings until it stops bouncing. Friction - I usually apply low friction on front wheels and high friction on the back. This seems to minimize random skating and makes turning at speed a bit more predictable.

As others have mentioned, the problem is drag, or rather, because of the specific way you want your rocket to point/land, a lack of it. Once the fuel is expended, the engines at the bottom are by far the heaviest part of the rocket, and the rest of the rocket is, as rockets tend to be, rather sleek, so there's no drag to counter the engines from 'wanting' to get to the ground before the rest of the rocket. Airbrakes at the top would be one way to counter this, but as you've noticed they are rather sensitive to reentry heating. Two methods to protect airbrakes from too much heat: 1) pumping the airbrakes - when they start heating up too much, close them for a bit so they cool down, then reopen, etc. 2) limit their authority slider (advanced tweakables in the game settings) so they don't stick out too much outside the reentry wake. An easier alternative: place service bays between the mainsail engines and the bottom tanks, and add toggling them to the brakes action group. That way when you engage the brakes, the service bays open and provide a bunch of drag at the engine end, which should help keep the rocket pointing the way you want.

Did you look at @Tyko's suggestion (and my video, which amounts to the same thing)? The answer hasn't changed since this question was asked - it works without fail. Welcome to the forum btw.

Mutter... I still blame Star Trek for breeding an entire generation of project managers that believe replying "You have half that time." in a forceful tone will change the fabric of spacetime.

There should be an earlier part enabling Comms right from the start of the tech tree. A good name would be 'Can-U HMN'. It should be from the 'Found lying by the side of the road' manufacturer, and consist of two empty tin cans attached through the bottom by a piece of string. It would only have Direct comms capability, not be combinable, and have a very low bandwidth. To balance those disadvantages, it would require no EC for transmissions. It will need to be a compound part like the struts and fuel lines, but without a length limit so it can reach all the way from KSC Mission Control to the orbiting craft. We're still trying to figure out how to keep the string from wrapping itself around the planet. There should probably be a second slightly more advanced model that attaches three cans in series, which would obviously give it Relay capability. That way the other end could be given to a Mun rover.

Careful gents. Enthusiasm for good looking stuff is to be expected, and considering how good the teasers are looking even more so, but let's not burn out the people volunteering their unpaid time and resources at the very start of the effort. Considering how much work they are taking on, lets give them some breathing room. It'll be released when it's ready.

My answer would be: take some time off, away from KSP. Play some other (types of) games. If KSP has you hooked, it'll tug the line at one point or another, and you'll come back to it naturally. If you're having to force yourself to play, it's time to take a break.

Did you mean to ask a question and forgot to add it? Are you posting a challenge and forgot to explain the objective? Are you asking for ideas for your career, or trying to tell people how to play KSP? In short: what is this message about?

I should've phrased that differently. Kerbals spawn inside a cabin with their helmets off - at least all the stock cabins. What I was focusing on is that we have no way to change this status in the current stock game. Since they are adding a feature to the game in 1.6 to allow removing the helmet when outside, it would be logical to also allow us to do the reverse when inside... ie. put on the helmets. It's speculation though because the preview doesn't show an inside (IVA) interaction.