Arrowstar

Members
  • Content Count

    1,929
  • Joined

  • Last visited

Everything posted by Arrowstar

  1. @Drew Kerman: Have I missed any bug reports or feature requests you've posted over the past few weeks or am I caught up?
  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. 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. Is what's missing asteroids or actual vessels? Can you give me an example of a vessel missing in one of those files?
  6. Correct! And sometimes not within acceptable margins lol (though we have plans for that sort of thing). How far off are you?
  7. @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.
  8. Issue also resolved for next release, as well as another bug I found along the way. 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.
  9. Author of KSPTOT here: Please let me know if you have any questions by posting on the KSPTOT thread!
  10. 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. 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. 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. 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. Enjoy: KSPTOT v1.6.5 pre-release 5. Change log (LVD): Resolves an issue with the true anomaly event termination condition where the directional termination was reversed from expected behavior. Added a pop out orbit display button to the main LVD UI.
  15. 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. 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! 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.