[01:27:59] NASSP Logging has been started by n7275 [01:28:01] I really don't think the systems SDK knows what to do with 900 degree "glycol", lol [16:01:43] Afternoon [16:01:52] hey [16:01:59] Did you see SN8? [16:02:08] yes [16:02:19] transition from and to gliding flight was awesome [16:02:45] Yeah, I didn't know what the exact test was before hand was quite excited when that happened [16:03:07] haha, same. There were a few moments where I wasn't sure if what was happening was normal or bad [16:03:36] "feature/SMSpin" [16:03:40] how does that work [16:03:45] is that the name of the branch? [16:03:50] Yes [16:04:04] didn't know you could have / as part of a branch name [16:04:21] PR is merged [16:04:36] Yep, it's used quite commonly actually. [16:04:39] Thanks [16:05:11] I also added a new label so that we can more easily use PRs for putting stuff on changelogs [16:05:58] When you do a release you can just filter on a milestone and any PR that doesn't have that label. There's your list of stuff for the changelog [16:08:12] sounds useful [16:08:33] btw, does Github have a limit for total size of the releases? [16:08:45] we have had 1141 releases [16:08:50] each 250MB [16:11:30] Should be fair-use [16:11:31] https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/about-releases#storage-and-bandwidth-quotas [16:14:57] that doesn't say anything about all the releases combined though [16:15:45] that's why I meant, we are at more than 200GB I guess [16:16:57] what* [16:19:32] https://docs.github.com/en/free-pro-team@latest/github/managing-large-files/what-is-my-disk-quota [16:19:36] https://docs.github.com/en/free-pro-team@latest/github/managing-large-files/distributing-large-binaries [16:20:01] Looking at those it seems they don't have an actual hard limit but they will contact you if they notice it gets too crazy [16:20:11] ah ok [16:20:23] I guess if it becomes necessary we can clean up [16:21:45] Yeah, eventually I think we should make a new release with every commit. If you want something that bleeding edge you can compile it yourself. [16:22:03] At the most we could provide nightly for like the last 10 commits [16:23:38] But I don't really have the time to dive into all that right now. But after the release of 8 I definitely want to make some improvements in our workflow. [16:24:00] And it start with renaming Orbiter 2016 to develop [16:33:57] I also saw this feature pop up the other day: https://github.com/orbiternassp/NASSP/discussions [16:34:13] Probably not that useful for us since we are on the Orbiter forum anyway. [16:34:29] Would've been useful if it popped up two years ago I guess [17:08:56] hey [17:14:59] Hey Alex [17:34:08] morning! [17:42:01] Hey Mike. [17:42:08] I'm out for a couple hours, be back later tonight [17:53:12] hey guys [17:53:34] AlexB_88, I'M thinking about what we talked a while ago, a more permanent solution for saving RTCC MFD data [17:53:58] the easiest solution is probably to load a MCC vessel [17:54:40] it could be created by the MFD, if it doesn't already exist in the scenario [18:01:00] ah yes [18:01:26] now with the VC being usable it would definitely help [18:02:13] of course the VCs can have MFDs defined, but I would really like to avoid that [18:02:19] right [18:02:28] too much of an immersion kill [18:02:29] and it would work as if the MCC is always on [18:02:40] but with mission and ground tracking disabled [18:03:05] MCC and RTCC MFD would share an instance of the RTCC class [18:03:36] which means you could manipulate the RTCC state with the MFD in such a way that the MCC breaks [18:04:31] right now MCC and RTCC MFD have separated RTCC instances [18:04:40] separate* [18:05:03] not sure if this could be a problem [18:08:19] I mean, I guess you would sometimes use the RTCC MFD in a scenario with the MCC running to e.g. uplink a state vector [18:08:41] you wouldn't really use the MFD a lot in a MCC scenario [20:17:21] I need spend some time learning the whole RTCC input thing. [20:24:01] you only need it if you want to use the mission planning features [20:28:53] and I consider it to be work-in-progress enough so that I'm not advertising all its features to the general NASSP user yet [20:29:04] that said, feel free to ask any questions about it [20:39:47] yeah, I just haven't played around with it much yet. it looks fun to play around with and really powerful tool, if you wanted to do something outside of the historical missions [20:53:32] I've been thinking about some ways to make a non-stiff (or less stiff) pressure regulator [21:02:09] it may be as simple as trapezoid method at small timestep, and a fixed value at larger ones. [22:41:30] I'm back [23:06:32] hey [23:06:54] long day? [23:10:42] Yeah. It's alright though. I'm part of the Dutch Red Cross' regional signal service so on Thursday evenings I usually head out there to work on equipment or other stuff. [23:11:59] Tonight I took apart some Intel NUC's to bring out the front panel header so we can connect an external power switch since they'll be hidden behind a panel, After that I spend some time debugging a mobile radio and repeater. [23:19:32] Anyway, I'm off to bed now. I'll be around tomorrow evening sometime. Will be at college tomorrow and I haven't set up ZNC so I can access it remotely. [23:33:37] sounds cool. night!