pincushionman

You can also angle your rockets out so they fire around the asteroid. Your separator can be significantly shorter that way. This introduces cosine losses, yes, but cosine losses >> blocked exhaust.

How little does a motor need to contribute to be a "rocket"? Hate to be a naysayer here, but if only three rockets contributedto the lift and four provided spin…then you only had seven motors on your rocket.

Well, that's certainly the info I was looking for. I can justify $150 worth of graphics cards, but another $300 or more on top of that in processors and mobo (that in particular would have been a pain in the butt) is a little tough to stomach, especially if the current CPU is not that bad. I haven't really taxed it in any of my KSP builds, but in other threads where CPU power was discussed, the consensus was that the 955 is perfectly adequate.

Okay, I'm looking at upgrading my current rig with a new graphics card. I was interested in NMS and Elite: Dangerous, but canirunit indicates I need a grapics card upgrade (I believe shader model or supported DirectX version is the problem here). Unfortunately, it doesn't look to be as simple as getting a new card. I have a Geforce 9800 GTX+ card, which is a PCI Express x16 2.0 card, and got a MSI NF980-G65 mobo, which has card slots to match. As it turns out, any of the newer cards that are a significant upgrade appear to need PCI-e x16 3.0 instead. It's a 6-year old setup by now. So, basically, I didn't future-proof myself very well with regards to the motherboard. So I'll need a new one. Which means I actually need a new mobo, a new processor, and a new graphics card. Not the kind of money I wanted to spend, but it is what it is at this point. Case, HD, power supply, and RAM appear to be swappable no problem. I don't want to go top-of-the-line power for everything, especially with the graphics card, but I do want to choose a motherboard that I can reasonably expect to find graphics and CPU upgrades for in, say, 4 years. I'm using these charts from Tom's Hardware as guidance: It looks like something like a Geforce GTX 950 is the price range I'm looking for, and it looks like there are many better cards that may be upgrade options later on, in the same interface. It's the motherboard and processor I need some help with the approach. I need a decent processor (I'm thinking an Intel i5) on a newer socket. Does anyone have suggestions on the direction I should take with that in mind? EDIT: Dang it. I had yanked the tables from those pages in spoiler blocks here because TH runs hella slow for me, and I didn't want to put you through that. But it didn't work, so links instead.

Oh, that's a really good idea!

Okay, then, so we're on the same page here. And if the direction matters, then two ends that aren't perfectly in-line can cause coupling between bending and twist. Angle snap would help immensely in reducing that. That or the solution I see in drawing programs where holding shift snaps a drawn line to a cardinal direction. That might be a solution too, but that might be hard to implement in 3D.

When I proposed the "core" concept, the location of the COM thing hadn't happened yet and all airplanes (particularly small and short ones) were notoriously tail-heavy. The engine COM change did help, but as you said it created the whole "fuel-volume" issue. And I understand the realistic problems a long jet pipe would cause, but this is a matter of working around the limitations of the LEGO building model. In real life engine designers have more flexibility in the jet pipe shape and length than we do, but more importantly, airframers have a lot more flexibility in the placement and shape of fuel tanks than we do, too. And a system like this would help keep the number of engine choices manageable, too. I'd rather have a few primary engine cores that get "featured up" with effectors than have to search through a long list of engines that are quite similar to get the same flexibility. There could always be a limitation in the effectors that they must be within X meters of the center of a core, particularly for "nozzle" effectors. But now we're getting more off-topic.

I have been having trouble with that with my current design (trying to strut from one 1.25m tank to another around a TR-18A), but that's not necessarily what I'm worrying about. What I'm encountering is the floppy rocket is twisting under a yaw, which is real bad. In real life, these two configurations are going to behave differently under vertical and side loads: That is, even under just the weight of the upper parts, the one on the right (in real life) will cause a counterclockwise twist when viewed from the top. Not much, and maybe not visible, but in real life things are way, way stiffer than they are in KSP. In KSP, I'm not sure how the extra stiffness of struts is implemented (frankly, I'm not familiar with how stiffness is handled at all). If it's an additional stiffness added between between the centers of the two parts, then it's just visual. But it the locations of the strut ends define the load path, then it does make a difference, and small deviations from the intended direction will have noticeable coupling effects given KSP's unrealistically floppy joints. We're already aware of the differential stiffness bug that causes aircraft to roll slightly when you apply pitch, and contributes to the aircraft-twisting-and-yawing-off-the-runway problem. I've done a little research, and it does seem that the exact placement of the struts along a single part does change the relative stiffness - it involved hanging a pod on the end of a long tank, connected to another tank via a radial attachment point: The deflection was measured by looking at the Pitch value of the right-hand pod in KER. Various strut positions produced different results. But the deflections are so small I'm not sure they're not just random fluctuations. I'd need to come up with a way to up the "gain" on the measurements and isolate them from the entire structure being tilted slightly. What I really need is a reliable way to measure the difference between the orange tank axis and the white tank axis, which I'm not sure we have a tool for. And a lot more tests to determine a trend or not. This is all somewhat unrelated to the circumferential snap problem, since it wouldn't help this setup and this setup isn't as sensitive to twist. But if the placement effect is real, then it's likely real in all directions. I'm willing to take the drag statement at face value, that sounds like the way it would have been done.

Title says it all. I spend a great deal of effort trying to get my struts to line up with one another. I don't know if it has any game mechanics changes for sure, but if the direction of the strut has any bearing on the direction of the force, or if it can change drag, it would be very useful to not have to eyeball the placement of the second end. It would sure make it easier to make it look better, at least. Especially since there is no readily available reference tools like moveable datum planes. I have done some very cursory experiments, and the indication is that the exact placement of the strut does have some bearing on the stiffness between the attached parts. But not detailed enough to know for sure.

…except the parts they're returning don't contribute to space debris since they're never in orbit. Who/where is that quote from? Link?

Do keep in mind the units system you're working in. The "taxi" speed you're describing is 156 mph. If that's not enough speed to generatee lift, you may also need more wing. Canards might be helpful.

Mass distribition. If I have a separate core, I can tune the COM of my plane much more easily.

The problem I have with the SciJr (and the goo cans, let's be honest) is their placement in the tech tree. They're the biggest, bulkiest experiments we have, yet we have to use them while we're fighting all the other part limitations at the beginning. The Jr is lightweight yet bulky, resulting in difficult-to-return or difficult-to-land-and-collect science because of the craft-flipping challenge and low crash tolerance. The goo cans, while smaller than they used to be, are the only physicsful radial science part and therefore can almost never be flown alone until you get bays, usually wasting mass and part count. And neither are reuseable. The other experiments are gotten late enough in the tree we can darn near guarantee that we already have the parts necessary to remove any challenge in their use. They're lightweight, physicsless, can be re-used with impunity, and we have bays and heatshields. So, in the late game, there's little value in fighting those limitations and they get left behind. In my opinion, we should start with low-science, easy, place-anywhere thermometers and barometers, and the goo cans and Jrs should be further down where they can offer significant rewards for putting up with the design limitations they demand.

I wonder if there is a mod to alarm you for upcoming close apoproaches (given a user-defined distance and closing speed), for those of you who are worried?

You also need to get comfortable with a type of maneuver known as a "zoom climb." This is where you go high and fast on jet power, and pull up sharply to convert forward speed into vertical speed, letting you glide above the flameout altitude (and the magic 23km cutoff) on a ballistic trajectory. This is, of course, easier with some engines than with others. There's a lot of meters between 15k and…let's face it, something way higher than 23. You also might consider a rocket assist to hump you over the critical altitude. I'm currently working on a design that uses thuds and wheesleys to pop up high enough to do high-altitude surveys, which is conceptually pretty similar to what you're trying to do, so I thought I'd mention it.

Doesn't mean he's their only deity.

Yes, and it's almost essential for ion use.

We had a discussion some time ago about separate "core" and "nozzle" parts, in the context of jet engines. I made the point that you could then have piston or electric "cores" as well as gas turbines, and that could drive different effectors (nozzles) like airscrews, generators, or wheels driven by these cores via a resource like "enginePower" or "compressedAir" or something like that. I'm glad the discusion has come back, not least because I was never savvy enough to even begin to mod it. As for limiting the various effectors by whether they're in water or not, the AtmosphereCurve of current jet engines is ultimately about pressure, no? Could that be used to enforce proper behavior?

Remember that "best/lowest delta-V" windows may be few and far between, but "adequate" windows for most targets should come around at least once per Kerbin year.

I notice almost all of these games are from the past few years. What about the true classics? Staying power, especially after "the next best thing" has come and gone, is the measure of a great game, in my opinion.

The map also assumes you've got a favorable transfer window and an efficient intercept.

This is a hell of a necro, but I'm about to pull the trigger and buy a Thrustmaster T-Flight HOTAS - but the question right now is whether the older "X" or the newer "4" is the best option. Here's what I'm finding, I think: The HOTAS X supports multiple programs, so I could have a mode where the main stick axes handle pitch and yaw, rather than pitch and roll (say, "lander mode" or "rocket mode", as opposed to "plane mode"). Several posters on this forum have commented that such a feature would be very useful, and I'm inclined to agree. Is this feature gone from the HOTAS 4? The HOTAS X is a true 5-axis stick, with the throttle rocker separate from the twist grip. The documentation for the HOTAS 4 seems to say they are not separate, just two different ways to apply yaw? (this is the most important question, if they aren't separate then the "X" is definitely the answer) The HOTAS 4 has better sensors and a smaller dead zone? The HOTAS 4 has up-gradeable firmware. How much of an issue is this, really? The HOTAS 4 can daisy-chain a new pedals unit. Does anyone have experience with the HOTAS 4 that could chime in about any of these details?

Right now there is no penalty for time warping, other than the opportunity cost of missed windows.

Some birds are already capable, with effort, to speak and understand words and very simple sentences. They rely on their tongues like ventriloquists do, since they have no lips. Parrots and crows are, of course, the most well-known examples. Crows and other large corvids are capable of simple tool use (as in, use found objects to help accomplish tasks). So you don't necessarily need a whole lot more for your super-bird species than bigger brains (for more memory and thinking power), and a better means of manipulating objects. They're kind of on their way already. Though, most of all, there needs to be an evolutionary advantage to communicating more complex information and have complex coordination as a group. Our own capability for language grew from such a need, and it advanced society, which drove more complex language…in a self-reinforcing cycle.

I have read that a fan asked Tolkien that very thing, and he said something like "Well, I...um...hrm. Didn't think of that possibility." Later on he concluded that the Mordor forces, which did have flying mounts, were savvy enough to keep a watch on the eagles as a matter of course, and an eagle would be easy to spot, especially if OH MY GOD IT HAS THE RING TOO