swjr-swis

I have to admit, I'm not at ease with the properties of and rules governing momenta. Perhaps if I were this would be as clearly obvious as you make it sound. In particular, and to my shame, I have quite honestly no idea what the below sentence means, at all: In any case, thank you for offering another way of answering this question.

That straight line will still always be the hypotenuse of a rectangular triangle, which changes continuously as a sinusoide function. Regardless of the angle of intersection, the standing side of that triangle will change from zero to a non-zero value and back again, and thus the hypotenuse/distance will also change. it does though, at four moments (or two if they coincide - and somehow phase through each other): when they pass through the AN/DN of their respective orbits. Which is the moment of least distance between them.

Because they intersect, it's always possible to rotate your position around the planet such that one of the orbits becomes equatorial, from your perspective. It really doesn't matter if it's equatorial from the planet's perspective, the system moves the same way regardless of frame of reference. Consider the special case of both sats exactly meeting each other at the points of intersection (AN/DN). Easy to see that the distance increases and decreases as they go through their orbit, yes? The distance is the hypotenuse of a rectangular triangle with the base on the projection of orbit B on the plane of orbit A, increasing and decreasing in a sinusoide function of the angular distance from the points of intersection. Now set one of them ahead, say, 90 degrees, with the other at a point of intersection. The distance between them is still the hypothenuse of a rectangular triangle, of which the standing side shows the same sinusoide increase and decrease, hence the hypotenuse (ie the distance) also increases and decreases as a sinusoide function. In other words: it continuously changes. We don't even need to calculate exactly by how much -even though we could- it is clear that it doesn't stay the same.

I am still seeing a much too tall rocket for the task it is meant to do. As mentioned in previous threads you've started, you really need to start by significantly reducing the size of the rockets you build. You will find that simpler rockets are also, ironically, simpler to control.

This is the essential -and exquisitely simple- element that was right there in front of me, but I was failing to visualize. There isn't any way to construct two orbits around the same body that differ in inclination but keep the distance between the orbitals the same. If it can't be done for just two, it certainly can't be done for four. And the inclination difference is required to construct any three-dimensional configuration, or they'd all be in the same plane, as @OHara already mentioned. Thank you all for the kick in the pants. I have taken my brain behind the shed and thoroughly reprimanded it for failing to see that obvious point. Bad, bad brain. I wasn't even looking for a formal proof in the full sense. Just the common logic reasoning of why it was (im)possible, as @HebaruSan worded. Are you sure? That is the beauty of assuming perfect spheres and circles, after all - apply any rotation to make the starting orbit be any inclination you wish, and it would change nothing to the system as a whole. So I do think @HebaruSan is quite correct in simplifying by starting with an equatorial. Rotate that starting orbit at will, and it will essentially be the same explanation.

A way to directly pick which types of contracts we want or not to be generated would certainly be a welcome addition, and might alleviate most of the aggravation you mention. If there is any (development) room for such a thing to still appear in KSP, I'd be all for it.

Good point, and along the lines of the 'simple' reasoning I feel there must be to reach a conclusion. I'm sitting here trying to visualize for myself what spatial path the other vertices are forced to follow in the general case, but it's likely to be constrained much (or exactly) as you describe. And @OHara to be perfectly clear: I'm not dismissing that your 'of course' isn't exactly as obvious as you state. I'm just failing to envision it right now and wondering what part I am missing.

Absolutely and entirely, not maybe. You say 'of course'... but I'm missing the obviousness here. Why is it 100% certain that it only works if they are all in the same two-dimensional plane? And that is the case I illustrated in the OP. Now reason this for when it's not simply 'an axis', but its own center of mass. It will require rotations in multiple axes, possibly all three. Is there an obvious reason why it's impossible for all vertices to be describing a valid orbit due to the combination of rotations?

We are definitely not on the same page, that was indirectly my point in the previous reply. You're offering me a practical answer to a theoretical/fundamental question. Not to dismiss the validity of your assertion in its own right, but it's simply irrelevant to my question here. Coverage, whether full or all-time or in any form, and practicality, are remotely secondary considerations of why I even started this train of thought in the first place. They were left behind completely once I questioned whether it was even at all possible. Right now, the only consideration (and reason for this thread, at all) is whether it is at all a mathematical/geometrical/physical possibility. Nothing less, nothing more.

It does matter for what I'm after, although rather than practical it's really more of a 'wait a minute... is this fundamentally even possible' type of questions. The one special case I am looking for, if possible and stable, would theoretically maintain full coverage without any interruption at all. Wether it would be practical is an entirely different matter. I know of full-coverage solutions relying on eccentric orbits, in which coverage is maintained except for the short moments when the individual relays race through their periapsis. This is in fact my usual way of creating a relay network, and they don't require a great degree of accuracy, which suits me fine. They are in pretty much all cases 'good enough'. That said, it doesn't answer my question, and I'm left with this nagging suspicion that the (im)possibility of such a configuration should be fairly easy to reason. Hence my seeking input from the community.

To quote directly from your own words: Unfortunately that's what we're stuck with in stock. It's an understandable construct to provide the game with some procedural content and variety, and with some workarounds one can avoid/correct some of the biggest annoyances of it and still enjoy what it provides. Ultimately though, it really needs replacement by a fundamentally different system. I don't think we can expect that in KSP anymore; KSP2 will be different, but that will be its own game. I play pure stock, too. Personally, I have long ago decided that to keep using contracts and still enjoy a career game without undue frustrations, and regardless of any other difficulty setting, 'Decline Penalty' needs to be 0. Nonsense or futile contracts are bound to happen from time to time, and I have to be able to dismiss them without penalty or having to wait for them to time out on their own. In addition, I have no qualms about using the Contracts tab in the mod-F12 menu to clear a particularly bad set of contracts and generate new ones. This way, I keep the frustrations to a minimum without having to resort to mods.

My forum and wider internet search-fu is failing me today, and I'm hoping some of the brighter and more educated minds inhabiting this forum can help me with this query: It's easy to envision a rigid-body tetrahedron suspended in free space rotating around its own center of mass. Without resorting to any math it's easily conceivable that there are an infinite continuity of possible roll/yaw/pitch rates possible, up to the limits of the material shear strength anyway. However, this does not mean that the vertices of such a rotating tetrahedron are *individually* following a valid 'gravitational' orbit around that same center of mass. In fact one can easily envision inducing only a roll rotation around the normal of one of the faces, in which one of the vertices wouldn't even move at all, while the other three are following a circular trajectory centered well outside the body center of mass. Where it not a rigid body, such trajectories would be gravitationally impossible. This would be just one special case, there's probably an infinite number of similar, more complex rotations to be conceived. Relays in orbit are not rigidly attached to each other, so to maintain a tetrahedron configuration at all times, if it is at all possible, they'd have to individually travel a valid orbital path. For it to be a regular tetrahedron, they'd have to be circular orbits, and centered on the center of mass of the body they are all orbiting. Something tells me that it should be easy to reason whether this is physically possible or not, but my brain is not cooperating today. Nothing more vexing than an easy solution just out of reach. I've already found numerous references and papers on 'central configurations'. Almost all of them talk of either rigid structures/bodies (not applicable here), or stable configurations only in the sense that the individual objects maintain their relative configuration while collapsing towards a common point. I can't seem to find any reference that either proves (or disproves, equally acceptable) that the configuration I describe above is possible. I welcome any and all pointers/links to a relevant reference, or a direct explanation, if what I'm seeking is at all possible or not. If someone has already established a discrete set of orbits doing this in KSP, I would gladly accept that as proof too.

Start a regular career game. As soon as you load into the Space Center scene, Esc and save game. This save allows you to reload a pristine starting point, from which to create any specific 'sandbox' you wish to test in. Using the Esc and mod-F12 options, edit your game to the settings you're currently wishing to test, including cheating your required tech/facility/experience levels, science, and funds. Save again. This save allows you to return to these specific settings at any time. Test in your newly created sandbox to your hearts content. You'll hae *everything* available to test with, including all facilities, contracts, the whole shebang. An actual sandbox. When you wish to return to a clean sandbox, load one of the saves you made. When you wish to change your sandbox settings, reload the pristine save, and make new settings to save again. Repeat for as many different, instantly recallable fully functional sandbox environments as you need, all within one 'save'.

I'm not sure how I missed this one , but seeing as I was just tinkering with fast little Juno planes for another challenge, I might as well file an entry to this one too. The Juno15K II, a dual-Juno plane that races to 15km and back to a safe stop on the KSC runway in exactly 10:00. The flight profile is a low climb rate (by holding SAS Hold) off the runway in favour of acceleration, and only pitching up slightly once enough speed is built up to exchange for altitude (around 8km going Mach 1.4). Then just haul back full throttle and use the eye-popping airbraking capabilities of an opened service bay to slow down at the very last moment. Full album of this speedrun, including the flight summary: https://imgur.com/a/FwDycvZ Craft file: Juno15K II (hosted on KerbalX)

I already mentioned how in the previous message, but a few pictures might help. 0 - Place mk1 cockpit with small intake in front, nose cone behind, and AV-T1 winglets in mirror symmetry on the sides. Nothing special about that, so no pic needed. 1 - Place mk0 LF tank radially attached to the top of the nose cone, and rotate it straight/horizontal. Attach mk16 chute to the front, Juno to the back, and wheels/elevons radially to the mk0 tank. 2 - Offset the Juno back, creating a visual gap to make room for the chute. 3 - Offset the mk16 chute back into that gap in such a way that all parts touch again, making it visually 'ok' again. 4 - Offset the mk0 tank down and forward into the cone, centering it on the CoM. The tank becomes hidden from view, but it's necessary to keep the plane balanced when fuel is used, and visually it even makes sense as a plane (relatively speaking anyway - this is KSP after all). You can download the LT-Supersonic II from my KerbalX repository if you want to test its capabilities. My apologies for not publishing the craft file before. So, is no one else submitting any entries for this? We can't go any lower than those 68 science points, but we could still compete on cheapest, lightest, lowest nr of parts, highest top speed or cruise altitude, or any other number of criteria. What do you think, @ImANoob ?

Another possible source of issues: Do you have some form of anti-virus or malware software installed? Some of those intercept and redirect web traffic through a 'localhost' port to implement their protections. Some browsers get confused by this and interpret it as your web traffic being intercepted - which of course it is, but for good reasons. Check whether you still get this weird behaviour when you temporarily disable your anti-virus/malware software.

You may want to add a few more criteria, or some scoring system. It's almost trivial to do with just two Junos and the bare minimum of science points to unlock the Juno. So I decided to try do this with just a single Juno. Would a cruise speed of mach 1.6 @ 11km be an acceptable entry, for say oh, 68 science points? The Mk0 LF tank is radially attached to the nose cone with a Mk16 chute in front and the Juno behind. I then offset/rotated the tank straight/centered and forward into the nose cone, and the chute and Juno back, for flight balance reasons. The chute helps it stop on landing since the smallest/least draggy wheels unlocked with this tree don't have any brakes. The reaction wheel in the pod is strong enough to provide pitch/roll/yaw all by itself in this design, but I wanted to at least make it somewhat resemble an actual plane. The elevons add 'proper' pitch and yaw authority, while the pod takes care of roll.

Sorry to hear it. You could recreate the station as it should've been, and cheat-menu it into the orbit the corrupted one is. The game cheated/bugged you out of a perfectly good station; seems fair to cheat it back into working order.

Have you checked whether any of the backup saves still have an intact station? Should be in your saves directory, under the save name, in a folder called 'Backup'. The game only keeps a limited number of them (5, I think) and deletes the oldest as time goes on, so if it's been like that too long it won't help. But it's worth checking.

You can, actually, in many ways. If you're willing to learn and apply a trick or two, people could show you. The RA-2 can be attached radially to the top, leaving the top attachment node of the part under it free to attach something else. You can add a 'magic' top node above a Stayputnik (or RA-2) by placing them on a 1.25m fairing base, and enabling the interstage nodes. You can place a 1.25m service bay at the top with the Stayputnik and/or the RA-2 attached to the inner nodes of the bay, and then offset or rotate them Or the much simpler suggestion I made: simply move them to another place in your module. They don't *have* to be at the top. You've been getting a lot of good advice from some people with a proven track record of building (and putting to orbit) amazing things. But you'll start losing their willingness to offer help if you only keep dismissing their suggestions without even trying to apply them.

If you only see impossibilities, KSP (or space, or flight, or Life) is not the game for you. You could simply relocate the one part that appears to make it 'not possible'. Just a thought.

Ironically perhaps, that may be the most fitting solution for this thread too. There's still no clear view of the entire payload, but just inferring from the long thin and light end shown sticking out of the fairing in the one screenshot, it's got to have most of the weight on the other end. A stick grenade, stick end up. Turn it upside down, put four relatively light boosters with radial decouplers directly around it, shore it up with some strategically placed struts, and I can't imagine it having much difficulty getting to LKO even without a fairing.

Oi... I resemble that remark. Much too harsh on yourself here; not at all what I see when we cross paths on tinker projects. So you don't take anyone's word for it and need to *see* it first. That's just good sense. To be honest, after quietly monitoring this thread for a few days now, and despite all the good advice given about the rocket, I'm surprised no one has yet put the finger on the real sore spot yet. Docking a 44t and long thin module.... with 0.625m Jr (*) docking ports?? This project is dead in the water even IF that payload ever gets to orbit. That station will shake itself to bits the minute it docks. (*: you'll notice from the very sparingly offered details that none of the other bigger docking ports are available)

Vice-chairperson of the 1.3.1 Forever-as-long-as-we-need-to-wait-for-an-acceptable-alternative Club, reporting. I started out writing a few paragraphs about how and why ... but what's the point, really. No one wants to read that, and it's not gonna make a bit of difference anyway. On to 1.12.1. Maybe that'll be The One. Hah. But maybe.

Ah... unbridled optimism. How quaint. <putters on in 1.3.1>