[18:42:55] NASSP Logging has been started by jordan64 [18:42:57] hi [18:50:30] morning! [19:29:00] Hey [19:29:43] yo [19:30:06] What's up? [19:30:18] mostly work [19:30:25] making pretty good progress on Sundial source [19:31:11] Ah nice [19:39:48] Jordan64, I'll be home in a few hours and I'll try the switch guards mesh you fixed [20:41:07] thewonderidiot: Reading your last comment. Are they any arguments as to why we need to keep compatibilty with prehistoric software? Why not just slap a big 2.0 sticker on to yaAGC and break the interfaces. Software using yaAGC needs to be rebuilt anyway before they can use the new stuff, might as well update it to support new features we implement. [20:42:28] that's a question for Ron [20:42:35] he's normally a huge stickler for backwards compatibility [09:16:52] morning! [13:05:55] Hey [13:09:35] hey Thymo [13:10:40] Got an exposure notification today. Looks like I'll be in quarantine for the next 10 days. [13:11:10] ah fun [13:11:25] I got myself a cold yesterday [13:11:36] I think I'm sneezing too much for it to be Covid [13:12:06] so not too worried [13:13:04] but I'll avoid people anyway [13:13:38] Yeah, the notification is most likely a false positive. It says that I was exposed yesterday but I was home all day, only went for a run at 21:00. Didn't see anyone. [13:13:59] Nevertheless better be safe than sorry. [13:14:05] definitely [13:24:47] I did some cleanup on the project files yesterday. Mostly removing defines from code that can be set as preprocessor option [13:27:05] 86 files changed, oh boy [13:28:46] but most of those are just the same project file change for every project [13:29:51] Yeah, just serach and replace basically [13:29:58] s/serach/search [13:30:58] and the functions like GenerateHANDRUPT in yaAGC, those were added in the NASSP files only? [13:32:49] Yep. I left them in agc_engine so that they can all be removed at once. If I change anything from yaAGC I get a merge conflict if I merge it into sync_agc [13:33:15] hmm [13:33:24] you also changed uprupt [13:33:33] not calling IsUPRUPTActive in yaAGC anymore [13:33:41] only checking on the interrupt request [13:33:42] but [13:33:49] that's not all that function was doing [13:33:58] IsUPRUPTActive (agc_t * State) [13:33:58] { [13:33:59] // UPRUPT is waiting to be processed [13:34:00] if (State->InterruptRequests[7] == 1) { [13:34:00] return 1; [13:34:01] } [13:34:02] // UPRUPT is processed currently [13:34:03] if (State->InIsr && State->InterruptRequests[0] == 7) { [13:34:05] return 1; [13:34:07] } [13:34:11] return 0; [13:34:12] } [13:35:32] Hmm, how did I mess that up.. [13:35:44] Will change when I get back to my desktop [13:37:06] sure [15:28:40] hey [15:34:28] hey Alex [15:34:51] Hey Alex [15:47:59] https://www.dropbox.com/s/jvk5qlpgqku5s3m/Screenshot%202020-11-04%2008.47.02.png?dl=0 [15:48:25] got the switch covers working [15:51:09] Nice! [15:58:56] hi [15:59:06] hey Jordan [15:59:13] https://www.dropbox.com/s/jvk5qlpgqku5s3m/Screenshot%202020-11-04%2008.47.02.png?dl=0 [15:59:22] thats with your changes [16:00:47] are these the new ones? I made them thicker. [16:00:54] yes [16:01:05] I think its much better [16:01:47] should we leave them like that? [16:02:13] yeah, I think its fine [16:03:20] I think the backplates should be left out for now. I think the mesh will be too big otherwise [16:04:02] the CM_VC looks pretty good so far. [16:05:34] I agree [16:06:13] Isn't the right SwitchGuard missing on the EDS? [16:07:14] about that, I am using this https://sketchfab.com/3d-models/apollo-11-command-module-combined-372bb6781922471cada4e0a9bd5c61fb [16:07:39] and that one has no switch guard there either [16:07:55] but Ill have too find other pictures to be sure that is correct [16:10:43] I know it. I've already downloaded it. At first I thought maybe it could be used as CM_VR if it were allowed. [16:11:24] I think every switch has it left and right [16:14:05] hey Jordan [16:14:13] which EDS switch are you guys talking about? [16:14:35] the one on panel 2 [16:14:43] ah [16:17:11] indy91, btw I have been thinking of ways to handle the AddSwitch and PanelSwitchesVC [16:17:59] https://freshspot.typepad.com/.a/6a00d83451f23a69e2019b009e9394970b-800wi [16:18:29] maybe there could be a way that switches are registered and animated all within that class? That could avoid making hundres of animations definitions in saturnvc/lemvc [16:18:41] it looks like there is only one [16:18:53] yeah [16:19:33] looks the same in the AOH [16:19:40] Systems Handbook* [16:20:06] there probably is enough space there for another guard, but there already is a switch cover on the next switch [16:20:27] so they probably thought it wasn't needed [16:21:22] animated in the class, but can you properly do that? Doesn't it need to be relative to something? [16:21:55] this 3d model from sketchfab is a real CM photoscanned. so it should be very suitable as a reference. [16:22:05] yeah [16:22:16] although the fun issue we sometimes have is, not all CMs were the same haha [16:22:30] but I doubt this is one of the differences [16:23:34] AlexB_88, what SSU also does it have a class for each panel [16:23:44] they defin the animations in there [16:24:06] I guess that is better in the sense that you don't have to define everything for the whole CSM and LM in one place [16:24:28] our only equivalent is switch rows [16:24:47] but that would be a bit too much, having separate classes and files for each switch row [16:24:57] right [16:25:20] might be possible to add a panel class to that hierarchy [16:25:59] and that then would be a good place to add all animations [16:26:22] I was also thinking of a system where all the possible configurations and switches are present in the mesh [16:26:35] and then are made invisible at loading [16:26:52] and each AddSwitch turns them on individually [16:27:34] dependent on the mission, so if the Addswitch is never called for a certain switch then it is never loaded [16:28:22] hmm [16:28:50] but in that system I was thinking of having everything (the ID, flags, oapiVCRegisterArea, etc) called after the AddSwitch [16:29:04] like in PanelSwitchesVC [16:30:27] I'll experiment a bit with that in the LM when I am done with the LVDC update [16:30:48] I am up to timebase 5 with my cleanup of that btw [16:30:58] the LVDC timestep is now nearly empty [16:31:07] only calls interrupt and non-interrupt functions [16:31:35] the rumours that the LVDC update is never going to come are exaggerated :D [16:36:06] but I want my smooth launch guidance now! :D [16:38:51] do some Saturn IB flying then haha [16:40:44] speaking of Saturn IB, those missions still load the old CM VC [16:41:00] Ill have to fix that [16:57:59] funny thing happened with the LVDC, I had a bug in there so that orbital navigation wasn't running. But stuff like orbital navigation is now scheduled ro run as a task. [16:58:16] So I fixed the bug in code, reloaded the "broken" scenario and it had orbital navigation running 20 times in succession to catch up with the current time [16:58:20] so it fixed itself :D [16:59:49] indy91: PR updated [17:01:13] looks good. I think I want Mike to have a quick look at it, if there is any reason not to remove those functions. But there probably is none. [17:01:40] Sure [17:26:32] indy91, do you thin an area ID could be assigned when the AddSwitch is called? i.e. the area ID is increased by 1 and assigned to everything from that AddSwitch call [17:27:27] and then oapiVCRegisterArea and animations are defined after based on the new area ID [17:29:27] so basically, the AddSwitch would send the necessary information: The meshgroup of the switch, mouse/draw flags, position, animation angle/axis [17:40:41] yeah, that can probably work [17:42:25] the AddSwitch calls would get long, but it would make it cleaner I think, and easier to implement custom configurations [18:02:57] indy91, just a very rough idea but: [18:02:58] https://www.dropbox.com/s/w6mpj8b04wf0800/Screenshot%202020-11-04%2011.02.23.png?dl=0 [18:07:19] morning! [18:08:18] hey Mike [18:09:09] what's up? [18:09:41] as usual, distracting Niklas :p [18:09:56] working on the CM VC, just added the switch covers [18:10:07] https://www.dropbox.com/s/jvk5qlpgqku5s3m/Screenshot%202020-11-04%2008.47.02.png?dl=0 [18:13:38] thewonderidiot, Thymo has made a PR with some deletions from our yaAGC file, to get closer to upstream. [18:13:49] Just thought that you could maybe have a quick look at it: https://github.com/orbiternassp/NASSP/pull/554/files#diff-cbd368947f5e928183601b0f770e0ae3de17d316da39583d0c2322d0ecc3227a [18:14:11] don't think there is any reason not to change this, but I am not really the person to know [18:14:46] AlexB_88, as I said I'll experiment with this myself a bit when I have time. I don't know much about any of these VC Orbiter API calls, so I first have to learn [18:14:58] my cold is getting a bit more annoying, heading to bed early. cya! [18:16:42] cool, will take a look at it later [18:19:21] No changes in yaAGC yet. Just on our side. [21:57:44] I updated my repository. If you want you can test it. Changes were made to the LC39, the ML and the LM_VC. Both mesh and textures have been updated.https://github.com/Jordan-64/NASSP [22:21:17] nice [22:31:14] I think I just made NASSP work with upstream yaAGC [22:31:57] Still have to do some work to separate yaAGS from yaAGC but apart from that it appears to work [22:34:41] Jordan64, looks very good [22:34:55] Thymo, ah nice [22:35:28] will that help with ggalfi's changes? [22:36:32] Yep, now he can just submit his changes to virtualagc instead of diverging our version again [22:37:11] I just checked basic operation. To be sure someone should probably try to do a landing in the LEM with it or something. [22:40:00] I still don't know how to power up the LEM nor fly it. Maybe someone can give me a crash course sometime? [22:41:28] good night [22:42:17] if you want you can try the Apollo 17 - Before PDI scenario in WIP Scenarios/Apollo - Mission Scenarios/Apollo 17 [22:42:40] all you need to do is push in the landing radar breaker and start P63 [22:43:26] And then just sit back? [22:43:31] Until touchdown? [22:44:12] when you are around 40000 feet do V57 for landing radar updates to the SV [22:44:45] and then yeah, it pretty much hands-off from there [22:45:07] oh and engine arm - des of course at TIG - 30s [22:45:42] & CMD OVRD - ON after ignition [22:47:05] Looks like I'm getting a restart light on scenario start. Will need to look into that. In P63 now [22:47:47] when you start P63, hit PRO on N61, then at 50 18 PRO again to fine tune the attitude, then ENTER to go to N62 [22:49:04] Also had to put the RDVZ radar in auto track [23:04:15] AlexB_88: PRO at V99? [23:04:22] Checklist says AUTO IGN [23:04:27] yes [23:05:08] Engine doesn't start [23:05:38] did you do ENG ARM - DES? [23:05:44] yes [23:06:10] cmd ovrd is still off [23:07:43] were you on 06 62 during the countdown? [23:07:56] Yep [23:07:59] weird [23:08:24] How do I manually start it? Wonder if it's an issue with the AGC or not [23:09:46] Oh it is on [23:09:52] Just doesn't do throttle up [23:09:55] I expected a noise [23:09:57] it starts at 10 % [23:10:03] yes thats normal [23:10:13] after 26 seconds it goes to 100% [23:10:32] It didn't [23:10:39] How do I abort :P [23:12:54] Abort and abort stage don't appear to do anything besides show a V97 P66 [23:13:21] thats because of V48 [23:13:29] do V22 N46 E E [23:13:53] Isn't the AGS supposed to take over? [23:14:05] Went into P71 [23:14:23] GUIT CONT - AGS [23:14:29] oh and AGS - AUTO [23:14:46] Did that [23:15:05] Did I break the AGS too :o [23:15:59] Orbiter crashed [23:16:01] Not sure why [23:16:10] I would've crashed into the service anyway [23:23:09] s/service/surface [00:29:42] night [02:08:12] hey Alex [02:45:33] hey [02:45:42] whats up? [03:12:12] Flew a few more landings with the LEM VC (in my branch). It's amazing how the 3d space improves workflow [09:31:10] Morning [13:12:41] .ask AlexB_88 Is the LEM VC in Orbiter2016 yet? When I tried it the models were there but no textures. Everything was white. [13:45:33] Thymo, need any LM flying lessons? [13:46:01] Haha yeah, I nearly crashed twice yesterday. [13:47:01] First time was with my new AGC changes. Didn't get the throttle up to work somehow. Second time I messed up during the final landing, started going up again. Pitchover was weird too, never could see the horizon. [13:47:05] Aborted at 150ft.\ [13:50:37] But the upstream AGC definitely was able to drive the LEM to proper attitudes. Still want to check the engine for behaviour differences and check that the IO is still wired up properly. Should be good to merge upstream otherwise./ [13:54:59] Oh and it looks like the AGC has a restart on scneratio start with the new stuff. Didn't see anything in the restart monitor, might be just the light. Will have to check on that [13:59:34] you randomly didn't get a throttle up? [13:59:49] but the engine was on [14:00:20] and from what I remember, two things that were different in upstream were uplink and downlink, so that probably should be tested [14:02:59] "Is the LEM VC in Orbiter2016 yet? When I tried it the models were there but no textures. Everything was white." that's probably the old issue with the textures being in the wrong folder [14:16:34] I'm not sure. Might've been a procedure error on my part, might've been the AGC. I tried a clock update, that worked. My latest PR fixed that. Still have to test downlink but don't expect any problems. [14:17:05] Regarding the textures, that was on rhe Orbiter2016 branch. Is there something I should've migrated first. [14:21:15] have you added the TextureDir thing in your Orbiter config? [14:21:30] because that causes it to exclusively use that texture folder [14:21:39] so also textures in the ProjectApollo subdirectory [14:21:41] Think so [14:22:13] so it won't use the new textures for the LM VC, those are probably only in your Orbiter Beta install [14:22:47] I guess the easy solution is to copy the Textures/ProjectApollo folder over [14:23:02] Right, I suppose I can create a symlink to my beta install [14:23:46] yeah, should also work [14:23:54] Do you know if Martin has any plans to merge Beta into release in the near future? [14:24:37] the last time he has logged in to the Orbiter Forum was in March... [14:24:53] so we don't really know his plans [14:25:00] I hope there is a release at some point [14:25:22] I think he has said that if he ever completely walks away from Orbiter he will make it open source [14:32:26] Him leaving aside I think Orbiter becoming open source would be great. Undoubtedly more development will come from it. [14:32:43] Would love to see Linux support come to Orbiter [15:58:47] good morning [16:01:21] are you using a symbolic link for your textures by any chance? [16:06:38] Yes. Looking at it right now [16:07:06] Thymo, if you do then you have to transfer some new textures to your target texture directory as it probably didn't get the new textures when you updated the branch [16:08:10] just copying the folder Textures/ProjectApollo over should do it [16:13:49] I created a symlink pointing to the NASSP textures in my beta install so I don't have to copy all the time. [16:14:49] Wow this looks awesome [16:29:53] thanks, still a work-in-progress of course [16:30:27] after Im done with the 1st phase of the CSM VC Ill make the ECS stuff work in the LM VC [16:30:46] and add the COAS's, etc [16:33:23] I noticed the Sun was shining through the hull of the LM haha [16:36:55] oh right, I used to have that in an older version of D3D9 [16:44:37] Hmm just updated D3D9 and Orbiter no longer launches [16:45:55] D3D9 beta? [16:46:55] looks like you found my problem [16:55:27] did you manage to land the LM? [17:19:55] No not yet [17:20:08] About to go for another try [17:22:19] Must say that the attitude is kinda odd in the AP17 PDI scenario [17:23:12] Aren't you supposed to be looking at the surface instead of 100° yaw? [17:26:11] hey Alex [17:26:32] Thymo, at PDI you need the large yaw to have the S-band antenna pointing towards the Earth [17:26:41] Apollo 17 used the most extreme yaw angle [17:27:36] only Apollo 11 pointed directly down at PDI and did a 180° maneuver later on [17:27:46] most missions were looking straight up at PDI [17:27:51] morning! [17:27:53] hey [17:28:39] okay [17:28:42] Hey Mike [17:28:54] hey [17:42:07] Aight it says raw right at TIG+4. So I should face up? [17:50:08] yes [17:50:28] Thymo, Comanche 45 never makes it easy it seems... [17:50:30] oops [17:50:35] @thewonderidiot [17:50:48] why can't I be lazy and just type in Th [17:51:01] hehehe [17:53:52] haha [17:54:21] How does redisgnating work again? I know I could click it up and down [17:54:26] Same goes for v/s [17:56:28] first when P64 starts you need to do PRO [17:57:38] and then use the rotational commands as usual [17:57:41] so joystick or numpad [17:58:00] with numpad I would suggest turning the left ACA/4 JET switch to disable [17:58:07] that's next to the DSKY [17:58:20] with keyboard commands you are fully deflection the attitude controller [17:58:39] and with that switch on you are doing full override RCS firings, even if you just want to redesignate [18:03:03] Landed. Not a great one though [18:03:15] VH was not properly nulled [18:04:53] practice makes perfect [18:07:34] with Apollo 17 LM software, when flying manually you can go back to PGNS - AUTO and that will null all horizontal velocities [18:13:59] gotta love auto P66 [18:34:03] almost done adding panel 2 switches [20:37:03] indy91: I see a comment in apolloguidance that the CycleCounter should not be loaded until the CduFifos are saved/loaded. Do you know what's up with that? [20:41:03] Because not reloading it causes issues in the AGC. If the CycleCounter is 0 a fresh AGC simulation is assumed and the Restart light is lit. [20:42:13] thewonderidiot: I thiink your patches replace the CduFifos? [20:45:49] yes, I deleted all of that stuff in favor of pulse I/O [20:47:41] So, chicken or the egg. Make this work with the CduFifos or get pulse I/O implemented. [21:03:08] thewonderidiot: Also, you wired the restart light into channel 163. Any reason why RestartLight in agc_t is not sufficient? [21:04:02] external peripherals like yaDSKY2 only communicate through channels [21:05:06] Right [21:42:41] Yeah, something is definitely up with the upstream AGC. It just doesn't do the throttle up after ignition. Only goes to idle. [21:42:47] Works fine with our version [21:44:27] Thymo, no I don't know what that is about the CycleCounter, but I remember seeing that comment [21:45:10] and about the throttle [21:45:13] compare this [21:45:15] https://github.com/virtualagc/virtualagc/blob/master/yaAGC/agc_engine.c#L2365 [21:45:16] Figured it out. The CduFifos time some things using the cycle counters. But the CduFifos aren't properly saved so that messes up somehow I'd guess. [21:45:24] to this [21:45:25] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_sys/yaAGC/agc_engine.c#L2394 [21:46:05] might have been me who added those parts for LGC THRUST DRIVE and ALTITUDE MTER DRIVE to work like the TVC/auto optics [21:46:46] yep [21:46:47] https://github.com/orbiternassp/NASSP/commit/e064e1355f1f84e46eab0094183c3908ede87e4c#diff-c9a4eee27793e0304516a9d0313f6d1eceeb819da9db38da23bdd6247197fc69 [21:49:42] I found a procedure in the AOH to do a landing with manual throttle.Call up N92 to display the desired throttle setting and adjust manually [21:50:28] yep, useful feature, they didn't have it in the earlier missions [21:50:57] The alt and alt rate tapes also don't work. [21:51:03] Wonder if the radar will [21:51:09] that's what I just said, yes [21:51:18] "might have been me who added those parts for LGC THRUST DRIVE and ALTITUDE MTER DRIVE" [21:51:33] I added those to the agc_engine.c [21:51:37] Check [21:51:41] and upstream never got it [21:52:19] not sure what to do about that though [21:52:46] wouldn't it be a bit pointless to add those to upstream if we have a different I/O implementation at some point anyway? [21:53:00] I wonder if I skipped over anything that Ron had intended for how this would work [21:55:05] RR CDUs in the LM are the same as optics CDUs in the CSM, so RR drive should probably work [21:55:17] I have no LR data so far [21:56:00] It's tricky. We've got our own fixes so the AGC works with NASSP, Mike has his to fix the CDUs and ggalfi also has some. Who goes first? [21:56:02] oh LR [21:56:29] what do you mean by LR data. On the tapemeter or going into the AGC? [21:56:47] tape meter should definitely be broken, as it's missing that code I added [21:56:56] LR is probably fine? Checking [21:57:57] hmm, I would have expected it to be fine, don't think we have any differences there [21:58:01] LR breaker is in? [21:58:13] and you won't have good data immediately after PDI [21:58:16] Yeah, it is. I was going off the tapes. [21:58:20] ah [21:58:29] yeah that would be broken, as I added that code [21:58:35] I'm still learning as I go. Have the AOH open at the same time to figure out how this thing even works :P [21:58:40] makes sense [21:58:57] on the DSKY, in Luminary 210, the LR data is always shown [21:59:03] in R1 [21:59:11] if it says +99999 data is still bad [21:59:32] It's bad them [21:59:34] then [21:59:55] I suppose there is no procedure to land with the LR INOP [22:00:43] nah, you would abort [22:00:57] but the LR breaker is in? [22:01:12] https://www.dropbox.com/s/kzjd2izbx0bccvi/Screenshot%202020-11-05%2015.00.58.png?dl=0 [22:01:15] panel 2 [22:01:16] I mean our LR code is rather cheaty [22:01:28] beautiful [22:01:38] It is [22:01:42] I just cycled it [22:01:56] helped on Apollo 14 :D [22:02:04] I know :D [22:02:40] AlexB_88: You make me wanna setup my TrackIR again. [22:04:16] you didn't break radarupt [22:04:51] can you get 6DOF with trackIR in Orbiter? [22:08:11] I think so. Not entirely sure thouh [22:08:13] though [22:08:43] well I see nothing obvious that could break the LR [22:08:53] What does V58 do [22:09:36] I did V58 and set RADAR TEST to LDG [22:09:45] AGC has an indication and tapes are driven [22:10:43] V58 is inhibit LR update. Rarely used, once you see good LR data you would do V57 [22:10:53] RADAR TEST to LDG is part of the LR self test [22:11:01] would disable normal operation of the LR [22:12:49] Got radar data now [22:13:09] Pointed the radar more towards the ground [22:13:38] oh yeah, with the large yaw angle it won't work [22:13:52] aaand Orbiter crashed again [22:13:53] that's why you manuall go back to 0° yaw a few minutes after PDI [22:13:55] damn [22:13:56] Second time today. [22:13:57] Weird [22:14:09] does it show anything what it is? [22:14:12] or can you debug? [22:14:52] if it's a ntdll.dll issue, that has been giving me nightmares for months, occasional and random crashes. Luckily not that often [22:15:15] No logs, No crash dumps, No exit code [22:15:23] I still had the debugger connected. [22:15:24] fun [22:15:32] It reported a normal exit [22:16:07] something in the Orbiter log or DX9 client log? [22:16:12] No [22:16:19] Modules\D3D9Client [22:16:29] D3D9ClientLog.html all fine? [22:16:41] accidental ALT+F4? :D [22:16:55] I already restarted orbiter so lost the dx9 log [22:16:58] right [22:17:09] NASSP does seem buggier than it used to be [22:17:25] but very difficult to find [22:18:52] Could do with some unit tests sometime. If someone is really bored and has lots of time [22:20:52] have some good landings, good night! [22:20:56] night [22:35:49] .tell ind91 Just got the crash again when I pressed F8. Got a screenshot of the error and a coredump. [22:56:54] Is the D3D9Client not open-source? [00:13:16] Thymo, is the error when pressing F8 to go in the VC? [00:13:48] and, yeah Im pretty sure its open-source [00:16:13] Yeah found the sources hidden in a forum thread. [00:16:40] It happened when switching out of the VC to the MFD/HUD view [00:17:11] Assertion failed in D3D9Surface::GetDC() [00:18:08] I managed to build D3D9 myself but the release version is not build with any debug info [00:18:16] So no way to go back and trace what happened [10:09:42] morning [12:52:27] hey [12:55:33] hey Thymo [12:57:03] How are the landings coming? [13:02:37]