Jump to content

Arrowstar

Members
  • Posts

    2,559
  • Joined

  • Last visited

Everything posted by Arrowstar

  1. Unfortunately this is impossible. Between the UI and the backend code, KSPTOT is nearly 100k lines of code. A rewrite just to go to another language with no additional benefits would take years of no added value.
  2. Hi everyone, I found a somewhat important bug in the latest release of KSPTOT. Within Launch Vehicle Designer, if you don't have any tank to tank connections or engine to tank connections, and you try to set the initial stage states of the vehicle from the Initial State menu dialog box, you will get an error. I've hotfixed the release from yesterday with a patch and re-uploaded. If you downloaded v1.6.2 between last night and now, please re-download to avoid this bug. Thanks!
  3. Not expected, but also not a big deal. (I've never seen it before either lol.) That call to "getDefaultLvdData" shouldn't be there anyway, it is from a time when LVD was going to be a part of Mission Architect. Looks like I forgot this one spot. Anyway, you can ignore it for now, and the offending call has been removed for the next release. Thanks for the find!
  4. Good evening, everyone! This evening I am happy to announce the official release of KSP Trajectory Optimization Tool v1.6.2. As with the previous release, this release primarily focuses on additional improvements to the Launch Vehicle Designer (LVD) tool. LVD is now faster, more robust, and contains an even greater set of tools for analysts to use when designing any sort of trajectory, from an ascent into orbit, to a trip to the Mun or other celestial body, and back again. Also making its debut in this release is the new Linux version of KSPTOT! If you've been looking to use KSPTOT but lack a Windows PC, now is your time to shine. Mac users can additionally take advantage of KSPTOT now by running the Linux version in a Virtual Machine. See the install instructions in the OP for details. Here's the change log: New Linux Version of KSPTOT! Added new "two body time to impact", "impact latitude", and "impact longitude" tasks to LVD's Graphical Analysis tool. Added new "tank mass flow rate" task to LVD's Graphical Analysis tool. Added checkboxes to show SoI radii and body children on the main LVD UI. These work identical to those in Mission Architect. Added ability to test an LVD event with all possible integrators to see which one runs the fastest. Accessible from the LVD Edit Event dialog box. Added the ability to set the width of plotted trajectory lines in Mission Architect and Launch Vehicle Designer. Added ability, in Launch Vehicle Designer, to create "Tank to Tank" connections that allow flowing mass from one tank to another. Useful for basic life support modeling or modeling propellant refueling. Added ability to see SoI transitions in LVD's Graphical Analysis tool. Added ability to define fluid types and assign those types to tanks. Now tanks that hold xenon or monopropellant will not have their mass accounted for as "Liquid Fuel/Ox." Added a new LVD Event Action: "Reset Extremum Value." Allows for an extremum to forget it's value in the middle of a mission so that it can be reused accurately later on in that same flight. Reworked the Mission Architect Insert/Set State user interface to be less tall and wider (fits on lower resolution monitors better). Many bug fixes and LVD script execution performance enhancements. As usual, the download is available in the first post of this thread. If you have any questions or discover any bugs, please drop me a line in some fashion to let me know and I'll do my best to address it! In particular, it would be great if those using the Linux version could provide any feedback on how it's working out. There are some known graphical issues, but those aside, if you discover any bugs that appear to be Linux-related, please let me know. Thanks! Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire. In any event, I hope you all enjoy! Happy orbiting! PS: Could someone on the Linux side please check the install instructions on the first post of this thread to make sure I got the correct? @russm maybe?
  5. @russm and @CraigCottingham are there any other instructions I need to include to get the linux install working besides the chmod instruction and MCR install directory instruction?
  6. A new pre-release build, KSPTOT v1.6.2 pre-release 6, should solve this issue with the Set State UI. Can you test and see if it works for you on your setup?
  7. Hey everyone! This post is only tangentially related to KSPTOT, but is something I wanted to share. A number of people have very generously donated to my Ko-Fi account listed in the first post of this thread. While I don't think I've ever stated as such, I have been mindful of the fact that I would like at least some of those funds to support the future development of KSPTOT. I consider that to be one of the priority uses of that money. My current PC is about 6 years old, and this is the machine that I develop KSPTOT on, among other activities. When I first bought it, I did my best to future proof it as much as possible, and I picked up hardware that has lasted reasonably well. However, since starting the development of the new Launch Vehicle Designer (LVD) tool, I've been running into situations where my PC has been dangerously short on available memory. Ever seen your RAM usage get to 98% or 99%? I did when I started compiling KSPTOT for Linux inside a virtual machine lol. The major downside of this is that Windows starts using virtual memory on my HDD hard and this really slows the whole system down. Not surprisingly, it has been clear for some time now that if I wanted to continue productively working on KSPTOT on both Windows and Linux, I was going to have to do something about my RAM problem. Tonight I've finally solved the issue. I picked up 16 GB of G.SKILL AEGIS memory and dropped it into my PC tonight. I can already tell you that it is making a world of a difference. I can now easily run MATLAB/KSPTOT on both Windows and Linux simultaneously (with room to spare!), which really speeds the process of writing code, debugging it, and building the executables that I push out to you, the KSPTOT community, in the form of releases and pre-releases. Everything is buttery smooth. The total amount donated to the Ko-Fi account to date is about $81 (less fees) and the RAM I picked up was about $75 or so. Basically, everything you guys have given to date has been put towards making the KSPTOT dev experience a bit easier and less of a headache. Thank you so much for making that possible (it wouldn't have been without you). It is very, very awesome of all of you and I appreciate it from the bottom of my heart. Happy orbiting, and thanks for being a great user community!
  8. Hi everyone, One final feature before the KSPTOT v1.6.2 update drops later this week. Someone a while back asked me about allowing names to be changed in LVD for the various types of mass you can hold in tanks. I've implemented that. See the state readouts in this LVD UI: You'll notice that the Monoprop and Xenon masses have been replaced with O2 and C02 masses. You can also have more than three fluid types: The first three will show up on the state displays as normal. Fluid types beyond the first three will get lumped into the dry mass so that the total vehicle mass remains consistent. (This is for some MA backwards compatibility.) But here, for example, you could add back monoprop, and "food", and other such resources whose mass change during the mission. These can then be coupled with the new ability to transfer mass to and from tanks (where it's converted from the old type to the new type of mass) to better simulate a simple life support system. Thoughts? Possibly. Which windows are you having trouble with? What height would they need to be to be usable? It's already in there actually. MA Menu bar -> Script -> Execution Settings -> Parallelize Script Optimization
  9. Hey everyone! This afternoon I have built KSPTOT v1.6.2 pre-release 5. This is a fairly important build with some nice new features. As with the previous pre-releases, both Windows and Linux builds are available here. Here's the change log. Most items are related to Launch Vehicle Designer unless specified. Added tank flow rate Graphical Analysis task. Added ability to test an event with all available integrators by right-clicking the integrator dropdown menu (in the Edit Event dialog box) and selecting the appropriate menu item. Shows how long all integrators took to process that event and allows selecting the fastest one immediately. Added line width to all Mission Architect and Launch Vehicle Designer UIs that generate a plotted trajectory. Added Tank to Tank Connections that can flow mass from one tank to another tank, from an external source to a tank (mass creation, like mining), or from a tank to an external sink (mass overboard, like venting propellant). Added back the "Show SoI Transitions" option to LVD's Graphical Analysis tool. Minor performance improvements and bug fixes. Please let me know if you run into any troubles or bugs, especially with the new tank to tank connections. Thanks, and happy orbiting!
  10. Sounds good, thanks for looking into it for me! Yes. For a rough cut that's pretty good, use the Rendezvous Maneuver Sequencer. It will have drop downs for the orbits of the various planets and moons. If you want something more high fidelity, use Mission Architect or Launch Vehicle Designer. Both can handle the analysis you're after with no problems.
  11. Thanks for checking this out! Given that this was the last major thing I wanted looked into before the next release, I think 1.6.2 will officially drop this week at some point. As far as the MCR goes, it was designed to be distributed with deployed MATLAB software so I doubt there's a problem with that. However, I do prefer to be in control of the distribution of KSPTOT, so I'd like to continue hosting it myself for the time being. I also like to keep the MCR package out of the distribution because it is so large, as you've seen. But thanks for looking into that! It's certainly a novel way to get KSPTOT out there and maybe I'll take you up on it in the future.
  12. Sure, no problem. I like your mock-up. @CraigCottingham, any luck with the Linux build of KSPTOT on Mac yet?
  13. Thanks! If you could put together any instructions users would need to get this to run on Mac, that would be great. And please do use the latest pre-release when you test, the Linux version should be in there. :)
  14. Thanks for the info! The parallel workers (the ctfxlauncher processes) are only used for optimization, so it makes sense that you only see minimal activity from them when you were just running the script. If you take that example MAT file I provided and start optimizing it, you should see those eight worker processes begin to do something.
  15. Hi everyone, Tonight I've built KSPTOT v1.6.2 pre-release 4. This is primarily a bug fix and performance improvement release, and I think we're nearing the v1.6.2 official release. As with before, this pre-release includes both Windows and Linux builds. Here's the change log: Added a few more Graphical Analysis tasks to Launch Vehicle Designer (LVD): "Two Body Impact Latitude", "Two Body Impact Longitude", and "Two Body Time to Impact" These provide information on where your spacecraft would impact the current central body under the influence of only two body gravity. Works well as an initial estimate for stage disposal impact points (because here everyone cares about not dropping stages on populated areas, right?). Fixed bugs reported here since last pre-release. A number of important performance improvements that should be noticeable. Please let me know if you find any bugs or issues in this release. Thanks! Also, could I ask a favor from people using the new pre-releases? I'm trying to get a feel for what sort of performance everyone is seeing on their systems in LVD. If you'd like to help, please do the following and report back with results to this thread. Either Windows or Linux platforms are fine. Download and run KSPTOT v1.6.2 pre-release 4. Open Launch Vehicle Designer. Load the "lvdExample_asparagusStagingToMun.mat" example included with the pre-release package. After it loads, use the Simulation -> Run Script menu command (or just ctrl-p, it does the same thing) five or six times. Basically just run the script with no changes five or six times. Report the lines in the output window that state how long it took the script to execute here in this thread (in a quote or code box). When you report, please include your CPU model (or number of CPU logical cores and CPU clock rate) and amount of RAM onboard your system. If you know them, of course. Thank you!
  16. Hi everyone, Here is a link to KSPTOT v1.6.2 pre-release 3. This file is about twice as big as the previous pre-releases as I wanted to push out a Linux v1.6.2 release to see how that goes for people. Feel free to delete the files you don't need after downloading. The change log is pretty straightforward: LVD: Added "extrema" to allow for recording and constraining of minimum and maximum values of various quantities. Lots of bug fixes as discussed above. Please note that if you're a Linux user and you don't have the MATLAB Compiler Runtime installed, you need to install it at "/usr/local/MATLAB/R2017b/ " for the software to work. Please let me know if you find any bugs or problems. Thanks! I think I actually just fixed this bug in the latest v1.6.2 pre-release, so check out what I just posted. And yes, that's all it does is rerun the optimizer with the last settings. It's a convenience, nothing more.
  17. Thanks for the file. I took a look but didn't have much luck that was better than you. I did notice that since it's your eccentricity (or really, SMA, since with the radius of periapsis constraint in there, they are one in the same) that won't come in, you might consider adding another course correction maneuver just before arrival to Eve's SoI. Or, just insert the 32 m/s Eve departure burn and let that try to make up the difference. You'd need to remove the constraints on the inbound Eve orbit and put them into the outbound Eve orbit. That's better practice anyway, really since if you've got the time and outbound orbits figured out, then it really doesn't matter much. Also keep in mind that the MFMS output makes the infinitesimal SoI assumption, so those outbound/inbound orbits are only approximate anyway. If you can't get a constraint to come in, you can always drop it and try to let the optimizer figure out the mission without that constraint. Let me know if you have any more questions!
  18. I have been working on something for a bit now that I can finally share! In Launch Vehicle Designer, one thing that has not been capable up until now is to look at the minimum or maximum values of some quantity. For example, want to constraint maximum dynamic pressure during your lift off and ascend? This is not possible in KSPTOT v1.6.1. However, it is now. I call the new feature "Extrema", as that's what they are. These are plots of dynamic pressure. The top is the straight up quantity: it is the time history of dynamic pressure during some ascent from Kerbin to orbit. The bottom plot, however, is the time history of the maximum dynamic pressure. This means that as dynamic pressure goes up, the maximum keeps increasing. However, after the peak dynamic pressure (when dynamic pressure starts dropping), the maximum stays up where it was at the peak. This allows you to set constraints for, say maximum dynamic pressure or minimum altitude or any such thing. Just about every quantity in the Graphical Analysis tool is available for use as Extrema, and of course both minimum and maximum extrema are available. I look forward to seeing how the KSPTOT community makes use of this.
  19. I wouldn't worry too much about triggering inferior SoI transitions. Work on setting up the SoI transition you want first and make it stable so that perturbations to the script don't send you somewhere you don't want to go, and then use the "Go to Next SoI transition" event. As far as what you're talking about with the function value... you could do something like that in theory, but it'd be pretty touchy and prone to failure I think. Best to not use the Central Body ID stuff as much as possible (because it has no slope or anything to help the optimizer key off of). You can minimize delta-v by using the "maximize spacecraft mass" objective function. It does the same thing in the end. It's not a dumb approach at all actually. I do something like that myself. Just use the maximize spacecraft mass objective function and you should be all set.
  20. The issue in the 4x example case is that the initial state for the SRB-S engines 2, 3, and 4 is "inactive". This causes the runtime on the script to be 4x longer. The script terminates because the minimum altitude of -1 km is reached. This is configuration in the integration settings. I'll try to put a warning in for this for the next release. EDIT: Done for next release.
×
×
  • Create New...