[21:26:24] NASSP Logging has been started by n7275 [21:26:29] Guenter! [21:31:37] Huh why did he leave [21:47:22] thewonderidiot: I have concluded that simulation in Quartus is permanently broken. Are there any standalone simulators that support VHDL that you can recommend? [21:47:49] I've only used Icarus Verilog.... whose name suggests that it might not do VHDL [21:47:56] I've never used VHDL, so I'm not sure [23:17:24] Allegdly Icarus Verilog has a VHDL preprocessor. I might test it out [06:22:46] Hey good morning/evening [11:31:44] He [11:31:45] y [11:38:25] How are things goind? [11:38:30] *Going [11:40:04] Pretty good. Doing some scripting to take a set of directory names from a CSV and creating the dir + share URL in Nextcloud [11:43:14] Interesting [11:44:44] There is scouting event this weekend and they want to give each group a QR code to a Nextcloud filedrop so they can hand in media files that gets dropped in a folder with their name so the jury can view it. [11:45:06] Nice combination of bash, curl, awk and qrencode to make it work. :) [11:46:48] awk? [11:46:58] I heard it only once [11:47:08] And I heard that only gods can use it [11:47:10] :D [11:47:28] It's quite versatile [11:47:28] Sounds fun [11:47:55] This one shows it quite well https://github.com/patsie75/awk-demo [11:48:47] I'm only using it to use the comma delmited data from the CSV to format it as a directory name [11:50:33] BRB [12:11:48] Same. Lunch [12:27:27] back [13:01:27] hey guys [13:08:18] Hey Mattew [14:04:30] hey [14:05:26] Hey Indy [14:13:56] how is the countdown going? [14:14:13] Setting up the set [14:14:22] Going nicely [14:14:40] I am 2000 times better prepared this year than on last year [14:16:03] when are you launching? [14:16:47] 7:51 CEST, may 18th [14:17:13] That is 5:51 UTC [14:17:18] good time, I'll be there I think [14:17:28] Early :D [14:19:36] I had a question about the crew egress after splashdown. I think I have it solved. They had to wait for sunrise right? It was too dark. I think, if my source is accurate (Transcriptions from PAO), that the crew egressed at 12:04 Houston time, that is around the hour 148 [14:19:53] I assume after the sun went up and visibility was good... [14:22:25] postlaunch report has [14:22:29] 10:52 EST landing [14:22:38] 11:48 flotation collar installed and inflated [14:22:45] 12:20: astronauts onboard recovery ship [14:22:52] 13:18 CM onboard recovery ship [14:24:53] "At 11:04 Houston time we received the report the hatch was open." [14:26:14] so at about 149h GET I guess? [14:26:37] lol, all these time conversions [14:26:58] landing was at 147h GET, that is sure [14:27:11] so at 148h, not 149 [14:27:55] so yeah, egress about an hour after landing, maybe a bit more, seems right [14:30:35] Yeah, must have taken the 12:04 wrong [14:30:44] 11:04 makes much more sense [14:30:56] As per the 148h [14:35:54] This wold be: [14:35:55] 10:52 EST landing, (147:01 GET), 11:48 EST Flotation collar installed and inflated (147:57 GET), 12:04 EST Hatch Open (148:13 GET) [14:35:59] Correct? [14:37:47] yeah [14:38:47] Be back in around half an hour [14:46:26] I think when I get these lights merged I'm going to do a deep dive into rewiring some stuff [14:48:52] I don't like making "controller" classes that just check the position of a switch. [14:56:40] ah you put the PR up, I'll take a look [14:59:31] why are you converting VESSEL* to OBJHANDLE and then when it gets used in the electric light class back to VESSEL? [15:08:28] oh whoops [15:08:47] I probably shouldn't do that [15:10:32] yeah VESSEL pointer should work fine [15:17:26] I'm fairly certain that I'm freeing the right memory on those but not 100% sure [15:21:25] what memory needs to be freed? [15:21:33] electricLight* newLight = new electricLight [15:21:35] from this? [15:29:40] need to dig into the API reference a bit more, but I'm pretty sure you have to call the oapi deleteLightemitter and it does some internal directx freeing [15:31:08] I'f I don't do that I get crashes on exist sometimes, and extra phantom lights showing up if I relaunch without closing first [15:31:45] calling those delete functions in the electric light destructor seems to fix it [15:32:28] electriclight itself should get deleted by pannelSDK on exit because it's an e_object [15:32:56] yeah [15:35:48] Hey guys [15:36:13] Do you recommend this for fixing the "pixelated" clouds on LEO/EPO? https://www.orbithangar.com/showAddon.php?id=abfd8649-ea3d-42c9-8e1c-6155d0e0e9d6 [15:36:51] hmm, I don't think SSU is calling the delete functions [15:37:01] DelLightEmitter or ClearLightEmitters [15:37:18] TurryBoeing, never tried it [15:37:56] Me neither, but my clouds are a little weird. Some viewer "complained" during 7 [15:41:06] These are my settings. Maybe something to improve ? https://prnt.sc/a4F9_dtvvP0j [15:41:15] n7275, for your new light class, the position is kept in the class itself, right? [15:41:24] Then it will need a function to be shifted [15:41:31] LightPosition [15:41:41] which will need to be called from [15:41:44] Saturn::UpdateMassAndCoG() in saturn.cpp [15:57:24] should I put the position somewhere else? [15:57:44] nah I think it's fine [15:57:53] often the VECTOR3 for the position is directly in the vessel class [15:57:57] it just can't be a constant [15:58:25] and the function you need to add gets the CG shift, so not total CG [15:58:33] function(-CoGShift) [16:15:28] okay [16:17:25] what's the best way to work out their initial positions? [16:20:53] the mesh is shifted by 24.538 meters from the CSM coordinate system [16:21:08] so I am calculating the CG in CSM coordinates and then apply the 24.538 meters [16:21:22] so you should also figure out the position in the CSM coordinate system [16:21:34] and then subtract 24.538 meters [16:22:10] aha! [16:22:14] systems handbook [16:22:19] has "SM axis +X location" [16:22:35] those are exactly the numbers we need [16:22:47] they are in inches of course [16:23:00] with that you can easily get the +X axis position [16:23:12] morning! [16:23:15] you probably already figured out Y and Z [16:23:16] hey [16:23:29] and of course the coordinate system in Orbiter is different [16:23:58] Hey thewonderidiot [16:24:05] n7275, drawing 11.2 on the left side [16:25:54] okay cool. that should be fairly easy then [16:27:31] they're in a rough placeholder spot for testing color/intensity at the moment. easy to move. [16:58:06] Installed the addon said above, seems to work [16:58:23] Just got one more question, Houston [16:59:34] What was or final statement on the LM/CM DV valve position? [16:59:53] (Tunnel vent valve) [17:00:03] Off or LM/CM DV ? [17:18:54] I'd go with off [17:18:59] and never touch it again [17:20:04] Off on prelaunch and no touch? [17:20:07] I agree [17:20:25] I believe it´s what we thought, but couldn´t remember [17:23:40] on missions with docking equipment it's also off until the backup crew procedures [17:24:22] and I hope you aren't actually landing the CSM on the Moon :D [17:30:57] I havn´t decided yet [17:31:25] would make the mission and especially the day in lunar orbit shorter [17:31:30] Been told stories about the beauty of the moon, and that it can tempt you... [17:31:54] indy91 but then we lift-off, no? [17:32:11] yeah just start P12 in the CMC [17:32:18] Touch and go [17:38:45] donation goal [17:38:53] for landing :D [17:45:30] Guys! Going to bed [17:45:32] :) [17:45:35] See you! [17:45:42] cya! [17:56:41] hahahahahaahaha [17:56:58] Marc just got specification documents about the Central Timing Equipment from NARA [17:57:10] and it has way more environmental requirements than I expected [17:58:06] (j) Hail: Hailstone accumulating to a maximum depth of 2.0 inches on horizontal surfaces in 15 minutes having an average diameter of 0.3 inches, a density of 50 lbs/ft3 and a hardness of 3 on Mohs' scale. Impact velocity shall be based on a fall rate of 100 ft/sec maximum, with a wind speed of 33 ft/sec maximum. [17:58:17] wtf were they doing to this poor box? it goes inside the CM! [18:06:09] astronauts throwing the CM out of the hatch while they are on the chutes? :D [18:06:15] the CTE* [18:17:03] but to be fair, those requirements will be driven by CM landing, water splashdown or not, more than anything else [18:17:46] still [18:17:47] hail [18:17:48] lol [18:19:40] yeah lol [18:19:47] I mean there's plenty of shock and vibe requirements as well [18:20:13] sea spray.... 4 explicitly listed types of fungus... but hail? [18:53:57] Florida has some weird weather [18:54:27] but still... [18:56:27] very odd [19:10:28] https://www.orbiter-forum.com/threads/orbiter-screenshot-thread.8/post-595014 [19:23:18] NASSP on Linux, nice [19:26:41] could our connector classes have problems with Linux? Maybe the command for S-IC/S-II sep isn't coming through [19:30:19] probably [20:24:57] night! [20:34:58] Wow! That's neat! [20:35:17] Obviously this is running in Wine. Connectors, and telemetry are Windows only. [20:35:26] Probably other things too. [21:14:01] someone did just get a Linux build working I thought [21:40:03] https://www.orbiter-forum.com/threads/linux-playground.40476/ [22:35:20] thewonderidiot, did you find any light documentation? [22:35:38] haven't had a chance to look through my CSM box, but will do so as soon as the work day is out [22:49:48] do you know how much, if at all, the lights differed between Block I and Block II? [22:49:55] (did Block I even have the lights?) [22:55:51] not sure about Block I vs II. the extent of what I know is that they were wired to the same thing for CSM-104 and CSM-114, at least as far as the wiring diagrams in the systems handbooks can be trusted [22:58:07] hmmm okay [01:23:56] n7275: no luck -- nothing unscanned that mentions lights in the CSM box [01:32:37] darn [01:41:27] well thanks for looking [11:16:54] .ask indy91 I've pushed my dsky changes to NASSP/agc. I'm having trouble finding out why the DSKY can't resolve the symbols for LEM_LCA in Saturn5NASP and Saturn1b. I've played with pretty much all the linker options I can think of and am a little out of ideas. Could you take a look to see what's wrong? [13:12:48] Thymo, I think the circuit breakers you added wiring for should be connected to specific phases of the AC busses rather than the bus itself [14:59:35] hey [15:00:57] sure [15:07:11] it's probably not a good idea to directly connect the LCA to the DSKY though [15:07:36] DSKY should have no LM or CSM specific stuff like that [15:12:39] Thymo, GetAnnunVoltage needs to be a virtual function if you don't include the lm_eps files in the Saturn projects [15:12:48] then it builds [15:38:02] hey Niklas [15:38:06] hey hey [15:39:36] yesterday evening I did a very rare rendezvous procedure, calculated with my new DKI processor. Still working on it. I thought I was nearly done, but there are so many details that still needed work. [15:39:47] one thing I need to check, the CSI burn didn't go well [15:40:04] when I started P33 it came up with a TPI slip time of 16 minutes [15:40:07] oh that's kind of an important one [15:42:37] with this procedure CSI burn was 370 ft/s, 18 seconds [15:42:42] and a quite high altitude rate [15:43:01] so I wonder if the finite burn time is a problem there [15:43:17] but I also had VHF ranging errors larger than normal, so could just be the state vector [15:47:51] but P32 did come up with a good solution [15:47:57] even if the burn wasn't great [15:48:14] so the RTCC calculated phasing burn was good, which is all I wanted to see [16:17:16] uh oh [16:17:32] I think I just found a bug if both Apollo 8 MCC-1 and 2 are being scrubbed [16:18:04] which is likely to affect Turry [16:23:45] morning! [16:23:52] uh oh, what is the bug? [16:24:55] LOI time never being calculated [16:25:01] which is used to schedule MCC events [17:15:16] it was a very different bug, but the exact same variable caused the issue he had in his last Apollo 8 attempt using NASSP 7 [17:28:42] what are the chances of that haha [17:42:36] indy91: You can move that block outside of if (scrubbed) now can't you? They're identical. [17:45:20] not quite the same [17:46:14] scrubbed && fcn == 20 [17:46:21] notscrubbed && fcn == 20 or 21 [17:46:39] so basically, it doesn't update the LOI time if it is the MCC-2 calculation and it's getting scrubbed [17:46:46] but do I want that... [17:46:56] yeah I think I want that [17:47:06] MCC-3 or 4 will be calculated on the basis of MCC-1 data [17:47:20] so the MCC-2 calculation shouldn't update anything if MCC-2 is scrubbed [17:48:40] https://github.com/orbiternassp/NASSP/blob/b73839c5820f8b538cab89148f516f84886ee010/Orbitersdk/samples/ProjectApollo/src_launch/RTCC_Mission_C_PRIME.cpp#L461 [17:48:41] https://github.com/orbiternassp/NASSP/blob/b73839c5820f8b538cab89148f516f84886ee010/Orbitersdk/samples/ProjectApollo/src_launch/RTCC_Mission_C_PRIME.cpp#L472 [17:48:49] Both those blocks are identical. [17:49:57] You don't want insert LOI time on a non-scrubbed MCC-2? [17:50:15] s/non-// [17:50:19] correct [17:51:53] I think that is slightly closer to the procedures they would have done there [17:52:30] So (fcn == 20 || (!scrubbed && fcn == 21)) [17:52:46] Meh. Probably warrants a little duplication over being easier to understand the condition [17:53:11] yeah. I had thought about moving the block to a separate one, but for now it's ok as it is [17:53:29] if anything more gets added to both scrubbed and not-scrubbed blocks I'll probably make it some common code [17:53:49] Agreed, sounds good. [18:47:31] I also want to adjust the Apollo 8 criteria for MCC-3 and 4 [18:48:10] if Turry didn't do that extra burn then MCC-1 and 2 would be scrubbed, but likely not MCC-3 [18:48:14] and then MCC-4 is near 0 [18:48:30] there are no criteria to scrub MCC-4 really for Apollo 8 [18:48:40] but it does says "trim residuals to 0.2 ft/s" [18:48:49] so I think I'll just use the 0.2 as the threshold [19:54:44] Okay I'm confused why marking that function virtual works exactly. Obviously I have some stufying to do on how the virtual table is being used by the linker [19:59:26] all I know is, that across dll modules you need to use virtual [19:59:35] like interaction between mobile launcher and Saturn for example [19:59:48] I only know it works, not sure why or if it's the best way :D [20:01:13] Okay, found something. If you mark it virtual a pointer to the function is retrieved from the VTABLE at runtime. If you don't mark it virtual the address of the function is resolved at compile time but obviously that won't work for DLLs. [20:45:16] This answer gives a decent explanation https://stackoverflow.com/questions/56247091/why-invoking-class-method-from-dll-requires-virtual-specifier/56247949#56247949 [20:49:12] ah nice [20:51:30] good night! [13:32:31] hey [13:36:57] hey [13:37:08] what's up? [13:49:20] Went home ealy from college. Massive thunderstorm. I should have left 2 minutes earlier, got back soaked lol [14:58:14] hey [14:59:00] hey Matt [15:00:42] Hi [15:05:39] MCC bug successfully avoided [15:06:41] should hopefully be the only problem of that sort [15:25:07] nice [15:25:38] I got my lights to shift with shifting cg last night [15:30:00] ah so each of your lights has a spotlight and a beacon [15:30:01] I need someone to add a little animated spotlight door now. [15:30:26] yes [15:32:35] weird that you need to treat spotlight and beacon differently with the CG location [15:32:48] that made it slightly more complicated because one of them has a *VECTOR3 position, and the other one is created by passing in a const reference [15:35:38] hmmmm [15:35:43] looking at the Orbiter code [15:35:55] spotlights seem to be managed by ShiftCG?? [15:36:25] so I don't think you need to manually call SetPosition even [15:36:33] it might work without [15:36:57] the LightEmitter class is what Orbiter manages [15:37:06] so AddPointLight and AddSpotLight [15:37:37] I'll do some more testing. it's a lot easier to see the beacon moving [15:39:31] there are some confusing notes in the API reference that made me think I needed to [15:40:54] yeah, and the Open Orbiter version is slightly modified from the last Beta I think [15:41:08] so not guaranteed that it actually works [15:42:06] openorbiter is going in so many directions... [15:44:16] there is a GetPosition function you can call [15:44:19] to check on the position [15:44:32] if that changes with a CG shift then we are good and you don't need to call SetPosition [15:44:50] is openorbiter going in many directions? I'm not really seeing it going anywhere. Just ideas [15:45:22] almost better than having 10 forks that become impossible to merge together at some point [15:46:55] well, that's what I meant. the ideas are all over the place. as long as what just happened to SimH never happens, I'll be happy though. [15:47:40] googles SimH [15:53:09] the current maintainer added a feature that no one wanted. people asked him to change it slightly. he added a clause to the mit-like license, saying no one is allowed to fork and change the feature... [15:53:20] and everyone jumped ship [15:54:36] how to remove yourself from a project in 4 easy steps [15:56:15] LOL! [15:56:35] So what do people do? Revert to a commit before the license change and fork from there. :P [16:02:52] yep [16:05:33] the IBM7094 and 360 emulators that I use, come from one of the "good guys" in that mess. so development will continue thankfully [16:07:07] imagine if someone would decide our DSKY should be pink [16:07:12] that would warrant a fork, too [16:08:34] hey gondos [16:08:38] hi [16:08:56] I need some help with apollo5 mission [16:09:27] how so? [16:10:00] did I break it again [16:10:54] we have two scenarios, one is cold and dark and one is at T-60 seconds. [16:11:03] which one causes problems? [16:15:23] sorry, got interrupted IRL... [16:15:35] I try the T-60s but it crashes [16:16:29] null pointer exception on vessel2->dock [16:16:55] but I see no docking point declared in nsat1stg1.cfg [16:17:04] so I think it's normal that it crashes... [16:17:11] interesting [16:17:14] I'll have to try it [16:17:25] I'm in linux though so it may explain the problem :\ [16:17:34] oooooooh [16:17:40] so about that [16:18:17] there are also docking ports only declared in code [16:18:35] we do a lot of inter-vessel communication with the windows, SendMessage() function [16:18:37] ah, interresting [16:19:16] via winsock you mean? [16:19:57] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendmessage [16:20:32] strange, I had no compile problem with that, I'm on the Orbiter2016 branch BTW [16:20:35] does the scenario crash when you load it? [16:20:39] or during launch [16:20:47] when I load [16:20:59] a better method would be to overload the Vessel classes a clbkGeneric() [16:21:18] Apollo 11 work for exemple [16:21:21] and which dll has the exception? [16:21:35] Apollo 5 uses stages docked together [16:21:48] and they talk to each other with the connector classes [16:22:10] ok [16:22:15] it crashes in the core [16:22:20] SuperVessel.cpp [16:22:21] Vector as(vessel2->dock[port2]->dir); [16:22:25] dock in nullptr [16:22:34] I see [16:22:35] vessel2->dock I mean [16:22:50] might be something we can change for it to work on Linux [16:22:55] sorry, have to go for a bit [16:22:57] and I see CreateDock is not called on the S-IB-4 vessel [16:23:38] I'll look around the connector stuff to see if I can work something out [16:23:41] thx [16:27:35] Are the MFDs necessary for it to work BTW? I don't know how to use them and I see no socket trafic going on during a launch^^ [16:38:23] :facepalm: [16:39:15] nah, none of the MFD are essential for the simulation to work [16:39:17] CreateDock was not called because I did not add s1b.cpp in the module [16:39:29] although the Checklist MFD does also use the connector class I believe [16:39:32] what a booboo^ [16:39:38] that'll do it haha [16:39:40] now it starts [16:39:51] oh you already did a bunch of code changes to make it work? [16:39:53] but the rocket wobbles on the pad [16:40:21] yes, mostly the socket API and lots of DWORDs to change [16:41:49] oh I just saw something in the screenshot thread. What Thymo said was partially wrong, the tower is not jettisoned automatically [16:41:59] yeah I figured it out ;) [16:42:07] it's only automatic when you do a Mode 1 abort [16:42:18] then the tower gets jettisoned when it's time for the chutes [16:42:28] that's what the auto position of the switches is for [16:42:39] I watch some videos on youtube and noticed some fidgeting with aborts nobs [16:42:55] morning! [16:42:59] but if staging doesn't work, the command for that goes through, you guessed it, the connector class [16:43:02] hey Mike [16:43:55] but since I got cheap and shared meshes instead of copying them in the graphics client, the offset added during stage separation messes with the camera in the VC and I can no longer flip switches^^ [16:44:04] morning [16:44:35] the staging is fixed, it was some CRLF problem in the config files, same old problem... [16:45:37] apollo 5 still gogin strong T+420s :) [16:45:43] *going [16:46:02] is it a suborbital mission? [16:46:21] not if things go as planned... [16:46:47] arf [16:46:51] there are suborbital abort modes the LM can do [16:46:55] but not normally :D [16:47:40] if you get Orbiter and NASSP working on Linux I will never use windows again [16:48:49] lol, it's on the way ;-) [16:48:58] just missing a good Graphics Client [16:49:17] and pushing some stuff in main will be a problem I guess [16:49:55] it pains me so much to see all the winapi stuff that's being used and that will break every mods [16:50:21] but I hope we can do something when goind 64bit because it'l break every binaries anyway [16:50:51] ok, got MECO [16:51:04] 163x238 orbit [16:52:01] that sounds right [16:52:08] that is kilometers I hope, not nautical miles [16:54:53] yep:) [16:56:06] a shame I don't have a windows box because I could push some PRs with moving GDI to sketchpad in NASSP [16:56:08] hopefully it can get rid of the nosecap and that isn't a Windows only feature [16:56:41] but right now everything does not line up and I don't know if it a bug on my side... [16:59:03] BTW, how di you reverse engineer the RTCC stuff? [16:59:19] I felt your pain going through all the gotos^^ [17:00:13] looks like assembler rewritten in C... [17:00:13] oh that is me foolishly trying to implement flowcharts for RTCC equations I have [17:00:21] ah, I see [17:00:32] hehehe [17:00:43] I should stop doing it. But whenever I find a new document I think "great, I can implement this 1:1" [17:00:55] just so you know, g++ does not allow declaring variables across goto labels [17:00:58] and likely, in Fortran, they did implement it that way with lots of goto [17:01:20] had to move every declaration on top of the function, it's even less readable now, lol [17:01:27] oh no [17:01:38] yeah I can at least avoid doing that in the future haha [17:02:26] anyway, that's a nice piece of work you've done :) [17:03:12] thanks! [17:03:16] lots of lines of code... [17:03:27] this is from a Shuttle document, not RTCC, but you get the idea: https://i.imgur.com/V1rQeBY.png [17:04:12] three do untils within each other [17:04:22] and you bet there are some gotos in there, too [17:04:55] yeah, I saw a video once, the guy was saying "the diagram *is* the source code" ^^ [17:07:02] if we had actual RTCC code we could run it as a black box and not worry about it using bad code from a modern point of view [17:07:26] Had one last question as I wrap up the first round of the failure code. Currently I have it in the MFD refresh function. For obvious reasons it should actaully be in timestep. This uses "g_Data.progVessel->MainPanel.SetFailedState("system", 1, 0);" It looks like it would require MainPanel to be public instead of protected? [17:07:29] but in like 80% of the cases I should not have used it [17:08:52] which timestep is that? Often we have avoided the public/protected thing by adding a new class as a friend class in the Saturn class [17:09:01] not sure if that is really a good solution though [17:10:53] The PAMFD timestep. I could also just stick it in the individual vessels (not sure where would make sense) and have PAMFD save and load the failure rate. Just not sure how to get the vessel to read a PAMFD var [17:11:57] what you could do is add a public function in the Saturn class [17:12:07] and that calls MainPanel.SetFailedState [17:12:15] probably the best solution really [17:24:06] I wonder if we could link gfortran and g++ objects... [17:24:25] I don't see why not [17:25:24]