Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,562

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    You actually want ports 8282 through 8295 open. This is correct. Maneuvers start and end at the start and end of their event. Impulsive DV maneuvers in MA actually work the same way. it's just that their duration is 0 seconds, and so the start and end time is the same. Yes, that's correct. MEA was designed to help with executing impulsive manevuers in KSP, with the caveat that the maneuver duration needs to be "considerably shorter" than the orbital period of the initial orbit. (If this assumption doesn't hold well, then the impulsive approximation to the finite burn will not hold either.) Ah, right. So the maneuver node uploaded to KSP is the attitude of the vehicle at the start of the burn, and the node is placed at the start of the burn. You are responsible for executing the rest of the maneuver according to the steering law you've picked. If that's inertial steering, then you can just hold that attitude. If it's orbital frame steering, then you need to keep the same attitude relative to the prograde/normal/radial markers on the nav ball. Let me know if that helps or if you have any other questions.
  2. Arrowstar
    Hi everyone, This afternoon I've built KSPTOT v1.6.7 pre-release 11. Here's the change log: LVD: Upload impulsive delta-v maneuver from "Add Impulsive Delta-V" event action is now available. Right click on an event in the sequential events list with an "Add Impulsive Delta-V" action and click on the upload maneuver menu item. MA: Resolved issue with computing position wrt Sun of other spacecraft. LVD: True anomaly termination condition should now work properly. LVD: Event actions with variables now correctly remove those variables when the action is deleted. Please let me know if you find any further bugs. Thanks! Can you try out PR11, above, and see if it resolves your issue. I still can't reproduce, so maybe I fixed whatever is causing your issue. (Unless, you're on Linux, right? I can't build for Linux right now, so unless you have a Windows system around, we might have to just wait for a bit.) Memory consumption should be pretty low. It certainly wouldn't consume 48 GB. You might be running into a bug somewhere... hopefully I can fix it, if I haven't already. Can someone else follow @vitorboschi's instructions in MFMS in PR11 and see if they can't reproduce? Thanks!
  3. Arrowstar
    I couldn't reproduce. Can you give me the exact steps I need to take to get this to happen? Thanks for the report! This one is resolved for next release. I have been trying to track down this one for ages, so I'm glad it's finally taken care of.
  4. Arrowstar
    Issue resolved for next release. Thanks for the report. Yeah, the true anomaly termination condition has always been a pain in the neck. I think figured out a decent way to do it this morning. It seems to work in all my tests, anyway. But really this is a much harder problem than it looks for a numerical integrator because of the annoying instances when your true anomaly has to go through 0 to get to the point you want. Hopefully my new technique is good enough. The issue here is that you switched to the two body propagator. This propagator can take large steps because the equation of motion is so simple (M_dot = n). The solution here is to specify the step size of the integrator directly in the events that you use it. Open the event, click integrator options, and then set the step size to something reasonable and greater than 0. Aim for about ~100 steps per integration in your step size. Do not just set it to 1 second or something super small, the code will take forever to run. I'll try to get a PR11 build out today with these fixes, but be aware that it will be Windows only as I'm away from my Linux environment.
  5. Arrowstar
    Here are some thoughts: "How close do I need to be?" While there's no good answer to this, the best I can provide is "reasonably close." If it looks like your current trajectory is off in the weeds, it probably is. Use the variable adjuster (Optimization -> Adjust Variables) to accomplish this. Seven pitch rate changes is probably a bit much. I bet it's possible to get by with 4-5. To many variables can confuse fmincon() in highly non-linear problems like this. I would actually recommend using radius, velocity, and flight path angle as your final orbit insertion targets. Use the appropriate astrodynamics calculator (Tools -> Astrodynamics Calculators) to get these values from SMA, eccentricity, and true anomaly. I can tell you from real life experience that constraining to Rp and Ra (or altitudes) doesn't work nearly as well. Additionally, remember that if you constrain C3, you've also constrained SMA so you should not then go constrain Ra and Rp (or altitudes). You can pick one but don't do both. Otherwise you over-constrain the problem. For a powered ascent from the surface, it's generally best to make all of your event termination criteria "event duration," especially if you're using them for orbit insertion targets. Trying to use other quantities can make things highly non-linear and cause issues, like you experienced. Convert your current termination criteria to event duration and set constrains where you need them instead. The only time it's acceptable to use non-time event termination criteria, in my opinion, is when you can be absolutely sure that you won't blow past them. For example, for lift off from the Mun, you might do a short vertical rise to a specified altitude. You can't miss it if you know you start below that altitude, so then it's okay. Let me know if you have other questions, and good luck! :) Sure, I'll look into adding that. Good suggestion. :) Okay, no worries. :)
  6. 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!
  7. 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.
  8. 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?
  9. Arrowstar
    Issue resolved for next release.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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?
  17. 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.
  18. 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!
  19. Arrowstar
    Agreed, I actual have rerendered stuff since then to take out the ocean floors. Thanks for pointing it out!
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...