Alexandicity

Members
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Alexandicity

  • Rank
    Rocketeer
  1. 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...
  2. 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!
  3. 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....
  4. 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...
  5. 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
  6. 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...
  7. 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?
  8. 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'
  9. 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...
  10. 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
  11. 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!!
  12. 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.
  13. 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...
  14. 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.
  15. 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!