Drew Kerman

  • Content Count

  • Joined

  • Last visited

Community Reputation

1,790 Excellent

About Drew Kerman

  • Rank
    KSA Operations Director

Contact Methods

  • Website URL Array

Recent Profile Visitors

10,137 profile views
  1. yaaaasss now that looks nice. Have to look forward right now for a while but eventually will go back and do another look at the previous flight to see what effect this has
  2. glad it was an easy fix, thanks. Okay I took a look at the new density model and it may still need work. I've got the LVD files, bodies file and excel analysis here, with plots of density, pressure and temperature by altitude. Let me know if I made a mistake somewhere. If not, then hopefully it helps point towards the problem
  3. will check PR9 later today right now I'm using PR8 and the new SOI search works great - I went back to orbital data from before the one I missed and propogated forward and it properly found that one and the future ones I know happen. However the new default 1000 search attempt setting exacerbates a problem I noticed before but wasn't really that annoying until now - I regularly check asteroid encounters for those I know are crossing a planet's orbit (I see the close approach icons when I target the planet in the map view) and if MA fails to find an encounter in 100 revs I just switch the Coast to Next SOI event to a True Anomaly event, enter 1 for coast revs and re-plot so I get a full orbit. However even though it's only doing one revolution (not 100) it still takes just as long for some reason. I just tried it with an asteroid in orbit near Jool and it took 98.975 seconds for the Next SOI coast and 104.830 seconds for the TA coast of 1 revolution.
  4. I agree that there's not enough data to say for sure that this will show a reasonable improvement. I'll go through some more launches in the coming weeks and analyze more data to continue to weed out other possible causes. We'll revisit this later on down the road
  5. Well, that's even more bizarre then because the game is calculating it wrong too? kOS and LVD are both giving the same 174.55m/s Here you go! It's an LVD case file built from PR7 On it, should have a chance to look it over this weekend, thx! Don't forget about the density curve too when you have time
  6. I just noticed something - the rotPeriod for Kerbin in the bodies.ini file I just generated to make sure it wasn't some earlier issue is defined as 21600 - which is the default. I have a MM config for Kopernicus that sets it back to the original period of 21651 (because I hate the sunrise/sunset being at the same time everyday): @Kopernicus:FINAL { @Body[Kerbin] { @Properties { // return Kerbin to old pre-v1.0.5 rotation period %rotationPeriod = 21651 } } } what's interesting tho is that when I load up LVD with a launch location set to KSC the velocity at rest on the surface is 174.55m/s which is correct (checked against my kOS telemetry data) for a slower rotating Kerbin (the wiki says the default period should have a spin rate of 174.94m/s) How does this work out properly? I can't find any value of 21651 in the bodies.ini file I'm using
  7. oh I get it. But you can still use lock for steer and then use set to change hdg and ang as necessary. that's what I do gah wait no I mean I do lock steering to heading(hdg, pitch) - you don't need a separate steer variable - unless you plan to update the steering model again later I suppose
  8. try doing unlock steer before using the set. I had a similar issue but the other way around where I defined a variable with set then later tried to lock it wait are you trying to change the direction of the locked steering? Then you should just keep using lock.
  9. no, but like zer0kerbal said it can work if you do it right. You need to send the craft the instructions, have it store them on the vessel and then run them when it boots up after you switch to it. You can find more about boot files (not bootstrap) in the kOS docs. I have a general-purpose control system that can do what you want, if you want to use it or just want a practical example
  10. managed to find some more weird behavior with the SOI search. Take this MAT file for example. Note end time of Y4 D45, which is an actual future in-game encounter Change SOI search tolerance to 1E-9 Note end time goes a few million years into the future Change SOI search tolerance to 1E-10 Note end time is now a more reasonable at Y4 D74 however I have already advanced the game past this and can confirm there is no such future encounter Change SOI search attempts to 3 Note end time is now a few hundred billion years into the future! Damn I'm good at breaking things Change SOI search tolerance down up to 1E-14 Note end time is now Y4 D71 - still no actual encounter there either Change SOI search tolerance down to 1E-8 Back to proper Y4 D45 So all this came about when I hoped to just set search revs to 100, search attempts to 100 and tolerance to 1E-14 and have a nice catch-all. I guess I shouldn't be surprised to find it's a bit more complicated than that I'll just make a habit of doing a manual check via distance graph output and if I see anything being missed I'll narrow down to just that one encounter and tweak around with the search options until I find it
  11. Auuuughhhghhhhghghg I did not pay enough attention to what you were saying and confused the "search attempts" option with "search revs" You're right, that works. Will keep that in mind thx
  12. I accidentally discovered what happens when I render clouds in Paint.NET applied with a Color Dodge blend mode over a screenshot of the Calm Nebula skybox by Poodmund and then do it again
  13. I accidentally discovered what happens when I render clouds in Paint.NET applied with a Color Dodge blend mode over a screenshot of the Calm Nebula skybox and then do it again
  14. when I open the file I sent you, I have a Mun encounter at Y4 D95. When I set the search tolerance to 1E-10 (attempts is already at 100) I get a Mun encounter at Y4 D114. The encounter I'm looking for, and the one shown in the plot I made, is at Y4 D65
  15. Thrust over time for no atmosphere, using 1.65 TWR until 40km then full throttle (you can see the throttle lag, but like I said I found its effect to be negligible): Thrust over time with atmosphere using 1.4 TWR until 40km then full throttle - the difference is so MECO happened inside the atmosphere (at 68km) because otherwise it would not be able to maintain guidance with its fin control surfaces (no atmo was using engine gimbal): Again a slight discrepancy similar to what was seen for the TWO (throttle wide open) scenario.