Alexandicity

ElWanderer: aah, thanks for the clarification. We fly with the navball set from the start to orbital, so hopefully we don't need to correct for this and can go direct to 6deg... We're trying to be uber-strict with the information we allow ourselves. One could argue that target velocity/distance calculations could easily be done by some nameless computer in mission control (as, presumably would things like Pe/Ap/alt etc), so I guess I wouldn't be unhappy to have this information - but then there's a practical issue of not being able to actually to select a target I guess we could install RPM and do it through that, or via the console somehow...

Ah yes - to be clear, we're not flying by eye all all: it's all in the maths. The pilot is ham in a can who points the s/c where we in mission control tells him to "Docking" with Minimus is indeed a possibility, but we'll not have target relative velocity information until we're in the SoI. It's also a pretty fuel- and time-inefficient. Minmus SoI is quite a small target so we may find that no matter how good our TmI burn is, we may struggle to hit it. In this case, we'll need to do corrections and the only way we (currently) have for that is the way you describe. Out of interest, ElWanderer, why that extra half degree in your heading targets? For launch, we've managed to get <1 degree heading error by simply reading out heading corrections to the pilot while launching. Seems to work fairly well! It's just that timing we're having trouble with. I guess we could go map mode just for launch, but we're hoping to get a specific time if we can. The longitude we're getting is surface longitude. I think what we need to construct is a local time -> orbital longitude conversion. Fortunately, I just found this by user Dib, which does just that I'll have to give it a whirl but it seems sensible to me. Thanks for your thoughts both!

Hi! Some friends and I are trying to fly to Minmus manual mode IVA without map view. We're therefore needing to plan out all our manoeuvres ahead of time. One that is giving us difficulty is the plane correction. We launch equatorial, but need to correct to a 6deg inclination to match Minmus. The burn itself is easy enough, but getting the timing right in order to be co-planar is problematic. We are using telemachus to give us telemetry (aka API access!) and so can see our various orbital parameters. We know that we need to burn at the ascending node - and we have the longitude of this relative to an arbitrary reference line. However, we're not sure how to see our vessel's own longtitude as measured from this same reference point. The longitude offered by the api/telemetry appears to be relative to the orbited body's prime meridian, which of course is rotating in inertial space. Looking at wikipedia, it seems that the way to do it is to take our argument of periapsis, and when our true anomaly is the negative of this, we make the plane change. We'd do this twice: once to correct launch errors (using the vessel LAN, INC->0), a second time to match minmus (using the minmus LAN, INC->6). Does that sound right? Is there any way to time a launch such that we can insert directly into a minmus plane (applying our inclination burn during launch)? Without an orbit, we'd not have a true anomaly or AoP, so we'd not know when we were at the LAN/when we were coplanar with minmus....

Long time ScanSat user here (although not played KSP nearly enough lately!). Some friends and I are doing a Mission Control challenge soon and I want to integrate SCANsat into the gameplay. Our "mission" is to go find an anomaly and land near it. Of course, we want to locate out target using SCANsat but we want the resulting maps to be visible to the "mission control" team, outside of KSP. Other telemetry we'll get through Telemachus, but I'm wondering - does anyone know if SCANsat maps/data can be accessed outside KSP? Ideally via a telemachus frontend, but opening a file in the KSP/mod direction or some other method would be OK too...

Hello! Big fan of this mod; been using it for a while and I think it adds great richness to the game. So thanks for that Has there been any discussion of incorporating some of Capt Snuggler's collected ideas into this mod? http://forum.kerbalspaceprogram.com/threads/67240-Map-view-satellite-mapping-and-how-it-should-work Basically, he suggests making mapping a more critical prerequisite to landing etc, which I think would be an excellent addition. Ignoring the part about the telescopes (which isn't mapping so much), one "elegant" way to incorporate would be the change the texture of a body in Map view to some "blank" texture by default, and then, as mapping is done, use the revealed map image as the texture. Effectively, as the satellite maps, the revealed terrain would be drawn on the body itself (rather than the Big Map window). The non-mapview I would expect to remain unchanged from the regular texture. Apologies if this has been discussed before - I couldn't see it earlier int he thread but it is a long thread

Seems there's lots of love of the biomes I agree that there should be lots of opportunities for trying different things and lots of biomes is the way to do that - I'm just proposing they get differentiated a little more. Even if you didn't actually reduce the number of biomes on a body, the other argument to make them substantially different I think is still interesting. Some really rocky, small or elevated ones would make you need to think more carefully about how you'd need to land at each one. It would provide a (slight) progression f difficulty to keep the challenge fresh. I think this is what you're thinking, Geb? I also enjoy large complex mothership missions with docking and mobile labs, but I have always associated these with more distant destinations (Joolean system, usually!) where the trek back and forth really is a slog. Getting to the Kerbin moons is pretty quick and easy, so for me there's never been much temptation to go through the complexity of building a large "all in one" mission. That said, I could try it for the lolz...

Hello! I was thinking about the biomes on the Mun as I attempt to rescue the brave crew who got stuck after my 6th landing. It seems to me there are "too many". Arguments I know go back and forth over the merits of science grinding, but I think there are an awful lot of biomes on the Mun that don't provide too much additional gameplay value. Usually, when you've done one, it's a rinse-and-repeat to get the rest. In my mind, you could on each body get away with just three: Easy Biome - typically flat landscape, near equatorial and low in elevation when the body has an atmosphere. These would be the easiest to get to and the usual target of the first landing. This biome would be the majority of the body's surface most likely.. Hard Biome - typically hilly landscape, much higher latitude and more elevated. This would provide more challenge and probably require an upgraded craft. Pinpoint Biome - could be anywhere, but very small - no more than 100m across. The motivation for these is to provide a reason to use a rover (which always seemed a little pointless to me?) to drive the last km from your landing point. Alternatively, if you hate rovers, you could use it to justify a hopper craft or a most excellent precision landing. These could be found marked by anomalies, which in turn would be found by a mapping mod or good old fashioned anomaly spotting. To balance the reduced number of places to do science, the points for each would be increased accordingly. Three (or some other similarly small number) of missions would be enough to get all the science from a body, but would nonetheless provide increasing challenge and difficulty, rather than the fairly repeated missions we do now. With more bodies getting biomes, this would seem even more important. What are your thoughts on reducing the number of biomes? Has it been discussed previously? Is there perhaps a mod already that does such a thing that I may have missed?

Always love to see data! Some comments on these graphs if I may * Units! Label the axes so we are completely unambiguous about what data is being presented. * Some more commentary on how we could use these would be nice. For example, the first one - I'm not sure how I can use this data to help me. Ultimately, any engine can lift any mass, if there's enough of them. I presume what you're getting at is at what mass the S/C's TWR (Thrust-Weight Ratio) becomes less than 1 (i.e., won't take off on a given body vertically), presumably on Kerbin. * On plots #2, 3, 4, 6, 7 and 8, it would be good to add text to the pots themselves (as you do in #5 and #9) as the sheer number of colours makes it hard to tell which is which. Also, I'd get rid of the 3D effect; as it is purely cosmetic. * In a similar line, the 3D plots of #5 and #9 are inappropriate for the data being presented. A 2D graph with many lines on it would be better (ie., this one as viewed from the side, as it were). A 3D plot like this is only acceptable if the engines were continuous data; but engines types are not (they are categorical data)... Keep on plottin'

On thing to consider is not shorten your lander - which is difficult - but to fatten it. This has the benefit of being easier to land and looks, for a constant height, less "tall"... But yeah, funny-looking spacecraft do emerge from KSP. And in real life, in fact; before the Apollo LM was built the popular imagination wouldn't have thought a lander would look all spindly like that Turned out the best engineering solution isn't what we might originally expect...

Thunder Aerospace Corp's Life Support mod meets this description, or at least the first half of it. Not sure what you mean running on an extra core - you mean a separate thread on your PC's CPU? Usually, mods like life support don't add much in the way of processing time so I don't think any of them would go out of their way to implement this (not to so they haven't - I'd just be surprised ). http://forum.kerbalspaceprogram.com/threads/40667-0-23-WIP-TAC-Life-Support-0-8-22Dec

If all else fails, you can send a manned crew to your satellite. A Kerbal on EVA can manually point the antennae of a dead satellite (they can also activate them), thus giving it a connection and life. A nice touch that adds to the utility of humans That said... a mission to the sun - it may be too hard to get a crew to the satellite!!

I'm loving this storyline Surprised at how far it's come from such humble beginnings. Excellent Kerbalship. Keep it up! For the planet mission, if landing is difficult, might it be an idea to fly into a planetary atmosphere, enjoy the view etc, then return to orbit without ever landing? All the fun of flight, without all the messy "ground" stuff.

I agree, you can do a Eve or Duna mission, even manned, without Mainsails or Skippers. The craft you used for your mission to the Mun (which seemed to be a return?) might well have enough Delta-V without further change... You could follow a historical a path to get that (small) amount of science you need to get these engines though: just try a flyby. Get on a path for either planet and, as you zoom by, do orbital science. You'll have plenty of time to get and transmit science from the SOI when you enter it, and if you are close enough (200km or something) from either planet you can do it again to get the "near space" science also. Or just plummet into the atmosphere (with a few 'chutes!!) and get the atmospheric science (as you burn/float down) and land science) without any further delta-V cost...

Just for background, the manoeuvre they're describing to "catch up" when you are trailing (or leading) another spacecraft in the same orbit is known as Orbit Phasing.

Maybe I missed something, but why no solar panels? I see no reason you couldn't slap a couple on the side of your craft. Even the single-pane fixed panels would be more than enough to power you!

Well, it's not quite a linear response. You could have a huge TWR at liftoff but that would be bad, because you'd accelerate too fast too soon. Conversely, too low and you're in the gravity field longer than necessary. If the atmosphere was constant, there would probably be a value, maybe like the 1.44 you found, that is optimal. However, the atmosphere isn't constant, and the fact that your craft becomes lighter as fuel is burnt (increasing TWR), means there isn't a single TWR that is good for the full ascent. I'm not sure, since I don't usually do TWR calcs, but I'd guess that you want a high TWR at first, but have it drop fairly quickly to something lower. Maybe someone else more familiar with TWR optimisation can confirm! Also worth noting that your drag - which will also affect max altitude - is likely to vary between the various test crafts you built (unless you compensated for that somehow?). All in all, however, good to see such experimentation! It's a complex problem but nice to see the methodology being applied! Would you mind posting your data?

Yes, I had the same problem not long ago. The tree structure imposes some restrictions, but seems a decent choice for most Kerbal endeavors. If you want to create something that "looks" to have the loop, like your example in the first post, build it as you did. The last truss won't connect to the first tank, ok, but it will look like it does. Structurally, throw a whole bunch of struts in place to hold everything in place.

I'm looking to do something similar myself soon so I'll be watching for replies here! Two ideas I've seen tossed around before: * Put your thrust at the front of your platform (so it "pulls" the assembly). Apparently this is more stable or something? * If the oscillation is definitely coming from the docking ports, use triple-docks and/or quantum struts (mod); both of these give rigidity. Maybe someone else has hands-on experience with these can comment?

For vehicles that are not very close to each other (and so you get an error message when you use [ and ] ), go to the map view and right-click the vehicle you want to control and select from there.

I too would suspect the planet rotation that SRV Ron suggests...

Sorry, there's an AGL altimeter somewhere? As opposed to an ASL one? I have a huge problem with this, to the point I ignore the altimeter completely unless I'm landing in the ocean... is there a way to get distance above the local ground level?

Hi Jumpster, Yup, I think you're thinking the same as me.. there are some configurations to be played with! I will need to try them all...

Hello - thanks for the responses! Amoun: Your second interpretation sounds about right. Four decouplers, one to each pod, support the middle section, which can be completely released (leaving a "hole" in the middle). This works well at the moment The question is... can I get the four pods to stay together when the middle section - currently the only "true" (non-strut) part holding them together - is decoupled. Kasuha: I understand your explanation of the tree - makes perfect sense. I think I also get your idea of the docking port - basically, build two technically different, half-ring spacecraft, and have them immediately mate. Intriguing. However, I suspect a full circular logical ring isn't needed - if I can make a branch that wraps around the central section (joining the four pods with three links), I can get all four pods to be attached to the tree without linking branches. The structural stability I can achieve by putting struts between the first and last pods in the tree So the tree would look like: Nosecone | Pod 4 | Pod 1 || | / || || Central Section || || | || Pod 3 ========|======== Pod 2 | Launcher stages (In this, a single line represents a decoupler, a double line a fixed link like a girder or truss). When landed, Pod 1 decouples from the central section, releasing it from the entire ring of pods, which remain still attached. Difficulties from this approach are it's messy: unbalanced and requiring some delicate placement of pods around the centre (rather than symmetry-attaching them). I will experiment tonight and see what I can achieve. I will use lots of struts to hold Pods 1 and 4 together (creating a mechanical, if not logical, ring) and to support all four pods to the central section (which otherwise would all be dangling off a single decoupler!) Phew - hard idea to convey in text! To put my diagram above in context, the existing lander I have now (that falls apart on decoupling the central section) is: Nosecone | Pod 4 | Pod 1 \ | / Central Section / | \ Pod 3 | Pod 2 | Launcher stages And what I would ideally want, but is not possible in a tree, is: Nosecone | Pod 4 ========|======== Pod 1 || \ | / || || Central Section || || / | \ || Pod 3 ========|======== Pod 2 | Launcher stages

Hellos! I have become a KSP addict... can't stop thinking about it!! I have general purpose Munar lander. It consists of a large radius central section with four normal radius tank/engine/leg combos on the four sides. It flies and lands well. I sling rovers below, and ascent stages above, the central section. Very similar in style to this (but with four rather than six radial tanks): (credit: Roboray) Now I want to make it land me heavier, larger payloads (base sections, large ascent modules etc) that would constitute the whole of the central section. This actually works as well; I have radial decouplers that can detach the four side engine assemblies from the central section that is then free to do what it wants. When I do so, all four side modules break off and fall to the ground; the struts between them disappearing (presumably because there are no "real" parts between them). That they fall to the side into a pile of rubble isn't a problem most of the time. But now I want those four side engines to stay together even when the central section is detached and removed. With the ring of four engines, I can fly away, leaving the payload where it landed. Or the lander can remain as an operational base once the crew has left. Presumably, to do this, I need to have "real" parts running between the four radial tanks. So, the question is: how do you attach off-axis things together in the KAB? If I use a truss or girder, I can attached it to one side; but it's never the right length to intersect the neighbouring tanks.. Even if it was, how would I make sure that both sides of the girder are attached (as opposed to the one side I positioned with)? Hope that makes sense; a little hard to explain!! It's been infuriating me for ages