Zhetaan

Wow. I don't normally see screens that pristine even in stock. Also, nice plane. Anyway, were you executing this burn by hand, I see a potential problem in that you're set to prograde hold in your second screenshot. A sphere-of-influence change would cause a problem there, since prograde is relative to the body you're orbiting. But MechJeb uses a form of manoeuvre hold to execute its burns (actually, it just knows which way to point the rocket, and points it in that direction--which is a throwback to how everyone had to do it back before SAS manoeuvre hold was a thing), so the sphere change wouldn't affect that. I'm starting to think that you've got a bug of some sort; this stopped making sense three posts ago.

Normally, I'd call that a 'control from here' problem as @king of nowhere mentioned. However: ... I'm honestly not sure of how to parse this one. Even if you had previously set up a manoeuvre for your Dres-Kerbin return using MechJeb, that would just be a standard manoeuvre node in the game--you could shut down or even disable MechJeb and the node (and planned burn) would remain. MechJeb works with KSP, not independently from it, which means that a lot of what it does is done merely using automatic control of features that are already accessible to the player. What I mean is that MechJeb shouldn't be randomly changing your target, but even were that to happen, it definitely shouldn't be cancelling existing manoeuvre nodes and setting up new ones. The only time I've ever seen similar behaviour from MechJeb is when someone deliberately created a new manoeuvre in MechJeb's planner and asked it to execute that plan immediately. Obviously, you're not doing that--at least not deliberately. The only way I can think that you might be doing it accidentally is if you keep MechJeb windows open under other menus while you do other things. One thing that a lot of mods in KSP do not have is click-through opacity (assuming that that is even the correct term), meaning that if you have menus open and overlaid on one another, then clicking on one also registers as clicking on any menu underneath that one, because the mods only register the cursor's screen position, not the menu 'depth' under the 'surface' of the screen, to coin an analogy. Is it possible that your MechJeb manoeuvre planner is under, say, the resource panel or a part action window that you're using on your rocket? If so, then you may be accidentally telling MechJeb to plan a manoeuvre and burn for Jool.

It's not completely impossible. There's a mod for that, but of course that requires you to be on PC instead of console. It's called ReCoupler, and in despite of the thread title saying v1.9, the SpaceDock version is rated for the current KSP version. There is also a way to accomplish what you want in stock: connect your flailing pieces together with docking ports. You absolutely can have a vessel dock to itself. You'll need to decide for yourself, though, whether that fits with the aesthetic that you want to achieve.

Putting aside Kerbin as a trivial case, Duna and Eeloo are the easiest to land on. Duna is extremely forgiving with its thin atmosphere, but Mun landings make good preparation for Eeloo. The difference is getting there: if your question is just about landing, then I'd say it's about even. If it's about the entirety of the trip, then Duna wins handily. Moho: It's actually not too challenging to land on, though it's the most difficult planet in the game to reach. Moho is made as a challenge for navigation. It's not totally easy to land on either; the surface gravity is about twice that of the Mun. Eve: Before heating was implemented, this was the easiest landing in the game provided you had a parachute. Now, landing here is tricky. Aerobraking is actually difficult because there's a very narrow range between failing to capture and burning up--and depending on your incoming velocity, there may be no safe approach without a braking burn. Eve is also a challenge planet: it's the most difficult to leave. Kerbin: Landing here is arguably the easiest, but again, it's trivial. Duna: Of the planets with atmospheres, Duna is the most forgiving for aerobraking--even more so than Kerbin. One is cautioned that parachutes often are not enough to carry the mass of an interstellar vessel, and so parachutes on Duna are often best used to assist a powered landing, but totally passive parachute landings are possible if one can control the vessel mass. Dres: Dres is actually easier, theoretically, to land on than the Mun, since it has .115 gee of surface gravity compared to the Mun's .166 gee. However, the gravity is, I think, overcome by the more uneven terrain. The orbit is rather sharply inclined to the ecliptic, so it's more difficult to reach, as well. Jool: Arguably the most difficult planet to land on. Let us know if you manage to do it. Take Dart engines: they're the only ones that work at 15 atmospheres. Eeloo: Essentially identical surface gravity to the Mun (Eeloo is .172 gee; Mun is .166 gee) means that if one can land successfully on the Mun, then one can do the same here. The terrain is easier and more forgiving, too. Eeloo's main drawbacks are its distance and its orbital inclination, but some creative navigation (and a gravity assist from Jool) can readily lighten that burden.

That'll do it. In both cases, being already out at a distant moon, it's tempting to think that since you're already close to solar orbit, you ought to go the rest of the way there and uncomplicate the manoeuvre. Maybe that's not your reasoning, specifically, but either way, it doesn't work very well. Here's the main reason why this wastes propellant and delta-V: once you get to solar orbit, as in the instant you leave the local sphere of influence (whether Kerbin or Jool), your vessel still has an orbit that looks a lot like that of the planet that you just left. Burning for solar orbit does change it just enough that you become separate entities, but only barely just enough. In other words, with the way that you're doing it, most of the burn for solar orbit is wasted propellant because once you're done, you're effectively only marginally different from where you started. One may imagine launching a rocket by burning until the engines are absolutely spent ... and then releasing the launch clamps. That's not a perfect analogy, but it's illustrative of the idea: you move, but the way that you're using the propellant isn't helping you much. I don't know how you run your Minmus missions, so this is an honest enquiry: when you do a mission to and from Minmus, do you return to Kerbin by burning to break Minmus orbit into Kerbin orbit, and only then burn to drop your periapsis and actually get to Kerbin? Or do you arrange the Minmus return by burning such that your Minmus escape also happens to throw you back along Minmus's own retrograde so that you both break Minmus orbit and return to Kerbin with one burn? If you do the latter, then that (or something similar) is what you need to do, albeit on a larger scale, for interplanetary transfers. The reason is backed up with a lot of mathematics, but the short version is that there is a lot of energy bound up in a high orbit of a planet, whether or not you happen to also orbit a moon. This is because high orbits have a lot of potential energy, which is actually a circular definition because these orbits get potential energy by virtue of being high: in an important way, potential energy refers to how far something has to fall. The problem is that when you burn to break from high orbit without first using that potential energy in some way, then it ends up literally being wasted potential. The thing to do is to burn to dive for a low pass of Kerbin, and when you're at that periapsis, that is where you complete your burn for Jool. The reverse applies for returning to Kerbin from Jool. There's a lot that goes into the timing for a burn like that, and I won't get into it because @king of nowhere and @Streetwind already covered it, but what I want you to take from this is that high orbits have a lot of potential energy, and that you can save yourself a lot of propellant if you make the effort to realise that potential by first diving into the lower planetary system from these high-orbiting moons. If potential energy is a measure of how far your rocket has to fall, then actually falling essentially converts that potential into energy of motion--and energy of motion is what gets your rocket to new and interesting places.

In the TAC-LS standard loadout, waste is the one waste product that you cannot recycle into anything else. Carbon dioxide and wastewater can be reclaimed or recycled somewhat, but waste is essentially the final end-state that represents an utterly spent resource. If you want to do anything with waste, then you'll need an additional mod. There are a few greenhouse mods that will use TAC-LS waste as an input to grow food. In the literature, TAC-LS does specify the different types of waste generated by each reclamation or recycling process (Water Splitter produces hydrogen, Sabatier produces methane, Bosch produces carbon), so it wouldn't bee too far off the mark for Realism Overhaul or RealFuels to make use of that, either. Again, it requires another mod.

The only mod I know that dynamically shifts coordinate systems is Principia, but that's because it simulates n-body orbital dynamics. There are ways to solve your problem, though: you can use the Law of Cosines to get a velocity vector for a combined plane-change/altitude-change burn. Here's a link to some example problems. For your case, you'd want to get the relative inclination between your initial and final orbits (since neither of them is zero with respect to the primary) and solve on that basis. I believe that would be the 31.58 degrees that is listed in your Kerbal Engineer window. Bear in mind that this method considers both initial and final orbital velocity, so you probably have a bit more calculation to do to determine the final velocity post-burn.

I believe that that will only work when the game considers it a single vessel, though, so you're not going to get away from needing to dock, in which case @NewtSoup has the general idea. Ground docking is usually a pain, because even if you took two identical copies of the same rover with docking ports on their noses, for example, putting them together on anything but perfectly flat terrain can cause issues because the docking ports may not be angled to meet correctly. There are some pre-robotics, stock solutions to the ground docking problem, up to and including making the refinery a landing pad and dropping the tanker onto it, but these tend to be cumbersome at best. That being said, you should be aware that quite a few people have reported problems with combining docking ports and robotic parts, so be wary. Anyway, there are some general tutorials out there for robotics parts, but I'm not entirely certain of how useful you will find them for your application. Regardless, here are a couple of them: Good luck!

Certainly. The general calculations, or at least an example of them, can be found here. A more practically useful step-by-step demonstration for Duna, which you can (and should!) use to evaluate your Duna trip so you can get a feel for how it works, is here. Also note that the second link is a part of a series of KSP Let's Do The Math videos, and the next planet in that series is Moho, so you may find it especially useful. The equations used in the video all follow from the vis-viva equation, which is as follows: v2 = μ[(2 / r) - (1 / a)] Where: v = instantaneous velocity at that point of the orbit, μ = standard gravitational parameter for the primary body (it is Kerbin for the escape, the Sun for the transfer, and Duna for the capture), r = orbital radius at the point of the burn, and a = the semi-major axis of the orbit. Calculating these for your parking orbit and your transfer orbit, then subtracting to get the difference, will yield the burn delta-V. You'll need to do it multiple times, considering each leg of the trip, but that's all fairly straightforward--especially if you have a good grasp of algebra. The nuance is in selecting where and when to burn. I understand that to be part of the challenge, so I won't deprive you of a chance to figure it out for yourself.

The Oberth effect is probably the easiest to calculate. You'll need the vis-viva equation and a decent working knowledge of algebra, but it obviously can be done: the ship flies, after all. Longitude of Ascending Node (which I assume is what you meant; how large the ascending node is is simply your inclination angle, but where it is is the longitude) is much more difficult to do. The problem is that in reality, LAN is defined based on a 'fixed' (that's only relatively, locally, and temporarily true, but it works for navigation for now because of the scales involved) point in space, and the only 'fixed' points in space are the stars. KSP, on the other hand, doesn't have stars. It has a pretty skybox, of course, but that skybox is essentially painted on the face of the universe for aesthetics and without any consideration for navigation. In other words, it has no fixed orientation, which means that you cannot take repeatable, reliable bearings from stars. That said, there may still be ways to help you: I find it difficult to believe that there would be an impossible challenge on the Discord without someone else figuring that out and announcing it. What is the challenge?

@Just Jim: My apologies for arriving so late to the article, but I wanted to express my appreciation: you've largely become the epitome of 'local boy makes good' for the forum, and to see how much you've been able to chase the dream is very gratifying for someone who's been a fan since Chapter 1 of Emiko Station (considering that it's been nearly seven years, now,--wow!). I have two thoughts: first, considering how unique KSP is, I'll say that if, after you've finished, KSP is only half as unique, then you've done the best job possible. It looks like that's what you're trying to do, and it also looks like you're succeeding. Not to diminish the contributions of your teammates (far from it--they sound like great colleagues), but I know that there has been concern in the past about whether KSP2 was going to be a, for lack of a better term, 'spiritual successor' to KSP instead of merely a sequential one. It is beyond satisfying to see someone whom we already know 'gets' KSP doing so much to curate the tone of the sequel. Second, are you certain that you want to go with Advanced Photonic Generation System? Electromagnetic Radiation Generator System abbreviates to a much better pun. On a side note (and much more seriously), I hope you've managed to dodge the storms without too much trouble. Stay safe, good luck, and thank you.

That's because orbital period defines the resonance implicitly. Resonance occurs when the two orbital periods are in a ratio that can be reduced to low integer terms, such as 1/2, 2/3, 5/4, and so on. For satellite networks, you generally want 1/1 because that keeps the spacing, and manoeuvres for that are more a matter of relative positioning rather than resonance. The reason that specific values for the apsides don't matter is because orbital period, in turn, is dependent on the semi-major axis, and only on the semi-major axis. The eccentricity doesn't matter; only the semi-major axis does. That said, for a comm system, having the satellites in high-eccentricity orbits will change their relative positioning on a cycle even though the average is constant. This can be a feature rather than a bug: satellites in Molniya orbits exploit this in combination with inclination to spend a long time above the northern hemisphere in resonance with the Earth's rotation, thus repeatably giving better satellite coverage to certain longitudes in the northern hemisphere. There are other important features of Molniya orbits, as well, but the point is that the resonance works because of the semi-major axis and its relationship to orbital period, not because of any other factor, which means that there's a lot of room to modify those other factors and thus many potential applications for different types of resonant orbit.

The only way I know to do what you want without mods is to use what I will call the contract slot machine. Normally, there's a penalty for declining contracts, but you can turn that off in the settings (it's one reputation point per decline, so it may or may not be worth it for you). Then, start declining contracts. Mission Control will generate new ones, and you can keep declining contracts until you get one that you want. However, there are two points of caution: Some contracts are locked until you do certain things in the game, whether it be visiting a celestial body or something else. If a contract is locked behind a milestone, then no amount of random number generator abuse will get the contract that you want. There's a weighting system in place for contracts. If you decline a contract, then the system takes that as evidence that you won't want that type of contract in the future. If it's a contract type that you don't ever want to do, then that's fine, but if it's a contract that you'd like, but not right now, then it may be a problem for you to decline contracts of that type too many times, because it means that you won't see that contract type when you decide that you do want it. If, however, mods are something that you might like, then I suggest that you give Contract Configurator and its associated contract packs a try. It will let you choose the contracts that you like from a list of available types. It won't necessarily have every contract possible (random numbers and player progression are still part of the game here), but it will show you contracts of the various types available as well as the requirements needed to unlock other types of contract.

Docking mode does change the controls. If you're having this problem, then it is possible that you have a keybinding issue or a conflict of some sort in your settings. However, it seems more likely to me that you have a CommNet problem. Are you playing with comms, as well? You might be having a problem where your radio signal (or lack thereof, actually) is only letting you have 'limited control', in which case it's not a docking mode issue at all. Does the vessel respond to rotation input when you turn SAS off? It may help to know that in normal flight mode, WASD provides rotational control (technically, it's WASDQE, because roll is a thing in three dimensions), and IJKL provides translational control (technically again, it's IJKLHN for a similar reason). The nice thing about that is that it allows you to have simultaneous control of rotational and translational motion, and also doesn't train you to press the shift key for anything other than engine throttle.

@Hamfisted: Here's the key to making it work: The Sentinel telescope works by scanning on behalf of the next planet farther out. This means that to scan for asteroids for Kerbin, it needs to be between Kerbin and Eve. If your telescope was saying that it was tracking objects near Duna, then its orbit was too high: it was between Kerbin and Duna, not Kerbin and Eve. How does it know which planet is the next farther out? There's no single orbital altitude when an orbit is eccentric (and don't forget that Eeloo is actually closer to the Sun than Jool for a portion of its orbit). However, it can compare semi-major axes. The telescope knows the semi-major axis of its own orbit, and it knows the semi-major axes of the planets' orbits, and so it tracks objects 'near' the body with the next larger semi-major axis than its own orbit. Thus, what happened with you is that when you burned to bring your telescope's orbit down, you reduced its semi-major axis to a value just below Kerbin's, and so the telescope began tracking objects for Kerbin rather than Duna. On the other hand, this: ... is not the answer. There's no list of discoverable asteroids; the game generates them at random. You cannot 'fish out' the asteroids from one orbit in the same way that the stock science sensors (thermometer etc.) can only extract a specific number of science points for a given experiment in a given biome. So long as one leaves the telescope in the right orbit and tracking objects, it should continue to do so indefinitely. Considering that it's been three and a half years, I certainly hope that that was enough time.

The Oberth effect does have, well, an effect, at least in part, but the relationship is less obvious because one tends to see the result through the lens of gravitational effects without intuitively recognising the fact that the orbital speed at the periapsis of the 200 x 10,000 orbit is necessarily greater than that at the periapsis of the 200 x 300 orbit. Instead, one tends to look at it in terms of orbital energy getting closer and closer to escape, but since higher initial velocities are unavoidably part of that, and the Oberth effect is the resultant change of orbital energy that is dependent upon (and attributable to) the initial velocity, the Oberth effect is unavoidably part of that, as well. To the maths! (In the spoiler; I'm not a sadist.) I hope that helps a bit.

That's because it's technically a gravity assist, as well. You're moving at high orbital speed with respect to your primary (in this case, Earth), so you get the benefit of the Oberth effect, but you're also using that effect to direct your velocity retrograde against Earth's solar orbit, which is to say, it's a deceleration with respect to the sun. Many people think of only unpowered gravity assists when confronted with the term gravity assist. Powered assists also exist. The end result is that the difference (with caveats, of course) between going to Mars and going to Venus, most everything else being equal, lies in which side of Earth you're on when you start your burn. However, that looks very similar to what I will call the second half of unpowered assists, where the difference between an acceleration or deceleration is which side of the planet's sphere of influence you exit.

That's not quite it. The transfer isn't impossible; it's just extremely inefficient to use a one-burn transfer when you're on that sliver. Part of the issue is that there's no single solution to the problem of how to get from your origin to your destination. There are literally infinite paths to take. The porkchop plot exists as a tool to help you choose from a group of solutions that offer some value or benefit over other possible choices, but it's important to remember that choices in that range are all trade-offs of one another. One set of solutions covers fast transfers, which take less time in transit. Another might cover immediate transfers, which let you leave right away. Another set covers efficient transfers in terms of delta-V expended. There are valid use cases for all of these: a fast transfer may be the best option when you have a life support mod to consider. An immediate transfer may be needed for a rescue mission. An efficient transfer is good for when you have limited delta-V or want to save it for some other part of the mission. However, when setting up the plot, there are still a few assumptions that the planner has to make. One of them is whether you want a ballistic transfer (that is, one burn at the beginning that gets the encounter), but sometimes that's not the best one in terms of your delta-V budget. Sometimes, a mid-course correction is cheaper, for the same reason that sometimes, it makes more sense to raise your apoapsis before making a drastic inclination change. Let me try to illustrate the problem a little better. I don't have a good Paint drawing, so I'll just have to be descriptive. When you're transferring to another planet, you have to account for the fact that you're already in motion, co-orbiting with the planet about the star. Generally speaking, efficient transfers are those that take advantage of your existing motion, because if you can use existing motion to your advantage, then you can subtract the cost of that existing motion, since you start with it and don't need to expend propellant to get it. This the exact same idea as to why it's more efficient to launch to the east; the planet is already rotating that way, so you can use it for free delta-V. However, if you want to go to the north pole, then launching east won't help you because your destination isn't in that direction. Similarly, if your destination planet is outside of your origin's orbital plane, then transferring within the origin's plane won't get you to your destination, because your pre-existing direction of travel doesn't go there. You can choose to transfer when you're at the ascending or descending node relative to the destination, but you might wait a century for a transfer window that aligns with the node--if there ever is one. You can go at the right window while staying in your orbital plane, but when you reach the destination's orbital distance at the correct time, you'll find that the destination planet is somewhere to your celestial north or south (i.e., 'above' or 'below' you relative to your plane, for whatever value those words have in space). In order to actually intercept your destination planet in a good transfer window, you'll need to leave your orbital plane. Generally, the best place to do that is as far from the line of nodes as you can get on that leg of the orbit--i.e., the mid-course correction--but if we've already established that this is a ballistic, or single-burn transfer, then that's not an option. The only burn that you can use to make the encounter is the initial interplanetary ejection burn. In most cases, you can add a bit of inclination (and possibly a bit of radial, too) to get a satisfactory encounter, but in extreme cases, the only solution to encounter a planet that will be a few billion kilometres to your origin plane's celestial north when you get there is one that arrives from the celestial north itself. This doesn't necessarily mean a totally polar orbit, but a burn that has you ejecting at 30° inclination when you don't need to do so is going to be inefficient no matter how you arrange it. Well, you can, to begin. If you want the very best in terms of efficiency, then I'd suggest using a transfer calculator (e.g. the Alex Moon planner or the mod that incorporates it into the game) and using the information from it to set up the burn. But that's not strictly necessary; you can get very good corrections on your own. The best place for a mid-course correction is a point 90° of true anomaly away from your encounter with the destination--or, rather, I should say from the point where you would like to encounter your destination, since you won't encounter it without the correction. I should also point out that the ballistic transfer is sometimes the better choice. MechJeb's advanced transfer calculator is very good. It automatically offers the best available ballistic choice, and that is usually negligibly different from the one with a course correction. Let's not forget that that sliver of inefficiency doesn't matter much unless the transfer that you want falls on it. If--if--it does, then sometimes, you're close enough in inclination that a mid-course correction is more expensive than simply working with the inclination difference ... or, of course, picking a different transfer. The option that works best also depends a lot on your mission: even when the delta-V difference is slight, different trajectory choices will affect your orbital insertion when you arrive at your destination, and possibly cost you more in terms of local manoeuvres if you're looking for a specific inclination on arrival. An example of where this is relevant would be when you're transferring to Jool: arriving in an inclined orbit over Jool in itself doesn't mean much, but if you want to visit the moons, then you'll probably want to arrive with an inclination close to matching theirs. Of course, changing your arrival characteristics so that you get favourable encounters requires a mid-course correction anyway, so you may be stuck with that. If you want to try your hand at figuring this for yourself, then I strongly recommend perusing Rocket and Space Technology and getting a feel for some of the mathematical relationships involved here. The link will send you partway down the page; there's a subsection titled Non-coplanar Trajectories that touches on some of your questions. Also, it has diagrams! Good luck, and should you have any further questions, please don't hesitate to ask.

@Lt_Duckweed has the right idea. I will offer one correction and say that the best place to make the mid-course correction is not at the node, since the node being in the wrong place is the root of the problem, but I'll get to that. If you take a look at the Alex Moon launch planner, just using the default Kerbin-Duna ballistic transfer, you'll see a sliver of inefficiency cutting across the plot. Switch the transfer type to 'Mid-Course Plane Change', and you'll see that the inefficiency goes away. When two orbits are not coplanar (which is the case for most orbits, even in KSP), then the mathematical solution for their intersection is a line, called the line of nodes, that joins the ascending and descending nodes. If you depart your origin at that node, then you can move efficiently in your original orbital plane and encounter your target, because when you reach it, the target will also be in your original orbital plane; you'll end up in an inclined orbit about the target, but you'll at least encounter it. If you depart from somewhere that isn't the node, then you need an orbital solution that will intercept the target. For intercepts that are relatively close to the nodes, you can get the encounter with only a slight amount of inclination, but anything that is more than a few degrees of true anomaly away will require a transfer that is a polar orbit of the sun--at least if you want to get the encounter with a single transfer burn. Adding a mid-course correction provides a much cheaper solution, because the midpoint of the transfer is an efficient point to change your node relative to the target. The cheapest place to change the node is as far away from the node as possible. For a (nearly) Hohmann transfer, that's at only one point (since you generally only use half of the Hohmann orbit), so the solution isn't difficult to calculate. However, some porkchop plotters don't bother with that solution because, for one thing, the solution that doesn't involve mid-course corrections is usually going to be cheaper anyway, and for another, if you're advanced enough in KSP to use a porkchop plot, then you're probably advanced enough to know about mid-course corrections, too. If you want to see more evidence of this effect, then you can play with the Alex Moon planner and try transfers between destinations with high relative inclinations, such as Kerbin-Eeloo and Kerbin-Dres (or, for an extreme and dramatic example of this, try Dres-Eeloo). Look at the ballistic (single-burn) transfer, and then re-plot using the same general settings but with a mid-course correction.

I don't know about faster, but whenever I do any kind of complex orbital assembly, I use a tug, which is basically a flying RCS tank with a docking port (or two; I tend to use Sr. and standard Clamp-O-Trons and build tugs to suit) and probe core for control (and obviously all of the electrical and communication support that it would need). For your application, you might consider fine control mode for your RCS. You get that by hitting caps lock and can tell that you are in fine control mode when the pitch, yaw, and roll indicator arrows (on the lower left of the screen) turn blue instead of orange. Fine control is slower, but it has the advantage of using compensated thrust, which is to say that it will adjust each attitude jet for you to try to push the thrust vector through the centre of mass.

It can grip it by the husk! Anyway, I'm glad that worked out for you. The orientation of the Sr. docking port (and correcting it if it's put on backwards) has been a point of contention since ... it was introduced, actually. For all I know, it's one of the reasons KAS was developed. It's nice to see that stock in-flight assembly has offered a way to deal with that.

You should probably look into those gravity assists. Without seeing more of your mission profile, I can't say anything definite, but my main suggestions are to check to see whether your encounter inclination at Moho is too high, and to see where you're meeting Moho on its orbit. The best way to Moho after a gravity assist is to try for one that encounters it at its periapsis, not apoapsis. Encountering it at the periapsis makes your orbital ellipse more similar to Moho's, which cuts the cost for capture.

If I understand your question properly, then no: you need to store it, dock, and transfer it directly. Science transmissions in KSP only go to Kerbin for processing. Data processing in a science lab entails taking the experiment data (not necessarily the experiment part) to the lab; once the lab is finished with it, then you can transmit it--again, only to Kerbin.

No go. Return to orbit, do whatever you need to return to Kerbin, and come back to the Mun with a better-equipped vessel with a design informed by the lessons learned from this attempt. I've never tried not returning a tourist, so I can't say for certain that the game requires it, but you shouldn't risk it anyway. Tourists cannot EVA, so any rescue mission needs to involve docking, whether be it for propellant or passenger transfer. That's much easier to do in orbit. Or, I suppose, you could make a vessel with a big cup on the nose and use that to return your Mun non-lander to Kerbin. Good luck flying that, though.

I tend to go in the other direction and make it harder. The finance system and the science system don't really interact in the stock game, and while reputation does influence both, I have never felt the need to pay special attention to it. Of course, that's just a way of restating your point--if the science and finance systems were interdependent, then you wouldn't be able to cheat one out of existence and still have a meaningfully playable game. My general goal is to try to force the science and finance systems to interact more, mainly by making science points tremendously more expensive so that I have to spend more money to acquire them (and even more to use them--I have the game set to require Funds to unlock the tech in the various nodes). I mod a few things, such as the big ISRU converter, to work less efficiently (no self-powered LFO plants for me), or to die off, such as the RTGs which I mod to decay. I use an extended tech tree that costs more to unlock, and also spreads out the technology so that each node unlocks less. I also turn down the science rewards to the point that there isn't enough science in the solar system for me to unlock the entire tree without labs, asteroids, and contracts that award science outside of the fixed-value experiments on and around celestial bodies. I make labs a good deal less efficient, but I also massively increase their data storage because the alternative is needing to revisit them every five minutes to top them off--I prefer to macromanage those sorts of things, not micromanage. This approach generally forces a careful build-out, but it puts me in a position where I need to pick and choose what I am going to develop for missions farther afield. The contract system, then, helps to guide and direct those missions--whether I go towards Moho or Eeloo is often determined by the contracts generator--rather than serve as a way to make some quick money to use in the thing that I really wanted to do all along. The research choices are then informed by the contract destinations: I can invest in power technology so that I can charge a battery out near Eeloo, but at the cost of being able to invest in more powerful engines, for example. Or I can go the other way and use the basic solar panels at Moho, but not unless I have good enough engines and propellant tanks that I can actually stop there after I arrive. I do make a couple of things 'easier': I set the temperature and pressure sensors (and any other sensor that only generates a number without handling a material) to fully return transmitted science, because why would it somehow be better to recover the sensor that reads '173K' rather than just transmit the value? However, to balance this, I also generally make it so that it takes multiple experiments to fully extract the available science points. In other words, I'm not going to land in the Badlands, take out a thermometer, and assume that that is the Universal Badlands Temperature. I'm going to take several measurements, which means either staying a while or making multiple trips. There are exceptions: I don't need to take multiple pressure measurements in high orbit, for example. The overall idea is to make the science, research, and development sides have a little more to do with one another, and thus make the game a little more realistic without needing to go to the same extent as Realism Overhaul. Then I can return the science that I gather and maybe unlock something that will ease the second trip. If this all seems very tedious to you, well, that's probably because it is. But it works for me. I will say that I try to balance it so that I unlock everything before I've gone everywhere (that's where contracts and labs come into play) because it doesn't make sense to unlock that big, fancy engine only after you've proven that you don't need it and can do just as well with something inferior. But I've never liked the idea of being able to unlock the whole tech tree before getting beyond Minmus, either.