Streetwind

I have had a similar experience when using jetplane parts in the VAB (which would be the opposite of what you were doing). Experimented with jet engine equipped liftoff boosters. One intake, one jet fuel fuselage, one tricoupler, three engines - this six-part booster assembly will freeze my 4.2 GHz Haswell CPU for 1-2 seconds when I move it to touch a radial decoupler and it switches to 6-fold symmetry. The same computer can effortlessly handle subassemblies of 50+ pure rocket parts in the same scenario without even a noticable slowdown. Upon pressing launch with a jet booster equipped rocket, the loading time is also vastly increased (four to five times as long).

I would be careful with what you declare as a fact. When lajoswinkler said "around 0 K", that was purely a guesstimate on his part. Unless someone wants to put money down to unlock that research paper I mentioned or find a copy of this old booklet, we have zero information as to the properties of this solid (and even if, there's no guarantee that the paper mentions what we want to know, as it focuses on a fairly narrow topic). This is how misinformation about a scientific topic spreads. Wild speculation should always be designated clearly as wild speculation, and any mention of the word "fact" avoided. Even as a figure of speech.

...I could just have looked at the equation, couldn't I. See, that's exactly my issue everytime this happens And all it takes is for someone to play Captain Obvious. (I must be getting old...)

I learned something new today! Awesome trick, must try out. ...which does not address the issue discussed in this thread at all.

Sometimes I get a bit confused with maths and physics, and when trying to decide whether a thing works one way or the other, I make up compelling arguments for both sides and subsequently become unable to figure it out by myself. The best thing in this situation is to hear someone else spell it out. In this case, I was trying to compare engines running on different propellants. Liquid fuel vs. monopropellant for instance. And I was wondering: is an Isp value given for an engine running on fuel type A directly comparable to one given for an engine running on fuel type B? Or is its meaning specific to one kind of fuel only, and you would need to translate the other number into that frame of reference before comparing? I suppose this boils down to the result of the following hypothetical scenario - an engine with 500 Isp fed by fuel tank A and an engine also with 500 Isp fed by fuel tank B. Tank A contains 1000 units of fuel A, which weighs 1 ton in total. Tank B contains 5000 units of fuel B, which also weighs 1 ton in total. Do the two engines run out of fuel at the same time, or will one run for longer than the other?

Rakaydos: yes, which is exactly why there's talk about bonding it into the IV-A form which would be stable and storable unless heated. I've been looking for more information on He IV-A, specifically reliable and trustworthy information with a real science background... but I've only really found a single unassuming research paper locked behind a paywall (without an academic login anyway). This seems to be a topic that's either being dealt with hush-hush (because JPL believes they can make it work soon and subsequently monopolize a major advantage in propulsion), or one that's so far ahead of contemporary technology that anything more than speculation is a waste of time. A part of me wishes that it's the former, although realistically I'm forced to believe the latter Mind you, though - as exciting as these numbers sound, if the info we currently have is to be believed, then that would mean that this fuel would be for solid rocket motors only. In other words, at best you could have a prefabricated burn sequence via grain sizing; but you'll never have liquid fuel engine advantages such as throttle control, shutdown and restarting or built-in alternators for power generation.

No they don't, not unless you use docking ports. Unity can only derive a part from one parent part, and you can never loop back. If there are four valid connection zones between a quadcoupler and a second, upside down quadcoupler, then one of those four connection will work and the other three will not because that would be looping back to the parent.

Nitpick: 500 mN =/= 0.5 kN 500 mN = 0.5 N = 0.0005 kN You want to use newton, not millinewton. This is physics, you can't just use a unit that's three orders of magnitude off!

Yes, this works reliably. Just make sure you fly ahead of the Kerbin system for the easiest time returning. Then all you need to do after exiting Kerbin's SoI is to perform your science and then brake hard (burn retrograde). Kerbin will simply catch up with you again and collect you along the way (you will see a Kerbin intercept show up after you burned enough).

That sounds interesting. Is that a planned* feature? (* in the sense of statement of intent from Squad)

The main tradeoff to "moar thrust = better" is the fact that increasing thrust usually comes in tandem with decreasing Isp. That means you'll be burning less fuel to fight gravity but you'll also be burning more fuel because your engine is less efficient.

Ooohh, I see. That actually makes a lot of sense. The SAS is probably compensating the minor differences during straight flight, but when I am steering I am monopolizing the control resources (reaction wheels and gimbals) and so the spin can propagate uncountered.

Now that I am home, I went ahead and made a test. As expected, the mainsail sucked my fuel tank dry before I could circularize even with careful throttling to stay at terminal velocity... but here's the thing: the rocket flew straight as an arrow the entire time. Not even the tiniest hint of rolling while steering. In fact it was one of the most well behaved rockets I've ever flown (with the caveat that the main engine had to be running in order to steer, but that's what it was designed for anyway). It seems then that it's really the quad-cluster of engines that induces rolling, even when perfectly in symmetry. Kind of a bummer, I like the ability to build a thrust profile not available in a 2.5m engine, or benefit from better Isp.

Or maybe they just saw the reason in the arguments presented? Contrary to popular belief, most people who enjoy playing mods are actually quite respectful towards the wishes of mod authors. It's sadly the bottom 10% who make enough problems for many times their numbers... If you or ferram or sarbian express your dislike for modpacks, then I have no issue accepting that. Besides, I'm not a "doer" in the sense of releasing anything anyway, I just like to tweak my things and explore various experiences. So you definitely don't have any drama to fear from my direction. Not really on topic here so I'll be brief, but you basically download an API that comes with a one-click installer. You then launch the client once to initialize it, after which you get a "mods" folder in your install directory, into which you drop downloaded mods. You don't even need to unzip them. Fun bonus: the stock launcher can support an unlimited number of parallel game installations of all versions past, present and future, both modded and unmodded. That's something I would definitely love to see added to KSP after they finish building the game itself! Now, while that API's mod ecosystem is huge and constantly growing, there are also still a good number of legacy mods that do jarfile editing with all its annoying downsides, even though Mojang explicitly forbids it in the EULA. This is because Mojang has unofficially stated that they're not going to actually enforce that until they have their own stock API finished. Currently, only mods using the aforementioned third-party API are fully EULA compliant, and enforcing the EULA would basically result in Mojang forcing everyone to use a non-Mojang product for modding Minecraft, which is a can of worms nobody wants to open. So basically it's come a long way but isn't completely there yet. By contrast, Felipe really did the community here a huge favor by concepting KSP as moddable from the start.

I'm using a quad adapter, so the alignment is perfectly even. I've also added Kerbal Joint Reinforcement and the rocket behaves no different than before. I'll keep an eye on the roll indicator, but gut feeling says it rolls with SAS off too (I may have turned it off midflight once or twice in order to have an easier time wrestling the rocket around while coasting). Yes, I mean rolling, as in the same motion induced by (or countered by) the Q and E buttons. My rocket flies perfectly straight with SAS on; it's only when I try to pitch into the gravity turn that it induces roll. I'm using the quad cluster of engines in this case because they give more thrust than a single skipper equivalent engine and have much better Isp than a mainsail. There's a significant time during which the rocket climbs using the already slightly underpowered central stack only, after shedding its liftoff boosters. Hence I can't afford to lose about 25% thrust by dropping down to a skipper. Meanwhile the fuel usage is such that the rocket finishes circularizing a 70km orbit exactly when the fuel on the ascent stage runs out, which leaves the decoupled transfer stage to go wherever it wants with a full tank. A mainsail would guzzle too much. Too bad there's no 2.5m engine with ~1000 kN thrust in stock or the mods I have... Maybe I can tweak one of KW Rocketry's some to fill that niche. The roll happens both while boosters are still present and after they have been shed (but they're liquid boosters, not SRBs). That said, the thing is strutted all over the place, and there's some OX-STAT panels that are in 3-part symmetry and not 4/8-part like the rest of the rocket, and two spotlights in a 2-part symmetry on the lander. But, those things clock in at 5 kg each, on a rocket that weighs 150 tons. Winglets I've considered; I usually include them, but in this design they don't fit well because the bottom of the rocket is surrounded by no less than 8 boosters (I blame Jeb). Because of the way winglets attach to circular surfaces, it's almost impossible to attach them without having them clip into a booster, and they would definitely be awkwardly offset from the normal axes of symmetry I am using for the rest of the build. As you can see, I've already put a lot of thought into that rocket, and trying to change it pretty much boils down to starting over fresh anyway. That's okay, I don't need help fixing it, it does work reliably after all. It's just a little willful during ascent. My question was more directed at gaining more insight into the nature of things that cause a rocket to roll while trying to steer it. To that end I've gotten some good info here.

I hope you guys don't mind if I hijack this real quick... this is something I've been quietly scratching my head about for quite a while and just never got around to asking. Basically, I have a rocket that is mostly steered via thrust vectoring during the gravity turn, because the ascent stage is so heavy that adding reaction wheels shows little difference and RCS would just become dead weight as soon as the ascent stage is discarded (the upper stage doesn't need it). And I have found that this rocket has a severe tendency to roll around its axis whenever I steer with the engines this way. Makes controlling the turn rather tricky as you can imagine. The thrust vectoring is provided by four 1.25m engines on a 2.5m quad adapter; other engines are present but don't have gimbals. Now that you say "multiple engines would also let you roll", could that be the reason the ship rolls itself inadvertedly? Mind you, I am not touching ya or roll controls at all, I am simply pitching along a symmetry axis between those four auto-synchronized engines. All four of them should divert their identical thrust by an identical amount in an identical direction. But still it starts rolling, even against the reaction wheels (which are very good at controlling roll despite struggling with yaw and pitch). Could you try help me understand where this rolling force is coming from?

Thanks for the links, they were very informative. While I understand that you feel strongly about the topic, I disagree with your assessment that there would be nothing to gain from prebundled packs. I've recently been trying out different KSP mods, and in all honesty, as soon as you get more than 2-3 installed at once, it gets both bloated with redundant parts and disjointed in terms of intended user experience. Also, if you want to play career mode, you're wasting a ton of potential without a custom tech tree - which must be tailored to the mod selection and/or vision at hand. I've briefly tried a few standalone tech tree mods, but most of them try to accomodate all mods ever and thus end up unplayable for any particular subset (unless you don't mind 8 out of 10 nodes being empty). Now I've no issues with editing stuff together for myself, but I thought I might as well check if someone else already had a similar idea. Might save me hours of work, you know? Asking mod authors to coordinate with each other to an extent where this is no longer an issue is both infeasible (it would limit creativity/variety in design) and extra work on their backs which takes away from development. It seems a much better idea for a player with free time and a vision for a specific experience to take on the task of integrating the mods he wants, and then offer that experience to other players to discover. If redistribution of mods is undesired, then a simple config pack could be provided, which merely overwrites config files on the end user side or works through a ModuleManager plugin. People would then download the mods themselves and simply use the config pack to integrate them. Of course the concerns of developers voiced in the other threads are valid as well, and I in no way support parading someone else's work as one's own. I just don't think that dismissing the idea of bundles with "there's no need" is a valid argument, because clearly there are people who see a need. Else this discussion wouldn't reappear so frequently. (P.S.: Minecraft has had drag-and-drop mod installation with zero jarfile editing for well over a year now.)

Some games, like Minecraft, have seen their modding scene progress well beyond simply having a selection of individual mods to choose from. Interested players can find a wide variety of full modpacks, which are pre-bundled collections of a number of mods, usually even with custom configurations et al. This of course raises the question: could one do this for KSP? I have not seen such a modpack yet (apart from one or two mods that bundle little helper plugins or mention that they are designed to be run alongside a specific other mod). So now I am curious why. Is there simply no demand for it, or are there legal reasons? I am not very good with that topic, so I'll attempt to summarize what I think I understand about mod distribution. Please correct me if I am wrong. As stated in the sticky, every mod posted must have some form of license. Technically that would allow a person to select a number of mods that allow redistribution by third parties, bundle them up, and release them as a pack. Licenses might also include permission to modify content, which would allow a modpack creator to tweak the respective mods themselves. As far as Squad's content goes, I am less sure. Would a maker be allowed to change stock part.cfg files and redistribute them as part of a modpack with the goal of more smoothly integrating stock and modded parts, or does that infringe on Squad's copyright? I'm not talking about actually bundling art assets, sounds or code; just config files that anyone can access and modify at their leisure anyway. And, in a related question, how are these config files treated from the perspective of modifying a mod that does not grant a license to modify it? Thanks in advance for satisfying my curiosity on the matter

NASA should have no trouble maintaining its current missions. They can still maintain two Mars rovers at once, even - Opportunity is a 10 year old rover with a broken wheel, two inoperable science instruments and a robotic arm that will only move with lots of good words and gentle coaxing. Yet they still have a team assigned to it full-time, and they are still receiving great results, especially since they also have Curiosity active which can verify or contrast the findings with a different set of instruments in a different geological location. There was a period of anxiety over maintaining existing missions as NASA's budget dropped year after year; eventually they would have to decide whether to keep existing missions running and don't do anything new, or terminate existing missions early in favor of occasionally doing something new. That point hasn't been reached, however, and NASA's budget actually went up this year as they got tasked with intensifying their space launch vessel development in the wake of a series of Chinese success stories that took some politicians outside their comfort zone. As such, I wouldn't worry so much. As long as Cassini can stay operating (venerable as it is, at almost 17 years of age) and do something useful, NASA will gladly make use of it. They know they don't have or will get the budget to send a new one anytime soon. This thing is precious to them. Existing missions are indeed very cost-efficient. Almost all the money is spent up-front, and the returns only start rolling in afterwards. Which is why decades-old missions like Cassini and Opportunity are by no means a waste of money... much to the contrary, they are among the most cost-efficient things NASA did. Sure, the instruments are old and low-resolution, but having lots and lots of low-res data is better than having nothing at all. Cassini received its numerous lifetime extensions precisely because it's such a good deal, not because NASA had people sitting around with nothing to do Whether Cassini will continue living will largely be a question of whether or not NASA feels they can still learn something from the data it sends.

Judging from the poll results, it would appear that at least a small group of people seem to see the use of swear words as a sort of badge of honor... hope they will grow up some day. Because after I grew up, I learned that it is far more efficient (and satisfying) to figuratively slap your opponent in the face with a cold hard fact about why they're wrong, than to mindlessly shout obscenities that have long since lost their meaning through constant overusage. I mean really, who can formulate a proper and original insult these days? Hardly anyone. Those who readily would, after all, don't usually have the vocabulary to do so *shakes walking cane in your general direction*

Ah, I see. That makes a lot of sense, especially about the SAS thing. Thanks!

I know that KSP, coming out of a sandbox game mode, rarely ever features redundant parts. They all have some sort of niche, some use case where they are ideal. That said, there are two items that have me scratching my head: the advanced inline stabilizer, and the stack separators. The advanced inline stabilizer is a 1.25m reaction wheel part. However, there is another 1.25m reaction wheel part: the inline reaction wheel. This other part comes earlier in the tech tree, and has exactly the same stats as the advanced variant... with one difference: it is lighter. So I am asking myself: if I have two parts that are mounted in an identical fashion and perform an identical function with identical stats, except that one of the two is lighter and researched earlier than the other - why do I need the other part at all? What does the inline advanced stabilizer do that the inline reaction wheel doesn't, that justifies its existance with higher weight and more difficult access? Similarly, the stack separators. In this case, I do understand where they function differently than decouplers - they eject both sides away from them instead of just one side. That still leaves the question though, as to why I would need that? A normal decoupler is lighter, comes much earlier in the tech tree, and achieves the same end result: cutting the rocket in half. All the separator does is add another part of space debris into the mix, because it floats off on its own, and that's bad. So where is the use case for stack separators? Thanks in advance for taking the time to enlighten me!

Indeed - that's where the solid motors come in. On the space shuttle, the two SRBs supplied 83% of the lift-off thrust, with the remaining 17% being the shuttle's three RS-25 and two OMS engines. That's why I mentioned in the cons that the RS-25 needs assistance to get off the pad The SLS, too, will use SRBs to supply lift-off thrust. It's not a bad strategy, considering that these SRBs are very cheap and very powerful (as opposed to KSP, where cost does not matter and liquid engines are simply better in all cases). That doesn't change the fact though that you have some very efficient engines running alongside the SRBs. You could be using more powerful, less efficient engines that could achieve lift-off thrust on their own, making SRBs unnecessary. But then they couldn't get you anywhere near orbit. You'll need an additional stage in the middle with smaller engines, making the rocket taller and heavier. The end result probably wouldn't be much different in performance, but likely more expensive due to using liquid engines everywhere.

Yeah, the F-1 is probably the biggest liquid rocket engine ever flown. Not the biggest rocket engine period (that probably goes to the space shuttle SRBs, those things are insane... they each have almost twice the thrust of an F-1!) but damn big nevertheless. The main issue it had was that it sacrificed everything for thrust, because the Saturn V was just so darn gigantic and heavy. As a result, the F-1 ended up with really poor overall efficiency. If they're looking at a new version of it for the SLS, it's probably going to be an at least partial, if not complete rebuild. It's basically required, because the F-1 runs on kerosene, while the SLS appears to be going the liquid H2 route - it is built around a space shuttle tank, which is a LH2/LO2 carrier. Doing so allows them to use existing production lines and proven technology, which is a huge cost saver. I highly doubt they'll build an entirely different first stage variant, which would have to be designed, manufactured, tested and validated, just to hook up an engine with different fuel requirements... Unless the superheavy lifter gets a completely different main stage in the first place that doesn't build upon existing parts. As for the Merlin D-series, you really gotta respect it's impressive thrust/weight ratio. They've got pretty much everything else beat, and development is still ongoing. I'm really excited for where SpaceX will be in five to ten years from now. They may well be able to push the envelope in ways that NASA doesn't have the budget to do. As for the V-2's engine... I don't know if it even had a name. That's probably a tradition that came up only later. It wasn't a very good engine either, which is unsurprising considering it was one of the earliest liquid-fuel designs ever to see service. But yeah, it was the engine that boosted, for the first time ever, a manmade object into actual space. For that, it deserves recognition.

Hah, I've always had a feeling that the static panels were overpwoered...