Jump to content

Drew Kerman

  • Posts

  • Joined

  • Last visited

Everything posted by Drew Kerman

  1. Yea, precision in this case is not the goal and you have the text box for that. Also a related UX suggestion - if it's possible to assign the scrollbar arrows tooltips, have one pop up containing the current warp factor setting so people make the connection on the behavior OMGGGGGGGG that's awesome now I don't have to use ground stations to try and figure out what part of the planet my ship is over Will it work in Mission Animator as well?
  2. if warp factor is set to 1000x then one click = 1000s. It would just be easier for stepping through things one. bit. at. a. time. to really make note of position/change, etc then have it all fly by in animation
  3. @Arrowstar just thought up a feature request for the Mission Animator - tie the scroll buttons to the warp factor. So a single click = warp factor. Pressing play/stop works okay but does also always advance two steps instead of one. If it's not simple to tie in the scroll button the play/stop method works fine, but only for advancing forwards. I know you can scrub with the scrollbar, but depending on the scale of the timeline getting tiny movements can sometimes be difficult. Also can the "sec" field allow for using the UT time dialog?
  4. Oh I know, I just don't really see the point of doing that. I figured doing the roll in LVD wouldn't have any major effect on the outcome and it doesn't have inputs for engine vector or fin steering steering limits so it can't actually tell me how long it will take the rocket to roll (future feature? eh, maybe at least for engine gimbal but either way not a big deal IMO). So why bother when the rocket will be otherwise heading straight up anyway? if it were pitching while rolling, that may be another thing. Please correct me if my assumptions are wrong! No comment on your other tips, I will work to apply them and update you on progress when I hit a wall at some point
  5. okay @Arrowstar work with me here on this ascent plan, due to launch in early Feb 2021, I want to try a direct injection to 300km circular orbit. I have everything setup for staging and for the initial launch, which will roll the rocket from 45° to 90° (can't launch 90° due to how its launch platform is setup). I don't bother actually rolling it in the script I just know based on game testing it takes ~10s to complete the roll so I have it fly straight up for that time. From that point I want to start pitching over. Although you said the tangent steering model wasn't best for an atmosphere, could I use it to just get an initial ascent path? Then from there make note of the alt/pitch and manually create several pitch events that recreate it with some leeway in optimized values and let the optimizer go to work? How should I set up the constraints? I know I would want an objective function to maximize LF/O but should I use ap/pe constraints or an altitude + ecc constraints? Speaking of objective functions, it's possible to have more than one but you can't change the optimization type for each? So I can't have maximize LF/O and minimize ecc objective functions? Finally, still not completely sure how to use the Scale Factor for constraints - is that based mainly off the Jacobian Heatmap or do you have some intuitive approaches to it? Thanks
  6. hey I noticed that recently too, and I have no idea what happened to it either! Been waiting for it to pop back up maybe it's contextual but so far no sign of it
  7. sorry, I guess I should have just tried it to see! What threw me was the default setting of 1 instead of -1 so I thought that was the current value, which matches up to the integrator's Initial Step Size
  8. so is this only really usable for bodies without atmosphere? OH!! Also I forgot to remind you that the Integration Step Size global control is not what I had in mind. What I was asking for was a way to globally set the step size for the integrator output
  9. @Arrowstar oh sunofa*** when I went to check for errors I opened an error log I saved from a previous problem that was underneath the *actual* error log file, which is indeed empty. This was coupled with the fact that I thought I had actually built an ascent in this file not just the vessel data. But I guess I didn't? Okay. Sorry @vitorboschi thx for the dbl-check
  10. @Arrowstar BTW I don't really need that file so if it's a pain to fix then don't bother. Just hoping it can lead to preventing any future issues
  11. R2020b: R2017b: Win10 Pro x64 i7 4790K @ 4.2GHz 24GB RAM Also, something happened to this LVD case file and it won't open. I rolled back all the way to 1.6.4 since I forgot when I made it but couldn't load it in anything. I know it ran fine the last time I used it so not sure what the heck happened to it
  12. It's now a thing that's possible with the CommNet Constellation mod
  13. And well used also. Smart Timer in particular for me remains essential as the only part that can "wake up" my probes on deployment so their flight computer boots up and phones home to begin their mission. Cool to see more of the old-timers stopping by lately...
  14. Try this. Not sure if it will work but it's the folder from my 1.3.1 install that I have archived - http://www.kerbalspace.agency/misc/Diazo.zip
  15. yea this annoys me too. That's a stock thing with EC but Kerbalism also does the same with rads, switching between mrads/hr and rads/hr
  16. yes, they show up in the notifications when the full science data is transmitted. I prefer to switch the settings to stock notifcations and then use One Window, since that records what pops up on the screen. That way I can also export them if I want
  17. you're using parts not properly designed for FAR, otherwise the stock CoL should not be visible - IIRC
  18. @Arrowstar nothing major missed in the last few months. There's still some deep analysis that needs to be done with some of the trajectory data I posted a while back where I found Mun encounters to be spoiling future plots of my captured asteroid but that's not a pressing issue still - something more to tackle in lieu of anything else. More good stuff from reddit tho - this is an update to a post I linked to earlier:
  19. Oh yea, the constraint started well below 0 and just kept getting smaller and smaller. It eventually quit on its own and the smallest constraint was 30 of 34 iterations. I was aiming for a very very specific number so I expected it would take time to work through the problem especially considering I use a lot of Cd values and had several pitch events as well. Didn't seem unreasonable to take that long although I also don't really know what reasonable would be I'll take some time later tonight or tomorrow to go back and double check for you
  20. @linuxgurugamer this is the same behavior I have reported as well
  21. How did you know it was these events holding things up? Switching to ODE5 did indeed bring down the execution time from 6s to 2s, but it also gave me a slightly different result. ODE5 has me coming down 3km from where ODE45 says the rocket will - which isn't really a huge difference so I'm not concerned about that. I'm just wondering though if the speed has sacrificed accuracy or improved it - could potentially make a difference on problems requiring more precision Also is this speeding up just the script execution or the optimizer execution as well? For my understanding in choosing between integrator options in the future, what would be considered a "stiff problem"? Ah, okay. So this is a bit of an inconsistency then since the Initial State coordinates seem to be okay with accepting -180/180 values for longitude. I thought then that was valid input for anything longitude in LVD (I know MA doesn't like it and I have to convert to 0-360). Actually this has always annoyed me a little bit since everything in KSP is done -180/180. A related minor annoyance is how input fields and stuff like the popup tooltips report lng/lat instead of lat/lng ;P Anyways yea adding 360 to make the conversion seems to have worked. At least, the optimizer has been running along now without issue for over an hour crunching on the problem and the constraint violation is trending downwards Also, this popped up on the kOS reddit yesterday. Not sure if it will be applicable to LVD's own work with drag calculation tho
  22. Last Progeny Mk7-B is on the pad for launch attempt tomorrow! Tune in - lift off scheduled for 17:45 UTC We have also filled out the remainder of our 2020 launch schedule, more information on these missions and the one above on the Ops Tracker
  23. Have you seen this? Not trying to discourage you but you're new to the forums I'm assuming you're new to the community in general and may not have come across it yet. You may be aiming for something different but if it already does what you plan to do the author is always open to suggestions and contributions
  • Create New...