ajburges

The question of which approach to follow depends on which losses bother you more. Radial components are components not increasing your orbital energy. Thankfully trig is non-linear so a 10° angle only saps 0.5% of your prograde component when integrated. Note: 30° robs 4.5% of your prograde component when integrated! Also note: these losses will worsen as eccentricity increases. A pure prograde burn will maximise the work of your dV, but it's harder to balance the burn correctly and control AoPe. Fixed heading burns tend to be slightly easier to execute while maintaining AoPe so can be more useful for precision maneuvers.

Does anyone know how distance is measured for waypoint activation for survey contracts? Config files suggest 15000 (m) but it lacks context. Is it a any point above any point within a 15000 m radius on the surface (a cone)? Or is it any point 15000 m from a line above the coordinates (a cylinder)? I ask because I am trying to calculate polar orbits that would perform ideal visitations without re-tasking.

OHara, thanks for that simple mechanism I got lost in the weeds and overlooked that simple division would give me the orbits then it was simply a matter of choosing a coprime number of revolutions to pair with it. I still have some questions about waypoint activation, but I'll ask that in seperate thread.

Didn't mention it in post but the title did specify stock. The useful instruments are the Kerb Net/Anomaly detector (FoV limited), experiments for survey contracts (are they lat/long limited or horizontal distance limited), and the resource scanner (practically not limited). Rubber ducking it out, I suppose the best sock polar orbit is the one (per scientific region) with the lowest time to come within survey distance of all equatorial points. Unfortunately, this varies greatly depending on the frequency of your orbital harmonics.

To clarify on finding an approximate resonance: I would like a better way to find orbital periods that follow a ground track that advances by x degrees every planetary revolution and/or by y degrees when a*x (mod 360) < x. I already have Kepler's law incorporated into my solver, but I can come up with a good way to solve given x and/or y.

Just wait till you have a lander with TWR low enough the gravity losses demand more dV than the map suggests! Edit: Why are you doing a Hohmann Transfer to synchronous orbit? Just launch to there and you use even less dV!

Everyone has sound advice, but I want to draw your attention to the root of you problem: The maneuver node system assumes instantaneous velocity changes. When burns are short (a fraction of an orbital period) the difference between your node and your burn is negligible, but longer burns will compound error. Long burn craft need integration of velocity over the course of the burn. That's a much more complicated problem to solve and KSP does not have tools to help solve it.

Discovered that the old thread of ideal scansat orbits got consumed by a forum change at some point so I'm working on a Google Sheet to help derive polar orbits with useful resonances with revolution period. I have calculators that can solve for altitude and resonance while calculating surveyed arc for given FoV, but the utility is limited beyond checking solutions. A few questions come up: What is the proximity toggle for orbital survey waypoints? In stock I think the most useful resonance orbit would minimize the time to visit all possible waypoints for contracts. Is there a better way to find an orbit of particular approximate resonance than brute force? The presence of non-discrete modulo arithmetic is a barrier I don't know a way to reverse.

Just making sure to voice support for doing it right over doing it fast. Be careful to manage communication to avoid building a hype train that needs too many boosters/struts to get off the pad! A lot of people would be thrilled with a refresh. Don't prime us for disappointment and I'm sure your work will be grand and well received. Avoid the trap of more time = more features, just say when you got delayed working out bugs or other back end issues. There's enough people on these forums familiar with code projects to defend you if the more naive make a fuss.

Are you looking for an easy or efficient transfer? Burning to get deeper into Duna's gravity well is probably not efficient. The Oberth gains would need to outweigh the losses from going the wrong way. Given that Kebin transfer from Duna elliptical is ~380 dV there isn't much room there for Oberth savings. Easy has already been covered: Leave Ike orbit for greater Duna orbit Transfer to Kerbin Enter Minmus orbit Efficient relies on not spending dV without getting useful potential/kinetic energy Calculate the necessary dV to transfer to Kerbin from Ike orbit (dV_duna_escape) Calculate the dV burn necessary to have approximately dV_duna_escape on Ike -> Duna SoI change Time Ike exit burn such that Ike is approximately in the correct position for transfer burn (a few hours early so SoI change occurs at correct phase) and you burn on the correct trajectory for ejection. If you track at least 3 SoI changes with trajectory planning, you should get transitions that lead to a Hohmann like transfer from Duna to Kerbin and be near rendezvous. You can skip to here with node planning, but mentioning the previous steps should help you visualize what you are doing. Halfway through the transfer, use fine trajectory adjustments to get a Munar intercept for an assist to capture into an elliptical kerbin orbit. Remember prograde, reduces energy, retrograde adds energy (or vice versa check against trajectory). You can also aerocapture, but a Munar assist capture will result in a higher Pe. Higher Pe is more energy in our orbit, The more energy in you orbit, the less dV you need for Minmus capture! normal for plane adjustment prograde + radial for pe height and time (Mun location) adjustments Munnar assist should help with Kerbin capture, adjust orbit for Minmus intercept.

Disclaimer: I was comparing values between 1.7.1 and 1.11.0. It is possible there was a change pre 1.11.0 that I missed. Ran both versions and compared parts in SPH with vessel mass readout.

Looks like they did change cabin masses while adding occupant mass. The one arm became 1 ton lighter fully loaded while the lab arm actually got a few dozen kg more massive fully loaded. Removing kerbals would increase the difference further. Looks like the root cause was the part rebalancing completely broke the station, but it did expose that ballast (or careful berthing management) would be needed for future artificial gravity projects.

Good thought on camera focus. I forgot about it because I use camera aiming to access the rotors easier on the prototypes. Did the crew cabin mass get rebalanced as well? The asymmetric arms were carefully balanced in 1.7.1, but one holds over 3x as many kerbals. if empty mass was adjusted, that would explain how they got so out of whack. Regardless, the variable mass of cabin parts seems to necessitate a ballast system these days.

Prepped an album with the latest contra rotating mechanism concept. Frustratingly, this is the the tamest one so far so it's less illustrative. I was able to eventually trim the oscillations out by redistributing ore mass as ballast (as intended for this design). With 1.11 adding Kerbal Mass, I think redistributable ballast is now the way to go. I also have a single ring countered by a rotating ore tank in-line, but the significant difference in moments of inertia further complicate things as spin-up is unbalanced. Also have no idea how to approximate the balancing of the opposite forces of the ring mass vs the counterweight.

Having issues were my rotor pieces on stations. The counter-rotating arms are producing torque on the rest of the station that is misaligned with the center of rotation. Is there any way to eliminate this? Could this be caused by slight mass variations between arms? Note this isn't from uncanceled torque. I have visually verified the arms are rotating WRT the station in opposite directions. Concepts that worked in 1.7.1 without this issue get rotation around 1 RPM. Net torque is not consistent and varies. I would say Kraken like, but the forces are tame and disappear when rotors are stopped. This uncontrolled attitude change makes it impractical for a station. Furthermore SAS refuses to correct for it (I have a control point orthogonal to the spin axis I intended to point in the normal heading). Took a break around 1.7.1 when I got sidetracked and stagnated designing BG craft. Came back recently. I've been toying with designs waiting for mods to update and one of the items in design is concept artificial gravity habs for stations.