Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,557

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    Hi everyone, Tonight I've pushed out KSPTOT v1.6.7 pre-release 10. This pre-release has a few new features and bug fixes. Here's the change log. LVD: View axis limit and camera information is now properly stored for various camera properties in the view profile. The information is recalled correctly if the user does not wish for view axes limits to be updated after propagation. LVD: Fixed bugs regarding vessel orbit import from KSP and SFS files in initial state and set kinematic state UIs. MA: Fixed bug with propagating to node calculations. LVD: Engines now model thrust and isp as a function of pressure through the use of curves and not the hard-coded vacuum and sea level pressure points. The interpolation scheme also moved to griddedinterpolants that use linear interpolation and nearest neighbor extrapolation. LVD: Engine data can now be imported from KSP engine config files. Right click in the edit engine dialog box on the thrust and Isp buttons. Please let me know if you find any bugs. Thanks!
  2. Arrowstar
    Hey guys, changes are coming to the LVD engine data dialog box that I want to show off tonight. Previously, users entered in the engine's sea level and vacuum thrust and Isp and the code linearly interpolated between these data w.r.t. the ambient pressure outside. While this was simple, it also posed some limitations for high pressure environments like sea level on Eve, where the pressure is significantly greater than Kerbin's sea level pressure. Namely, engine thrust and Isp were not computed correctly at these pressures. Coming in the next pre-release, you'll now see those text areas replaced with two new buttons for editing custom thrust and Isp curves. These buttons open a dialog box identical to the existing "throttle modifier profile" button. Engines must have two data points, one at Kerbin sea level and one at vacuum. Other data points can be added, and intermediate points are interpolated linearly. Existing engine data will be automatically ported over to the new system when you first load an LVD case, and no action is necessary by the user to make the update. It should "just work." Please let me know if you have any questions! Thanks. EDIT: You can also import data into the engines (thrust, isp, min and max throttle) directly from KSP engine config files now. It's a right click context menu in the Edit Engine dialog box, if you right click on the thrust or isp buttons or min/max throttle text areas.
  3. Arrowstar
    By the way, if anyone has outstanding bugs or issues that I haven't already addressed, please let me know ASAP. I want to put out a pre-release tomorrow before I take a break for a few weeks for Christmas. Thanks! Any luck with reproducing your error?
  4. Arrowstar
    Issue resolved for next release.
  5. Arrowstar
    Yes, can I see the MA MAT files that you're working with? It's the only way I can diagnose these things. I'll take a look tomorrow.
  6. Arrowstar
    Alright, you did find a bug and I believe I've got it fixed. I'll push out a fix for PR9 tomorrow. In the mean time, copy/paste as needed.
  7. Arrowstar
    Can I see the SFS file? The parameters in the initial state dialog box look like they're still on the ground. EDIT: And the MA MAT file, please, too.
  8. Arrowstar
    Sure. I'll set it up so that if the camera toolbar is visible on the main UI, then it will be visible on the pop out display as well.
  9. Arrowstar
    Hahaha, oh no lol. I'm glad everything is working as expected now. The impact of texuturing the spheres is pretty minimal after you load the texture the first time, and even that's small. I'm not worried about it.
  10. Arrowstar
    I'm not sure. I can't reproduce any propagation error on either Windows or Linux. Can you try to duplicate the error in a clean MAT file? And double check you're seeing "v1.6.7 PR9" in LVD's output area, of course.
  11. Arrowstar
    Yes, I pulled the MAT file from the link in your last post there. It loads fine for me. Does it not for you?
  12. Arrowstar
    Are you sure you're on the latest PR? I couldn't reproduce it over here and it looks like it's the same issue you reported previously which I fixed.
  13. Arrowstar
    Well great timing! Thanks for the segue. Today I've built KSPTOT v1.6.7 pre-release 9. Here's the change log: LVD: Steering model UIs now display proper angle names and not just "alpha", "beta", and "gamma." LVD: The main LVD window is now resizable. There is a minimum size limit equal to the current window size, but no limit on the maximum. Resolved TwoBodyPropagator error. The ocean floor has been removed from the Eve and Kerbin surface textures. The issue with radio button strings overrunning their bounds in the main KSPTOT UI on Linux has been resolved. LVD: Added a new toolbar button to toggle the camera toolbar on and off. The camera toolbar can be used to move the physical scene camera around, which often makes for a better viewing experience. The current zoom and pan buttons actually adjust the scene axis limits directly, which can be non-ideal in many cases. Please let me know if you find any bugs, thanks!
  14. Arrowstar
    Agreed, I actual have rerendered stuff since then to take out the ocean floors. Thanks for pointing it out!
  15. Arrowstar
    The basic difference is that sidereal day length is the amount of time the planet takes to rotate 360 degrees. The synodic day is the length of time required to rotate from noon to noon (so overhead sun to overhead sun). These are different because the planet must rotate MORE (> 360 deg) to get back to noon because it is also moving around the Sun. Sidereal rotation period is what I need for computing the angular rotation rate of the celestial bodies, so that's what's in KSPTOT. I'm not sure if that helps any? Yes, you found a bug. Resolved for next release. I'm also happy to share that the main LVD window will now be resizable. It was a ton of work to pull this off because I had to compute the new dimensions manually, but hopefully this is a nice addition. Don't expect it for other UIs any time soon though lol.
  16. Arrowstar
    Right, okay. So assuming you made your bodies.ini file from KSPTOTConnect, then the 21600 seconds is correct. That is pulling directly from the "rotationalperiod" parameter inside KSP itself. I know you mentioned that Kopernicus should be updating the rotational period to 21651 seconds. Could you verify that's actually happening correctly, that your definition of rotational period and Kopernicus' definition of rotational period are the same (both should be sidereal day lengths), and that you created your bodies.ini file using KSPTOTConnect? Create a new mission in Mission Architect or Launch Vehicle Designer (MA will be faster), copy the state prior to the propagation into the initial state, propagate for your desired amount of time, and then copy the resultant final state back into your original MA or LVD mission case file as its initial state. Alternatively, in LVD, once you've done this you can use a Set Kinematic State action event to just jump time and orbit and whatnot forward to the resultant state above instead of using it as an initial state. If you want to do this or not depends on what you're trying to accomplish and is a bit more complex, yes.
  17. Arrowstar
    The rotational period in your LVD MAT file is 21600 s for Kerbin. Could that be the issue? EDIT: If I correct the MAT file's rotation period to what you set and then plot the coordinates of the pin that you showed on your KSA tracker map into a ground station in your MAT file, it looks like things line up at first glance.
  18. Arrowstar
    Right, so you've mostly got it. The entry "surfTextureZRotOffset" in the bodies.ini file should basically be set to the central longitude of the texture you're using (or is it the opposite of the longitude... I'm not sure lol). In any event, yes, that parameter is only read once when the bodies.ini file is loaded. Once you create an LVD case file, the parameter is basically fixed because the celestial body information is cached in the case file. I guess I don't understand the bit about the calculation being off. Everything looks okay on my end. Do you have an example? EDIT: If you grabbed PR8 download before I fixed the "bug" (in actuality, it was something I did intentionally to make sure things were working as intended but forgot to revert at first), then you might be having an issue. Try downloading PR8 again and see if that helps maybe.
  19. Arrowstar
    It's solving Lambert's problem for each combination of departure and arrival date. It runs computes both the type I and type II solutions and uses the one that minimizes delta-v for each departure/arrival combination.
  20. Arrowstar
    Yes, this is correct. KSPTOT uses 365 civil days of 24 hours per day when using "Earth time." KSPTOT uses seconds from an epoch as the internal time system. Everything ultimately gets interpreted that way. KSPTOT doesn't actually care about years, or days, or hours, etc. Just the seconds past epoch is what matters. The behavior you're seeing is correct. There are places where UT seconds are shown with their date, like on the main KSPTOT UI. But generally "dates" aren't very interesting, and certainly not useful for astrodynamics. Remember, KSP itself doesn't really do dates and KSPTOT is primarily written for KSP. You'll get used to working with the universal time (UT) seconds at some point.
  21. Arrowstar
    Hi everyone, Tonight I've compiled KSPTOT v1.6.7 pre-release 8. Sorry for the much larger download size of this file. Turns out the high res planet textures take up a fair bit of space. I'm going to try to get that down in the future somehow, but I'm still exploring that at the moment. Here's the change log: LVD: Fixed bug with Adjust Variable dialog getting a weird axes in the background sometimes. LVD: Optimization variables are now sorted by event number before optimization so they appear in order in the optimization UI. LVD: Having the Update View Limits option checked in the View Settings now retains the existing view direction, it just updates the axis limits. LVD: Added ability to display a semi-transparent atmosphere overlay in the View Settings. MA/LVD: Added a new astro calculator to find radius/velocity/FPA from sma/ecc/true anomaly. MA: Mission Animator UT time entry field now has a context menu for entering time as date/time. It also attempts string evaluation. LVD: Added angle equations to steering and throttle UIs. LVD: Users can now set the type of throttle model and steering model in the initial state, as well as their corresponding parameters. Celestial bodies can now display a surface texture instead of the color gradient used previously. Warning: This will only apply to new MA and LVD mission cases because the data is stored in the data structure that contains data from the bodies.ini files. Since MA and LVD cache their celestial body data, those existing data structures will not have the data necessary to display the surface textures that now ship with KSPTOT. A potential "update" path is currently being looked at to add the surface textures to existing cases if the body name and ID match what's in the shipped bodies.ini file. MA/LVD: Added flight path angle graphical analysis tasks and constraints. MA: Mission Animator time slider step size is now fixed to warp rate.: EDIT: I found a small bug and am re-uploading the pre-release. Please hold off until I edit this post again. Thanks! EDIT 2: Alright, give it 10 minutes and then it should be good to go. Note that I did write a rudimentary update function for adding in the textures to existing LVD and MA mission plans. If you experience issues with this, please let me know. Thanks!
  22. Arrowstar
    Alright, here's some more eye candy. I've got all of the high detail textures in for all the KSP bodies (aside from the Sun and Jool, which don't have textures). This is Kerbin and the Mun, as viewed from the Kerbin-Mun two body rotating frame. You can see both bodies rotating and the sunlight moving around them. Pretty neat, huh? I'm going to put out a pre-release tonight, I think, so people can play with this.
  23. Arrowstar
    THANK YOU! Yes, this is perfect. I'm generating the map data now. Thank you!
  24. Arrowstar
    Hi everyone, I'm working on an upgrade for my KSP Trajectory Optimization Tool that requires having planetary maps. I am specifically looking for something like this for all of the stock KSP celestial bodies. Surely these must be out there somewhere, right? Does any know where I can find them? Thank you!
  25. Arrowstar
    Roger, I'll keep the default implementation then. Done for next release. And yes, I can add a tooltip. Good thought. Yeah, it's turning out even sweeter than I thought it would. Red triangle is KSC, white triangle is 0,0 (lat/long). No idea about Mission Animator. Maybe? I haven't gotten that far yet. I'll add it to the to do list. By the way, if anyone knows where I can get high-res surface imagery of all the stock KSP bodies, please let me know. I was able to find Kerbin, and maybe outdated maps for Duna and the Mun, but I'm not confident about getting all of them.
×
×
  • Create New...