[12:16:57] NASSP Logging has been started by gondos [12:16:59] I can ;ake it generate more sensible code but I had to revert to templating the classname [12:17:05] so it looks like this : if(utils::IsVessel(this)) [13:08:13] Gondos, "I haven't checked the generated assembly" me neither, as in, never :D [13:08:27] but you finding some good bugs with your advanced debugging methods haha [13:09:39] lol [13:09:59] it is the only way to check if it's worth going further :p [13:32:21] indy91 csm_cue-cards.pdf page 22 "MANUAL TLI" is missing in the cue card scans [13:38:20] Apollo 15 maybe didn't have that card [13:38:40] yeah I think that is the case [13:38:44] they made changes to P15 [13:38:51] so it wasn't just a backup program, but used any time [13:39:28] so so there aren't any manual TLI specific procedures required anymore [13:39:50] but of course that also means the Apollo 15 cue card is only really usable for 15-17, sigh [13:41:25] Apollo 14 is even worse though [13:41:39] the procedures on the Manual TLI card would only be usable with the Apollo 14 software [13:41:43] which we don't have anyway [13:42:22] there are also many differences between the scans and the csm_cue-cards.pdf [13:43:04] I have so many cards that I can't position because I don't know where they belong [13:44:51] LAUNCH_ABORT_PAD where does he have to go? its position is marked outside the panels [13:47:21] one a floodlight apparently [13:47:24] but where is that floodlight haha [13:47:59] for the position of the others, we have that cue card document for Apollo 17 [13:48:03] should be very similar to 15 [13:48:39] https://www.ibiblio.org/apollo/Documents/apollo_17_csm_cue_cards_rev_a.pdf [14:24:32] 13 left for positioning [14:25:02] indy91 try it https://www.dropbox.com/s/bfhyp2k6buzjne7/ProjectApollo.7z?dl=0 [14:27:25] Should be a good test how scalable my code for this is haha [14:27:56] so hopefully a quick job to add these to the system [14:31:26] if you have problems, change the two lines in the mesh files above TEXTURE [14:31:45] with this 2 lines [14:31:48] 1.000 1.000 1.000 1.000 0.000 [14:31:51] 0.700 0.700 0.700 1.000 [14:33:32] that's the orientation or location? [14:34:20] emission and specular colors [14:34:23] aaah [14:34:53] with my system right now you define the default cards in code, but mission specific ones in the mission files. [14:35:04] So after this gets merged the process to e.g. add a mission specific TLI card is [14:35:10] just add mesh and texture [14:35:20] and then add a line in the config file for the mission [14:35:25] so no code changes required [14:36:43] sounds good. this makes it easier to expand [14:37:13] yeah. Disadvantage as you said, going to be a lot of files with the mission specific ones [14:37:17] hmm [14:37:25] the cards appear nearly black in-sim [14:37:47] change the lines as i sayd [14:41:27] yep that worked [14:41:33] new problem [14:41:42] SPS burn cue cards are too far left or so [14:41:52] you can barely see the FDAI rate needle [14:43:39] how far should it go to the right [14:44:04] could it also be a size problem? [14:45:12] hmm [14:45:18] all the way to the DSKY I think [14:45:27] interesting issue [14:45:41] I think you never have these cue cards up at the same time as the long TLI one for example [14:46:28] you can basically line it up with the velcro spots in the simulation [14:46:36] with the SPS burn cue card [14:46:49] it has three spots on the left side [14:47:03] if you turn it around, those go on the three spots next to the DSKY I think [14:49:14] but there is a gap for the mission timer, i think it should be centered. I don't know how accurate the velcros are in the nassp texture [14:49:44] MSHX1 [14:49:46] GROUPS 1 [14:49:47] LABEL SPS_BURN_CONTINUED [14:49:48] MATERIAL 1 [14:49:49] TEXTURE 1 [14:49:50] FLAG 0 [14:49:51] GEOM 4 2 [14:49:51] -0.6014 0.4851 0.2830 0.0000 -0.0000 -1.0000 0.0000 1.0000 [14:49:52] -0.4558 0.4851 0.2830 0.0000 -0.0000 -1.0000 1.0000 1.0000 [14:49:54] -0.6014 0.6798 0.3481 0.0000 -0.0000 -1.0000 [14:49:55] -0.4558 0.6798 0.3481 0.0000 -0.0000 -1.0000 1.0000 0.0000 [14:49:56] 0 3 1 [14:49:57] 0 2 3 [14:49:58] MATERIALS 1 [14:49:58] SPS_BURN_CONTINUED [14:49:59] MATERIAL SPS_BURN_CONTINUED [14:50:00] 0.800 0.800 0.800 1.000 [14:50:01] 1.000 1.000 1.000 1.000 [14:50:04] 0.800 0.800 0.800 1.000 [14:50:06] 1.000 1.000 1.000 1.000 [14:50:06] 1.000 1.000 1.000 1.000 0.000 [14:50:07] 0.700 0.700 0.700 1.000 [14:50:08] TEXTURES 1 [14:50:09] ProjectApollo\VC\CueCards\SPS_BURN.dds [14:50:09] try this [15:01:31] is this SPS_BURN or SPS_BURN_CONTINUED [15:01:45] the texture name is SPS_BURN there, rest is CONTINUED [15:02:56] SPS_BURN.msh -> [15:02:58] MSHX1 [15:03:02] GROUPS 1 [15:03:03] LABEL SPS_BURN [15:03:04] MATERIAL 1 [15:03:04] TEXTURE 1 [15:03:05] FLAG 0 [15:03:06] GEOM 4 2 [15:03:07] -0.6002 0.4845 0.2826 0.0000 -0.0000 -1.0000 0.0000 1.0000 [15:03:07] -0.4542 0.4845 0.2826 0.0000 -0.0000 -1.0000 1.0000 1.0000 [15:03:08] -0.6002 0.6791 0.3477 0.0000 -0.0000 -1.0000 [15:03:09] -0.4542 0.6791 0.3477 0.0000 -0.0000 -1.0000 1.0000 0.0000 [15:03:10] 0 3 1 [15:03:10] 0 2 3 [15:03:11] MATERIALS 1 [15:03:12] SPS_BURN [15:03:13] MATERIAL SPS_BURN [15:03:13] 0.800 0.800 0.800 1.000 [15:03:14] 1.000 1.000 1.000 1.000 [15:03:27] SPS_BURN_CONTINUED.mesh -> [15:03:29] MSHX1 [15:03:30] GROUPS 1 [15:03:30] LABEL SPS_BURN_CONTINUED [15:03:31] MATERIAL 1 [15:03:32] TEXTURE 1 [15:03:33] FLAG 0 [15:03:34] GEOM 4 2 [15:03:34] -0.6014 0.4851 0.2830 0.0000 -0.0000 -1.0000 0.0000 1.0000 [15:03:35] -0.4558 0.4851 0.2830 0.0000 -0.0000 -1.0000 1.0000 1.0000 [15:03:36] -0.6014 0.6798 0.3481 0.0000 -0.0000 -1.0000 [15:03:36] -0.4558 0.6798 0.3481 0.0000 -0.0000 -1.0000 1.0000 0.0000 [15:03:37] 0 3 1 [15:03:38] 0 2 3 [15:03:39] MATERIALS 1 [15:03:40] SPS_BURN_CONTINUED [15:03:40] MATERIAL SPS_BURN_CONTINUED [15:03:41] 0.800 0.800 0.800 1.000 [15:03:42] 1.000 1.000 1.000 1.000 [15:03:43] 1.000 1.000 1.000 1.000 0.000 [15:04:12] the texture name is also the mesh name [15:04:19] yeah [15:05:38] copy paste in the corresponding msh file, overwrite the entire file [15:05:46] yep, got it [15:06:39] I think the event timer is not necessarily centered [15:06:41] https://www.flickr.com/photos/projectapolloarchive/21672887342/in/album-72157659052908231/ [15:06:54] the velcro spots on the backside go on the spot next to the DSKY [15:07:14] so the card has to go at least halfway over the three spots left of the DSKY [15:07:30] because thats where they are attached [15:08:55] the cards use the same font, i think i have to adjust the textures so that the text is the same size, then i can position them better [15:09:25] if it helps, I can push an update to my branch with all your meshes and textures and default cards [15:09:41] then you can work in that branch and better see where the cards are in-sim [15:13:21] you can do it, but it doesn't have to be. I have a blender file with the panels, position the cards there and export them individually as a mesh. works quite well. [15:17:36] ok [15:18:16] but yeah, as you can see in the photo, the card goes on top of the three velcro spots on the left of the DSKY [15:18:35] not the best perspective for the photo though [15:22:47] or maybe the card is even larger? [15:24:45] Yes, I can use the velcros on the nassp texture as reference points. The scans all have the same font size, at least the one pdf file with most scans, so I don't have much work to do. I can also use the photo as a size reference. But you also have to consider the gap. [15:25:56] true [15:26:17] the gap is wider than the event timer and I don't think it is centered on the timer [15:26:19] so it should work out [15:28:59] to quote some AGC code comment: "I HOPE HOPE HOPE" [15:29:50] a bunch of cue cards need position adjustments it seems [15:30:40] https://i.imgur.com/veoSA9e.png [15:31:00] nice to see the LV lights, but I don't think they work without a S-IVB :D [15:32:01] you can send me the adjusted and missing meshes in one set later [15:32:19] posting the contents of meshes in here is not very efficient haha [15:32:36] I have some clickspot work to do now anyway [15:34:00] and I'll take a look where that launch abort PAD would go [15:51:40] hey guys [16:01:39] hey Matt [16:38:56] I figured out why I'm chacing my tail so hard on H2 tank temps....some part of the telemetry scaling is a bit off [16:39:26] oh no, I'm sorry! [16:39:35] s/chacing/chasing [16:39:36] did we get the scaling fix wrong? [16:39:41] or just some numbers [16:40:02] I'll always trust a debug string above an 8 bit telemetry word... [16:40:18] oh yeah. lesson learned, haha [16:40:53] the client is saying -380, when tank temps are at a much more reasonable -411 [16:41:21] I'm going to put an issue up on github as a reminder [16:41:41] yeah, I'll track that down [16:41:44] Other temperatures seem okay, I think it's just Hydrogen [16:43:57] ok [16:45:38] scale is -425 to -200 °F [16:46:20] it's handled with sensors [16:46:27] H2Tank1TempSensor("H2Tank1-Temp-Sensor", -425.0, -200.0), [16:46:33] correct so fa [16:46:36] r [16:47:30] showTempF( eps_form->s10A60, data, -425, 200 ); [16:47:34] 200 instead of -200 [16:47:41] so wrong in the client [16:49:17] ahh okay. that explains why it was more right at the beginning of the mission [16:51:05] I have a tank temperature calculator (spreadsheet), that I'm considering including in a future commit here. it makes setting up scenerios and config files a bit easier. [16:57:01] sounds useful [17:04:01] ok, found some clickspots for all the cue card locations on the left side of the CSM panel [17:05:18] morning! [17:06:17] hey Mike [17:10:24] so what do you say Mike. What movements did the RR make during Apollo 11 PDI [17:11:08] hahaha that is an excellent question [17:12:02] was auto tracking Columbia [17:12:11] 10° yaw right before PDI, still tracking [17:12:28] tracking all the way shortly before the start of the 180° yaw at PDI+3min or so [17:12:34] to shortly* [17:12:39] then switch to slew [17:12:45] still showing signal strength [17:12:52] 180° at 4°/s [17:13:04] RR kept inertial, so quite the maneuver for it in... shaft [17:13:06] I think [17:13:19] but CSM to LM relative direction moved because of LM slowing [17:13:25] didn't see any signal strength anymore [17:14:05] if it kept inertially tracking all the way to touchdown it roughly points backwards after landing, instead of upwards as before PDI [17:14:54] "so quite the maneuver for it in... shaft" actually, I haven't looked at this yet [17:15:03] might not do that with the correct behavior [17:15:14] my first implementation was only working for mode I and II [17:15:25] not so good in-between [17:17:59] I really should get the specs for the RREA and RRAA from the national archives and see if they have movement specs [17:22:19] that would be very interesting to see [17:22:33] silly question -- I assume they stowed the RR after landing and before the EVA? [17:25:18] yeah, thermal stow position [17:25:55] ah well [17:26:04] first to the position where it isn't in the way for the AOT [17:26:17] 0° trun, 283° shaft [17:27:10] after the P57 to 180°, 270° [17:27:16] so pointing up [17:27:19] in mode II [17:28:37] I guess on the surface it was unpowered and at 180°, 270° for the most part [17:28:48] 0°, 283° for the P57s [17:30:11] https://www.flickr.com/photos/projectapolloarchive/21472310108/in/album-72157658601662068/ [17:30:15] like that, pointing up [17:32:35] right, gotcha [18:33:46] indy91 can you check this https://www.dropbox.com/s/6tjucdei64d6kug/Orbiter.7z?dl=0 [18:36:24] a bunch of mesh updates? [18:40:11] Have all repositioned. Is not difficult. Blender can import images directly as a mesh. [18:43:09] The problem is positioning. Since the pdf does not always show which cards are where. There are other terms used. That's why I left out some because I don't know where they are. [18:44:07] yeah, we will figure those out eventually [18:44:27] Also, the size and shape of the cards does not always correspond to that in the pdf file. [18:44:49] yeah that's a bit strange [18:44:55] I think the velcro spots in NASSP are pretty accurate over all [18:45:10] so at least in some cases you could measure the cards by their backside and the velcro [18:45:45] burn cards are great now [18:45:48] SPS* [18:46:08] What I don't know either, how are the backs positioned? The velcros don't fit. [18:47:16] I think they do fit [18:47:24] definitely for e.g. the SPS burn card [18:48:32] some specific issues [18:48:33] PRE-ENTRY_ATTITUDE_TIMELINE [18:48:53] hasn't been positioned yet. Also, I wonder if they didn't flip down the upper part [18:49:03] which has entry procedures on the backside [18:49:16] because when correctly positioned it would be above the EMS counter [18:49:18] not ideal [18:49:19] Look at the most left one. Its like a triangle, if you turn the backside the tra [18:49:29] Triangle doen [18:49:41] Doesn't match. [18:50:19] which card? [18:50:59] The most left one. Something with CDR. [18:51:20] Im on my mobile, can't tell the right name [18:51:50] ah [18:51:52] CDR_MAN_P_BACK [18:51:56] Yes [18:51:57] haven't even checked that one yet [18:52:16] could be a case where the velcro doesn't match. It's definitely not 100% in our cockpit [18:53:08] I haven't even found where they put that :D [18:53:14] The velcros are there in the Cockpit [18:53:45] oh above the left master alarm, I see [18:53:47] In put it there because this is the only spot it matches [18:54:21] yeah that one might not perfectly match, haven't gotten there yet [18:55:31] This are the ones that i know were to put, but don't know how to match them exactly. [18:55:51] The others i left out, i have no idea werde [18:55:58] Were to put them. [19:39:23] yeah I'm going through the spots step by step [19:39:35] last one I added so far was above the fuel cell meters, top right [19:40:07] and I am working my way down [19:40:37] let me work on it for a while, I'll come back to you with a list of things that need changing [19:40:48] or ideas where to put the missing meshes [19:41:56] Ok [19:43:29] good work so far haha. I just wished we had high res Apollo 11 cue cards as the template and not 15 [19:43:50] 11 would just more applicable to the missions we support fully, 7 to 11 [19:44:13] 15 has lower Earth orbit, different program for TLI, SIM bay, CMP doing EVA etc etc [19:55:30] Are there any 11 card's available? [20:04:31] not really [20:04:38] maybe some from auctions [20:04:55] the launch checklist has the TLI cards, at least in their paper version [20:05:02] and boost [20:46:34] up to 25 cards visible in-sim [20:54:01] n7275, -414.33°F is reasonable for H2 temp? [21:27:32] I put up a PR for the telemetry client for that [21:27:37] good night! [16:09:15] hey [17:39:49] morning! [17:48:22] hey Mike [17:57:26] what's up? [17:58:20] cue cards, cue cards, cue cards [17:58:25] and you? [17:58:46] I see a photo of almost half a CSM on Discord [17:59:33] the CTE is something I would also like to simulate... [17:59:57] hehehe [18:00:09] the CTE really isn't doing much so that sounds like a relatively easy project :D [18:01:45] CTE is getting a timing reference from the CMC? Or the other way around... [18:02:35] it gets a timing reference from the CMC, or falls back to its own if the CMC is off [18:02:44] right [18:03:04] we have the procurement specs for it -- gimme a bit and I'll upload them [18:03:07] well I had the idea of a central timing hub in code, which generates function calls at the correct rate [18:03:43] sounds nice :D [18:03:47] eliminating the problem of e.g. PGNS to AGS data transfer requiring a workaround and not working with time accel [18:03:53] and issues like that [18:04:35] of course there are multiple systems providing timing reference, which already makes it difficult [18:06:27] hah yeah, I was laughing about that yesterday [18:06:38] the PMP needs 512kc references from both the CTE and the PCM [18:06:53] but the PCM gets its 512kc reference from the CTE -- which has two 512kc outputs [18:07:11] so for our setup for now we just skipped the middle-man and just connected both 512kc outputs from the CTE directly to the PMP :P [18:08:28] cheaping out on buying a PCM, I see [18:08:59] ah great, I get to completely rewrite how our mission files are read I think... [18:10:06] oh no definitely not cheaping out. we have two Block II PCMs and a Block I PCM in the lab [18:10:26] haha ok [18:10:31] just more difficult wiring then [18:10:45] yup. more things to restore and more harnesses to make [18:12:57] running a mission or event timer with the help of the CTE would be fun [18:17:13] Marc has his wired up to a nixie tube display at the moment [18:25:58] oh great, thanks! [18:30:54] hmm, do I put in some bad code to avoid rewriting the entire mission file loading... [18:31:19] hahaha [18:35:33] bad code it is [18:37:50] because it's already done now :D [18:49:05] that's the nice thing about bad code haha [19:04:43] if I ever try to implement a 17th mission specific cue cards for a particular mission and it doesn't work then I can blame past me for the bad code [19:04:52] card* [20:46:01] hi [20:47:07] Hello :) [20:47:48] I fixed the include path on the classname PR [20:48:26] Yep. I was wanting to play around with that, got distracted by a discussion on Discord. Just fetched your changes. [20:48:29] such a beginners mistake^^ [20:50:17] I think such things happen to everyone once in a while [20:51:40] yeah, but it's really not developper friendly as a default behavior, of course I don't want an absolute path in there... [20:54:38] for the network work I'm factorizing error handling, I think I'm going to add the POSIX version too before switching the draft [20:55:38] for the cuecards PR, will the cards show on the 2D cockpit BTW? [20:56:20] I don't know about the cue cards. I would assume so. That's Nik's little side project. [20:56:40] oki [20:56:56] Your changes made me look into stricmp again and apparent;y they are not portable. I'm testing with strcmp now to see if they map 1-1 [20:58:00] yeah, the comment about non standardness is a joke since the _stricmp is also not portable [21:00:14] same thing with the sscanf_s stuff, the compiler screams but all it does it make code non portable for a dubious security improvment [21:14:59] Yeah all that needs to be replaced with something portable at some point [15:44:34] hey [15:47:44] hey Matt [15:49:37] currently writing up something for a draft pull request for my liquid density model [15:53:06] oh great. hopefully the telemetry error didn't derail you too much haha [15:55:05] not at all [15:55:19] that's a lot of commits [15:56:03] there are duplicates from other branches. will rebase and force push before attempting to PR for real [15:56:10] ah [15:56:22] was about to ask. This seems to include some of your other pending PRs [16:00:35] quite the number of PRs we have open [16:00:50] yes [16:01:00] some drafts by me, Ryan never checking Github to get the MCC one merged lol [16:01:40] the RR one should be done, just a question of finally deciding that it is correct behavior [16:02:11] cue cards are pretty far, too [16:02:38] at least the initial release of it. Doesn't include some boost and TLI cards for most missions yet [16:03:32] for 32 out of 33 cue card meshes Jordan made there are clickspots now [16:03:47] there seems to be one card that only Apollo 15 had [16:03:52] At least 14 and 17 didn't have it [16:04:00] for some manual Saturn V flying [16:05:31] and there are a bunch of textures for which there are no meshes yet, because we don't exactly know where they would go [16:05:41] some SIM bay stuff, probably next to the panel for it [16:28:44] I have a pretty good idea of how to make thrusters draw fuel from two tanks in Orbiter code. haven't got around to testing my idea yet [16:31:33] that would probably be useful for many Orbiter developers [16:50:00] tanks and thrusters are just structs [16:50:15] thrusters have pointers to tanks [16:50:33] so I'll just add a second, optional, tank pointer [16:50:50] and some kind of "mixture ratio" variable [17:05:11] yeah, which needs to be set externally [17:05:22] defaulting to 50/50 or so [17:56:04] morning! [18:07:18] hi [18:18:01] hey guys [19:29:33] hey [16:23:00] hey guys [16:29:11] hey Nik, Jordan [16:29:49] checking my RR branch again, I managed to break gyro stabilization in auto tracking mode, while implementing it for slew haha [16:29:54] fixed now [16:32:08] branch would be ready to merge now... but I'm still looking for more validation that it is a correct change [16:37:34] thinking about it in an a priori sense, is there any good reason for them to have designed it in a way where it *didn't* hold inertial position? [16:38:08] you might want to put the RR to specific angles while the LM isn't perfectly in attitude hold [16:40:08] but you can do that with LGC designate mode I guess. That will also be affected by this change I think [16:40:16] but you are usually using continuous designate [16:40:22] and then pulling the RR breakers [16:40:30] that gets you to precise angles [16:40:44] would the gyros be necessary if it were designed that way? [16:41:23] yes [16:41:40] I always thought their main purpose so to keep auto tracking with attitude maneuvers [16:42:26] the main advantage of this change will be a bit easier manual acquisition [16:42:36] because it's inertially stabilized [16:43:02] disadvantage, the RR is always moving and the only way to stop it is to pull the breakers [16:43:12] no parking mode [16:54:33] oh lol [16:54:47] MIT digital simulation is interesting [16:55:19] "In the search-designate mode the antenna stabilization system is [16:55:21] simulated . In the hardware, the antenna is inertially stabil i zed in two [16:55:24] axes by two servo loops which hold the antenna mechan i cal bore sight fixed [16:55:26] in the presence of vehicle motion . " [16:55:54] "In the tracking mode, which is distinguished by the presence of [16:55:55] the LGC "Data Good" discrete, the RRADAR program no longer simulates [16:55:56] the antenna stabilization loops. It is assumed that the radar can keep its [16:55:56] beam center directed along the line of sight to the transponder. " [16:57:21] was that the confirmation you needed ? [17:00:20] not really, the second part is surely not correct behavior [17:00:36] I'm trying a RR designate with a 1°/s pitch rate [17:02:39] doesnt seem to work [17:03:27] its in mode 2, but doesnt properly fight the rate [17:03:38] so it's kind of stuck [17:16:40] so V41 N72 needs attitude hold, or at least nearly attitude hold to work right. Which I have not seen in any procedures [17:27:07] interesting [17:38:13] but if this is correct behavior then the RR made quite the journey during the descent on Apollo 11 [17:39:09] it also was drifting a bit, so after a few minutes it would never point exactly where it did initially [17:39:16] the real one [17:40:30]