• Content Count

  • Joined

  • Last visited

Posts posted by Arrowstar

  1. On 2/9/2020 at 12:05 AM, Drew Kerman said:

    here's a strange one, possible edge case. MAT files. Start with #1

    1. add a coast to ascending node
    2. convert the AN coast to UT and back off 5min
    3. add a coast to function value of 500km altitude (my comms range)
    4. add a coast to Pe
    5. add a coast to function value of 500km altitude
    6. advance script to the Pe coast event
    7. open the GA tool
    8. check the option to display Pe crossings
    9. plot and see Pe line displayed

    Now repeat these steps for files #2 and #3. Both fail to show the Pe crossing. I upped the log entries to 5000 and 10000 and still got nothing displayed. It's not like the trajectory changed much between #1 and #2 or #3

    Resolved for next release.

  2. Hey guys, just wanted to provide a behind the scenes heads up regarding some new functionality that may appear in the future if needed.  One of the things I've been dreading about KSP 2 is that I'm almost sure that bodies will have axial tilt.  If this happens, and it will I believe, then KSPTOT as it stands today would not be able to provide accurate orbit information when moving from SoI to SoI.  Over the past few months, I've slowly been incorporating the new reference frame system into various bits of KSPTOT in order to handle this.  As of tonight, I believe that KSPTOT can now handle axial tilt in the four applications where it would be needed:

    • Compute Departure
    • Multi-fly Maneuver Sequencer
    • Mission Architect
    • Launch Vehicle Designer

    There is no axial tilt term in the bodies.ini file at this time.  The code assumes at the moment that all bodies have spin axes aligned with the global [0;0;1] vector.  This can change fairly easily, though, and if it's requested, I could make it a part of the next release.

    Why is all this necessary?  Right now in KSP, all spin axes are aligned to that aforementioned unit vector.  Kerbin spins around the same axis as Duna, etc.  In KSP 2, I'm concerned this may not be true anymore.  If it does happen, then all orbit measurements which are relative to equators (inc, RAAN, argument of periapsis) would be wrong compared to what you'd see in the game.  They wouldn't be wrong outright, but the numbers would be with respect to a different reference frame, and this would confuse players, I believe.  Therefore it had to be tackled, preferably before the KSP 2 release.

    No one should see any impact to any calculation as of today.  Right now, those rotation matrices that handle the spin axis stuff are all identity matrices, so no rotation occurs.  However, if you do see something off, please let me know, as it could be a bug in the implementation.  Thanks!

  3. Hi everyone,

    Tonight I'm releasing KSPTOT v1.6.5 pre-release 8.  Here's the change log:

    • MA: Marker type for mission animator added.
    • Fix to SFS file read.  Bug was causing some vessels to not get found in the file.
    • LVD: Addition of a new propagator type, "Two Body Motion."  This change also includes a number of backend reworks to incorporate a new way to propagate spacecraft orbits and a generic interface for adding new propagator types in the future.  See discussion below.

    Okay, so what's this about a new propagator type in LVD?  Let me show a picture of the updated Edit Event dialog box to use a talking aid.


    See the new Force Model Propagator entry in that drop down menu on the right?  You can now change that to either "Force Model Propagator" or "Two Body Propagator."  What's the difference? The force model propagator is what you're used to in LVD right now.  It includes the full suite of force models that are in LVD: gravity, drag, lift, thrust, etc.  The two body propagator is strictly gravity from the central body.  Why use this propagator?  Because in cases where you really are only under the influence of central body gravity, the equations of motion simply significantly (basically, mean_anomaly_dot = n, where n is a constant) and the integration goes much, much faster.  This is a good way to speed up the long coasts around the Sun or whatnot and make the whole case run faster.

    Let me know if you have any questions! :)

  4. On 2/18/2020 at 7:53 AM, Drew Kerman said:

    @Arrowstar heads up, my upcoming mission will be exposing KSPTOT a good deal over the next several days so be sure to check it out and let me know what you think. Tell any co-workers/friends you think might also be interested! @KSA_MissionCtrl - if anyone is really against visiting or following twitter the next best place is via the Ops Tracker since the tweets load on the side with 0-30s delay

    Thanks for the visibility!  Sorry I haven't been able to code as much over the past few weeks, personal life has been crazy.

  5. On 2/2/2020 at 5:48 PM, Drew Kerman said:

    new report has to do with these SFS files - they are all roughly the same, captured within 2hrs of each other, but for all of them even on the latest PR I couldn't get MA to show all the vessels that are actually in the file when trying to import orbital data

    Is what's missing asteroids or actual vessels?  Can you give me an example of a vessel missing in one of those files?

  6. On 2/14/2020 at 1:55 AM, Drew Kerman said:

    sheeet you guys have plans for all sorts of things, I know it :P For this recent mission, there were things that went wrong where I was like "crap why didn't I think of that maybe happening?!" and it made me realize I was like dealing with 0.005% of what real mission planners have to worry about and at that point my brain almost melted (although, I'm not really too hard on myself cause I know these missions have teams of people putting their heads together)

    It's why we spend years on mission design.  We can't just YOLO our trajectories like people do in KSP. ;)

  7. On 2/12/2020 at 8:15 PM, Drew Kerman said:

    above all just don't try to be perfect. no actual space mission does perfect. They like to say they are flying perfectly as planned but in reality they are just within acceptable margins that were decided ahead of time @Arrowstar feel free to smack me down here :P

    Correct!  And sometimes not within acceptable margins lol (though we have plans for that sort of thing). :)

    23 hours ago, stankwoo said:

    Still having the same issue where once I perform the first burn the second maneuver, etc. aren't matching up with MA.

    How far off are you?

  8. @Drew Kerman, sorry I haven't had the chance to respond to your messages over the past week.  It's been a crazy few days.  I think I've addressed everything bug-related you've mentioned though and I'll post a pre-release today with the fixes.

    And here it is: KSPTOT v1.6.5 pre-release 7

    Change log:

    • LVD: Added the ability to compute the gradient sparsity to the custom finite differences gradient method, which can improve optimization speed and accuracy in some situations.
    • LVD: Added IPOPT to optimizer list.
    • MA: Resolved issue with orbital decay on coast that was breaking it.
    • Resolved two issues with MA drag coefficient calculator that would slow down the calculations in some instances.

  9. On 2/5/2020 at 11:41 PM, Drew Kerman said:

    yup, issue spam means I'm currently working on a mission! Here's a new one, found in PR2 but brought forward to PR6 and still the same symptoms. MAT file. Repro:

    1. open Set State for Orbit 2
    2. change any of the Mass properties
    3. close and note Final State lists changes
    4. re-open Set State for Orbit 2
    5. note that fields have reset to default
    6. cancel out to not save and have the bug revert values
    7. insert a new Initial State at the end, alter any of the Mass values before saving
    8. note Final State matches your mass values okay
    9. re-open the Set State that was just created
    10. note that the Mass values now match what was entered for the previous Set State event

    So we have two issues here: unable to save proper mass values (which is bad when only needing to change orbital data, now you also have to make sure to set the Mass values too) and improper loading of mass values (maybe a feature actually to carry forward values?)

    Fortunately, now that I understand the problem it's easy to work around

    Issue also resolved for next release, as well as another bug I found along the way. :)

    On 2/2/2020 at 8:25 PM, Drew Kerman said:

    hrrmmmmm unless I'm somehow being incredibly dense there seems to be a problem with the Drag Coefficient Calculator:


    It just locks up the program and never finishes computing. Same result if I select FAR modeling as well

    It looks like the way you've got it set up is causing the code that runs the drag calculations to become "stiff", meaning that the differential equations take forever to solve.  I've made a change to the ODE solver function to something that handles stiff ODEs better, but it is still going to take some time to solve.  I'm not completely sure why, to be honest.  It could be the pretty high periapsis altitude means that there isn't a lot of variance on the trajectory when you change the drag coefficient.

    EDIT: Yeah, with that it solved in a few minutes.  The answer I got was 3286.799992 though... lol.

  10. 7 minutes ago, Drew Kerman said:

    Also what in the hell is happening in that ascent figure??

    Red and blue is the main vehicle.  Green is the first stage disposal trajectory after it falls away.  Black dotted line is the orbit of the space station we're meeting up with.  This is all with the new Set Kinematic State action I added a few pre-releases ago.  Pretty neat, huh? :)

  11. 16 hours ago, Drew Kerman said:

    Ok @Arrowstar I'm going to brain dump here cause I was hoping writing it all out would make something click and turn a light on inside my head. No such luck. Maybe it will come to me tomorrow after I step away for a while. If you want you can follow along with this excel analysis sheet I made of my recent mission earlier this week. It will open to the first chart and I'll work through them in order.



    I'll take a look this weekend!  Thanks for sharing.

    In the mean time,  I do want to share a new feature that's going to be in the next KSPTOT release within Launch Vehicle Designer.  For some time now I've had the desire to be able to change variable values directly without either having to go through the optimizer or the specific UI window where that value is set.  Enter the new "adjust variables" feature, available from the Optimization menu:


    This simple UI shows you all of the variables that are currently active in your script (NOT including any you've disabled in the event listbox), the current value, and the bounds.  You can then adjust the value directly or with the slider.  As you adjust, the plot and state windows in the main LVD UI will update so you can see what's happening.  Saving will keep the changes you've made and canceling will restore the values of all variables to their original state.  I hope this feature is useful to people as they use LVD! :)

    Oh, there is another enhancement.  The variable bounds warning that you see below now shows the actual variables that are near bounds and not just the events that they're on.  Should be more intuitive to use this way.


    Let me know if you have any questions!

  12. 21 hours ago, stankwoo said:


    I was using "Minimize distance to body" similar to how the tutorial does it. I figured I would use it from the Mun to Kerbin to get as close as possible. The big difference I see is when going from Kerbin to the Mun the objective function is "minimize distance to body" and the stage is a coast to the Pe after the DV maneuver for trans Mun injection. I was trying to optimize using the same objective function but on a stage coast to SOI. Not sure if that makes a difference. 

    Is there a way I can understand why it was having a hard time using "minimize distance to body"? Or is that something you just learn over time to try different objective functions? My goal was to understand the results of the optimizer so I could know where to tweak as necessary.

    Appreciate the patience while I attempt to harness the power!

    No problem.  I don't know for sure why things behaved the way they did, but what I often find is that having constraints and objective functions that are very similar ("distance to body" and "periapsis altitude" for example), you may get funny behavior.  But as you suggested, yes, all this is really something you just learn over time.  Keep playing with MA (and give Launch Vehicle Designer a go - it's basically an advanced MA with a more powerful way to structure what your vehicle is doing).  You'll get it in no time!

  13. 2 hours ago, stankwoo said:

    Sorry, forgot to attach link earlier - here it is: MAT file

    Here you go.  All I had to do was change the objective function to Maximize Spacecraft Mass and reoptimize.  It snapped right in, so I'm not sure what the issue was, but it seems to have been solved! :)

    EDIT: Also I found a bug in MA after optimizing that is definitely in the v1.6.5 pre-releases and causes the program to crash.  I'll put out a new pre-release tomorrow with it fixed.

  14. 3 hours ago, stankwoo said:

    I really appreciate the explanation. 

    On the example mission plan it basically looks like:

    1. Coast to a certain true anomaly 

    2. DV maneuver 

    3. Coast to SOI

    4. Coast to Kerbin PE

    For the optimization, there is a constraint on step 3 above: central body ID of Kerbin and Kerbin Pe altitude of 0,0. 

    I am guessing the optimization would be set to step 3 and then "Minimize distance to body" with "Kerbin" as the body. Since it is on step 3, it will be optimizing step 1 and step 2 above with trying to get the result within the constraints (re entering into Kerbin). Is this the correct explanation?

    I will try this again tonight. My problem was I was getting a Pe altitude of 0 or close to it but my Ap was infinity. When I would upload it to KSP just to check, it showed me escaping the Mun but then also escaping Kerbin with a giant Pe. Basically not at all what the mission architect was telling me the final orbit was. That is the part I was having trouble on - using MechJeb maneuver it came up with was a Pe to re enter atmosphere and a Ap that was far away but not infinity. I'm not trying to leverage one tool against the other - just using both to learn what I am misunderstanding. (I'm positive the issue is between the seat and keyboard!)

    Thanks again for the help, this has been a great learning experience. 

    Could you please post the Mission Architect MAT file you're working on so I can take a look?  Thanks!

  15. 50 minutes ago, Drew Kerman said:

    BTW just to make sure - that Like of my post was the "cool, that's a bit involved so I'll look into it when I have more time" kind of like right? :P (press Like if Yes :D)

    Hey, yes, lol.  I finally had a chance this afternoon.  The true anomaly coast thing was a one-line bug that I fixed easily, so thanks for that report.

    About your insertion burn question: I haven't had a chance to fully recreate what you did yet.  I need to walk through your steps.  However, I would recommend allowing the pre-burn coast duration and burn attitude to be optimized, and then optimize those quantities.  Some of the disconnect between LVD and MA is probably that inertial aero angles are not really the same thing as the NTW (prograde/radial/normal) vector components, although they are close.  This may be why the MA and LVD solutions are different.  But I still need to look into it more.

    EDIT: Okay, I got it.  After you turn your engine on in event 18, create a Set Steering Model action and set it to an Inertial Aero Angles model with zeros across the board.  Do not inherit the attitude.  Set the burn duration in Event 19 to 30.478 seconds.  You should get ~700 km SMA.  I did.  Basically your burn attitude in MA was pure prograde.  Prior to this, you forgot to set your steering to be the same thing, so your burn didn't do what you expected. :)

    4 hours ago, Christopher Vaughen said:

    OMG!! That was it - just had to try the download again.  It got it - it's running - so happy!  If I download with Firefox, and then check the "unblock" box in file properties before unzipping - well that does it!!

    Now I just need to learn how to read all this stuff.  Fascinating!!!  Impressive stuff, thank you so much for making this available.

    Glad you got it working!  Please let me know if you have any questions.  The maneuver planning tools are fairly straight forward but Mission Architect and Launch Vehicle Designer are definitely complicated tools to learn.  I can help get you on the right path though! :)

    50 minutes ago, Drew Kerman said:

    I bet Arrowstar wishes more people would show off the things they are doing with it. I know I do

    lol yes, I do wish KSPTOT got a bit more exposure for the amount of work I sink into it, but I mostly do it for myself, so it's not too big of a deal. :)