Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Arrowstar

  1. The easiest way to do what you want is to just open up the Porkchop plot generator and paste the UT time into the Earliest Departure Time box. It'll show the Year, Day, etc immediately below that box when you do.
  2. Usually if you right click a time related text box, you'll see an option menu that has an option for converting a KSP date to universal time. If you don't see anything, can you share which text box it is that you're looking at? Yes, it absolutely can. You would use Launch Vehicle Designer (LVD) for this work. Please let me know if you have any questions, and sorry for the delay in getting back to you, it's been a busy few months.
  3. I've recreated the bug and I believe I've got it figured out. I reuploaded the PR7 ZIP file. Please go ahead and redownload that and let me know if you have any issues going forward. Thanks!
  4. Today I've built KSPTOT v1.6.10 pre-release 7. This pre-release adds a bunch of new functionality and includes some bug fixes and minor performance improvements, all of which are in LVD. Here's the change log: Noticeable performance improvement when using numerically propagated celestial bodies. LVD: Added new ground track tab to main LVD UI's display area. LVD: Added sky box code for more "cinematic" display of 3D trajectories. Set option to enable in View Settings. LVD: Added additional camera controls functionality (Dolly horizontally/vertically camera). LVD: New steering model: tabular quaternion interpolation. LVD: New throttle model: tabular throttle interpolation. LVD: Update version of IPOPT optimizer to v1.1.6. LVD: Add new SQP optimizer algorithm. LVD: Bug fixes and performance improvements. Please let me know if you find any bugs. Thanks! Happy orbiting!
  5. No, this is a new one certainly. Can't say I've seen this before. I'm going to push a PR7 out pretty soon (maybe even tomorrow), so can you let me know if the issue persists with the new build? If it does, I'll investigate further. Thanks!
  6. Ah, I didn't realize you were using Principia. In that case, yes, you can turn on the n-body calculations for the celestial bodies as you had it. Just realize that it's going to be very slow. Sorry about that.
  7. Ah, no, sorry, I think I see the confusion. Numerically propagating the orbits of the celestial bodies is NOT the same as using n-body gravity on your spacecraft. To enable n-body gravity, you need to do the following: In your initial state, set the bodies you want to use for 3rd body gravity. For each event, set the Force Model to use 3rd body gravity. That should be all you need!
  8. Honestly, just leave the numerical propagation to two body for everything. Your simulations will run much faster. You typically want to scale your objective function so that the value is between -1 and 1. Since final vehicle mass is the objective function, and the final vehicle mass is around 4, a scale factor of 10 is appropriate since it'll make it 0.4, which is between -1 and 1.
  9. You had a couple of issues that I was able to resolve: 1) You had numerical propagation turned on for all your celestial bodies. That's much slower than the two-body analytic solutions and was causing the propagator to take forever. I had to change things back to analytic two body propagation. 2) I scaled the constraints by their current value (Optimization menu -> Scale Constraints -> Current Value). 3) I scaled the objective function by 10. Once I did all of these, the optimizer brought the solution in easier and quickly. Here's the file. Please let me know if you have any questions with anything I did! Happy orbiting! https://drive.google.com/file/d/1t9DxXgP46S7R3gHbPCPeSpExvdcHQHFy/view?usp=sharing
  10. I have access but when I try to load your MAT file I'm told that it's not a binary MAT file. Can you try again? EDIT: Nevermind, seems like it works now.
  11. It can, but I'd still highly recommend using LVD. Did you try scaling the constraints as the text box message that pops up describes? Can you share your MFMS output with me so I can take a look at it and see what's going on? In other news, work on the new optional sky box functionality for LVD is progressing nicely. No more grey axes boxes if you don't want them!
  12. I've been working on a new display for Launch Vehicle Designer (LVD). This is a new ground track display that can show the following on a 2D map of a celestial body. This display is located on a new tab in the Display area of the main LVD GUI. Vehicle trajectory Ground object location and trajectory Celestial body location and trajectory Terminator line between lit and shadow (day and night) portions of the celestial body Terrain contours (may be turned off and off in View Settings) Here's a great image of Duna that illustrates these new functionalities. You'll also notice that the tool tips on this display are much richer and show more useful data. This is true for the 3D orbit display as well! This will show up in the next v1.6.10 pre-release. Let me know what you think! Happy orbiting.
  13. Hi everyone, I'm happy to announce that after a fairly lengthy hiatus, I've built KSPTOT v1.6.10 pre-release 6. This new build moves KSPTOT to a new MATLAB version, MATLAB R2023b. You will need to download and install the MATLAB Compiler Runtime version for R2023b to run this build. Please do so before attempting to run KSPTOT v1.6.10 PR6. Here's the change log: New MATLAB Version: R2023b LVD: Update NOMAD solver to v4.4 and removed v4.3.1. LVD: Enabled DiscoMADS option for NOMAD solver. MA/LVD: Updated the optimization variable plot mouseover label background color to be not transparent. LVD: Run Case Matrix workers now record diary as they run to a "running" log file. LVD: Updated tab order for initial state and set kinematic state UIs. LVD: New example: lvdExample_MunarFreeReturn MA/LVD: Many bug fixes. Please let me know if you find any issues. Thank you and happy orbiting!
  14. Just a heads up to everyone, the next pre-release will probably update MATLAB to R2023b (the latest version). It'll also have an updated version of the NOMAD optimizer (v4.4) in LVD, along with some other changes.
  15. I actually couldn't reproduce this error. Does it still happen for you? Propagating to certain "events", like true anomaly or whatnot, doesn't work as well in the integrator based system that LVD uses. This is why everything is time based. Set up constraints to the target you want at the end of an event and then optimize the propagation time of that event to meet those constraints. This should work out pretty well most of the time.
  16. Hey, sorry about taking forever to get back to you. Between Christmas and New Year's Day I've been pretty busy recently. You've basically got the idea on point 3 about updating the state. Once you're in between major bits of the mission and you're just coasting along, you can remove the previous segments and update the initial state to match your current state in the game via importing it (right click in the Initial State dialog box). At that point you can add maneuvers for corrections and stuff like that. I think there's an "advance to segment" option in the right click menu of the script listbox that helps make some of this easier! Does this help any?
  17. I don't have the skills for that, but if anyone would like to give it a go, they are welcome to let me know and I'll help with info as I can.
  18. Hey there, that warning just means that the mission needs to be run first. It's not really an error and it doesn't imply that anything is wrong. That said, I'd encourage you to use Launch Vehicle Designer (LVD) instead, since it's a far more fully featured and robust mission planning tool that works for both launch vehicles and spacecraft. I haven't really maintained MA in a number of years now aside from a bug fix here and there.
  19. Hi everyone, Tonight I've built KSPTOT v1.6.10 pre-release 5. There are a few new features I want to discuss in this release before I get to the change log. These are all Launch Vehicle Designer (LVD) related. First, body (meaning "spacecraft") angular rates are now available to be used as Graphical Analysis tasks and as constraints as well. Second, there are a variety of new actions you can apply to events. These are: Set Plugin Variable Value: Sets the value of a "plugin variable" to a particular constant number. Example: Value = 5 Add Value to Plugin Variable Value: Sets the value of a "plugin variable" to itself plus or minus a given constant number. Example: Value = Value + 5 Set Plugin Variable Value to Quantity: Sets the value of a plugin variable to the value of a given graphical analysis task quantity. Example: Value = Altitude [Kerbin Inertial Frame] Set Next Event: Sets the next event to be executed to a given event. I'll get to why this is relevant more in a bit. Third, there is a new Conditional Action. A conditional action is an action that lets you set the conditions by which a group of actions may or may not be executed. The action is structured in the same way that an "if-else if-else" structure written in a programming language. Let's walk through the UI. The upper section, the "IF" section, is evaluated first. If the condition on the left is true, then the actions on the right are evaluated. The middle section, if "ELSE IF" section, is evaluated next if the IF condition returned true. You can have as many ELSE IF conditions as you'd like, each with their own conditions and associated actions. If none of the previous conditions returns true, then the "ELSE" actions are executed, if any. Conditions are edited through their own UI. Most conditions will be based on Graphical Analysis task quantities, but there are also AND and OR booleans that let you chain conditions together in a very flexible way. The best part about this is that you can use this, combined with the new "Set Next Event" action, to create conditional, branching trajectories. I've done this is the example UIs that I've been showing here. Note that the "quantity comparison" conditional can compare one quantity against a fixed, constant number like I'm doing here or against the value of a different quantity at that same point in time. This is particularly useful for comparing the values of Plugin Variables, which are really now great places to store numeric data that you might want to compare against as you propagate your trajectory. Anyway, that's the main gist of things! Here's the full change log. LVD: Added new polling and search methods for patternsearch(). LVD: Warn/alert area is now a UI table. The KSPTOT main GUI has been replaced with something that is much more visually indicative of what functionality KSPTOT has to offer. KSPTOT UI now supports theming of the colors of all UIs. Access from the new main GUI: View -> Edit Themes and View -> Set Theme. New icons for KSPTOT and various KSPTOT tools and applications. There is also a new splash screen shown when loading KSPTOT. LVD: GUI areas for initial/final state is now a text area so it can scroll. LVD: Added body angular velocity Graphical Analysis tasks. LVD: Added body angular rate constraints. LVD: Added conditional action. LVD: Added Longitude termination condition LVD: Added Add value to plugin var value action and other similar actions. LVD: Added Set Next Event action. LVD: Actions are now sorted alphabetically. Fixed bug with Select Departure/Arrival Date button in Compute Departure stuff. That should be it! Let me know if you have any questions or find any bugs! Happy orbiting!
  20. Open up this MAT file in LVD. It should be the optimized trajectory you're looking for! https://drive.google.com/file/d/14co-L5ztASEKLreLAskrx9YM7Pf1bY2g/view?usp=sharing
  21. Can you share a screenshot or the LVD MAT file? I think I misunderstood at first. I was thinking you were asking how long it took to generate the MFMS data file for LVD. The actual optimization of the trajectory in LVD could take some time, yes.
  • Create New...