Jump to content

Arrowstar

Members
  • Posts

    2,557
  • Joined

  • Last visited

Everything posted by Arrowstar

  1. Great, thanks! Forgot to ask, could you put the floatCurve for the engine in that file too? That way I can build the engine correctly in LVD.
  2. Oh, I believe you that it's built into the game directly. As @Starwaster said, it seems like FloatCurve is a KSP/Unity concept. The actual math behind it is that spline you mentioned a number of posts up. As far as that goes, I don't actually have any formal math background in, but luckily MATLAB has a function for generating those types of splines so I will just call that and be good with it.
  3. Could I get from you, @Drew Kerman, some more test data? I think I remember you saying you had some plugins that could record data. Could you take one of your SRBs that you're using with this throttle table thing, fix it to the ground at a set altitude using a launch clamp, and provide me with: Sea level thrust and Isp Vacuum thrust and Isp The fixed altitude of the SRB A table of a tank mass vs. engine thrust all the way from 100% full to 0% (empty) That would be helpful for me to make sure I'm putting together the model correctly without having to have you double check my work every time I think I have the correct thing. Thanks!
  4. Alrighty then, this probably isn't so bad. The UI work will be the tricky part, as usual. I guess it'll be in pre-release 1 of 1.6.2.
  5. Okay! Thanks for the test, that is useful to know. So I guess I could use that thrust curve number as a modifier for the current throttle value as it pertains to that engine. So basically, to compute the effective throttle, determine the actual throttle, incorporating the min and max throttle limits first, and then multiply by the table value. The last question is the fuel remaining. Should I find all the tanks that engine is connected to, sum the remaining fuel at the time step, sum the max fuel for those tanks, and then divide the two sums to get the value to look up in the table? I guess that's probably how KSP works? Any insight?
  6. Kind of. I guess I'm wondering if the percentage in the table represents a modifier to the max thrust (and if so, which thrust, SL or vacuum), or to the current throttle of the booster?
  7. Okay, thanks. That is very helpful. And how does atmospheric density/pressure impact the thrust when you start getting higher up in the atmosphere?
  8. Hello! This evening I am happy to announce the release of KSP Trajectory Optimization Tool v1.6.1. This is a point release that primarily focuses on improving the new Launch Vehicle Designer (LVD) application within KSPTOT. LVD is a fully featured mission design tool primarily focused on allowing users to model and optimize launch vehicles. However, because of the generic way in which LVD is presented, KSP mission analysts can now model full missions, from launch, to in-space maneuvers, to powered landings and parachute descent, all within Launch Vehicle Designer. Most of the changes in this release are improvements to existing functionality, quality of life enhancements, bug fixes, and LVD script execution performance improvements. Here's a summary of the change log (generally all referring to LVD): Added a "normal force" model; Added the ability to select the integrator algorithm used for each event; Added new Event Actions to modify drag and lift force properties; Escape key now closes most LVD UIs; Added a dynamic pressure task to Graphical Analysis; Added ability to set the integrator step size for each event; Added "non-sequential events" that can be triggered based on a specified condition in between sequential events; Added a Thrust to Weight throttle model that holds a particular T2W ratio; Added constraints for all existing attitude angles and throttle quantities; Added Graphical Analysis tasks for tank masses, stage dry masses, engine active state, and stage active state; Added "stopwatches" that can be turned on and off during a mission to determine the amount of time between arbitrary events (includes constraints and GA tasks); Added a new LVD example that shows how to model asparagus staging while demonstrating a full trip from Kerbin to the Mun's surface and back to Kerbin; Added ability to selectively turn on and off force models for each event; Greatly sped up the time it takes to perform any action in the UI that could be undone; Added total thrust as a graphical analysis task and constraint; Many, many performance improvements to the LVD script execution engine. Executing an arbitrary script now takes 25%-50% of the time it did in v1.6.0, on average; Many, many bug fixes! 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! This is a really great release that makes LVD more powerful and more enjoyable to use, and I'm hoping you all can start taking advantage of that right away. 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, please let me know if I can help anyone out with using KSPTOT. Happy orbiting!
  9. Done, it will be in the next release. Good to hear. I could probably do something like thrust profiles, but I'd need to understand better what you actually want. Can you sketch out how such a system would work? I'm glad you're enjoying KSPTOT! While I agree with you that a video tutorial would be great, unfortunately I have no experience at all with creating videos and wouldn't even know where to begin. If someone else wanted to take up that challenge, I would be happy to support them, of course. Keep in mind that Mission Architect and Launch Vehicle Designer, while not quite "professional grade", are certainly approaching that point. Tools like that are incredibly rewarding to use but do take some time to get your head around. Keep playing with them, and start simply. The "flyby" problem in Mission Architect is actually pretty challenging. I would encourage you to start by simply trying to first model one revolution of a low Kerbin orbit, and then try to change that orbit to a geostationary orbit using two impulsive delta-v maneuvers. Once you can do that, you should have enough of the basics down to model more challenging missions. In the mean time, if you can describe a bit more about what you're trying to do and what is not working, I'm happy to help. Please provide the Mission Architect save file (*.mat format) when you do so I can take a look with you. Thanks! EDIT: Oh, wanted to share something interesting with the community. Right now KSPTOT is on MATLAB R2017b. I had an opportunity today to trial R2018b with Launch Vehicle Designer. This has been on my radar for some time because of supposed improvements to the MATLAB runtime engine that would result in faster execution of code. Well, The Math Works actually delivered on this one: the asparagus staging example I included a few pre-releases ago executes on R2017b in about 5 seconds. That same file, using the same code, executes in about 4 seconds on R2018b, resulting in a 20% improvement in code execution speed. I'm not saying we're going to R2018b or later any time soon, but it's definitely something I'm going to be thinking about this year because a "free" (as in, no code changes) 20% performance improvement in LVD is nothing to just dismiss outright. So anyway, stay tuned.
  10. So this one isn't so much a bug as it is intentional... when you change the aero properties and then close that dialog, they are changed in the event object in memory immediately. The "save and close" button the Edit Event menu is (and I realize this is not great design) just for the elements on that UI not behind a button. I'm sure there's a better way to go about this, I'm just not sure what that is yet. I won't try to fix it for the 1.6.1 release but maybe I can get that in a 1.6.2 pre-release. This is actually a "feature" of the a built in "list dialog" of MATLAB, probably not much I can do about that without creating a custom UI for that. If it's annoying enough, I'll look into it. Normal force is essentially the ground pushing up on an object to counteract gravity. It's what keeps you from sinking into the earth. You can disable it just about every instance unless you're modeling a plane moving down a runway (or any other instance where you need to move along the surface of a body (altitude = 0) relative to that rotating body). Correct. In fact, I first do a check and see if density is less than zero, and if it is, I don't even compute the drag force in the normal way, I just return a zero vector for that force element. So you don't need to change drag properties once you're out of the atmosphere because they're not even checked.
  11. Okay, I was able to repair your file. I also added a check that hopefully prevents that from happening again. I'm guessing this happened on the previous pre-release build, because what I believe caused it was removed in the latest build I posted earlier today. Let me know if you have any other issues or that file doesn't work for you.
  12. It's those dumb engine states again (you're missing 2, one on the second stage and one on some radial boosters). I'm not sure if the issue is a hold over from before the last build or if this is something new. I'll investigate...
  13. Here you go, @Drew Kerman. This is the build with your bug reports and suggestions incorporated. Let me know if I missed anything. Thanks!
  14. Yes. On the main KSPTOT window you'll see a menu for "KSP Real Time System". That's the entry way to the "mission control" side of the house that lets you pull information from the game as you fly.
  15. Hi! KSPTOT author here. @Drew Kerman gave you a pretty good reply, but I wanted to let you know that if you have questions you can post here and I'll do my best to answer them as time allows. Happy orbiting.
  16. Bugs: Fixed in next release. Fixed in next release. I did a pass of all the LVD UIs and made sure that tab orders made sense everywhere. Should not be a problem any more. Thanks for noticing this! Engines are organized by stage because they are stored in Stage objects that are arranged in a particular order. Anyway, I tried it out and the edited engine gets moved to the bottom of the list (well, the bottom of the part of the this that has engines for that stage). This is because the engine is actually destroyed and recreated when you edit it. There were some issues with just modifying the engine and its associated state many moons ago when I wrote that code, if I recall. In any event, it should be transparent to the user, but I can understand why it would look weird for it to be doing what it's doing now. I would have to think about how to change this to get the behavior of staying in the same spot... it's not straightforward the way it's set up now. Fixed in next release. I gave the Initial State UI a big overhaul. Now when you change the dropdown from one element set to another, it converts the numbers in the boxes too. And if you try to import an orbit from KSP or the orbit clipboard when you're on Body Fixed elements, it converts those to Body Fixed instead of (erroneously) leaving them as Keplerian numbers. Fixed in next release. (All of the engine issues were really just one big issue under the hood that correcting resolved.) Suggestions: Good idea, added for next release. Implemented for next release as I explained above. So... yeah. This is hard because the first dialog box you see is generated from the main KSPTOT UI. If you tell it to close windows, then it issues close commands to the other UIs. However, those UIs aren't aware of who is issuing the close command, they just do it. I'll keep thinking on this for the future, there's probably a way to get things to communicate, I just need to find a way that isn't a pain in the neck to implement or maintain. Questions: For best performance, try to combine tanks and engines as much as possible. So if you have 9 of the same engines on your actual vehicle, just make one Super Engine with 9x the thrust and the same Isp. If you have multiple types of engines, you can either create one Super Engine for each type or create one single Super Engine with the total thrust of all the real engines and the mass flow rate-weighted Isp. I can explain how you do this if you'd like, but the former option might just be easier to implement. As far as tanks go, where tanks exist on the same physical stage, try to combine those. An inactive stage: Will not have its dry mass included in the mass of the vehicle; Will not allow access to any engines onboard that stage (active or inactive); Will not allow access to any tanks onboard that stage and will not include the mass of anything in those tanks in the total vehicle mass; and Will not allow engine to tank connections from stages that are inactive. Hope all that helps! Let me know if you have any questions or you find something else buggy. Thanks!
  17. Hi everyone! So I lied. The past few days I've really been focused on improving the performance of LVD. I know it usually takes a fair bit longer to run a script in LVD than in Mission Architect (which is why MA is still the recommended tool for pure in-space mission analysis and design). I had a few "shower thoughts" yesterday on enhancements I could make and I wanted to share those with everyone in one final pre-release before this weekend, when I'm still planning on having the formal release of KSPTOT v1.6.1 drop. In light of that, here is KSPTOT v1.6.1 pre-release 6. Change log (all work is in LVD): Performance enhancements in script execution everywhere. More intelligent caching of information that doesn't change frequently during a mission, such as engine to tank connection states. My asparagus staging example runs about 30% faster today than a did a few days ago. A new "Simulation" menu that allows users to run the LVD mission script as-is. Useful for refreshing information or debugging. Has a Cntrl-P hotkey so you don't need to use the menu directly. Just about every dialog box will open faster now due to a serious performance improvement in the way that undo/redo caching works now. (That long pause before the Edit Event dialog opens up? Yeah, that's LVD serializing the current application state. I made that bit go much faster.) Added the ability to turn off certain force models for some events. Allows for some performance improvements if, say, you know that your event will never be thrusting: don't bother calling the Thrust force model in this case. Also included two new mission validators (that populate the warnings & errors segment in the lower right): a check to see if the throttle is greater than 0% for events where the Thrust model is turned off, and a check to see if the vehicle is in atmosphere but drag is turned off. Finally finished up the Normal force model, which can be used to keep an object on the surface of a body (altitude = 0). This allows for modeling of aircraft on a runway (anyone want to try modeling SpaceShipOne?), rovers on the surface of a planet, and really anything that touches the surface of any body. Please let me know if you have any questions or find any bugs. Thanks!
  18. I know it's not quite "in KSP" but I continued working in my KSP Trajectory Optimization Tool's "Launch Vehicle Designer" application. I'm currently developing a full up simulation of an end-to-end mission to the Mun and back again. I have the following goals: Simulate a realistic launch of a vehicle that utilizes asparagus staging to achieve a direct injection to a trans-Munar orbit. Include realistic gravity, drag, and engine throttling. Simulate a realistic Munar deorbit and landing, ascent and Munar departure, including a realistic stay duration on the surface of the Mun. Simulate a realistic arrival back at Kerbin, including jettison of the service module, re-entry, parachute deployment and landing. It's looking pretty good so far! Simulation of the launch trajectory: Simulation of Munar arrival, stay, and departure: Simulation of Kerbin return, re-entry, and landing: KSPTOT, including Launch Vehicle Designer, is available at the link I provided above. Feel free to check it out and PM me if you have questions. Happy orbiting!
  19. Hi everyone! Tonight I'm posting the 5th pre-release of KSPTOT v1.6.1. This pre-release is primarily focused on Launch Vehicle Designer (LVD) and adds the following functionality: Adds a new integrator, DOP853, to the LVD event options. New LVD constraint type: Stopwatch value. Speed improvements to the script propagator. Some other bug fixes here and there. I've also included with this pre-release package an LVD example MAT file that: Demonstrates how you could model asparagus staging in LVD (and by extension, many other common staging techniques); Provides a full up example mission that launches from Kerbin, flies to the Mun, lands on the Mun, stays on the Mun for some time, launches from the Mun, flies back to Kerbin, and lands back on Kerbin. As usual, please let me know if you have any questions or you find any bugs. This will probably be the v1.6.1 release unless there are any comments. My goal is to put out the v1.6.1 release this weekend, so please let me know if you find anything important. Thanks and happy orbiting!
  20. So nothing in the software "records" your save file time. However, since you enter times manually when you use KSPTOT, there's really no need to. You can also have it pull the time from KSP itself or from a save file directly. It shouldn't be a problem for you to keep your existing save. :)
×
×
  • Create New...