Jump to content

Drew Kerman

  • Posts

  • Joined

  • Last visited

Everything posted by Drew Kerman

  1. No, seriously my heart skipped a beat when I saw this thread. This is exactly what I've always expected a weather mod to be - someone actually interested in climatology (likely from an educational perspective as you are as well) running an external simulation that feeds data into the game. Magnifico, amazing to finally see it come to be. I need a moment here... phew... what's not clear tho is if this is just the current state or a permanent conflict. Have you spoken to @dkavolis, the current FAR maintainer at all? Can FAR be modified to accept the values of KWP or does it somehow rely too heavily on the values it uses? I'm also pinging @Arrowstar to make him aware of this, since his Launch Vehicle Designer models atmospheric pressure and temperature that would be affected by this mod I look forward very much to testing this out, and seeing how close or far I've been in my own very very general & basic modeling of Kerbin's weather for my KSA roleplay the past 4 years. Hoping I don't have to make too many obvious retcons my use of weather has become more of a story aspect tho - I create weather events to delay launches I need more time to prepare, for example. I've never felt comfortable causing launch delays solely due to weather I've been forced to "make up" on my own. Having the game tell me conditions are not good for launch will add a nice new aspect to dealing with missions I've been missing for years
  2. It's been a while so I started out in 2016 with i7-4790K (but not OC'd) 16GB RAM R7 250X then in 2018 I bumped up to an RX 460 (cause it was the only decent card I could find at a decent price on short notice when my older card burnt out, stupid bitcoin) early last year I moved up to a 2060 Super and 24GB of RAM (didn't go full 32 cause I can't carry it over to my new mobo this year when I upgrade my CPU) graphics card may seem the best upgrade of course, finally decent frames on scenes with lots of ground scatter but that's never really been an issue since I actually fly with graphics as low as possible to increase sim rate. All photos/video are recreated and taken after the fact so FPS doesn't matter. Really looking forwards more to a new CPU this year and 32GB RAM. TBH tho I didn't really suffer any regular stability issues with 16GB of RAM but I did have to take many extra measures to ensure I was only loading parts I was using to keep memory usage down
  3. will try to take a closer look this week but cool stuff and I can def attempt to apply it to my next orbital mission launching in Feb
  4. Happy new year! 2021 is looking exciting and here is a look back at all that was accomplished in 2020. Full res images in this flickr album For the first time an entire year was spent by our crew mostly in training, with the fewest amount of actual missions carried out - such is the complex nature of space flight! KerBalloon missions were as numerous as last year and mission time was nearly doubled on average as surface expeditions became more far-flung & long-lasting. The successful use of orbital comms tested this year has everyone excited to really open up surface exploration in 2021 we got in a few flights this year before the Genesis program was shuttered. Fixed-wing aircraft development remains alive with C7 Aerospace Division and missions like those previously flown by Commander Valentina & Captain Jebediah are now handled by a growing pool of commercial aviators although we did have a shutdown of the rocketry programs early this year, there was no shutdown of the entire Agency at any point and we at least got off one mission each month in 2020, continuing the streak that went through 2019 as well. Planning to keep it alive in 2021! Even though overall launch count was down from last year, the missions were much more complex, including our first ever orbital missions launched from the Ascension Mk2 and getting the rest of our crew up into space via the Mk1. The Mk7-B helped qualify the reusable boosters for the upcoming Ascension Mk3 as well as paving the way for the Progeny Mk8. Ironically, our Progeny Mk6 missions, technically the easiest, did not fare well For the first time we get to look at some stats from missions that circled the planet multiple times, something we plan to do a lot more often in 2021, and we have confirmed the Ascension Mk3 can take us interplanetary!
  5. @JadeOfMaar FYI your github link for Thor Tech in the OP doesn't go to the latest release
  6. I'm getting endless nullref spam when I just launch a kerbal in a mk1 pod to the pad and switch to map view, even stripped down to stock & dependencies in 1.10.1 logs
  7. Our operational year ended yesterday and Kerbin II was returned to the surface intact (mostly) this past week as well after more than 84 days, 15 million km and 3,000 orbits. Click the image for more info on the Ops Tracker. Be sure to catch up on anything you may have missed over the course of this year and even prior via our Ops Summaries What do we hope to achieve in 2021? Here's a peek at our main goals, in rough order of operations: Ascension Mk3 debuts with launch of Kerbin III into high-Kerbin orbit to study the radiation belts & test new vacuum LF/O engine Progeny Mk8 debuts, first flight of rocket guided only by thrust vectoring. Payload mission TBD Mk1-B capsule completes qualification trials, heads to space on sub-orbital test flight atop an Ascension Mk1 WildCat-V engine completes qualification trials for integration into Ascension Mk3 Commander Valentina or Specialist Bob become the 1st kerbal to orbit Kerbin CommSat Network begins launch of 3 satellites into low-Kerbin orbit for continuous ground coverage up to 70° latitude Progeny Mk8/Ascension Mk3 unkerbed short-term missions to Mun and Minmus under Extremis program. Maybe orbit? Additional, longer kerbed orbital flights, possibly a space walk Extremis I flagship mission attempts first interplanetary exploration of Eve, Jool and Plock over the next 3 years KerBalloon continues operations in later half of year with extended expeditions supported by commsats Iterative design continues to work towards an Ascension Mk4 (full TVC) and Progeny Mk8 Heavy Future Extremis flagship missions for 2022 and beyond planned Thanks to everyone who has and continues to support us! Stay tuned for 2020 recap infographics coming at the end of the month
  8. nice. Also here's some "IRL" results for you! De-orbited my Kerbin II satellite today: End of plot is where the chutes were calculated to deploy at 1.2km and the red spot is where the satellite actually splashed down. Not too shabby!! In fact, the discrepancy is most likely due to the chutes pre-deploying at ~30km and this extra drag is not factored in, which is why the LVD plot goes a bit further. I did a "simulation" where I just Hyperedited the satellite to 80km and had it drop straight down while logging in FAR to get a rough Cd curve. Imported that then I used my drag area technique from the wiki, plugged in the re-entry trajectory orbital deets from MA where I calculated the maneuver - and viola! Well, almost. I did screw up and forget to unload the propellant from the default spacecraft tank in LVD, so I originally got the result I showed in my earlier posts. Ooof I know you guys have procedures to avoid simple mistakes like this and I still have to work on mine!!
  9. this is really cool. Is it possible to use also in the pop out figure window? Although if not, at least the LVD window can be resized now to make the figure almost as big
  10. Yep, I felt there was one dropping soon Also, I am a FRIKIN IDIOT HAHAHAHAHAHAHA I figured out what the problem was. Guess what happens when you move the time slider to the end where the vessel is supposed to be at that time? *sigh* This does present an interesting question for Mission Architect though, where I'm not sure the planet textures serve any real purpose because at what point does the surface texture relate to the orbit given that you can't actually see the vessel's position? It's useful in LVD and Mission Animator, but for the default Mission Architect view you're just as good with the original shaded bodies. However if there's no performance impact to having them textured then I also see no harm in the textures being used
  11. Ah, so here is the root of the problem then? I guess I am actually changing Kerbin's synodic rotation rate. Here's the patch I use: @Body[Kerbin] { @Properties { // return Kerbin to old pre-v1.0.5 rotation period %rotationPeriod = 21651 } } I know Kopernicus is working because the new default is 6hrs to match sidereal rotation and the sun will stay in one place if I forward time. Using Hyperedit I can increment the game UT on a week/day/hour basis and clicking repeatedly on the Day+ button the date increases but the sun position does not change after disabling this patch. When I restart the game with my patch again enabled, clicking the Day+ button makes the sun move across the sky. As I noted in my original post, I made this change so sunrise/sunset times would change from day to day. My understanding of sidereal vs. synodic time however is still not that great in application so maybe I'm just barking up the wrong tree on this issue?
  12. Possibly? I thought this issue sounded familiar so I did a search for 21651 and turns out I actually raised this question last year: If you follow the posts after you asked for a MAT file and I provided one but I don't see a response referencing it. Seems we both let this one fall through the cracks! So for this entire time has my .ini file exported from KSP failed to report the proper rotperiod?
  13. nope, still an issue you mean you want the actual LVD case file? You can grab it here. Images in my prev post demonstrate the issue. When I plug in the lat/lng from the Final State position it shows up on my Kerbin map where I planned for it to be, but in LVD the trajectory *appears* to end too far east due to the improper texture position. I use Kopernicus to change my Kerbin rotation to 21651s (it's the slower original Kerbin rotation period before the 6hr synodic day change in v1.0.5)
  14. @Arrowstar I can't use the included bodies.ini file because I have Kopernicus messing with Kerbin's atmosphere and spin rate. I tried to generate a new .ini but the texture feature was not included in the file. I placed the Kerbin texture lines in myself and that works but was not able to adjust the rotational offset. I tried using surfTextureZRotOffset but not sure if that's what that is for as it didn't seem to make any difference. I made sure to not only reload the .ini file after editing but also never saved my LVD file after load which means it would again convert it to the new .ini data. Here is the discrepancy: LVD: Where the trajectory is supposed to end, plugging the lat/lng into my online map Ahhh, I was just about to post this and had another thought. Did some experimenting and yup, I see what's happening now. The surfTextureZRotOffset is working as intended, each time I edit it and load up LVD the default view of Kerbin changes as the texture is rotated. I didn't really pay attention before just loaded straight up into my case file. So okay the conversion is not using the currently-loaded .ini file it's converting based on the .ini data already in the case file. So then you're either a bit off on the offset calculation to account for a different body rotation speed or forgot to account for that altogether during the update.
  15. 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?
  16. 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
  17. @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?
  18. 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
  19. 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
  20. 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
  • Create New...