Jump to content

timchap

Members
  • Posts

    9
  • Joined

  • Last visited

Reputation

4 Neutral

Recent Profile Visitors

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

  1. Awesome. Let me know if there's any compatibility issues with planet rescaling - like I say, it should work, but you never know...
  2. Those suicide burn calculators only work if you're descending directly towards the body. Mine works for any suborbital trajectory, which is (though I do say so myself) a much more difficult problem. On top of the standard dynamics of the problem (e.g. changing fuel mass), you have to 2 dimensions to deal with instead of one AND (most importantly) the changing terrain height over the course of the descent.
  3. It should do. Benefits should roughly scale with overall dV required to land. It's all relative, anyway - it really depends on how good your manual landings are. When I've tested it I've typically saved anything from 100-200m/s on the Mun (where the descent itself is a few hundred m/s) to upwards of 500m/s on some Tylo descents. Basically, this mod allows you to time your retrograde thrust perfectly so that you come to a stop just above the surface. If you manage to luck out and time it perfectly on a manual descent you'll get exactly the same delta V result. If not, you'll either crash or lose a few extra dV in the final descent (when you realise that you're going to stop short and you throttle back). Timing it perfectly is a lot easier when you (a) are moving slower, and (b) have a higher TWR, so this mod will probably be more "useful" in a rescaled (bigger) system. In fact, the idea for this mod was initially conceived when I was trying to land on Tylo with barely enough dV. I basically quicksaved and then repeatedly attempted the descent, changing my thrust start time each time. If I crashed, I knew to try a bit earlier. If I ran out of fuel before landing, I knew to try a bit later (or I just didn't have enough dV). Unfortunately, I quickly realised that when you're moving at 2000m/s towards the surface, missing your thrust start time by even 1 second means that you will over-or under-shoot the surface by 2km. To that end, I made a mod that would (a) effectively simulate all those successive descents for me, and (b) start thrusting at exactly the right time. tl;dr Try it in a rescaled system, it should work and it'll probably give you more dV savings than in the stock system.
  4. Alright, sorry about the delay. New version available at the link in the OP. Changes include: Added required dV to the post-calculation window Added predicted landing coords to post-calculation window. I will continue to look into marking the landing spot in map view Added option to change all gimbals to a given percentage in settings menu (a bit clunky but hopefully self-explanatory) Minor bug fixes Haven't tested these additions extensively so let me know how you go.
  5. Thanks for the recommendations! I'll have a release with (1) implemented for you shortly. Don't know why I didn't do this already. I agree (2) would be handy, not so much for RCS (is there any reason you can't just use the action group?) but gimbals can definitely be annoying. (3) would also be very nice, I can get the coordinates pretty easily but I'll have to look into marking the landing spot in map view or something.
  6. Hi there! Have you ever injected from solar orbit into a highly horizontal suborbital trajectory towards a huge lumpy rock, and wondered... ...What is the most delta-V efficient way to bring my vessel to a safe landing? Well, wonder no more! Download Source As you may be aware, the delta-V-optimal way to come to a stop over a non-atmospheric body is using 100% retrograde thrust (relative to surface). However, begin thrusting too early and you will come to a stop with a long way yet to fall - on the other hand, begin thrusting too late and you will find that the surface forcibly assists your deceleration. Finding the perfect balance is a mathematically non-trivial problem. To this end, I have developed a successive approximation numerical landing solver: the Improved Non-Atmospheric Landings (INAL) mod, which allows you to pull of scary-ass landings like this: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ How to use it: Other recommendations for use: Current issues: Changelog: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Other than that, please experiment with this mod and test its limits! Bug reports, suggestions, support, and feature requests are welcome in this thread, however this is my first-ever software release of any kind so I'll do my best but no guarantees. Oh, and I'm also accepting better names for the mod. Enjoy!
  7. I'm working on yet another landing guidance plugin. I'm almost ready to share an early version, but I'm having trouble with the coordinate system. In particular, I'm trying to find the latitude and longitude of the active vessel on its current orbit at some arbitrary time in the future, taking into account the rotation of the planet. The code looks something like this (with a nod to KER for inspiration): Vector3d position = vessel.GetOrbit().getPositionAtUT(currentTime + deltaT); double bodyRot = 360 * (deltaT) / body.rotationPeriod; double lat = body.GetLatitude(position); double lon = NormAngle(body.GetLongitude(position) - bodyRot); //NormAngle normalises the angle between -180, 180. When I continue on the current orbit and sample the actual lat and long at UT = currentTime + deltaT, I find: a ) Lat and long are both a bit off (0-2 degrees), thought long is usually more wrong than lat (possibly suggesting that my bodyRot is incorrect). b ) The error is greater the further in advance I try to calculate the lat and long (if I calculate no more than a few minutes into the future the error is negligible). I suspect that my understanding of the value returned by Orbit.getPositionAtUT() might be incorrect. It seems to return a value which is sort of "the position that the vessel would be in at time UT if the main body stopped moving", which I think would make my logic consistent. But either of those assumptions may be wrong. Can anyone offer any advice, or an alternative method?
  8. @TheCardinal, good thought RE performance concerns. Your thoughts on (2) are noted, that'll probably be an easier place to start anyways.
  9. Hi all, Long time player/reader, first time poster. I'm keen to get into modding and I've got a couple of ideas that I think would be neat. I'm seeking the following feedback: (a) Do other people think the ideas would be cool and/or useful? ( Can any experienced modders point me in the right direction to get me started? I've read (and am fairly comfortable with) lots of the general modding material, but I'm still not really sure to start with the first idea. © Have these mods already been created? The two concepts are as follows: (1) A mod that allows idle Kerbals to perform some scripted walking around and/or other activities when they are standing within some range of the active vessel (or other Kerbal). An explanation: it detracts from the immersion for me when I have a bunch of Kerbals standing around some planetary base, but they are all completely static. (2) A mod that allows RCS-powered vessels (including Kerbals) to be controlled relative to another orbital vessel. I don't just mean that the directional controls are aligned relative to to the vessel (as they are when you set a docking port as target), but also so that the RCS vessel comes to a stop relative to the other vessel when the WASD controls are idle. I feel like this would make it way easier to whizz around orbital stations on EVA. Keen to hear your thoughts!
×
×
  • Create New...