[20:06:28] NASSP Logging has been started by thymo [20:06:36] Should be fixed now [20:06:51] yep, looks like it works [20:06:52] thanks! [20:07:45] Uptime was at 151 days. Now it's at 0 again. Time to let that build again.. [20:08:58] Gonna have to take it down again when I get back from holiday. Kernel could use an upgrade. [20:09:09] But it's not that urgent. [13:34:06] hey [13:36:25] I am very smart. Flying some more Apollo 8 without switching to the development branch I have for the MCC changes [13:38:18] hey [13:38:20] nice [13:38:51] I think I didn't actually change the mission states in the part of Apollo 8 I am currently in so it's probably fine?! I'll have to check [13:39:36] oh haha I see, hopefully the states will still match [13:40:35] yeah, I didn't change anything in the middle of the translunar coast [13:40:45] just up to after TLI and then before LOI [13:41:10] Is there a certain document that would have the state of the LM batteries before initial checkout? [13:41:22] like which are on and which are off [13:41:32] ours have 1 and 4 on, 2 and 3 off [13:41:49] hmm [13:41:57] but the Apollo 12 Activation check would suggest that they are all on in lo taps [13:41:58] Systems Handbook might show them in specific states [13:42:15] it would if it wasn't missing the EPS page, haha [13:42:39] we have the one from Apollo 15, but it's different of course [13:44:14] isnt there a pre-launch close-out checklist or something? [13:44:25] yes, in the AOH Volume 2 [13:47:59] hmm [13:50:55] it's a difference between LMs [13:51:05] Apollo 15 LM Activation has Bats 2 and 3 in bp [13:53:16] but it's weird [13:53:24] the prelaunch checklist has it all in off [13:53:34] and then later during flight all in low [13:56:17] Im looking at LM11 AOH vol2 and I see the same [13:56:51] not sure the SCEA is powered at that point though [13:57:13] could just be that [13:57:21] hmm probably not, I guess thats just a switch position check [13:59:55] yeah [14:00:24] so from AOH Volume I and comparing the pre and post Apollo 14 versions of it I would say it's a mission specific thing [14:01:04] we use the later version right now, with batteries 1 and 4 in low, others off [14:01:15] but I guess it had all batteries online until at least Apollo 12 [14:01:41] yeah the Apollo 12 checklist has them all on [14:01:48] 14 also [14:01:50] so up to 14 [14:02:07] so we should change it [14:02:13] easily done [14:02:20] well "Verify" which implies that they were all on from before initial entry [14:02:25] yeah [14:02:56] do you want to change it? I'm in the dev branch [14:03:08] haha I had the code right in front of me, sure [14:03:09] lemsystem.cpp starting line 176 [14:03:20] ill change those to 2 [14:03:22] yep [14:03:29] for bats 2 and 3 [14:08:44] yeah [14:09:02] I wont change the ascent batts :P [14:15:34] this makes me want to properly implement the relay junction box and the deadface relay box :D [14:20:23] sure [14:27:38] hmm, so I tested the changes to batteries 2 & 3 and it works, but going to LM PWR - CSM and back seems to switch batteries 2 & 3 off [14:28:45] interesting [14:29:29] LEM_XLBControl::UpdateFlow [14:29:36] in lm_eps [14:30:29] the implementation seems to be lacking a bit of realism [14:32:43] in case -1 it sets 2 & 3 back to 0 [14:33:13] yeah [14:34:44] how it should be working is that the signal from the CSM can override the LM internal setting [14:34:57] and when CSM power is disconnected the LM power returns to what was set there [14:35:12] as usual a relay by relay simulation would solve this :D [14:37:09] hmm [14:37:10] so I guess its not a case of switching those to 2 as well [14:37:22] I think there actually is a wiring difference between missions [14:38:18] because you would want to have 2 & 3 off during CSM power ops [14:38:48] and then 2 & 3 back to on when the LM power is reset [14:38:55] that's only an Apollo 15 and later thing [14:39:07] ah ok [14:39:21] before I believe all LV taps should be switched on and off [14:39:24] but not 100% yet [14:39:42] funny that the EPS is modelling the J config while the panel is the earlier one [14:39:55] well partly modelling* [14:40:11] they probably only had the later AOH available [14:40:16] right [14:40:25] we have more information nowadays [14:41:29] I think one of the 1st thing we should do once we have the configurable systems in NASSP 9 is properly make the different versions of the LM EPS (systems & panel) [14:42:41] yeah [14:44:27] in the mean time, should I make case -1 in LEM_XLBControl::UpdateFlow turn all 4 back on? [14:47:07] researching that right now [14:50:36] what I am trying to figure out is two things [14:50:46] well, no [14:51:08] when CSM power is applied the state of the ECAs doesn't matter much [14:51:40] but when power is returned to the LM, should it go to LV or whatever was selected before [14:53:47] right [15:14:47] just set them all to LV I guess [15:15:13] a different solution would need the relay junction box properly implemented anyway [15:16:23] on Apollo 15 and later the LV taps were actually removed from batteries 2 and 3 [15:16:40] so that wouldn't work anyway [15:17:05] ok [15:19:39] https://www.icollector.com/Apollo-LM-Relay-Junction-Box_i22363936 [15:22:21] the CSM signal is the same as if you were holing the low voltage switch in the up position [15:22:28] holding* [15:23:28] that's the reset signal [15:23:44] so I think forcing them all to be in low voltage is correct [15:41:15] Ill make the change to LEM_XLBControl::UpdateFlow [15:41:59] on another topic, the LPD window FOV code we have sets the FOV to 60 all the time, I think we should rather handle this like the AOT view [15:42:18] which sets the FOV based on user screen resolution [15:42:54] without it, then the LPD markings are not accurate unless the LPD window markings are completly visibile without scrolling up and down [15:43:28] which is only true if you have a 16:9 screen I think [15:43:56] yes [15:43:57] but adding the same code for the FOC as the AOT has fixes this [15:44:01] FOV* [15:44:13] the person who figured out the AOT for us made some suggestions about that iirc [15:44:14] oapiCameraSetAperture(atan(tan(RAD*30.0)*min(h / 1080.0, 1.0))); [15:44:19] yeah [15:45:10] but he ended up saying it wasnt needed since we can do an LPD calibration, but imho we should use the FOV code. LPD calibrations were not meant for calibrating our sim's screen lol [15:45:51] and that was a feature added with Luminary 131 or so [15:46:08] yeah [15:46:43] and I believe you would benefit from this, aren't you using a 16:10 display? [15:47:17] indeed [15:47:52] I have tested the code with 1680x1050 resolution and its sets the FOV to 57 [15:48:11] and that makes the LPD markings line up perfectly with the HUD pitch scale [15:48:47] nice [15:49:06] I always had good LPD results, but I know that they were off a little bit on occasion [15:50:08] so at FOV 57 you will have accurate LPD markings, I think if you scroll the view however, you just have to go out and back into the LPD panel to re-center [15:50:34] yeah [15:50:38] no problem [15:50:41] yep [15:50:54] Ill commit that change along with the EPS changes [15:50:58] I can just about press the PRO button in the LPD screen [15:51:09] so rarely a need to scroll [15:51:14] right [16:01:10] tested a landing with 1024x768 (4:3) which gives an FOV of 43. Worked perfectly [16:01:52] with that I always had to scroll to the DSKY to see the numbers [16:02:03] I wonder if theres a hotkey to center the view [16:03:23] Home [16:03:28] "Return to default view direction." [16:03:34] so probably not centering it [16:03:40] hmm I think thats just direction [16:03:41] if it's not Home then there is no hotkey [16:03:45] yeah [16:04:19] home works in the VC for returning the view to center [16:37:34] dseagrav responded to my XRSound issue [16:38:52] I guess Ill tell him we are planning it but it may not be for a while that it gets implemented but well let him know when we do so that he can make the change to the autobuild [16:40:42] yes [16:50:18] morning! [16:50:36] hey Mike [16:50:43] what's up? [16:51:01] the classic multi hour research for one tiny change [16:51:05] hehehe [18:09:06] indy91, PR sent [18:09:37] I have various fixes in there along with the LM EPS and LPD FOV stuff [18:10:17] what's the panel direction one? [18:10:49] upper hatch, had to rotate it 180 degrees [18:11:13] ah [18:11:36] or else the open view did not match with what you see on the tunnel/hatch mesh [18:12:53] I also removed the annoying crash sound that you hear at interstage sep [18:13:08] I guess you wouldn't really hear anything there [18:14:24] yeah I highly doubt it made that noise [18:14:52] there are some pyros firing for sure [18:14:56] but in vacuum by that time [18:15:06] yeah [18:15:16] they might of felt a thump I guess [18:15:21] yeah [18:15:23] that's ok to be removed then [18:15:54] merged [18:16:13] thanks [18:30:05] Im suddenly getting that telecom bind fail message come randomly for some reason [18:42:11] hmm [18:42:13] weird [18:42:44] try closing Orbiter completely [18:42:52] I think I had it sometimes when I was immediately reloading [18:50:08] ah maybe it was still running somehow [18:50:32] Ive had it where I had to use the task manager to completely close Orbiter [18:50:34] Orbiter running twice could cause it [18:50:37] yeah [18:50:59] it's like the LM and S-IVB using the same frequencies, always causes issues :D [18:51:11] two CSMs are no good [18:51:55] yeah [18:53:42] speaking of LM and S-IVB, id like to figure out a way to delete the 2nd docking port on the LM after LM extraction. I guess is the LM->CSM->SIVB connector can return success to the LM after LM/SIVB sep command and use that to kill the docking port? [18:54:41] how far along is that, does the 2nd docking port still get created after reloading? [18:54:59] yeah its always there [18:55:03] hmm, ok [18:55:25] maybe you could add code in the LM timestep somewhere to check if the docking port is undocked [18:55:29] and then it deletes itself [18:55:29] its just defined in clbkSetClassCaps [18:55:40] ah right [18:58:45] the default Orbiter Shuttle should have the same thing [18:58:52] I'll check how it handles it [18:59:21] normal and ET docking ports get created in the constructor [18:59:37] in the separateTank function it does [18:59:45] if (hDockET) { [18:59:45] Undock (1); [18:59:46] DelDock (hDockET); [18:59:46] hDockET = NULL; [18:59:46] } [19:00:11] ah [19:00:13] and in clbkPostCreation [19:00:23] if (status < 3) { [19:00:24] }else [19:00:29] if (hDockET) { [19:00:30] DelDock (hDockET); // remove the ET docking port [19:00:31] hDockET = NULL; [19:00:31] } [19:00:36] so it gets deleted in post creation [19:00:39] ok [19:00:49] post creation is after loading? [19:00:51] I always forget [19:01:15] yes [19:01:17] after loading [19:01:25] so that is the appropiate place for it [19:01:30] sounds good [19:01:36] got to go out for a bit but Ill check look through that when I get back [19:01:41] ok [19:02:06] in doubt we need to add a flag for "separated from the SLA" [19:02:10] and then make a check on that [19:02:25] not sure if the docking has properly happened in PostCreation already [19:02:27] maybe it has [19:38:48] cya [11:40:58] hey [11:41:34] hey Alex [11:42:41] I think Ive managed to figure out the docking port deletion [11:43:29] ah, very nice [11:43:32] and the docking port is now defined in the constructor [11:43:45] both of them [11:43:49] yes [11:43:55] and deleted in post creation? [11:44:20] yes, but also in the timestep [11:44:31] using the flag for if separated [11:44:54] ah, we already had that [11:44:58] what was it used for? [11:45:45] or did you just add that [11:46:02] hust added a bool SepFromSLA; [11:46:08] just* [11:47:31] anyways Ill push what I have if you want to have a look [11:48:14] ok [11:48:24] I almost wonder if we even need a flag for that [11:48:45] because, the docking port should never exist in the undocked state [11:49:00] it gets docked together basically when the LM gets created [11:49:08] right [11:49:19] so the condition "is docked" is almost enough to delete it [11:49:50] https://github.com/jalexb88/NASSP/commit/ccdf4584ddb9fae2464dd63ec30b2ab0217b97b2 [11:50:01] a check on that would require it to be docked in post creation already [11:50:56] if ((!DockingStatus(1)) || (stage > 1)) { [11:50:58] hahaha [11:51:03] now this is creative thinking [11:51:14] separating the ascent stage while the LM is still in the SLA :D [11:51:29] the LM is only attached on the descent state I guess [11:52:21] I know I had tested it so I added it to make that work :p [11:53:33] yeah [11:53:40] I wonder if this was ever considered in any way [11:54:00] ascent stage alone is rather useless for most things [11:55:46] I put this in prestep but I dont know if post step would be better [11:56:38] should be ok [11:56:41] hmm [11:57:06] I wonder what this ascent stage case does to the connector [11:57:35] I'm pretty sure deleting a docking port currently in use undocks before deleting it [11:57:39] so that should be fine then [11:57:54] the undocking of the LM/SLA connector is done upon a docking event [11:59:36] and that stage thing is also the reason why we do need the flag [12:00:52] the descent stage isn't docked to the SLA though, right? [12:01:02] also, the docking pots used to both be in clbkSetClassCaps... I think then they would of been created after the connectors were registered in init ie: RegisterConnector(1, &LEMToSLAConnector); [12:01:03] when you stage before SLA sep [12:01:12] no not the descent stage [12:01:27] its in the right position but not docked [12:01:44] registering connectors luckily doesn't require them to exist yet [12:01:49] ah ok [12:01:51] it just registers the docking port ID [12:02:01] 0 or 1 in all cases right now, more aren't supported [12:02:01] but now they are before anyway [12:02:06] yeah [12:03:06] I was hoping in might of caused that CTD but maybe not [12:04:06] yeah, probably not [12:04:14] maybe something else with the connectors, but not that [12:04:26] right [12:05:19] I can add an undock(1) for the ascent stage case to be sure [12:05:51] to do what? [12:06:28] to be sure its undcoked before the deldock in the case of ascent stage sep [12:06:41] undocked* [12:08:19] or if (DockingStatus(1)) Undock(1) [12:08:38] DelDock "Any object docked at the port will be undocked before the docking port is deleted." [12:08:44] ah ok [12:08:49] DelDock takes care of it [12:08:52] good [12:09:18] and it's 99% likely that it will call the docking event callback for that [12:09:44] if not that probably would be an Orbiter bug [12:10:25] the only CTD from that would be if you try to command a LM ejection after the LM has already staged [12:10:51] but as I said, I very much doubt that is the case [12:12:40] I also moved SetDockMode(0); from SetClassCaps to the constructor [12:14:02] ok [12:14:05] whatever we need that for [12:14:12] maybe the dockingprobe code needs it [12:14:30] yeah [12:16:37] a bit more testing and I will PR this [12:17:13] but so far so good, Ive already tested it quite a bit last night, as you can see even trying weird cases like ascent stage sep from the SIVB :D [12:17:53] yeah [12:17:57] looks good from my side [12:18:26] I found separation procedures for TLC LM staging [12:18:29] but not in the SLA [12:18:41] I'm sure there are mission rules about this [12:20:14] ah yes [12:20:18] Apollo 11 mission rules [12:20:43] 2-12C "If normal LM ejection is not successful, no attempt will be made to man the LM and 'stage' to recover the ascent stage." [12:20:50] but this might not be the same for all missions [12:24:09] same mission rule for all missions I think [12:24:14] I checked 9, 12 and 17 [12:25:33] but it probably depends on the situation [12:27:42] what if you have a complete fuel cell failure between TLI and TD&E? [12:27:43] you probably want to get the LM at all cost then [12:27:44] yeah [12:28:18] speaking of mission rules [12:28:33] there is a wrong Apollo 8 direct abort maneuver [12:28:34] TLI+35 [12:29:04] they got a Maneuver PAD for a 4800 ft/s maneuver and the P37 numbers for the 24h hour faster return (7800 ft/s) [12:29:26] not sure what that is even based on, max DV is 10000 ft/s. Why go slower??? [12:30:21] the 7800 ft/s solution doesn't exceed the return velocity constraint either [12:35:13] using the slower solution is in agreement with the operational abort plan though [12:38:59] weird [12:40:32] maybe there is some other rule with maximum desired SPS burntime [12:51:19] now I too am wondering if I need that sep flag lol [12:52:43] why not: [12:52:48] timestep: [12:52:49] if (docksla && ((!DockingStatus(1)) || (stage > 1))) { [12:52:50] DelDock(docksla); [12:52:50] docksla = NULL; [12:52:51] } [12:52:57] post-creation: [12:53:06] if (docksla && !DockingStatus(1)) { [12:53:07] DelDock(docksla); [12:53:07] docksla = NULL; [12:53:08] } [13:08:50] yep it works [13:09:51] what does DockingStatus return for a docking port that doesn't exist anymore? [13:10:32] well it has to get by docksla 1st anyway? [13:10:58] yeah, I was just wondering [13:11:14] good question [13:11:43] param port docking port index (>= 0) [13:12:16] probably returns 0? [13:13:20] I can test with a test with a debug string [13:13:25] in the mean time: [13:13:34] https://www.dropbox.com/s/gmje2uclxete0h8/Screenshot%202019-05-31%2009.09.22.png?dl=0 [13:13:59] "Houston, we have LM extraction...uh wait" [13:15:17] partial extraction, what does the mission rule say, don't do that... oh [13:16:59] I guess the check on docksla should stay [13:17:04] Alternate universe Apollo 11 [13:17:06] then it doesn't matter how dockingstatus reacts [13:17:25] yeah, to me it looks safer [13:17:34] I mean, you can still crash the ascent stage into the Moon, if you had any sensors there to measure the impact [13:39:27] oh, can you add the same kind of code to the docking module? [13:39:29] ASTP project [13:40:20] there is an empty PreStep function [13:40:31] and you would have to add the post creation [13:42:05] sure [13:42:08] needs the exact same function name and format or else the overload doesn't work [13:42:43] I'll be gone for a few hours [13:42:47] cya later! [13:51:00] .tell indy91, dont we want to keep both docking ports on the ASTP anyway? Anyway sent the PR for now [16:18:11] morning! [16:25:17] hey Mike [16:29:54] hey [16:29:55] what's up? [16:49:13] more fixing of things here and there, you? [16:54:20] work work work [16:54:30] need to finish up those CDU models at some point [16:58:14] good evening [16:59:27] well, the SLA "docking port" and the one for the Soyuz are not the same [16:59:40] or rather, there currently is no docking port for the Soyuz [16:59:58] coordinate system wise it is almost on the same level, but not quite [17:00:22] hey Niklas [17:00:23] ah ok [17:00:51] hey Mike [17:01:04] SLA Truss attach point at 585.2 inches [17:01:12] if you wait a bit before merging the PR I can add the ATSP stuff [17:01:13] Soyuz/DM docking interface at 588.0 inches [17:01:53] yes that would be good [17:02:23] not sure how those two docking ports will be handled in the future [17:02:37] maybe by only having one active at a time [17:02:47] SLA attach point gets deleted, docking interface created [17:02:50] or something like that [17:02:51] eventually [17:03:14] AGC couldn't handle a docked Soyuz anyway :D [17:03:22] none of the versions we have at least [17:03:31] haha [17:03:34] that's the docked Skylab DAP reused [17:03:37] someday maybe [17:04:14] CSM + DM should work quite nicely by assuming the DM is a LM ascent stage [17:13:47] indy91, PR amended [17:15:13] and merged [17:15:34] thanks [17:18:48] on another topic, I figured out why my DEVMESHHANDLES are not getting initialized at LM initial creation, and only at LM loading from a scenario file [17:19:18] that caused the issue where the astronaut mesh appears in the LM when it gets 1st created on the SIVB [17:20:50] ah, good [17:20:52] but anyway, in clbkVisualCreated, GetDevMesh(vis, ascidx); does not work as expected because I think the ascidx is not yet initialized at that point. But if loading from the scenario file, it is initialized by then [17:24:28] so I tired as a test to call SetLmVesselDockStage() from clbkSetClassCaps and that makes it work correctly, but probably breaks a whole bunch of stuff too haha [17:25:09] probably not a good solution and I dont know if this is going to be easy to fix [17:25:59] the reason I tried it in clbkSetClassCaps is becasue thats where the deltaglider calls all the stuff in our SetLmVesselDockStage(), etc [17:28:00] hmm [17:28:07] order of things is an eternal problem in NASSP :D [17:28:14] so much depends on this saved in the scenario [17:28:28] maybe doing something in post creation would help? [17:30:37] well, I think the only way would be to initialize the meshes before clbkVisualCreated, which seems to me like itself is called pretty early seeing as the meshes indexes dont seem loaded yet [17:31:09] or is there a way to recall clbkVisualCreated after loading? [17:36:14] no, Orbiter calls the clbk functions [17:36:25] yeah thats what I thought [17:38:18] anyway I confirmed with some debug strings that it is the mesh indexes all saying -1 still when it passes through clbkVisualCreated at LM initial creation [17:38:36] and they say 0 as expected when loading the LM from a scenario [17:39:00]