[22:53:02] NASSP Logging has been started by gondos [22:53:04] ok, I got it, was looking at vapor_mass *after* boiling so the values where off. it was indeed zero before it... I just put an air_volume !=0 check to fix it then. [02:50:58] .tell indy91 well I missed a whole bunch of systems discussion earlier... [14:04:53] hey [15:02:21] morning! [15:03:54] hey Mike [15:04:05] got a suggestion for a mouse, mine is failing... [15:04:55] drag and drop is dangerous, it doesn't hold the click anymore :D [15:23:40] hahaha [15:23:56] yeah that is very dangerous [15:24:35] I'm left handed if you didn't know, so that already limits my options [15:24:46] I don't really have any suggestions... I'm currently just using a small mobile mouse with my laptop and haven't bought a new mouse in a long time [15:24:47] the cheaper mouses are better for me they are usually symmetrical :D [15:24:51] haha [15:24:54] oh I did not know, yeah that limits things a lot [15:24:56] haha [15:28:33] I kind of thought I should buy the "next best" one, a small upgrade, if I have to buy a mouse. But I should probably get one where I won't be disappointed with how much I spent if it turns out to be garbage [15:39:25] the Microsoft joystick I have is very nice and form fitting... for right handed people. Using it for longer periods of time doesn't feel so nice. [15:57:38] hey [16:17:48] hey Matt. Did you read what we talked about last night? [16:30:15] I did. the divide by 0 part seems easy enough to fix [16:33:01] the code there is essentially calculating idea gas law properties, but with the two-phase stuff it's very similar to van der waals state equation [16:33:22] it's horrible to read though. could be cleaned up [16:34:12] I think my long-standing specific heat PR fixes some of that iirc [16:34:36] or maybe I intended to...not sure [16:42:48] yeah, the code does some weird stuff [16:42:59] stuff I would expect from the AGC code to not have to use an additional variable :D [17:22:33] Hey [17:25:47] hello real time sleep period simulation man [17:38:13] :D [17:38:18] Nice title [17:39:01] G&N power up includes P51 and 52 right? [17:40:04] I don't think so [17:40:09] P51 comes an hour later [17:40:49] After damping rates [17:40:50] Oka [17:41:04] :facepalm: [17:41:17] Didnt´t press the DN button on the checklist :D [17:41:28] If I saw it, I would have not asked [17:43:42] the Checklist MFD isn't so bad that it would just skip a P51 and expect you to do it :D [17:44:07] damp rates finally is a relevant point [17:44:19] although with gravity gradient torque it already was before [17:44:29] Yeah [18:16:45] WOAAAAAHHHH!! : [18:16:47] https://prnt.sc/zdpvlKyVKqck [18:16:59] <3 <3 <3 <3 <3 [18:17:16] is that the Nile Delta? [18:17:25] Affirm [18:21:30] What is the inclination for Apollo 9? [18:21:40] changes often [18:21:42] Orbital inclination, I mean... [18:22:05] a lot of the SPS burns are out of plane and change it [18:22:11] Did it get to 35 or a little more ? [18:22:19] don't think so [18:22:25] Oh [18:22:55] at launch about 32.5 [18:22:59] Yeah, but if I passed over the Nile delta, maybe I can pass over Gibraltar or so, thus making Iberia a little visible [18:23:07] The southern part [18:23:11] That would be cool [18:23:19] the peak inclination was apparently after the docked DPS burn [18:23:23] 33.97° [18:23:35] end of mission 33.52 [18:23:59] SPS-3 increased it the most [18:24:32] That is Casablanca.... Canary island definitely visible [18:24:48] Maybe the southern part of iberia is visible... [18:24:57] *Canary Islands [18:31:12] Northern Germany... maybe ASTP or Skylab :D [18:31:49] ASTP was the same inclination as the ISS and any Shuttle launch [18:32:02] I've seen the Shuttle during rendezvous, trailing the ISS, a bunch of times [18:35:10] Yeah, me too [18:35:27] When I was young :D [18:35:34] Maybe on STS-118 [18:36:18] The inclination for ASTP was because of the Baikonur latitude, I imagine [18:36:28] yeah [18:36:31] same as for the ISS [18:36:36] yeah [18:36:48] Skylab was 50° [18:36:55] Where was MIR launched from? [18:37:02] just to cover more of the world than Apollo [18:37:20] Or is the MIR inclination incorrect on Orbiter? [18:37:34] I think Mir was the same [18:37:37] also Salyut [18:37:57] there was a Soyuz mission when they transitioned from Salyut to Mir [18:38:22] it flew to the Mir, undocked flew to the last Salyut, and then back to the Mir bringing over a lot of stuff :D [18:39:05] https://en.wikipedia.org/wiki/Soyuz_T-15 [18:39:15] Wow [18:39:30] Don´t know much about Mir or Salyut myself... [18:39:32] so they must have been in very similar orbits, in terms of orbital plane [18:51:39] https://web.archive.org/web/20070811092717if_/http://spaceflight.nasa.gov/gallery/audio/shuttle/sts-95/wave/fd10.wav [19:04:46] Good morning, Houston [19:34:49] ah, no more sleep period simulator [19:35:25] Yeah [19:35:32] But training session in complete [19:35:34] *is [19:35:39] at GET 19:05 [19:35:44] hours [19:45:35] Leaving for a real sleep period [19:45:43] Good night / day ! [15:31:07] GODD GOOD WX [15:31:15] Hey, good afternoon :D [15:45:37] indy91 I saw that the "Gumdrop" spacecraft is not created yet. Could it contribute to the viewport dancing issue? [15:56:38] I'm not sure what you mean [15:59:16] Gumdrop is the name of the Saturn/CSM vessel in the Apollo 9 launch scenario [15:59:17] https://prnt.sc/E497GyPq0scQ [15:59:26] I mean that [15:59:30] uhh [15:59:36] Gumdrop gets created after the first undock? [15:59:48] You must be using an old NASSP install [15:59:58] uhh [16:00:20] 1894 I think [16:00:24] it got changed at the beginning of February [16:00:39] Did you maybe not start from the T-4h scenario? [16:01:57] I got this one [16:02:00] https://pastebin.com/LWpzFK3g [16:02:05] I am sure that I am on 1894 [16:02:28] But yeah, scenario is "Apollo 9 MCC - Launch.scn" [16:02:42] and modified "dec 17 2021 15:45" [16:02:55] As the other MCC scenarios [16:03:12] oooh [16:03:21] There are no more scenarios named MCC [16:03:39] I think this wasn't very clever from us [16:03:43] Uhhh [16:03:44] https://prnt.sc/FtpERWLJgUv7 [16:03:46] we deleted the non-MCC scenarios [16:03:47] Yeah [16:03:52] Where are them? [16:03:55] :D [16:03:59] OOPS [16:04:09] and renamed the MCC scenarios to what previously were the non-MCC scenarios [16:04:13] so just got rid of the MCC in the file [16:04:15] 8, I did it with the dec 17 scenario [16:04:29] but when you install the most recent NASSP zip file on top of it [16:04:41] then you keep the old MCC scenarios that don't get updated anymore [16:04:43] Are there many changes? Am I bugged? :spinnermodenebaled: [16:05:30] Time for P51 [16:05:35] it should be fine [16:05:53] I would suggest deleting those 5 scenarios with MCC in the name right now [16:05:58] Apollo 7-11 [16:06:09] they won't be updated anymore [16:06:23] Aha [16:06:31] But my current scenario is fine? [16:06:34] as they aren't even part of NASSP anymore [16:06:38] yes, it's backward compatible [16:06:50] and the viewpoint bug doesn't have anything to do with it [16:06:59] that's a bad acceleration calculation when docked [16:07:30] https://pastebin.com/YFcX3Ehc [16:08:20] I don't need to check the scenario [16:08:35] the main change is AS-504 to Gumdrop in the more recent launch scenario [16:09:02] but I didn't remove AS-504 anywhere from the code, so it still recognizes it as Apollo 9 [16:09:18] and don't try renaming it in your scenario [16:09:45] that's one easy way to actually break it :D [16:10:00] because you would have to rename a few things in the scenario then [16:10:25] just get rid of the old scenarios and when you next fly the mission you will get Gumdrop instead of AS-504 [16:10:55] morning! [16:11:29] hey Mike [16:12:23] Hey sir [16:13:12] indy91 Noted everything [16:13:16] Thanks! [16:13:58] indy91 Deleted with Shift+Delete [16:17:10] so now in your main NASSP scenario folder you have scenarios named like [16:17:15] Apollo 9 - Launch.scn [16:17:17] and nothing else [16:17:55] Correct [16:19:19] I think that you already explained me; What is the stroking percentage for the SPS burn? [16:20:59] that's the maximum amplitude of the stroking test commands that are added to your TVC commands [16:22:09] aha [16:22:18] Amplitude as in a signal [16:22:32] stroking test wiggles the SPS [16:22:33] *an analog signal [16:23:17] and how much of an angle it wiggles it back and forth, that is the percentage [16:24:01] Aha [16:24:29] https://i.imgur.com/HRXG1KQ.png [16:25:07] That is 80 %? [16:25:14] ESTROKER is the variable used to control it, that's what you manually change in the memory [16:25:18] I think this is 100% [16:25:30] ESTROKE = 5 is 100%. 2 is 40% [16:25:36] I think you use 2 for SPS-2 [16:25:43] Yep [16:25:52] 0.02 radians is about 1° [16:26:31] in NASSP you don't see too much from this test as there is no propellant sloshing [16:26:53] I think it causes a bit of back and forth, 0.2°/s or so [16:27:33] We´ll see if it´s visible on the GPI [16:27:46] 29 minutes for that [16:27:55] also not a lot I believe [16:28:07] the GPI needles have a limit how fast they can move [16:28:22] not sure if that limit is correct, but I believe it is slightly slower than the stroke test commands [16:58:44] https://prnt.sc/AEKElR_Cx8VV [16:58:50] Does this include a V66? [17:01:28] if it says so it should uplink a V66 [17:05:53] All rightie [17:32:00] GET 21:10:00 340 lbs average on the quads [17:32:20] Am I good? Or I am low? As I am thinking that I am using too much RCS [17:32:25] The LM is heavy! [17:32:38] Docking went fine, I think... [17:43:06] I'm not finding the graphs I have for other missions [17:43:17] but I can tell you some numbers [17:43:19] before SPS-2 [17:43:38] predicted RCS used so far is 160 lb [17:43:43] actual was 195 [17:44:17] Aha [17:44:18] So on average you used 60 lb so far? which would be 240 [17:44:30] or how much RCS do you launch with [17:44:41] 400 I think, on launch [17:45:01] So I used 60 lbs average [17:45:51] So I am fine! [17:47:00] indy91 One think [17:47:10] I am talking with him, you know who [17:47:30] The label on panel 13... you know... it´s mirrored [17:47:48] well you used 240, which is more than you should, but still fine, yes [17:58:37] not much I can do there [17:58:49] Was a joke indy91 :D [17:58:53] if there isn't one yet, best create an issue on Github [18:02:21] Going to dinner; The P52 align check procedure is not my friend... Will need to practise that more, but I think that I am fine for SPS-2 [18:06:15] what's the problem with the procedure? [18:06:53] you manually select a star there it seems. Which ones are you selecting? [18:20:43] The ones that I see close to the optics zero position [18:21:27] And like three or four sets of the same [18:21:30] And time :D [18:22:11] But I think that I understand now... I can move the optics to the star that I like and then indicate to P52 wich one I liked, right? [18:22:34] And the check basically consists in putting the optics to CMC and see if they move to where they should [18:22:45] But... Why 3 or four reprtitions? [18:22:53] *Repetitions [18:22:57] of pairs... [18:24:38] no idea why the repetitions [18:24:45] Yeah... [18:24:51] but I think it's in the procedures [18:24:56] Is the part that I don´t get, really [18:25:00] flight plan page 4-18 [18:25:35] now that I read this [18:25:51] there are 3 of these alignment checks during the mission [18:26:03] maybe the repetitions aren't meant to be done in one of these checks [18:26:14] but it means the same procedure is to be used for test 2 and 3 [18:26:35] althoug [18:26:37] h [18:26:47] "two different star pairs are desired for each alignment check" [18:31:37] So... I may have done it right [18:31:55] The first test I failed [18:31:56] The second i did, but then I "failed" [18:32:12] what do you mean failed? [18:32:17] Got the "Cannot move optics there, too far away" alarm [18:32:22] Don´t remember the alarm code [18:32:35] then you should only select stars that are visible :D [18:32:48] So, I did it right :) [18:33:18] On this second test, when I got the alarm, was when I was doing the "second repetition" [18:33:27] Because I didn´t want to use the same starts [18:33:34] So I moved the optics around [18:33:42] From their zero position [18:33:52] Don´t know if I am explaining myself... [18:34:26] right, but if you are close to the limit then you might see a star in the telescope but the sextant can't point at it directly [18:34:35] Yeah [18:34:42] Wich alarm code was that, BTW? [18:35:44] I think 407 [18:37:29] Yeah [18:49:19] Go for SPS-2 [18:56:32] SPS-2 complete. Saw the stroking on the GPI. Orbit 188.1 * 102.8. Ins´t it a bit low? [19:00:33] A bit, but V82 might not give the exact values [19:01:26] I'm already seeing something I want to change about the SPS-2 targeting though haha [19:02:04] the burn happens at 64°W, that is from the mission report [19:02:18] but in the RTCC calculation that is the impulsive maneuver point [19:02:39] when a finite burn is calculated from that, the actual TIG is 4° different [19:02:50] aha [19:02:52] TIG would be 1 minute later [19:02:53] 4º [19:02:58] That is much... [19:03:00] no? [19:03:08] well, this is a plane change burn mostly [19:03:57] so the difference in final orbit isn't that much [19:07:00] Something special for SPS-3 [19:07:23] ? [19:07:50] MTVC! [19:08:36] yeah [19:08:44] brb [19:15:26] Back [19:15:43] So MTVC was attitude control, with RHC, by moving the engine bell [19:15:48] IIRC [19:15:58] yes [19:16:15] And control should be done by tapping the keys, if using the numpad as I am [19:16:17] if you use Numpad you can't have Direct RCS on [19:16:22] or else it will try to use RCS [19:16:24] Can´t have... [19:16:25] oh... [19:16:32] OK, I take notes [19:17:03] Maybe that is why I got the RCS hotfire suring 8´s boost ? [19:17:12] *during [19:17:45] could be [19:18:01] Didnñt get from MCC the SPS-3 gimbal angels; I am at 22:34 GET [19:18:07] (:00) [19:19:08] Didn´t* [19:19:44] That isn't implemented [19:19:52] Oka [19:20:41] those IMU angles are given so that you could already maneuver to the burn attitude [19:21:06] That is nice [19:21:09] but the burn attitude for the three maneuvers isn't very different from each other [19:21:24] 022:20:05 Roosa: Roger. Reading: roll 024, pitch 001, yaw 353. [Pause] [19:21:29] that would be for SPS-3 [19:21:33] with the SPS-2 REFSMMAT [19:21:44] 025:27:25 Roosa: Roger. Roll 017, Pitch 001, yaw 355. [19:21:51] and that for SPS-4 with the SPS-3 REFSMMAT [19:22:04] should be fairly similar in NASSP [19:22:24] Ok; I moved my yaw accidentally to almost Gimbal lock [19:22:40] Because I typed "Didn´t" on Orbiter [19:22:49] ? [19:22:56] how does that move your attitude [19:23:00] T [19:23:05] And also being distracted [19:23:09] :D [19:23:10] Can't be, you don't even have that button [19:23:28] Yes, i Do: "TTTTTTT" [19:24:03] our MCC doesn't really use the MPT yet. So to give you the IMU angles early it would need to calculate the maneuvers twice. Once when you get the attitude and then for the proper update with Maneuver PAD [19:24:13] I think that is why I never implemented that update [19:27:58] But I will at some point of course, in some shape [19:28:53] Saturday is for another sleep period sim :D [19:29:14] During those I just have Orbiter on the background [19:29:21] and do other stuff [19:29:27] I am not that insane :D [19:31:00] And sunday, hopefully to enter the LM! (GET 40 to 47) [19:31:14] Can´t wait [19:34:48] 50 pages of LM AOH every day, that's your assignment haha [19:34:56] ^Okay [19:35:18] What do I say to my boss? [19:36:28] it doesn't take a whole day to read 50 pages [19:36:52] I am not a reader [19:36:59] So yeah, it can take ;D [19:37:16] I haven't found an audiobook version yet [19:37:19] https://www.hq.nasa.gov/alsj/LM-intro.pdf What about this one to start? [19:37:56] wow [19:38:01] you really aren't a reader [19:38:11] that's nice pictures, but with little context :D [19:38:31] ROFL [19:38:42] Didnñt scroll down after posting the link [19:38:49] *Didn´t [19:38:52] and from 1966 [19:38:55] which is ok I guess [19:39:00] not outdated in too many ways [19:39:02] Yeah :D [19:39:23] there is a LM vehicle familiarization manual [19:39:28] which is only 150 pages [19:39:36] kind of a short version of the AOH [19:39:50] AOH is 800 pages [19:40:46] Link for both was? [19:41:06] I am finding various for AOH... Not sure wich one is the correct [19:41:14] https://de.scribd.com/document/43824384/Apollo-Operations-Handbook-LM-6-Vol-1 [19:41:26] That is sadly on scribd, but the best version to read [19:41:37] as it is for LM-6 [19:41:47] ALSJ only has the J-type mission one [19:41:52] which has differences [19:42:29] Another doc from the future :D [19:42:33] But you can download from scribd, too, just need to log in [19:42:38] Okay [19:42:44] we have the LM-3 AOH, too [19:42:59] LM-3 seems familiar [19:43:09] https://www.ibiblio.org/apollo/Documents/LM-3_Apollo_Operations_Handbook_Vol_I.pdf [19:43:30] our LM does not account for all differences between the various LMs [19:43:37] That was the one I was looking for. Thanks! [19:43:44] so LM-6 is closer to what we have in NASSP than LM-3 [19:43:56] I think that you have plans for it, right? [19:44:16] not really for the remaining differences [19:44:32] it's mainly differences that require a different panel [19:44:51] caution and warning lights for example [19:45:24] Yeah [19:45:58] like the Rough Combustion Cutoff Assembly [19:46:06] which stops the DPS engine if it has problems [19:46:12] there is one switch associated with that [19:46:20] and only Apollo 9 had the system and the switch [19:46:28] it's not implemented in NASSP [19:46:55] oh [19:46:58] it's for the APS [19:46:59] not DPS [19:47:11] see, that's how much I know about it :D [19:47:24] haha [19:47:34] and the AOH doesn't talk too much about AGS software, but we don't have that one either [19:47:45] we use the Apollo 11 software for 9 to 11 [19:49:09] Oh! COAS = Crew Optical Alignment Scope! [19:49:19] You always learn something every day [19:49:44] AGS scares me [19:50:09] It´s the "Other DSKY" right? [19:50:25] AGS is the whole system [19:50:28] it goes like [19:50:32] PGNS and AGS [19:50:36] LGC and AEA [19:50:40] DSKY and DEDA [19:50:46] IMU and ASA [19:50:52] any questions? :D [19:51:25] https://www.youtube.com/watch?v=S7qu-GqQDJw <3 [19:52:28] https://history.nasa.gov/afj/ap13fj/photos/deda.jpg [19:52:41] DEDA ? The other DSKY :d [19:53:05] yeah [19:53:27] the first burn you will do with the LM will be using the AGS [19:53:32] during rendezvous [19:53:36] Interesting [19:53:41] docked DPS burn of course is 2 days earlier [19:53:50] I will have a lot of fun with 9, it seems :D [19:53:55] and you will likely run into some problems [19:54:00] using the AGS is difficult [19:54:04] But it´s a hard one, it also seems [19:54:22] just need to learn the LM fully [19:54:32] Before Octuber :D [19:54:59] and then we can have Oktoberfest [19:55:23] And hopefully don´t forget everything [19:55:29] who needs that [19:55:33] Southern Germans maybe [19:55:38] ahaha [19:55:47] I though it was the whole Germany [19:55:49] I have been at the Oktoberfest though [19:55:54] Me never [19:56:00] on a school trip [19:56:09] and it wasn't optional, we went there with the teacher [19:56:11] no joke [19:56:16] We do something here to celebrate that period of year... [19:56:32] well people like drinking. So there are some imitation Oktoberfests even in Northern Germany [19:56:38] With the teacher? That is not fun at all... [19:57:23] that teacher got drunk one night so much that we thought we couldn't continue our program the next day [19:58:59] I didn't like the Oktoberfest. Too crowded, you couldn't find a place at a table, the beer is terribly expensive. It wasn't all full of puke yet, I think that is only at night... [19:59:10] Yeah [19:59:13] I can imagine... [19:59:44] Going to a traditional place like the Hofbräuhaus in Munich was a lot better [20:00:05] Also during that school trip, but we were 18 already :D [20:00:23] Too much people and party at one place can for sure ruin the enjoyment... [20:02:05] I'll take the beer though [20:03:44] Yeah [20:04:45] But in quieter places... [20:04:52] You can do this kind of stuff: [20:04:54] https://prnt.sc/F7r7TvdiYjc5 [20:13:58] Well guys [20:14:02] Time4bed [20:14:10] Thanks for the documents! [20:14:26] See you tomorrow [20:15:56] cya [20:16:09] good picture [20:16:37] :D [20:16:39] Bye [20:17:08] I'll also log off, getting a bit of a headache. cya! [13:25:42] good morning [13:26:46] hey [14:57:27] else if (CSMrelang > 100*RAD) //CSM body shadowing the antenna [14:57:39] n7275, we found a case where this HGA value doesn't work right :D [14:58:51] that one's going to haunt me forever isn't it haha [14:59:42] of course [15:00:21] and that would be the CSM skin reflection area, right? [15:00:32] 100° is probably a bit to narrow [15:00:34] yes [15:00:36] shadow zone would be with the scan limits [15:01:36] with a single angle it's like the HGA is on the surface of a sphere rather than a cylinder [15:03:01] looking at some CSM Data Book graphs, I feel like there should be a single angle that is the right threshold [15:03:10] but maybe not using CSMRelAng [15:04:39] correct [15:06:27] https://i.imgur.com/MRgb3Fy.png [15:06:29] could be a simple as sqrt(pitch^2+yaw^2)<35deg [15:06:34] 45° of theta? [15:07:15] but I don't quite get this yet [15:07:56] oh maybe I do [15:08:11] I thought that point the CSM straight at the Earth and using 0° for pitch and yaw works [15:08:15] pointing* [15:08:22] but apparently that is in the interference zone [15:08:27] yes [15:09:44] so if the pointing vector of the HGA is within 45deg of the x axis of the CSM there will be a reflection [15:11:30] CSMrelang is only used for this one calculation? [15:11:40] Did you add that or was that my old code [15:11:46] Vector math brain activate [15:13:36] I added it [15:19:04] I'll do a bit of rewriting if you don't mind [15:19:21] nothing major, just making it clearer (for me) [15:22:18] I had to draw so many pictures for that project [15:22:26] don't mind at all [15:27:19] hi huy, computing link budget for the HGA? [15:27:28] *guys [15:27:49] hey [15:27:51] haha [15:28:01] when the HGA points at the CSM itself it doesn't work [15:28:07] and we don't quite simulate that right it seems [15:28:10] in some rare cases [15:28:30] lol, the kind of cases nobody would notice [15:28:37] so you have to fix it :p [15:29:20] yeah, someone on Discord is flying Apollo 15 [15:29:37] and there is one attitude, with some handwritten angles for the HGA in the flight plan [15:30:04] and that attitude is 1° above the threshold where the HGA in NASSP stops working :D [15:30:12] lol [15:30:54] 1°, you just quantified the difference between theory and practice [15:31:01] ^^ [15:31:59] yeah, well in practice it would probably not stop instantly at a specific angle, but the signal gradually gets worse [15:32:11] might even need to simulate that, have to see [15:32:12] btw regarding the pressure thing, I think there is a mismatch in the Antoine equation : https://en.wikipedia.org/wiki/Antoine_equation [15:32:37] it's using log10 in the formula but NASSP uses exp instead of pow(10,xx) [15:32:46] n7275, I'll take care of the HGA, you can talk to gondos about the systems simulation :P [15:33:59] nah, all systems are green now :p [15:34:31] my next issue is with the camera going wild on stage separation but I don't think it's a bug on your side [15:35:10] if it turns out it is, i won't fail to notify you ;) [15:35:43] camera goes wild during the whole launch really [15:38:16] n7275, this new relative angle calculation results in 51.8° [15:38:27] so well above the 45° [15:38:32] if 45° is correct there [15:39:06] "The high-gain antenna can track into the [15:39:06] skin reflectivity region; however, acquisition may not be possible in that region" [15:40:08] yeah, not a great implementation of that then [15:42:19] just my 2 cents, when the antenna goes past the angle, it should only introduce a bit of masking (lower signal) and the reflected signal will add phase interference (lower C/N0), but it should not actually cut the signal completly [15:42:40] good luck modelising that... [15:42:46] *modeling [15:44:15] btw [15:44:16] relang = acos(dotp(U_R, unit(R_E - pos)))-0.9*RAD; [15:44:21] where does the 0.9° come from? [15:44:55] is that some offset from where the HGA is pointing to where the maximum signal strength is? [15:45:44] uuuuuh good question [15:46:41] have to look into that one a bit to answer better [15:47:16] Hola [15:48:05] https://github.com/orbiternassp/NASSP/commit/9bba6b54b734b701d25dd492102d5c8d572fe095 [15:48:08] hey [15:48:42] gondos, the Antoine coefficients we're converted to natural log iirc [15:49:09] ah, nice to know:) [15:58:04] indy91 oh I know now [15:58:14] 45° should be right, that's the number the chart in the CSM Systems Handbook also gives [16:00:45] I'll leave the rest of the logic as it is right now. Gradual loss of tracking and such can come later. [16:01:10] the antennas point in different directions, but when they're locked into the earth, they a signal strength that is consistent with a 1 deg error [16:01:21] but they shouldn't [16:02:22] ah [16:02:28] thought it was something like that [16:03:48] and the real one doesn't use differential signal strengths, it uses phase sum and difference [16:04:26] but what we have is just a simpler way to write the same math [16:05:24] right [16:18:42] TTCA = Thrust Translation Controller Assembly [16:18:47] Throttle is there, too? [16:22:33] yes [16:22:55] in reality there was a lever to switch between RCS (jets) in the "up/down" axis and throttle [16:23:14] I think that it is shown on the Apollo 13 movie... [16:23:23] That lever, I think [16:23:41] if you use keyboard only, the throttle is controlled with the Orbiter hover engine controls [16:23:59] 0 and . [16:24:01] yep [16:24:09] if you assign a joystick specifically as a TTCA, then it simulates it the proper way [16:24:33] then one joystick axis controls the throttle [16:24:46] and the lever on the joystick switches between the two modes [16:26:00] And could you configure a deadzone for the throttles? [16:26:05] *Throttle [16:26:17] As joysticks can be noisy [16:26:40] And you just reminded me that is the reason why I don´t use a joystick in orbiter [16:27:13] no deadzone, aside from maybe one that is part of the actual TTCA [16:27:17] Noysy joystick = inadverted RCS pulses, at least with Deltagliders or things like that... [16:27:32] Yeah, a lot of people have trouble with their yaw axis on the joystick [16:27:43] if the joystick isn't very precise [16:28:12] There is some procedural things you need to do if you aren't using a joystick as the ACA [16:28:32] because keyboard = full deflection of ACA [16:28:33] morning! [16:28:38] hey [16:28:42] hey Mike [16:29:08] Only problems with yaw @indy? [16:29:30] Because it may depend on wich pot is dirty [16:35:34] Sps-3 is long! :D [16:36:37] the yaw axis on most joysticks is a bit different than pitch and roll [16:36:53] I don't know, I never had this problem [16:37:29] so if you use keyboard, you want the left ACA/4 Jet switch in the disabled position for most of the time [16:37:35] that is like Direct RCS in the CSM [16:38:12] and maybe, that is more of a preference, you want a lower ACA rate setting in V48 [16:38:24] hmmmm [16:38:47] I can give the LM a try with the joystick for Apollo 9 [16:38:50] CSM too [16:39:11] I would definitely recommend trying that at least [16:39:18] Would be a nice last spin with it before I migrate to a Warthog :D [16:39:51] the Warthog doesn't even have a yaw control on the joystick, right? [16:40:11] only rudder pedals? [16:41:18] WANT THIS: https://youtu.be/tB3g2jZ4vYc?t=940 [16:41:46] indy91I think it doesn´t... but may depend on the grip you choose... [16:42:00] in the CSM only the SCS uses the proportional output from the RHC [16:42:12] the CMC it's only on/off at a certain deflection [16:42:30] but the LGC does use the proportional deflection as input [16:42:40] that's why the maximum ACA rate with the LGC is pretty high [16:42:46] you usually have that set at 20°/s [16:43:00] and then it's a quadratic function, deflection vs. rate [16:43:08] so a small deflection is still a pretty small rate [16:43:30] when I use keyboard I change the ACA rate to 4°/s in V48 [16:43:42] and then just do all manual attitude maneuvers at 4°/s [16:46:54] alternatively use the minimum impulse modes of PGNS or AGS [16:47:00] one sec [16:47:03] Now I read... [16:55:11] I will definitely test with the Joystick [16:55:25] Will ask for config [16:56:02] Better said, I´ll test with the HOTAS [16:56:11] fairly simple. Check the RHC/ACA enabled box [16:56:28] in the NASSP configuration menu [16:56:47] Need to enable it under Orbiter? [16:57:02] no [16:57:07] Okay [16:57:39] it must be disabled even [16:57:50] at least that's what the angry red text says [16:58:19] Angry red text... [16:58:45] you'll see when you enable the joystick for NASSP [16:58:50] Good idea! for the truckers that expect the screen to read the barcodes, insted of the barcode reader [16:58:53] :D [16:59:11] "READ THE DAMN BARCODE THROUGH THE BARCODE READER, NOT THE SCREEN" [16:59:45] The "damn" word is important, too [17:02:25] only damned barcodes, no normal ones [17:02:55] No, no [17:03:14] Any barcode, combined with a stupid user, AKA trucker :D [17:03:44] https://prnt.sc/0QfE-2FhU7rs [17:03:48] Checklist typo? [17:04:20] yes [17:04:32] tell that to Ryan on Discord, checklists aren't my department :D [17:06:01] since I also joined Discord he has never been here anymore haha [17:06:13] :D [17:10:25] Lots of user interaction issues at my job. Too much issues related with user interaction / User experience [17:10:40] Bad for mental health :D and faith in mankind [17:13:39] have you tried turning it off and on again? [17:13:49] hahaha [17:14:07] Have you tried READING THE SCREEN ? :D [17:15:45] Yeah but our apps have UX issues... We are trying to fix them. They are old and they are "inherited" old code an old team before us did [17:20:27] Another off-plane burn, to the north! [17:20:39] And a long one... [17:20:47] Inclination after SPS-3? [17:25:50] mission report says 33.82° [17:27:52] Direct switches to off for MTVC with keyboard, right? [17:27:59] yes [17:28:47] That is about tunis´s latitude [17:35:31] Do I have to use the asterisk for cutoff? [17:35:51] which cutoff [17:36:02] Engine cutoff [17:36:06] at MTVC [17:36:08] SPS? [17:36:09] yeah [17:36:14] isn't it auto shutdown? [17:36:35] I am thinking that it should, but just in case... [17:36:40] asterisk can be used, in the VC it can be tricky clicking a switch on time [17:36:52] asterisk switches DV switch to off [17:37:14] DV Thrust I mean [17:37:39] both switches to off [17:38:05] that is basically the manual cutoff method [17:38:11] yeah [17:38:24] But it should auto shutdown on SPS-3, right? [17:38:49] Saw the stroking again; It´s fun :D [17:40:20] yes, auto shutdown [17:40:50] the only reason the Apollo 7 SPS-5 wasn't an auto shutdown is that the DVC for the EMS on the Maneuver PAD was set to 100 ft/s higher than necessary [17:40:59] on purpose [17:41:06] so that you have to cut off manually [17:41:26] to test it [17:41:30] Oh boy! [17:41:34] What a ride [17:41:35] :S [17:41:38] :D [17:41:44] to test how accurately astronauts could do it [17:41:53] Have to test this with joystick [17:41:54] but with DV set 100 ft/s it would still cut off there [17:42:16] maybe we implemented this feature with the key for SPS cutoff after watching you fail :D [17:42:25] Yeah [17:43:42] https://prnt.sc/j0H8X6_m7djk [17:43:48] SPS-3 residuals [17:43:53] Very high :C [17:44:21] practice makes perfect [17:44:28] Yeah [17:46:20] n7275, https://github.com/orbiternassp/NASSP/pull/792 [18:11:40] I will test that out tonight [18:12:27] this got scanned fairly quickly https://archive.computerhistory.org/resources/access/text/2022/06/102775895-05-01-acc.pdf [18:24:32] oh nice! [18:32:16] Maybe stupid question [18:32:41] How was the TTCA used during landing? If you had to control throttle and translation with the same hand? [18:41:01] you don't need translation during the landing [18:41:19] there are enough space simulators/games out there these days that you'd think a rotation-translation joystick would be comercially viable [18:41:51] You control your attitude to change your forward and lateral velocity [18:42:01] As an helicopter... [18:42:04] yep [18:42:05] I see [18:42:20] Are you saying that I should also need to learn to fly helos? :D [18:42:21] fully manual landing would be ACA + throttle [18:42:41] nah, only this [18:42:43] https://en.wikipedia.org/wiki/Lunar_Landing_Research_Vehicle [18:43:37] I don´t want to bite my tongue :D [18:43:46] Are you working on one??? [18:44:07] no [18:44:17] I would like that as an addon for Orbiter though [18:44:26] maybe there is some old one [18:44:43] (I though Armstrong bite his tongue when he had the accident on the LLRV, but I think that is drama) [18:48:01] https://www.youtube.com/watch?v=BkIwHkwh3Ws [18:48:06] Never saw this video [18:48:33] Only the dramatizations... and maybe the last 3 seconds of the event, but many many years ago [18:54:46] would be cool to simulate [19:14:12] https://prnt.sc/l8g38yJn5PBb [19:14:41] Houston! My head is outside the spacecraft! [19:14:44] :D [20:20:00] that's never good [20:25:54] Too much fresh air [20:25:56] :D [20:37:53] Anybody happen to know what triggers the DPS/APS/SPS engine sounds in NASSP? I've managed to port the code over to XRSound and everything works except those sounds, as far as I can tell. [20:41:04] Strike that, LM Master Alarm also seems non-functional [20:41:50] sounds like it's all the custom wav files [20:42:08] anything played by an Orbitersound call [20:45:16] Maybe an issue with the WAV enconding? [20:45:58] Working on OS because it reads wavs differentry than XRSound? [20:46:56] but other things like switch sounds and CSM Master Alarm work fine [20:47:12] cabin fans, suit compressor, those all work fine too [21:05:49] strange [21:06:23] there should be some playsound() calls somewhere in the code [21:07:46] yeah, and that's what I'm having trouble finding [21:07:57] my main guess is that this is a loading order issue [21:08:24] I have to load the sounds AFTER the vessel is constructed and initialized, whereas with OrbiterSound it has to happen DURING construction [21:09:26] so I moved all the sound loading code I could find to inside clbkPostCreation() [21:09:51] my guess is that engine firing sounds and LM Master Alarm is loaded at some other point that I haven't been able to find yet [21:15:46] I can search later when I get home. (and if I remember....) [21:16:53] I think the sound file we want is "Hover_int.WAV" [21:16:59] it's in the NASSP sounds dir [21:17:06] but for whatever reason it isn't working [21:20:28] IRC for OrbiterSound you provide a parameter to tell if you want the sound to be played from cockpit view or from the outiside [21:20:47] are the non working sounds the ones that are supposed to be heard from outside the ship? [21:21:39] no [21:25:40] I actually don't know what sounds NASSP would have that play outside the ship [21:26:13] I also haven't been able to test the launch because things crash, likely due to these weird Soundlib init timing issues [21:27:49] there is a trace in xrsound : [21:27:50] VERBOSE_LOG(this, "XRSoundEngine::PlayWav ERROR: no wav loaded for soundID %d (did you forget to call LoadWav for it?)", soundID); [21:28:02] in case a sound is not loaded [21:28:27] shouldn't cause a crash [21:29:43] Okay I see a sound for ID 10025 but I have no clue what that means [21:29:54] you can activate the trace via XRSound.cfg [21:29:58] EnableVerboseLogging = 0 by default [21:33:58] okay, no errors when the engine fire sound should be happening [21:34:09] so what the heck does that mean lol [21:39:54] 10025 is the enum for Liftoff [21:40:02] probably the default sound [21:41:34] maybe you reassigned the id to a new sound but since you disabled the default ones, it doesn't play these ids [21:41:44] I didn't touch IDs [21:42:04] they're all the defaults from when we used OrbiterSound afaik [21:45:49] don't know much about OrbiterSound, even getting access to the SDK is a pain because it's distributed as an exe file :( [21:49:24] just did a global search, I cannot find any indication of an engine sound trigger whatsoever [21:49:39] at least not through the same means used to play other sound effects [21:50:42] are you preloading more than 60 sounds? [21:58:42] I dunno [21:58:49] probably not? [21:59:18] again I'm not doing much different than what we did when we used OrbiterSound [21:59:33] so as far as I know, we're sticking to the limit of 60 sounds [21:59:55] but that doesn't matter for XRSound anyways, it supports an arbitrary number of sounds [22:01:18] yep but there is a slot reallocation mecanism to handle more than 60 sounds, don't know if it is triggered [22:01:50] the hover_int sound is linked to ullage motors [22:02:05] right, but it doesn't seem linked to anything else [22:02:12] and Launch Vehicle sounds also are not playing [22:02:35] but stage sep, countdown, etc. other sounds are [22:02:56] it's just the engine sounds that aren't playing [22:03:05] well, non-RCS engines [22:03:10] RCS sounds play fine [22:03:35] but any kind of long-sustained engine sound just refuses to play and doesn't give any sort of warning about missing sounds [22:03:44] heck, I can't even find them in the first place [22:03:55] as far as Soundlib is concerned, engine sounds do not exist [22:04:11] oh, maybe it's using default engine sound from XRSound? [22:04:26] well it's trying to but if your disabled it... [22:06:02] i'll rephrase: orbiter sound adds engine sound automatically isn't it? [22:06:16] if that's the case, you must let XRSound do the same [22:06:20] I have no idea [22:06:26] I don't have a clue how OrbiterSound works [22:06:42] yep, so much for closed sourceness... [22:08:18] so how would I make XRSound play its engine sounds? [22:09:06] I guess you just don't disable them [22:10:47] they aren't disabled [22:11:04] I'm using a stock config file, except with ATC callouts disabled [22:12:15] hum, I'm confused with your OF post : [22:12:17] "after completely disabling the XRSound default config to eliminate its own sounds" [22:12:33] right, but since I was having issues I reverted to a stock config [22:12:40] ah ok [22:13:34] so yeah I don't think that's the issue [22:13:56] after all there's no way NASSP has integration for XRSounds' default sound effects anyways [22:14:33] but for the life of me, I cannot figure out where the hell the engine sounds are triggered [22:14:56] looking at deepstar vessel, they do this : [22:14:57] xrSound->LoadWav(XRSound::MainEngines, "XRSound/Deepstar/Engine.wav", XRSound::PlaybackType::BothViewFar); [22:17:36] right, but I mean how engine sound effects are triggered in NASSP [22:18:05] I can find the triggers for all the other SFX [22:18:08] but not for engines [22:18:52] Well guys, going to sleep! Tomorrow another sleep period sim :) [22:21:52] man I am just so baffled by this [22:22:34] I feel like I must be missing something because all of my searching tells me that engine sounds never existed in the first place, or were somehow handled completely externally from NASSP's sound code [22:22:43] Neither of which seems possible, IMO [22:23:15] XRSound hooks in clbkPreStep and plays the sound automatically [22:23:38] in void EngineDefaultSoundPreStep::clbkPreStep(const double simt, const double simdt, const double mjd) [22:23:56] const double totalThrustLevel = pVessel->GetThrusterGroupLevel(m_thgType); [22:23:57] if (totalThrustLevel > 0) // should sound be playing? [22:23:58] { [22:23:59] const float volume = XRSoundEngine::ComputeVariableVolume(m_minVolume, m_maxVolume, totalThrustLevel); [22:23:59] // DEV DEBUGGING ONLY: sprintf(oapiDebugString(), "Engine thrust level = %lf, volume = %f", totalThrustLevel, volume); [22:24:00] // OK if sound already playing here; if so, this call will merely change the volume [22:24:01] PlayWav(true, volume); [22:24:02] } [22:24:04] else [22:24:08] StopWav(); [22:24:46] so by adding a xrSound->LoadWav(XRSound::MainEngines, yourwavfile, XRSound::PlaybackType::BothViewFar); [22:24:51] it should play the sound automatically [22:25:33] hm, then I wonder why it's not giving me an error [22:46:18] okay so I'm doing that, and it still isn't playing engine sounds during liftoff [22:46:57] I'm going to throw in the towel for now [22:47:21] 99% of the sounds work so I'll let someone who can actually figure out how the engine sounds originally worked take care of this [22:47:41] hehe:) [22:48:02] if you wanna do it, be my guest [22:48:26] i'm on linux so I don't count :p [22:48:40] ??? [22:48:49] oh you can't build NASSP [22:48:52] right [22:49:14] I can but I cut out the sound parts [22:49:43] plus there's some DirectSound stuff around, I don't know if it's dead code [22:50:03] I commented all that out [22:51:02] yeah I dunno either [22:52:16] but yeah I've got a special OpenOrbiter branch of NASSP going which is like 90% functional [22:53:10] if you have a PR somewhere I can try to apply your patch on mt branch and see if I can get something rolling [22:53:50] sure, I'll make a draft PR [22:53:59] you got a github account link? [22:56:38] ok found it, it was quite obvious^^ [22:56:51] I'll be making a draft PR to the main repo shortly [22:57:39] ok, thx :) [22:58:08] https://github.com/orbiternassp/NASSP/pull/793 [23:00:05] ok, I'll check this out tomorow [23:00:17] good night, I'm off to sleep [23:01:22] night! [23:01:48] oh by the way, make sure when building to use the x86 Debug profile, I haven't reconfigured the projects for the Release build yet [23:02:05] don't worry, I use my own cmake files [23:05:55] sounds good [10:55:59] Buenos días [11:01:48] indy91 TTCA / ACA ready :) [11:01:55] https://prnt.sc/R2UDDLM9t4fP [11:02:50] nice Game Boy [11:03:06] Still works as the first day [11:03:30] I have the same in yellow. Gave it to my brother, but I expect it to still work, too [11:04:21] If you removed the batteries after longs periods of time yes it should... I read somewhere that some games had a battery [11:04:31] on the cartridge [11:04:34] To save [11:04:39] the game [11:04:43] yeah, probably a lot of them [11:05:16] with the joystick, I think you will know during the LM activation how good it works, with deadzones etc [11:05:28] or lack of deadzone really [11:05:50] Yeah [11:05:52] It´s less dusty that I expected [11:06:03] Not used it since january I believe... [11:06:04] does it have force feedback? Or good centering force? [11:06:13] No force feedback [11:06:30] That, on joys is Satan [11:06:37] I tell you from experience [11:06:42] I think the important bit is that it stays in the detent in neutral [11:06:43] it´s a PITA [11:06:50] It should... [11:07:08] I am concerned with the detent this trottle has at 50% [11:07:37] Could I configure one device for ACA and other for TTCA? That way I could use the Throttle quadrant too... [11:07:46] And it would be on my right hand :D [11:13:27] oh, actually, if you have a joystick as the ACA, the throttle lever can be used as throttle lever [11:13:38] a bit cheaty, bit nice to use [11:14:09] but if the throttle lever is on a different device than the joystick, I think then you need to get into VESIM [11:14:21] Aha [11:14:53] Yeah, the joystick is HOTAS so Joystick on the right hand, Throttle on the left, but same device [11:15:34] But if I could use HOTAS´s joystick device and put it to my left, and then the Saitek Throttle Quadrant (another device) to my right hand [11:15:44] But I have to use VESIM for that [11:15:48] I understand... [11:15:55] For the next Apollo 9 run! [11:15:56] :D [12:56:54] See you later guys [12:56:59] F1 and Le mans [12:57:10] And at the afternoon i´ll be away [12:57:22] Maybe at night I´ll connect to configure the HOTAS [14:29:34] hey [15:34:42] gondos, any luck so far figuring out where the original launch sounds happened? At this point I'm just trying to implement my own, I think [15:37:33] hey guys [15:38:57] CaptainSwag101, I'm not quite up to date, which sounds aren't playing? [15:39:38] Just the main engine sounds: Launch Vehicle/Booster, SPS, DPS, APS [15:39:56] and I can't even find code that plays them in the first place [15:40:07] Why would there be code? [15:40:16] They are played by Orbiter Sound [15:40:27] every other sound effect is played via code in NASSP [15:40:38] SoundName.play(); [15:40:49] well yeah. Normally Orbiter Sound does it for the engines [15:40:56] the exception are the RCS thrusters [15:40:58] well that explains why I can't figure it out [15:41:04] so how should I proceed? [15:41:12] and all those engines you are listing almost had to be exceptions, too [15:41:30] We don't want Orbiter to have control of the RCS engines for its attitude control [15:41:34] the autopilots [15:41:36] prograde and so on [15:41:53] so the RCS engines are not part of one of the defined thruster groups that Orbiter can use for that [15:41:57] XRSound seems to have the capability to play "Main Engine" sounds but I have no clue how to set that up [15:42:07] nor do I know if that's what we want [15:42:21] and the result for the RCS engines was the sound of them wasn't played for them anymore [15:42:30] so we had to play those sounds manually [15:42:43] now for all the engines you were listing, somewhat recently we made a change there, too [15:42:57] We didn't want Orbiter to have the same kind of control [15:43:14] like, previously you were able to throttle the SPS and Saturn engines manually [15:43:20] through Orbiter [15:43:48] so I changed the engine type of all of those [15:43:58] which for Orbiter Sound meant it's playing a slightly different sound [15:44:25] originally I thought I needed to make the engine type to custom engines or something like tha [15:44:28] t [15:44:29] hi [15:44:40] and then we would have also needed to play the sounds manually [15:44:53] I'm currently applying your PR in my branch [15:45:12] thg_sps = CreateThrusterGroup(th_sps, 1, THGROUP_USER); [15:45:18] does it explain the directsound stuff for the LEM. [15:45:19] so THGROUP_USER for the SPS engine [15:45:38] that's how Orbiter Sound does play a sound, but different than THGROUP_MAIN [15:45:45] if there was no thruster group at all, no sound [15:45:53] so then we would need code [15:45:58] that's how it worked under Orbiter Sound [15:46:27] I don't know how XRSound handles all this [15:46:33] maybe it has no sound for THGROUP_USER? [15:46:59] We can't go back to using the other thruster group types [15:47:20] so maybe with XRSound we need to play the sounds of all engines in our code [15:47:31] yeah that's what I'm thinking [15:47:33] but I have no idea [15:49:38] Hey guys [15:49:55] I am around here; debriefing FD3 of Apollo 8 [15:50:20] indy91 I will configure the joystick after I post [15:50:22] hello [15:50:27] *after i POST :D [15:53:09] I'm still pretty proud though, this is a bit out of my league but I managed to get things compiling and sound working mostly [15:53:34] that said, I'm also very perplexed why the Floodlights aren't working still [15:54:03] yeah, great job! [15:56:02] I just checked, XRSound does not support THGROUP_USER but it should be trivial to add [15:56:34] so it's either a PR to Orbiter or do it manually in NASSP [15:57:35] Wonder what the tradeoffs for either approach would be [15:57:42] CaptainSwag101 Are you saying... we have floodlights already? [15:57:44] obviously if we do it in NASSP it can be done quickly [15:57:49] (On OpenOrbiter) [15:58:09] TurryBoeing I'm referring to the launchpad floodlights that illuminate night launches [15:58:16] Ahhh :D [15:58:31] But we are working to add the Run/EVA/Docking lights to the CSM! [15:58:35] or rather Thymo is [15:58:56] I had read somewhere that VC floodlights don´t work because of some D3D9 client issue... [15:59:05] I have seen that for the default DG [15:59:41] interesting, wonder if it's fixed in OpenOrbiter then [15:59:57] I know they fixed that issue with the VC clickspots not working sometimes [16:00:12] has something to do with the vessel's center of gravity I think [16:01:14] oh yeah I looked deep into that issue before I noticed there was a issue on Github for it and already a fix in Open Orbiter [16:02:12] doesn't happen because of the COG specifically, but with a shifting CoG and many switches TurryBoeing got a rare cases where the clickspot calculation was bad [16:02:21] kind of random [16:02:48] indy91 once we figure out why the hell the EMS scroll texture is crashing the D3D9Client, I think it should be a superior experience to Beta R90 [16:03:04] minus the engine sounds not working at least, lol [16:03:22] but that won't be that much additional code [16:03:34] the question is, will it be a superior installation experience [16:03:47] if we get to that point, then we can really push for a NASSP 8 release actually [16:03:55] oooh [16:03:57] good point [16:07:32] Honestly I don't even know how to install OpenOrbiter aside from compiling it [16:07:42] but I will say, that experience is actually really cool once you get it working [16:08:08] there's a dedicated "install" option that builds the output directory structure perfectly and strips out debugging-related files [16:09:24] I almost got it to the point where I could compile it [16:10:13] yep, the tears of join the first time you can run your own build^^ [16:10:16] *joy [16:22:44] gondos http://www.quickmeme.com/img/5e/5eea26750df29a3a470da712460d3e449ffe4bf4d7370a161c690dcfe5ca5848.jpg [16:22:46] I think it took me 6months to get it to compile on linux:\ [16:23:01] lol [16:23:15] https://imgflip.com/i/5q0bvq [16:23:26] who needs tests when you can trun warnings off anyway :D [16:25:14] one thing for sure, orbiter does not like breakpoints... [16:25:30] the dt explodes when you unpause and everything goes to hell [16:26:25] that even happens on Windows [16:26:32] I use 0.1x time acceleration when debugging [16:26:36] lol [16:26:53] still, you need to do some hardcore speeddebugging [16:26:54] then there is at least a chance that the simulation continues right after I let it run again [16:27:38] or you can patch to enable lower accelerations [16:29:45] how long does it take to load a scenario on windows? it takes ages here... [16:29:57] I think it's the config parsing that takes so long [16:30:40] yeah, I actually found some fairly major inefficiencies in the loading code recently [16:30:47] haven't gotten around to work on that yet [16:31:28] well, the orbiter core restart from the begining of the files everytime you try to read a parameter [16:32:03] should read all at once ond put it in a map, that would speed things up [16:32:18] but since the API uses a filestream... [16:32:20] and also, our scenario files are so large not even the Orbiter Forum likes them :D [16:32:26] lol [16:32:52] you planning on putting in a yacc parser? :p [16:35:50] ah it's just too much code that is called for every line in the scenario [16:37:48] scenarios are just read once I think [16:38:01] unlike config files that are read for every parameter [16:39:08] Apollo 8 RTS GET 52:41:36: "Hey! I have a ruler here... Let´s use it..."  -> https://c.tenor.com/RXYcinC5s_AAAAAC/nodding-thumbs-up.gif [16:47:09] lol [17:54:38] I got some sound on linux by taking stuff from PR793 but I think the right way would be to get rid of SoundLib and directly call XRSound [17:55:50] it only piles up a new layer of indirection and I don't see what value it adds [18:15:47] Apollo 8 FD-3 debriefed! [18:16:07] Let´s see how the hell I debrief FD-4 tomorrow :D [18:23:04] indy91 Config for joystick for NASSP is under "Extra->Vessel Configuration", right? [18:28:08] https://prnt.sc/f6v9geCzJajR [18:28:33] Don´t understand the ID field; but would this configuration be valid for me, if only using the HOTAS? [19:03:19] TurryBoeing, ID of the joystick is for the case you have multiple devices connected to your PC [19:03:34] so in most cases it should be 0 [19:03:38] That is interesting for me [19:03:59] if you have two joysticks connected, like for RHC and THC, then you can choose which one is used for which [19:04:03] by using 0 and 1 [19:04:27] same logic for the throttle slider, most joysticks will only have one so it should be 0 [19:04:32] And only for the throttle? [19:04:46] I guess there are some that have two, for left and right engine [19:05:15] in most cases the default numbers should be fine [19:05:31] Yeah, not my case; But I have to HOTAS (one device, with throttle) and the throttle quadrant (another device, just throttle(s)) [19:05:36] unless you are called Ryan and have more flight sim equipment connected at all times than I have USB slots [19:05:48] :D [19:06:38] but you don't want to use your throttle quadrant, right? [19:06:45] you just have it connected [19:06:56] so it might be 0 or 1, hard to say, you have to try [19:07:33] If I use my throttle quadrant, I could have my joystick on the left hand, and a throttle lever on the right hand [19:07:49] Not my throttle quadrant is disconnected, yeah [19:07:53] *Now [19:08:25] for that setup you would need probably need VESIM [19:08:32] Aha [19:09:05] standard setup can only do: one device = one in-sim controller [19:09:17] Understood [19:09:35] How to control the DPS throttle manually? I was practising before with "Apollo 10 before DOI" [19:09:53] engine throttle switch in manual [19:09:54] But had no throttle control, neither with joystick or numpad [19:10:04] and engine arm to DPS [19:10:15] you probably didn't have the engine armed when you tested [19:10:32] or did you try the burn? [19:12:42] I tried to manually throttle; With 0 and . and with the throttle [19:13:09] THR CONT is in MAN, and ENG ARM is in DES [19:13:16] I think how it works is, it doesn't look at the keyboard commands if you have joystick enabled [19:13:38] But no throttle; So maybe something is bad on my config; It´s as on the screenshow above [19:13:41] Dinner now [19:13:46] Back in a bit [19:13:53] I'll load that scenario [19:15:07] ok without having joystick enabled, those two switches let me control the throttle [19:15:17] then maybe something is wrong with the config [19:15:37] what might be possible is that it detects your yaw control as a slider [19:28:41] Back on Snoopy [19:28:43] Okay [19:29:02] The slider behind my throttle moves the CMD slider [19:29:30] From 10% to 90%... [19:29:47] Is that the throttle? I Think that I am going to need VESIM :D [19:30:41] Yeah, my throttle is there, on the "Thing" behinf the throttle [19:36:59] well that's what the ID is for [19:37:06] so 1 maybe works? [19:37:11] instead of 0? [19:37:13] Nope [19:37:14] for the slider ID [19:37:18] Not 1 or 2... [19:37:41] ggalfi had some website to figure out which IDs your joystick has... [19:37:47] This stick has only one slider [19:37:55] And is that one... [19:38:12] what do you mean with "The slider behind my throttle moves the CMD slider" then [19:40:28] https://prnt.sc/uYNrIYkDvgL- [19:41:14] ok [19:42:44] I don't know then [19:42:50] VESIM :D [19:43:00] https://prnt.sc/tNd8n3yrJjnt [19:43:12] The only slider is that; the others are axes [19:43:26] How to set up VESIM? Doc somewhere? [19:44:02] yes, in the NASSP doc folder [19:44:06] Okay [19:44:39] you could also use Numpad for throttle, joystick for ACA only [19:44:48] it's not like you will need the throttle very often [19:45:19] Ah, yeah.... [19:46:38] Didn´t though of that :) [19:46:55] hmm well [19:48:06] That works for me, for the moment [19:48:35] the ACA was on the right hand, or on the left hand, on the real LM? [19:49:09] https://i.imgur.com/m7p5tWX.png [19:49:14] there is this :D [19:49:57] but it's not like you can't do that with Numpad [19:50:15] yeah, TTCA left, ACA right [19:50:20] for both astronauts [19:50:30] in NASSP you are always controlling the CDR controllers [19:51:00] there is a switch for the throttle control, CDR vs. LMP [19:51:08] LMP won't do anything [19:51:22] I guess at some point we need to add support for 4 joysticks :D [19:55:15] https://i.imgur.com/m7p5tWX.png Nice [19:55:25] Saw that on Ryan´s video [19:55:33] It´s on the checklist I think [19:56:03] Okay, TTCA left, ACA right.... Can do that, just need some desk arrangement :) [20:00:50] and... Modes: Correct me if I am wrong, but this is what I saw; CONT means that no matter how much I deflect the stick, I will get rotation for as long as the stick is deflected, and when stick is centered, my rate will automatically stop [20:00:51] PULSE means that I will get pulses if I deflect the stick a little, and if I continue to deflect, i will get a continuous RCS fire; It will NOT kill my rates if I return the stick to neutral [20:00:51] DIR means that I will get a "proportional" rate, and will not kill my rate if I return the stick to center [20:00:52] To start the engine manually I need to press the start button, and manual throttle range goes from 10 to 90% [20:00:52] To stop the engine I need to press the stop button [20:02:05] I quoted proportional because it´s like two behaviours if the stick is deflected beyond 25% or 75% [20:18:42] mostly correct. Those are all AGS control modes. With MODE CONT it also depends what the AEA wants to do [20:18:57] depending on the AGS Mode Control switch [20:19:10] What you described is basically Att Hold [20:19:38] DIR is like Accel Cmd in the CSM [20:19:55] Pulse is kind of like Min Imp [20:20:05] but Min Imp just fires the thruster once for one deflection [20:24:54] There is a table in the AOH with all the control modes [20:25:47] PDF page 210 in the LM-3 one [20:25:57] Aha [20:27:55] Well guys; [20:28:04] Tomorrow I will be in Spider [20:28:13] Let´s see how it goes :) [20:28:18] See you [20:29:48] should be fun [20:30:09] Surely [20:30:12] Bye bye [09:38:24] howdy [11:14:40] hey guys [11:16:33] hi [11:16:56] looks like a texture is missing on github [11:17:11] ProjectApollo/VC/aot_font.dds [11:17:19] the LEM VC tries to use it [11:17:51] however there's a bitmap ProjectApollo/Bitmaps/aot_font.bmp [11:18:00] is it supposed to use the bitmap? [11:24:07] also I have a small fix with moon dust particle stream not correctly initialized [11:24:08] https://github.com/TheGondos/NASSP/commit/582b85f206ed8eba8ac88f6da0161aafe05cd8a3 [11:51:15] huh not sure how we have a missing texture [12:34:13] lol [12:34:15] gondos@gondos-desktop:~/github/orbiter/Addons/NASSP$ git log --all --grep=texture|grep Forgot [12:34:16] LMVC: Forgot textures [12:34:17] MCCVC: Forgot texture [12:34:18] MCCVC: Forgot texture [12:34:19] Forgot to add texture files in LM VC phase 1 [12:34:20] Forgot to add texture files in LM VC phase 1 [12:34:31] not for the first time it looks like :D [12:50:53] oooooh [12:53:53] do you have that file in your directory btw? [12:59:38] I will take a look later. I think so. out of the house right now. [13:02:16] ok [13:09:32] I'm trying to use the bitmap to see what it looks like but I don't know how to use the AOT [01:35:57] not sure what happened there [02:06:14] darn. no ZNC for a bit while I fix the pi [02:12:01] .tell gondos I do not have that dds file [03:43:02] .tell indy91 I didn't realize I could push to your branch... [15:03:20] hey [15:07:54] Hey, how is it going? [15:08:06] Beware with me; I am infectious [15:08:46] better quarantine, in space [15:09:03] n7275, how does that work that you can push to my branch... because I added you as a reviewer? [15:11:57] indy91 No apollo until june 26 [15:12:40] Maybe earlier, but we´ll see [15:12:45] why not? [15:13:08] Need to be sharp; and I have unconfortable sympthoms [15:14:53] Yesterday I was on bed for 90% of day, with back hurting, and vomited two times, couldn´t eat. Today I am better, could eat, just have "rhinitis" [15:15:04] ah damn [15:15:23] I am vaccined [15:15:32] But it depends on the organism [15:15:47] Rembember that Kranz wants sharp people, and he is on 9 :D [15:16:22] If I am OK this weekend, I can try to resume the practise... But we´ll see [15:16:31] yeah you are pulling a Rusty Schweickart [15:16:36] :D [15:16:41] yeah [16:05:23] hey guys [16:05:46] Hey sir [16:06:11] I hope you feel better soon. that doesn't sound like fun [16:06:41] Let´s see what happens from tomorrow, as I am much better than yesterday [16:06:56] Hopefully today I will get a good sleep [16:11:07] good sleep is the best healer [16:40:51] indy91, not sure how I was able to push. I actually intended to push to my own copy of your branch and make a pull request, but if you're happy with it than I am too. [16:41:06] haha [16:41:15] just slightly worrying [16:42:19] so that additional flag causes it to go to the manual angles when it looses track [16:42:57] GitHub makes me use two factor authentication, and ssh keys but I can push to other people's repos without any issue... [16:43:09] yes [16:43:41] more importantly it forces it to stay in manual until it has reached what the pitch and yaw knobs are set to [16:44:36] otherwise it just jumps back into auto as soon as manual moves it outside of the scanlimit [16:45:00] yeah, it should drive back to the manual angles [16:45:05] it can still go into a loop of course [16:45:53] I wished we had more details on the HGA electronics, for logic like this [16:46:31] ah wait a moment [16:46:41] I'm not sure this correct behavior [16:47:32] ok, it is correct [16:47:59] I thought it might stop tracking at the scan limit, drive to the manual position until it reaches the scan limit warning [16:48:07] and already tries tracking again at the scan limit warning [16:49:00] I did give it a pretty through test last night [16:49:25] but you are right, it does drive all the way to the manual position before it tries anything else [16:49:34] granded I've been saying those same words about this exact piece of code for like 2 years... [16:49:53] s/granded/granted [16:50:58] maskdgmkasdmfpoaiksdhpaisohrioakshfpoiadsaiopmoiehaoidgaer [16:52:06] er, what I meant to say is [16:52:12] didn't know you spoke Welsh [16:52:17] morning! [16:52:22] hahahaha [16:52:30] good evening [16:52:47] you okay Mike? [16:53:10] lol [16:53:20] yeah I'm fine lol [16:53:42] we have all fallen on our keyboards [16:53:53] nothing to be ashamed about [16:54:43] hey sometimes spelling is hard [16:55:04] yeah [16:55:09] either that or you got excited because you just made an important discovery [16:55:20] nah, no important discoveries today [16:55:22] although I usually make words shorter when I miss spell them... [16:55:34] I made a bunch of CDU discoveries yesterday, but none of them were super important. just interesting [16:56:07] https://i.imgur.com/HuibaGz.png [16:56:40] I got the full range of things. wires that I expected to be connected that weren't, wires that I expected to not be connected that were, and wires that went to different pins than I was expecting [16:57:28] ah, nice. well not really nice. [17:01:06] I'd classify it as nice. learning is always good and there wasn't anything surprising in a bad way :D [17:02:41] that's good at least. Next step is tests on individual modules? Or on one of the trays? [17:03:47] n7275, I think eventually we should make the internal HGA electronics logic independent from the switches [17:04:01] make it more like it works in reality [17:04:19] so the switches will energize some relays, and those relays control the logic [17:04:37] right now there is probably a bit of redundancy in auto and reacquire modes [17:04:44] I agree. it's a bit messy now [17:04:49] probably individual modules, to an extent at least [17:05:00] but that's the kind of thing we would need more information about [17:05:44] "Schematic, Service Module, Electronic Box for CSM 106 & Subs.", Dalmo Victor Drawing No. 199401 (5 sheets total), October 1968 [17:05:51] that would be useful :D [17:06:36] whoa [17:07:00] that's at UHCL? [17:07:17] nah [17:07:23] listed in references in a MSC memo [17:07:25] ohhh [17:07:29] gotcha [17:07:32] so unobtainable :D [17:07:43] worse even than CSM schematics [17:07:48] subcontractor schematics [17:07:54] does the functional integrated system schematics show what you need? [17:08:30] I think no, but let me look again [17:14:32] different than Systems Handbook, but over all even less information [17:14:36] boo [17:14:43] it doesn't even have the two switches controlling the HGA at all [17:14:46] the mode switches [17:14:59] now I wonder if that is on a different drawing I never looked at hahah [17:16:52] I guess either that or they weren't added yet [17:19:37] nowhere to be found at leasr [17:19:47] least [17:27:58] n7275, is that 1° from some source or made up? [17:28:17] when it detects that is has been driven to the manual angles [17:28:26] and will try to reacquire again [17:58:45] made up [18:15:11] I guess that might or might not be the same logic as used by the manual mode when it should stop driving the HGA [18:15:14] but who knows [18:15:50] I'm kind of surprised we didn't have thos logic yet, that drives the HGA in reacq mode all the way to the manual angles [18:15:54] this* [18:16:08] but I guess we never implemented that [18:22:25] ah, I remember now [18:22:41] we partially implemented it, like, LOS in lunar orbit worked [18:22:49] when it immediately had no signal [18:23:01] and no signal until it reaches the manual angles [18:59:26] the reason it probably worked before is that it would hit the overly narrow shadowing CSMrelAngle [18:59:36] in ptc [19:05:03] Guys! Going to the best place of the world; bed [19:05:11] :D [19:05:17] Let´s see how I am tomorrow [19:48:12] oops [04:22:47] the issue with the pi and znc.... [04:23:02] was DNS [05:19:12] :surprised-pikachu: [16:18:10] n7275, I guess you could push to my branch because of the "allow edits by maintainers"? [16:18:18] Didn't know you were a maintainer :D [16:18:24] but it's just a weird concept [16:18:36] I create a PR that needs approval [16:18:48] you put your own updates in there and can approve it yourself? [16:18:59] How does this process make sense :D [16:21:56] maybe the concept is more that the reviewers can do small fixes directly without having to ask for it? [16:29:18] yeah definitely an odd. I had no idea I could do that. [16:29:56] I merged the PR now [16:30:19] oh and I was just looking at your gravity model update for Orbiter [16:30:46] I am confused which part of it is Pines method haha [16:31:23] I had read a document called "Pines method for circular and elliptical orbits" [16:31:29] that gets used by the Shuttle computer [16:31:44] but that Pines method is an integration method I think? [16:32:02] And is then Pines "algorithm" the one that calculates the gravity vector efficiently? [16:33:35] spherical harmonics have a singularity at the poles [16:34:03] this method was described in an AIAA paper by Samuel Pines [16:34:52] https://arc.aiaa.org/doi/abs/10.2514/3.50619 [16:35:02] right, so I am pretty sure it is two different things by the same guy [16:35:18] Pines, S.: Variation of Parameters for Elliptic and Near Circular Orbits [16:35:32] just keeps naming things after himself [16:36:00] I wanted to have a look at the L1 lunar gravity model [16:36:10] which they apparently used in the RTCC by Apollo 15 [16:36:25] that is one coefficient more than the AGC ever got [16:36:28] adding C33 [16:37:56] https://i.imgur.com/v554KPp.png [16:38:43] L1 was not good enough to predict the fairly quick downwards trend in the perilune altitude after DOI [16:39:08] https://i.imgur.com/oadwipr.png [16:42:40] what document are these from? [16:44:51] first one is: https://ntrs.nasa.gov/citations/19700028128 [16:45:43] second one is "Apollo 15 Navigation Results". Which used to be on some ESA website [16:45:49] I think it came from UHCL [16:49:37] I can send it to you if you want [16:54:28] I did successfully implement the Shuttle navigation equations that probably use a similar scheme as your gravity branch uses [16:54:34] Had you looked at those? [16:57:58] morning! [16:59:18] hey Mike [17:02:51] what's up? [17:04:12] I would be interested in seeing it. I hadn't seen either of those before. [17:04:18] hey Mike [17:04:48] looking at gravity models a bit [17:05:22] they never really figured out the lunar gravity field properly, I think they still had difficulties on Apollo 17 :D [17:05:30] hehehe [17:05:32] should have send the LRO first [17:05:50] ah wait, it wasn't the LRO [17:06:00] https://en.wikipedia.org/wiki/GRAIL [17:06:23] n7275, is that what your data is coming from? [17:08:21] https://web.archive.org/web/20100507094627/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19800070633_1980070633.pdf [17:08:31] Shuttle Navigation Requirements [17:08:42] look on pages 4-125 and B-32 [17:11:09] Ebb and Flow, good names for spacecraft measuring gravity of the Moon [17:16:37] if I have too much time I can already implement the L1 model in our RTCC, just with some values nulled [17:30:37] too much time? what is this concept? [18:04:23] the concept where I won't implement that L1 gravity model any time soon [18:07:20] hahaha [20:48:17] night! [16:28:02] morning! [17:08:40] hey [17:33:11] hey guys [17:36:05] hey hey [17:36:06] what's up? [17:53:02] looking at multiple potential projects, but all of them don't have a very good balance of effort vs. gain haha [17:53:20] hehehehe [17:57:44] Bonsoir [18:02:22] hey Thymo [21:29:11] hello gondos. And everyone, I have been talking a lot to Jordan about the problems with Linux and NASSP in Open Orbiter. [21:29:17] The main issue is case sensitivity [21:29:22] hi [21:29:41] We have meshes that want to load textures, but use the wrong name [21:29:48] or rather wrong case [21:29:54] oh yeah, for that I added an oapiGetFilePath which translate from windows to unix path [21:29:57] and includes and bitmaps in code with the same issue [21:30:11] in the source code you mean? [21:30:22] yeah [21:30:24] lots of #includes have the wrong case [21:30:31] So we are thinking about the best process to fix this [21:30:48] File renaming is a thing, git doesn't really like it much [21:31:41] Jordan wrote a program for a more consistent naming scheme, but we should probably rename as little texture files as possible to not see in the commit history that they are new and the other file got deleted or so [21:31:46] another big issue is bitmaps embedded in the dll [21:32:21] but yeah, first step would be to fix the includes [21:32:55] or you install orbiter on a fat32 partition^^ [21:33:35] should have tought of that sooner, lol [21:33:41] haha [21:34:55] But yeah, we have a few different sub projects here [21:35:09] Jordan is naturally mostly interested in the meshes and textures [21:35:59] Jordan would like to do a bit of restructuring of textures and folders and such, but then we possibly loose git history. [21:36:10] But it's not code, so not as big of a deal. Or is it? [21:36:24] Thymo, any opinions? [21:36:36] speaking of textures [21:36:42] zzzMetalMantel.dds has a strange resolution [21:36:53] 1964x1965 [21:37:00] so says gimp anyway [21:37:32] it resizes to a power of 2 on loading, takes quite some time [21:37:59] (in debug) [21:39:21] Told that to Jordan on Discord. He prefers to speak German to me, which fries my brain even more so late in the evening lol, switching between the two languages. [21:39:32] Ehhh unless you wanna mess with loopback devices to build NASSP on an case insensitive FS I think renaming is the only option [21:39:58] Not as bad as when I had to translate a Latin text into English, together with somone from Belgium (and me being German) [21:40:00] I didn't do any rename [21:40:06] I just fixed the #includes [21:40:34] and for the runtime I have a function that enumerate the directories and does case insensitive compare to find the correct path [21:40:45] it's ugly but it works for now [21:42:18] Regarding commit history, git does track moving/renaming files. It just doesn't display it in the log by default due to performance reasons. If you want to inspect the pre-rename history add --follow to git log [21:42:42] oh, can I do that on Github somehow, too? [21:42:52] yeah, as long as you do not rename and make too many modifications to the file in the same commit, it's workable [21:43:37] textures being binary, you'll prefer not to change them at the same time [21:43:42] Not sure if GitHub web supports it [21:47:27] another issue is the microsoft "_s" strings functions (sprintf_s & co) [21:47:33] it does no exist on gcc [21:47:50] We had a discussion about that recentrly [21:47:58] I tried a thridparty library but in the end it didn't support sscanf_s so I scrapped it [21:48:19] There is a pragma that MSBUILD recognises that will replace "unsecure" functions with their _s variant. [21:49:05] Then we need to replace the _s variants currently present with a different one so gcc/clang gets it [21:49:27] I think it's overrated anyway [21:49:40] yeah [21:49:43] we're not dealing with inputs from the network [21:49:47] That's kind of where I got stuck with my RTCC TLI presettings generator haha. Visual Studio under Window didn't like "sscanf" and I kind of didn't want to force it to allow it. [21:49:59] But Linux has no sscanf_s [21:50:01] if an attacker can mess with the config files, he can do better than this [21:51:41] The only reason I ever started using sprint_s was for the MCC PADs. There are a lot of sprintf and there were a few CTDs I couldn't explain other than some sprintf and char array gone bad [21:51:59] Did manage to catch one or two bugs that way thanks to hard crashing in the sprintf_s [21:52:46] does ASAN work on MSVC? [21:53:03] I can't get it to work with modules on linux [21:53:35] it fails to reconcile symbols across dll boundaries :\ [21:54:35] time for bed for me. Good night! [21:54:39] night [21:55:48] 23h55 here, gonna go to bed too^^ [21:55:56] see you later [21:56:01] see ya [15:33:31] hey [15:33:42] hey Matt [15:37:23] I think I don't want to fix the coordinate system in our RTCC anymore :D [15:37:45] it uses ecliptic coordinates, like Orbiter just rotated to right-handed [15:38:06] real RTCC used the Earth equatorial coordinates like the AGC, changing every year [15:38:25] But Skylab is not using the yearly coordinate system and that would cause problems [15:38:32] so maybe it's better it stays the way it is [15:41:56] another advantage is, I don't have to do anything :D [15:46:20] and for gravity models, which got me thinking about this, it can then be consistent between Earth and Moon [15:46:44] convert from ecliptic to planet fixed coordinates, calculate gravity, rotate gravity vector back to ecliptic [16:01:45] morning! [16:01:52] not having to change anything sounds like a good outcome :D [16:05:18] good evening, yes, haha [16:05:33] one thing I do want to change is how REFSMMAT are handled though. [16:05:40] Right now they are also in ecliptic coordinates basically [16:05:46] so need conversion before uplink to the AGC [16:06:21] it should probably be stored in the correct coordinate system, and if it is used internally in the RTCC, an extra rotation matrix is applied. Or so. [18:57:40] ok update from Jordan. His preferred way forward is doing a lot of restructuring and renaming of the textures. To make it Linux compatible (case sensitivity) and to make it more organized. [18:58:20] Problems are Git and for people who install NASSP with the zip, renaming leads to files being there twice. [18:58:37] But when the change gets merged we can tell people to delete their texture folder before unzipping. [18:58:52] he has an automated system [18:58:58] Here the proposed names [18:58:59] https://www.dropbox.com/s/zuq8o52ecpd6x07/TexturesOldNames.txt?dl=0 [18:59:03] https://www.dropbox.com/s/ukptoyyrlr09dyn/TexturesNewNames.txt?dl=0 [18:59:24] And he would like feedback if the name changes are ok [18:59:43] I guess Git history turned out to be not such a big deal, especially not with textures [19:00:09] the Mesh files also will have these changes because they have texture names, also case sensitive under Linux [19:00:19] and a small number of textures are loaded in code [19:00:36] I think he can do basically all the changes on his own, just wants the ok to do it this way [19:00:57] I am fine with his ideas. I'll have a look at the new names, but they seem ok. [19:02:26] Hi [19:03:24] I'm happy with the new naming. looks good to me. [19:03:32] wow, that is an old message :D [19:04:06] Guenter has a good memory sometimes [19:04:25] Hi Jordan! [19:04:44] Hello [19:05:28] has it been so long since i was here last? [19:08:44] maybe a different user name. Maybe only "Jordan"? [19:09:23] but maybe it was so long [20:45:05] hi [21:40:36] lol I totally forgot about that request [21:41:01] Don't even know who requested it lol [23:27:42] Thymo, I thought you did. [00:00:32] oh wait nevermind [00:00:58] I think it was whoever was working on the raytraced VC textures [13:24:20] Hey hey [13:29:52] hello hello [13:32:39] Still positive, but good; Today I am going to prepare a video and debrief FD4. I´ll be on the LM tomorrow [13:32:59] Now, lunch [13:34:35] at least you are feeling fine [13:52:20] My name is Ice... [13:52:25] cream [13:59:19] nice [13:59:28] I heard you are currently all melting in Spain [14:01:55] Didn´t saw that [14:01:58] I am sick [14:02:12] But yeah, people is saying that [14:02:46] Melting? It´s 23ºC :D [14:03:02] LEVX 171330Z 29007KT 260V340 CAVOK 23/18 Q1018 NOSIG [14:03:45] well then not everywhere in Spain :D [14:04:02] News this days you know... [14:04:04] LEMD 171330Z 18004KT CAVOK 40/07 Q1019 NOSIG [14:04:09] Well; this is hot [14:04:33] But if we go southern... LEMO 171330Z VRB06KT CAVOK 33/13 Q1015 NOSIG [14:04:37] Nah [14:04:45] Average for Andalucia [14:06:07] So you see; Madrid melting = Spain is melting [14:07:00] wait there is more to Spain than Madrid? :P [14:08:11] Not for jourlalists [14:08:22] And some policitians [15:57:10] indy91, what testing does your docking initiation processor need before it can be merged? [15:58:27] I know it works right in many cases I have checked. Maybe some feedback on how the inputs and outputs work, if anything should be changed there or so. [16:01:34] There is one single case where the MCC uses the DKI, which I have already checked and it gives a good result [16:01:52] That's really my main concern all the time. Don't. Break. The. MCC. [16:02:09] anything in the RTCC MFD isn't such a big deal for me. [16:06:17] There is probably more examples I could add to the manual or so [16:23:13] morning! [16:39:08] hey Mike [16:39:27] oh wonder, people actually take a look at my two week old RTCC pull request :P [16:50:24] haha [17:00:23] indy91 Know what my face is saying here? [17:00:24] https://prnt.sc/TW954wC0nnGc [17:00:36] Wich one is CP2? [17:02:50] need to study the maps :D [17:12:56] thewonderidiot, have you tried searching for anything at UHCL in the last few weeks? I get 502 Bad Gateway most of the times :( [17:13:17] hmm I have in the past few months but not the past few weeks [17:15:46] I can get through on the Archives Search Index about 1 out of 10 times. History Search Index, 0 out of 10 :D [17:20:52] wow, that's pretty bad [18:32:11] Ok guys; [18:32:34] Hardest part of FD4 to debrief, is debriefed on the forums [18:32:53] Now it should be very easy for the remaining of the mission. [18:48:14] great! [19:47:33] Leaving guys [19:47:41] See you tomorrow [21:11:05] night! [09:06:14] Hey hey [09:07:01] Looks like negative; well, wait, the T is drawing up, just a tiny bit; 7 minutes remaining in our count [09:09:23] my least favourite kind of countdown [09:12:49] How the hell did I got COVID..... or better said; Omicron, but well, COVID [09:13:02] I always wear the mask [09:13:39] I think it was a positive contact at job, around 8th of june... [09:13:55] And I also clean my hands every 30 seconds :D [09:14:16] Omicron... finds a way [09:14:27] Yeah it fucking does :D [09:14:48] GLS is go for auto sequence start [09:15:04] And we have positive; but looks like just one more day of quarantine [09:15:08] now you are talking about terminology from the future :P [09:15:14] :D [09:16:08] TCS, Terminal Countdown Sequencer maybe [09:18:34] BRB, see you in a bit [10:03:21] All rightie; [10:03:44] 39:19:00 GET, today until 47:00:00 GET [10:03:53] Gonna repeat some hours I did on sunday [10:52:35] good morning [10:55:54] Hey n7275 [11:01:41] hey Matt [11:47:44] 1 hour to get into the LM :D [12:05:26] :S [12:05:34] Lst the link to the LM-3 AOH [12:05:38] Got it? [12:05:44] *lost [12:16:23] https://www.ibiblio.org/apollo/Documents/LM-3_Apollo_Operations_Handbook_Vol_I.pdf [12:16:51] Thanks! [12:20:53] n7275, I think I'll replace the RTCC gravity models with the ones from the Space Shuttle computer. Seems like a pretty efficient implementation and when we have a different gravity model in Orbiter I just have to enable the tesseral terms. [12:21:10] testing that right now, looking good so far [12:21:33] indy91 You are talking future =* [12:23:18] kind of [12:23:33] the Apollo RTCC did have this gravity model I am implementing [12:23:41] it's just a slightly different implementation of them [12:26:09] https://i.imgur.com/ilm68m7.png [12:26:17] doing fun stuff like this over one day :D [12:26:37] Sinos [12:26:41] *Sinus [12:27:00] 3 days actually [12:27:54] nonspherical gravity is fun [12:27:58] https://i.imgur.com/6oLPdln.png [12:28:07] this is the most circular orbit you can have in Earth orbit [12:28:12] this is one(!) orbit [12:28:30] but with two apogees and perigees :D [12:29:25] this might be what you will have for the rendezvous on Apollo 9 [12:29:50] the SPS burn after the docked DPS burn does a circularization [12:30:04] Aha [12:31:00] I think that is the burn (SPS-5) where you will get huge residuals [12:31:52] 10 ft/s in DVY [12:32:00] happened on the actual mission, too [12:32:05] I take note [12:32:13] we get it also since consistently performing ullage and having a shifting CG [12:32:16] Finishing up pressure equalization [12:32:25] Getting ready to smell the LM [12:32:27] and they knew they will get it from simulations [12:32:51] "we did [12:32:52] not clean it up by burning out the resid [12:32:53] uals; this was not included in the flight [12:32:55] plan, and we ended up with somewhat of a [12:32:56] noncircular orbit for rendezvous. " [12:33:29] but yeah, first you have a lot of hours in the LM to do :D [16:04:21] thewonderidiot, this should be an easy question but somehow it isn't. What are the limits of the sextant trunnion? [16:05:14] the only limit is yourself :D [16:05:57] but seriously, you mean at what angles does it hit hardstops? [16:06:00] yes [16:06:22] procurement specs might have that info [16:06:25] if we have them [16:06:54] I have found answers to this question, but they don't satisfy me. Something doesn't add up. Haven't looked at procurement specs. [16:07:05] I kind of need an independent answer from what I have found :D [16:07:58] hah [16:08:17] I won't look at them so as not to bias my own idea of angles, but what places have you found these conflicting answers? [16:09:16] CSM Data Book [16:09:28] ok, here is my problem [16:09:31] Backup GDC Alignment [16:10:31] you are supposed to move the optics to 0° shaft, 352.5° trunnion [16:10:38] and afterwards you are switching the optics off [16:10:55] there is manual scanning telescope drive [16:11:38] with the optics already off and some tools to manually move only the telescope [16:11:57] the limit I am finding for the sextant is not -60°, as it is for the telescope, but 0° [16:12:15] so that procedure can't work. Optics power is on, so you are driving the SXT with SCT slaved to it [16:12:24] no way to get to 352.5° [16:13:26] a while back we changed the limits on both sextant and telescope to -60° [16:13:29] or -59° or so [16:14:07] But I don't think resolved mode is working correctly there. But then I am not really finding evidence that anything is supposed to work below 0° trunnion at all [16:15:27] hmm [16:16:02] if the SXT can go below 0° trunnion then it might just be an issue with resolved mode. Or even something that works bad like this in the real CSM [16:18:32] also weird is that before Apollo 13 the procedure uses 7.5° trunnion and 180° shaft [16:19:10] those angles are no problem [16:19:13] "In trunnion axis, positioning of the indexing mirror is restricted mechanically to a range of -5 to +50 degrees through the use of a limit stop. A command torsion spring assembly is provided in the drive assembly to minimize positioning error." [16:21:10] I need to some reading about how this thing works heh [16:21:57] https://i.imgur.com/jimEt95.png [16:23:54] hmmm [16:25:17] I also looked in ND-1021043 [16:25:56] but doesn't really help me either [16:35:55] Question [16:36:10] On the capcom menu, the Voice Check option... does something? [16:36:31] no [16:36:48] we should make it do something [16:38:04] I think I was going to, like 2 years ago... [21:14:23] night! [21:38:37] Good night [08:06:22] Good mirning [08:06:30] Negative, breakfast and LM [08:14:53] hey [08:17:34] Let´s see how that DPS works [08:18:06] already got the LGC up and running? [08:18:16] Negative [08:18:20] Not yet [08:21:59] I think in around half an hour I´ll have that [17:42:24] Guys, leaving [17:42:33] See you [17:26:32] hello [17:34:38] hey [17:37:01] n7275, with the gravity models, they surely removed the gravity of the Earth from the equation, right? [17:37:18] because the special thing with the Moon is, longitude = direction of Earth, or at least nearly [17:37:55] I started thinking about this when comparing the trajectory propagators I currently use in the RTCC [17:38:23] there is still an old one based on the AGC, which disables the contributation of Sun and secondary body (Earth or Moon) in low orbit [17:38:48] the C0,0 term is the like a point mass [17:39:02] and then the two modules based on what the RTCC had. Those do not disable those calculations. [17:39:03] is that what you're asking? [17:39:46] I guess I am asking, for the L1 lunar gravity model, it basically gives the coefficients as a function of latitude and longitude [17:40:02] but for a complete gravity model you still need to add Sun and Earth gravity [17:40:54] Earth gravity pulling on an object in lunar orbit is basically a function of longitude [17:41:01] because it's tidally locked [17:41:13] it's not an insignificant contribution [17:45:13] I'm seeing about a kilometer difference in one day of lunar orbit between taking Earth and Sun gravity into account or not [17:51:41] Hey n7275 [18:41:01] hmmm I'll have to dig into tidal effects a bit more [18:42:57] my implementation is tide-free. I presume propagators like GMAT add tidal contributions as a superposition [18:46:01] Yeah I think too, I was just looking at the development of gravity models and saw detailed numbers, but separate Earth gravity wasn't mentioned [18:46:12] special case of the Moon of course [18:47:51] I'm sure there are a lot of performance-saving tricks in the older implementations too, where we can afford to be a bit more general purpose (in the Orbiter code) [18:49:59] in the AGC calculations it switches on Earth gravity before switching off non-spherical perturbations [18:50:27] so in low lunar orbit it uses: non-spherical gravity perturbations [18:50:38] in middle orbits: non-spherical gravity and Earth+Sun [18:50:45] in high lunar orbits: Earth+Sun [18:50:54] at specific radii [18:51:04] if that were at the same radius it would be suspicious [18:51:25] but I think this nearly confirms, there is not any such trickery to take Earth gravity into account [20:41:00] I think Orbiter handles multi source gravity, including contributions from Jupiter in earth orbit [20:58:20] yeah, definitely [20:58:22] night! [15:58:30] thewonderidiot, Apollo 9 Technical Debriefing pages 4-263 and 4-264 talks about the backup GDC alignment. [16:00:33] confirms that there was no change to the optics required for either technique to work [16:01:10] there was also an anomaly with the telescope on 9, that could have been the reason for that ECP 724 or whatever it was [16:42:22] morning! [16:42:24] ahh interesting [16:43:20] but it does sound like there is... essentially a soft stop around 0 degrees that can be overcome with a bit of extra effort or something [18:06:50] hmm [18:06:53] maybe [18:07:10] there is a way to move the telescope manually, but I think it requires the optics power off [18:07:17] and it requires a tool [18:07:48] but the thing is, without that tool, the only way to drive the optics manually is with the optics hand controller [18:07:55] and that drives the SXT only [18:07:59] and the SCT follows the SXT [18:08:14] and I am fairly sure about the SXT at least that it can't be moved below 0°... [18:08:44] hmmmm [18:08:46] right [18:08:47] yeah [18:10:22] oh wait [18:10:26] it has to be able to move below 0 [18:10:58] "it is necessary to leave the telescope shaft [18:10:59] at zero and move the trunnion to minus 7.5 [18:11:01] or 82.5 on a DSKY read-out." [18:11:02] DSKY readout [18:11:04] that's the sextant [18:18:53] and that's how it already works [18:18:58] it does shows 82.5 there [18:19:17] so maybe what we have now is correct. ggalfi is rarely wrong, this was his change :D [18:24:14] hehehe [18:24:33] I dunno, I still feel like we're missing something [18:25:11] yeah [18:25:21] maybe the soft stop idea. We need to find evidence of that [18:25:59] yeah what is this "stop override" that ECP 724 talks about [19:45:36] how different are the optics between Block I and Block II? [19:57:07] similar, at least in operation [20:33:16] ah you got the point of "not enough Block II information" where you think "maybe Block I information is useful" :D [20:33:23] hah yeah [20:33:43] guess who looked at Block I AOH and Systems Handbooks earlier :D [20:33:50] hehehe [20:33:54] I was thinking about the study guides we have [20:34:12] https://archive.org/details/apolloguidancena00acel [20:46:53] "The components which rotate about these axes are capable of 360® of rotation; however, these capabilities are not fully utilize" [20:52:20] night! [15:29:27] hey [15:30:23] hey Matt [16:28:09] I recently started a new job, which is why I haven't been around as much. [16:37:38] things should normalize soon though. [16:42:47] ah nice [16:43:29] I put a draft PR up on Github: https://github.com/orbiternassp/NASSP/pull/797 [16:43:51] most coefficients commented out, but this is as far as I would take the RTCC gravity models [16:45:36] using the Shuttle implementation of Pines harmonics development [16:45:43] spherical harmonics* [18:54:00] I'll take a look at it [22:00:00] n7275: Congrats on the new job! Same stuff different place or are you mixing things up? [22:21:12] I went from rope design to pump and motor design, so quite a bit different [22:22:23] Some mixup. Souds exciting! Not too long a commute I gope [22:22:30] s/gop/hop [22:26:23] it's about a 20 minute drive. not too bad. long enough that I can actually listen to something on the way home, but not so much that I'm spending my whole day in the car [22:27:59] That's nice. From home to the office is about a 20 minute bike ride for me too. It gives you a nice moment to get going or unwind at the end of the day. [22:30:44] Anyway, would love to talk further but it's already past midnight here. Have a lot to get done tomorrow, deadline to finish everything to graduate is approaching fast. That's also why I've been a little less active the last couple weeks. Talk soon, night! [22:32:15] night! [22:32:28] o/ [13:57:48] Good afternoon! [13:58:10] How's everyone doing today? [14:14:14] hey Thymo, doing good. How are things for you? [14:18:39] Feeling pretty good. Finally forced myself to sit down to plan my vacation, got about 60% of the route done and have some motels in mind. Also made arrangements for a date for the first time in i don't know how long so prettty excited for things to come :D [14:19:50] Still waiting to hear back from college to see if I can still hand in my last assignments in order to attend the graduation ceremony. That's scheduled for the 12th [14:28:36] ah got a whole tour planned for the vacation? [14:33:31] The plan is to fly to San Francisco and stick around there for a couple days (supposedly someone among us lives there), then I'm going on a loop east to visit some national parks. kings canyon, seqouia, grand canyon, antelope canyon, kayenta, bryce, zion, las vegas, yosemite in that order probably. [14:34:35] that sounds pretty epic! [14:37:08] yeah I also heard that someone among us was living there [14:38:41] It's been on my list for a while. The route is pretty heavily inspired by the one from my neighbor. He's been there before and send me his plans from the time. [14:40:57] Still debating on h/motels or camping some of the time since I like camping and it saves some costs but that also means thinking about camp gear and what to do with it at the end. It's not a cheap time to go. [14:45:09] also sounds like pretty hot areas for camping [14:45:18] but maybe better than rainy areas... [14:46:11] I was camping for a week in North Carolina, very humid. But at least we were in the mountains, so temperature was nice [15:10:59] That's true, something that shouldn't be dismissed. At least all rental cars have AC :) [15:14:13] Yeah, AC is probably a must haha [15:14:54] I was used to that in cars of course, but my eyes were constantly irritated from the airflow of ceiling fans everywhere when I was in the American South [15:15:02] took a while to get used to it [15:23:21] I have hard contact lenses and I already have dry eyes here, probably not gonna be better then [15:59:51] hey guys [16:28:18] Hey [16:36:28] morning! [16:42:24] sounds like a fun trip :D [16:43:48] You home the weekend of 16-17? [16:45:00] what month? July? [16:45:10] Yes [16:45:18] yup I should be around [16:47:38] I expect to arrive Friday, provided that the strikes at Schiphol don't get too many flights cancelled. [17:00:00] awesome [17:00:07] here's hoping you don't run into any flight problems [17:01:05] fingers crossed [17:14:37] hey Matt and Mike [10:23:34] good morning [10:37:35] hey Matt [11:00:51] what's up? [11:07:10] I was just doing a "git diff" in my old Apollo 7 branch for drag haha [11:07:31] which I might just deleted, but I'm still taking bits of pieces from the branch [12:33:34] I have a good collection of branches with semi-finished projects at this point [12:42:24] git branch, the command to view the skeletons in the closet [13:06:35] yes haha [11:39:07] good morning [11:55:21] hey [12:17:20] hey [12:41:03] what's up? [13:36:12] hi [13:37:47] A workaround with breakpoints breaking the timesteps : in Orbiter.cpp [13:37:49] @@ -1721,6 +1725,7 @@ bool Orbiter::BeginTimeStep (bool running) [13:37:50] // skip this step if the interval is smaller than the timer resolution [13:37:51] deltat = time_delta.count();// *1000.0;//* 0.001; [13:37:52] } [13:37:53] + if(deltat>0.1) deltat=0.1; [13:37:54] [13:37:55] time_prev = time_curr; [13:38:03] simple but effective [13:48:54] huh interesting [14:29:45] going up to the lake for the day. I need to find some reading material. [15:23:19] that sounds nice [15:23:26] fiction or non-fiction? :D [15:36:23] if you're in SF, Larry Niven is a pageturner for me:) [16:05:57] morning! [17:47:39] phone seems to be having some issues rejecting heat to the surrounding environment today.... [18:01:19] why is your phone running our LM ECS? [18:18:49] n7275: If you like submarines I can recommend book from Michael DiMercurio. Currently reading Dark Transit from him. [18:20:59] gondos: For debugging purposes that would be acceptable I guess. It would cause systems that do timekeeping to go out of sync though, e.g. the AGC. Maybe there is a way to keep them in sync? [18:21:41] From my understanding dt keeps ticking while in the debugger and with this all systems will be out of sync by whatever time period the sim was halted. [20:15:49] the AGC keeps its own time reference? [20:16:12] is it compatible with replays then? [20:17:50] ma, I'm having trouble with bmp decoding, I can't find a lib that will accept every bmps [20:18:04] there is always a error somewhere... [20:18:13] what tools did you use to author them? [20:18:53] trying with the bmp lib from netsurf right now, it's better but I still got some issues [20:46:37] some of those may be 15+ years old at this point [20:50:39] hehe, it was a rethorical question:p [20:51:05] a least now I've got the 2D cockpit useable [20:57:06] I played around with the LEM CoG update frequency to investigate my issue and a ridiculously big offset forms rapidly between the thrusters and the exhausts [20:57:27] does it ring a bell to anyone? [08:17:48] morning [16:08:01] hello [16:43:41] morning! [17:10:01] hey guys [18:36:26] indy91 what do I need to finish to merge my light PR, do you remember? [18:39:58] it's been long enough that I am not even sure haha [18:40:18] I think I was wondering if moving those inclundes from the cpp to the header file was the right idea [18:40:46] but I think those are fine and probably should even be there [18:42:27] I think I wanted Thymo to have a look at that, but I am pretty sure that is fine [18:44:43] uhh [18:44:55] 21 days ago you said my requested changes are fixed [18:45:11] your last commit was on May 26 [18:45:17] did you forget to push your last commit? :D [18:46:54] your actual last* [18:57:34] oh maybe haha. I will look tonight. [18:58:56] some funny news from Ron [18:59:42] apparently his (and every single other NARA volunteer) accounts got disabled due to 2+ years of inactivity [19:00:15] and he's the first volunteer who's gone back to try to get things set back up, so they had no idea that this had happened [19:00:46] so... things are moving but very slowly and with lots of difficulty lol [19:00:53] haha [19:01:17] I admire his dedication [19:01:35] most likely all of them are going to have to re-take all of their training to get the accounts re-enabled [19:01:45] which takes several days [19:01:58] and can only be done on-site, whenever they actually allow volunteers to fully come back in [19:02:38] that's a bit of a joke, it's not like they all just stopped caring about doing research voluntarily [19:03:50] the people doing the training probably need to get trained themselves first... [19:04:47] gotta love government [19:04:49] Y2K bug, didn't do any harm. Corona bug, deactivates all accounts! [19:06:06] But that would have happened exactly the same way here. Rules say training due to inactivity, no higher circumstances can ever change that! [19:06:29] hahaha [19:08:04] Was doing a little bit of work on my padload generator tool earlier, looking at Colossus 237 now. [19:08:19] I already identified a few smaller issues with our Apollo 7 padload [19:08:51] hardcoding lots of values is easy with the way I set it up. But dynamically calculating numbers with user inputs is hard [19:08:57] oh interesting [19:09:18] the padload just consists of so many different facets [19:09:30] masses, Saturn pitch polynomials [19:09:44] ephemerides, nutation/precession corrections [19:10:35] ever mission has something a little bit special [19:10:38] every* [19:13:23] although it does get more streamlined in the later missions [19:14:19] EMSALT is a funny example [19:14:37] that is the altitude when 0.05g acceleration happens during reentry [19:14:48] used to calculate EMS init parameters [19:14:57] Colossus 237 source code comments say [19:15:05] # EMSALT 2DEC 86759.2 B-29 284643 FT (-29) M (ORBITAL REENTRY) [19:15:09] # EMSALT 2DEC 90657 B-29 297431 FT (-29) M (LUNAR REENTRY) [19:15:31] so different altitude for Earth vs. lunar missions, because different reentry speeds [19:15:59] Apollo 11 padload has a value close to, but not exactly the same as the 297431 ft [19:16:12] maybe recalculated for different lift-to-drag of the CM or so [19:16:14] but then [19:17:13] oh actually, Apollo 12 has quite a bit higher [19:17:21] 304519 ft [19:17:34] ah [19:17:36] but then :D [19:17:41] Apollo 13 uses 290,000 feet [19:17:44] so do 14-17 [19:17:49] so do Skylab and ASTP :D [19:18:00] so they just stopped caring about that exact number :D [19:18:10] that's what I call "streamlined" [19:22:09] but then what do I use in a padload generator. Probably the 290,000 as a default but allow an option where you load the exact padload of a specific mission as your template for a new padload/mission? [19:30:40] hahahaha [19:30:58] yeah I think that makes sense [20:59:32] night! [04:24:34] okay this is odd. I pushed a commit on 7 June, but github has no knowledge of it [04:33:07] no git, everything is *not* up to date [04:39:17] too tired for this. problem for tomorow [14:26:46] n7275, why does Github say all commits for your lighting PR were done at exactly the same time haha [14:27:04] https://github.com/orbiternassp/NASSP/pull/779/commits [14:52:26] oof [14:52:37] whoops [14:52:56] I had a commit that wouldn't push [14:53:24] strange [14:53:35] so I rebased and push --forced it [14:53:50] probably what caused that [14:54:01] looks good now though, I'll give it one last test and then merge it [14:54:10] yeah, the rebase [14:54:27] okay [14:54:37] I think I figured out part of my issue though [14:55:03] I had two branches, "Lights", and "lights" [14:55:21] not intentionally... [14:56:44] oh no haha [14:56:58] in your last commit you changes something around [14:57:07] changed* [14:57:17] RndzLightSwitch.Init [14:57:34] SpotLight, RndzLight [14:57:44] RndzLight, SpotLight [14:57:52] is that what I think it means? Did we both not notice that before? :D [15:10:26] oh yeah haha. I forgot about fixing that [15:22:59] I tested my gravity branch in some details. Looks good to me now. [15:23:42] Functions I use, derived from Orbiter, for planet fix to ecliptic coordinates are made more efficient and give exactly the same results as before [15:24:53] one day of state vector propagation gives a tiny difference to before, it uses a different formulation, Pines method, I think like in your Orbiter update [15:25:09] 4384144.309747 4762431.753276 1079302.155314 [15:25:29] vs [15:25:41] 4384144.345524 4762431.719813 1079302.158851 [15:25:53] that sort of difference [15:26:08] not too worried about it [15:26:26] I think I can even explain that [15:26:57] previously it just calculated a polar unit vector once, used in calculating the non-spherical gravity terms [15:27:14] but now it calculates the rotation matrix to Earth fixed every integration step [15:27:37] because with the new formulation the non-spherical gravity can be a function of latitude and longitude, not just latitude [15:27:57] and that makes a tiny difference for the Earth due to precession. A bit more for one day in lunar orbit though [15:28:10] -1424061.179135 1174986.648766 -64.669627 [15:28:24] -1424061.172319 1174986.656528 -64.730576 [15:28:36] ok, not really much more :D [15:30:08] and I had added the J3 parameter for the Moon, that of course also makes a difference. Maybe 100 meters in one day. [15:30:21] feel free to do more tests like this [16:26:05] morning! [16:27:51] hey Mike [16:28:11] what's up? [16:29:01] staring at numbers as usual. And you? :D [16:29:29] what's the state of the rope reader, haven't heard about it in a few days [16:29:31] hahaha [16:29:48] it's been a hectic week or so, so not much progress [16:30:04] but last night I finished routing all of the connections on the backplane board [16:30:07] at least an initial pass [16:30:39] may shuffle a few pins around based on the driver board, but the backplane is pretty much done aside from that and fancy silkscreen [16:31:15] tonight I'm going to try to put together a plan for how I'm going to place all of the set/reset/inhibit drivers and how I'm going to route the various power rails to them [16:33:39] what is getting set and reset? Is that for addressing? [16:36:29] potentially dumb question but then I probably can't ask many intelligent questions about a topic like this... [16:40:51] hahaha [16:41:07] set and reset are the main wires that cause cores to flip one way, and then the other [16:41:36] the basic idea of rope memory is that you drive 450mA through a set wire that goes through all of the cores, which would cause all of them to flip [16:42:11] but at the same time you run 225mA through a bunch of inhibit wires going through the cores in the opposite direction, and which are woven in a pattern that makes it so that you can pick out a particular set of them that stop every core except for one from flipping [16:42:32] then you release the set wire and the inhibit wires [16:43:55] and then you run 450mA through the reset wire, which also goes through all of the cores and also goes in the opposite direction of the set wire [16:44:03] that causes the one core that flipped to unflip [16:44:14] and it's that unflipping that you turn on the sense amplifiers to listen for the data from the core [16:50:05] Internet what you doing [16:50:17] I thought this was how the erasable memory worked, that you have to reset the core after reading. "Destructive reading". So rope memory works similar... [16:50:49] well, sort of [16:51:12] with erasable memory, the data is stored in the polarization of the core -- the cores are a big mix of "set" and "reset" [16:51:43] with rope memory, all of the cores are always "reset", and then one is briefly transitioned to "set" and back when you read from it, to make it pulse 1s on the wires that are threaded through it [16:53:19] so you can loose the memory of the rope, temporarily, kind of. You just have to power the right circuit and the data "comes back" because of how it was woven? [17:02:35] the magnetic state isn't memory in ropes -- it's entirely in the weaving [17:02:52] the losing memory and then it "comes back" is how the fixed memory in the AGS works :D [17:05:02] haha ok :D [17:34:27] do we have an idea of what resources we would need to find for custom landing sites/launch dates? [17:36:30] maybe 2-3 more Niklases? :P [17:55:16] ha [17:55:49] well there is a bunch of documentation still out there, some of it at UHCL, with some targeting parameters [17:56:20] I have found a little bit of documentation about how they came up with TLI guidance presettings, but not too much [17:56:54] And for developing something on our own, one problem I have is that I don't really know what TLI should even be targeted for [17:57:03] in a way it's easier with free return [17:57:35] you have to come up with a latitude of pericynthion but otherwise you can't choose too many parameters yoursel [17:57:36] f [17:58:18] and calculating it completely from scratch, including liftoff time, seems very hard when you aren't even completely sure what you are targeting [17:58:24] with non-free return even less so [18:05:52] yeah. too many not-obviously-wrong solutions [18:12:29] I know there was something called the Quick Response Targeting Program [18:32:05] n7275, I can't merge your PR because Thymo had requested some changes, which you have done I believe. I am happy. He can look at it and merge it. [18:33:35] If I don't get around to it tonight go ahead and merge it. [18:34:40] ah I guess I can dismiss your review? Because otherwise I can't actually merge it, it doesn't let me [18:43:46] Ah [18:43:53] Didn't know it did that [18:44:52] I'll look at it after I look at Turry's issue [18:48:43] no hurry [19:19:24] Did anyone play with textures lately? My CM is white [19:39:39] I don't think so [19:39:52] it's probably another fun texture folder path issue [19:57:58] n7275: Is the spotlight supposed to reflect off the LM? [20:10:02] it should [20:11:43] do you have local lights enabled? [20:14:17] Huh apparantely my DX9 settings were reset. [20:14:57] That also fixed my CM texture [20:16:09] Do the running lights work? [20:17:12] ahh. not yet. [20:17:25] need mesh help for those [20:18:05] Also I have some concerns with the rendezvous light. At what frequency does it flash? It may cause issues for people with photosensitive epilepsy. [20:18:55] the flash rate is consistent with the systems handbooks [20:19:01] 1Hz iirc [20:19:31] yeah it's very slow [20:19:36] good point though [20:19:48] so slow that I thought it didn't work, but I was just in 0.1x time acceleration :D [20:20:06] could be a problem with time acceleration and high framerates [20:20:41] it's only on for 20ms [20:22:14] yeah, in 0.1x it's off for nearly 10 seconds [20:22:39] was all my fault of cause for forgetting I was in 0.1x haha [20:23:15] and I don't think that's quite enough to cause any epilepsy issues. Maybe in 10x, haven't tried that though [20:23:43] Supposedly 3-60 hertz. Anything below that is uncommon to cause seizures in those prone to it. [20:25:35] so how should we approach this? definitely a warning if we leave it as is [20:25:40] and ideally an option to disable/change? [20:26:04] I think it's fine. You won't use 10x with the rendezvous light on much at all. [20:26:19] our solution for the split line-of-sight of the sextant is 100 times worse [20:26:26] if we need a warning it would be for that [20:26:41] Also true [20:26:44] oh yeah.... [20:27:16] you know, with the way that Mercury addon handles its periscope or whatever it is [20:27:36] it might not be impossible to render two views above each other, both transparent [20:27:51] I don't really know though [20:28:13] I haven't even started looking into it properly for the optics in the VC yet [20:48:28] oh I'm sure we could do something like that [21:04:38] night!