[15:27:53] NASSP Logging has been started by n7275 [15:27:55] hey guys [15:32:22] should we encourage people to diret development talk/questions to IRC vs discord? [15:32:40] /s/diret/direct [15:38:53] I would say all actual development talk should be here [16:45:03] morning! [16:53:30] hey mike [16:55:31] what's up? [17:04:06] not too much [17:05:36] i have a feeling that im going to have to put the thread project on the back burner for a while [17:07:15] so i guess ill need to find a new project, maybe one of smaller scale next [17:11:36] booo [17:29:04] but yeah makes sense. multithreading is an enormous can of worms [17:33:22] in its curent state it isnt even faster, and i still need to add things line syncronization for all the SRC->voltag() calls, etc. [17:46:36] *like [17:46:55] plan b, wait for computers to get faster [17:48:12] hehehe [18:53:53] if you want a smaller project you can help me with the 2D panel... ok that was a lie, not actually smaller :D [18:58:50] hehehe [14:37:47] hey Niklas [14:40:34] hey [14:47:29] I got thinking about my threads last night. I think the problem is that I'm trying to do this with as many threads as possible, which in my case is 24. if I scale that down to like 2 or 4, results are substantially better [14:56:05] interesting [14:56:35] why would that be? [14:57:24] probably the overhead from locking/unlocking/waking all of them [14:58:15] there also seems to be some weird competetion between the AGC threads and the system threads [15:19:36] no matter how dificult implimenting this gets though, at least we won't have to update any scenerios :) [15:24:29] same for my 2D panel update. A looot of code changes, but scenarios wont care [15:26:13] I need to add a mutex to ship_object, so that when a particular system is being updated/refreshed it can't touch connected systems. e.g prevent it from updating a battery and itc charger concurrently. [15:26:31] *its [15:27:57] figuring out how to prevent deadlocks there will be fun [15:44:35] speeking of pannel stuff, does any of the SPSDK pannel code get used for the 2d pannel? [15:44:58] *panel [15:53:04] hmm, don't think so [15:53:10] I should try deleting that some time :D [16:17:46] morning! [16:18:37] hey Mike [16:18:45] what's up? [16:32:20] i decided against flying a mission last night, in favor of messing with my code again [16:32:46] hehehe [16:33:35] maybe with a few more adjustments, i can fly a mission *with* this new code. [17:39:01] I have done that so often, just waiting for doing one more code update to fly another mission :D [17:41:34] at this point I am not sure which mission I would fly next though [17:41:43] I haven't flown all of them from start to finish though [17:41:55] maybe I should do Apollo 13 with explosion [17:58:33] I'm waiting to fly that one until I have fuel cell code that depends on partial pressures of reactants [18:00:22] I still want to try a non-landing polar orbit survey mission at some point. [19:33:39] this new Mercury addon is quite impressive [19:40:19] Yeah, I would love an open source version [19:41:27] I wonder how that secondary view works [19:41:49] the periscope [19:42:03] I didn't know that was possible, it definitely has a different FoV than the main window [19:44:32] I wonder if it's a camera projecting a texture [19:44:54] just going off of the screenshots though, havn't tried it yet [19:51:21] I think the 2016 Vostok addon has something similar [19:53:15] It does https://youtu.be/m7hpU9pV3N8?t=790 [20:04:34] for some reason this is making it very hard for me to be interested in re-reading ASME B30.30 again right now haha [20:08:10] What do you mean? How could anything be more exiting than reading safety standards? :P [20:25:16] custom camera [20:25:53] seems like the VC will be able to support the sextant at some point [20:28:36] yay! [20:29:26] ...to the sextant thing, not the safety standards [20:54:12] we would have a slight performance advantage in that we would only need one camera on at once [21:04:49] yeah, I'll have to start reading in the DX9 client API [21:05:00] night! [22:48:14] n7275: This mercury familirization manual is pretty handy: https://ia800500.us.archive.org/8/items/nasa_techdoc_19790077942/19790077942.pdf [22:48:25] It's quite a fun addon to play around with [01:24:56] Thanks! [14:45:37] hey [14:46:15] hey [15:05:36] Hi [15:16:30] oh boy, there is currently a moon landing conspiracy discussion happening in my office here. I need to remain calm and not do anything too drastic... [15:18:16] Just think how calm Buzz has always react... nevermind [15:20:19] lol, I opened my big mouth. at least no one needs to wonder about my opinion now haha [16:20:06] morning! [16:20:13] your coworkers actually believe in that crap? [16:20:17] :P [16:34:37] yeah how can you believe Apollo 11 landed, have you seen the list of radar anomalies that software had [16:38:40] the best thing about Ron scanning all these first pages of MSC memos, he also scanned the first pages of change documents [16:38:58] and those changes usually have a bunch of features listed on that page [16:39:29] it's helping me figure out how they went from Apollo to Skylab rendezvous targeting on the ground [16:39:34] hah nice [16:39:53] interestingly I do have the main document from the archived NTRS [16:40:12] so if I ever ask Ron to scan this, all I need is the changes [16:45:26] would have been nicer of course if NTRS already had the change documents :D [16:45:32] but it only rarely seems to have that [17:18:03] haha if only [17:33:43] I'm not sure how much input MSC had on MIT when coding the Skylark rendezvous programs, but I feel like I see some "yeah MIT did it better" changes in these update notes [17:34:27] always fun moments. I would also like to know about the whole back and forth on the powered descent abort targeting. [17:34:45] In the PGNS Apollo 9, 10, 11 and 12 had different schemes each mission [17:34:54] and they settled on what the AGS did on Apollo 11 already haha [17:35:26] so big brother AGC had to acknoledge that little brother AEA did something simpler and better [17:36:07] oh really? [17:36:10] lol [17:36:22] that had to hurt a little bit :P [17:38:41] I'm sure the TRW software team was also a lot smaller [17:40:24] the Apollo 12 LGC uses the same scheme as the Apollo 11 AGS, but they did slightly expand on it with a second segment for late PDI aborts [17:40:41] Apollo 12 flew FP6 so there was a incompatibility between the two programs [17:40:55] from Apollo 13 on they finally had it all figured out [17:42:22] I guess another reason for this is also that the mission techniques for descent abort were a bit fluid until they actually started landings [17:42:32] so the software had to follow the trend of the current best technique [17:44:47] meanwhile TRW had already figured it out so they just sat back and watched :D [17:46:10] yeah definitely in terms of making use of orbital mechanics knowledge TRW won that one [17:51:19] ohhhhhh man the CDU just shipped [17:54:00] :D [18:37:33] so, roughly one week until I get to pop it open and see what mysteries it contains [18:39:32] nice! [20:50:29] night! [14:14:29] good afternoon [14:16:02] Hey, good afternoon :) [14:17:44] I think I am happy now to drop one maneuver sequence from the DKI, one of our rendezvous processors. I know the real DKI never could calculate this sequence and it's fairly simple to do with the MPT. [14:18:09] I have been thinking about this a lot lately, haha, all caused by the Skylab stuff, they ran this rendezvous processor as part of the launch window calculation [14:19:41] Not many people will care yet anyway, this specific sequence is mostly used for Apollo 13 and later, No PDI+12 abort maneuver [14:21:11] Sounds good. I'm sure I want to fly it at some point. I've been wanting to gain a better understanding of how rendezvous actually works instead of blindly following procedures [14:26:02] now I am regretting doing the current PR in my Orbiter2016 branch, you always come up with something to change... [14:26:07] but it makes sense [14:27:31] I'm not sure I completely understand it though. So there would be some new header file, which has an enum defining each class type [14:27:40] and there is one IsVessel function with integer input? [14:27:56] and inside it, it does switch/case with each class name? [14:28:12] would that be a global function, or would you put it in a class or... [14:32:03] Hmm, maybe not it's own class, unless you need state. A namespace could work. [14:32:26] Then we can have a nassp_util namespace for other utility functions we may need in the future [14:33:45] So you use nassp::util::IsVessel(...) or if you want to you can then have: using namespace nassp::util. [14:34:05] we already have nasspdefs.h which does something similar [14:34:13] mostly #define though [14:34:16] but some functions [14:35:13] Those are just inlined functions with very basic conversions [14:35:17] yeah [14:38:02] I guess I'll also call the file nassp_util.h then [14:39:07] and how would you implement my solution for the general Saturn class. Just two function calls to IsVessel? [14:39:39] I had a IsSaturnIB and a IsSaturnV. And IsSaturn just does return (IsSaturnIB() || IsSaturnV()) [14:41:08] ah I guess I can add Saturn class as a separate thing in the enum [14:41:16] and just check on both class names [14:41:27] Or just call IsVessel again [14:41:44] Maybe you could make the switch fallthrough some cases [14:42:07] Or split it into an internal function if it's too complex [15:09:09] recursion also works [15:09:21] calling itself with [15:09:26] case Saturn: [15:09:27] return (IsVessel(v, SaturnIB) || IsVessel(v, SaturnV)); [15:10:06] I forgot if you liked recursion or really hate it :D [15:10:20] alternatively [15:10:21] bool IsVessel(VESSEL *v, ClassNames name1, ClassNames name2) [15:10:22] { [15:10:23] return (IsVessel(v, name1) || IsVessel(v, name2)); [15:10:23] } [15:10:36] whichever has a better chance of getting approved by you... [15:28:08] Wait, what is the purpose of the second one? [15:28:45] Check if it's either a V or IB? [15:29:06] yep [15:29:34] I'd go with the switch [15:30:21] ok, so recursion [15:31:00] should work [15:41:40] Nice, looks good [15:44:30] thanks [17:04:02] morning! [18:21:57] hey [18:28:39] what's up? [18:48:34] still looking at rendezvous stuff [18:48:35] and you? [18:50:48] trying to figure out what the heck system 207's story is [18:51:52] I guess the answer isn't, it launched on Skylab 3 :P [18:52:07] hahahaha almost certainly not [18:52:14] unless they were getting extremely desperate [18:53:28] yeah Skylab 3 was system 221 [18:55:10] but Skylab 3 was AS-207 ;) [18:55:49] lol I wonder if there are any missions whose G&N system number matches their AS- number [18:56:24] I don't think there are [18:56:33] Hey guys! [18:56:37] hey there :D [18:56:42] Training, training and more training ! [18:57:33] Apollo 7 and Skylab 2 were only off by one number [18:57:35] hey Turry [18:57:46] https://prnt.sc/uyyLs4d-rvmf [18:57:53] Gutten tag [18:58:06] (I hope I didn´t made a typo) [18:59:09] one t too much [18:59:42] although depending on the area in Germany it could be pronounced more like "gutten" :D [19:00:11] My teacher was from frankfurt I think [19:00:30] Went to a quick german course many years ago [19:00:35] Forgot everything :D [19:00:41] Too quick course [19:02:51] nice LTA you got there [19:02:56] just lighting is suboptimal [19:11:46] yeah [19:12:06] Although I enabled ambiend light on debug options, it was dark too [19:12:14] Maybe wrong sep attitude? [19:12:43] https://prnt.sc/XaU325zibvnz [19:13:25] I doubt it [19:13:39] all other missions yawed left or right by 40°, but not Apollo 8 [19:13:45] Aha [19:13:53] so I think the attitude is right [19:14:10] Yeah, just transposition and pictures... [19:14:16] No docking [19:14:20] sim [19:14:48] could also be that LTA mesh and the way the lighting works in general, maybe has a hard time getting into that ring [19:15:17] yeah [19:25:12] So, I am running 1881. Is it safe for me to go to 1882 or 1883? [19:27:07] I already founds bugs in 1883 [19:27:16] nothing that would affect Apollo 8 [19:27:59] There was a bugged invoice today at job [19:28:14] I already had the may bug :D [19:28:25] right, only one bug per month allowed [19:28:42] 1883 is on the works still, right? [19:29:07] oops, released 4 hours ago [19:29:33] yeah [19:32:44] What is the "nassputils.h" file for? [19:32:59] just some utility functions [19:34:18] And yeah just some functions for failures, that I assume may come in the future [19:34:32] PanelSwitches::SetFailedState(const char *n, bool fail, int fail_state) [19:35:17] yeah, PanelSwitches is where all the switches of a vessel are managed [19:35:28] and every switch has a name assigned to it [19:35:39] with that function you can set failed any switch by name [20:09:22] Well guys! Sleep time [20:09:28] Good night [20:46:53] I do think we should add some local lights. maybe that would be a good side project for me. [20:50:51] Does anyone have a copy/link for the Mercury-Atlas 6 flightplan? [20:53:35] Asked too soon! [20:53:36] https://catalog.archives.gov/search?q=*:*&f.parentNaId=278187&f.level=item&sort=naIdSort%20asc [20:53:54] oh nice [20:54:06] I had searched for a little bit but hadn't found much [20:56:47] Meh it has revisions A and B which are pen and ink changes to the first file [20:56:54] Would be nice to have a final version [21:02:51] speeking of lights, the cockpit lighting in that mercury addon is something I want [21:04:38] I love the sounds too [21:05:36] Can I get this in a PDF? https://catalog.archives.gov/id/278190 [21:06:11] Can't figure out how this works, other than viewing the pages in-browser [21:06:25] yeah same [21:06:30] might just be .gif [21:07:20] "Include thumbnails" give you poststamp size images in a pdf [21:11:40] night! [21:12:51] Oh haha [21:12:52] https://www.ibiblio.org/mscorbit/document.html [21:13:08] Meadville Space Center is useful again :D [22:15:13] oh wow [22:16:14] i need to ask estar about forum archives again. would be kinda cool if those were searchable [16:11:51] morning! [17:09:04] hey mike [17:09:14] what's up? [17:11:31] oh not too much, started working on some external lights for NASSP last night [17:12:09] nice :D [17:12:28] sounds like a sufficiently smaller project [17:13:08] I hope so haha [17:14:53] I'm trying to figure out what the correct way to take apart a CDU is [17:15:10] as far as I can tell they don't have the same fancy disassembly features that the AGCs have [17:15:54] it's kind of remarkable how different their mechanical design is, for being two boxes of the same shape and size, both designed by MIT/IL [17:42:54] that sounds like a complicated puzzle [17:59:43] I also have no idea what the two little square protrusions above the test connector are.... and am wondering if they might be part of said puzzle [02:02:04] it would be really cool if visual studio had some way to know which files you wanted open in which branch [12:26:38] Awyt1 from the discord here. I've been experimenting with getting the PAMFD to fail cbs open, without actually opening them, to add additional system failures. Before I go any further I just wanted to check the best way to do this was to add CircuitBreakerSwitch::SetFailedState (like PanelSwitch) to toggleswitch.cpp, and then call a failed breaker [12:26:39] using SetFailed? [15:17:33] Abr35 I believe indy91 just added a few new functions recently related to fail states [15:20:41] it looks like you should be able to fail a cb with SetFailedState() now, if im reading this correctly [15:22:18] that function takes a name, bool failed, and then a state to fail in (enum or int iirc) [15:25:03] im looking at this on my phone so not the best advice atm, sorry [15:28:19] but im pretty sure that if you have PointerToSomeSwitchRow you can do: PointerToSomeSwitchRow->SetFailed("name",true, whatever the enum is for the state you want) [15:29:03] .tell indy91 correct me if im wrong on this [15:29:59] No problem - that's how I understood it. Tried to fail the AGC via the GNComputerMnABraker & MnB and recompiling the PAMFD was breaking all failures. Do I have to recompile the whole Project, or just the MFD? Sorry Im sure its a basic question [15:35:08] compile all doesnt hurt, not sure its necessary but there are a lot of shared files [15:35:29] breaking as in compile error or orbiter crashing [15:35:32] ? [15:56:15] Breaking as in the other failures do not work. So I can fail the LES Motor and or TowerJet Switches in the MFD, the flag changes, but switches and motors still work [15:56:50] Making it hard to test [16:37:22] morning! [16:52:44] It looks like it's compiling the MFDs but they aren't interacting with the vessel. Using VS2022, and can't find any current tutorials on setting up the environment for Orbiter. [20:32:27] hey Mike [20:33:25] Abr35 you will probably have betrer luck with 2019, thars what we're all still using [21:57:45] we're (Orbiter community at large) lacking a proper setup tutorial on build enviornment. but if you just open the VS solution in VS2019 it should build without any aditional setup. [23:28:23] So it looks like SetFail for the circuit brakers fails the image of the switch (open or closed) but not the behavior? I can still "open and close" failed breakers but their graphical appearance stays the same. Shouldn't it allow the braker to be manipulated but lock the behavior is either open or closed? [01:45:38] huh. yeah that doesnt seem right. [14:09:04] hey [14:21:50] hey Matt [14:22:20] you are wrong on this [14:22:30] I didn't add anything to the SwitchRow class there :D [14:22:37] I don't think it has any failure code [14:22:56] I added a function to PanelSwitches and that iterates through all the switch rows and switches to find the right one [14:23:13] ooh [14:23:54] well my advice to him was probably less than helpful then... [14:24:10] "Before I go any further I just wanted to check the best way to do this was to add CircuitBreakerSwitch::SetFailedState (like PanelSwitch) to toggleswitch.cpp, and then call a failed breaker" [14:24:17] Abr35 forgot what we talked about on Discord haha [14:24:21] that is not needed [14:24:35] the problem with circuit breakers right now is that it checks in the "state" variable in most places [14:24:42] on* [14:24:59] But to use the failedState variable you need to call GetState instead [14:25:15] GetState is checking if the switch should simulate failures and then either return state or failedState [14:26:18] "state" is always the actual position of the CB [14:26:23] or of a switch in general [14:27:55] CircuitBrakerSwitch::Voltage() for example checks on state right now and doesn't care about Failed or failedState [14:28:48] it does require some thinking though [14:29:03] if a CB is pushed in but it's failed open, that is an easy case [14:29:26] but the CBs have a trip point for overcurrent [14:29:45] so should it even be allowed to simulate a CB failing in the closed position? [14:30:06] Hey guys [14:30:15] Good afternoon / Morning [14:30:28] hey [14:30:32] hey [14:30:47] n7275 can answer your question on the forum best [14:31:07] short story is, a while ago there was a small physics update and old scenario take a bit getting used to the changed physics [14:31:10] but they recover [14:31:16] and new scenarios aren't affected [14:33:46] Physics or quimics? [14:33:48] :D [14:34:18] That was the name of a spanish TV show :) [14:34:41] I am now doing some electronics [14:35:36] "but they recover" What scared me was the cabin temp going up... 120ºF may not be confy :) [14:38:35] that wont happen during a mission that you fly from launch [14:39:04] Correct [14:40:24] its a bit like microwaving uptra-pure water in a smooth container [14:42:50] the new physics moves the phase boundry between liquid and gas, and also changes the energy requirements based on pressure [14:47:05] the cryo system is in a supercritical state for the first half or so of most missions, so you wont notice a change there (no energy required to go between liquid and gas) but near the end, and especially before entry there is a clear mix of liquid and vapor in the tanks, so when you load a scenerio that was simulated with the old method, some of that boils or condenses resulting in the cryo press warning [14:48:18] I understand [15:06:36] i also started a branch for adding lights [15:08:01] the lights on the csm should be fairly easy [15:08:57] ooohhh [15:09:08] Internal lights? [15:09:41] external first [15:09:45] ah [15:11:47] for some reason the latest version of d3d9 client for orbiter beta doesnt suport internal light. but ive been playing with this new mercury addon in 2016, and i love the lighting [15:12:52] which reminds me, i should ask on the forums why that was disabled [15:15:07] Could that be because some HDR "thing" has to be enabled or supported? Saying this because for example on X-Plane you have to enable HDR to be able to see cockpit lighting effects [15:15:19] But X-Plane runs with Open-GL or Vulkan [15:15:30] So don´t know if related... [15:24:00] i dont think so. the lighting options between the 2016 and beta clients are virtually identical [15:24:18] from a setting standpoint [15:24:29] *settings [15:24:42] and they dont look different [16:44:36] morning! [16:44:56] Hey [16:46:53] what's up? [16:53:24] Doing some electronics [17:20:28] oh nice. what are you working on? [17:22:23] An arduino based remote controller for my raspberry robot [17:23:38] sweet :D [18:15:29] i have a whole bunch of electronics projects that i would like to do, but i dont own an oscilloscope. should probably get one first [18:24:39] well those arebt as expensive as i thought they were... [18:25:15] *aren't [18:52:33] hey Mike [20:49:30] n7275: yeah hobbyist grade scopes have come a very very long way [21:36:05] Good night guys! [22:07:11] @indy91 Ok, now I'm catching on. The braker image is still stuck open but I was able to fail the computer via the PAMFD. I can try implementing a few random failures and then worry about github. How do we want these triggered? Adding a new tab to the PAMFD was my plan unless there's a better idea. [14:46:37] hey [14:53:46] hey [14:58:13] how is the CSM external light coming along? [15:02:29] well I got started on it on Saturday, and then got distracted by Mercury stuff on Sunday... [15:03:17] adding lights wasn't hard. I just need to make them do the drawpower and on/off stuff [15:10:55] right [15:11:14] yeah Orbiter has a decent lighting system [15:11:23] in terms of API [15:29:19] morning! [15:35:40] hey Mike [15:37:30] I finally figured out the correct way to open a CDU last night [15:37:37] just in time for it to show up today or tomorrow :P [15:42:00] so it is possible to open it [15:42:31] I already forgot all our conversations about it haha, wasn't it very difficult to do because it has basically been closed up to the point where you can't even repair it? [15:43:14] that is the backplane [15:43:25] it's still possible to pull the trays apart and get the modules out [15:44:08] ah right, just the backplane [15:47:05] I still haven't managed to come up with a good CDU joke. CDU is the second largest political party in Germany, Angela Merkel's party. [15:47:13] I've been thinking for a while :D [15:52:50] if I come up with one nobody not from Germany would probably get it, so I might as well keep it for myself lol [15:54:50] hahahaha [15:54:58] I did not know that :P [16:00:05] ok seems like I am finally getting somewhere with this Skylab rendezvous targeting [16:00:16] the ground solution, not the Skylark one I implement a while ago [16:01:28] it gave me "a" solution. Not sure yet if it works correctly. Need to actually display the outputs from the calculation [16:02:24] eventually I should be able to remove both the Skylark and our old DKI processor from the RTCC and only use the new one for both [16:09:03] nice! [16:10:06] was difficult to decide on the right version to implement. I have lots of information about it, missing lots more, and this was the main processor for Gemini rendezvous [16:10:19] undergoing development all the time to Skylab [16:11:12] one day I might develop a Gemini RTCC, but for that I need a few (hundred) more MSC memos from 1964 and 1965 :D [16:11:46] hehehehe [16:13:07] I do already have three very large volumes with flowcharts for the Goddard backup control center [16:13:16] was on the archived NTRS [16:13:47] it doesn't have any rendezvous calculations, I guess if they really needed to use the backup control center they were mostly interested in getting back to Earth [16:16:06] yeah that makes sense [16:16:17] similar to how the AGS can't land [16:17:27] those flow charts needed to be scanned at a bit higher resolution to be fully usable sadly [16:17:46] And there is lot of things I don't understand about them haha [16:17:56] referring to weird variables and doing weird things [21:03:03] night! [14:43:20] heh [14:44:03] So it turns out that in the VC the LEB DSKY is a mirror of the MDC DSKY instead of the actual MDC DSKY. [14:44:09] The 2D panel does it properly [14:44:40] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_csm/saturnvc.cpp#L1509 [14:45:06] That shouldn't fallthrough. It should call the render functions on dsky and dsky2 respectively. [14:46:15] Hey [14:48:01] good afternoon [14:51:23] Doing a bit of work on the DSKY today. It isn't being powered properly and the VC is rendering the MDC DSKY in the LEB, along with some cleanup. [14:51:33] Found some remnants of SimpleAGC :P [14:54:51] oh haha [14:55:56] I thought the ForceRestart was for Apollo 13 [14:56:02] but maybe we removed it [14:56:17] That whole variable isn't being used anywhere [14:56:26] ah we commented it out [14:56:46] hey guys [14:56:54] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_csm/saturn.cpp#L4625 [14:56:58] hey Matt [14:57:35] Well even then ForceRestart won't do anything. It just sets Reset to false.. Which it already is :P [14:58:00] if you thought the DSKY color debate was bad, wait until people start in on the flood light color temperature :) [14:59:54] Can't wait [15:03:31] n7275: How can I easily make the IMU very hot? [15:14:01]