qoonpooka

So, I'm building my first orbital tug for space station operations as I plan a rather robust local tourism infrastructure consisting of modular components so that passenger modules can be docked to vehicles appropriate to their itineraries. (This same infrastructure will include scientific and other payloads as well, but tourists seem to have enough variety in their needs that designing for that use-case will be a goodly ways towards what I need.) The problem is thus: I can't seem to make the clampotron Jr. lock to directly above the center of mass. Given that this tug will be attaching to things much larger than it, an offset CoM from my CoT will be problematic in an environment where high degrees of precision are called for. Am I missing something obvious? Other parts, like parachutes, snap just fine. I'm having similar issues with the command module's roof. Edit: If I turn the clamp-o-tron upside down (such that it generates the 'uselessness' error) it will snap just fine. Of course, then it's upside down and can't be used.

So, I'm a PhD student in Law and Public Policy. This is decidedly not my field, I just really enjoy building and flying rockets. But it is a thing of beauty to watch y'all discuss this stuff and I'm learning a tremendous amount from it. So thank you all for having this discussion in front of me. That is all.

There is a bold-gradient on the orbit now. The boldest part represents the 'head' of the thing, if you will, and the faintest part is the 'tail.' Orbits chase their tails. So the orbit is moving towards the faintest part of the orbit, from the boldest part.

I'm curious what you did as I seem to be having the same problem. KER is clearly there, because the parts are there, but when I install the KER part to the rocket, I don't get the KER window. Is there a troubleshooting doc somewhere? I've searched around but can't find it. I now seem to have the KER window back after re-installing KER and NOT allowing AVC to check for updates.

I just had a decoupler fail to separate the stages, and then rattle off the rocket like a ringtoss in reverse. When I went back in I discovered that the fuel tank under the decoupler had somehow attached... not to the decoupler, but to the heatshield directly above the decoupler. Not even sure how that worked, but apparently you can make that happen.

Is that because ore intensity is biome-wide? or because it gives you all of the information for the whole biome in one go? If neither, then that suggests that if you pick the wrong spot to analyze, you just lost whatever potential deposit that biome might've had?

Awesome, thanks!

So, I have this Clamp-o-tron I'd like to have aligned with the stack. (Actually I have two, a Jr. atop the capsule, and a standard on the bottom of the same lander. The top one, so I can attach tourist capsules for delivery to their destos, and the bottom one so I can park it on my space station when not in use.) Thing is, every time I build something to this standard I spend 10-15 minutes fiddling with the positioning of the damned things because they won't snap to the stack like parts usually do. Because of this, I can be nearly certain that I'm moving my CoM away from my CoT... No problem for mun and minmus hops, I'm sure, but it's going to no doubt cause issues for my Duna-bound tourists. halp?

does this mean that (to a point, obviously) higher TWR means you waste less fuel?

Thank you for this. I think this is going to be one of those things I just don't understand and have to memorize, rote. Every time someone has tried to explain this, it sounds to me like they're contradicting themselves or other things taken as read. I'ma tag this 'Answered' and trust that the discussion is useful for folks.

Geometry involves static shapes. If I was expending fuel for distance traveled, instead of for velocity, this would make sense. But all the while I'm changing my velocity, and gravity is working to do the same. So if I burn diagonally, my thrust is less effective at canceling my horizontal motion, AND less effective at canceling my vertical motion. To me this seems like it should work like cornering in racing: At any given moment I can only have access to 100% of my traction. Some of that I spend turning, some of that I spend braking, but the moment I ask my tires for more than 100%, I crash. Some of my thrust I spend horizontally, some I spend vertically, but when I thrust diagonally against my retrograde marker, there is nothing in geometry that says that I should somehow be able to apply more than 100% of my thrust - just that I should be able to travel a shorter total distance (that's the hypotenuse). But burning in one direction to cancel out my horizontal, and then burning the vertical off involves traveling more total distance, and involves taking more time, but you're coasting for part of that, and falling while you burn out your horizontal. That extra velocity is velocity that /would have/ been canceled out by the diagonal thrust, I'm just waiting until the horizontal element is gone before I set about burning that off. And that's the part I don't understand. Why is that? Why are 'speed I am traveling' and 'distance I am traveling' necessarily the same? Why can't I take more time, travel more distance, but because there's no drag, spend the same amount of fuel overall? It's not like part of a triangle is being constantly accelerated away from the rest of the triangle so saying things like "It's trigonometry" isn't actually helpful to me in this instance. I learned trig on a chalkboard, not in a blender or tilt-o-whirl... at least not within my frame of reference.

One thing I want to have cleared up before I go check the "Answered" box. As an aside, thank you guys for this great discussion it's been very helpful! Given This: Why should this be true? I understand why it should be true when driving on the ground, where all motion is subject to friction losses and whatever else. But in vacuum, it seems to me like an object in orbit has both the horizontal velocity and vertical acceleration to contend with. But, assuming I have enough TWR, why should it matter when I cancel out each component? KerikBalm's example of dropping from 100km is extreme but useful here: I get that the longer I spend in gravity's grasp the more velocity I'll need to counter but when I lower my orbit it looks like all I do is trade some of that vertical velocity for a higher horizontal component as a result of my higher orbital speed. Does the Oberth effect not help make up the difference? My higher velocity when I begin my landing burn should make that burn more efficient as I begin and by then end it should match up? Why does 400 + 300 = 500 in KerikBalm's example? I wonder if the actual math is more like 400 + 300 = 700m/sec suicide burn, but stop and drop is more like 400 + 300 = 900?

So I've heard two (three if you count atmospheric methods but let's assume no atmo for now) methods here so far that are interesting: Method A: Chase the retrograde marker all the way down (suicide burn), under thrust the whole way, looking to attain 0m/sec just as your gear hits the dirt. Method B: De-orbit from gonzo-low Periapsis first, then over-burn on your way to the ground. I've been using Method C: When you're near where you want to land, burn laterally to cancel out your horizontal velocity and then regulate your descent based on available TWR. This sounds rather like it splits the difference between these two, is it more or less efficient than either, do we think?

I saw it mentioned in another thread that landing is super inefficient and can consume upwards of 2-3x the dV given on a dV map. That seems like it makes dV maps basically useless. How do we trim as much of that manuvering loss as possible while still having a reasonable margin for safety and surprise terrain issues?

I notice, in the video, that Manley can bring up a menu to interact with the placement of a part. How does he do that? I've placed the radial attachment points just as he has, but possibly a bit high. Sinking them into the wing may fix this, but I don't know how to do that.

Been following Manley's VTOL build but I can't get the vertical engines to attach to the damned radial attachment point. I'm here: And this is where I've gotten to in my SPH: No matter what I do, it adamantly refuses to let the engine attach. Is there a key I'm missing?

Okay, this is as much to post this screencap as anything but it got me thinking: I understand the basics of gravity assists, or I thought I did. So I got the contract for the Ultimate Kerbin 3 Challenge: Flyby Mun, Flyby Minmus, Suborbital on Kerbin, that order, one ship. So I grabbed my prebuilt Minmus Lander Mk I, a 1.25m build with a Terrier that lasts me about 980 dV after orbit and figured I'd grav-assist off the Mun since I have dV for days. So I set up my flyby and try tinkering with the maneuver node to do a powered grav assist since I know I'm just hi-5ing Mun as I go by on my way to minmus. As i do this, I notice that if I burn RETROGRADE at the Mun periapsis (behind the Mun) I loiter in the Mun's grav well longer and the exit orbit looked higher. higher = closer to my destination of minmus so I figured this was correct... I had though, however, going in, that it was the other way around, that I basically peri-kick off the Mun and get higher that way? Anyway, while fiddling with the burn to come out closer to proper incline I scored a minmus encounter! SWEET! Then I looked at the Mun and saw my trajectory and... that just looks FUNKY... is this about right for grav assists with plane changes? Is there a consistent way to optimize these kinds of maneuvers? Or is simply mucking around with it the way to go? EDIT: As I drew nearer the Mun, the orbits began to flicker and I lost my mun encounter... o.O What's going on?

Joint reinforcement did VERY nicely. Now it only flips out if I oversteer during the gravity turn. I was mistaken about the TWR. Those were after I chopped the station payload in half, and decided to send the 2nd half of the station up as an add-on. Anyway, Joint Reinforcement seems to have solved the slinkyness. Here's photos for further commentary, though. (That probe payload worked like a dream, it's parked on Minmus with 2.8k dV to spare for future temperature scan missions.)

I tried struts, but they all seem to clip inside the tank walls and it's a VERY vertical stack. When I get home I'll try getting a picture, but it's so tall it exceeds the viewing area.

I will give that a check-out just on principle. This was my first 2.5m project, but the 1.25m rockets I had started to get an unnerving amount of flex to them too.

The problem was delta-v. I wound up cutting the station in half, and plan to launch the second half once I finish the probe's mission. It was still floppy but I wrestled it into orbit with 200m/sec delta-v left over after I parked the main station body. It sounds like this is a problem without much solution, but I'll mess with the lower TWR launch profiles. The boosters are released before I go supersonic and the next stage can be throttled, but I can tweak it a bit.

Answering the questions: Launch TWR is 2.85, main lift stage is 2.51, orbit stage is 1.57, transit stage is 0.7. Reaction wheels exist, but have been disabled. RCS is equipped, but disabled. Rocket has fins near the tail. Flying without SAS gives me a stable ascent, but the natural gravity turn (probe core riding on the side of the rocket, ultimately destined to be the station's maneuvering pilot) is too steep. The probe cores are pretty far apart, one riding 2/3rds of the way up the station stack, and the other as part of the terminal probe payload. I'd fly without the probe core on the stationstack, but I'm worried the decoupling will knock the station out of minmus orbit - I plan to re-use the station as a refueling outpost for outbound interplanetary voyages. It sounds like there's no way (short of unlocking better fuel tanks to reduce the joint count in the stack) to get this rocket off the ground. Disabling gimballing leaves me with a rocket that can't really fly into the gravity turn and has to circularlize nearly a vertical ascent.

The whipping around begins immediately after launch, before I even touch the controls. The only thing I can think of is that I do have two probe cores (OKTOs) and I turn SAS on by habit. Maybe they're engaged in tug-of-war? But it can't be my grav turn because it happens even when I don't grav turn. (The slightest touch of the controls will, however, make it much worse.)

Rocket consists of 3xX200-32s atop a Mainsail, stack decoupler, Poodle with additional X200-32, another decoupler, station consisting of 3 crew cans and one mobile lab + attachments (PV, docking clamp, etc) separator and then 2t fairing + probe package. Mission is a minmus orbital station + probe does flybys of some temperature sites then lands on minmus and sends back data. Shortly after launch the thing whips around like a slinky before finally whipping itself into a tumble. No apparent cause, no amount of fins seems able to stabilize it. Rocket length is 38.2m, total vehicle weight is 269t. Struts don't seem to help, either. FIXED: Joint Reinforcement seems basically necessary once you step up to 2.5m parts. With that mod, this thing flies well. Pics on 2nd page.

That biecliptic transfer is super counterintuitive, but yay for Oberth Effect. Is there a point (other than SOI boundary) beyond which you don't get much fuel savings anymore? Is there a minimum eccentricity I should look for?