FloppyRocket

Is there an energy advantage in going to Jool on the way back to Kerbin? I understand it has a big gravity well, but if I go there, I have to get out again. I don't really have any experience with gravity assists as a way of losing energy.

Or, you could launch the 2nd and 3rd satellites into slightly lower orbits than keostationary, wait until each drifts into the correct position, and then circularize.

Progress report. Currently orbiting Dres after completing landing and ascent. Struggling mightily to plan a Kerbin return trajectory. Cannot get the alexmoon launch window planner to give predictions that I can enter as maneuver nodes and have the time marks match. Burning a lot of time trying to figure out how to get back home, and wondering if I have enough delta-v.

See TriggerAu's post on this thread from Dec. 30, 2018.

Could not get enough performance out of Mainsails. Currently I'm set up with five Twin-Boars, plus four Kickbacks. Heavy-lift rocket design is not my long suit.

@GoatRider, @Geonovast, thanks for the tip. Lots of goodies hiding in "advanced tweakables", I've never been in there.

Near-novice question when it comes to cross-feed: How does one "set the priority of each tank"? All I see is an enable/disable option.

To get the Mainsail, I have to buy-up the previous Tech Tree level - then I have a docking port, and it means I can't simply use my Minmus lander - because I also have to launch an orbiter, and that increases the launch payload, and there seems to be very little from my Minmum mission design that I can reuse. The rules for this challenge are very cleverly crafted. I spontaneously ended up with a ship that looks eerily similar to @VQkr's rocket - though my lander is docked on top of the crew pod and is launched under a fairing.

Today's observation (without having read @VQkr 's post which probably makes mine seem stupid...) Designing a ship with orbiter/lander and return from Dres is much harder work than I expected. But, I didn't really know what I was getting into when I started this challenge. I'm learning a lot, though.

Minpollo accomplished, using ship Minpollo-Aa. Re-built after reverting to fix my previously-reported accidental acquisition of docking port technology. Tech tree (w/o the problematic Miniaturization node) : Ship Minpollo-Aa (never played with the Skipper engine before) Landed - looking very minty The mission itself ran pretty smoothly - didn't bounce the landing, used EVA during polar orbits of Minmus and Kerbin to corral some additional science. Science net for this mission: 885.9 points. Probably going for Drespollo next, but I'm going to need a bigger rocket.

@5thHorseman, In the Joolpollo mission, it says "Do a Jool 5". Could you provide a little more detail, or a link? I'm not familiar with it. Does "Jool 5" also explain why it says "you need an orbiter around every world you land on"? Does that mean you need a separate orbiter for each world? Or just that one has to be left in orbit around each world during the landing (as the challenge already stipulates once you have docking ports unlocked). I'm wondering if there is some non-obvious requirement hiding in the text. The wording is a tiny bit unclear. Thanks!

Egad...or Wow!... I'm not sure which is more appropriate.

Well, drats. Halfway through my first try at Minpollo, a thought occurred that I might have accidentally unlocked a docking port in Level 5 (via the Miniaturization node). I didn't think about checking for that before I launched Minpollo-A, because frankly I've never used a docking port before, and I really intended to make only small changes to Munpollo-C and re-use the core design for Minpollo-A. Per the challenge rules, I have to use an orbiter/lander combination after I have a docking port available. Mostly my KSP time has been spent in Career mode churning out LKO rescue contracts via writing kOS autopilot scripts. All my rescue contracts have involved an EVA between ships - docking ports are a novelty. So, after I complete the in-progress Minmus landing just for the personal experience (because I've never been farther than the Mun before), I'll have to revert and not purchase the "Miniaturization" node, and then re-build and launch Minpollo-A again. I'll have to figure out a strategy for the later missions where I might need items farther up the tech tree, which then will force use of the the orbiter/lander combination.

Completed Munpollo mission. Ship Munpollo-C got the job done with about 260 m/s delta-v to spare. Only a couple of reverts needed. Launch image here: As landed image here: On recovery from Kerbin grasslands, the net science for the mission was 760.4. Having Jeb do a one-orbit EVA around the Mun before landing covered a lot of biomes. In other news, the end of the mission takes a long time when you do two orbits of aerobraking, and run out of battery power. 65 units of ablator left when jettisoned.

Meanwhile, back FloppyRocket-land, there will be brief delay while the Munpollo ship is re-designed into something that stands a chance of making the whole round-trip. Munpollo-A and Munpollo-B have been retired. - Munpollo-A vanished in a cloud of reversion-dust when it failed to escape Mun's steely clutches. - Munpollo-B made only one test launch before being retired to the land of shame. I blame these design errors on uncontrolled weight-gain by the capsule occupant. Jeb seems to have put on an unexpected 0.9 tons between design and launch.

Initial challenge documentation images: Kerpollo mission ship: Tech tree during Kerpollo mission: Science cart used to farm more Science to extend the Tech Tree for the Munpollo mission: Tech tree before starting to build the Munpollo ship. I had just enough Science to complete Level 3 and then get the Electrics group, since solar panels are handy (Update: Had to go farm some more science in order to buy the landing struts in the middle of Level 4). And, my game settings:

Ok, thanks for the reply. I'll post some images shortly. For some reason I'm having trouble adjusting my notification settings. It seems I never get email notices for replies even when I'm following a Forum thread.

Greetings! Just started the challenge this evening. I'm running Normal difficulty mode. Mods: only one - ForScience. Pretty handy, I've never used it before. Progress: Farmed some science around KSC, cleared the first two tech tree levels. Built, launched (and re-launched a couple of times), and completed Kerpollo. Blew up the goo canisters on reentry, and though I aimed for a desert landing, I mis-judged the Pe marker and landed long and in the bay. Went swimming. Now have about 160 science to proceed into the third tech tree level. Any other documentation needed? I don't do videos, sorry.

Thanks!

The situation is something like this? (please comment)

Thanks for the tip about what vector the POSITIONAT() function returns. I'll give it a try. Yes, I've struggled with VECDRAW() also.

kOS "POSITIONAT()" problems: I'm having trouble making the kOS positionAt() function work the way I hope it can. The kOS documentation on vectors, reference frames, etc. are fairly baffling, so I've gotten myself into a very confused state by trying a lot of different things and making a lot of plots that are all starting to make no sense at all. I'd appreciate any pointers. The scenario: (Note: I know there is likely an easier way to do this. I'm puzzling over how this particular function works. Also note that I'm also not using maneuver nodes). I'm working on a kOS script to automatically match the inclination of a Target's orbit. My ship is in a low-altitude inclined elliptical orbit. I've selected a Target, which is in a much larger elliptical orbit, with a totally different inclination, and whose Ap and Pe are both higher than my ship's orbit. When I select the target, the AN and DN markers appear on the Map view. The end goal of the script is to automatically point the ship in the correct direction at the correct time to burn by the correct amount to match the inclinations. Based on some helpful posts here on this Forum, I start by computing some cross-products to find the two vectors that are normal to my ship's orbital plane and to the the target's plane. I then compute the cross product of those two vectors, and the resulting vector points along the AN/DN (named "andn" in my code). That seems to work fine. To verify that it works, I have a script that computes... local angle_error is vang(ship:body:position, AnDn). ...and print this value in the console as my ship orbits. The value ranges from 0 to 180, and is at 0 exactly when my ship marker is over the DN marker, and is at 180 when my ship is over the AN marker, then trends toward 0 as the DN marker approaches again. The value of the AnDn vector is stable for a given pair of orbits.. So I think the AnDn vector is correct, and I can measure the difference between my current position vector and the AnDn vector, and all that seems very tidy. I'd like to warp ahead to just before my ship reaches the nearest of AN or DN. So I'm trying to use positionAt() to search into the future to find the time when angle_error reaches either 0 or 180. The problem: The values I get for angle_error using my ship's future position vector are not consistent with the values I get for angle_error in real time. For debugging purposes, I've got a loop that iterates through one ship's orbit, computes the future ship vector and angle_error, and logs the utime and angle_error to a CSV file. // survey the predicted angle over one orbit of time in 1/100 increments local dt is 0. local tinc is ship:orbit:period / 100. local tnow is time:seconds. until dt > ship:orbit:period { local tim is tnow + dt. local an is angleAt(tim). log dt + "," + an to "search_data.csv". set dt to (dt + tinc). } // return the future angle to the ANDN vector at a time 't' // use this for making predictions with "positionAt()" // note; andn is global vector of the An/Dn markers function angleAt { parameter t. local ang is vang(positionAt(ship, t), andn). return ang. } When I run this script, let's say that the real-time angle_error is maybe 170 degrees, but the first value for the future predictions is around 55, and over the orbit period it increases to 180 and then decreases to around 125. It does not vary through a complete cycle of values over an orbit. So there are two issues I haven't been able to resolve: - Why is the initial angle_error prediction so badly incorrect? - Why doesn't the predicted angle_error vary from its starting point up to 180, down to 0, and back to its starting value as I predict the future through one full orbit? I've been wresting for a couple of days and am making no further progress. Hopefully someone on the Forums will recognize the symptoms and give me a head-slap. One thing I tried which does not work is changing the angleAt() function to use (positionAt(ship:body), andn). That gives results which vary for the first few test examples and then asymptotes to a stable value for the rest of the orbit period. I would expect that to not work, because using the position of BODY in its orbit is not correct, but even given that, I don't understand why the value it returns has an asymptote behavior. It seems like examples of POSITIONAT() that I've seen online tend to be used with adjusting a maneuver node. Is POSITIONAT() somehow tied to using maneuver nodes? I'll post this before my internet connection burps and I lose it. I can post some images of the plots if it would be helpful. Thanks for any assistance.

The values in the delta-v charts can be derived from the "vis-viva" equation, which is also the basis of the "Hohmann transfer" equations for orbit changes. https://en.wikipedia.org/wiki/Vis-viva_equation The vis-viva equation gives the current velocity at any point in an elliptical orbit, based on the current altitude. I can't insert an image from this computer, but the equation is v = sqrt( GM * (2/r - 1/a)), where ... GM is the gravity constant for the body you're currently orbiting 'r' is the current altitude (plus the planet's radius) 'a' is the semi-major axis of the orbit (which can be computed as the average of the Ap and Pe values, plus the planet radius). This works for all elliptical orbit changes. The initial delta-v for getting into orbit is a given value of 3500 m/s, based on experience. The presence of the atmosphere prevents vis-viva from being used for the initial orbit. So flying out from Kerbin you can work out the delta-v changes by knowing what orbit you're currently in (that will be the Pe), and what altitude you're aiming for (that will be the new Ap). Example: I'm in a circular low-Kerbin orbit at 80 km, so Ap = Pe = 80 km. Vis-viva says my speed is 2,279 m/s. (Note that the launch rule-of-thumb says I used 3,500 m/s to get there). If I want to reach the edge of the Mun's SOI, that would be a new Ap of (Mun's orbit - Mun's SOI size) = (12M meters - 2.43M meters) = 9.57M meters. Update the 'a' value using this new Ap value. Use the current Pe (80 kM) to compute the current altitude. Plug it into vis-viva, and the speed I need to be going right now to reach that Ap is 3,120 m/s. Since I'm currently going 2,279 m/s, I need to burn prograde by the difference (about 840 m/s). The delta-v charts typically say that a Mun intercept costs 860 m/s. So that's a good estimate. When computing delta-v values, you need to use the GM value for that body. So when in the Mun SOI, you use a different GM than when orbiting Kerbin, etc. Note that the vis-viva equation doesn't cover changes of orbit inclination. Re: the rocket equation: The rocket equation can be used to design a rocket that gives the delta-v you need to fly those trajectories.

Thanks much!

Is there another (preferred) way to get ALT:RADAR? I wasn't able to find a discussion about this on the Forum. The Docs page for ALT: https://ksp-kos.github.io/KOS/structures/vessels/alt.html ... says that ALT "is grandfathered in for the sake of backward compatibility, but this information is also available on the Vessel structure as well, which is the better new way to do it:" But I haven't been able to find anything in the Vessel structure that references a RADAR suffix.