Tallinu

Members
  • Content Count

    144
  • Joined

  • Last visited

Community Reputation

28 Excellent

About Tallinu

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Okay, I believe what you're telling me is that if any of my active craft (the ones saved in the persistence file and any quick saves) contained parts which suffer from this module duplication issue, "fixing" the duplication before installing the newest release of TweakScale would have caused the affected parts to experience issues like zero mass and other nastiness, regardless of whether or not their scale had been changed (simply the presence of the broken duplicate module is enough). Is that an accurate summary? Assuming that is true: Since I have not used any of these parts (the parts in which I found module duplication in the cache file) in any of the craft I've launched so far, none of my existing craft should experience any problems, regardless of what I do (because none of the parts they contain have duplicate modules saved). But now that I have installed the new version of TweakScale, it will prevent the duplicated module in those parts from eventually corrupting any craft I might launch that use those parts, because it renames the extra module to something else which won't overwrite the correct settings in the first instance of the module. Therefore, with the new version installed, I should be able to safely use any parts which are affected by that duplication, without having to try to manually fix hundreds of lines in the cache file every time I install or remove or update an mod (which happens frequently enough that it isn't really feasible). Correct?
  2. How do you know for sure if you are affected by the problem? That doesn't seem very clear to me. None of the craft files I have saved recently seem to have any duplicated TweakScale modules, but when I hunted through my ModuleManager.ConfigCache file I found some parts where this was the case, matching what you showed on the GitHub issue even down to the duplicated type and defaultScale settings in the first module. The affected parts don't seem to include any that I have actually used in my craft so far. And as I said, I didn't find any evidence of this issue in my saved .craft files. Does that mean I don't have to worry, and once I install this TweakScale update, there won't be any problems if these corrupted extra modules do get added to things in the future? I actually don't use TweakScale very often, funnily enough. I'm usually able to do everything I want without changing part scales. The only thing I can really remember doing most recently is increasing the size of the micro landing legs one time when I needed longer legs for a lander but only had those legs unlocked, and that craft was recovered a long time ago.
  3. Tallinu

    LKO rescue plan

    The Klaw is the (official!) nickname for the Advanced Grabbing Unit, in the Actuators (160) research node. It's capable of latching onto other vessels/parts without needing a docking port on the target (and can latch onto asteroids in order to stay attached while mining or moving them). (Ninja'd!)
  4. Tallinu

    Rescue in LKO

    You can actually change which direction they point their helmets by switching camera modes using the V key (pretty sure that's the default). In "Orbit" mode, "up" is north as bewing said. But in "Free" mode, "up" is away from the planet, and pressing space will orient EVA Kerbals that way instead. If your target is significantly above or below you in one camera mode, or you're having trouble getting a grip on a ladder because of the target craft's orientation, switching camera mode may make it significantly easier to maneuver to or around your target.
  5. Right. I just didn't understand that when you said "this is a special case" you were referring back to this constellation setup again, rather than orbit segment time scaling in more general terms, which is where my mind was leaning (as in that last paragraph) as I'm learning how these things work. I always understood intuitively why the TA of 90 was needed in this case, even when I was originally describing it wrong, lol! It needed to be symmetric, with the AN/DN equidistant from both Pe and Ap. Anywhere else would not put the nodes in the right place, the orbital plane would be tilted around the wrong axis, and sufficient error would prevent 100% coverage.
  6. Actually, the biggest issue I'm addressing by having all four satellites be deployed by a single carrier vehicle (second to interplanetary encounter/capture) is to get the correct relative timing between the four satellites. Each must reach apoapsis at a different time, staggered by 1/4 of their period and in proper sequence. Deploying them from a lower circular orbit that makes 1/4 less than a whole number of full orbits in that amount of time allows each satellite to arrive at the target apoapsis from its deployment burn with the correct timing, raise its periapsis and tweak its period to be as accurate as possible, and from then on remain synchronized with the others, even as they all later perform their inclination changes -- the orbits are fairly high even at that point, so the delta-V cost of doing inclination last was acceptable. A small lightweight relay satellite can easily have 2000 to 3000 delta-V with just a few oscar tanks and a spark engine, though relays meant to reach Kerbin from the outer planets would by nature require larger, heavier antennas (or arrays of them) and therefore more fuel and thrust -- although a better way to go about it, especially around Jool, would likely be to have a pair of large, powerful relays as the main link back toward Kerbin, while small satellites with RA-2 antennas like the ones I've been experimenting with provide local coverage of each moon, bouncing signals around to reach the larger relays as needed. Really? Let's see, the SMA given in his thread is 3,625,000m and according to the wiki, Laythe's SOI is 3,723,645.8m and its radius 500,000m. So that's 5/6 of Kerbin's radius. Scaling 4,350,000 by that factor does indeed give 3,625,000. Despite the fact that Laythe's SOI is vastly smaller than Kerbin's, that result is still lower, but the orbit isn't circular, so... Okay, I think I finally found what I need to do to figure out the Ap and Pe (to center of mass) from eccentricity and semi-major axis. Google was all like "Here's how you calculate the things you already know!" Eventually found https://jtauber.github.io/orbits/017.html and managed to piece it together from various pages there... Focal distance c = a * e 3625000*0.28=1015000 It looks like Pe = a - c/2 3625000 - 1015000 / 2 = 3625000 - 507500 = 3117500 And then I think Ap = 2a-Pe 2 * 3625000 - 3117500 = 7250000 - 3117500 = 4132500 Dang, it's less than 10% outside the SOI! And for the most interesting and science-rich of Jool's moons, too... Well, that one will just have to make do with three equatorial satellites. Anything landing on the poles will probably be able to see the strong primary relays north or south of Jool. A set of three of those, equidistant in a polar orbit, should ensure that one or more are always visible. Indeed, I was just thinking that as I read the previous paragraph. (Also: I get that reference! High-five! ) Good, I had a feeling it was something like that. And now I'm confused. I'm not sure what the difference is, compared to what you said earlier in that paragraph. How does "being Pe" or "being AN/DN" change anything, compared to going from, for instance, 30 degrees to 45 degrees TA on two orbits with the same eccentricity but different periods?
  7. Wow, you've really gone above and beyond here! Did you get your Ap and Pe references swapped in the above line? Or is there some reason to use the Ap sight angle for Pe and vice versa? And considering that I actually used a SMA greater than 4,350,000m around Kerbin anyway (5,506,299m), in order to get easy to work with periods (12h), and plan to do the same around other bodies, there should be an even larger safety margin. What I had in mind was, TargetBodySMA = KerbinSMA * TargetBodyRadius / KerbinRadius which I'm pretty sure gives the result I'm looking for, linearly larger or smaller in proportion to the change in radius. If that does the job the way I believe it should, then I don't have to mess around with math that I can't do in my head. It's great to have alternate verification though! Dangit! Google never dug up Zyx's post for me. And you had even posted there, too, at the time. "Indeed, you're looking at the prospect of four launches, at least for Kerbin." Well, I'm getting all the satellites there with one launch, but making that plan work is what I needed help with in the first place. XD Mainly I'm doing it that way because I wanted something that would work for moons and other planets, and getting a single vessel carrying multiple satellites to intercept a planet will be far easier than trying to manage multiple vessels, and means that the satellites themselves only need to carry enough delta-V for moving into the correct orbits once they detach from the carrier. And it looks like he already did the work of figuring out the SMA for all the planets and moons! I'll probably check a few with that ratio method to see if they match, and if they do, I can just use his values as minimums and try to find nice periods above them. It seems the only one that he had an issue with was Duna because of Ike, and for some reason he went lower instead of higher. I'll have to have a look at Duna's SOI and see if the constellation could be set up in higher orbits instead, to avoid creating gaps in its surface coverage. And that video and patent document are also interesting. I suspected there was probably a range of values that would work for things like eccentricity and inclination, and one of those illustrations confirms that, though it seems like 0.28 and 33 are pretty close to optimal there. Again, thank you for all your help, you've done far more than I asked! Edit: I just had a thought that might save me a lot of trickier calculations if it's correct. Assume that the eccentricity of the orbit remains the same, and only the period is altered (causing the SMA and both the periapsis and apoapsis heights to increase). For example, going from a 12 hour period to an 18 hour period. Am I correct in thinking that the time taken for a satellite to travel from periapsis to latus rectum (TA=+-90) scales linearly with the period? As in, 18/12=1.5 so t=7000*1.5? In my notes from working out the right equation to do what you showed me, I have: t=(2tan^-1(3/4)-(0.28*sin(2tan^-1(3/4))))*43200/(2pi) It looks to me like the location of that 43200 value for period makes it a simple linear scaling factor for the result.
  8. https://steamcommunity.com/sharedfiles/filedetails/?id=1654472000 I just got done setting up for the first of these maneuvers, and it looks great! Not exactly crossing the other satellite's orbit line but I doubt that's possible without performing the inclination change for the first two satellites before the other two (the ones opposite them) are even launched... https://steamcommunity.com/sharedfiles/filedetails/?id=1654490026 Aaaand done! Periods correct down to a thousandth of a second thanks to thrust limiting down to 0.5% and slow-mo physics warp. Pretty much perfect. Yeah, reading about it did fill in a bit more historical detail for me, which was interesting. The whole epicycles thing, heh... And to think that today we have people "all around the globe" (lol) who supposedly believe the Earth is flat again. Right. I figured that one out. Yeah, I had to figure out adding in and removing the planet's radius already. It's nice that they gave Kerbin such neat round numbers, heh. The reason I was trying to figure these calculations out to begin with was that I couldn't find a way to do it (accurately) using Engineer or MechJeb, but hey, maybe I've actually learned something! I doubt I'll remember the details of the equations a week from now, and there's no way I could write any of them out from memory, but the relationships between the anomalies and what everything does and means is all pretty clear. You've been a tremendous help with this! I don't suppose you have any thoughts on the additional issue I noted near the end of the OP, about figuring out what semi-major axis would be required around other planets? My best guess on that right now is to compare the radii of the planets and just scale up/down proportionally from the 4,350,000 that was used in the original details for Kerbin (in the thread I referenced), on the assumption that the geometry will end up the same. I'll still need to figure out what the period would be in the rescaled orbit and figure out if it can be done within the SOI of some of the smaller moons, or if the reduction in mass (and hence gravitation) causes even that (presumably) closest possible orbit to be outside the SOI of, say, Minmus the same way a synchronous orbit would. Although I have the advantage of not worrying about the planet or moon's rotation speed, only its radius, which is going to be smaller along with the gravity, so maybe it'll work out nicely...
  9. I figured that would be the case. Just to make sure I'm not missing anything important, my understanding is that TA = 0 at periapsis, is that right? I need to figure out how to get characters like ε typed in without copying and pasting from something else. And how to remember what to call them (other than "curly E" or "curly W" LOL). I've seen these equations everywhere, but always in the context of solving for position, and just couldn't sort out what I needed to do to get the answer I wanted. Looks like I was overthinking things, and except for the first one they were already in the required form with no "numerical analysis methods" (whatever that means) needed! Awesome! Thank you so much for the walkthrough of this process. And the answer -- when I try it myself I can use that to check my work. This should be able to get me the time before periapsis as well, right? Symmetry and all. If my satellite is at apoapsis (just after getting the 12h period matched), just subtracting 7000.63 from the UT at which periapsis will be reached should give me the position on the closer side, without having to wait and go past PE. And I should be able to use this around other bodies as well, right? It doesn't appear to directly require any constants regarding gravity and such, just the parameters of the orbit and the period. Taken together, those effectively incorporate that kind of information already, I believe? So what I need to do now is go back to make sure all of these are solved in the form I need, more or less the way you did but keeping the input of True Anomaly as a variable, then chain it all together with another variable for period, and I should have an equation where I plug in those two values and it spits out a time-since-periapsis as a result. I could then convert that into a bit of code to do the job quickly. Maybe even figure out how to write a KSP mod to do it. (If I decide to get really ambitious I could probably work up a pull request for MechJeb to let it automatically place maneuver nodes at specific points in the orbit...) As it turns out, I was very much mistaken when I claimed that the position I wanted was along the semi-minor axis. In hindsight, that should have been pretty obvious, since the minor axis goes through the center of the ellipse, NOT either of its foci. I'm glad I mentioned the true anomaly, since that's the actual position I need in order to change the inclination correctly. The apoapsis and periapsis need to be the points most distant from the equatorial plane, with the orbit not tilted one way or the other around the major axis, to match the example configuration as closely as possible.
  10. Credit for trying to help, but yes, I am familiar with orbital maneuvers and standard relay satellite deployment patterns. And I am, in fact, making use of a particular variation of a resonant orbit (or maybe it's something more properly known by some other name), a kind of result which that calculator isn't designed to provide, to get all four satellites launched on their different trajectories at precise times. I'm afraid I put "advanced" in the subject line for a reason. I'm working on this because I want to do something way cooler and more effective with fewer satellites. The kind of help I need is not "how do I shot relay satellite?" It's "how do I math Kepler to solve for X given Y" or "how do I avoid having to math Kepler and get this accomplished to the desired precision by some other means." I don't want to be just eyeballing the position of my maneuver node based on where the lines appear to cross, I want to do it right, or find a way to make the game or the mods do it right for me (that doesn't take launching extra equipment). I've been trying to figure out how to get from point A to point B mathematically speaking, where A is the assortment of orbital parameters I have and B is the one piece of information I think I need to solve for. But, at least so far, I'm just too unfamiliar with the relevant equations to know which I need and in what order and form, compounded by my programming-trained brain always finding it harder to work with variables that don't have names which are intelligible words that remind me what the variable is and does just by reading it. About the only one I even know how to say is theta, because it was used so often back in trig class, lol!
  11. This is also a great perspective, overall, but I think it needs a couple of minor caveats. Time to Apoapsis (I'll abbreviate as TTA) isn't necessarily going to stabilize and stop increasing "until nearly in orbit" if you run your engines at full power at all times the way you suggest. In my experience it never stops going up, slowly at first but more rapidly later in the ascent, unless I'm actually taking too sharp a turn and not going to space today after all. If you're taking a high enough turn to make sure you don't burn up or lose excessive amounts of speed to drag, once you start to get into the upper atmosphere TTA can rise quite rapidly, thanks to the increase in TWR as your stages expend fuel. This can happen even if you start with low TWR (around 1.2), as in your engines are just barely strong enough to take off. Taking a sharper turn isn't necessarily a surefire answer to that, especially if your TWR drops quite dramatically when you stage. It depends on your rocket design and what fraction of your trip to orbit is performed by each stage. In fact, the closer you come to getting all the way into orbit on your first stage (doing so creates a SSTO rocket with any remaining stages as payload), the more you have to throttle back as you get closer to aiming at the horizon in order to avoid pushing your apoapsis up to your target too soon. Another issue: Being a little too high compared to the most efficient possible gravity turn for your craft is basically safe. Being a little too low can be deadly. Keeping TTA stable toward the higher end of the range gives you more time to correct if it starts dropping (for example, after staging), by aiming slightly above your prograde vector. Doing that is not necessarily the most terrible thing ever in terms of efficiency, as long as you don't have to veer too far off prograde. For example, I've read that real-life rockets often circularize post-apoapsis, which would require just such an orientation.
  12. The most efficient kind of ascent path is typically what's known as a gravity turn. This involves gaining a certain amount of straight-upward velocity, and then tilting the rocket a certain number of degrees in the desired direction (usually east, and often north or south for polar orbits), waiting for the prograde marker to descend to match the rocket's new "forward" direction, and from that point on following the prograde marker in a smooth curve that minimizes drag. If you have a level 1+ pilot or a good enough probe core, you can turn on SAS and simply set it to the "follow prograde" mode. And as mentioned by many others everywhere, there is no single, optimal ascent for every rocket. Finding the best gravity turn path for your unique rocket takes trial and error, even when a plugin is doing it (the Gravity Turn launch autopilot is an excellent assistant and/or learning aid if you want to watch how it tries different paths and see what the results are, just be sure that you have the option to 'revert to launch' before using it). With experience, you'll get more of a feel for what's likely to work well for a given rocket. It depends mainly on two factors: TWR (Thrust to Weight Ratio) and staging. Drag can also be an issue if it's very high (large fairings or a great deal of parts sticking out without a fairing, for instance). TWR determines how fast your rocket accelerates. If it's not above 1.0, you can't even get off the ground. I prefer to keep the starting TWR in the 1.2 to 1.5 range, and though going higher is an option it could also mean that you have built too much rocket for your payload and might be able to save some money by using a weaker engine. TWR will increase over time as each stage expends fuel, reducing its mass and thus its weight while the amount of thrust (typically) remains constant, resulting in a greater acceleration being felt, peaking right before the fuel runs out. Staging affects your ascent by typically causing your TWR to change suddenly, usually decreasing quite a bit as your spent first stage's powerful engines and rising TWR are traded for a more efficient but weaker upper stage engine. If your second stage (or third, etc) doesn't have enough TWR you could potentially find yourself falling right back into the atmosphere if your prograde is too low to the horizon and you haven't gained enough horizontal speed yet, especially if the engine is simply too underpowered for the amount of payload it's trying to push. I'd recommend keeping this above 1.0, but keep in mind that sometimes you need to make sure it's showing you the vacuum stats (rather than atmospheric / sea-level) in order to see the right TWR and delta-V figures, as some vacuum-optimized engines (like the Poodle and Terrier) have abysmal sea-level thrust and efficiency (ISP). How does all this affect your ascent path? If your starting TWR is high, especially if your second stage's is as well, you typically want to make more of a turn away from vertical, and start sooner. If your TWR is low, you want to start later and turn less. Expressing when to start the turn is also often done in terms of your rocket's current speed, such as "start turn at 100m/s" rather than by giving a time or altitude. They're all interrelated along with TWR anyway, and since a high-thrust rocket will gain speed faster than one with lower thrust, using starting speed figures can make it easier to make comparisons and take what you've learned with one rocket and apply it to another. Finally, it's typically best to throttle back when your time to apoapsis reaches about 50 seconds (in the stock game you have to go to the map view and point at the apoapsis marker to see this, you can right click it to make it stay visible without having to track it with your mouse). Try to maintain that time at 50 seconds so that more of your rocket's thrust is applied later in the ascent when the rocket is aiming closer to the horizon. The benefits of this are twofold: You waste less thrust on going up, and you delay causing your apoapsis to reach your intended orbital altitude. The sooner that happens, the larger a circularization burn you'll need to finish gaining horizontal velocity. For "getting into orbit" purposes, a larger circularization burn is bad. That's because having to apply more of your horizontal thrust at apoapsis, compared to at a lower altitude, reduces the efficiency of that thrust, costing you more fuel, according to the Oberth Effect. (Basically, you spend more delta-V for the same effect when you do it at a higher altitude.) It's a bit counter-intuitive, so to put it another way: Applying less thrust during the middle stages of the ascent (when you're aiming more upward) allows you to apply more total horizontal thrust prior to reaching your desired apoapsis height, which saves you from having to apply significantly more thrust at the end of your ascent where that thrust is less effective. The net effect is that you spend less fuel to reach orbit if you throttle back as needed to avoid pushing your time to apoapsis over about 50 seconds until as late as possible in your ascent (often into the 25-50% range, although TWR affects it too).
  13. Hello! I'm not sure if this is really the right place for this advanced topic, and if anyone has a better idea for where to put this I'll happily post there or get it moved if possible. I'm working on a mission plan to place four relay satellites in a tetrahedral configuration which will provide 100% uninterrupted coverage of a planet's surface, using Kerbin as my starting point for now (since I still need to figure out how to calculate the minimum semi-major axis required to provide such coverage around other planets and moons). This requires four eccentric (0.28), inclined (33 deg) orbits with the same orbital period and, for Kerbin, a SMA of 4,350,000 km or greater. I'm using 5,506,299 km because that results in an easy to deal with period of 12 hours. I'll include the exact orbital parameters needed farther down, which I have shamelessly lifted from a very old (2013) thread which I will also link. Here are a few screenshots to give you a quick idea of what it looks like. Four-satellite tetrahedral configuration for 100% comms coverage on Imgur, or open the following: I've figured out how to accomplish *almost* every step of the process! Plotting the inclination changes to be performed at the correct time/location is the only thing eluding me. It's not a simple matter of doing something at the current ascending/descending node since they all have to start out in equatorial orbits, and I couldn't just target another vessel and use the relative AN/DNs unless I launch two additional satellites and carefully position them in 90 degree polar orbits which are perpendicular to each other and have their Longitude of Ascending Node carefully tweaked to be positioned exactly along the semi-minor axis of the pair of satellites which need to change inclinations relative to that plane. But launching six satellites instead of four defeats the entire purpose of this plan, and if I knew how to figure out where the AN/DN of these polar satellites needed to be, I think I would already have what I needed to figure out when the inclination changes should be performed without requiring some external reference. All I really need is a way to find out the number of seconds since periapsis (or AP, whatever) which will put the satellite in line with its orbit's semi-minor axis (not major, the one at a right angle to it), the latus rectum, which is to say, when the satellite is at +/-90 degrees True Anomaly. (For an elliptical orbit like this, 90 degrees is not simply 1/4 of the orbital period, like it is for a circular orbit.) Kerbal Engineer can show me what my vessel's current True Anomaly is, but it doesn't provide a way of finding out what the UT will be at that point in the orbit or how much time remains before it, so that doesn't help me plot a maneuver node in advance so that it occurs exactly at 90 degrees, which is necessary to allow the burn to be started at the right time. For reference, here's where I'm at in terms of the mission plan. The four satellites each need to reach their target apoapsis in sequence, 1/4 of their final orbital period apart. The period I'm using is 12 hours, so each satellite need to decouple and burn to raise its apoapsis at 3 hour intervals. Additionally, since the Argument of Periapsis for each satellite is rotated 90 degrees (drawing lines from their APs to Kerbin will form an X or + when viewed from far above a pole), the launch vehicle needs to complete 1/4 of an orbit more or less every 3 hours (180 minutes). A circular orbit with a period of 48 minutes will result in making 3 complete orbits in 144 minutes and another 3/4 of an orbit in the remaining 36 minutes. So, first the launch vehicle gets into an equatorial orbit at an altitude of 305,314 meters, which gives an orbital period around Kerbin of 48 minutes. Just before every 3 hour mark the launch vehicle decouples a satellite, I take control of it and create a very precise maneuver node, first using MechJeb's maneuver planner to "raise apoapsis" after an arbitrary fixed time of several minutes and then tweaking the values using PreciseNode until the accuracy is down to the 10 meter range (just because I can), and then I set the UT of the node to a specific time. For the first satellite I just pick some convenient round number far enough in the future to allow time to get ready. I record this value, and then for the other satellites I simply add on the correct number of additional seconds (3 * 60 * 60 = 10800) to ensure that each node is executed with the correct timing. The time taken for these satellites to reach apoapsis from the deployment orbit is around 3 hours 40 minutes, so the first will need to perform a burn shortly after the second is deployed, and so on. The AP burn brings the PE up to approximately 3364.5 km, and I adjust as needed to ensure that the orbital period is as close to the intended 12 hours as possible given the limits of precision in the values displayed by Engineer and MechJeb. Getting MechJeb's Synodic Period (with another of these deployed satellites as a target) to display a value of over 1000 years, for example, is not difficult and offers more than sufficient precision. After all four satellites have performed these burns, the final step will be to change their inclinations so that they provide constant polar coverage as well as equatorial. And that's what I'm not sure how to do accurately, as described. Here is a save file for a 1.6.1 sandbox game that shows the desired final configuration (it's really nifty to watch in the tracking station as the comm network lines maintain this rolling, stretching irregular tetrahedron, always completely surrounding the planet as the satellites sweep through their elliptical orbits). The state I need to get there from is simply the same thing but with all satellites having an inclination of zero. You'll find two quicksaves in there, one showing each configuration. https://drive.google.com/open?id=1Y71svhDTCd6uBXDtN0mRpcN0l1dGn3z2 Additionally, I'd be grateful if anyone could provide suggestions regarding how to determine what the minimum SMA is for establishing 100% coverage with such a constellation around other planets or moons. Even having a simplified calculation that overestimates somewhat would be perfectly useful. Finally, here are the exact orbital parameters and the thread I referenced for them (the real source, Draim's article, is sadly behind a paywall):
  14. Even the basic fly-by-wire system in AA is amazing, it's like SAS on steroids. The craft goes exactly where I tell it to and stays rock-steady in other respects. I finally got the kinks worked out of the OBS I installed (mainly an irritating hiss in my microphone input line) and got the mission recorded last night, along with a bit of description and commentary. I didn't expect the resulting video to be basically an hour long, although part of that is that KSP ran noticeably slower while recording, but it's done and the latest minor revision of the craft landed intact once again, despite a mishap at the end which nearly led to a crash for the utterly silly (silly, I say!) reason that my velocity readout never switched back to Surface mode automatically, so I thought I was going far faster than I actually was and kept trying to slow down unnecessarily! Here's a link to the video: Which apparently the forum automatically embeds! Alrighty then. It's unfortunate that you can't simply count passenger cabins, particularly those which are required to allow the vessel to contain the number of Kerbals occupying it during the ascent or descent phase, as payload mass -- it uses more delta-V to keep such dead-weight attached for the return trip than it would to drop it off in orbit, after all! And detaching components that make up more than a third of the main body of the vehicle isn't exactly something you can do with a spaceplane, and have it remain stable... or even intact. But I believe this qualifies for utilitarian credit despite that ruling, thanks to the relay satellite "payload" (which weighs less than 10% of what those passenger cabins weigh, LOL ). And it turns out that little thing could actually prove quite useful, since despite its size the satellite actually has enough delta-V to transfer itself to either moon and take up a decent high orbit, and the RA-2 antenna can provide 100% signal strength even from Minmus to a level 1 tracking station. There are links in the description of the video to KerbalX pages with both craft files, for the basic version and the one with the relay payload. I actually rebalanced the RCS thruster positions on the latter in order to compensate for the slightly heavier fairing base left behind after dropping off the satellite. It probably wouldn't make a significant difference, but it's there if anyone cares about the difference.
  15. Tallinu

    [1.6.1] CommNet Constellation v1.3.1 [27 Jan 2019]

    @Shadriss I didn't see such a question or answer when I glanced through the last few pages or the first page, and there's only so much time you can spend looking for things that may not exist. Also, since it doesn't look like anyone responded to that part: "KSP.log" is the one you'd want, found right in the main folder where the executable is. @wile1411 Thanks for linking those! That spreadsheet makes it so much easier to figure out how far you can reach with various setups -- I had no idea that you could get more signal strength than the level 3 DSN with four stock RA-100 relays! A set of relay satellites spread out in a solar orbit could extend your reach quite a bit...