[19:09:29] NASSP Logging has been started by thymo [19:09:31] thewonderidiot: http://0x0.st/ozx6.log [19:11:26] I was debugging that optics issue from October since Turry also ran into it. I found out what was happening. I still haven't figured out what caused the optics to get borked though. [19:14:04] Would someone mind chiming in on the forums lol, have someone trying to blame NASSP for bad framerates :P [19:14:24] He refuses to change settings because his fps is fine in the 3d cockpit [19:14:30] https://www.orbiter-forum.com/threads/weird-fps-in-the-nassp-2d-cockpit.40299/#post-589552 [19:14:50] On it [19:17:02] Thanks! [19:17:05] In his defence. We really ought to list some minimum specs and some settings in PA Configurator to optimize performance in a public place. [19:17:38] I have reinstalled the wiki this afternoon. I still need to import the articles but the new wiki is a good candidate. http://nassp.space/index.php/Main_Page [19:20:14] Wouldn't hurt for sure [19:20:21] But how do we define those lol [19:21:47] Who of us is using a system most closely resembling a potato? [19:22:33] I run a Ryzen 7 2700X and a 1080Ti so I think my system doesn't qualify. [19:25:33] I run on a thinkpad x1 carbon gen6 -- but with an external gtx 1050 dock [19:25:56] I could try my old laptop sometime. [19:26:28] Usually its an arbitrary cutoff though. What do you want to support without alienating a large part of your userbase [19:27:38] dealing with this sort of stuff for tons of users is exactly what turned me off of 3D graphics stuff many years ago [19:27:54] My laptop isnt awful but not new by any means [19:28:29] https://store.steampowered.com/hwsurvey/ could be a good help in estimating [19:28:32] I had a project with maybe a couple hundred to a thousand users, and ended up abandoning it because I got fed up with the endless tech support for graphics issues [19:28:44] i7 7700Q @2.8 [19:29:37] GTX 1050 gpu [19:29:42] 16gb ram [19:30:03] What specs does that kid in Discord have? Minimum would be about two CPU generations newer than he has. [19:30:13] Ah good question [19:30:37] I assume you are asking :P [19:30:42] Yep haha [19:30:42] Yes :P [19:31:09] Oh ggalfi posted a PR [20:25:06] I forget what my dual core xeon, ddr2 box had but that was very potato-like [20:25:35] the 45 minute rebuilds were the biggest pain tho... [20:26:46] I have a pair of x5690s now which are still old but seem so fast by comparison [21:00:51] a hardware survey of some sort is a good idea [21:22:06] Yeah I think that would be wise! [22:46:30] rcflyinghokie: Added you to the review. Some stuff gets added to flip switches programmatically. The checklist MFD also does that so maybe you have something to say about that. [22:56:52] Yep I will take a look [00:27:56] I dont think that will impact anything [00:29:17] The only thing I am unsure of is DSKY presses [15:53:44] good morning [15:58:12] morning [15:58:37] Actually, just who I wanted to talk to haha, just as a small thing I would like to get the recorder tb working in the LM [15:58:52] Just something simple like is powered and the switch is on [15:58:59] right now it stays bp [16:01:00] I think the reason is there is no underlying system yet for it [16:01:44] not sure I follow [16:01:58] The CM doesnt record, does it? [16:04:25] And the LM has a lot of DSEA code written already [16:06:09] hmm [16:06:25] TapeRecorderTB [16:06:50] its state is set by the DSEA timestep [16:07:00] so I wonder why it doesnt work already [16:10:54] good morning [16:12:31] Hmm [16:13:34] Ohh [16:13:46] if (state == RECORDING && VoiceXmit() == true) [16:13:47] { [16:13:48] lem->TapeRecorderTB.SetState(1); [16:13:49] } [16:13:54] LM_DSEA::VoiceXmit() [16:14:07] Looks like it only wants to work if there is an xmit [16:14:13] which we dont have [16:14:19] right [16:14:20] I wonder if that was normal behavior? [16:14:25] only going grey if xmit [16:14:29] seems odd [16:17:30] Actually it seems correct [16:17:35] only goes grey if moving [16:17:42] and only moves when recording voice [16:18:00] Can only store 10 hours of voice so that would make sense [16:28:52] So I guess the behavior is correct [17:14:32] I reimported everything to the wiki again today [17:14:43] http://nassp.space [17:15:09] Still need to get HTTPS and email going but should be good for the public after that [17:16:22] morning! [17:17:09] Hey Mike [17:21:29] Thymo, so we'll be able to edit things on there again? [17:21:33] Yep [17:22:31] sounds great, some of that stuff was quite outdated [17:23:01] Ill try and get my forum post done today btw [17:25:06] Thymo, that's awesome! [17:25:31] Your report with all the stuff exported was a great help :) [17:33:26] s/report/repo [17:33:33] Long day [17:45:27] I have never edited a wiki before but of course I would also be willing to help add content [18:08:39] glad to hear. :) [18:11:42] AlexB_88 how complicated would it be to implement the RNG/ALT tapemeter power light? [18:23:53] or "power signal monitor light" as its called [18:27:32] hmm, where is that light exactly? [18:28:52] https://www.dropbox.com/s/q20fkl35x8pcp61/Screenshot%202022-01-07%20112837.jpg?dl=0 [18:28:57] https://history.nasa.gov/alsj/a15/lm10-co33.jpg [18:31:47] Its mentioned in some of the checklists and is present in the LM-8 systems handbook [18:34:34] I thought those already worked? [18:34:38] At least in the 2D panel [18:36:08] That specific one is not there [18:36:17] what works are the power failure red lights [18:36:22] ^ [18:36:28] but I think that is different to what Ryan means [18:36:36] is that one even red? [18:36:53] https://www.dropbox.com/s/38wi96cxwgnp0p0/Screenshot%202022-01-07%20113639.jpg?dl=0 [18:37:53] and was it present on Apollo 11? [18:38:19] Those are questions Nik and I were trying to answer haha [18:42:02] I have a few more pressing issues right now, like click-spots at staging and scenario start from VC, but Ill get to it eventually [18:42:38] Oh its no rush, just curious [18:42:50] The funny thing is Apollo 14's checklists dont mention it [18:42:53] But on 15 it does [18:43:02] Yet the LM-8 handbook clearly has the light and logic [18:45:11] Just a small piece, but a puzzle that intrigues me [18:49:59] Also in the AOH for LM-11 [18:50:05] https://www.dropbox.com/s/k1kigvlb4wywr6u/Screenshot%202022-01-07%20114947.jpg?dl=0 [18:50:39] thewonderidiot any idea which if any of our LM drawings would have that? [18:53:54] the LM-8 systems handbook will have sources used for each drawing [18:53:59] towards the beginning [18:55:22] Rendezvous Range Rate - 'EFD9-515 [18:55:31] that doesn't help us because that's not a grumman drawing lol [18:55:32] hmm [18:56:10] I guess the question is was it on all LM's or if not when was it added [18:57:47] it looks like it's part of the thing itself, not something Grumman would have added to the panel, right? [18:58:20] so drawing-wise the level 3 diagram may not even show it [18:58:32] "IND RNG/RNG RATE" is LSC 350-307-13 [18:59:06] Yeah i think its part of the assembly [18:59:28] the relevant level 3 drawing would be LDW 350-54000 [18:59:33] which I do have [18:59:56] I think I only have the 330 series [18:59:57] I have a meeting now, but https://drive.google.com/drive/folders/1saMU30sD4YNXqEZOE7h3fvcL5GF2kxcD?usp=sharing [19:00:10] I never process/stitched this, but you should find it somewhere in there [19:00:18] sounds good I will look [19:11:26] if you have 340 it has the lighting on it as well [20:08:38] Looks like more chatter about that FPS dropping [20:09:37] yeah... [20:10:09] It might be the dump [20:10:16] I personally never noticed it [20:13:30] I havent either [20:13:43] But I also dont play very prolonged either [20:13:51] Maybe a few hours max at a time [20:14:16] Curious how to best diagnose the cause [20:41:50] d3d9 R4.26 is the latest I need right? [20:41:57] Gonna upgrade to a shiny CSM [20:49:11] Aand I broke it. Crap [20:52:08] 30.7 [20:52:16] rcflyinghokie: I never got the level 3 drawing for LDW 340 unfortunately [20:52:36] Oh my god I can't read [20:52:45] Yeah, I downloaded the one for stable [20:52:51] haha [20:53:14] thewonderidiot ah ok no worries, I found the tapemeter in the drawings and see lighting wiring coming off of it with a note to see 340 [20:53:15] Thank you. I feel stupid [20:53:24] Haha seems to be a common theme [20:53:30] I did the same my last install [21:15:17] a few months ago I ran a simulation for around 90 hours testing Niks drag branch. I did not notice the fps drop. [21:19:28] very odd [21:30:39] I have done a 30 hour run and didnt have one either [21:30:56] but I typically save a lot and load [21:32:54] Hey guys [21:33:03] Greetings [21:33:12] "Merry magic kings" [21:33:18] Well, it was yesterday [21:33:27] Here in spain we celebrate it [21:33:40] It´s like christmas day but again [21:33:43] :D [21:34:14] In The Netherlands we call it "three kings" :P [21:34:37] Merry three kings to you too haha [21:34:45] thanks :D [21:35:07] One quick question: On the Apollo 8 flightplan, when it says Maneuver spacecraft to sighting attitude [21:35:14] What does it mean? [21:35:27] To look at earth through windows 2 and 4? [21:35:54] Pretty sure it is move the sextant in view of the stars in P52 context [21:36:24] I am at 27:05:00 GET [21:36:38] So the sextant already looks at stars... [21:37:09] And no further activity until 28:15:00 [21:38:12] You have a P23 right after. So this probably means the earth [21:38:48] So look at earth with sextant, not windows 2 and 4 [21:38:54] Do you get any kind of attitdude from MCC? If not I'm pretty sure P23 also does an auto maneuver [21:39:02] Nope [21:39:04] rcflyinghokie: Thoughts? [21:39:06] No PAD there [21:39:27] P23 does do an Auto Maneuver [21:39:47] So sighting attitudes were read up to the crew [21:39:52] Our MCC doesnt compute them currently [21:40:18] Oh [21:40:26] Yeah they are placeholders right now [21:41:47] But it´s an attitude to put the earth on the sextant or on the windows 2 and 4? [21:46:27] Its the P23 attitude [21:46:49] Its the expected P23 attitude for the first star selected [21:51:15] Aha [21:51:18] I see [21:58:29] Basically its less awkward to V49 to the expected attitude and trim with P23 [22:06:03] Turry your post the other day made me look at the optics code again and I did find out where in the AGC things are getting messed up. I don't know what causes it to happen though. Have you done anything or have your noticed anything while interacting with the optics leading up to the issue? [22:06:09] Think zeroeing them and such. [22:06:49] After I did the P06 and recovery at around... [22:07:11] 25:00:00 ish [22:07:17] Everything nominal [22:07:23] Did 2 P52´s [22:07:28] And various P23 [22:07:45] and everything nominal [22:12:52] Didn't notice anything before you first had trouble with auto optics? I know I'm a bit vague, I don't really know what to look for either. [22:17:35] I think not [22:17:46] Nothing strange on the AGC [22:17:58] before i had that truble [22:18:03] *trouble [22:18:22] I first noted it during the first P23´s on Apollo 8 [22:18:35] The ones with earth landmarks [22:49:41] Nite guys [00:06:00] rcflyinghokie: Are you reading #off-duty in Reentry discord? :D [00:51:44] No I have been out [00:52:29] Oh the fella I blocked for being annoying and childish [00:53:15] if he shapes up I am ok with it [01:37:20] But he is immature as they come [01:50:27] just my 2 cents [14:50:55] Hey [14:51:16] My w-matrix overflowed. I'm not quite sure how I should reinitialize it [15:17:44] i have no idea what im doing havent used this in forever [16:39:56] hello [16:41:47] Hey [16:41:55] About to do the last rev on Apollo 8 [16:52:39] cool. discord app is being a pain. back in a bit hopefully [17:05:49] hey [17:10:34] Hey Alex [17:12:58] When I look out the rendezvous window with track ir I can see MDC1 through it. Can that be changed to be non see-through? https://puu.sh/IBm0S/2729152fb7.jpg [17:38:22] AlexB_88 tried out your improved visuals this morning. very nice! it's amazing what a huge difference the metalness makes on the sm skin [17:39:27] Thymo, ah yes I meant to fix that [17:40:13] I guess I had forgotten some people use track IR :D [17:40:37] n7275, thanks! yeah the LM foil now actually looks like foil lol [17:41:38] oh and Thymo, I will have to separate posts in the forums almost ready, one for the CM VC and one for the textures update [17:42:40] s/to/two [17:43:48] I guess I will just post both as separate threads? [17:48:21] morning! [17:49:31] hey Mike [17:57:38] AlexB_88: Sweet. Just post them to the same thread. Then I can merge them both at once [17:57:51] ok [17:58:05] will I be able to edit them after the merging? [18:04:10] I think so [18:31:02] Thymo, 1st one posted [18:31:03] https://www.orbiter-forum.com/threads/cm-virtual-cockpit.40302/ [18:31:14] so I will reply to it with the 2nd one [18:31:54] I'm ready [18:33:45] ok, it will still be a few minutes for the texture update one, Ill let you know when I have psoted it [18:34:21] okay [19:15:47] Thymo, all done [19:19:25] Done [19:21:14] awesome, thanks [19:24:02] Very nice [20:57:14] Alex, to build upon your work, how do you feel about normal maps? https://i.imgur.com/a7wwm7V.png [21:22:53] n7275, wow, looks very good [21:23:16] I honestly didn't even think of it for the foil [22:03:51] n7275, did you come up with a texture for that? [23:07:32] rcflyinghokie: Are the INFO and REV buttons in the checklist mfd even implemented or ar e they broken somehow? [23:20:54] Hmm I am not sure I dont think I have tried them lol [23:43:37] AlexB_88 Iused this tool http://www.smart-page.net/smartnormal/ I'm sure there are better ways, but for 5 minutes of work I think it looks passable [23:47:25] n7275, how did you load the image? I tried loading goldfoil.dds but it doesn't seem to do anything [23:53:58] ah, I guess it does not accept dds files [23:58:58] wow that is amazing [23:59:42] like you said for 5 mins of work lol [01:39:36] it needs a good eye to make sure the normal are pointing in the right direction but other than that it's amazingly easy [15:28:13] Hey Nik [15:40:05] hey! [15:40:08] happy new year [15:48:09] Hey Happy new year :) [15:52:42] happy new year! [15:56:36] haha wasnt that last weekend? [15:56:48] Oh Niklas is back! [15:57:18] not for me in this chat at least, happy new year, haha [15:59:05] happy new year :) [15:59:26] now I get to try and figure out where I left off, had to do that quite a few times lately [16:01:45] good morning [16:01:55] hey Alex [16:09:36] ah I was trying to push the Orbiter aerodynamics to the edge so that it can be singularity free [16:09:53] instead of bypassing the system entirely and just use AddForce [16:13:36] indy91, by the way if you have D3D9 R30.7 you can enjoy some new metallic effects on the CSM+LM [16:14:06] and proper CW light colors :) [16:14:19] also, some textures by Max-Q have been integrated into NASSP with his permission [16:14:22] and if I update to the latest NASSP first :D [16:14:39] the effects wont work with R30.1 though [16:14:53] yeah I only upgraded to R30.7 quite recently actually [16:15:46] looks like there were a bunch of updates [16:16:37] the specular lighting handling was changed in 30.7 so I had to adjust them for all the materials to look good again, and also decided to add the "metalness" shader [16:18:52] indy91, we also were looking more into that pwr/signal fail light for the LM RNG/RNG RT tapemeter, its still a little elusive haha. I was trying to investigate if it was on all LMs or only later LMs [16:20:05] I remember looking at the schematics and they didn't help much [16:20:20] Yeah we have the logic flow diagram in the LM 8 handbook [16:21:00] and I found a possible clue in the LDW 350 [16:21:11] But it says reference LDW 340 [16:21:43] the tape meter block has lighting wires coming out of it which could be that [16:21:56] but also could be backlighting for all I know [16:22:58] n7275, suggested adding normal maps for some textures, and boy does it look good I think for the foil: [16:23:02] https://www.dropbox.com/s/1nub2t34e7ker3t/Screenshot%202022-01-09%2011.20.30.png?dl=0 [16:23:57] n7275 suggested* [16:24:15] Yeah it does [16:24:47] the CM really looks a lot more like in the photos from e.g. Apollo 9 [16:27:59] yeah [16:28:23] theres a few places on the SM that I think Ill add normal maps too [17:14:33] morning! [17:19:19] hey Mike [17:30:19] indy91 what would you think of removing the non MCC launch scenarios or moving them to another folder [17:32:59] well it's quite easy to disable the MCC, so they could also be deleted entirely [17:33:43] there are some advantages to having the RTCC initialized in the scenarios, whether it uses the MCC or not, so maybe all scenarios could be set up to be MCC scenarios [17:33:53] even if there is no support for all missions yet [17:35:53] I think thats a good idea [17:42:40] I think if you would have the MCC enabled for e.g. Apollo 15 right now it would do the displays like "Liftoff" [17:42:46] up to insertion [17:42:50] and then nothing more [17:42:57] so that should already work [17:43:07] making all scenarios MCC scenarios basically [17:43:54] I dont see any harm in that [17:44:08] Would probably make it a little less confusion [17:44:49] agreed [17:54:34] Alex do you by chance use these? http://absimp.org/orbitersim/apollolandingsites.html If so do they mess with anything? [17:55:25] I have been using them without too many issues, but I do see the LM sink or bounce around a bit especially on load [17:57:44] I do use them [17:58:12] yeah, theres issues with the LM sinking into the terrain sometimes [17:58:38] if you land right on the historical spot it should be fine though [18:15:43] Would it be worthwhile adding that to the installation guide? [18:15:48] I think they look pretty fantastic [18:21:08] yeah I think that is a good idea [18:21:31] heck maybe even ship them with NASSP at some point [18:21:43] with ggalfi's permission [18:26:27] indy91, I think there's something buggy happening with the VC click-spots when both CSM and LM are present, I have been banging my head trying to find the cause for the past few days [18:26:35] made an issue: https://github.com/orbiternassp/NASSP/issues/671 [18:29:06] this is separate from the click-spots at staging issue [18:29:38] for that I think we need to change to ShiftCG() in the saturn staging code [18:30:11] yeah, just a few more cases of ShiftCG [18:37:03] Yeah if ggalfi says yes I am all for it [18:42:18] for now though theres still issues with the visual terrain not aligning with the surface which the touchdown points settle on [18:43:07] not too bad on Apollo 11, but at Fra Mauro my LM lands like 50 feet above the surface, even at the historical spot lol [18:43:34] I think that might be an Orbiter bug [18:44:07] so for now Ill just put it in the installation guide as an optional [18:45:39] Yeah good call [18:45:54] At least having the link available [18:51:12] isnt the FOV for the AOT, SCT and SXT suppose to automatically reset every time you go to that panel? [18:51:31] Thats the behavior I am seeing but the gent I am helping in the forums says his is not [18:56:03] hmm, weird [18:56:05] works for me [18:57:16] yeah same, I am trying to get a scn file to test [20:02:54] alright I have these normal maps ready to commit [20:51:49] Thymo, thanks [20:51:55] posted a few pics: https://www.orbiter-forum.com/threads/orbiter-screenshot-thread.8/page-405#post-589651 [20:58:08] Steven really likes it [21:01:18] added one more [21:52:44] Nice master alarm :P [22:00:06] AlexB_88 those textures or landing sites shouldnt effect P57s should they? I have been trying to help someone with them and short of seeing if their technique is wrong I cannot figure out why i get good angles and his are huge [22:10:32] I don't see how [22:14:17] That was my thought as well, just trying to diagnose...but I am thinking its a procedure/technique thing [22:19:44] yeah dont think it would be an issue [22:19:58] ok just thought I would sanity check my thinking :) [22:20:11] unless his LM wasnt "settled" on the touchdowbpoints and constantly moving around a bit [22:20:32] which can happen if you land on a slope thats too steep, at least in Orbiter [22:55:18] This was the pre liftoff P57 for Apollo 15 [22:55:31] I have his save and its stable for me just canted a little [23:12:56] right [23:16:40] was the FOV thing sorted? [23:17:26] Not sure, I cannot replicate the behavior [23:17:41] On his scn mine changes back to 60 whenever entering the AOT [23:18:21] Wonder if monitor resolution could cause any issues with this? [23:42:41] ah [23:42:54] /set FOV to 60 degrees (except for lower resolutions) [23:43:03] he has a lower resolution [23:43:09] I think this is needed in his case [23:43:31] because the AOT must be bigger then the size of his screen [23:43:38] so the FOV is compensated [23:44:14] DWORD w, h; [23:44:15] oapiGetViewportSize(&w, &h); [23:44:16] oapiCameraSetAperture(atan(tan(RAD*30.0)*min(h / 1080.0, 1.0))); [23:45:20] Oh interesting [23:45:41] So how is this fixed [23:45:44] now if the AOT view is indeed taking up his entire screen (ie. doesn't need to scroll around) then that would be an issue I think [23:46:38] I asked what screen resolution its running [23:47:44] if he needs to scroll to reach the edges of the AOT panel then it means the FOV he has (56?) is correct and needed [23:49:22] and of course he has to NOT scroll the view since that will make the spiral out of alignment [23:49:49] what keys would scroll to reach the edges? [23:50:01] oh like any 2D panel [23:50:10] just the scrolling around the 2D panel I mean [23:51:16] for the AOT, a 16:9 1920x1080 is what its optimized for, and you should not be able to scroll at all in the AOT view if you have the nominal resolution [23:51:39] Yep I have never been able to scroll mine around [23:51:53] but if you have a smaller resolution, the AOT view will be zoomed in" and you will be able to scroll around [23:52:27] which means the FOV needs to be lower to compensate for the zoomed in AOT [23:52:46] and there is code which calculates that compensated FOV [23:53:32] Hmmm ok good to know [23:53:45] I guess I have always just played on 1920x1080 and never noticed [23:55:31] Any way to get the AOT back to a default position if scrolled? [23:55:48] just change view and back [23:56:02] ok [23:56:04] he just has to be sure not to scroll while using the AOT [23:56:10] that could be the issues here [23:57:13] the LPD use to be like that to actually [23:57:23] used* [23:57:52] and there was code for the 2D panel LPD to compensate lower res screens [23:58:25] but now the 2D panel LPD view is actually looking at the VC's LPD [23:58:50] so even if you scroll around its stays fixed with the centerline [23:59:04] and if you zoom-in or out, the LPD will as well [23:59:25] so no need for any FOV compensating code for the LPD any more [23:59:49] ah I think I remember the LPD scrolling a bit [23:59:53] eventually I will make a 3D version of the AOT, so this won't be an issue any more [00:00:20] That combined with moving the stars to their proper positions would be really great [00:00:21] yeah, you will notice now the LPD stays fixed even in the 2D panel [00:00:25] Yep [00:02:07] Well I mentioned the FOV and AOT scrolling in the forum post as well, I didnt think about that at all [00:02:17] Hopefully we can get him going haha [00:02:36] what FOV did he have again? [00:10:47] I think he said it was 46? [00:11:54] https://www.orbiter-forum.com/threads/apollo-15-lunar-ascent-preparation-and-rtcc-procedures.40282/page-3 [00:11:58] the thread haha [00:12:47] what is he using a 4:3? :D [00:14:29] I didnt think to ask until you mentioned all of that :P Hoping to get an answer [00:19:38] if its 46 sounds like he has quite a low resolution [00:19:54] probably a laptop or something [00:21:02] I think your theory is sounding more and more the case [00:21:25] Oh well at least I now have a P57 procedure typed out [00:24:51] haha [00:25:49] if he wasn't scrolling and wasnt changing the FOV, then the issue would be elsewhere I think [00:29:38] yeah thats why i thought procedural at first [00:30:18] You might be able to explain that better than I based on his reply [15:17:24] hey [15:20:38] morning [15:20:45] looks like it was the resolution [15:21:43] oddly enough the "FOV" set by NASSP (45.79) gave him worse results than rounding it up to 46 for some reason [15:21:45] https://www.orbiter-forum.com/threads/apollo-15-lunar-ascent-preparation-and-rtcc-procedures.40282/post-589685 [15:29:22] hmm, the code should find the exact FOV he needs so I woudn't change that I think [15:35:00] things were much easer when everyone had a 1024x768 CRT monitor [15:38:08] so what would explain better angles with using 46 vs 45.79 [15:38:27] technique is the only other thing I can think of [15:42:39] I think its technique, I find I really have to be very precise with the spiral, even on an HD monitor [15:42:56] so his low res is not helping there certainly [15:52:58] this may be obvious, but does he know about the ability to fine-adjust the AOT with alt-w/s? [16:08:47] Yeah I mentioned that in my pseudo tutorial [16:31:21] Hey [16:31:55] AlexB_88: You just got added as a moderator to the NASSP subforu. You can reply to the work thread and do other administrative actions from now on. [16:32:24] Thymo, awesome thanks [16:32:25] In addition Xyon gave everyone of us who didn't already have it the addon developer tag on the forum. [16:32:30] that will make things easier [16:32:56] Thankfully our forum moderation isnt a babysitting job like some places :P [16:34:24] Few questions on the installation guide [16:34:31] Is this still relavant: Note: At this time, it is recommended to leave "Gravity-gradient torque" and "Atmospheric wind effects" disabled as in some occasions they can cause CTDs with NASSP. [16:34:35] Indeed, I rarely have an actual need to use moderation stuff, but its very handy when I do occasionally. [16:35:26] rcflyinghokie: Don't know to be honest. I have them enabled but I do get the odd CTD every now and then. [16:35:43] Usually somewhere in OrbiterSound or d3d9 code [16:35:51] I have had them enabled as long as I can remember [16:35:55] same [17:21:14] I've had them enabled too, for as long as I can remember. [17:28:20] about the Gravity-gradient torque thing, here's the back-story [17:29:38] I don;t know if this would still be the case, but at one point there was issues with the SLA panels from the SIVB crashing into the moon which caused a CTD [17:30:47] at 1st I had no idea why I was getting a CTD around LOI time, but after a long investigation I found it happened at the moment of lunar impact of the discarded SLA panels lol [17:31:14] interesting [17:31:19] and the fix? un-checking Gravity-gradient torque [17:31:33] I haven't run into that one lol [17:31:47] mind you this was back in 2017 or 18 so maybe worth testing again [17:31:52] its very rare [17:32:12] I guess the SLA panels are not always in a lunar impact trajectory [17:32:32] but it could also be that the CTD doesn't happen any more, not sure [17:34:04] and I think Atmospheric wind effects caused a CTD when a certain discarded stage (SII?) impacted the ocean [17:34:15] at least it did back in 2017 [17:35:19] might be worth looking in the orbiter code for the cause. if memory serves Orbiter computes some distributed-mass properties from MOI alone. maybe we have a singularity that we could remove by making a very small adjustment [17:38:19] Is it just the impact that happens to be caused by that option or the combination of that option and the impact causing the crash? [17:44:31] im not 100% sure, but I think its the combination [17:44:44] I will have to look at it again [17:45:27] morning! [17:45:39] I definitely remember in my testing back then that having them un-checked made the CTD go away [17:45:41] hey Mike [18:07:51] Hmm wonder if they just don't impact [18:07:59] Afterall TLI has been much improved [18:08:21] yeah [18:08:36] Any idea what the lowest (actual) post TLI PC was offhand? [18:09:04] a test maybe do an early cutoff during TLI [18:09:17] then separate and time accel to LOI [18:09:46] hmm good question [18:10:21] I believe there was at least one mission who's PC was below the surface [18:10:55] before MCC-2 of course [18:18:37] I think 8 was [18:19:31] Also caused P21 to stall out [18:20:20] So that would make sense that the SLA panels could hit [18:21:03] Ah yeah it was like -130nmi at TLI cutoff [18:21:33] and that was probably the mission I was testing when I had the CTD [18:33:32] Would make sense [18:33:51] I have flown a lot of 8's though with that enabled, I am curious if its still a thing [18:34:10] I would think other things impacting would cause a similar response [18:39:24] Hell we have been targeting the SIVB to impact [18:41:49] Is it possible that Martin's docked MOI fix also fixed the issue causing the CTD? Would be interesting to try in 2016 and see if you still get the CTD [23:38:12] well I think I fixed the issue with the click-spots being lost at staging in Saturn [23:38:16] https://github.com/jalexb88/NASSP/commit/d52c13de5807f30d73c440eb2dce1838a2d89d8f [23:39:25] did a lot of testing to be sure it didn't break anything else IE. the variable CG stuff in the CSM [23:39:58] going to get Nik to look at it though before I PR [23:40:36] and this is not related to this issue: https://github.com/orbiternassp/NASSP/issues/671 [15:38:05] morning [15:47:24] Good morning [15:47:46] Hopefully have Wedge sorted out with his star marks at this point :P [15:48:08] I do appreciate his attention to detail going through a J mission as he has [15:55:55] he's got quite good angle diffs but he seems to not want to move on lol [15:56:07] angle diff OCD [16:08:30] Thats why I am trying to push him along :P [16:08:43] I mean 00003 was great for a P57 [16:11:22] I think I figured out the clickspots breaking at scenario start from VC [16:11:38] and its Nik's fault :D [16:11:45] Haha! [16:11:56] the variable CG stuff is the culprit [16:13:14] but its very weird because the each vehicle's variable CG function "UpdateMassAndCoG()" breaks the other vehicles VC clcikspots [16:13:48] so the UpdateMassAndCoG() in the LM is breaking the CSM's clickspots and vice-versa [16:16:13] not even sure how that is possible lol but it does [16:18:56] That is very interesting lol [16:19:06] Something with the CG and view spots? [15:44:24] good morning [15:58:45] morning! [16:25:34] ugh, after 22 months of avoiding it COVID finially caught up with me. 0/10 would not recommend. [16:32:43] ah that sucks, hope for a fast recovery! [17:13:08] yesterday was rough but I'm better today [17:16:25] glad to hear [17:18:25] morning! [17:22:57] hey mike [17:23:11] hey [17:23:26] I think I found an Orbiter bug [17:24:15] basically, it seems ShiftCG seems to be changing the click-spot position of EVERY vessel's switches registered in the session...not just the switches of the vessel its called in [17:24:38] wrote about it here: https://github.com/orbiternassp/NASSP/issues/671 [17:25:15] oh interesting [17:26:13] I tested it it with Orbiter native vessels and it happens there too [19:11:15] that shiftCG issue is very odd [19:12:58] yeah very weird [19:13:44] if it is an Orbiter bug i'm surprised nobody noticed it before [19:17:15] I think we use the API a bit harder than anyone else does [19:18:20] then I guess it take specific conditions to reproduce it...multiple vessels in the session, dynamic CG updating, virtual cockpits [19:18:23] yeah [19:23:50] almost seems like something is static that shouldn't be [19:42:22] ah GLS on the forums just reproduced it [19:42:39] Hey [19:42:44] n7275 Get well soon! [19:48:32] hey Thymo [19:50:12] Did you guys happen to see the MFD screenshots I posted to Discord? [19:50:52] I added the ability to change automatic checklist execution to the checklist mfd. [19:51:28] That means that now you have "autocomplete" and "autoexecute". I'm a little worried people might find that confusing. What do you guys think? [19:51:31] oh nice [19:52:03] I definitely like the fact you can do that in the MFD now [19:52:35] It's non-persistant for now, when you exit it will revert to what you set in the PA configurator [19:55:05] probably for the best [19:55:38] like if you forget a certain scenario has autocomplete on [19:55:50] that could be bad haha [19:55:55] It is a global setting, just not persistent [19:56:12] Even if I made it persistent it would be a global setting not tied to a scenario [19:56:22] right [20:07:33] I like autoexecute for when it goes through and flips the switches for you [20:07:50] but yeah autocomplete can be confusing now that I reflect on it [16:17:44] hey [16:24:15] morning! [16:24:56] hey Niklas [16:24:59] what's up? [16:25:08] think I found an Orbiter bug [16:25:18] Transporter-3 just launched two of our sats -- so today is an operations day :D [16:25:51] which causes the click Area corruption at scenario start from the VC [16:26:56] yay, we can blame Orbiter instead of NASSP for once [16:27:12] thewonderidiot, awesome... amount of work coming your way [16:33:40] I'm still comparing aerodynamics between the NAA simulator and Orbiter. There is even a difference in the 2D case which I can't really explain yet. Hope that's not an Orbiter bug, too [16:38:38] thankfully nowadays we can do something about it if its an Orbiter bug [16:39:41] well, we don't use Open Orbiter (yet) [16:40:38] but at least we can read and understand what Orbiter does [16:41:51] right [16:43:17] I tend to trust the NAA simulator, although it could have typos [16:45:44] btw, regarding the other click-spot issue at staging, I have a PR which changes the remaining ShiftCentreOfMass() calls to SHiftCG() in Saturn [16:47:05] https://github.com/jalexb88/NASSP/commit/d52c13de5807f30d73c440eb2dce1838a2d89d8f [16:52:03] this fixes all the lost click Areas at staging, EXCEPT the CSM/LV sep when a LM is created [16:52:31] but that is beacuse once the LM is created it falls into the other issue (caused by the suspected Orbiter bug) [16:53:10] but I tested this branch a lot and it works quite well so if your happy with it Ill go ahead and PR [16:54:59] I'll look at it. But I think in general the change to ShiftCG isn't too difficult. What will be more work is the cleanup, because it's then rather unnecessary to delete and creates all the meshes etc. from scratch again [16:55:04] if everything can be shifted instead [16:56:06] right [16:56:11] SetReentryStage(_V(0, 0, 13.15 + 2.0499)); [16:56:17] 2.0499 changed to 2.1? [16:56:46] well its a 2.1 shift between CSM stage and Reentry stage [16:56:56] right [16:57:00] must have been an error [16:57:02] and 2.0499 didn't work and 2.1 did [17:00:51] the 2.0499 is also used in if (stage == STAGE_ORBIT_SIVB && new_stage == CM_STAGE) [17:01:14] ofs1 = _V(0.0, 0.0, S4Offset - 2.0499); [17:01:48] in the offset used to create the discarded SIVB I guess [17:07:45] so many numbers and no idea where they come from [17:09:15] tell me about it [17:10:39] so many of these for example: const double CGOffset = 12.25+21.5-1.8+0.35; [17:10:50] lol [17:12:02] the original developer knew where the 12.25 came from [17:12:17] and then more people just added new offsets to it, I am definitely guilty of this [17:17:00] if we want to ever fix that then we need to make a decision where the CG of each stage is relative to the actually used coordinate systems [17:17:23] and make that a fixed, known number and use it everywhere. And in doubt change the meshes themselves to conform to the numbers [17:17:48] because I am sure our CSM and Saturn stages are still not the exactly correct size [17:17:56] LM is better because you remade it [17:19:26] yeah [17:20:30] at the top of Saturn::RegisterActiveAreas() [17:21:09] the offset there is basically a simplified view of all the shifts [17:37:51] aaaah, found the aerodynamics issue [17:37:59] it was my mistake [17:38:31] because the CSM is symmetric, I was only calculating lift and drag coefficients from 0° to 180° angle of attack and not -180° to 180° [17:38:45] so I had to invert the lift coefficient if the angle is smaller than 0 [17:39:10] now I get (in the two dimensional case) the same numbers for NAA simulator equations and Orbiter [17:41:13] ah nice [17:41:32] now I can try working on the singularities we get in Orbiter [17:43:35] I guess its still set at 0.05 of actual drag? [17:48:15] yeah. a few weeks ago I pushed an update, no lift, 5% drag, 100% of moments [17:48:58] lift and moments can have singularities, for example if you are nearly 90° yawed out-of-plane. Then the slip angle is that near 90°, but the angle of attack is basically random [17:49:18] the system Orbiter uses is good for aircraft which don't usually have these extreme angles [17:50:28] I was flying Apollo 7 to update the MCC for eventually 100% drag, but then I saw these random values when you are yawed or pitched at 90° [17:50:47] random values for the moments [17:51:07] I think I can implement a system that uses the standard Orbiter method for lift, drag, moments [17:51:15] if I really have to I could do it with AddForce [17:55:38] right [17:58:46] so we'll soon be able to do the cobra maneuver with a CSM? :D [17:58:50] https://en.wikipedia.org/wiki/Cobra_maneuver#/media/File:SAAB_35_Draken_performing_the_Cobra_maneuver.gif [18:00:20] exactly [18:00:33] although you will find that all you have to do is att hold [18:00:54] and you will get to +/- 90° pitch relative to the airstream all on your own [18:09:58] hey guys [18:10:30] hey [18:11:52] PR sent [18:12:31] good morning :) [18:15:24] I think I know my way around the staging stuff enough to start doing some of the clean-up work such as mesh deletion/creation [18:17:59] hey guys [18:18:21] AlexB_88, great [18:18:56] https://i.imgur.com/aDGfEoR.png [18:19:22] this happens if you point the CSM exactly forward, then yaw out-of-plane by 1° [18:19:28] and then pitch 360° around [18:19:38] ouch [18:19:47] at -90° and 90° pitch bad things happen [18:20:09] because the side slip angle as calculated by Orbiter essentially becomes undefined [18:22:24] there is a general trend that the aerodynamics will push the CSM back in-plane if it's pointing out-of-plane [18:22:36] but near 90° that doesn't properly work yet [18:22:46] due to that issue with how Orbiter does things [18:26:55] random question, is there a good doc or equations for how the LM treats the transposition of N22 angles to N18 angles? [18:27:46] I can tell you the GSOP page with the exact equations for it [18:28:10] well it's 5.6.12 FDAI-IMU Transformations [18:28:16] in the LM GSOP section 5 [18:28:28] ah perfect [18:30:17] Thats exactly what I was looking for [18:30:17] AlexB_88, ah I see you are using the system I implemented for the CSM to CM CG shift for all cases where the state changes to CSM now [18:30:43] that should work I guess [18:30:44] ShiftCG(-currentCoG + cg_ofs); [18:30:54] currentCOG will ony be non-zero on the CSM stage [18:30:57] yeah I did it for the CSM [18:31:53] for the saturn stages I simply called the ShiftCG before the state change call [18:32:47] right, and removed the ShiftCenterOfMass [18:34:18] ah sorry, Orbiter is british [18:34:21] Centre not Center [18:35:15] haha [18:36:42] Need the Orbiter Translator plugin [18:38:34] Open Orbiter branch with certain issues "fixed" so that Americans are able to read the code [18:40:30] I don't have that problem of course, we learn British English in school here in Germany :D [18:41:01] Lol [18:44:42] I had to present a paper to a French organization, in the Netherlands a few years ago. One of the requirements was that it be in British English. It has forever ruined my ability to spell certian words... [18:46:37] Haha yeah some of that spelling, having grown up in the US, immediately stands out as wrong because of how my brain is wired [18:46:59] I see "tyre" for example and am like wait a minute something's not right [18:47:26] me spending two summers in the US definitely helped my general pronounciation more than it hurt that I was now talking more American than British English [18:48:08] I guess I also didn't write that much when I was in the US, so that didn't cause any issues [18:49:08] AlexB_88, did you test any Saturn IB pad abort? [18:49:26] Either I don't understand then code or there could be something wrong in the PR [18:49:35] every possible abort in both Saturns [18:49:38] hmm [18:50:07] vs3.vrot.x = 39.5 + 28.4; [18:50:10] this is altitude, right? [18:50:20] yeah [18:50:26] that is for the landed state [18:51:15] oh you also changed the number for SetReentryStage [18:51:23] was that wrong? [18:51:58] or is there some shift in the chain of events that you removed [18:58:19] ok so SetReentryStage was 35.15 even before for the not landed state [18:59:34] and that worked well, the CM click areas still worked when doing a pad abort [19:00:02] but the old 32.55 did not work for the CSM stage (ie. doing a CSM staging from pad) [19:00:31] and it should be a 2.1 difference anyway so 35.15 - 2.1 = 33.05, not 32.55 [19:00:55] and with 33.05 the click areas work at staging for the CSM [19:01:47] for the landed state, there was no shifting at all of the centre of mass before [19:02:18] but of course it needs to have one (ShiftCG) for the click areas to shift [19:06:29] hmm, then I don't really understand what the vrot.x setting does [19:09:21] its for when you do a pad abort while in the landed state [19:09:37] right, but in your PR it does both [19:09:54] the vrot.x change should work similiar to ShiftCentreOfMass [19:10:02] and then another ShiftCG? [19:11:10] that still looks visually right from the outside? [19:11:49] or does the CM get created too high. Did you check that, too, or only if the click spots work right? [19:11:58] the ShiftCG was added or else the click areas didnt translate [19:12:29] but I see what you mean, it doesnt seem to do a shift twice visually [19:12:56] ie. once with vrot.x and again with ShiftCG [19:13:11] yeah [19:13:18] visually it seems to have only done the 33.05 or 35.15 shift once [19:13:24] ShiftCG calls ShiftCentreOfMass internally [19:13:31] right [19:13:34] I wonder if something there works differently when landed [19:14:30] without the vs3.vrot.x thing, aborting from a landed state makes the CM seem to abort from the center of the rocket [19:14:37] and the rocket itself just disappears [19:16:50] I think the same is done in the LM [19:16:57] right [19:17:15] well I'm sure I'll understand it eventually :D [19:17:33] Orbiter landed physics are weird [19:17:49] staging from the landed state vs2.vrot.x = 5.32; and then the ShiftCG is called in SetLmAscentHoverStage(); [20:38:54] indy91, jsut looking at SetState2 in Orbiter source [20:39:53] yeah, haha, the code for the landed state is a bit difficult [20:40:32] https://www.dropbox.com/s/7lz2yyivjusyaun/Screenshot%202022-01-13%2015.39.51.png?dl=0 [20:41:20] case 1 landed at the bottom [20:41:53] I dont know if there is a ShiftCentreOfMass in there at all [20:47:26] it calls InitLanded [20:47:31] which does manipulate the position [20:47:48] without calling ShiftCentreOfMass, just by changing internal variables for the position [20:47:55] which is what makes it complicated to understand [20:55:49] right [21:00:17] does a ShiftCentreOfMass() call on its own even work when a vessel is in a landed state? [21:02:27] or even most of everything else that is called in a ShiftCG [21:03:52] and its really just the if (g_pane) g_pane->ShiftVC (vs); part of ShiftCG that is not ignored when called from a Landed state? just an idea [21:30:09] not sure, have to look at those position variables that are being changed in some detail [21:30:13] night! [14:49:02] Good morning [14:50:38] Have an interesting one on the forums, cannot seem to fire the RCS out of direct [14:52:27] Even the CMC isnt using the RCS [15:04:34] Ah the SM relays werent on [15:12:27] Wonder what would have caused those to disengage [15:13:50] used a mission scenario where it was off [15:13:55] https://github.com/orbiternassp/NASSP/commit/0feffecb2fa8d18197c9c91c52779dc1133d6d16#diff-5937bd57660217a5f0d4cf9bcb362dafcc566d99b35e36da274c3c69d2c7b24b [15:14:14] that fixed the mission timer and added the state of the SECS, but with those relays off [15:14:24] seems to be the case for the TEI scenario and later [15:14:54] Ahh [15:15:33] Yeah it was a TEI one [15:17:18] I can fix them [15:17:41] Want to remove the non MCC scns while you are at it? Or move them to another folder :P [15:18:35] right [15:18:56] I probably should delete the other scenarios and rename the MCC scenarios to what the non-MCC scenarios are currently called [15:19:25] won't be good for the git commit history, but that's the best name for them [15:20:27] and later on I'll add the MCC to the other launch scenarios [15:20:42] but that isn't critical and those aren't strictly supported scenarios [15:21:38] right, just generates a little confusion on which one to choose for newish people since they are in the same folder [15:23:28] funny, git detects the change in the Apollo 11 scenario as just adding the MCC to the file, not any deletion or renaming of the file [15:23:45] huh [15:24:02] huh x2 [15:24:13] found a difference between the two Apollo 7 scenarios :D [15:24:22] a LVDC padload I had renamed [15:24:30] which one is correct... [15:26:45] which one had the correct one [15:26:48] Haha [15:27:04] I think the one in the non-MCC scenario, but all those padloads default to the Apollo 7 launch parameters [15:27:15] so even if the wrong ones were set in the scenario, they are all correct [15:27:33] that happened when I changed the Saturn IB LVDC to use the Skylab variable launch targeting [15:28:47] where launch azimuth, inclination and descending node angle can all be variable, but by default it's fixed values like Apollo 7 would have always launched to 72° [15:29:16] Assuming launching at the beginning of the window :P [15:29:41] well for Apollo 7 (and 9) they would have always launched to 72° [15:29:55] I think Apollo 7 didn't even launch at the beginning of the window [15:30:10] aaaand found another difference on Apollo 9 [15:30:24] but it's just the DAP config [15:31:04] which seems to be part of the padload, but I think it even defaults to that when the AGC restarts or so [15:31:18] Is that the correct padload? [15:31:30] the 31102 and 01111 in V48, literally padloaded like that [15:32:09] That would make sense [15:34:32] it does appear in padloads, yes [15:36:37] but I think the software sets those as well, not quite sure right now [15:40:37] So after a restart it defaults to a 3 in R1 A [15:41:08] hey [15:41:48] hey Alex [15:41:55] morning [15:42:04] not so sure anymore, we used to set those DAP settings in our code for the padload [15:42:09] that got removed at some point [15:42:15] Apollo 9 T-60s scenario is older [15:42:22] so it still got set by our code [15:42:56] and we have it in our checklists to set V48 after insertion [15:43:13] https://github.com/orbitersim/orbiter/pull/161/commits/40d6a632dce5dc129fabba404905712d4ba2ab54 [15:43:15] so maybe some people who flew Apollo 9 from scratch and not using the T-60s scenarios had all zeros [15:43:26] and then entered the 31102 and 01111 [15:43:40] in any case, it's not back in the padload [15:43:42] now* [15:44:12] I think all missions checked the DAP load for that after insertion anyways [15:44:38] it's in some checklists, yes [15:44:49] in all of ours, but not all flown ones I think [15:45:02] and another LVDC padload difference, Apollo 10 [15:45:12] I did not do a good job having the two launch scenarios identical [15:45:20] Hmm I think verifying the DAP is in every launch checklist we have [15:46:03] not the Apollo 9 abbreviated crew checklist that Mike scanned [15:46:27] oh interesting [15:46:56] but that would be different from the launch checklist [15:46:58] but it's in the Apollo 8 TLI checklist [15:47:22] Yep [15:47:35] And in 11, 12, and 15's launch checklist [15:48:06] 13 as well [15:48:51] not sure the abbreviated checklists we have for 7 and 9 were flown [15:48:58] might just be for crew training [15:49:13] could be [15:49:28] The launch checklists seem pretty consistent with verifying that DAP load [15:49:38] yeah [15:54:02] AlexB_88, I don't understand that fix [15:55:20] wouldn't that prevent the VC from being shifted at all if ShiftCG is called in a vessel that is not currently the focus? [15:56:33] yeah but once you switch to the other vehicle, clbkloadVC recalls all the AID's at the correct spot [15:58:16] ah true [15:58:25] so a bit of a workaround [15:58:40] the ShiftVC still does something bad, but it's not called in this fix [15:59:25] ah found it [15:59:26] https://github.com/orbiternassp/NASSP/commit/bbbae63040828ce405fc4eec2dbcadbd436adeab#diff-8678884d6d1c09dd6fc08e92987b3d512a42ef4f8dddec0abc986829f004ca17 [15:59:36] this is the change I accidentially only made to the MCC scenario [15:59:44] and not the non-MCC scenario [16:01:16] ok, pushed the scenario updates [16:01:28] no more non-MCC scenarios for Apollo 7-11 [16:01:48] Excellent [16:01:50] indy91, I think the ShiftVC only takes care of shifting the AID's and HUD pos [16:02:25] but those are only loaded for the current vessel, did I understand that correctly? [16:02:39] so a ShiftCG call in the non-focus vessel did bad things [16:02:47] yeah [16:03:43] I think every time clbkLoadVC is passed (every time you go into a vessels VC) all the AIDS are deleted and remade [16:03:49] so only for that vessel [16:04:19] so other vessels ShiftVC calls will mess up this vessel [16:07:38] you can see the issue in action easily, just go into the CSM VC, fire the engine with the SPS direct, then switch to the LM's VC, for a few seconds the click areas are fin but then they stop working [16:15:23] was just confused, but you mean letting the SPS continue to fire which triggers the ShiftCG, right [16:15:56] yes [16:16:13] then after the 100 KG used the ShiftCG call [16:16:41] right. I guess this is the only way to fix it then [16:16:46] morning! [16:18:56] good morning [16:19:35] hey Mike [16:21:29] hey [16:45:23] hey guys [17:11:23] indy91: Hey could you do me a favor and try doing noteworthy changes through pull requests? I'm trying to keep track of what gets merged through the NASSP 8 milestone so it can be included in a changelog when NASSP 8 releases and if things get directly committed I won't be able to find them. [17:14:26] you mean the scenario change? [17:15:06] I guess it's kind of noteworthy, right, even if very little changed. The two scenarios were nearly identical, so it felt more like deleting a duplicate haha [17:17:13] Yes, exactly. That change will now get lost in the endless stream of commits and once NASSP 8 releases I guarantee I won't find that specific commit as its own change and not include it. [17:19:00] I try to keep track of absolutely every change that goes in. If it turns out to be very minor I label the PR with 'ignore changelog'. Once I rework the way our builds get done I want to turn off committing to that branch completely as each PR will get a test build to see if things still compile okay. [17:21:22] yeah it's especially annoying with this kind of commit where it doesn't detect it as a deletion and replacement but as a deletion and small modification of the original scenario [17:21:54] so even if you stare at the commit you wouldn't necessarily see what it properly does [17:24:48] I was thinking about making a post in the forum about it. I should have thought: "that's noteworthy" -> "so better make it a PR" at that point [17:26:29] Yep, even those posts are hard to track TBH. By tagging them to the milestone I can just open up the milestone and look at the title of each commit. I'll instantly know what the change was about. [17:30:22] I'm not so sure every update needs a PR. Sometimes there are a lot of small fixes and then you just get a stream of almost as many PRs as commits. [17:30:35] But I should be doing a lot more PRs, that makes sense [17:32:21] I've been mostly working on big, complicated, very long projects in the last time, so most of my output falls in that category [18:14:33] wow [18:14:48] the NASSP scenario directory looks so clean now :D [18:20:07] :D [18:21:57] I'm making good progress on these LM study guides -- just a few more to go and then I can get all of the CSM functional integrated system schematics scanned [18:22:10] I got the EPS study guides scanned but not processed last night [18:26:54] correct me if I'm wrong, but can't you tell git explicitly to rename a file? [18:27:12] `git mv` is the closest thing [18:28:20] ahh, yep [20:11:48] I recommitted those commits and applied them through a pull request so they are tracked. [20:21:43] oh, awesome [20:22:12] I had to do dirty things though [20:22:21] I can imagine [20:22:56] ah you put that other commit in there as well [20:23:03] that just fixed some old scenarios [20:23:32] about your PR description, it's true for Apollo 7-11. They were always flyable with the RTCC MFD. [20:23:44] the other missions and alternative launch dates still have no MCC [20:24:29] the RTCC init happens when you open the RTCC MFD or done by the MCC when it reaches orbit [20:24:35] Well yeah. I suppose I could have added it was within context of the next release. [20:24:42] right [20:25:21] The ones without MCC are under WIP so it doesn't really matter. People can't complain if its broken. [20:25:30] true [20:26:02] some things are even just barely supported by the RTCC MFD... see multi page Apollo 15 thread on the forum [20:26:55] Apollo 5 also has MCC support, but there never were two scenarios [20:27:25] Apollo 5 had some uplinks, they had some interesting things planned, like uplink a wrong mass on purpose to see how the DAP deals with it [20:27:51] so that always happens in the scenarios for it [20:30:59] I would consider Apollo 5 part of the supported scenarios for NASSP 8. It tends to break easily as it doesn't get quite as much testing when big changes happen [20:31:12] I'll move it to the main scenario folder at some point [20:33:44] You know I have never actually flown it in it's entirety [20:34:02] Same [20:34:34] well it's not very interactive haha [20:34:42] and you have to wait a while until things start to happen [20:35:25] there isn't a flight plan for it, at some point I need to at least include a schedule of events [20:36:00] I can promise you more different AGC program numbers than you have ever seen in the span of a few hours haha [20:36:50] and what makes that mission awesome for me is what goes on behind the scenes [20:37:21] the LGC runs the code for deleted program P61, which was supposed to be the onboard calculation of the DOI maneuver [20:37:31] it runs actual LM descent and ascent code [20:37:42] lots of epic stuff [20:38:21] so because it's just a playback essentially in NASSP, you need a lot of background to have fun with it [20:59:08] Hey if it's the LM I can have fun with it regardless ;) [21:03:30] The RR shaft animation is buggy [21:04:39] Sometimes it gets in weird positions, I have seen that [21:04:53] if the animation is not actively being updated it goes into an inverted position [21:04:58] if (rr_proc[0] - rr_proc_last[0] != 0.0) lem->SetAnimation(anim_RRPitch, rr_proc[0]); [21:05:09] if I take the if statement out it works [21:05:41] the if statement just ensures the animation is not constantly updated if there is no change to the shaft angle [21:06:17] the trunnion works fine even with the if statement so its weird [21:16:50] I just got admin access to the NASSP SourceForge project [21:17:00] oh man [21:18:00] I emailed Daniel. At first he replied "I no longer maintain NASSP. Have you tried talking to the maintainers?". Then he looked my name haha [21:19:37] Had I done this earlier I could've just dumped the database... [21:19:47] n7275 [21:20:41] I smell a cleanup [21:21:08] I plan to redirect as much as possible with the eventual intend to get rid of it [21:27:17] n7275, you posted on the forum an issue with missing DX libraries for running open source Orbiter [21:27:31] I have the same issue, did you manage to fix it? [21:33:40] First order of business: Add a redirect button to the GitHub page. https://sourceforge.net/projects/nassp/ [21:52:59] night! [21:56:41] And also sort of disabled those ancient downloads [22:19:39] I have SFTP access too. Here I was thinking Daniel had lost all access to the wiki, I can get to everything without any trouble. [23:13:34] Hey Thymo [23:13:50] i have not had a chance to look at it again [23:14:40] Hey Matt [23:15:30] I'm a few days behind on IRC logs too.. [23:27:46] AlexB_88 I haven't had a chance to dig into the open orbiter stuff again, unfortunately. I'm fairly certain at least one other user did though. [23:33:22] Thymo, I like the sourceforge redirect. [23:35:09] the sf page says "234 downloads this week" that's more than I would expect... [23:35:52] Try to click the download button [23:36:13] I did everything to get people to download from GitHub. Short of deleting the project. [23:39:10] haha I like it [23:39:34] I was suprised people even used that. The builds aren't even updated there. [23:39:51] Last one was september, build 1719. Who knows how buggy that was. [23:54:23] must've been good. all our reviews are 5 stars. "good software" [15:09:19] Good morning [15:20:57] hey Ryan [15:21:39] we have questions :D [15:22:16] Uh oh [15:22:22] Whats up [15:22:38] Oh the forums haha [15:23:08] Yeah I am looking at the first one now, stuff "not working" like P51 and ORDEAL [15:31:51] P51 could be optics not nulled [15:32:05] or procedural error, like not entering the right star [15:32:37] Yeah thats what I am thinking [15:36:15] Looking at the ORDEAL one, about the pad attitude being 0 0 0 [15:37:03] At this point the REFSMMAT was established by burn, which was retrograde [15:38:01] What would determine if that was heads up or heads down when the computer does it [15:38:30] CMC? [15:38:34] Yeah [15:39:51] always heads down [15:39:57] Thats what I thought [15:40:08] so 0 0 0 would be heads down [15:40:11] retrograde [15:40:19] for SPS6 [15:41:31] right, Apollo 9 SPS-6, purpose of the burn is to get the perigee down for better SM RCS deorbit capability [15:41:41] so that's always going to be retrograde [15:43:52] Right, so 0 0 0 is correct, I think he is assuming FDAI is showing LVLH attitude [15:44:11] Also I assume the drift is from atmospheric drag? [15:44:15] Q4 [15:44:17] yep [15:44:27] that is new and already at 100% strength [15:44:33] even if not 100% correct yet [15:44:41] I wonder if that REFSMMAT is the wrong way around for the ORDEAL [15:47:45] Hmm [15:48:05] Well it should be maneuver to SO65 attitude (which was computed by MCC) and then hold orb rate there [15:48:24] wouldnt the SO65 attitude be computed using that REFSMMAT? [15:49:17] yeah [15:49:28] the DAP orb rate maneuver should work fine in any case [15:50:35] Yeah, with some drift in the ordeal since the orbit isnt circular [15:51:26] I am not 100% sure yet, but I think with that REFSMMAT the ORDEAL would work exactly the wrong way [15:51:40] I am loading up a Pre SO65 scn [15:51:51] interesting, on the actual mission they had some trouble, I think with the optics, and postponed the SPS-6 maneuver by one orbit [15:52:03] they got PADs for both [15:52:22] I recall seeing that when I was doing the last flythrough [15:52:32] Of course I based on the flight plan [15:53:48] Wow the checklist positions are all over the place on the Apollo 9 saves lol [15:55:59] I am asking for a scn file to see whats up [15:56:37] For the last question in that one, I dont think I have ever used RTCC to compute the rendezvous maneuvers, are there procedures for that? [15:59:19] not good ones haha [15:59:24] it gets complicated [15:59:40] they placed the CSI maneuver shortly after AOS of a tracking station [16:01:42] we had mission specific inputs guides for the RTCC MFD for Apollo 7 and 8 in NASSP 7 [16:01:59] I should get some preliminary ones going for 9 to 11 [16:03:32] once you know what CSI and TPI times you want it's not too complicated [16:04:38] but this assumes you are just before CSI [16:04:44] Yeah thats what I thought, he wants to use RTCC instead of the LGC for those because of getting behind, but my initial reaction is you will spend more time on RTCC and get further behind haha [16:04:53] with phasing and insertion maneuvers you need the MPT I think [16:05:13] the MCC doesn't use the MPT, but needs some complicated logic [16:05:44] for Apollo 9 and 10 I have two functions that generate the maneuver times, DMissionRendezvousPlan and FMissionRendezvousPlan [16:06:23] yeah, that probably takes more time [16:06:52] I guess can you prepare the RTCC MFD better in advance than you can with the LGC [16:07:00] Thats what I thought, if you cant do it with the LGC in the allotted time...RTCC wont help at all haha [16:07:48] True, but doing that and flying the LM at the same time (esp on 9 without P20 holding boresight) would take a lot more time [16:08:21] definitely much better to try and stay in the timeline and let the MCC take care of SVs and targeting [16:10:46] Exactly [16:15:26] hey [16:16:00] Morning [16:16:28] Ah he brought up the registers during the cold fire checks [16:17:07] I have the values from Apollo 12's activation checklist in there [16:17:36] We dont have a LM activation checklist for 11 do we? [16:18:19] no, but I have 13 pages from it, pictures from online auctions [16:18:30] Oh could you link me? [16:18:52] that would probably be 13 separate links, it wasn't all one auction [16:19:00] which page do you want? [16:19:19] Oh haha, RCS cold/hot fire if you have it [16:19:38] Looking for the DSKY registers [16:19:44] ah, I think we have that [16:20:15] I guess the LGC on 12 was a bit different :P [16:20:46] I know you explained what causes those differences a while back, mind refreshing my memory? [16:20:49] good morning [16:20:55] one thing that works is googling "Apollo 11" and then the page [16:20:57] like [16:20:59] "ACT-50" [16:21:00] and later [16:21:07] that is where the RCS checkout is [16:21:09] hey Matt [16:22:03] ah sadly I haven't found page 52 [16:23:18] https://i.imgur.com/hqESICh.png [16:23:29] didn't find page 51 on the Internet anymore [16:24:15] https://i.imgur.com/KA9HpIn.jpg [16:24:16] 53 [16:27:40] oh didn't read your question, haha, which differences? The numbers from the ACA? [16:28:42] indy91, random question but, remember the old "7-parameter" function for TLI? [16:29:10] does that still work ie. if someone decides to fly to Venus or something :D [16:30:07] indy91 ACA and TTCA [16:31:23] Looks like specifically TTCA Cold Fire Up which would be on 52 :P [16:32:21] What causes the slight number differences though, isnt that differences in the actual TTCA/ACA hardware? [16:37:59] yeah I think so [16:38:08] there is a certain amount of tolerance [16:38:49] AlexB_88, the RTCC MFD can't handle it anymore right now, because I deleted a bunch of old functions [16:38:55] I want to implement it again some time [16:38:58] the LVDC can still do it [16:39:25] ah right [16:39:32] they didn't actually have this capability on the actual missions, there was a TLI targeting display, but only for Mission E I think [16:39:46] so basically a "TLI" maneuver that goes up to a certain apogee [16:39:57] and that got deleted by Apollo 11 [16:40:09] the mission rules always say that there will be no targeting update [16:40:15] Looks like the only differences are TTCA UP and DOWN [16:40:23] so that's why I didn't focus much on it anymore [16:40:33] makes sense [16:40:50] V11 N10 5E checks, the rest are close [16:45:44] He found a few typos haha, I have corrected and made a PR [17:15:03] Wow those EPS study guides have good detail on the ECA logic [17:15:38] And the RJB [17:16:46] indy91 did you get a chance to look at them by chance? [17:17:13] is that something newly scanned from Mike? [17:17:14] Ohh CSM/LM power transfer diagrams :) [17:17:19] Yep yesterday [17:18:06] very clear logic diagrams [17:18:58] are they on the Virtual AGC page yet? Not seeing them immediately [17:19:20] I don't think so [17:19:31] I can link the drive links\ [17:20:14] I am looking through the 1967 one right now [17:21:23] thanks! [17:21:33] how good can it be if every page says obsolete :P [17:24:23] but yeah, it's pretty good [17:24:57] Yeah I don't think anything really changed in that until Apollo 14 [17:25:23] WRT the ECA and switching logic [18:41:42] Anyone have some clear pictures of the LM overhead window markings? [19:30:14] I'll see what I can find [19:31:41] from what I can see the one in our 2D panel bitmaps looks realistic based on the very few real images I found [19:31:44] AlexB_88 looking for something specific? The OVHD window is also in the LM-8 Systems Handbook [19:32:17] like this one: https://www.bing.com/images/search?view=detailV2&ccid=OJ64uI%2fG&id=3D6744126186A89E726FE078CF8A57685BCD3E75&thid=OIP.OJ64uI_GNWKpjZ_Qq2bshwHaHk&mediaurl=https%3a%2f%2fs3-eu-west-1.amazonaws.com%2flowres-picturecabinet.com%2f43%2fmain%2f8%2f87714.jpg&cdnurl=https%3a%2f%2fth.bing.com%2fth%2fid%2fR.389eb8b88fc63562a98d9fd0ab66ec87%3frik%3ddT7NW2hXis944A%26pid%3dImgRaw%26r%3d0%26sres%3d1%26sresct%3d1%26 [19:32:18] srh%3d799%26srw%3d783&exph=428&expw=419&q=apollo+lunar+module+rendezvous+window&simid=608036463006400950&FORM=IRPRST&ck=15DF7E84710EF22C89DDFB9EC4AB3CEA&selectedIndex=54&qpvt=apollo+lunar+module+rendezvous+window&ajaxhist=0&ajaxserp=0 [19:33:30] right, but I wanted to find some real pics as well [19:33:47] Gotcha, I will see what I can find as well [19:36:02] should have an overhead COAS coming soon to a LM VC near you [19:40:10] Nice! [19:40:16] indy91, wasn't there an ascent procedure using the overhead markings? [19:42:24] I know there were descent attitude checks with it [19:45:54] Ah found it [19:46:10] At least a brief mention in the LM Timeline [19:46:21] "OHW 4 Step" [19:46:34] I am in Apollo 12's [19:47:19] https://www.dropbox.com/s/f7blqnu2z6dbpbh/Screenshot%202022-01-15%20124705.jpg?dl=0 [19:48:02] Looks like it changed to a "7 step" later [19:48:35] https://www.dropbox.com/s/66v8qtt3zdm3p3n/Screenshot%202022-01-15%20124820.jpg?dl=0 [19:48:53] Apollo 15 in that case ^ [19:48:58] ah great [19:49:22] I would love to try that with a properly aligned OHW [19:49:26] 7 simple steps to get into lunar orbit [19:49:35] disclaimer: might require CSM rescue [19:50:25] "MSFN Will Call 2 degree pitch and roll BIAS commands" [19:50:56] won't get that yet in NASSP :D [19:51:50] I wonder if that is in the mission techniques [19:53:37] it is [19:53:48] Have a link? [19:56:57] they change up the technique over the missions, but it's mostly the number of steps I think [19:58:10] Did they use any other than 4 and 7? [19:59:21] I see a 8 step one in an update document [19:59:28] make it went 4 -> 8 -> 7 [19:59:36] Interesting [19:59:58] ok, in terms of ground monitoring [20:00:19] Lunar Descent/Ascent Digitals display [20:00:28] and then a correction in roll based in out-of-plane velocity [20:00:39] we don't have the display, but we know what it looks like [20:02:26] https://cdn.arstechnica.net/wp-content/uploads/2019/06/misc-screen.jpg [20:02:59] based a lot on telemetry [20:03:11] main reason why I haven't implemented it yet in the RTCC MFD [20:10:44] I've tried this before, but didn't know when to cut off [20:10:51] so apolune became too high [20:11:01] RTCC MFD didn't like the orbit for rendezvous calculations [20:11:05] too elliptical [20:11:28] might be better now, but the orbit was quite bad, even for the rescue technique [20:11:45] PGNS and AGS were those the onboard calculations to compare with MSFN? [20:12:25] I tried it with the FDAI, not the OHW [20:12:29] PGNS and AGS state vectors [20:12:44] and then those display numbers calculated in the RTCC [20:14:45] Ah [22:34:47] AlexB_88 did you have any luck with OpenOrbiter? [22:35:16] made it halfway through the loading screen [22:35:32] it fails loading D3D9 [00:44:50] same for me [14:49:13] hey [15:44:16] hey [15:45:07] hey Alex [15:45:11] https://github.com/virtualagc/virtualagc/issues/1154 [15:45:20] you will find this interesting [15:46:27] haha [15:46:39] I do find it interesting [15:47:28] I knew I wasn't crazy :D [15:47:47] well I checked that issue myself and got it, too, of course [15:47:59] I also think I finally figured out how to do the CSM aerodynamics without singularities [15:48:11] so good news all around haha [15:51:58] and Ill make it 3... [15:52:00] https://www.dropbox.com/s/i41p56se2d1wbqm/Screenshot%202022-01-16%2010.45.41.png?dl=0 [16:23:05] morning! [16:23:58] ah looks great [16:24:00] hey Mike [16:24:35] can confirm looks great :D [16:24:39] what's up? [16:25:01] https://github.com/virtualagc/virtualagc/issues/1154 [16:25:18] might be the cause of our FP8 issues with RR data from PGNS to AGS transfer [16:25:31] I saw that and agree with the fix :D [16:25:52] I'm going to do a quick look through aea_engine as soon as I'm done with this scan to make sure that the same bug isn't anywhere else [16:26:20] great, and then I'll fix it in NASSP [16:27:48] excellent [16:27:55] also, this new scanner is the best thing ever [16:30:50] good speed, good quality? [16:31:40] good speed, good quality, ability to scan 12" by 18 foot double-sided foldouts at 300 DPI in a single scan [16:32:38] wow [16:34:07] so I'm finally no longer afraid of a number of documents I had sitting in my collection lol [16:36:58] haha, that's why it took so long, you were afraid of your acquisitions! [16:37:37] yeah [16:37:54] now a document that would have taken me 6-8 hours to scan and process will be done in 30 minutes or less :D [16:41:22] that is an impressive improvement [16:47:05] when in the overhead window view, you need to use FOV of 80 to see the whole scale (up to 40) [16:51:22] https://www.dropbox.com/s/mfcj6r38xd9qw4k/Screenshot%202022-01-16%2011.50.44.png?dl=0 [16:51:39] that is viewing it at FOV 80 [16:59:14] happy manual ascents [16:59:35] tested a couple last night [16:59:50] let me guess, you got an orbit, emphasis on AN [17:00:10] Hey people [17:00:19] it worked but as you said, probably require a CSM rescue [17:00:21] when do you cut off? [17:00:25] hey Thymo [17:00:33] I used PAMFD to judge the cutoff [17:01:17] hey Thymo [17:01:49] I kept the exact attitude profile the whole ascent though, just using PAMFD to monitor the ApA/PeA [17:02:16] Wiki is now available over HTTPS, so you can make an account without sending your password in the clear :) [17:02:17] https://nassp.space/index.php/Main_Page [17:02:29] ended up in a 60 x -20 NM [17:02:44] so needed a burn at apogee [17:02:50] Still need to figure out email for the account confirmations, I might need to setup a mailserver for that. [17:03:27] oh nice. So this is the old wiki ported over to a new page? [17:04:15] Yep. [17:04:28] I imported everything from Matt's git repo. [17:04:47] Although by now I also have full access to the old wiki. [17:05:10] but nobody could create new accounts in the old wiki, right? [17:05:27] Yeah, I think because email was broken? I'm not sure. [17:05:33] yeah [17:05:40] dseagrav had approved my account somehow [17:05:49] but I believe even that wasn't working anymore in the end [17:05:53] You should be able to create an account on this one though, you just won't get anything in your inbox yet. [17:06:35] The old wiki was also running ancient versions of mediawiki and PHP. Not really secure anymore [17:08:13] right [17:08:38] we are getting things done today :D [17:11:25] hell yeah \o/ [17:22:26] IRC logs are now here: https://nassp.space/irclogs/ [17:40:49] good afternoon! [17:41:25] lots of great stuff happening by the looks of it [17:50:34] hey [17:50:52] indy91, Thymo, PR sent for the overhead window [17:51:32] the overhead window is accessed up the CDR position [18:30:41] that's going to improve the docking experience greatly [19:01:29] testing the AEA fix now [19:05:30] got almost 10 marks reported by 621 [19:06:32] and it bang on agrees with V83 and the tapemeter [19:20:32] Mike just shared that with me this morning [19:20:39] Its working?? [19:22:00] it is for me [19:22:02] very well [19:22:38] even constant V47's didnt keep the AGS this close to the raw data from the RR [19:23:07] at least for me [19:23:14] Thats fantastic [19:23:36] Running FP6 or 8 right now [19:23:56] I think it only works on 8 [19:24:06] so Apollo 15+ [19:26:00] well, we use FP8 on Apollo 13/14, but I dont think Luminary178 and 131 can send RR marks to the AGS [19:32:49] No but you can manually type in range and range rate in FP6 [19:32:53] And that wasnt working [19:33:11] You make a "mark" typing those in [19:34:33] was the manual marking not working before either? [19:35:17] I dont think it was [19:35:18] what I just tested was the AGS auto SV update and that is working very well [19:35:40] I haven't tested the manual marks with the fix yet [19:35:42] Either wasnt working or it worked poorly [19:35:48] right [19:38:42] I think there is a good chance this fixed both [19:39:14] Yeah it sounds like it! [19:39:22] I will be able to play with it tomorrow [19:39:30] Can you give FP6 a shot? [19:40:15] you mean test the manual RR marks? [19:40:38] yeah [19:41:06] its more of a PITA but I am curious what results we get [19:43:25] I don't have much experience with them haha... there could still be errors but those would be "user-created" more then an issue with the AGS :D [19:43:35] Yeah haha that is true [19:43:52] I think initializing the radar filter previously caused problems [19:44:03] I will see tonight if I have time and report back [19:44:08] Sounds good [19:44:17] In Apollo 12's G&N its AGS-25 [19:44:48] I used to try them and it just FUBARed my AGS SV :P [19:45:19] I also remember that even just doing constant V47's to keep the AGS updated, still had issues [19:45:36] like for the smaller burns post TPI [19:45:41] the MCC's [19:46:06] Curious if this helps in general [19:46:09] the solutions the AGS gave looked pretty random and not in agreement with PGNS [19:46:33] I had good AGS results with MCC's last time I tried an AGS rendezvous [19:46:42] I also did a V47 after each PGNS burn haha [19:47:53] and the burns were calculated by AGS? [19:48:31] I mean you burned the AGS solution and not the PGNS one [19:48:58] Yes haha [19:49:02] right [19:49:23] But I had PGNS running P47 [19:49:29] So I could keep a good SV [19:50:12] But come to think of it last time I did a full AGS rendezvous (shut down the LGC) I got back in one piece [19:51:11] then you have no choice but manual marks :D [19:54:00] I remember manual marks working, but it's quite difficult to do. I definitely screwed it up once or twice. But it could still be the case that this bug was causing issues with it. Not that I know how [19:55:16] or how it even fixes the auto updates :D [20:06:23] Email on the wiki works. [20:15:11] indy91 yeah I could make marks but the SV deviation seemed very high (again could have been user error) [20:15:42] In the AGS only one I did I didnt update at all and just used the AGS SV from launch haha still got back to the CSM [20:17:12] I need to implement some ASA biases to put a stop to that :D [20:17:48] I remember that I made marks that helped the SV converge, but other times it got screwed up. User error or bug, no idea [20:20:18] Yeah I never had good luck even though I "seemed" to be following the procedure well [20:20:27] null RR errors and enter [20:23:02] indy91, yeah thats what I observed to when I would take marks before [20:23:16] a few marks would seem to make it get better and give you hope [20:23:34] but then a few more nope! downhill it went [20:24:00] makes me wonder if it was a function of that accumulator [20:24:09] some working some not etc [20:24:59] https://github.com/virtualagc/virtualagc/issues/1154 [20:25:06] "this happens for small negative values" [20:26:11] It sounds like it would have been the small SV errors that would have caused the worst issues if I read this correctly [20:28:37] yeah you're reading it right [20:28:58] and it does look like this class of bug doesn't exist anywhere else in aea_engine [20:34:22] glad to know it wasn't widespread [20:36:19] AlexB_89, so how does the LM COAS work now [20:36:28] you click on it to move it over to the other location [20:36:32] between the two windows? [20:37:38] if you click on one location to show it, the other will disappear [20:37:45] ah ok [20:37:53] so you click where you want it [20:37:56] since there was only one COAS on board I think [20:38:00] yeah [20:38:02] exactly [20:38:13] of all the things to have a spare, the COAS seems unnecessary :D [20:38:28] unless it floats away on an EVA in space [20:41:26] in a previous commit, I had wrongly made the LM create without the forward COAS installed [20:41:33] so I reverted that [20:44:47] Speaking of COAS was there ever a mission where they installed the CM COAS in the RH window? I know it had the mount for it [20:44:58] And power etc [20:52:50] no idea, but in the right window it would be used by a different crewman than the one controlling the CSM [20:53:55] Yeah and of course it would not be useful for say the LM docking target] [20:58:58] maybe if the left window is fogged up or damaged somehow [21:00:04] thats what I was thinking for redundancy [21:00:28] Wonder if there was any contengency to dock with the window messed up [21:00:34] TD&E [21:02:06] thewonderidiot, ok, I am implementing that AEA fix then. [21:02:10] and not anywhere else [21:02:29] :D [21:08:55] Question is, should I add back all the radar checklist steps? [21:09:23] Taking RR marks etc, without an LMP it might bog down time for people even more [21:10:22] I think don't add it back [21:11:44] did Buzz take marks IRL... or did they rely on just the V47's? [21:17:12] "During the coelliptic phase, radar tracking data were inserted into [21:17:13] the abort guidance system to obtain an independent intercept guidance [21:17:14] solution. " [21:18:07] ok [21:19:13] I guess the auto updates of 15+ made that portion of the flight much easier [21:20:00] yes, but of course they mostly relied onn V47 and the manual updates were just for practice [21:20:24] kind of like using P23 at all [21:20:25] right [21:25:17] Thymo, I think the MFD change you proposed is good all around [21:25:44] Checklist MFD* [21:37:35] night! [23:17:01] I have virtually no idea what I was working on last.... [23:21:56] hahaha [00:09:24] my specific heat branch is in dire need of being finished. should probably do that [00:14:42] it also looks like im about 12 minutes from staging on my apollo 10 run. perfect. I can finish it as a final test. [00:19:18] n7275, how's the lunar gravity project coming along? [00:20:51] I have a branch for it https://github.com/n7275/orbiter/tree/tesseralGravity [00:21:35] Do it :) [00:22:16] I tested my functions outside orbiter, and both my gravity model loading function, and my perturbation function do what they're suposted to [00:23:23] for some reason, orbiter won't load the gravity model though. its very strange. it acts mike my code isn't even there. I was hoping at least for a crash [00:26:30] odd [00:54:20] Let me know how the specific heat works out I tried it a bit before making my ECS branch with no obvious ill effects [00:58:12] AlexB_88 did you test the AGS in general after the change to make sure there were no issues elsewhere? [16:04:56] good morning [16:25:47] hey [17:06:13] hey [17:09:34] morning! [17:09:53] hello [17:09:56] hey guys [17:39:42] new CSM aerodynamics testing is going well so far [17:40:07] seems better than before. And I found one typo [17:40:20] made the moment coefficients too strong [17:40:47] reference diameter is 154 inches not 254 [17:40:56] so it was too strong by the factor 254/154 [17:41:47] ah nice [17:41:59] the general behavior still seems a bit weird too me, but it's not an aircraft [17:42:10] so it's not going to be too great [17:42:25] did you need to use AddForce after all? [17:42:33] nope [17:42:40] figured it out with the airfoils [17:42:44] nice [17:43:59] so, of course it depends on the CG, but the general behavior is, at 0° angle of attack it is not stable [17:44:39] but it is at 10° [17:44:48] it would be stable if the CG was even further forward [17:46:29] and then when you enter the atmosphere the stable point even shifts to 30° [17:46:44] I tried that, it becomes fairly stable at 30° when it reenters [17:46:58] and the singularities are definitely gone [17:48:26] I can't say it's too intuitive how it behaves [17:48:52] but the maths agrees with the NAA simulator [17:49:56] as said in the mission report, the CSM likes to get back in-plane when it was a bit out of plane [17:50:04] but [17:50:13] let's say you are out-of-plane at perigee [17:50:30] CSM starts rotating towards in-plane [17:50:35] slow process [17:50:49] you get to apogee, less density [17:51:17] it moves past 0° yaw [17:51:30] and the less dense atmosphere doesn't stop it as much [17:52:01] so if you are unlucky it can swing you into gimbal lock on the other side [17:52:08] right [17:52:37] over the course of 2-3 orbits or so, have to test it again, as I said, the effect was a bit strong [17:52:40] I guess making sure our orbit doesn't decay is more important as well? [17:53:40] yeah drag is realistic, seems a bit strong at times, but the numbers work out [17:54:16] the opposite can happen too, it randomly stops at 10° angle of attack and is then fairly stable there [17:56:26] and I implemented lift now, too, although it's not very significant [17:56:32] but that had the singularity, too [18:05:25] so there is a bit of a risk of drifting into gimbal lock by accident, but it's not too bad [18:05:32] it would take a while in any case [18:06:28] and if you were in-plane with a small attitude rates it won't happen at all I think [18:07:57] but I'll test a bit more [18:13:37] I did this in my branch where I also work on Apollo 7, but I'll implement these changes for the Orbiter2016 branch, too, with reduced drag as it is right now [18:14:34] Orbiter2016 has reduced drag right now, but too strong moments (due to the typo) and with singularities [18:20:59] Good evening [18:21:21] hey Thymo. [18:21:37] indy91 that sounds like great news [18:35:36] even with your old drag moment model it took me about 18 hours to drift into gimbal lock uncontrolled when I tested it [18:36:21] where it might cause an issue is if you were aligned out of plane. but that's realistic. [18:48:36] yeah on Apollo 9 it really didn't want to stay in the attitude for the docked DPS burn [18:49:11] I mean, I doubt it's going to be any significant RCS activity caused by it, but over a longer period of time it wanted away from that [20:40:51] I got so distracted by the new normal maps last night that I missed my staging, lol [20:53:01] haha [21:08:32] better no staging than tumbling staging [21:30:02] I took the old wiki down. If you go to nassp.sf.net it will now redirect you to nassp.space. [21:30:40] Over time it will also start to start showing up in the goold results instead of the other [21:50:41] that's great [21:51:06] the new wiki still some issues, right? It doesn't seem to show pictures [21:52:06] I see 13 missing files. Those were probably missing on the old one too. [21:52:48] There are still some minor issues, like broken templates. They contain some things that are no longer supported or work differently nowadays. [21:53:19] ah makes sense, different wiki software [21:53:31] I want to make a new thread calling for people to start writing stuff, because we all know how much time we spend on the wiki ourselves. [21:53:46] Same software but about 10 years newer :P [21:56:18] haha [21:56:24] yeah, now people can actually write stuff [22:04:53] night! [16:02:56] morning [16:47:41] hey guys [16:51:48] hey [16:52:30] found the bug that screws up the RR shaft animation [16:53:38] oh nice. [16:57:41] indy91, I also found something suspicious with AGS burns, the engine on signal from the AGS seems stuck to always on in my Apollo 11 scenario [16:58:50] for example, I ran the External DV checklist for the AGS and when you get to Abort(stage) - push then engine fires right away [16:59:33] it should not fire right away, but only when it senses an ullage signal isn't it? [17:04:01] hey [17:04:29] could that be caused by the bugfix? [17:04:43] or maybe the ullage counter is set to 0 for some reason [17:04:49] whats your ullage counter set to [17:05:26] 616 [17:05:59] its 0 [17:06:16] I remember something about this [17:06:21] theres your problem lol [17:06:46] haha [17:06:56] i think its 1 on the counter for ever 2 seconds? [17:07:08] padload is 4 [17:07:11] so 616+00003 would be 6 seconds ullage [17:07:18] this shows the extent of my AGs experience :D [17:07:20] I believe we had trouble with this before [17:07:26] Yeah I think I ran into it [17:07:34] something changing it [17:07:53] there used to be a saving/loading bug [17:08:00] but it would be the other way around [17:08:27] the flight program gets loaded, which already has some non-zero values [17:08:47] and then any number you had set to 0 wasn't getting saved in the scenario, to save space [17:09:04] ah yeah I remember that [17:09:08] Didnt that get addressed? [17:09:17] so that didn't overwrite the flight program values back [17:09:20] yes, long fixed [17:09:43] and it would be the other way around, being set on purpose to 0, saving/loading, back to 4 (or 3 or whatever) [17:09:48] AlexB_88 are you using one of the save states or your own from prelaunch? [17:10:14] doesn't it get set to 0 for descent on purpose? [17:10:16] for abort [17:10:24] that's how we discovered the bug [17:10:25] yes [17:10:32] because it didn't fire immediately [17:11:10] yeah its set procedurally shortly after undock [17:11:27] my own [17:12:21] there is 616+7 not long after insertion [17:12:27] for CSI I guess [17:12:37] well this is a post undock scenario [17:12:38] well [17:12:46] any possible APS burn [17:12:54] so I guess I had done the 616+0 [17:13:16] yeah, it's in the procedures [17:13:24] between undocking and sep [17:16:33] it is 1 decimal =2 seconds of ullage right? [17:16:40] I think so [17:16:41] so 616+00007 would be 21 sec [17:16:54] 7*2 = 14 [17:17:00] yes [17:17:09] I can do math [17:17:11] :P [17:17:26] I don't know what setting it shortly after undocking to 0 meas for DOI [17:17:37] would they ever do that burn with the AGS [17:17:42] I doubt it [17:17:45] yeah [17:18:00] Without looking at the rules I would bet PGNS go is a DOI condition [17:21:52] yeah, definitely [17:23:18] yeah PGNS required [17:33:14] so you would just have to set the ullage counter again [17:33:22] e.g. if you do No PDI + 12 with the AGS [17:37:21] I just wanted to add that I noticed this behavior too: Again with the ullage counter at 0, pressing the Abort button starts the engine at 10 %, then if I depress the abort button, the thrust level jumps up to 20% before going to 0, like a kind of transient [17:38:06] that's weird [17:38:10] I've seen this weird transient on various occasions before too like the thrust jumps up a bit before going to 0 [17:38:35] it only seems to do it with the abort buttons [17:38:55] hmm, that sounds like a bug in the control electronics [17:40:51] morning! [17:40:58] hey mike [17:41:15] speaking of control electronics -- all 10 of the LM study guides I scanned recently are up on the virtualagc website this morning [17:41:20] including the CES / AGS one ;) [17:42:42] yay! [17:43:03] https://www.dropbox.com/s/y16h76w614qmpw4/Apollo%2011%20MCC%20-%20AGS%20test.scn?dl=0 [17:43:12] I havent looked at the CES/AGS yet, still digesting the EPS :) [17:43:31] indy91, in that one you can see the issue, just cycle the abort button [17:43:36] Alex are you using keyboard or any joystick inputs [17:44:13] that's a lot of guides :D [17:44:37] oh it actually wants to go to full throttle before the cutoff signal is sent [17:44:42] that is very strange [17:47:09] rcflyinghokie, no unusual inputs [17:49:04] huh interesting [17:49:07] same behavior here [17:50:24] so part of it is probably that there is a set of valves that is fully open if the DPS engine is NOT armed [17:50:45] they prefered to fail those to 100% thrust instead of 10% [17:51:17] so they fail to 100 before the cutoff signal? [17:51:29] so this has to be a case where the engine is not armed anymore, but there is still a engine on signal [17:51:43] for a split second [17:51:54] engine dearmed with the abort button being depressed [17:52:13] and only a split second later does the AEA not send the engine on signal anymore [17:52:36] but surely this condition should be prevented in the control electronics somehow [17:53:46] ooooh [17:53:55] I found a note in the AOH [17:54:11] talking about the ENG ARM switch, but it should be the same [17:55:06] "ENG THR CONT: ENG ARM sw - OFF removes arming signal to throttle actuator, causing throttle to move to fully open position. To avoid possible transient thrust surge, pause 3 seconds after pushing ENG STOP pb. This ensures all engine valves have time to close" [17:55:43] so this is probably correct behavior. If you want the engine to stop, push the engine stop button [17:57:04] if I had a dollar for every time we find a NASSP bug but its in fact a realistic effect of the depth of simulation :D [17:57:49] I think I read that passage before. But I would have known this immediately if that is why I implemented it. [17:58:04] I think you can pull some circuit breaker and cause the condition like a valve failure [17:58:11] so that it's always at 100% thrust [17:58:21] that's what I wanted to implement [17:58:50] oh right, full DECA failure [17:59:02] with the descent engine command override switch you can then still fire the DPS [17:59:03] Nice find! [17:59:07] but not throttling or gimalling [17:59:51] oh and of course, imagine hovering over the surface during descent [17:59:54] and then the DECA fails [18:00:04] and you are stuck at 10% or maybe even 0% [18:00:10] better have the valves fail open [18:00:49] haha that would be an interesting surprise [18:00:55] yeah, if you do a normal descent and then pull the DECA circuit breakers, descent engine command override will keep the DPS firing [18:00:56] at 100% [18:02:37] ah yes I have seen that before, like that one time at P64 I started pulling breakers randomly 1 by 1 until something bad happened just for my amusement [18:02:52] all of a sudden full thrust [18:25:41] 616+7000 [18:25:53] 616+70000* [18:26:07] and I was wondering why it takes so long for the engine to start [18:26:39] that will take a 140000 second ullage :D [18:27:35] 616+00007, tahts more like it [18:28:33] that's a bit much haha [18:30:25] Lol [18:30:38] Ah Nik mistakenly said 616+7 [18:31:10] Thats a long ullage ;) [18:31:15] ah yes, haha [18:37:14] almost 38 hours [18:37:21] *39 [18:38:09] Thats a lot of propellant [19:05:26] Another observation: [19:11:32] Before powering up the AEA for the 1st time, it seems if you have DPS and ATCA powered with GUID CONT - AGS, the engine will fire with the abort stage button [19:12:05] but when you psuh in the AEA CB and turn on AGS the engine does not fir any more with the abort stage button [19:12:11] fire* [19:19:27] interesting [19:20:29] infact simply just arming the engine [19:21:41] so just guidance control AGS then arming the engine seems to fire it [19:21:50] I think I've seen this a long time ago and didn't know what to do to replicate it [19:21:53] before AEA 1st power on [19:22:14] it's probably the output channel of the AEA being all 0 [19:22:23] it's inverted logic [19:22:36] right [19:22:39] so if that is 0 then it will set engine on [19:22:57] but engine off will be 0, too [19:23:08] I feel like that shouldn't start the engine then [19:23:49] if the signal is ambiguous, engine on and engine off signals the same then it should keep the current condition [19:23:54] so either keep firing or keep it off [19:24:09] now this could be a control electronics bug :D [19:25:21] so to replicate it you need DPS powered ENG ARM cb in, ATCA AGS CB in, then cycle GUID CONT to AGS and then arm the descent engine [19:27:57] and all before AEA 1st power on, here is a scn: https://www.dropbox.com/s/szg4hkkrtgox1c3/Apollo%2011%20-%20AGS%20test%202.scn?dl=0 [19:30:16] and then once AEA is powered up the behavior stops, and even shutting the AGS back off/pulling the AEA CB, the behavior does not re-occur [19:31:06] yeah, once the AEA software starts up it sets the right bits to keep the engine off [19:37:53] having AGS mode control not in auto causes the engine off signal to not come through [19:38:06] so as far as the DECA is concerned it's a valid engine on signal [19:38:19] that must be wrong, in at least one place in our code [19:42:21] So I was planning to announce the new wiki and open the flood gates to new users. Turns out the spambots were one step ahead of me while I was sleeping last night. [19:42:33] oh no [19:42:34] haha [19:42:37] Yeah :P [19:42:47] did they manage to do anything? [19:43:24] Just a couple of spam users and pages. I disabled user edits and account creation until I get some proper captchas and forced email verification sorted. [19:43:35] cool cool [19:43:40] But man mediawiki is not really secure out of the box [19:43:44] I haven't registered yet so let me know when you have something for me to test [19:45:00] Yeah will do. I need to find out what is the defacto antispam measure for wikis nowadays though. According to the documentation a recaptcha where you click images is not that secure apparrently. [19:45:35] Oh well. Rather have them breakthrough now that it can be easily rolled back than when a bunch of people are working on stuff. [19:46:07] It's also a reminder that I should really set up proper backups for this thing. [19:55:25] AlexB_88, AEA test failure and engine on and off signals all need AEA power [19:55:48] so no matter what the state of the output register is, it wouldn't be send as an engine on signal to the control electronics [19:56:15] I already have a function in the AEA code for the test mode failure for this, I'll just make engine on and off the same [20:03:45] This reminds me, we still dont get any alarms when the AGS is brought back up after it was powered down on the surface [20:12:02] indy91, so it wasn't an engine on signal before AEA power-on? [20:13:00] ah I said that in a confusing way. That signal from the AEA should require power, but it doesn't right now [20:13:16] test mode failure does already, so I'll make engine on and off signals work the same way [20:13:43] gotcha [20:13:44] right now it directly checks the state of the AEA output discrete [20:13:50] which is just 0 because it hasn't been turned on [20:13:56] and that signal gets inverted [20:14:05] makes sense [20:15:27] also, I was thinking of adding audible feedback when an explosive device is fired, what do you guys think? [20:15:43] could be just a pop or something [20:16:11] don't know if it was audible in real life though [20:16:19] like the staging sound? [20:16:59] hmm maybe [20:17:03] dont we have a staging sound already? [20:17:07] maybe the staging sound is a bit much though [20:17:19] but yeah could be a candidate [20:17:53] rcflyinghokie, I mean for the explosives in general, like DPS/RCS DES PROP ISO VALVE etc [20:17:58] Hmm I need to look into the tech debriefings but I dont recall any mentions of those sounds in general [20:18:05] Yeah I am following now haha [20:18:27] right [20:18:35] But some sort of audible pop would be a nice feedback option [20:22:10] I believe landing gear extension made an audible sound in the LM though [20:28:26] Looks like some could hear the parker valves cycle though haha [20:29:43] CONRAD "Deployment of the landing gear left no doubt in our minds that [20:29:44] the pyros fired" [20:30:19] Not sure if that was visibility or sound, but 15 reported a shutter when they fired [20:33:26] PR is up [20:34:22] I also checked if the whole auto engine on/off logic was correct, because it's a bit different than the systems handbook [20:34:46] but it's just like in the Grumman schematics, sooo, I think Grumman schematics > Systems Handbook :D [20:35:08] yeah for sure [20:35:28] it's just slightly scary because our relays switch on each timestep [20:36:13] and the relay that can keep the DPS engine on, if the control inputs are ambiguous, switches just before the control logic [20:36:21] but with the right order of things it works like intended [20:36:52] in reality a spurious signal would probably not be enough to energize the relay [20:43:55] yeah, usually you need 100ms or so [20:51:01] indy91: Is your comment "The check on the bits in the output register could be accomplished with less code" an observation or a question? [20:51:17] observation [20:51:23] feel free to make it better [20:51:47] that conversion to the bitset and only then checking on the bit is inefficient [20:56:02] Oh and btw. You can create branches in the NASSP repo. You don't have to specfically create a PR from a fork if you didn't know. [20:57:44] right [20:58:02] would probably be good for a branch that multiple people are working on [20:58:31] And it saves me 7 keystrokes. `git fetch` or `git fetch indy91`. :P [20:58:46] haha [21:26:58] we have a few AGC branches. ate there still plans for those? [21:27:31] *are [21:27:51] Plans? Yes! Time? If only. [21:28:36] It's part of this issue https://github.com/orbiternassp/NASSP/issues/551 [21:51:36] night! [21:58:40] Should we add the landing site texture link to the installation guide? [21:58:42] http://absimp.org/orbitersim/apollolandingsites.html [22:06:47] I think so. [22:08:14] Alex and I talked about it, I thought he was going to add it haha [22:08:29] I didnt want to edit his post [22:08:37] we agreed at one point that we didnt want to incorporate those into NASSP. but the more of them he releases the less I think they should be seperate. maybe we should think about including them again. [22:08:44] I'd add it as optional though. [22:09:00] or not... [22:09:22] Think of the people with prehistoric internet that just want to get into it. [22:09:29] High res textures aren't a requirement either [22:09:43] fair enough. [22:09:46] Yeah thats why I think just the link for now [22:10:23] But if they were incorporated (and AlexB_88 you can correct me if I am wrong) things like touchdown points and such could be better defined for that terrain instead of based on orbiters base install/textures [22:11:22] I think that's Orbiters fault actually [22:12:01] theres a precision difference from visual terrain and physical terrain [22:12:22] float/double issue or one LOD tree level or something [22:15:43] float vs INT16 with cubic interpolation [22:15:46] Post in thread 'Apollo Landing Site Sceneries for Orbiter 2016' https://www.orbiter-forum.com/threads/apollo-landing-site-sceneries-for-orbiter-2016.38022/post-565386 [22:16:26] yeah there is a bit of a visual difference between the graphics and the physical terrain, so the LM seems to sink sometimes [22:17:07] so I think it should be optional, but I will add it to the installation as a recommended download [22:17:38] maybe once those Orbiter issues are fixed we can think about talking with ggalfi about incorporating it into NASSP [22:21:36] yeah that sounds perfect [22:21:47] I think its a great optional link to include [22:21:54] One other thing you need to consider is that people that use his terrains don't neccesarily use NASSP. [22:22:20] So if you merge them he either needs to maintain two instances or people have to install NASSP if they want to use it. [22:22:53] yeah. good point. [22:26:02] very true [22:26:08] right, I guess the merging option wont be for a while anyway [22:26:17] Yeah optional is more than sufficient [22:26:33] Alex what causes that jittering on the surface [22:26:51] Like I will see my rate needles vibrating very fast [22:27:14] the rate is infinitesimally small but you can see its bouncing between 2 points rapidly [22:29:40] it should settle after a few seconds with no thruster activity [22:30:35] the reason it jitters is because Orbiter still thinks your in an airborne state [22:31:16] like if you were to save while its jittering, the quicksave says your vessel is orbiting the moon [22:31:26] Ahh interesting [22:31:49] its really a question of fine-tuning the touchdown points to make that transition quicker [22:34:15] What do those depend on [22:38:30] it should settle after a few seconds though, does it not for you? [22:42:54] Not usually, no [22:43:12] Sometimes it does but sometimes its continuous [22:44:59] if its steep enough it could be continuous in my experience [22:45:34] there difinetly is room for improvement with the touchdown points, they are quite a challenge to get right [22:45:43] Oh I bet! [22:45:51] Do textures play any part [22:45:59] Or is it strictly orbiter [22:46:08] the terrain might [22:46:52] the .elv files I mean [22:47:13] that come with ggalfi's landing site [22:47:30] since they have more definition [22:47:43] but I am not entirely sure how it all factors in though [22:48:25] yeah I noticed it more using those [22:48:33] could be a factor [22:48:47] Nothing breaking, things still worked properly but it always caught my eye haha [22:49:49] but with the normal Apollo 11 landing site with default Orbiter terrain, it should settle fater a few seconds at most [22:55:14] Ah ok [23:09:51] Added the link to the install guide [23:09:59] Awesome [23:19:02] Ah good disclaimer in there :) [23:22:54] Thymo, maybe the installation guide should be migrated to the wiki at some point [23:26:34] speaking of which... has anybody ever tried to make a dedicated NASSP installer? [23:26:44] something that goes through all of the steps currently necessary automatically [23:27:36] AlexB_88: Yep, the old one is still on there. Good idea to move the new one there. [23:28:26] thewonderidiot: No, mostly because NASSP is one of the few addons for Orbiter shipping under GPL. We wouldn't be able to distribute most other things. [23:28:54] I'm not envisioning distributing anything with the installer [23:28:57] There has been some discussion about a CKAN kind of thing for Orbiter this summer though. Let me find it. [23:29:03] it'd basically be a script that automatically does the downloads [23:29:10] what if it just downloads them [23:29:16] beat me to it haha [23:35:26] Some discussion here https://www.orbiter-forum.com/threads/orbiter-is-now-open-source.40023/page-4#post-584858 and here https://www.orbiter-forum.com/threads/orbiter-2016-mods-on-the-interplanetary-file-system.35066/#post-536848 [23:38:27] I started a draft document back then to define some ideas but it never really got off the ground. Maybe some day. [23:40:28] it would be awesome [23:40:43] although I am much less interested personally in solving the problem generally than just for NASSP specifically :P [23:45:40] Why do you think I never finished my idea? :P [23:45:52] So many edge cases [00:13:10] yep [03:33:17] PR sent which fixes the RR shaft animation issue [04:05:50] Just coming back, good find! That was bugging me for sure! [04:06:13] Now if only the mysterious disappearing SM bay could be tracked down [04:06:52] Still catches me sometimes https://www.dropbox.com/s/1nlwl81tr6j3ryx/Screenshot%202021-10-15%20143641.jpg?dl=0 [04:08:50] huh? I thought hat was fixed already [04:09:24] I guess not lol [04:10:54] Well the screenshot was from october, I dont remember a fix for it but I could have missed it [04:11:56] https://github.com/orbiternassp/NASSP/commit/28acef9f1233bb3dce23cc30765f696371dca333 [04:12:12] thats what I thought fixed this [04:12:53] it definitely fixed the CTD when opening the CM forward hatch [04:13:52] so the SM panel thing must be entirely separate [04:14:13] its funny but I have never seen it occur on my PC [04:16:59] Hmm interesting [04:17:05] Yeah i get it time to time usually on a load [04:17:32] And that pic as I said was from October, so well after that PR, but I saw it once or twice since then as well [12:58:26] .tell AlexB_88 this may be of interest http://orbiter.dansteph.com/forum/index.php?topic=14697.msg224706#new [15:15:47] hey [15:17:24] rcflyinghokie, sorry, I haven't followed that Apollo 15 RTCC thread all that much. What is it that you all need the MPT for when flying Apollo 15 descent/ascent/rendezvous? Because I want to remove that as much as possible, MPT shouldn't be required for normal missions, not if it can be somehow avoided. [15:18:58] I think the only true required case is getting the post insertion time tagged state vectors [15:19:43] Also if you want to get ahead computing the LM ascent before CSM plane change, I use it there as well [15:19:47] But that isnt necessary [15:20:12] Oh and the insertion time for the tweak burn's calculation [15:20:43] huh, does the ascent processor page not show that [15:20:54] I dont believe it does [15:21:06] Checking now to be sure [15:21:21] it shows the insertion state vector [15:21:22] and its GMT [15:23:49] for concentric the lunar rendezvous plan table of the LLWP shows a GETINS [15:24:23] is the GMT within those state vector values on the ascent processor page? [15:25:17] yeah, position vector, velocity vector, GMT [15:25:25] but GMT isn't too helpful [15:25:29] Not user friendly to get a GET [15:25:32] Yeah [15:25:49] Also the LLTP doesnt show a GETINS [15:25:53] yeah [15:25:59] which is weird, that is the real display [15:26:46] Where even is the insertion time when you use the MPT haha [15:26:49] DMT? [15:27:08] not even the MPT display has the ascent cutoff time... [15:27:15] Checkout monitor I believe [15:27:20] ah right, with MVE [15:27:22] yeah [15:27:46] And of course you need MPT set up with the ascent for that [15:28:57] well they do that in my notes from the Apollo 11 FIDO loop [15:29:09] 96:44:30: Checkout Monitor, ascent cutoff vector, MCI (no, MCT) [15:29:23] Lines up with what I have been doing [15:29:45] but I can implement a GET display for the ascent processor [15:29:56] RTCC didn't have that anyway [15:30:00] What about a post insertion SV [15:30:29] well the same page shows that SV already, maybe it can be transferred for uplink [15:30:40] although it's exactly at insertion [15:30:43] not time tagged [15:30:51] hey [15:31:15] Looks like in 15's example the CSM got a LM SV for INS+18 [15:31:34] time tagged SV requiring a maneuver between "now" and "then"... that is the whole reason why I implemented the MPT, that old system to get e.g. a REFSMMAT for lunar orbit before even MCC-4 was terrible [15:31:57] Which is why the MPT works well for it haha [15:32:15] hey Alex [15:32:26] yeah it works well once you have figured out what to do [15:32:35] Sice note, other MPT cases are extremely useful for determining scrubbed MCCs both TLMCC and TEMCC [15:32:40] Side* [15:32:58] nice texture [15:33:09] No other work around for that I am aware of..but of course its not "crucial" to flying a mission [15:33:21] Just flying it "accurately" [15:33:43] well need one without the red bands too for the LM [15:34:00] hey [15:34:22] for that state vector, it seems to be insertion plus 18 minutes for all missions [15:34:26] hey Matt [15:34:55] so maybe I could have that page "export" a SV at that time [15:36:04] just an additional button, routing it to CMC LM state vector uplink [15:36:50] hmm was it 18 for all? [15:37:04] I could be way off but I seem to remember some different ones as well [15:37:09] I'm using 18 for the Apollo 11 MCC uplink [15:37:16] but maybe other missions had something else [15:37:37] in doubt that button gets an input box where you can enter the number [15:37:49] 17 was +5 [15:38:02] that would be good [15:38:38] indy91, my PR fixes the RR shaft animation [15:38:44] ah Apollo 17, always doing something weird [15:38:50] 16 also +5 [15:38:51] AlexB_88, I'll take a look [15:40:14] And 12 for example used a CSM INS+18 [15:40:20] Instead of LO [15:40:23] AlexB_88, what do you think a reasonable upper limit is for VC texture resolution is? [15:40:53] as I recall it had very little effect on framerates [15:41:05] hmm good question, I think some of them are 4K [15:41:30] rcflyinghokie, hmm? what do you mean with liftoff [15:41:40] is it liftoff + 18 in some cases? [15:42:05] No I mean the CSM SV was time tagged for liftoff time [15:42:10] oh ok [15:42:17] but that doesn't have anything to do with the ascent processor [15:42:22] No [15:42:26] you can time tag anything you want on the uplink page [15:42:31] Just an interesting observation on the differences [15:42:34] right [15:43:02] Yeah the CSM since its not changing after the PC, time tagging it's SV is already doable [15:43:09] Just the pesky LM insertion :P [15:44:02] With those changes, along with others, might have to go back and edit the RTCC QRM [15:44:17] Perhaps a variant not using MPT for simplicity [15:45:07] yeah. At one point I want to have the MPT running at all times, mostly automatically [15:45:13] But it's not that time yet :D [15:45:23] Haha that would be nice indeed [15:46:04] Trying to think are there any other necessary MPT cases [15:46:17] I feel I am forgetting something but it's not coming to me [15:46:32] that tweak procedure is also not very nice [15:46:47] well, the realistic method would require the same sort of setup [15:46:49] That seems like it could be automated/preloaded [15:46:58] but they had a dynamic display for it [15:47:06] All the other values are present elsewhere [15:47:12] and didn't have to use the normal rendezvous calculations [15:47:25] they actually already had such a display for Apollo 11 [15:47:56] I guess if insertion was bad they could have done a tweak burn there, too [15:48:05] setting up better for CSI [15:48:24] sadly I know very little about that display and the calculation method [15:48:36] I really only have the MED inputs for setting it up [15:48:40] and 1-2 mentions in the FIDO audio [15:49:09] I don't know if it uses the same rendezvous calculation method or some simpler version of it that they could run every 2 seconds or so in the RTCC [15:50:18] I never considered a tweak burn contingency for 11 [15:50:39] I guess I assumed they had enough maneuvers to null out errors between the 3 major burns and MCCs [15:50:41] but it's probably a display like the ascent/descent digitals. It would calculate stuff with the PGNS, AGS and MSFN state vectors [15:51:13] That would be a great info page [15:53:54] and it should calculate some rendezvous on its own, for a tweak burn [15:54:53] tweak burn could also be required for a descent abort [15:55:26] Very true [15:56:00] At least the bailout burn has a fixed number :P [15:59:13] rcflyinghokie, I'll have a revision coming to the RTCC quick reference guide soon [15:59:23] Oh excellent [16:06:16] Looks like you might get away with a non MPT version [16:06:44] funny. That display is called ascent rendezvous montitor (ARM). And for the short rendezvous profile they needed an additional display for that. How do the mission rules call it? "Short ARM" [16:06:59] as opposed to "Long ARM" :D [16:07:34] Hahaha [16:07:42] but yeah, according to that it calculate solutions for PGNS, AGS and MSNF [16:07:44] MSFN* [16:07:56] and I think it will also need to calculate tweaks for both LM and CSM [16:08:34] and also for a bailout maneuver it seems [16:09:54] I think the bailout maneuver is DVX only to get back to coelliptic, right? [16:12:02] yeah [16:12:07] if tweak is > 60 ft/s [16:12:17] or perilune becomes lower than 5 NM due to the tweak burn [16:12:29] then you do the bailout maneuver instead [16:16:55] Yeah [16:17:13] A predetermined attitude and DVX is also in the lm timelines for those it semems [16:17:14] seems* [16:17:41] yeah, probably the attitude that is DVX burn only [16:17:58] 15 for example was LO+12, FDAI 0 242 0 or OHW 10deg, and DVX 41.5 [16:18:39] LO+12:10* [16:19:36] Looks like tweak for 15 was insertion + 2 minutes [16:26:22] oooh [16:26:29] DESCRIPTION OF THE SHORT ASCENT [16:26:30] AND RENDEZVOUS MONITOR DISPLAY [16:26:30] PROCESSOR TO BE USED ON [16:26:31] APOLLO 14 AND SUBSEQUENT MISSIONS [16:27:04] but probably NARA only [16:28:17] https://archive.org/details/NARASWSelectedApolloBoxes/page/n733/mode/2up?view=theater [16:28:22] yeah, UHCL doesn't have it [16:28:25] or the archived NTRS [16:30:28] I guess I'll wait until I can get that before attempting to implement it on my own [16:30:34] ... so not in a while [16:31:46] Haha figures [16:31:49] But still promising [16:33:55] oh yeah, I am sure it will be very good [16:40:27] That reminds me, I still dont rememeber finding anything procedure wise on that "yaw/roll maneuver" used for maneuvering to TPI attitude without losing radar lock [16:40:35] Do you recall anything by chance? [16:41:04] nope [16:42:11] morning! [16:42:23] hey Mike [16:43:47] Damn ok, same here I have been striking out [16:43:54] morning Mike [16:44:22] the Apollo 17 rendezvous procedures have "YAW / ROLL MANEUVER" in very large letters [16:44:28] but then doesn't go into any more detail [16:49:26] Yeah and the timeline books have it as well [16:49:30] Thats all it says [16:49:54] I am assuming its a maneuver to TPI attitude without breaking RR lock [17:13:35] I am trying Shift-W and Shift-S for ORDEAL slew switch up/down...what do you guys think? [17:13:51] it will make ORDEAL operation from the VC much easier [17:14:55] sure, I never had any issues really. If you zoom out fully then you can see both ORDEAL and FDAI [17:17:43] well ideally you want the DSKY in view too [17:17:48] with V83 [17:18:34] right, I guess that is difficult [17:27:40] it will be nice to have actual degree marks on the fdai balls [17:33:16] AlexB_88, in your PR, you removed a bunch of AddSwitch calls for the VC [17:33:43] that prevents DefineVCAnimations being called for them, right? [17:34:35] yeah all the hatch controls are derived from RotationalSwitch and PushSwitch [17:34:49] so the AddSwitch would want a meshgroup [17:35:28] but the challenge with the Hatch stuff is that its multiple animations as children of the main animation (Hatch) [17:36:53] so the DefineAnimationsVC is in the hatch classes already [17:37:41] so I think the AddSwitch, without a meshgroup being sent, probably said "ok then I will find a random meshgroup for you" [17:39:12] hmm [17:39:47] so it just didn't call DefineMeshGroup for it [17:41:42] so right now if you operate the LM hatch releif valves (both), they directly set the state of the RR shaft, like 0.0, 0.5, 1.0 [17:41:59] so the RR shaft somehow got used as the meshgroup [17:42:53] RR shaft animation* [17:45:29] is RR shaft mesh group 0? [17:45:52] no [17:46:58] 45 [17:49:49] I think there can be a better solution, this is more of a workaround [17:49:59] But first I have to find out why it changes that particular animation [17:50:34] yes but the hatch is a special-case since all the animations have to be defined in the same DefineAnimationsVC I think [17:50:49] since they all depend on eachother [17:53:39] that's fine, there is still a better solution. This doesn't really fix the bug, which is that it defines an animation with an undefined mesh group. This just changes all the cases where the bug happens [17:54:15] so the bug still needs to be fixed. It shouldn't try to define the animation in those cases. Maybe even write a message in the orbiter log or so [17:55:24] I guess any case where an "AddSwitch" on its own might cause that bug [17:56:15] that's why the DefineVCAnimations functions already check if they have direction and reference defined [17:56:21] bHasReference && bHasDirection [17:56:30] it needs something similar for the group index [17:56:34] right [17:57:13] and then when it calls DefineVCAnimations it doesn't do anything [17:57:17] if you never called DefineMeshGroup [17:57:31] that way the switch is still managed, so no need for the separate cases for the mouse click [17:57:39] but it doesn't try to define an animation [17:58:14] right makes sense [17:59:37] hmm [18:00:24] did that bug happen every time? [18:00:26] or randomly [18:00:36] and always the RR animation? [18:00:54] so it was consistent, but only when in the VC [18:01:33] and only when nothing else was setting the shaft animation such as when you are in auto-track [18:02:00] so when the RR was un-powered or you were in slew and not actively slewing [18:02:17] and yeah always the RR shaft [18:05:57] so only the pitch of the RR, the yaw was fine [18:06:28] so I think it already doesn't define an animation [18:06:40] because you aren't calling SetReference for it either [18:06:53] but it seems to call SetAnimation though [18:06:57] so that is the bad part [18:07:50] aha [18:08:01] that animation is the first one that gets created in the LM [18:08:14] ah [18:08:40] think its the 1st animation I ever made :D [18:09:40] OurVessel->SetAnimation(anim_switch, 1.0); [18:09:54] it calls that for the relief valve handle [18:10:01] but anim_switch wasn't set to anything [18:10:05] it's 0 by default [18:10:41] so it manipulates the animation with ID = 0 [18:12:53] it needs to check on bHasAnimations [18:20:50] this could theoretically be fixed in the PanelSwitchesVC call, but it's better to have it in each function [18:23:03] so to fix this I would suggest [18:23:08] TwoPositionSwitch::DrawSwitchVC [18:23:09] ThreePosSwitch::DrawSwitchVC [18:23:10] RotationalSwitch::DrawSwitchVC [18:23:19] those three functions need a check on bHasAnimations [18:23:36] and if that is false, then those functions shouldn't do anything [18:23:45] if (!bHasAnimations) return; [18:23:48] or so [18:23:52] at the top of them [18:28:53] and you can revert the changes that did, if you want. But the check on bHasAnimations should definitely be added [18:28:57] that you did* [18:30:41] ok I will revert my changes as well, no use clogging up clbkVCMouseEvent [18:33:33] I'll just quickly check if all that theoretical talk actually is true [18:38:59] well yes, interestingly it only calls the DrawSwitchVC function after I have used the switch for the first time [18:40:46] but then forever? [18:42:18] it seems to depend on the state of the animation [18:47:00] aaah, no [18:47:06] if (viewpos == LMVIEW_FWDHATCH) { // To avoid that my DSKY clicks plays with the forward dump valve as well [18:47:33] that VC area isn't defined in all view positions [18:47:39] to avoid it being clicked [18:47:54] ok, so those animations are normally called every timestep [18:48:26] so yeah, that bHasAnimations fix should prevent the issue [18:53:04] ok great [18:59:54] SSU does the same, in most places for its switches [19:00:37] the PanelSwitchesVC stuff is inspired by some SSU code, but it's very different as our switch code is very different [19:01:35] so, I was looking at CM aerodynamics, just to understand how it works [19:01:44] we have only one airfoil, vertical, defined for it [19:02:07] for a bit I was confused how that can lead to any stability in the yaw axis [19:02:17] because the airfoil is really just for pitch [19:02:32] but you can define a center of pressure for the airfoil [19:02:41] I set that to 0 for the CSM to have more control over the numbers [19:02:53] but for the CM it's about a meter above the CG [19:03:11] and the force of the drag which is applied to that point pushes the CM back to 0° yaw [19:03:35] so it won't produce any lift or additional drag if you yaw out-of-plane [19:03:49] but it will create a strong centering moment due to that center of pressure [19:04:11] because we have a lot of good numbers now I would also improve the CM aerodynamics soon [19:04:23] like to* [19:04:30] nice [19:05:11] just testing the changes, should have the PR amended shortly [19:08:59] looks good [19:23:07] indy91, ok PR amended [19:23:21] only has the checks in toggleswitch.cpp now [19:25:05] LGTM [19:53:21] looks quite simple now :D [20:04:18] yeah agreed [20:06:09] I wonder if something tries to animate that SM panel somehow [20:06:58] hmm was the issue there before the VC work? [20:09:15] it's been there for a long time [20:09:27] but after the NASSP 7 release, fairly sure [20:09:32] when it started [20:10:18] Ah the mysterious vanishing panels? [20:10:22] yeah [20:10:52] but I am fairly sure the properties of the mesh are being manipulated [20:10:54] I know it happens regardless if there is a sim bay panel or not [20:10:58] it's still in the same place [20:25:24] True [21:04:35] that's about as much debugging as I ever managed to do on it [21:04:45] with the DX9 graphics debugger in-sim [21:05:38] that is why I thought it was the code used to hide the probe mesh [21:05:43] but that wasn't it [21:06:38] yeah I thought so too [21:06:57] at least that fixed the CTD when opening the forward hatch in some cases [21:12:58] Its just so hard to reproduce it seems [21:13:32] very [21:13:44] I think it has happened exactly once for me. [21:13:54] it happened fairly often when I first started my PC [21:13:57] and of course when it does happen, you save and reload and its gone [21:14:03] and then did a launch, T-60s scenario [21:15:50] in all my fuel cell debugging, which was thousands of short 5 minute runs with the csm, I never noticed it. [21:25:40] I know at least a few users have noticed it [21:27:11] it kind of started at the same time as I implemented the SIM bay panel jettison [21:27:34] I have checked that commit 100 times, that can't be the issue [21:35:58] I just wish there was a way to replicate/debug haha...I'll blame gremlins [21:39:35] is it invisible or is the mesh not loaded? [21:42:22] maybe it's some environment variable witchcraft happening behind the scenes [21:46:17] I'll have to look at it directly, but the mesh is loaded with its properties being manipulated to be invisible [21:46:55] I'm no expert, but these properties are in the mesh files, but can be changed by some API calls I believe [21:47:00] the mesh group editing [21:49:41] D3D9 Debug Controls [21:49:56] Highlight selected mesh [21:49:57] I linked a screen shot the other day I took last time I got it [21:50:22] go to the mesh and then down below it says Material 1 and 4 numbers with sliders [21:50:35] well, one slider [21:50:51] anyway, the fourth number must be transparency or something [21:50:58] because if you set that to 0 the mesh is invisible [21:51:09] and that's the state it was in when I got the bug and tried this debugging [21:51:21] and I think the other 3 numbers were wrong, too, not sure [21:56:58] so probably not even caused by a wayward SetMeshVisibilityMode call [21:57:31] I'm not sure, it could be. [21:57:53] haven't tried replicating a SetMeshVisibilityMode call that does the same [21:59:32] what I fear is some unsafe memory stuff [21:59:43] either way it would lead us in a particular direction [21:59:48] that could be caused by about anything [22:00:19] but its always that mesh even if it only happens randomly [22:07:12] yeah [22:07:17] good night! [23:19:53] yeah definitely gremlins. no other explanation [15:35:31] hey guys [15:38:10] hey [15:39:37] morning [15:42:48] good morning [15:43:07] n7275 were those your Apollo 10 rendezvous? [15:43:18] the shots in discord [15:52:30] I should continue with Apollo 7 and stop being distracted by CM aerodynamics :D [15:55:20] yes, Apollo 10. [15:55:35] it went very smoothly. [15:56:13] the new CM texture makes it a bit harder to see, but that's not unrealistic [15:56:46] the radar could see it. that's what counts [15:57:58] Awesome [16:00:20] did our CSM rendezvous light work at one point. I thought I remember it but I may be mistaken. [16:07:54] hmm don't think so [16:08:41] would be cool to add them and the LM track light as local light sources. [16:09:22] + sprites of course [16:16:43] yeah I think ill do that next [16:17:43] oh nice. I'm sure the LM will look amazing at night with the tracking light flash. [16:55:06] That and the other lights [16:55:21] Right now I think some lights are hardcoded in the CSM? [17:07:24] keep in mind that we have a hard limit of 8 local lights. because orbiter has a lighting model from 1998 [17:14:35] but yes, the SM navigation lights are always on. [17:17:15] morning! [17:20:15] this left handed vs. right handed coordinate system stuff will be the end of me [17:20:19] hey Mike [17:21:00] evening [17:23:51] hey [17:33:14] yeah left-handed coordinate systems are evil incarnate [17:49:01] n7275 so we couldnt for example have CSM running lights and LM docking lights on at the same time? [17:54:01] are docking lights considered local light sources though [17:54:53] as they are now none of our lights are local lights [17:55:07] the csm running lights are just an permissive mesh group [17:55:17] they dont illuminate anything [17:55:56] so we could switch those on and off similar to the LM [17:56:16] yeah [17:56:19] Only 2 lights on the CSM should be "local light sources" I believe [17:56:25] The Spot and EVA lights [17:56:31] correct [17:56:38] The rendezvous beacon and running lights dont need to be [17:57:41] stuff that we dont need to be able to shine on another vessel could be done with a light map texture [17:58:01] basically same as the LM has [17:58:27] Interesting, I didnt realize there were EL lights in the docking ring [17:59:05] *RL [17:59:34] we dont have any lightmaps currently [17:59:56] Well however lighting is done on the LM then haha [18:00:21] Also, I am shocked I never came across this before, the EVA boom light actually is extended at tower jett [18:00:29] ITS DONE WITH AddBeacon IN THE lm [18:00:36] SORRY CAP LOCKS HAHA [18:00:41] lol [18:00:42] there [18:00:42] haha STOP YELLING AT ME [18:00:45] haha [18:01:27] "the cork covered boom is deployed as the BPC jettisons with the LES, pulling a pin that holds the boom, in its stowed position" [18:01:33] I should really look at what I wrote before pressing enter lol [18:01:51] Yeah cant stealth edit on IRC ;) [18:02:24] autocorrect makes me say some weird things sometimes if I dont catch it [18:03:01] How hard would it be implementing the EVA light boom itself [18:05:43] as that light is on when the running lights are on [18:06:33] it all should be pretty easy [18:06:58] the boom is extended by the astronauts before EVA right? [18:07:23] nope its spring loaded and pops out at BPC jettison [18:07:32] oh [18:07:34] see my above quote from the AOH [18:07:52] I did not know that until today haha [18:08:00] so its extended the whole mission basically [18:08:09] seems that way, yeah [18:09:03] and all the EVA handles have RL lighting and so does the docking ring [18:09:06] Also TIL [18:10:15] I guess ideally it could be animated [18:10:19] And the fwd hatch exterior handles as well so they can be found in the dark [18:10:39] but the issue is I think animations in Saturn are only defined after CSM/LV sep [18:10:51] as it is now [18:11:03] Considering its spring loaded, I dont see the harm in just "popping" it out per se [18:11:21] If animating it rotating isnt possible [18:19:02] after a bit of clean-up of the saturn stagings, ideally getting rid of all the ClearMeshes() as we now do ShiftCG, it should be possible to add an animation right after LES jettison [18:19:17] That would be pretty cool [18:19:36] the problem with ClearMeshes() is it screws up the animations when called [18:19:39] And then that light could be switchable with the running lights [18:20:00] there is a flag that is supposed to keep the animation, but it seems to not work correctly, maybe an Orbiter bug [18:20:11] interesting [18:20:44] it was actually a major issue for us when we 1st started adding animations, im sure Niklas remembers :D [18:21:37] What all animations does the CSM have? SPS bell and HGA? [18:23:10] other then VC, yeah [18:23:28] and hatch [18:24:16] hatch is animated? I thought it just popped out [18:24:28] Like the docking probe [18:24:33] ah, right for the exterior view [18:24:44] from the VC, its animated [18:24:51] Oh ok gotcha [18:24:56] probably should make them both animated [18:28:18] would be cool to fly a backup rendezvous using the CSM beacon and the AOT [18:33:19] looks like its 1 pulse/sec like the LM tracking light [19:24:06] just realized the original LM mesh we had came from Eagle Lander 3D v1 [19:24:18] https://www.youtube.com/watch?v=av_94HfTkpI [19:24:24] look familiar? [19:24:44] https://www.bing.com/images/search?view=detailV2&ccid=UzconYAb&id=631A0186F70C79EB28218CE62BD127A8B3F3A0C5&thid=OIP.UzconYAbiH7eC6-kQEY6mAHaFX&mediaurl=https%3a%2f%2fwww.orbiterwiki.org%2fimages%2fthumb%2ff%2ffc%2fNASSP7LEMOnMoonSmall.jpg%2f600px-NASSP7LEMOnMoonSmall.jpg&cdnurl=https%3a%2f%2fth.bing.com%2fth%2fid%2fR.5337289d801b887ede0bafa440463a98%3frik%3dxaDzs6gn0SvmjA%26pid%3dImgRaw%26r%3d0&exph=435&expw=600&q=n [19:24:46] assp+Lunar+module&simid=608038339902245702&FORM=IRPRST&ck=66FA96C6F71A57DEEB9D8962E892D797&selectedIndex=5&ajaxhist=0&ajaxserp=0 [19:48:30] oh wow [19:48:34] or Eagle Lander got it from NASSP [19:50:24] or they both got it from the same source [19:54:35] We no longer use it right? [19:59:58] nope [20:07:42] Good. Almost got me worried. [20:07:59] We'd have to pull the mesh if we still used it. [20:09:46] I doubt that very much [20:10:29] I'll do a bit of digging, but I'm sure we either find that there was permission given or Eagle Lander uses the NASSP mesh [20:11:39] the NASSP 7 release is probably using that mesh [20:12:09] don't know when Alex did the new one [20:12:39] https://github.com/orbiternassp/NASSP/commit/24defd2ea8e674fbb1b1ae0115bf2386a33b1941#diff-ae6a6b9c165e262d832a9e151316e2e144fb521dea682ed00b8cf1709bb16928 [20:12:40] 2018 [20:13:02] It's not in 7 [20:14:33] the new one isn't you mean [20:27:21] Yeah [20:27:35] do we still have the CVS commit history? [20:27:39] I can download the files [20:27:55] but I am not seeing a commit history [20:31:22] CVS commits should be visible back to 2005 [20:32:00] but where? [20:36:31] git log --all --grep="string" [20:37:47] https://github.com/orbiternassp/NASSP/blob/master/Meshes/ProjectApollo/LM_ascent.msh [20:38:50] the original was added on 21 november 2005 [20:39:00] by Tschachim [20:40:10] 85c72f94f33c91af4a2578825d69a96cc57abe10 [20:40:41] what do I do with that? [20:43:26] https://github.com/orbiternassp/NASSP/commit/85c72f94f33c91af4a2578825d69a96cc57abe10 [20:44:59] oh, I tried that and it didn't work and then thought it wasn't a git commit :D [20:47:20] it could have been an older version of this [20:47:26] https://nasa3d.arc.nasa.gov/detail/lunarlandernofoil-c [20:52:55] oh actually the LM mesh goes back to the beginning [20:53:14] ...of the CVS history [20:54:40] nassp 4.x used a different version by the looks of it [20:54:44] https://nassp.space/index.php/File:NASSP4_CSM_LM.jpg [20:55:48] http://spacebarjoe.free.fr/ [20:55:53] the NASSP 4 one looks like that NASA one [21:15:00] I think the previous mesh was added in NASSP 5 [21:15:25] in the documentation credited to "Rodion", at least the ascent stage is [21:15:48] and that person is still occasionally active in the Orbiter Forum [21:15:54] so in doubt we can maybe ask [21:24:42] I guess he would of given the mesh to EL3D v1 as well [21:24:45] and we should probably do a better job of keeping track of this stuff for non-code [21:25:04] of course in some cases it goes back by decades already haha [21:26:07] it's unlikely that Eagle Lander even has the same format for meshes [21:26:47] so if they are indeed the same, it's likely that is comes from the same source [21:27:02] but probably wasn't converted somehow in an effort to "steal" it [21:28:24] yeah I highly doubt is was "stolen"... surely any permissions must of been obtained [21:28:43] too bad its hard to track down though [21:43:02] i haven't looked but maybe theres some info in the Meadville forum archives [21:46:24] https://www.orbiter-forum.com/threads/tell-us-about-yourself.43/#post-8502 [21:49:32] "orig. mesh by Ron Monsen" [21:49:49] that pretty well settles where it came fro. [21:49:51] from [21:50:19] ah good find [21:50:31] there is no way we didnt have permission though [21:51:07] indeed [21:51:16] at least I choose to think that :D [21:51:31] better than taking down all of the NASSP 7 (and 6!) releases haha [21:51:42] yeah [21:55:05] aha! [21:55:20] NASSP Enhancement Pack 1.0 for NASSP 5 [21:55:24] in the documentation for that [21:55:29] CREDITS [21:55:33] Ron Monsen - creator of the awesome EAGLE LANDER 3D lunar landing simulation (the second version of which is now available and indeed an awesome Lunar Landing simulation in itself). The initial "skeleton" for this new LM mesh comes from the raw 3DS files found in an older version of his simulation. Thank you sir, for a great base-mesh to work with. [21:55:51] hmm [21:55:59] of course that still doesn't say they had permission :D [21:56:53] Sounds like we are climbing down a rabbit hole :P [21:57:03] as far as NASSP 7 is concerned, if we had to remove the LM mesh it wouldn't change much of the user-experience anyway...most of the rest of it is already missing :D [21:57:07] https://www.linkedin.com/in/ronaldmonsen/ [21:57:16] We could ask him if needed [22:00:40] right. At least we now know where it comes from [22:04:22] on a different topic, the "Html" folder has some ancient stuff in there [22:04:34] we can probably delete that [22:04:42] or make new ones [22:04:57] true, I saw that earlier when I was searching, too [22:05:08] So does doc [22:05:15] we also credit him here https://web.archive.org/web/20190101121832/http://nassp.sourceforge.net/wiki/ProjectApollo:About [22:05:48] Thing about deleting stuff is that the people extracting over a previous version will still have those files [22:05:58] Same goes for the recently removed scenarios [22:07:04] right [22:07:06] hmm [22:07:30] for the MCC scenarios that means that, when overwritten, they will be twice in your folder [22:07:42] old MCC scenarios with MCC in the name [22:07:52] won't get updated by new releases anymore [22:07:59] it should already help if you delete all the "Project Apollo" folder [22:08:04] folders* [22:08:19] maybe something to add to the Installation Guide [22:09:14] most of our files have a dedicated folder, except for the Config and Html directories [22:10:08] and Script [22:13:33] indy91: How do I know if I'm in Earth or Moon SOI using the AGC? [22:13:40] Some flagword? [22:14:49] Found it :p [22:15:35] wasn't there a specific procedure they did in the real mission concerning this? [22:16:47] CMOONFLG [22:16:48] 102:18:00 Collins: Okay. The purpose is to bring the LM and the CSM state vectors to Earth's sphere of influence. Step one: Verb 37 Enter, 23 Enter. Step two: At Noun 70, at Noun 70, load and register 1, 2, and 3 the following numbers. Register 1, 00002; register 2, five balls; register 3, 00210. Step 3: proceed on Noun 70, Noun 70. Step 4: proceed on Noun 25, 25. Step 5: do not proceed on Noun 18. Wait for 30 [22:16:49] seconds; then do Verb 37 Enter, 00 Enter. End of procedure. Over. [22:17:19] is that Apollo 13? [22:17:34] LGC doesn't automatically switch SOI [22:17:43] Apollo 8 [22:17:46] oh [22:18:15] well I guess that brings the state vector to current time [22:18:23] which is then in the new SOI [22:18:38] otherwise the SOI switch isn't done until P00 decides it needs to integrate [22:20:53] right [22:21:19] so they maybe wanted to force that process [22:22:25] 102:20:34 Collins: Roger. Normally, it is done automatically, Jim; and had you done the P23s exactly as scheduled, it would have been, but there was some doubt P23 was stopped about 7 minutes prior to the transition point and just to be absolutely sure, we included this procedure. Over. [22:22:47] so some possible P23 weirdness [22:24:30] night! [23:04:20] n7275, is the lighting subsystem even exist yet in Saturn? [23:04:50] i'm looking through the code and cant find anything [23:05:47] whatever subsystem controls the Run/EVA & Rdvz/Spot [23:06:34] I can easily add the rendezvous light to start but I don't know what to wire it to haha [23:11:29] I can help with what to wire to [23:13:39] I guess the CSM version of the TLE "Tracking Light Electronics" in the LM [23:15:25] Yeah at least with respect to its flashing [23:15:33] Doesnt really have a subsystem like the LM [23:17:26] RUN EVA has 2 breakers LIGHTING - COAS/TUNNEL/RNDZ/SPOT MNA MNB [23:19:25] Those power the EXTERIOR LIGHTS 2 switches RUN/EVA and the RNDZ/SPOT switch [23:21:45] Since the beacon light and its electronics are all in the SM it didnt need a true subsystem like the LM [23:23:03] right [23:23:06] The RUN/EVA controls the running lights and the EVA light on the boom [23:23:30] RNDZ controls the flashing rendezvous beacon light [23:23:39] and SPOT the forward facing spot light [23:24:29] CSM 114 systems handbook pdf 223 has the lighting schematics [23:26:16] Ah I was mistaken the LIGHTING RUN/EVA/TRGT cbs power the RUN/EVA switch [23:26:27] And the CSM docking target outlet [23:27:07] Because those are AC [23:29:05] Interesting the spot light pops out of a little door [23:30:45] It deploys on the first use and remains deployed [23:30:52] So another animated thing lol [23:35:35] Spot light seems to be connected to both AC and DC busses in the AOH but only DC in the CSM 114 handbook [23:35:38] Might have been a change [23:39:08] Yeah thats odd certainly a discrepancy [00:00:38] CSM 104 and 114 handbooks have just DC but the AOH has AC and DC [00:02:13] Hmm but why is there an AC neutral in there...I just cannot connect the dots in the handbook haha [00:03:19] Ah found it [00:04:00] AC powers the light itself via the RUN/EVA/TRGT AC2 cb [00:04:59] And DC power from COAS/TUNNEL/RNDZ/SPOT MN B [00:05:36] Got it haha (sorry for wall of talking to myself text) [00:36:08] Spotlight is more convoluted than I thought lol [00:36:10] "The spotlight is mounted behind the left rendezvous window on the door of a concealed compartment in the CM/SM fairing. The door is spring-loaded to the deployed position and is held flush by a pin extended [00:36:11] To deploy the spotlight/door, on MDC-2 (upper left) place the EXTERIOR LIGHTS-RNDZ SPOT switch in the SPOT position. The spotlight door initiator/actuator receives 28 vdc, its pin-retention wire melts, pulling the spring-loaded pin and releases the door. The spring-loaded door swings to the deployed position and is held there by a hinge-brace. As the switch is placed in the SPOT position, it simultaneously applies 115 vac to the [00:36:12] spotlight, turning it on. [00:36:15] " [00:37:01] So "technically" if we tried turning it on for the first time without DC power it wouldnt open..should simulate that ;) [00:46:18] rcflyinghokie: this is early and somewhat outdated https://www.ibiblio.org/apollo/Documents/CSM%20Functional%20Integrated%20System%20Schematics%20Block%20II%20Revision%20K.pdf [00:46:37] it's NAA's CSM equivalent of Grumman's Elementary Functional Diagrams [00:46:56] a good source for corroboration, or finding things that the systems handbook misses [00:47:12] Actually I was able to corroborate them, it was me misreading haha [00:47:38] So user error [00:47:55] ah, classic PEBKAC [00:48:19] ^ [00:48:27] Clear cut case [00:48:49] It lines up right down to which cb of the 2 dc and ac were used [00:49:02] But isnt that door mechanism interesting? [00:49:36] does seem very interesting the amount of fine detail that can be simulated when reading the AOH [00:50:01] but I think I will start with animating the EVA boom, then we'll see from there :D [00:50:23] yeah, I didn't know they had little deployables like that :D [00:50:28] Haha of course, boom is already there and we dont have a CSM spotlight currently anyways [00:50:51] But yeah, DC power to melt a wire to release a spring door [00:51:18] that's pretty classic... a lot of satellites even nowadays do exactly that to deploy solar arrays [00:51:23] speaking from experience ;) [00:51:43] Honestly it makes perfect sense but I didnt even think about it [00:51:52] I never read into the CSM lighting until today [00:52:17] So that and the boom being deployed by the BPC jettison and being extended the whole mission two TIL [00:53:17] Still kind of geeking out over the brilliant in its simplicity concept [00:57:09] hehehe [01:00:59] And still amazed how I never learned about the CSM exterior lighting until now [01:01:09] Its more complex and robust than I thought [01:07:18] (sorry Alex :P)