[12:46:47] NASSP Logging has been started by n7275 [12:46:49] good morning [12:54:59] hello Matt! [12:55:10] I hope you had a good few days [13:15:43] I did. everyone ended up loosing power, except my wife and I, so we ended up hosting Christmas. I have(and have eaten) way too much food [13:17:41] you? [13:17:50] oh were you caught in this winter storm I heard about? [13:18:52] I was at my grandma's with the extended family. Had a good amount of food, maybe a bit too much drink :D [13:19:26] this can hit pretty hard: https://en.wikipedia.org/wiki/Feuerzangenbowle [13:39:13] oh wow. haha, I bet [13:40:30] yeah we had a pretty bad storm. I think Portland set a record for tide+storm surge. [15:44:42] I made some minor edits to the wiki, mostly on the main page based on some inspiration I've taken from other wikis [15:44:54] should make things a bit more obvious [15:50:39] I want to work on the first steps page next. what we have right now is relevant for 2007 NASSP, not so much for our current version [16:09:15] makes sense [17:49:29] morning! [18:01:04] hey Mike! [18:01:13] how was your Christmas? [18:04:01] it was great! how was yours? [18:05:11] good, good. Did the weather affect you at all, like Matt? [18:06:08] At exactly -0.1°C our trains usually start breaking down and Christmas traffic becomes chaos. Luckily no problem this year :D [18:06:38] it was -20C here for a couple of days with wind chills down to -37C or so [18:06:54] but we didn't lose power and just stayed inside haha [18:07:12] good strategy! [18:21:42] I stayed inside too haha https://twitter.com/photographmaine/status/1606343063441477634?t=LsQEt_Dm70_H1XuBKYj-RQ&s=19 [19:12:31] oof yeah good call haha [21:27:36] night! [13:55:49] good morning [14:24:30] I'm just about ready to start working my new fluid simulation into a branch. [15:04:58] I'm reasonable sure that I'm not inventing any new physics just to make this work. [15:07:48] hello hello [15:07:55] I think that is a good thing [15:08:03] unless you want a job at CERN or so [15:12:25] hahaha [15:12:48] if I start playing with quantum states in our code, please stop me [15:16:40] I know my "request changes" button Github [15:16:48] button on* [15:19:19] same thing goes for combustion :) [15:19:48] the only thing I am concerned about is stability (NaN) and CPU performance [15:20:23] if those are not affected too much I am open for every stupid level of detail :D [15:22:21] I am going to add some checks to make sure tank volumes are above critical compressibility limit, as long as that's true NaNs shouldn't happen. [15:26:10] I don't think performance will be impacted. if anything, when I translate this into C++ I can definitely make it cleaner than what's there now, and the compiler should have a much easier time optimizing. [15:28:27] I'm undecided at the moment about how I want to handle boiling and condensing, with respect to rates of phase transition. [15:28:52] I think I can make that more stable too. [15:32:21] what I am really looking forward to is making the "before and after" phase diagrams. should make for some cool graphs [15:45:44] yeah the graphs that prove that what you did made a lot of sense are always fun :D [15:55:52] I like Orbiter's "tech notes". I might add a few documents for some of my own stuff. [15:57:03] or actually, maybe I'll just add stuff to the wiki, because people will actually read it if it's there [17:45:16] more likely that the wiki is being read, but people still ask questions first and doing required reading second :D [18:29:11] speaking of which, I've been trying to analyze the forum questions a bit, in hopes of writing a better first steps page. any thoughts or input on what should go there? [18:54:46] keyboard commands [18:54:56] suggest learning how Orbiter works first :D [18:56:23] I'll think about it, I'm sure I have heard many other common questions [21:57:30] night! [02:20:00] GitHub discussions now have spam apparently. fun. [13:31:20] good morning [13:46:25] hey Matt [13:46:35] have you tried my failure test scenarios? [15:05:09] I have not, but I did test saving some of my own [15:55:07] we're those part of your pull request? [15:55:14] I didn't see them [16:04:30] I put them on Discord [16:11:15] oh. I totally missed that [16:16:12] yesterday evening [16:17:10] I found them. [16:23:26] I need to practice up on my failure procedures [16:25:17] both of the scenarios can teach something about that [16:26:31] I think we were talking about getting rid of any kind of IMFD support a while ago [16:26:43] any reason not to delete it? [16:28:57] not that I can think of [16:29:58] it was very useful years ago when we needed it, but we have better tools now :) [16:30:34] and I will add back TLI targeting to the RTCC [16:30:47] in the form that the early RTCC Requirements had it [16:30:57] which probably never made it into the real RTCC software though [16:31:44] in its simplest form, just a lunar flyby at a specific latitude, with optional return to Earth [16:33:01] calculating a 7-parameter update for the LVDC [16:36:59] yeah nothing was using the IMFD interface anymore actually [16:37:04] I thought I had to remove more code [16:37:16] I had probably already deleted it [16:40:24] how much control does a TLI burn have over pericynthion height vs longitude? [16:41:26] latitude or longitude? [16:41:41] longitude [16:41:48] longitude not so much [16:41:53] depends on the incoming trajectory [16:41:58] hybrid trajectories help [16:41:59] I thought so [16:42:15] if you want to go to a specific place you better do TLI at the right time of month [16:42:56] pericynthion height is of course the main thing the duration of a TLI burn changes [16:43:43] latitude is also fairly free as long as you don't care about the inclination which you have when returning to Earth [16:44:12] but I guess changing latitude can cost you lots of TLI DV [18:14:01] looks like we had a whole bunch of unused code [18:22:32] and that's just the stuff I found quickly :D [18:44:12] approved [18:53:10] oh. we do have a keyboard commands page on the wiki. it's just not called that [18:53:13] https://nassp.space/index.php/Controls [18:53:29] needs a few updates [19:22:27] the first steps page is the one that needs the most updates [19:22:34] and it can link to the controls page [19:35:36] agreed [19:36:43] next kind of cleanup in the code, reducing the dependency on the mission time variable [19:36:53] I finally want to stop and recycle countdowns... [19:39:57] first obstacle, S-Band power amplifier, uses mission time to keep track of time for shutting down and powering up. Can't change it to simulation time with current code or else saving/loading during powering up is broken [19:55:08] why does that system need mission time? there has to be a better way to do that [20:01:23] I think the rendezvous radar transponder saves a "heating up" timer [20:01:46] we also can and should probably make those thermal objects [20:10:18] it saves the time when you start the powering up process [20:10:33] and sees it as finished at that time plus 90 seconds or so [20:10:47] probably should use simdt every timestep or so [20:10:57] have to look at the Systems Handbook, probably some delay timer [22:19:10] night! [14:51:06] hey [15:51:13] hey Matt, happy new year! [15:52:57] happy new year! [15:55:16] The only thing I'm seeing for compatability issues with the latest OpenOrbiter build is our EMS scroll [15:58:28] right [15:58:49] the code for that probably needs to be rewritten a bit [16:40:48] XRSound is going to be a necessity. There are so issues with MT vs MD that could only be resolved if OS5 was rebuilt against OpenOrbiter. [16:43:44] yes, as I was saying on Discord, I think we could even move to XRSound first, so that it's not one huge update to OpenOrbiter compatibility [16:58:26] agreed [15:40:37] hey [15:51:09] n7275, I see you started doing some small updates again with the Fortran code from the MSC memo [16:07:38] yes, hoping to get that all transcribed at some point. would be nice to be able to run it [16:17:27] yeah it's very interesting code [16:17:35] as closely related to any actual RTCC code as we have [16:26:28] I expect I'll have to do some more back-porting to the 7094 archetecture so I can run it [16:27:18] and then maybe I can try running it through the OS360 fortran compiler [17:54:02] good morning and happy new year! [17:55:03] hey Mike. happy new year! [18:19:32] thewonderidiot, happy new year and may YUL throw fewer curses at you this year :D [18:20:34] hahaha but I want more! [18:21:10] ah, going for the highscore then [18:21:16] indeed :P [18:21:22] hopefully this year will bring Comanche 67, Comanche 72, and Corona 261 [18:21:54] does that get you a signed autograph from Hugh Blair-Smith [18:21:57] uhh [18:22:00] and maybe more [18:22:01] slightly redundant [18:22:06] lol [18:22:12] I was thinking of signed letter or something lol [18:23:08] can't wait to get fact checked by Youtube if I post a AS-202 video [18:24:38] I am only posting true things about Corona 261, I swear [18:24:45] hahahaha oh man [18:25:32] but it's a very video friendly mission [18:25:40] definitely will create one [18:28:51] I'm sorry I haven't really been any help with Sunrise btw. I just wish I could crack the "scaling code". Even without that I should be able to understand more of it. I'll get back to it [18:30:41] oh no worries, I've been taking a Sunrise break as well [18:31:16] I'm probably going to get back into it this afternoon -- making use of all of those flowcharts and working on the non-mathy parts of orbital integration [18:34:25] one advantage of having so many projects at once, just jump to the one with the least temporary dead ends [18:36:36] hah yeah [18:36:59] or the most mindless busy-work one if you are too tired to put in concentrated mental effort [18:55:49] well I'm hitting my first interpretive code in an AGC program and it looks like pyul is handling it all correctly [18:55:57] I did a lot more work on the AGC target than I had remembered [19:56:24] pyul is closer to the real YUL than yaYUL? [19:56:38] and there was also GAP, which we don't know much about, do I remember that right? [20:03:40] pyul is a direct port of the H-1800 assembly for Yul to python [20:03:46] so yeah, significantly closer :D [20:04:16] and yeah, GAP was the port of Yul to the IBM 360 with some changes. we don't have that, although we have the user's guide for it now [20:06:41] ah nice, they got some 360s then at the lab at some point [20:07:25] I remember when we tried to figure out which computer this MSC Fortran program ran on I looked at government procurement lists, lots of computers going all over the place :D [20:09:44] hahaha yeah [20:10:31] oh and the answer I got from those documents was, MSC got all kinds of computers and no, you can't tell from it which department got what [20:19:22] yeah that's not surprising lol [20:21:01] and because they really got all kinds of computers, even of the high end variety, you couldn't tell anything from it [20:45:40] The comments and floating point stuff were at extream odds with one another. [21:40:12] night! [16:54:54] hey Niklas [17:01:15] morning! [17:01:50] hey guys [17:34:42] I'm fairly certain that I'm going to need to "experimentally" 81 different interaction parameters for my new substances. I give myself an optimistic 60% chance of finishing this project [17:45:00] the smart thing would be to make Matlab do the hard work and automate the tests [18:01:24] ah, the classic 60% project [18:01:43] I usually finish them... on the third attempt after having deleted every remnant of the previous versions [18:35:57] how's XRSound coming along? [18:44:37] pretty well, considering I am finding lots of very old issues [18:44:56] I'll have a branch to test tomorrow or so [18:45:05] still have some linker warnings I need to get rid of [18:45:30] and we will have to do lots of testing before this can get merged [18:51:41] oh definitely. I think making the move to XRSound, separately from the move to OpenOrbiter is a good idea. [18:58:20] never again getting CTDs by typing outside of Orbiter haha [19:00:09] yeah, that'll be very nice to have. [19:25:57] I'm sure for every step we can take our of the installation instructions we gain something like a tenfold increase in accessable, too. [19:30:01] yes, but, this isn't one of them [19:30:12] you still need to separately install XRSound [19:30:47] it's just a step in the direction of going to Open Orbiter [19:58:13] I know. it was only a semi-related thought. [19:58:52] that's now quite how what I said reads though, haha. sorry [20:00:39] I've played around with the 32bit version of Open Orbiter, I like it quite a lot [20:00:58] when me move to that then you are right [20:03:24] I kinda wish there was a bit more chatter about development intention from the dev team. [20:03:47] they need an IRC channel [20:07:09] but it's quite solid so far. a lot of good changes. [20:08:44] yep [20:08:53] I also like the UI and MFD updates [20:21:28] if you want to play with my gravity model, I can build and send you a copy. [20:23:00] ah I think there is plenty of work to do just to get current NASSP working with current Open Orbiter haha [20:23:30] we can start lobbying for including your gravity model once NASSP has upgraded [20:25:01] sounds good [21:40:19] night! [15:31:49] good morning [15:34:21] hey [15:36:26] for your propagation control code, and not just for that, I think it would be good to have some ephemeris "tapes" [15:37:16] either create it on our own or find it somewhere [15:37:52] either one giant text file or a few of them [15:39:19] oh yeah. definitely. one of those routines is the "read from tape" routine, iirc. [15:40:05] one of the TRW documents for NASA contains the format of the "NASA/MSC GEOCENTRIC SOLAR AND LUNAR EPHEMERIS TAPE" [15:40:15] not sure if that is the same as in that Fortran code though [15:40:40] should be pretty easy to determine from the READ statements [15:43:24] I think there was one tape with data for the nearest Besselian year [15:43:46] so switching coordinate systems slightly every year, like Apollo [15:44:04] and then another tape with only B1950, like Skylab AGC and Shuttle [15:44:08] 1950 to 1999 [15:44:58] what would be really cool is if we could generate the ephemeris tapes with a 7094 or 360 jobstream [15:46:51] would that be realistic? I thought the tapes were simply supplied by JPL [15:52:28] I don't mean the same job stream that runs the propagator. [15:52:58] a separate one [15:53:39] would be interesting to learn more about how JPL generated those (hardware/ programming language) [15:54:21] right [15:57:22] the RTCC itself also used JPL ephemeris tapes [15:57:29] the format might not be the same for all of them [15:57:50] could be specialized for each type of computer etc [15:58:12] in late 1968 they had a tape with data from 1967 to 1980 [15:58:26] or at least that is what the tape read function QMGEPH allows as input year [16:47:59] I'm switching to english language in my Visual Studio [16:48:23] sometimes it auto generates files in German like in the LM telemetry client [16:48:36] and if I want to ask help about something I have to translate build warnings... [17:08:27] ahh, that has to be super annoying. [17:09:34] annoying enough that I will all set it to english now haha [17:27:24] so you're saying that setting mine to German probably isn't the best way to learn haha [17:28:19] it's the best way to render stackoverflow useless for you lol [17:58:39] morning! [18:16:29] hey Mike [18:45:13] what's up? [18:48:50] I just finished turning EXTENDED VERBS into punchcards for Sunburst [18:49:06] I'm at 915 cusses.... coming up on the 1000 mark real quick [19:01:33] ha, fun [19:02:50] it's already very nice being able to compare Sunburst and Aurora punchcards [19:03:11] the yaYUL-formatted code's whitespace is alllllll over the place. makes it nearly impossible to diff programs [19:10:50] yeah that's gotta be a pain. [19:11:21] I'm kind of tempted to make a punchcard-to-yaYUL generator to run once I'm done making punchcards for everything [19:11:30] to get it all on the same baseline [19:12:19] haha oh no [19:12:35] making it worse... but compatible! [19:14:36] worse how? [19:15:04] I would argue it's hard to get worse than the current state of the AGC codebase :D [19:35:07] punchcard-to-yaYUL generator, didn't you meant that the output from yaYUL has bad whitespace? [19:36:10] no I mean the source .agc files have terrible whitespace [19:37:33] some have tabs, many have spaces but different files have different numbers of spaces between columns.... the vast majority of the transcribers paid no attention to whitespace in comments... etc. [19:40:28] ah yes, now I understand [19:41:07] got a bit of a headache, logging off. cya! [20:41:15] that's an excellent cautionary tale for me, with my transcriptions [20:42:10] at least I can claim, if I do it right, that the bad whitespace is the fault of the original listing. [20:47:35] yeah. part of the problem is that with yaYUL, it's impossible to correctly capture the original whitespace in all places [20:47:53] due to restrictions with yaYUL itself, or the addition of leading "# " for comments throwing off alignment, etc. [20:48:07] and so since it wasn't 100% possible, no real attempt was made [20:48:44] the nice thing about putting things into punchcards is that whitespace correctness is now unambiguous...... mostly [20:49:10] the only thing that can be ambiguous sometimes is column 8 for vertical spacing, on page breaks or before P cards [14:43:29] hello [14:50:06] hi [14:55:11] trying to compile NASSP on windows but the ibiblio link it dead... [14:56:32] when compiling against OpenOrbiter I get "'MT_StaticRelease' not match 'MD_DynamicRelease'" link errors [14:57:00] and with compiling with Orbiter2016 I get "TextW" not defined errors<<< [14:57:03] any clue? [15:17:18] which ibiblio link? [15:17:38] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864 [15:17:42] hey guys [15:17:54] hi [15:17:57] oooooh that is very outdated [15:18:12] the link is from the Readme.md [15:18:20] where have we not updated that yet haha [15:18:23] hey Nik [15:18:46] oh no haha [15:19:59] the 'MT_StaticRelease' not match 'MD_DynamicRelease' thing is something I just encountered, too [15:20:05] thought it was just XRSound [15:20:30] we have a draft pull request to switch to Open Orbiter/XRSound/Visual Studio 2022 and that has to change that, too [15:20:39] I assumed that was an OrbiterSound5 thing [15:22:29] yeah I just saw the PR, it changes some MultiThreadedDLL [15:22:35] Gondos, our nominal installation instructions are: [15:22:38] https://www.orbiter-forum.com/threads/nassp-8-installation-guide.36801/ [15:22:39] our plan is to upgrade to XRSound and stay with R90 until we know that's working, then as a separate step, make the move to OpenOrbiter [15:22:54] less bugs at once [15:23:48] aha! [15:23:51] https://web.archive.org/web/20181231164219/http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864.0 [15:23:56] I'll change our readme to this [15:24:22] and we should probably have a similar post on the Orbiter Forum, if we don't have it already somewhere [15:26:52] I'm not sure about the TextW thing [15:26:58] ok, so when you say "Latest Orbiter Beta NASSP 8.0 is not compatible with Orbiter 2010 and is at this time only compatible with the latest Beta release of Orbiter 2016", what is exactly the latest Beta release of Orbiter to use? [15:27:15] I used TextW to show greek letters on the RTCC MFD [15:27:32] yeah, but UTF16 suck :p [15:27:49] utf8 is not supported by sketchpad? [15:27:52] if you have a better idea I am open to changing it :D [15:28:45] the best Orbiter version to use with NASSP is currently the latest and last Orbiter Beta, Release 90 [15:29:49] If TextW gives problems, was that maybe only added in the Orbiter Beta? [15:29:53] Not there in 2016 yet? [15:30:56] I can try UTF8, maybe I didn't know I could do greek letters in a different way [15:31:05] yeah looks like it, I just extracted the Orbiter2016.zip inside the NASSP repo [15:33:06] https://www.orbithangar.com/showAddon.php?id=4f300319-5ee2-4c48-a213-50995a480e06 [15:33:29] this is a snapshot of the last Orbiter Beta [15:33:38] I think it would need to convert UTF8 to wchar16_t inside Text if UTF8 is not supported so it would require a change in the orbiter core [15:34:12] ok, thanks for the link [15:35:23] I'll check if sketchpad Text is enough [15:35:40] oh and you had some other proposed changes, not all of them have made it into NASSP yet [15:35:46] CaptainSwag101 is still active? [15:35:50] yep [15:36:24] nice, because the PR looks stalled [15:36:55] I think he didn't have time to continue [15:37:12] I am continuing with it since a few days ago [15:37:18] only switching to XRSound for now [15:37:29] because that is built into Open Orbiter [15:37:34] so it's "the future" :D [15:38:13] yeah, he's in school right now iirc. semester was just finishing up [15:38:20] ah ok [15:41:55] I can do some tests on XRSound now that I have a windows box ;) [15:44:47] skp->TextW(9 * W / 32, 5 * H / 32, L"\u03C6LLS", 4); [15:46:38] I think the greek letters are always multi-byte? [15:46:57] so not sure yet how to do it without TextW [15:52:18] with UTF8 strings are still char * [15:52:48] I looked at the core, it would impact the graphics clients [15:53:23] ok so I could compile with r90 and TextW [15:57:13] if TextW is properly supported in Open Orbiter still there might not be a reason to change this then [15:57:29] We don't recommend using NASSP with Orbiter 2016 [15:57:33] even less so building with it [16:04:50] I'm more concerned with the compatibility with gcc on linux [16:05:08] if TextW can be impemented on linux then it's not a problem for me [16:05:20] I'll have a look at it [16:05:36] hmm ok [16:06:04] if it's a graphic client issue, I don't think we care much about DX7 aka MOGE compatibility [16:06:18] I'd rather drop DX7 compatibility than Linux [16:06:35] DX7 has severe limitations anyway [16:06:49] mesh transformation is not supported [16:07:07] and I am not seeing DX7 anymore in Open Orbiter [16:41:48] arf, the d3d9client for beta link is crap too [16:42:47] in the current installation instructions? [16:43:15] links to https://www.orbiter-forum.com/resources/d3d9-for-orbiter-beta.5495/ which looks good to me [16:56:50] I kinda wish the D3D9 site had stayed up until there was an Orbiter beta releasr [16:56:54] release [16:57:21] I was able to rescue the old versions with archive.org [16:57:36] the zip I get from archive.org is corrupted [16:57:46] why do we need old versions? [16:57:51] I also still have a lot of them locally [16:58:19] oh, I just mean the last R90 release [16:58:43] "old" in the sense that it's not the OpenOrbiter version [16:58:51] is what I linked not for R90? [16:59:10] it is for R90 [16:59:34] it links to archive.org but you get an HTML file instead of the zip [16:59:53] hang on [17:00:24] if I try directly from archive.org, it starts then rstart seeral time and finally gives up and fails [17:00:59] that has everything that was on the site [17:01:52] same deal... [17:02:00] the files are all 9k [17:02:15] if you open them with notepad you'll see they are html files [17:02:25] oh crap [17:03:01] hang on...emailing some people [17:03:09] lol [17:03:48] so if I want to do a PR to fix some file cases in #include statements, you mind if I do a single commit which impacts lots of files or do you prefer several ones? [17:08:41] one commit is good [17:09:24] I'm sure it's all for one purpose, so one commit makes sense [17:09:45] yes, it's just cosmetics from windows point of view [17:10:20] sounds like a change that would also make our joining and leaving friend Jordan happy [17:10:23] next I'll try to PR some sketchpad work but I need to have that damn D3D9client r90 version [17:11:54] n7275 seems to be taking care of it [17:12:03] I can quickly send you the file, too [17:13:05] I emailed jarmonik and IronRain, they will look into it [17:13:21] if you need it, I linked it [17:13:32] thanksm I got it [17:16:19] I have about 20 others where that is coming from lol [17:16:31] I'm a data hoarder [17:16:46] LOL [17:17:00] nice, I see you've removed the IMFD integration [17:17:18] yeah wasn't needed/used anymore [17:17:26] oh did that get in the way of Linux, too? [17:17:38] number 26426 of things that are getting in the way? [17:18:42] yes, the shared memory with IMFD was not playing nice with linux [17:24:50] interesting question on the forum. do we have that document? [17:26:46] at least one volume [17:26:58] I wanted to ask Mike if it was ok to share [17:27:18] he got us the document and I am not 100% sure the source was ok with sharing it [17:28:15] morning! [17:28:24] I'm pretty sure it's fine [17:30:43] I don't think we have the full thing [17:31:14] those tend to sell for a lot and haven't been high-priority things for me to try to get my hands on [17:48:43] didn't know that early AOH was coming from the same person [17:52:11] yup! [18:06:55] ooo those are very nice [19:06:17] hey guys [19:06:23] happy new year [19:09:16] hey Alex! [19:09:26] happy new year to you too [19:09:34] thanks [19:11:02] hey Alex, haven't seen you all year! [19:12:06] hey, happy new year! [19:12:08] haha [19:14:21] indy91, I haven't had internet all year either...my wifi broke on the 1st :D [19:14:51] im using my friends for now, luckily he's got an unlimited plan [19:18:16] ouch. You almost had to actually use a TV to get news, yuck! [19:20:55] yeah lol, but my TV also relies on wifi :D [19:25:44] could be worse, like loosing power. Last time that happened to me for more than few minutes it was the whole area and everyone seemed to have started using the wifi of their phones. [19:25:54] So much so that the network overloaded [19:26:08] people were standing in the middle of the street in order to get better reception :D [19:26:14] all because power failed for 30 minutes [19:28:11] I pushed the PR, hope I didn't mess anything, first time for me^^ [19:29:08] one commit, correct branch for the PR, seems good :D [19:29:48] oh wow that's a lot of includes that had to be changed haha [19:29:58] and some comments lol [19:31:48] yeah, it grows up quickly given the size of the project [19:32:19] I haven't updated my NASSP installation in a few months, just looking over the changes since then [19:32:35] hmm interesting [19:32:46] "Rendezvous radar compensates for body attitude rate at all times, even in slew" [19:33:32] that hasn't been merged yet. Ryan put that in there by accident, but it got reverted before being merged [19:33:36] it's still in a branch of mine [19:33:43] ah [19:34:28] it's something that we knew for a long time about, but the sources were always a bit confusing. So I was holding up any change to it [19:35:36] so in slew mode it would stay at a fixed orientation relative to the stars I guess, despite spacecraft movement? [19:35:45] that's the theory yeah [19:35:58] it does sound like it would make things a bit easier [19:36:11] to slew around and lock on to the CSM in slew mode [19:36:39] and might also be the reason why you so often pull the RR breakers [19:36:43] not only to save power [19:36:52] but also to not let the RR rotate unintentionally [19:36:59] like when the CSM maneuvers, before undocking [19:37:31] I've been pushing at this because I think RR antenna movement is required to explain what appears to be variable loading in the Apollo 11 landing [19:37:41] i.e. I think if the dish wasn't moving they would have gotten many more than 5 program alarms [19:37:50] Gondos, it builds and the code looks good [19:38:12] this was probably the easy part. Next up meshes and textures? :D [19:38:18] ok, I'm officially the king of search and replace lol [19:38:29] or is that Jordans department [19:39:15] we have been talking about it for a while, he has some scripts etc. [19:40:28] I got the d3d9client to work on beta r90, I good to work on sketchpad [19:40:39] PR merged [19:40:56] will take longer since there is actually some real testing to do on these ones [19:41:08] yeah I can imagine [19:41:23] this was more of a case of "it builds" or "it doesn't build" [19:41:31] I will be back on tomorrow, cya! [19:41:35] cya! [19:41:44] with meshes and textures it could be a missing texture you don't easily notice etc [19:42:28] or a mysteriously missing SM panel :P [19:42:37] psssst [19:42:56] IRC channel rule says it's not allowed to talk about that :D [19:43:15] hahahaha oh sorry [19:44:43] usually they put an ugly magenta as default texture so you can't miss them [19:47:26] yeah [20:13:15] I have a request for our 3d modelers [20:13:33] whoops, I missed alex [21:23:47] thewonderidiot, what do yellow underlined characters mean in your punch card vim syntax highlighting? [21:24:00] uhhhh underlined yellow? [21:24:17] do you have a picture? [21:24:49] oh actually, nevermind [21:24:51] I'm dumb [21:25:04] it's the damn cursos... lol [21:25:10] cursor [21:25:18] long day [21:25:38] hahaha [21:25:55] I've been monkeying around with it some more recently [21:26:13] I got it to highlight everything past column 80 as red [21:26:18] oh also I don't know if I ever sent you this [21:27:32] https://pastebin.com/raw/x1zHzP2c [21:27:56] that's my setup outside the syntax file [21:27:59] but that last line [21:28:17] let @n="0lv7|yjv7|p0l^A|7|l" (where ^A is ctrl-A) [21:28:30] is a macro that copies the current line's punchcard number onto the next line, and increments it by one [21:29:03] regardless of how many digits the number is [21:29:14] it saves an insane amount of tedium [21:29:42] usually I can just hold down the @ key to fully number a page, only stopping to take care of vertical spacing or nonsequential numbers [21:32:17] I have everything but the macro. [21:32:47] I also have like 5 different vimrc files... [21:32:52] hahahaha [21:33:32] 4 of which are empty [21:33:32] why? I have no idea [21:33:57] amazing [21:34:24] typical Debian things... [21:34:46] oh yes that sounds like a very Debian problem :D [21:36:39] I've been trying to think of macros that might help with my transcriptions. [21:38:01] hopefully this one helps! manually numbering cards is a pain [21:38:09] let me know if you think of anything else useful [21:39:33] unfortunately a lot of the fortran card numbers numbers have letters mixed in, and formatting is a bit inconsistent [21:39:52] oh that's annoying [21:44:45] n7275, are you transcribing the functions in order? [21:45:37] yes [21:45:46] I was scrolling through the document, reminded me of the atmospheric density situation :D [21:46:14] RTCC still uses US standard atmosphere [21:46:34] oh yeah, I vaguely remember discussing that one :) [21:47:11] can one of you send me a link to the document? I've forgotten which one it is [21:47:35] https://web.archive.org/web/20100519203534/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19750065854_1975065854.pdf [21:48:00] thanks! [21:48:17] I think the only difference between that document and our current RTCC function is a different radius as reference for altitude [21:48:25] and the way it calculates the geopotential height [21:48:54] that is definitely different between the actual RTCC (as of late 1967) and this document [21:49:30] what I recently found is that the Entry postflight trajectory analysis documents use an Air Force supplement to the standard atmosphere [21:49:42] with different profiles for different latitudes [21:49:47] and January vs July [21:49:57] they use 30° for the most part [21:50:05] standard atmosphere is essentially 45° [21:50:16] ... which Apollo never gets to [21:51:04] so I am tempted to switch to the numbers for January, 30° latitude [21:51:17] it's the same scheme, just different numbers [21:51:52] downside is, that would contradict the IBM document that clearly says it is using 45°, so the standard [21:52:12] but they could have changed their mind about that [21:52:23] and in like 71, 72 they changed to a Jacchia model anyway [21:53:10] if only UHCL had found those system parameter documents... [21:55:43] maybe I should change it to the Jacchia model for better accuracy. With the constant flux value that Orbiter also uses. [21:56:53] my main issue is that the 0.2g time on the Earth Entry PAD is usually off enough so that, strictly following mission rules, you nearly have to abandon the AGC because you can't trust its downrange error. [21:57:24] and the difference is clearly from RTCC vs. actual (in Orbiter) atmospheric density [22:09:17] night! [13:56:58] hey [13:57:17] hi [14:07:19] what's up? [14:07:32] working on sketchpad for NASSP ;) [14:07:53] but there are issues related to DPI I think [14:08:27] the needles are really thin (1 pixel) but with GDI windows is fattening them to take DPI into account looks like... [14:11:15] also the MFD button text is sometimes off by one pixel, makybe not that big of a deal though [14:22:18] is this for the EMS? [14:23:48] the EMS scroll? [14:24:01] yea [14:24:20] yeah it works with the ems but it's also thin with the GDI [14:24:30] ahh [14:24:59] I believe Jordan is working on improving the resolution of a bunch of stuff. would that help too? [14:25:30] not really, the bitmaps are not impacted but DPI awareness I think [14:25:58] the graphics client should handle that but I don't think it's the case [14:26:28] oh okay [14:42:26] hey [15:19:39] hi Niklas [16:03:10] I found a slight correction to the RTCC atmosphere model, it was just that the reference radius used for the calculations wasn't quite right. I just used the Earth radius in Orbiter, but actually it's a bit of a fake radius for geopotential height [16:03:45] it's not extremely close to the model in the propagation control package document [16:03:49] now* [16:04:33] only downside, at the height where it differs the most from Orbiter the density is now 5% greater, when I actually wanted it to be smaller :D [16:16:44] uh oh [16:26:06] doesn't make the overall issue much worse, so I think I'll go with that for now. The agreement is very good [16:27:07] one trickery I could do is, the DSKY only updates every 2 seconds, so if 0.2g is detected then it switches to the next noun and shows downrange error (that you are supposed to compare to the Earth PAD) [16:27:20] so I would "win" 2 seconds if I account for this [16:34:18] ahh okay [16:34:56] how far off is the .2g time, currently? [16:35:25] I think it was almost 20 seconds [16:35:33] enough to travel almost 100 NM [16:35:47] which is the limit [16:36:01] you look at the first downrange error, which it shows after 0.2g [16:36:12] and it has to be within +/- 100 NM [16:36:16] of the PAD value [16:36:24] or else PGNS can be coonsidered bad [16:43:15] huh [16:43:25] I just tried it again, Apollo 7 [16:43:29] with the updated density model [16:43:33] only 6 seconds late... [16:45:38] but I recalculated the PAD and there was no change in the 0.2g time :D [16:47:42] maybe it's more random than I thought, with solar and latitude variations [16:56:05] also only 6 seconds late on Apollo 9... [16:56:24] maybe the issue somehow went away on its own then :D [17:13:03] nice when things work out like that [17:27:16] morning! [17:36:57] hey Mike [17:43:13] hey Mike. looks like you beat the final boss of Yul [17:46:31] YUCCCHHHH [17:48:20] haha indeed [17:48:22] only 245 pages in [17:48:30] now I'm kind of curious how high that count is going to get [17:49:17] most of the core functions and constants that are causing all of the cusses aren't going to get defined until page 950 or so [17:51:04] also Ron is pretty damn focused on this shuttle stuff lol [17:51:31] I sent him those documents yesterday, and he said they came at the perfect time because he was just considering taking a big break from his HAL/S work [17:51:33] I guess this couldn't happen as badly in Luminary then because the Controlled Constants section is on the first few pages? [17:51:49] .....and since then, no documents in the library and there have been several more commits on the HAL/S thing :D [17:51:55] hahaha [17:52:24] it's not controlled constants, it's things like the EXECUTIVE, inter-bank communication (so POSTJUMP, BANKCALL, etc.), constants like ONE, TWO, THREE, the bit constants BIT1, BIT2, BIT3..... [17:52:27] I am enjoying seeing his progress though and he has some impressive sources. Who knows what else will appear in the documentation section.... [17:52:36] ah, even more fundamental things then :D [17:52:41] fundamental things that are called and referenced all over the place [17:52:44] yeah [17:53:08] that's why I'm averaging like 4-5 cusses per page lol [20:03:37] Happy New Year to all. [20:07:13] hey Jordan. happy new year [20:08:21] happy new year! [20:34:54] how are the textures going? [20:44:18] Matthew are u asking me? [21:05:11] yes [21:08:35] I am very advanced. If I haven't missed anything, the text in the panels should be ready, both in cm and in lm. [21:09:23] Updated my branch today. [21:09:42] very exciting :) [21:10:49] A few gauges still need to be worked on. [21:11:15] Not the text but the gauges itself [21:12:27] The biggest problem is the Sourcecode as i mentioned earlier. I am not a coder so it is hard for me to do all the changes. [21:14:59] I can help with code if you want. [21:16:09] Any help is welcome. [21:18:59] I made a define "TexMul = 2" somewhere in the code and use that for multiplying the xy coordinates, take a look in my Sourcecode. I wanted do make a variable but i don't know how to make it visible in all the modules. [21:21:08] This define is important because i made the textures 8k and scaled them down to 4k wich is double the size of the actual ones. If someone has a fast computer then he can later use the 8k textures wich are more crisp. [21:27:27] I will take a look when I get home tonight. [21:32:22] do you think it would be possible to make a texture with just the text? I'm interested in implimenting integral at some point. [21:34:51] http://www.ibiblio.org/apollo/Documents/LM-Panel-Sept1968.jpg [21:44:27] It is. I've been thinking a little for the future. All the textures are made in levels. The text ist separated fro [21:44:34] ...fro. the [21:45:15] ...from the rest , wenn i export the texture thrn all will combined [21:45:43] nice! [21:47:08] Have u any idea how to make the code for vc work separate from 2d? [21:49:07] there are some places where variables are shared between 2d and vc. we would just need to make some new ones, just for vc [21:49:23] I know we have looked into this in the past [21:49:45] I thought when the function for blitting the texture is called we can give an extra parameter for the "TexMul", if 2d is called then set TexMul to zero otherwise 2 for 4k or 4 for 8k. [21:51:08] Function or i think Method is it called in c++ [21:53:32] i think "method" is technically more correct, but I usually call them functions. technically methods are functions that are members of a class [21:54:48] and yes. that way of calling oapiBlit with TexMul would work I think [12:09:42] hi [14:34:42] I.m trying to test the PanelSDK visuals but I can't find a way to trigger them... [14:37:56] is it only used to aggregate the subsystems and not for drawing? [15:44:06] Gondos, we only use PanelSDK for the systems. [15:59:11] ok thanks [15:59:27] I'll put the sketchpad stuff in but no tests then^^ [16:01:20] i've set up a draft PR btw [18:40:52] Gondos_, yep, I'm following your progress [18:41:02] this PR will take a bit more than 15 minutes to validate though :D [18:41:18] lol [18:41:28] good timing, I pushed the last one [18:42:24] one EMS scroll saving and FDAI are using the old API [18:43:15] not much to do about it since the clbkSaveSurfaceToImage is not accessible via the OAPI [18:43:41] and the FDAI is using opengl so it needs to access an HDC [18:45:22] the selling point is the bilinearly filtered logo in the MFD lol [18:46:07] sounds great for performance [18:52:29] btw, the OpenOrbiter PR is talking about a crash with D3D9, sounds like the same one I stumbled upon [18:53:44] what causes it? [18:58:07] a texture flag not being set [18:58:43] the one that says the texture will be written to so it needs to be uncompressed [18:59:02] and set compatible with a render target [19:00:01] I've put a work around since there's a bug in the core and it will probably not be fixed in the beta [19:06:33] ah fun, another Orbiter bug :D [19:36:12] n7275-: did you checked my code? [19:36:32] Hi [19:49:55] hi, I did. it looks good to me. [19:50:47] I think eventually we'd want 4k/8k selectable in the Project Apollo Configurator [19:52:02] maybe make TexMul a const global, rather than a define [20:26:26] jarmonik updated the download for D3D9 client. we have functional installation instructions again. [00:12:44] n7275 Thanks Matthew, "const int" was what I was looking for. I was looking for something like this but had no idea what to use. Everything I tried ended up in unknown TexMul or something, so I used #define. [00:16:55] Gondos Thymo I started making NASSP cross-platform compliant last Year. For this I wrote a small program that searches all NASSP files and changes the file names so that they are the same. For example the filename is CM-Docktgt.msh but in the source code the name is written as cm-docktgt.msh. This is just one example. Windows has no problem with [00:16:57] this, but Linux and possibly MacOS do too, because they both use case-sensitive file names. [00:16:58] In addition, the program is able to change file names, such as my texture files with stupid names like zzzECS.dds to e.g. ECS.dds [00:16:59] The program uses two file lists of all NASSP files. [00:17:00] One with the original names and one for the one to be renamed. [00:17:01] It creates two folders one with the names only corrected and one where the filenames are renamed. [00:17:01] I've compiled it as a test under Windows and Linux and it worked, at least I didn't find any errors. [00:17:02] What do you think? [00:17:03] Those are the files. [00:17:04] https://www.dropbox.com/s/hnklvk6yv4nj0aa/NameConversion.cpp?dl=0 [00:17:04] https://www.dropbox.com/s/d5q3zt1j6wss4iz/FileStruct.txt?dl=0 [00:17:05] https://www.dropbox.com/s/k50xkowuvbjgexl/FileStructRenamed.txt?dl=0 [00:19:47] Hi Jordan [00:20:20] Hi [00:20:50] In my branch I added an oapiGetFilePath that takes a "windows" path and iterates through every subpath to find the case sensitive correct one [00:21:23] but if the names are correct from the beginning it's even better :) [00:22:29] I.m working right now on the threading to remove the windows specific code and replace with standard C++ thread stuff [00:22:31] Just take a look at my post. i think this is the better solution [00:25:02] can you also patch vessel classes in scn files? [00:25:21] because for examples I had to patch Eagle-LEVA-FLAG:ProjectApollo/sat5flag to Eagle-LEVA-FLAG:ProjectApollo/Sat5Flag [00:25:39] What is also important is that some file names are not spelled correctly, for example some .bmp files end in .BMP instead of .bmp that fixes my "program" too. [00:26:12] All files are processed [00:27:18] only these files not because they are binary std::string fileExt[] = {".bmp", ".jpg", ".xls", ".wav", ".dds", ".pdf", ".db", ".doc", ".elv", ".chm", ".xlsx", ".lib", ".ods", ".sxw", ".png", ".bin"}; [00:28:09] ok, that's nice [00:29:13] regarding the bmp files, one big issue are the embedded HBITMAP [00:29:29] it would be better if they can be loaded as textures [00:30:03] I'll do some tests but the D3D9Client seems to be able to open bmps, from the look of its code at leat [00:30:52] That's outside of my programming skills. I'm just a beginner, so unfortunately I can't do anything [00:33:13] I've already done something like that on my branch but I can't cherry pick it if it's not compatible with the official client [00:33:46] By the way, if you want to test my name converter you have to adapt the FileStruct.txt file. I used absolute paths there. but that's easy to find and replace does the job [00:34:09] the major impact would be a change in the directory structure when creating the NASSP package [00:36:49] FileStruct.txt in constructed with "find>FileStruct.txt"? [00:37:56] how do you keep up to date? [00:40:37] I haven't made an update yet. The last time was about 10 months ago. My idea was to let my program run once to make all changes and then to name all new files correctly. [00:41:13] OK, I downloaded it, I'll play with it tomorrow from a linux session [00:41:41] the nice thing with such a tool is that you can use it to check for mishaps in the future [00:42:06] I wrote a batch file in linux that generated the correct FileStruct.txt. [00:42:20] when new files are added to make sure you don't introduce inconsistencies again [00:42:38] ok [00:42:40] good night [00:42:57] I'm in windows now but can send you the batch file tomorrow [00:43:02] night [18:03:11] good evening [18:07:48] hi [18:09:20] hey Gondos, I see you are busy haha [18:09:44] hehe [18:09:59] I've been postponing this for too long ;) [18:10:07] "Provide safe Watt to dBm conversion" this one n7275 can look at, it's kind of his department [18:10:12] seems like the most innocent change [18:10:37] yeah it's a minor thing [18:11:03] for the thread stuff I don't know exactly where to look at for bugs [18:11:58] on apollo11 where reaching high altitude I get a message "thread started" [18:12:13] then "thread finished" or something like that [18:12:34] but I don't know what would happen if there is a problem there [18:12:37] yeah as long as the thread finished message comes up it probably all worked fine [18:12:50] right, there are cases where something can get stuck in a loop [18:13:06] the problem is that there is no standard way to kill a thread [18:13:07] in the RTCC MFD you can simply press a CLC button again and it would kill the thread [18:13:18] at least that's how it was before [18:13:29] I've put a debug output for now [18:13:48] don't know if you're supposed to clear the buffer afterward? [18:15:26] the proper way would be to have a boolean to tell the thread to stop [18:15:39] but you need to know where it loops for it to work... [18:17:06] which buffer? [18:17:31] the oapiDebugString [18:17:45] if you write to it, the message stays forever? [18:18:11] yeah I guess [18:18:38] writing "" to it would clear it [18:19:01] so in your PR right now there is no way to kill a thread? [18:21:06] and naturally anything that affects the operation of the Virtual AGC that will require a bunch of testing [18:21:18] with the MCC and RTCC MFD it's probably more simple. It either works or it doesn't [18:24:56] yeah no way to kill [18:25:15] that's why I've left it as a draft [18:25:24] I think it need more serious testing [18:26:43] I can implement a proper thread stopping if necessary [18:26:57] but I'll need to investigate where the loops are [18:27:12] and it'll be quite fun to test^^ [18:29:28] yeah I think it's a good idea to have a way to kill threads. Maybe it is difficult to believe, but with the wrong inputs there are ways to cause stuck threads in the RTCC MFD [18:29:36] not hard to believe for me :D [18:30:11] hehe [18:30:59] worst case, you can still get the native thread handle and call killthread on it [18:31:21] sketchpad PR, I think some things might still need tweaking, but otherwise it should be good. What is the solution for the EMS for now there? [18:31:22] nothing a couple of #ifdef can cure [18:31:35] you mean the crash? [18:32:31] yeah [18:32:41] or is it not possible to change until Open Orbiter [18:32:54] the workaround works fine [18:33:03] and should still work on openorbiter [18:33:45] there's an '#if 0' for the proper solution and the workaround is in the #else [18:33:57] so it's just a matter of changing it [18:34:39] https://github.com/orbiternassp/NASSP/pull/890/commits/060f10c8f880fdac5c6328d399d2b863bd9ef5d5 [18:34:47] this is this commit [18:35:06] ah yeah, that is fine [18:35:07] need to go to diner [18:35:12] see you later [18:35:36] haha [18:35:39] same here [18:35:42] cya in a bit [19:23:33] re [19:25:12] checking out your sketchpad PR, I want to see the RSI needle in action [19:25:43] the MFD buttons look like a centered vs. not centered difference [19:26:20] but why the box around the currently active checklist step is slightly different, that is a bit strange haha [19:26:28] but such a tiny difference, doesn't bother me [19:27:27] for the box it can be fixed but I prefer the new one^^ [19:27:45] does not overstep over the next entry as much [19:28:24] for the text it must be the D3DXFont that does not produce the exact same result [19:28:44] which is a shame because it really shows [19:29:14] yeah I agree, that doesn't have to be changed just for the sake of making it exactly as before [19:31:15] man, all those algorithms in RTCC, they were reverse engineered? [19:32:05] tremedous work... [19:32:08] a lot of them come from flowcharts of original IBM RTCC documentation yeah [19:32:35] there is definitely some duplication at the moment [19:33:05] where I implemented "real" RTCC functions but didn't trust them enough yet to immediately delete old ones I came up with myself [19:33:21] in a way the RTCC is in a constant state of changing [19:33:22] hehe [19:33:45] but what I don't want to do in the future anymore is to try and exactly replicate original functions [19:34:05] just too many bad coding practices. No chance of doing it right without plenty of label/goto etc. [19:34:16] all the do {...} while(stop == false), if stop was a member we could set it to true to end the computation? [19:34:46] yeah, flowchart and structured programming don't play well togother I guess [19:35:37] but the incorrect result would propagate... [19:36:28] oh that's what you meant with implementing a bool to stop calculations... [19:36:39] yep [19:40:10] Do you mean in the RTCC directly, just put that on any while? [19:40:15] not sure that's a good idea [19:40:31] it wouldn't be realistic for one thing [19:40:45] also wouldn't catch all possible issues [19:41:06] how would a real RTCC deal with it? the operator would reboot it? [19:41:27] that was one way yeah [19:41:38] in one place they had a solution like you are proposing [19:42:12] ok [19:42:15] they had an input to kill any return-to-Earth or midcourse calculation [19:42:36] probably the places where you could get stuck the easiest in some iteration [19:43:14] that's the other thing, with some wrong inputs you potentially have a calculation that takes nearly forever, but isn't necessarily fully stuck [19:43:59] so I think I do want a solution that allows you to directly kill a thread and not something that sets a variable in a thread to stop it [19:44:47] what is the scope of those threads. Would they be killed if you close Orbiter? [19:46:33] oh of course, the thread are all part of the same process so they die when the process exists [19:47:22] I'll add a native way to kill the thread since it looks like it is really needed [19:48:20] I was not sure it was still needed since the MCC does not do that [19:48:39] yeah the solution for the MCC is to send me a scenario so that I can write a bug fix [19:48:50] arf [19:48:53] if the MCC has a failure you are screwed :D [19:49:12] with the RTCC MFD you could maybe change some inputs and get a better result [19:49:22] it does come down to my code not being perfect of course [19:50:01] in some cases derived from the AGC code where you could have cases where you need to do V96 to kill coasting integration [19:50:35] that's probably how that RTCC input works that kills RTE and TLMCC calculations [19:50:51] something in the trajectory integration routine that stops it [19:52:51] if the RTCC code becomes 100% bug free we don't need any theead killing anymore [19:55:48] MED F00 causes a RTDETACH of task PTFLTPLN [19:55:57] n7275, ever heard of RTDETACH? [19:56:06] sounds like thread killing to me :D [19:56:25] causes an abend [19:56:28] that I have heard before [19:56:31] https://en.wikipedia.org/wiki/Abnormal_end [20:04:38] new RSI needles is too small [20:04:39] https://www.rrauction.com/auctions/lot-detail/33239020429180-block-ii-entry-monitoring-system-ems-/?cat=0 [20:06:15] the rest of the sketchpad PR is good, no issues there. Just have to go through the code once and do a bit of testing, but I have changed some things from HDC to Sketchpad myself in the past, so that looks all good to me [20:06:47] do you notice any change in performance from the changes? [20:12:59] lol yeah, that thing is huge [20:13:47] Ithe pen is set to white so that may explain but it should do the same with GDI [20:14:04] performance wise I don't know [20:14:19] but the background looks nice now ;) [20:14:24] the MFD's [20:14:49] I think what makes a performance difference is my current sound config :D [20:15:05] have only XRSound enabled, was testing that in another branch [20:15:15] but in this branch it's all Orbiter Sound code [20:15:24] so no special sound code running at all.. [20:20:05] morning! indy91, does "circuit utilization box" in the CSM mean anything to you? [20:21:21] hey. hmm, not immediately [20:22:09] but google helps [20:22:38] specifically in Block II. most of google's results are Block I [20:22:59] was about to say :D [20:23:08] Block I AOH mentions it etc. [20:24:17] so it would be an S-Band thing in any case, right? [20:25:22] can you rebuid? I pushed a modification for the RSI needle [20:25:34] it now extends to the top [20:25:40] sure [20:33:02] Gondos, if I rotate the RSI through 180° then some black dots remain where it is going through [20:33:13] only at the lower end [20:34:20] ok, how do you rotate it manually? [20:34:53] I just loaded a reentry scenario [20:35:15] and then used the Entry EMS - ROLL switch [20:35:19] and rolled the CM [20:37:23] thewonderidiot, I am seeing three relays that potentially are the descendant of the circuit utilization box, but I am not sure where they would be physically located [20:38:18] I'm asking because we have the Block II version in this box in the lab and I'm trying to figure out what all it still does :D [20:38:23] ok thanks, I'll look into this [20:39:38] Gondos, it might be because it's too large now and draws on a surface that doesn't get redrawn as completely white? [20:39:59] basically something where the background isn't redrawn [20:40:25] thewonderidiot, my theory would have been there was no CUB on Block II, but I guess this proves it wrong :D [20:41:24] the relays in the Systems Handbook are just under "Unified S-Band Equipment" [20:42:12] yes there is a white circle drawn to reset the surface [20:42:15] I can see it in a couple of places in the Block II Functional Integrated System Schematics [20:45:01] apart from that, the size looks good enough? [20:45:02] Gondos, yep, sounds like it draws slightly outside of it now, at least on the lower half, near 180° [20:45:13] yeah there is a gray outline [20:45:29] don't know if it should be here in the first place [20:45:57] Size is good. Might just have to make it one pixel smaller or so, to not draw outside the white. Or make the circle one pixel larger or so. [20:46:11] but it's definitely noticable when it goes through 180° [20:48:42] thewonderidiot, can you give me a page? [20:50:07] the relays I meant are also in a box called unified S-Band [20:50:35] C28-1A105 or V36-714001 [20:50:49] ha, right next to the CMC [20:52:25] by extending the circle 1pixel down the issue looks gone [20:53:08] ah you commit was just a different pen? [20:53:11] your* [20:53:15] yes [20:53:29] black instead of white [20:53:38] but I guess that's still not exactly the same as before haha [20:53:54] nope [20:54:26] at least we are slowly getting to a magnifying glass level of differences [20:54:45] I pushed the fix for the stray pixels [20:55:11] I hope it's not the kind of thing that depends on screen resolution or GPU drivers... [20:55:56] ah right, let me check how it looks on the split main panel, before I update to your latest commit [20:56:07] GPU drivers would be annoying [20:56:11] but not much we can do [20:58:06] don't think screen resolution is a problem [20:58:18] it's all the same size [20:58:28] same scaling I mean [20:58:46] except for some special things like the sextant where we have separate bitmaps [20:58:56] did I ever say I want to get rid of the 2D panel eventually? :D [21:01:35] can confirm, RSI doesn't loose any black pixels now [21:10:39] nice [21:12:39] paint has dried [21:13:28] lol [21:45:56] night! [15:52:49] good morning [15:53:53] hey [15:55:23] I got pretty far into some code cleanup last night on some of my code, from my early projects. [15:56:05] I definitely write better code than I did 3 years ago haha [15:57:51] I like Gondos' changes. I will make a pull request in a week or so, that simplifies things a bit more. [15:59:26] making the switch to relays/voltages from things like: if(switch is up) is on my list too [16:00:05] for the communications code? [16:00:47] yes [17:13:07] I had started on removing more places where MissionTime is used in our code. The next bigger thing was the S-Band power amplifier warmup [17:13:41] started on trying to implement it with relays and such, but got a bit confused with the logic in the Systems Handbook [17:13:51] morning! [17:14:05] yeah S-Band power amplifier logic is very confusing haha [17:14:18] might even have toyed around with relays in the circuit utilization box a week ago :D [17:14:23] without knowing it [17:14:40] hahaha [17:14:51] ah yeah the warmup override logic is what got me [17:15:06] so in Block II it only has 3 relays, and I think the S-Band ones might be gone... maybe [17:15:10] and or gate decides if a signal is setting a relay [17:15:19] an or gate* [17:15:30] an AND gate is going into the OR gate [17:15:43] and one of the inputs to the AND gate is a reset signal to the same relay??? [17:15:49] so SET requires RESET... [17:15:56] that's where I gave up for now haha [17:16:09] I'm sure it becomes clearer with the schematics and such [17:16:16] but I just wanted to get rid of MissionTime [17:16:27] the functional integrated system schematics draw the relay logic too... but I think they have errors in different ways [17:16:30] https://www.ibiblio.org/apollo/Documents/CSM%20Functional%20Integrated%20System%20Schematics%20Block%20II%20Revision%20K.pdf [17:17:15] pdf page 19 has some parts of the Circuit Utilization Box... in columns 47/48 and 39/40. I think there's more but that's all I've found [17:17:37] pdf page 95 has PA relay logic [17:20:57] ah I see [17:21:01] it's a box with the same name [17:21:05] but this is EPS [17:21:13] not COMM like in Block I [17:22:38] the Block I version did have some battery-related relays, as well as something to do with SECS [17:23:00] hmm ok [17:26:00] ah it has the equipment to measure main bus undervoltage [17:26:05] https://i.imgur.com/Wg22Vi8.png [17:26:32] the Block II Functional Integrated schematics are too early to have a finding index but the Block I version has it there [17:26:34] https://www.ibiblio.org/apollo/Documents/v14-900112h_vol2_functional_schematics_sc-012_sc-014.pdf [17:40:38] physical location of the box is still a bit elusive :D [17:41:01] I guess you haven't found the drawing number yet? [17:41:08] oh hang on I did find its V36 number [17:41:11] lol [17:41:18] where :D [17:41:21] in a document that calls it the "circuit utilization panel assembly" [17:41:33] https://books.google.com/books?id=hA8v9Xw8udEC&pg=PA36&lpg=PA36&dq=%22circuit+utilization+panel+assembly%22&source=bl&ots=DLaeK0mUG8&sig=ACfU3U06cM6o3trzhHbnHrrefSv1_4Kziw&hl=en&sa=X&ved=2ahUKEwiRos61hLv8AhUcI0QIHTItCNgQ6AF6BAgJEAM#v=onepage&q=%22circuit%20utilization%20panel%20assembly%22&f=false [17:41:50] V36-442213 [17:41:56] which means.... [17:42:46] (I assume that's the same thing; it's really not a box, it's a flat panel with a few relays and things mounted on it) [17:43:03] my guess was near panels 3 and 5 actually [17:44:20] so 44xxxx is electrical installation... xx2xxx is RH equipment bay [18:30:05] thewonderidiot, found it! [18:30:30] Systems Handbook, HSI-481260 [18:30:44] PDF page 212 [18:30:57] location 107C [18:31:46] to the right of the master events sequence controllers [18:32:06] oh nice! [18:32:32] excellent find :D [18:34:58] so now the question is, what all does it actually do lol [18:39:23] well relay K1 is powered when you switch the battery charger on, to any of the batteries [18:39:36] that relay allows power from the CBs to the battery charger [18:40:50] then it has the main bus undervoltage circuitry, signal to the caution and warning system [18:41:46] and then we need to find more instances of the box in the schematics [18:42:04] man I wish the Block II FISS had a component index [18:42:12] we really need to find a later copy of that somewhere [18:43:55] it does not seem to be involved in AC undervolt measuring [18:44:00] that's the AC control box [18:48:26] I'm not seeing it involved in any COMM stuff [18:49:17] there are two more relays that could do something [18:50:55] I didn't find the SECS one in Block I when I was looking for it, but I wonder if that retained its purpose in Block II [18:52:25] what was in the SECS in Block I? [18:58:33] oh sorry, SCS [18:58:51] relay K7 did "FLT COMB CONTROL" [18:59:30] although I didn't find it when I went looking for it [18:59:36] we have the Block I FISS? [18:59:50] ah I see [19:00:02] hadn't downloaded them yet I think [19:00:21] not complete, but we have a lot of sections for various spacecraft [19:00:54] right, downloading them now [19:01:08] I'm sure I could find a Block II equivalent to anything in a Block I SCS [19:03:41] https://i.imgur.com/Wg22Vi8.png [19:03:48] which document was this from? [19:04:40] found a version of it where that relay is struck through :D [19:04:53] for SC-008 [19:06:16] ah sorry, found it just now [19:07:04] oh interesting [19:07:15] that screenshot is from the SC-012/SC-014 version [19:07:33] yeah [19:07:43] but in the schematic I can't find the relay [19:08:03] I'm still not sure this is even the same box [19:08:26] well [19:08:34] it does have the battery charger control in common [19:08:45] but that's about it so far haha [19:13:31] that refers to the flight combustion stability monitor by the way [19:13:53] http://www.astronautix.com/d/details17971.html [19:14:25] ohhh interesting [19:14:35] early CSM had two switches for that, removed before flight I think [19:15:25] but yeah it's possible that there's no real direct relation between the Block I and Block II versions aside from the name [19:15:31] it's a very nondescriptive name haha [19:21:31] aha! [19:21:42] Block II schematics [19:21:50] H2 [19:21:58] PDF page 53 because there are many H2... [19:22:18] location 65 [19:22:27] at the bottom [19:23:16] and it refers to P2 [19:23:24] where relay K3 is located [19:23:28] aha! [19:23:32] nice :D [19:23:49] and K3 is energized if it senses unstable combustion I guess [19:24:10] it's the link from the SPS to the SCS engine on/off logic for that I guess [19:24:26] yep makes sense [19:25:26] Apollo 8 mission report says, as a change for that mission, the FCSM was deactivated [19:27:30] awesome [19:27:39] ....I still don't understand the name "circuit utilization box" :P [19:28:33] haha [19:29:08] for Apollo 7 the switches for the FCSM were forced in the override position [19:29:12] I think [19:29:18] so it couldn't have stopped the engine [19:36:51] lol makes sense [14:53:54] hey [14:56:51] hey hey [15:17:28] do we have any LM code that does anything with HV/LV battery taps? [15:20:41] not quite sure what you mean. HV/LV is implemented so yes, we have code for it? [15:21:15] ahh, I just can't find it in the code. [15:22:02] a lot is in lm_eps [15:24:29] let me check what specifically does the HV/LV thing [15:25:39] LEM_DescentECAch class [15:26:03] LEM_DescentECAch::UpdateFlow [15:27:19] I forgot that I did the control logic for that in detail [15:27:21] LEM_DescentECASector class [16:39:57] perfect. I think I was just searching for the wrong terms [16:48:25] I couldn't remember if we simulated a different voltage when the high taps were selected. [17:06:39] we do yeah [17:06:43] it's an interesting wiring [17:07:23] several layers of ECA classes [17:07:42] the only way to do it properly with all features like power from the CSM etc. [17:07:55] I had to "learn" it when there was an issue with power [17:08:09] first 3 timesteps or so there was no power in the LM [17:08:31] had to do with the order of how things were wired together [17:08:58] it was done in the wrong order so it took some timesteps for power to "propagate" through the system [17:16:48] ahh okay. cool. [17:18:41] I think in terms of load and charge remaining the batteries still aren't giving the perfect voltage though [17:18:43] I'm also seeing that we have some battery temperature failure stuff. this'll be a good test of my new thermal code when I get closer to landing [17:19:20] I would agree. very linear. I can attempt a better discharge curve at some point [17:21:35] I recall if the curve was too steep then it would start become unstable [17:21:57] cycling between two voltages maybe [17:23:04] so maybe it would have to have some logic where the voltage can only change a certain amount of from timestep to timestep [17:23:16] might also be interesting for the Apollo 12 lighning case [17:43:42] oh fun [18:17:04] Hi [18:22:14] morning! [18:24:01] :-D   it is 19:23 in Germany. [18:24:17] 10:24am here :) [18:25:08] You have almost the whole day ahead of you [18:46:43] hey guys [18:48:45] yo [18:59:24] hey [19:12:12] what's up? [19:18:27] NASSP customer support kind of evening :D [19:18:44] hahaha [19:19:33] and you? Still looking at your generically named box? [19:20:17] nah, I'm satisfied with the info we found about it [19:20:30] looking through these schematics reminded me, maybe I should take a look at the SCE again. There were a few things I had not 100% figured out about it. [19:20:36] I can order the drawing from the national archives if we decide to try to do anything with it [19:20:43] oh? [19:20:55] kind of what happens at what voltage [19:21:29] SCE to Aux should not have been necessary, it's automatic. Only because of specific voltages involved was it necessary [19:21:51] oh weird [19:22:33] I think I have said this a bunch of times but by chance Scott Manley did a video on it at the same time I was implementing it. And he kind of got stuck with the same issue of not 100% getting what didn't work [19:22:46] you're saying that there's more to a widely popular Apollo story than is generally told? I'm shocked :D [19:22:52] hahahaha [19:23:34] I think the simplified answer was, automatic switching happens at voltage X, primary system stops working at voltage Y, higher than X [19:24:00] so because voltage was between X and Y it never automatically switched and also didn't work [19:24:10] but I think that wasn't 100% right, have to look at it again [19:24:39] when Ken looked at it he came away thinking that the switch didn't just switch the power supply, it also disabled an undervoltage lockout circuit [19:24:50] so that was his take [19:25:22] hmm maybe, as usual I have forgotten about 90% of what I knew about it [19:25:32] lol sounds about right [19:32:11] everything in the CSM is powered through redundant circuit breakers, just not the SCE :D [19:32:34] it gets power from the flight plan, via one circuit breaker. Flight bus has redundant power from the main buses. [19:32:40] But still, SCE, only one CB [19:32:52] flight bus [19:32:56] not plan of course :D [19:33:36] I guess that's why SCE had this internal redundanc [19:33:38] y [19:33:41] which worked so great [19:47:30] ok that schematic is less detailed than the Systems Handbook [19:55:28] which one? the FISS? [20:02:48] yep [20:03:59] that undervoltage lockout circuit isn't even there! [20:09:59] boo [20:37:29] indy91, https://gist.github.com/n7275/845dafa245c4cf73762842943e1a7c5e [20:50:40] ah, thanks! [20:59:53] indy91, here's Ken's thoughts: https://www.righto.com/2022/05/talking-with-moon-inside-apollos.html#fn:sce [21:07:25] right, I think I had read that [21:07:39] I think there is only one problem with this [21:08:36] "loss of the fuel cells caused the voltage to sag to about 18 volts. Within milliseconds, the voltage climbed to 24 volts under battery power" [21:08:40] that's correct [21:08:44] but the mission report also says [21:08:51] "The signal conditioning equipment was turned off by its under-voltage sensor at 36.5 seconds, when the bus voltage dropped below 22.9 VDC" [21:09:13] so why didn't it turn on again when the voltage got above 22.9 V again? [21:10:20] I think that's the dead end for me. Either the 22.9V value isn't exact or the way the detector behaves makes it only detect a failure at 22.9 but doesn't stop detecting it at the exact same voltage [21:13:33] hmmmmmmmm [21:13:44] yeah, we might need the SCD to get further [21:16:41] it's of course likely that it kept being disabled due to the undervolt circuit, but the numbers don't quite add up. Would be nice to have more detailed schematics, but you would need a level of detail where that under (and over) volt detection is described in full [21:17:07] I think the NAA SCD would do that [21:17:32] possibly the ME* but certainly the MC* document if such a drawing exists for it [21:52:37] one day we will get it right haha [21:53:08] good night! [15:26:42] hey [15:27:32] hey Matt [15:28:05] bad news about my fuel cell N2 pull request [15:28:12] I ran out [15:28:31] of nitrogen [15:28:55] I think that is bad? :D [15:29:43] I probably just need to make the valves smaller [15:30:50] yeah, that would be bad. H2 and O2 would eventually need to depend on it for a reference to their pressure regulators [15:31:22] and loss of pressurization would result in the seals between cells blowing out [15:31:42] "FC pH" alarm [15:32:02] doesn't sound much better than an Apollo 13 scenario [15:36:35] yeah, would be pretty bad [15:39:09] I think our FC mass is still absurdly low in the Orbiter2016 branch, that and my repressurization valves/regulators being too aggressive, I'm thinking, mean it just uses too much N2 maintaining pressure. [15:39:21] I'll have to look back and see where it ran out. [15:39:35] somewhere around 100 hrs I'm thinking [15:40:57] hmm [15:47:04] temperature fluctuations in lunar orbit are a bit more pronounced too [17:05:56] hi [17:07:35] hey Gondos [17:09:01] I think I'm finished with the thread stuff [17:09:12] I've set the PR accordingly [17:09:42] ability to kill RTCC threads has been restored on the last commit [17:11:08] tested it with a "while(true);" in the REFSMMAT calculation^^ [17:39:07] ah great [17:39:48] morning! [17:39:56] hey [17:41:07] hey Mike [17:42:32] hi [17:43:08] I think your Sketchpad PR will be first, I'll have a good look at all the changes soon [17:43:49] I'm checking the performance [17:44:37] it was better in your branch on the 2D panel than I usually get haha [17:44:47] but it might have been sound instead [17:45:09] XRSound vs. Orbiter Sound, in a way both disabled, at least our custom sound [17:45:17] that could have been the performance difference, no idea [17:46:03] my rig has an old Geforce9800GTX+, on a 1920x1080 I go from 22fps to 32fps with sketchpad [17:46:59] oh nice [17:47:06] 20fps with GDI if I open 2 MFDs (checklist and apollo), still 32fps with sketchpad [17:47:17] I like hearing that a lot :D [17:47:32] yeah that is awesome! [17:47:39] but then if you need a random number generator I would choose our 2D panel frame rate [17:47:41] it feels more like my linux experience [17:47:48] with GDI it lags too much [17:48:04] lol [17:48:16] kind of the reason why I was put off from improving our 2D panel, I could never reliably tell if a change actually improved things [17:48:30] no matter how stable my configuration was [17:49:07] sometimes it was some Windows process hogging all the CPU performance [17:49:20] Windows likes doing that randomly [17:50:54] reentry is kind of the best test case for your branch [17:51:02] EMS, altimeter etc. all being used [17:52:21] but I see a bunch more that has changed. Even the AOT [17:53:25] does the sketchpad change effect VC stuff too? [17:53:32] or just 2d? [17:56:33] basically the only things still using GDI are saving the EMS scoll on exit and the FDAI, everthing else is using sketchpad [17:57:32] I know the VC is using the same EMS texture as the 2D panel [17:57:41] I don't know if there's something else [17:57:44] yeah I think the EMS might be the only thing [17:58:03] basically all the meters are animations in the VC [17:58:45] RedrawPanel_Horizon in the LM [17:58:51] that doesn't even seem to be used [17:58:54] what even is that... [17:59:26] arf [18:00:03] it's ok, I can delete it later [18:01:20] was there ever a plan to change the FDAI? [18:01:22] what is oldObj in DrawReticle in lempanel? [18:01:37] I think in some other cases you deleted oldObj [18:01:42] change what about the FDAI? [18:02:21] the oldobj is to save the old pen when changing it [18:02:38] since this function takes a sketchpad we need to restore its state [18:03:37] usually we take a surface and do an oapiGetSketchpad so we don't need to restore since we release the skp ourselves [18:04:07] the FDAI is using opengl, that's a bit ugly^^ [18:05:02] the shuttleA is using an actual 3D mesh to render its ADIball, it may look a bit better [18:05:07] yeah, I don't think any active developer ever changed it much [18:05:23] ... if you need a followup project... [18:05:32] hehe [18:05:54] I don't want to be too hopeful, but full CSM 2D panel had 50-70 fps for me, with dips down to 40 [18:06:00] now I get 130-140 [18:06:06] with Orbiter Sound enabled [18:06:11] nice [18:07:08] a big part of this is probably the MFD [18:07:14] but also round meters [18:07:18] there are a bunch of them [18:08:08] haha [18:08:11] yeah, all the switching between GDI and directX are a killer [18:08:18] clear performance dip when the FDAI has a lot to do :D [18:08:51] but even then [18:08:52] it has to go anyway because it does not play well on my linux branch :p [18:08:56] down to 120 [18:09:07] I'm not sure I have often seen more than 100, ever [18:09:17] that is good news [18:09:42] having sluggish scrolling is obnoxious [18:09:53] I'll switch branches after this reentry to check [18:10:52] MFD buttons of course look a bit different, but it doesn't bother me [18:11:06] if we want to tweak it we can maybe still do that in the future [18:11:45] the FDAI also currently has a bit of unconsistency between 2D and VC [18:24:34] it feels like a bunch of the changes you had to make are for unused code [18:25:23] I wonder how much of the PanelSDK panel code we actually use [18:26:20] checked the Orbiter2016 branch, I think the performance improvement is undeniable [18:26:43] got 73 then dips down to 48 with FDAI moving a lot [18:27:01] 50% improvement with the update, and that is conservative [18:27:22] :) [18:27:26] at least for me. With CPU and GPU and such it's probably going to be different for everyone [18:28:47] having it stable of 60fps is nice [18:28:51] *over [18:33:06] yeah that should really be the goal. I have a 144 Hz monitor but 60 fps is the threshold where I would say "work is needed". I've tried in the past but never had much success. [18:33:16] Didn't think of GDI vs sketchpad being the problem haha [18:44:54] I've changed branches three times now because I had to check "did this really look like this before" did every time so far [18:47:47] Gondos_, what was the problem with the EMS writing to file? Your solution looks a bit like a workaround, converting the data back to the old format for writing to file. Is there no better way? [18:53:58] hey [18:54:04] otherwise, everything else I am seeing looks really good [18:54:06] hey Alex! [18:55:22] have you stopped by the Apollo 9 real time simulation yet? [18:55:26] https://www.youtube.com/watch?v=SyCY5XVvABE [18:55:45] rest period just started. He did the rendezvous today. Slightly rough, but successful [18:56:55] ah cool [18:59:00] not really, the better way would be orbiter exposing the GC function to save to a file but it's not [18:59:39] ah. I tried it, it's not like the simulation freezes when you click the button, nothing like that [18:59:46] so it's fine [18:59:49] since the EMS is written to way oftener than saved to a file, I opted to convert to the fomat needed only when saving [19:02:51] but POINT and oapi::IVECTOR2 are just a couple of 'long' [19:03:21] maybe we can just do a cast with no conversion but it would break if the two become differents [19:05:03] the bitmap is only saved right? it is not reloaded when loading a scenario? [19:07:08] yeah [19:07:12] ScribePntArray is saved/loaded [19:07:25] and that gets used for drawing the current scroll [19:07:45] the current solution is fine. But I guess it doesn't fully solve the Linux issue, does it? [19:08:08] the bitmap is useless then? apart for postmortem analysis [19:09:05] I'll try some lobbying to have a new oapi call in orbiter to expose clbkSaveSurfaceToImage ;-) [19:09:25] but it'll have to wait for openorbiter [19:10:10] I'm not sure how it'll turn out with the D3D9 extensions + gccore stuff [19:10:22] not a fan [19:10:49] if it's a de facto API it should be in the core, not in the GC [19:23:00] lunch break, see ya [19:43:54] sorry, was called away. Yeah the EMS bitmap is only for looking at it after a reentry haha [19:45:07] do I have any fun ones saved... [19:45:30] ah wait a minute [19:46:20] the line is now drawn in black [19:46:23] it was red before [19:46:46] it's a lot better to see in red [19:49:39] how can that have changed though, g_Param.pen[5] paints red [19:49:45] but then I don't really understand much of this code [20:33:52] hi [20:35:40] Gondos_ I created a new branch for case sensitive filenames. Maybe it helps you. [20:35:50] https://github.com/Jordan-64/NASSP [20:41:37] hey Jordan [20:42:40] hi Indy. [20:43:37] Ich habe einen neuen branch erstellt, das thema hatten wir schon mal. vielleicht kannst du es mit den jungs besprechen und testen. [20:44:09] na klar! [20:44:15] CaseSensitiveFileNames [20:44:23] clear name [20:45:11] "268 files changed" no surprise [20:45:33] auch das / und \ wurden angepasst. [20:46:30] hab es letzten sommer kompiliert und es lief bei mir. ob die neue auch funktioniert weiss ich nicht da ich momentan mit den neuen texturen ziemlich ausgelasten bin. [20:47:48] da sind auf jeden fall ein paar Sachen nicht korrekt [20:47:57] Scenarios wurden auch geändert [20:48:03] LVDC_FSPFileName Config\ProjectApollo\Saturn IB Default Flight Sequence Program.txt [20:48:05] zu [20:48:09] LVDC_FSPFileName Config/ProjectApollo/saturn IB Default Flight Sequence Program.txt [20:48:45] windows hat mit / kene probleme [20:48:49] keine [20:48:56] In der Datei wird Saturn auf jeden Fall groß geschrieben [20:50:36] Scenarios zu ändern hat glaube ich auch wenig Sinn [20:50:59] Orbiter speichert es als \ [20:52:04] Oder ist das unter Linux anders? [20:52:42] linux erkennt das \ nicht als pfad trennung nicht an [20:52:59] windows erkennt beide [20:53:03] Also funktionieren die Standard Scenarios generell unter Linux nicht? [20:53:32] vielleicht sollte orbiter auch geändert werden um es kompatibel zu machen [20:54:17] hmm [20:54:32] Zumindest "LVDC_FSPFileName Config/ProjectApollo/saturn IB Default Flight Sequence Program.txt" ist ein Fehler [20:54:50] mit dem kleinen S [20:54:54] gondos hat einen parser geschrieben der es während der laufzeit korrigiert, er ist aber der meinung das es gleich richtig gemacht wird [20:55:17] das habe ich eben auch gemerkt. welche datei ist es? [20:56:08] Alle Apollo 7 Mission Scenarios [20:56:36] es gibt das ganze auch für Saturn V, weiß nicht ob das auch so geladen wird [20:57:29] wahrscheinlich nicht, bis Apollo 12 sind es missions spezifische Flight Sequence Program Dateien [20:57:42] da gibts keine Mission Scenarios [20:58:20] ich muss mal meine nassp datei liste checken ob ich da etwas verändert habe. [21:00:08] haha, das ist ja ein furchtbares Durcheinander teilweise [21:00:16] AS-512-PANEL1:ProjectApollo/sm-panel1 [21:00:22] sm-panel1.cfg [21:00:26] ClassName = smPanel1 [21:00:30] MeshName = ProjectApollo/SM-Panel1 [21:00:41] da ist dann auch jede Groß/Kleinschreibweise dabei... [21:01:18] im Prinzip egal, hauptsache man nimmt den richtigen cfg Namen [21:04:50] das problem ist das manch dateinamen ohne endung  gleich sind zb SM-Panel1.msh -> sm-panel1.cfg [21:10:02] Macht das Skript nicht einfacher [21:14:13] Aber an sich sind das in CaseSensitiveFileNames schon alle notwendigen Änderungen? [21:14:20] nicht unbedingt. handarbeit notwendig [21:14:40] ja.. vorher und hinterher bevor es ge-merged wird haha [21:15:21] es sind sogar zu viele änderungen . zb die ganze visualstudio dateien müssen nicht geändert werden, sind ja eh nur  für windows [21:15:46] ja das hatte ich schon gesehen und war mir nicht ganz sicher [21:15:57] hab sie aber trotzdem gemacht [21:16:06] du wolltest nur mehr geänderte Dateien have als Gondos mit seinen Includes :D [21:16:15] haben* [21:16:27] :') [21:18:35] AlexB_88 is also the top contributor to NASSP in terms of lines changed, because mesh files are tracked by Github and there are many lines in mesh files :D [21:18:42] cheater [21:20:18] wait until i make more changes to the meshes, first place is mine :') [21:21:06] it's a race! Until our GPUs give up [21:22:43] also das mit dem sm-panel1 müsste programm technisch auch zu lösen sein ich müsste nur zusätzlich  vergleichen ob es sich um die richtige erweiterung handelt. [21:23:16] in die cfg dateien kommen doch nur mesh namen? [21:23:23] ist so auch das saturn vs. Saturn Problem entstanden? [21:23:28] mit der cfg [21:23:42] es dachte alle "Saturn IB" müssen "saturn IB" sein? [21:24:22] wenn die namen ohne  endung  gleich sind könnte es vorkommen [21:24:25] hmm, config Dateien haben entweder Mesh oder Modul [21:25:45] also wenn es solche fälle gibt dann muss man das manuell ändern [21:27:33] Hoffentlich wenige [21:28:17] also überall wo Saturn V Default Flight Sequence Program.txt vorkommt ist der fehler drin [21:28:46] ich vermute dass ich es in meine liste kleingeschrieben habe [21:28:54] Saturn IB war das Problem [21:28:57] alle anderen sehen gut aus [21:29:07] Saturn V gibt es auch als Datei [21:29:18] aber wird eher selten benutzt [21:30:06] ich muss mal die liste alphabetisch sortieren und sehen wo gleiche namen vorkommen das macht es einfacher [21:31:19] das macht mich stutzig "ClassName = smPanel1" smPanel1 als datei gibt es keine [21:31:40] Bin mir auch gerade nicht sicher was ClassName überhaupt macht [21:32:00] welche datei war es? [21:32:32] sm-panel1.cfg [21:33:54] wird aber auch von Orbiter selbst benutzt [21:34:00] also nicht veraltet oder so [21:34:42] ok da ist nichts geändert worden. [21:35:33] MeshName = ProjectApollo/SM-Panel1 [21:36:18] Hier kann man sehen ob es sich um eine config oder mesh handelt also wäre leicht zu korrigieren [21:37:54] hatte ich nur erwähnt weil ich es gesehen habe [21:37:56] Apollo 17 - Before PDI.scn [21:38:02] AS-512-PANEL1:ProjectApollo/SM-Panel1 [21:38:06] zu [21:38:09] AS-512-PANEL1:ProjectApollo/sm-panel1 [21:38:32] Und dann haben halt die cfg, msh, ClassName etc. alle eine andere Schreibweise [21:39:31] ClassName wird im Code benutzt, so wird zum Beispiel DeltaGlider mit und ohne Scramjet unterschieden [21:40:36] glaube ich.. [21:44:10] re [21:44:57] if you go back to the wall of German I had some things for you haha [21:44:59] "AS-512-PANEL1:ProjectApollo/SM-Panel1" also das wird etwas kompliziert. ist es ein mesh, cfg ??? [21:45:08] ahah [21:45:19] strange about the red thingy [21:45:38] is it also supposed to be red in the scroll in the VC? [21:45:52] Jordan64, scenario always loads the config file [21:45:57] config file can load the mesh [21:46:20] Gondos, no I don't think so, that was just for the saved bitmap to better see the line [21:46:29] ok that makes it easier [21:46:39] uhh now I am unsure which color it should have actually :D [21:47:13] maybe it was some subpixel shenanigan? [21:50:32] http://moonpans.com/apollo_flown_items/Apollo12-flight-scroll-big.jpg [21:51:18] yeah in-sim it needs to be black [21:51:23] on the bitmap we had it red [21:52:00] why it isn't anymore... no clue [21:52:51] maybe it was not colorblind friendly and someone changed it^^ [21:53:43] haha, nono, it's your PR changing it [21:53:54] preeetty sure [21:54:07] last scroll I saved was middle last year, still red [21:54:17] I can check if something had already changed it before your PR [21:54:20] but I think it's your PR :D [21:56:24] yeah the mesh files are huge [21:56:37] especially the CM VC :D [21:58:15] ok, I'll investigate [21:58:54] well actually I think it's pretty simple [21:58:58] HGDIOBJ oldObj = SelectObject(hMemDC, g_Param.pen[5]); [21:59:15] g_Param.pen[5] is now an oapi::Pen *, not an HPEN... [21:59:26] aaaah [21:59:41] nice catch, I'll fix it [22:00:12] sounds good [22:01:06] really excited about your update now. 2D panel performance increase of 50% is really not nothing haha [22:01:18] yeah that is huge [22:01:21] even if that was only partially a reason to change it [22:01:42] all those 2D panel holdovers... are going to hold over longer now [22:01:50] LOL [22:02:19] ProjectApolloConfigurator.rc    -> "resource.h\0" is this just a zero terminated string? [22:02:58] that's also a Visual Studio file, isn't it? [22:03:06] i think so [22:04:05] what's the shortcut to save the scroll BTW? [22:04:30] and yeah it's probably just a zero termination... better don't touch it, could make VS unhappy [22:05:24] ok [22:05:36] shortcut... it's E [22:06:11] it shows you if you press the MNU button [22:06:13] on the MFD [22:06:23] if you have the left MFD open it would be left shift + E [22:08:51] good night! [23:26:07] Hey AlexB_88 Happy New Year [23:37:32] Jordan64: thanks, happy new year to you! [23:41:36] i have work for you I have new textures for the vc both cm and lm. Some changes have to be made in the source code because the texture coordinates are hardcoded. Since you wrote the code, you know better where to change what. [00:17:39] .tell Jordan64, ah sounds great. Ill be a bit busy this week but hopefully I will find some time sooner then later to do it. Have any previews of the textures? [00:31:30] AlexB_88 https://github.com/Jordan-64/NASSP/tree/HighRes_VC_Textures [00:35:09] .tell indy91 Nitrogen system is fine. I have once again forgotten the "build" part of "checkout and build" [00:36:07] n7275: I have today uploaded the rest of the textures. All the text are done. If errors are found you can report them. [00:36:57] I'll take a look :) [00:38:19] AlexB_88: just take a look at my branch. [00:39:18] These are 4k textures but i have made them 8k and scaled down to 4k [00:41:14] I am on my mobile and have no Screenshots here but maybe n7275 have some. [00:42:39] I can sent some in a few minutes [00:49:39] I took a quick look at it, looks very nice! much crisper [00:51:57] what part of the code needs to be changed? The active texture coordinates I guess? (mission clock, timer, etc) [00:52:46] I guess a lot of those must have loss their alignment with the resolution up-scale [00:53:41] thankfully in the VC there are only a limited amount of dynamic textures compared with the 2D panel which is all dynamic [00:55:53] There are a few talkbacks that still need to be adjusted: https://imgur.com/a/FgvVLwn but overall it looks amazing [00:56:21] ah yes the talkbacks [00:57:15] the DSKY looks so real now [00:57:21] and oxid/fuel percent [00:57:34] holy crap those rotaries [00:57:44] looks fantastic [00:58:56] I have some of them adjusted, look the source code [00:59:32] great [01:00:02] tomorrow I will take a closer look at this, and start on fixing the coordinates [01:00:52] One problem is that the 2d doesn't work as it should after the adjustment [01:01:43] But who wants a 2d Cockpit when we have a better vc [01:08:00] We just need to figure out the optics first [01:16:59] hmm, I am running NASSP with no joystick right now, I used to be able to use the num-pad keys to control ACA/TTCA but now none of them work. Any changes to this recently? [01:19:44] Do you have VESIM checked in joystick config? [01:34:16] it was un-checked [01:36:08] is it needed for keyboard control of RHC/ACA, THC/TTCA? [01:41:01] no, you should be able to use normal orbiter translation/rotation controls [01:41:07] that's what I normally do [01:41:39] hmm and what I used to do too [01:44:00] aha [01:44:48] I have a modified keymap.cfg where I disabled a lot of the default orbiter commands [01:45:07] I just reverted it to the original and now it works [16:35:27] hey [16:38:06] hey Matt [16:39:10] I think Guenter had a message for you from me, but without the "_" :) [16:39:30] I fixed my nitrogen issue [16:40:34] it was a typical Matt kind of problem... [16:41:07] wrong branch [16:44:11] the repressurization hasn't used any nitrogen so far, which makes sense. the pressure tolerance is fairly large on the regulator. if one of the cells cycled between 400°F and 450°F or so it would use a bit. but that would be fairly atypical [16:45:12] always the best kind of fix, doesn't require any changes :D [16:53:01] I was very happy [17:35:59] morning! [17:42:23] hey Mike [17:42:53] what's up? [17:43:10] was checking if Turry's orbit is good for SPS-7 [17:43:21] Apollo 9 SPS-7 is the one that gave me a lot of trouble for the MCC haha [17:43:24] seems good [17:43:34] nice :D [17:43:58] and now I will check if the EMS bitmap is getting drawn in red now [17:44:11] and you? [17:45:48] very red [17:47:08] haven't been working on anything in particular over the past few days. just indexing my collection, since it's past the point of having needed that [17:47:38] writing down what has been scanned and what hasn't motivated me to buy another scanner which should be here tomorrow... I'm going to try using a book edge scanner on those AC Electronics program information books [17:48:09] you mentioned Apollo 17 data cards on Discord [17:48:11] if it works out we should get really nice 300/600 DPI scans of them, which will blow all of the other poor scans we have out of the water [17:48:28] yeah it turns out I did already scan those and just failed to find the scan when I went looking [17:48:42] ah LGC data cards [17:48:47] not to be confused with LM data cards :D [17:49:11] https://www.hq.nasa.gov/alsj/a17/a17LMDataCardBook.html [17:49:15] right [17:49:18] https://www.ibiblio.org/apollo/Documents/apollo_17_lgc_data_cards.pdf [17:50:05] happens to me regularly, not finding a document that I already have [17:50:39] haha yeah [17:50:52] usually because I am looking in the wrong folder [17:51:04] and I didn't name it right so that it gets easily found [17:51:41] yeah I don't know how I missed this one [18:01:11] one last reentry in the VC, because the EMS scroll code was changed, then I think I can approve the sketchpad PR [18:02:45] nice [19:00:42] good afternoon [19:06:14] hey Alex [19:10:08] hey, I had an idea for the COAS. could we draw the reticle with a custom sketchpad HUD? [19:20:50] hey [19:21:41] sketchpad PR approved. I'll wait for Gondos to have the last word on it though haha [19:24:14] after it gets merged I'll have a serious look at the PanelSDK [19:24:23] because we don't even use its panel code [19:24:38] and Gondos had to make a bunch of fixes to something we don't use [19:24:45] I wonder if I can just delete a lot of it [20:10:04] probably [20:16:04] I remember you discovering an alternate vector definition to VECTOR3 [20:16:09] you were... shocked :D [20:18:56] oh yeah [20:23:16] those would be nice to clean up. [20:23:17] at some point [21:54:18] znc is not playing nice tonight, apparently [22:06:48] nothing a reboot won't fix haha [14:52:02] hey [14:55:20] hi [17:22:07] good evening [17:22:17] lol [17:22:32] haha [17:22:34] I guess Guenter had a vacation day [17:24:39] Gondos, any last words on your sketchpad PR? Or is it good to go. I have checked everything I can think of. [17:25:13] hi indy91 [17:25:37] I would have liked to do a final test on OpenOrbiter to make sure it won't explode when we switch to it [17:26:12] morning! [17:26:16] hi [17:27:14] hey Mike [17:28:32] Gondos, sure you can still do tests on OpenOrbiter. I guess you would have to merge it first etc. [17:29:03] I'll try merge the OO PR in the sketchpad branch [17:29:36] but it's a mess the way I have set up my NASSP workspace [17:30:27] I cloned the project inside an orbitersdk [17:30:32] is there a better way? [17:31:02] ah because you have Orbiter itself set up with git [17:31:04] and then NASSP [17:31:15] yes, both are clones [17:31:46] I did some copy/pasting to have something working but it's ugly [17:31:58] I have this problem with Shuttle, my FDO MFD and SSV [17:32:15] my crude way of doing it is copy and moving the .git folder [17:32:37] like, right now I have a .git folder and a .gitfdo folder [17:32:44] git is the active one with SSV [17:32:52] but then I can't use git with the FDO MFD [17:33:00] if I want to work on that I need to switch the folders [17:33:13] not great, there are some issues with files that both use [17:33:19] like gitignore [17:35:05] I have nothing left to do with your branch. Just tell me when you feel happy about it being merged. [17:36:29] I'll see if I can get something out of the cmake stuff I did on linux [17:36:42] if we can co;pile out of tree it'll be better [17:37:27] ok thanks, i'll try with OO this weekend [17:38:17] yeah one step at a time haha. The next step for me is XRSound [17:38:30] yeahm but step that one [17:38:57] man my brain is still in azerty mode^^ [17:39:36] got 2 keyboards, one azerty at work, one qwerty at home [17:39:51] I can send you a QWERTZ one if you need another one :D [17:39:56] lol [17:41:02] someone was dumping a sun type 6 keyboard in the bin, I couldn't resist [17:41:55] I learned the craft on this stuff ;-) [17:42:45] I just switched the caps lock and control keys, it was really too awkward... [17:46:05] spent 5 weeks in the US. 3 weeks needed to get used to QWERTY [17:46:16] 3 weeks afterwards to get back to QWERTZ in my brain [17:46:18] where are you from? [17:46:56] Germany? [17:47:22] yep [17:47:25] and you? [17:47:58] ah, we are neighbour then: [17:48:02] ) [17:48:27] I'm on the other side of the 'Rhein' [17:48:51] Normandy more precisely [17:49:54] ah I forget that you have AZERTZ [17:50:33] AZERTY* [17:51:58] is it a French-only thing? [17:52:08] "The AZERTY layout is used in France, Belgium, and some African countries" [17:52:15] ok [17:52:44] https://fr.wikipedia.org/wiki/ZHJAYSCPG [17:53:05] lol, they must have tested every possible layout [17:53:32] sorry, it's french only [17:54:31] I guess this has the most used keys in the center [17:57:18] yep, took 20 'experts' to come up with this^^ [18:00:22] that is France for you [18:01:11] haha I'm sure we had similar ideas here [18:01:48] so if I just copt out\install\x86-release\Orbiter into my NASSP directorym it should be enough? [18:01:53] *copy [18:03:16] not quite sure what you are trying to do. In your NASSP directory, what Orbiter have you there right now [18:03:38] 2016 [18:03:51] I'm recompiling OpenOrbiter right now [18:04:13] it generates in out\instal\... [18:07:40] I guess that could work [18:07:49] I'm not sure, haven't tried it that way [18:09:03] I'm getting the " error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in IUUmbilical.obj" errors [18:09:06] it's a good sign [18:09:23] it was fixed in the oo branch [18:11:10] oh, the branch is on another repo, I had forgotten that [18:24:06] what actually causes that? [18:25:42] different compilation options between openorbiter and orbiter2016 [18:25:58] now the fun begins, XRSound is not deployed [18:26:42] I copied the .h but it asks for the .lib [18:28:03] ah yes, I did not install irrKlang [18:28:23] btw there is sone directsound stuff in NASSP [18:28:32] is it legacy or still used? [18:31:23] hmm let me see [18:32:05] in the LEM I think [18:33:12] we have scheduled audio for the CSM [18:33:20] like Apollo 7 through the first few hours [18:33:23] but also preflight [18:33:32] for the LM we still have audio for PDI, but it's unused [18:33:39] didn't find a good way to schedule it [18:34:01] I wouldn't be upset if we get rid of it, we haven't used it since NASSP 6 [18:35:32] I think the timed sounds in the CSM use the normal sound setup [18:35:40] Orbiter Sound or XRSound, whatever is in use [18:35:55] only that old LM PDI stuff would use directsound... that's my first impression [18:36:21] ok [18:36:29] one more thing to port [18:47:27] I got something on screen [18:47:47] but it's strange, the MFD background does not look filtered [18:49:40] ima grab a snack, see you [18:50:22] ok [18:50:28] checklist MFD or PAMFD or both [19:42:35] thewonderidiot, congrats, your document collection now looks the same as a NARA inventory [21:34:23] hahaha [21:34:49] I was getting tired of (a) having a big pile of documents unassigned to boxes, and (b) not knowing what box things were in [21:35:03] and was also having a hard time remembering what still needed to be scanned [21:38:45] yeah makes sense [21:38:52] not finding PDFs is one thing [21:39:05] scanning large documents multiple times by accident is another :D [21:45:02] hahah yeah [21:51:45] night! [11:33:50] hi [11:37:34] hey [11:55:01] si, I can confirm there is no crash in 3D VC with openorbiter [11:55:34] however in 2D I can't switch panels, ctrl+arrow keys just scroll the panel [11:55:43] is it a known issue? [11:56:15] I want to check the sextant/scope to see if there are issues with transparency [11:56:55] I think they did some changes in the D3D9Client to handle the violet background by disabling bilinear filteringm that may explain the change in the MFD background [11:59:10] huh, the panel switching issue is weird [11:59:50] is your CTRL key broken :D [12:00:58] oh, it works with caps lock... [12:01:09] did they switch do dinput8 in OO? [12:01:32] no idea... [12:01:46] maybe may config to switch control with caps lock is bypassed by dinput8 [12:02:36] I mean this should be all Orbiter code [12:02:44] we don't do anything fancy with panel switching I think [12:04:47] yes, I haven't tested 2D panels in OO ever on windows [12:05:03] and on linux I don't have the issue [12:05:31] it'll propably be the same in other 23D panel so the issue is with my keyboard config, no big deal [12:05:46] the scope and sextant are looking ok [12:06:20] so I'd say I'm ok with the PR [12:06:27] I've tried the Open Orbiter release, not building it myself [12:06:35] seems the same as always [12:06:37] not with NASSP [12:06:43] but other vehicles with 2D panels [12:08:14] yes, but on my end I physically inverted the Caps lock and Control keys on my keyboard since they are the same size, and did some config to tell windows to invert them in the OS [12:08:26] but I guess direct input is not playing well with this [12:08:27] ah yeah you mentioned that haha [12:09:09] so it's only an issue for me [12:09:25] right [12:09:48] it's merged! [12:09:52] thank you [12:10:05] nice, thx :) [12:10:26] for me I next want to get XRSound merged [12:10:36] now I have to go back to 2016, I didn't make a backup before switching, silly me... [12:10:39] I see dsegrav had some things to say about your thread PR lol [12:11:00] yeah, I hate when there are comments on stuff that you didn't code [12:11:24] the enum stuff is ok, but the int was already there, I just made it atomic... [12:12:22] on which branch are you integrating XRSound? 2016? [12:13:46] I have it as indy91/NASSP/XRSound right now [12:13:50] it gets complicated [12:14:07] arf [12:14:20] CaptainSwag kind of put the update in his OpenOrbiter PR [12:14:52] yes, but the vcproj in this PR are changed to another platform toolset [12:14:56] but I think it's still going to be merged from my branch rather than his, just because I prefer it to be a XRSound update only [12:15:12] not too many updates at once [12:15:15] it's a mess to switch between [12:15:20] true [12:15:27] yes, better to have it self contained [12:15:45] switching to VS2022 will come soon, too, I think [12:16:07] and then it's really only issues with Open Orbiter itself left that we need to solve to switch NASSP to using it [12:16:30] lol, I installed 2022 just after installing windows10, then quickly removed it for 2019 [12:16:37] I couldn't compile a thing with it [12:16:46] neither with cmake or vcproj files [12:16:52] this is ridiculous [12:17:08] I only got rid of VS2010 last year... [12:17:48] last time I used visual studio, it was VC6 back in the days, things have gotten more complicated since^^ [12:18:09] I guess just like Windows itself its [12:18:16] it's kind of layers of bad decisions [12:18:24] somehow still working [12:23:39] no merge conflicts from this update for the XRSound branch at least [12:27:13] :) [14:20:26] hey [14:25:23] hey Matt [14:30:26] sketchpad got merged I see. :) [14:30:49] yep! [14:32:06] being on the 2D panel is fun again [14:37:30] ah right, I wanted to check what happens if I delete the old panel stuff [14:46:05] hmm so many errors, I think I need to do it step by step [14:47:49] aaah this was for adding panels and panel elements with config files like we have for the ECS/EPS [14:48:32] but I don't know if NASSP was ever using it that way [15:05:08] it probably wouldn't even work [15:05:17] 15+ year old code [15:05:37] it's also some old "vessel management" code to specify e.g. propellants in that config file [15:06:07] this is probably something I have to bring up with the others, but I am sure nobody will be against deleting all this [15:11:31] oh interesting [15:11:41] every PanelSDK system is assigned a number [15:11:54] and there is feature where every system above a certain number is deleted [15:12:15] would be used to systems on a specific stage [15:12:20] to delete* [15:12:25] at e.g. CM/SM sep [16:52:16] there is a user manual that was published with the release version of spsdk [16:52:18] https://www.orbiter-forum.com/resources/spsdk-1-7.632/ [16:53:07] I think we can probably clean up most of the panel stuff that we don't use [17:14:09] right [17:14:19] we have already been making a lot of changes [17:24:20] there might be some opportunities to API-ify our custom systems a bit better too [17:51:55] morning! [18:12:21] hey [18:27:59] what's up? [18:29:13] got that PR merged with the big performance improvement. Now looking at what more old code can be deleted [18:29:19] and you? [18:29:50] nice :D [18:30:05] doing some Sunburst punchcards as I'm waking up [18:30:20] I'm going to seriously start digging into Sunrise orbital integration code today [18:30:27] after a couple of weeks of threatening it lol [18:32:22] at least I figured out the W-Matrix init stuff, at least one contribution :D [18:34:34] I'm sure I will have questions for you haha [18:35:08] yeah, no problem [18:35:34] looking at this (and other implementations later on) I know less how this all was actually coded than I hoped [18:35:52] but still, I know how it works on an equation level at least [18:38:21] I'll do another pass at figuring out the scaling of that example state vector [19:09:28] hmm [19:09:33] might have found a clue in Solarium [19:10:59] ooooh [19:11:06] 14467 00000 DENBASE 2DEC 6455 B-14 # EARTHRAD +100 KM SCALED AT 2 TO THE (14) [19:11:24] this octal value is nearly the same as the radius in Sunrise [19:11:31] UNK6205 OCT 14445 # FIXME: WHAT IS ALL OF THIS [19:11:34] OCT 01766 [19:13:04] so about 82km altitude [19:13:13] pretty low, but, who knows :D [19:13:19] haha [19:13:22] no nice round number that I can find [19:13:24] interesting [19:13:30] but maybe with a different Earth radius [19:14:44] not sure who would use 6355 km as Earth radius [19:14:52] that's even a bit less than polar radius [19:16:45] well Solarium I guess :D [19:17:36] lol [13:35:37] hey [14:38:09] hey Matt [15:11:54] a crazy thought has entered my mind [15:12:01] reconstructing AGS flight program 7... [16:14:28] interesting. I've been thinking about that too, but I really have no idea what's involved [16:15:14] other than the procedural differences what could we verify with. do we have any checksums like with the AGC programs [16:15:21] ? [16:19:44] don't think we have checksums [16:20:02] I understand at least one change from FP6 to FP7 on an equation level [16:20:11] but what that involves in the code... no idea yetz [16:50:40] morning! [16:50:45] oh no you guys are up to no good [16:52:38] hey Mike. I guess we should do good things then, like converting AGC listings to punch cards [16:53:01] hahaha [16:55:00] got started on Sunrise? [16:55:21] according to diff there's around 1137 lines different between FP6 and FP8, after removing modern comments and whitespace differences [16:56:07] I've only identified two new features in FP7 so far [16:56:11] from FP6 [16:56:23] requires some erasable shifting though [17:09:18] and yeah I started in on Sunrise. didn't spend too much on orbital integration yet but I did work through all of those flowcharts I got from Don's [17:09:30] I mean, I know two sections that can be copy and pasted from FP8 to FP6. And then the mess begins :D [17:09:45] https://github.com/thewonderidiot/virtualagc/commit/2360f7897c7de20b36515b6edd0a4dcb75323cb5 lots of renaming [17:09:47] hahaha [17:11:22] I do want to get the AEA assembler going I think, just to see what happens [17:13:31] for Sunrise, I guess it's likely that UNK6205 is scaled in such a way that the most significant word is in kilometers [17:14:04] even if, near 80km, that is pretty low for "orbital" integration [17:14:18] velocity (UNK6213) still doesn't make much sense to me [17:14:25] the only round value there is the inclination [17:14:29] exactly 28° [17:14:33] but that's the case with any scaling [17:15:12] whatever variants I have tried, it's either a suborbital or a near or beyond escape velocity [17:15:22] with no nice and round values I could find with any units [17:15:37] maybe Solarium can help again [17:20:45] yeah if you could reconstruct something resembling FP7 that would be awesome [17:21:11] could we learn more about the scaling by studying the code differences between solarium and sunrise? [17:21:26] like looking at where they added or removed shifts? [17:23:31] possibly. I am not yet sure that much really changed though. [17:32:21] although even the KEPLER routine seems to have changes [17:36:46] SCALING FACTORS AND ARGUMENTS [17:36:58] that looks different between Solarium and Sunrise [17:37:34] yeah there's shifting changes all over the place [17:38:21] 27D means decimal instead of octal 27, right? [17:38:27] yup [19:18:56] telemetry downlink language [19:19:00] this is a thing? [19:22:17] hmmm? [19:23:39] in the AGC software. The format of telemety stuff is its own kind of language that the assembler needs to deal with? [19:24:54] oh yeah [19:25:38] it's a bit confusing at first haha [19:27:38] interesting. I knew I couldn't recognize much of the code [19:27:46] but not that it is its own little language [19:28:07] makes sense though. A lot of repetitions, could easily get out of hand with the size of the downlink format etc. [19:28:17] yup [21:00:38] hmm I could use an Apollo 13/14 LM AOH Volume 2 right now [21:00:54] it has a procedure to rescale the AGS from lunar to Earth orbit [21:01:04] and I'm missing FP7 addresses there [21:04:36] does that show up anywhere other than AOH volume 2? [21:06:53] not that I have seen, other than the AGS operating manual of course [21:07:45] they added three addresses in one place. And most of the things after it have not shifted, likely because of this: [21:07:53] ADDR OF SDVX MUST END IN 4 [21:08:16] 714 in FP6, 644 in FP8 [21:08:52] so I guess the puzzle revolves around SDVX being in a place where that works [21:09:08] I know there was some change between FP7 and FP8 so I know how it does NOT work [21:09:22] I guess you have dealt with this sort of situation many times :D [21:09:56] hahaha yes [21:25:01] ah, FP8 manual has long lists of erasables and black bars next to them if they changed [21:25:18] that's a few more than in the introduction section where it lists FP7 to FP8 changes [21:27:38] even if I only know what changed, not how [21:30:43] already don't trust it [21:30:45] sometimes that can be just enough information :D [21:30:58] hah oh no [21:31:15] same in FP6, FP8 and Apollo 13 G&N Dictionary [21:31:19] still marked as some change [21:39:30] ah, editorial changes [21:39:45] compared to the FP6 manual [21:55:08] night! [16:36:51] hey [17:10:30] morning! [17:21:53] hey guys [17:30:57] haven't solved the FP7 erasable puzzle yet, no surprise I guess :D [17:36:33] in a way it's easy to solve. Added complications, I don't really want to move erasables that have the same address in FP6 and FP8 [17:36:46] and all this is right at the edge of the DEDA accessible memory [17:37:01] so I can't push anything beyond a certain number or else it can't be written to [17:38:10] I guess these are the issues they were facing when writing FP7, too [17:38:35] and of course I haven't even started moving code around where I added some, yaLEMAP gave me a few memory overflow warnings [17:43:03] yeah, it can be tricky when starting a reconstruction to find the right change to start with [17:43:17] I usually end up trying a bunch to figure out what makes things the least angry [17:52:50] https://upload.wikimedia.org/wikipedia/commons/3/34/Jenga.gif [17:56:15] hah yeah, exactly [18:03:22] alright, new backup hard drive is in. just kicked off a download of everything we have on the internet archive [18:03:28] I'm curious to see how big it is :D [18:54:20] I need to get some new drives [18:57:46] what's wrong with current drives? [19:36:38] they're old and small [19:37:34] I have a bunch of 1TB drives but nothing larger. [19:37:45] all of them are at least 10 years old. [19:52:10] having multiple drives of the same age can be dangerous [19:52:15] they could fail at the same time [19:52:21] ...speaking from experience [19:54:48] ouch [20:15:56] which is why I need to replace them [21:44:15] night! [21:45:17] thewonderidiot, did your download finish? [21:49:32] hah no [21:50:07] I'm only 100GB into it [21:51:43] oh wow [21:52:30] I'm expecting it to be close to a terabyte [22:01:06] I started making local backups of the LM drawings and pretty quickly ran into storage problems [22:01:47] haha yup [22:01:52] oh hey, while I'm thinking of it. what computer did LEMAP run on? [22:02:13] oh good question. I don't know [22:02:42] for some reason I'm thinking something RCA but I couldn't find anything definitive [22:33:00] Approved gondo's thread worker changes [22:34:33] Actually, need one minor changes. But it is just documentation. I'll keep an eye on it and approve it when he has taken a look at it [23:02:22] hey Thymo. [15:13:27] good morning [15:17:08] hey [15:26:38] I read through the LEMAP manual last night. apparently it ran on a 7094, at least when the copy we have was written. [15:36:20] ah fun [15:36:26] real powerhouse of the time [17:09:35] morning! [17:16:27] hey Mike [17:16:46] I can never find anything useful in the MIT schematics [17:16:53] today I thought I had found something [17:17:05] but I was searching for the LM, what I found was in the CM :D [17:17:16] granted, exact same name. But still :D [17:17:17] hah! what are you looking for? [17:17:21] success rate still 0% [17:17:39] the AOT counter that shows the angle of the reticle [17:18:34] I think it is [17:18:39] COUNTER ROTATING FIXED MTG ANGLE [17:22:32] hmm yeah I think you are right on the title, but NARA is missing that drawing [17:23:06] but we have the one for the scanning telescope with the exact same name :D [17:23:11] in the CM [17:24:47] probably a coincidence [17:26:42] I was looking at one random LM and saw it didn't have the drawing [17:26:47] then I used the search for the name and found it [17:26:56] then I looked at all the other LMs and still no drawing [17:27:06] that's when it dawned on me that I found something in the CM :D [17:27:56] haha [17:28:06] what are you trying to figure out? [17:28:57] https://discord.com/channels/735588859366342678/809545464331370506/1064921184736649216 [17:29:51] ahh [17:30:27] we don't need this drawing -- we can just compare what e.g. Apollo 5 and Apollo 17 had configuration-wise. if they were the same, then the counter must have been the same [17:35:13] LM-1 had AOT 6011000-021 and LM-12 had AOT 6011000-111 [17:36:30] so LM-1 had Telescope Eyepiece Assembly 6011846-000 and LM-12 had 6011846-031 [17:36:39] no major part number change there [17:37:29] and that counter is applicable to all revisions of 6011846 [17:37:32] so I'd say it never changed [17:40:39] makes sense. Thanks for checking! [17:45:11] so I'm starting to understand more about orbital integration in sunrise [17:45:39] not the mathy side that you've been looking at, but its overall structure -- how it's started, what its phases are, how the displays work, etc. [17:45:51] I kicked it off a few times last night and it looks like it might run for a single orbit and then exit? [17:47:39] it puts up a V07N01 looking at address 1315 that updates every 10 seconds ish... it counts its way up to +00900 12345 ish... that +00900 almost makes me wonder if it is minutes into the orbit. 90 minutes is a nice orbital period [18:03:32] oh that's fun [18:03:52] let me check if I can find something like that in the code [18:06:53] does address 1315 have a name yet? [18:06:58] nope, I called it UNK1315 [18:07:03] but I think it is purely for display [18:07:23] right [18:08:30] it gets to the V07N01 via UNK6237, which is really `ADRES UNK1315` [18:10:21] if you want to try it out in the Block I virtualagc, do: [18:10:22] V37E 11E (program should change to 02) [18:10:24] KEY REL (the V07N01 should pop up after you do this) [18:11:51] maybe doing this will help me understand the initial state vector, too [19:22:47] uh [19:23:09] there is absolutely no way that the Apollo 1 AGC could have survived the fire relatively intact right? [19:36:10] possibly? [19:36:16] why [19:36:58] looking at this thing https://airandspace.si.edu/collection-objects/computer-apollo-guidance-block-i/nasm_A19720340000 [19:37:16] at least as of June 1965, this was the computer for the Apollo 1 capsule [19:37:30] if I'm reading this table right [19:38:30] oh wow [19:39:06] https://ids.si.edu/ids/deliveryService?id=NASM-A19720340000cp07&max=900 [19:39:15] and I mean, it does look slightly burny there on the front... [19:39:29] but that could be other decay [19:40:43] do we have a serial number or something? [19:41:17] https://www.ibiblio.org/apollo/Documents/HSI-208496.pdf#page=26 [19:41:22] this is AGC-112 [19:41:44] and the rope allocation report table in this document says that AGC-112 was associated with AFRM 012 [19:42:24] it furthermore says that AGC-117 is associated with AFRM-011 (aka AS-202)... and I believe that held true and that AGC-117 was the one that actually flew on AS-202 [19:44:12] the appendizes to the accident report are very detailed [19:44:40] but it talks about "computer S/N 123 removed due to corrosion on pins" [19:44:44] 124 instead installed [19:44:59] different numbering system? [19:45:22] Block I has four different numbering systems, and it's infurating [19:45:28] hmmm [19:45:37] where did you find that? [19:45:59] https://history.nasa.gov/Apollo204/appendices/AppendixD1-4.pdf [19:48:18] aha, thank you [19:48:24] no, same numbering system [19:48:29] so they definitely swapped this out [19:50:15] I've made the mistake to try and build the Virtual AGC on Windows. Apparently I had that set up a while ago, but I'm not sure if I ever was successful [19:50:23] definitely am not successful today... [19:52:37] can't even get one of the requirements building haha [20:08:33] indy91, I can make you a login on my pi if you want [20:09:39] it builds fine there [20:12:36] ah thank you, but I also have laptop with Ubuntu, I can update there [20:12:47] always worked fine on Linux [21:24:59] thewonderidiot, dumb question, how do I run a custom rope with the Virtual AGC nowadays [21:25:15] block 1 or 2? [21:25:20] Sunrise [21:25:41] I never go through the GUI; I always manually start up yaAGC and yaDSKY [21:25:45] ah [21:25:48] so for Block I, you want to do: [21:26:30] ./yaAGCb1 --rope=Sunrise45.bin --pads=test.agc.pad [21:26:37] from the yaAGCb1 folder [21:26:49] and separately from the yaDSKYb1 folder: [21:27:06] ./yaDSKYb1 [21:27:40] actually if you don't want to use the debugger, start yaAGCb1 with: [21:27:41] ./yaAGCb1 --rope=Sunrise45.bin --pads=test.agc.pad --run [21:29:28] doesn't find the rope. Do I have to tell it in which folder it is? [21:32:35] you might be able to give it a full path, but I usually just copy the rope into the yaAGCb1 folder [21:32:40] yaAGCb1 is kind of finnicky [21:32:42] just did that haha [21:34:04] the two ways you can start orbital integration are with V37E 11E and V37E 12E. that starts up orbital integration ("1") in either manual phase 1 or manual phase 2. they set UNK1210 differently which causes the displays to behave differently, but I'm not sure exactly what the difference is yet [21:34:42] ah great, when I want to start the DSKY I get some wxWidgets error [21:34:48] I do too [21:34:51] just ignore it :D [21:35:05] but I have no DSKY D: [21:36:05] oh huh [21:36:11] I get the option to "Stop" or "Continue" [21:36:20] clicking Continue gives me a working DSKY [21:36:26] error while loading shared libraries [21:36:36] cannot open shared object file [21:36:41] no such file or directory [21:36:46] oh that's a different error from me [21:38:32] what does `ldd yaDSKYb1` give you? anything it needs missing? [21:40:41] yeah something not found. I'll check my install. A wonder that it even built [22:05:21] I give up for today haha [22:05:24] good night! [22:40:09] Merged the Cpp thread api changes [15:26:19] hey [15:31:08] hey Niklas [15:35:03] looking at my collection of unmerged branches today [15:35:32] just getting the CueCards branch for the VC up to date and rewriting it to be flexible [15:48:50] oh that will be nice to have [15:49:46] speaking of branches, we have a few in the orbiternassp/NASSP repo that can probably be deleted [15:54:00] diode_init and syn_check have been merged [15:56:44] oh wow, you do have a lot of branches haha [16:04:30] well locally I have deleted all my branches that have been merged lol [16:04:36] which is the vast majority [16:06:22] maybe I should do a force push to Github or something [16:06:30] that probably gets rid of the locally deleted ones [16:10:33] probably [17:14:13] indy91: You want git remote prune origin for that [17:14:32] D [17:14:40] Do it with --dry-run first to be sure [17:14:53] never heard of prune... sounds scary :D [17:16:03] It removes all stale branches. [17:20:23] hmm, doesn't look like it would be doing anything [17:33:32] morning! [17:46:21] hey Mike [17:52:32] what's up? [17:53:27] somehow people on the forum don't believe in the issues I had with the Orbiter airfoil model for CM and CSM :D [17:53:42] hahaha [17:54:24] they haven't put the Orbiter code for this in a MATLAB script like I have lol [18:11:01] yeah, I was kinda surprised by that [18:29:11] Orbiter updates it's lift and drag forces once per substep, which with default settings can be as many as 10 times per timestep [18:30:45] then it's probably not ideal to get the airspeed vector from the Orbiter API [18:30:52] might not be updated once per substep [18:31:02] but I guess unless you have a huge attitude rate it's no big deal [18:32:32] hmm, I need more cue cards for testing [18:32:39] where are Alex and Jordan when I need them :D [18:33:41] at some point I need to figure out how to use Blender [18:34:35] same [18:35:23] I've been using Solidworks and Inventor for about 15 years but keep saying I just "can't figure it out" [18:35:28] I think I'm just lazy and learning new things is hard, haha [18:35:51] yeah and I am thinking "do I really need to understand this aspect of NASSP, too" [18:35:59] I already had my fingers on too many topics in NASSP [18:36:13] haha [18:38:39] I'm a genius. I made a copy of the mesh and texture, drew some terrible lines on the texture with Visual Studio [18:38:47] and now I have two cue cards :D [18:39:00] at least enough for testing the logic to support multiple cue cards in one place [18:40:44] and I think the way I rewrote the code today will also allow mission specific cue cards fairly easily [18:41:19] nice :) [18:41:21] stuff like the TLI cue cards are different for each mission of course [18:41:29] boost also, slightly [18:41:39] and TLI procedures in general, like, P15 or not etc. [18:42:41] https://i.imgur.com/snN2TpI.png [18:43:09] you're an artist :P [18:43:38] said nobody ever about me, the least of all art teachers in school :D [18:45:08] yeah me too [18:46:17] that one time we were supposed to draw a labyrinth and we were allowed to use rulers and such [18:46:25] I wasn't bad at that [18:46:33] take the ruler away, the grades go down [18:47:11] draw a human face, laughter ensues [18:53:18] indy91__: remote prune only deletes your remote tracking branches. To actually remove them from github you need to manually delete them. [18:54:25] aaah ok [19:04:21] the next cue card I would put on top of the DSKY lights. Who needs those anyway. [19:04:50] then the question becomes how visible they still are through the card. Maybe you could still see them a bit [19:05:16] could be done with a partially transparent cue card mesh... I think [19:21:10] yeah, if you made it very slightly transparent [20:21:39] nice and stable Internet I have today [20:35:45] I learned something. Pointer to an object that is part of a std::vector is bad. [20:36:11] because if that vector gets changed in size the whole vector might be moved somewhere else in memory [20:38:36] ouch [20:41:07] Jordan64, up for a little side project? "side" is barely correct, it involves meshes and textures for the CSM VC [20:42:31] Um was geht es? [20:42:41] https://i.imgur.com/prDIs2l.png [20:43:01] I am writing the code to add cue cards [20:43:09] but I am useless at creating cue cards [20:43:13] Alex made this one for me [20:44:32] it's a separate mesh [20:44:36] normally it's not there [20:44:42] you click on the velcro and it appears [20:44:58] click again it disappears, or another cue card in that place appears [20:45:24] so I could use some help creating a few other cue cards, just so that I can get test having multiple ones [20:47:07] Da ist doch nur Text drauf. Das sollte einfach sein. Wie langweilig 🤣 Ich schreibe deutsch, hab keine Lust den google übersetzer zu benutzen. [20:47:18] ist gut haha [20:47:29] ja einfach für dich :D [20:47:47] Schick mir ein paar vorlagen was da drauf stehen soll. [20:48:19] Alex hat die cue card im CM VC schon richtig plaziert und dann einfach ausgeschnitten [20:48:49] also eine super einfache mesh und dann die Textur, halt das Bild von dem Ding [20:50:02] also müsste es richtig positioniert werden. Ein Problem ist dass ich auch noch die Koordinaten brauche wo ich drauf klicken muss [20:50:36] halt dieses Klettband wo die Karten drangeheftet werden [20:50:59] was hat Alex als Vorlage genommen... [20:51:57] ah ja, Apollo 15 hat gute Scans [20:54:31] https://history.nasa.gov/afj/ap14fj/pdf/csm_cue-cards.pdf [20:54:46] Das ist Apollo 14, aber man kann daran sehen wo die cue cards hinkommen [20:55:01] Ist die textur aus den a15 scans genommen oder ist der text von ihn geschrieben? [20:55:14] a15 scan [20:55:24] Langfristig sollte aber das Datum entfernt werden [20:55:31] oder alles mission spezifisch machen [20:55:37] daran arbeite ich [20:56:07] ok in der Apollo 14 Datei sieht man die DAP Monitor Card die Alex schon gemacht hat [20:56:10] über dem DSKY [20:56:32] ich hätte gerne, um ein bisschen mehr testen zu können, zwei die auf den DSKY Lichtern sind [20:56:46] das wären Saturn V Boost und TLI Cards [20:56:57] https://readux.io/volume/spd4z/page/spd4z_004a.tif [20:57:09] https://readux.io/volume/spd4z/page/spd4z_005a.tif [20:57:14] vielleicht einfach die beiden [20:57:23] gleiche Größe, exakt gleiche Position [20:58:45] und Alex hat es halt in das CM VC plaziert, so dass es die richtige Position hat [20:58:56] und dann ausgeschnitten als separates mesh und textur [21:00:51] Mit sowas bin ich unterfordert 🤣 [21:01:01] haha [21:01:06] Brauchst du nur die 2 [21:01:09] aber es wird NASSP umso besser machen! [21:01:42] die echten Astronauten haben diese Cue Cards relativ viel benutzt. Und ein paar Prozeduren direkt im Cockpit zu sehen wäre super [21:01:48] Das glaube ich. Ich mag feine Detail. [21:01:50] Naja ich dachte mir erstmal die zwei [21:02:06] Ich teste wie das funktioniert mit den clickspots und so weiter [21:02:26] und dann wenn der Code es hergibt ein bisschen Massenproduktion an Cue Cards :D [21:03:22] eine Cue Card ein- und auschalten geht schon. Ich habe einfach ein bisschen drauf rumgekritzelt um zwei verschiedene zu haben [21:03:24] Also das mit den clickspots musst du dann machen oapi Programmiertechnisch bin ich eine NULL [21:03:44] so ist das entsstanden: https://i.imgur.com/snN2TpI.png [21:04:20] hmm ja. Ich brauche im Prinzip die 3D Koordinaten von einem Viereck [21:04:35] das ist dann eine 3D Fläche auf die man klicken kann [21:05:06] also vier 3D Koordinaten, muss nicht super genau sein, kann man aber bestimmt in dem Mesh Editor deiner Wahl gut herausfinden [21:05:28] Warte mal ich Loge mich nochmal am PC schick mir mal nochmal die links. Ausser der pdf Datei. Die habe ich schon. [21:05:40] ok [21:05:42] https://readux.io/volume/spd4z/page/spd4z_004a.tif [21:05:46] https://readux.io/volume/spd4z/page/spd4z_005a.tif [21:07:22] ok die lade ich runter. kennst du die position im cmvc? [21:08:37] naja, über dem DSKY [21:08:46] wie in der PDF zu sehen, seite 5 [21:08:56] über den DSKY Lichtern [21:09:19] darum hat Alex auch das ganze VC in Blender geladen um es zu plazieren [21:09:54] ich kann dir die DAP Monitor Card mesh und texture geben als Referenz [21:09:57] wenn das hilft [21:13:34] das ist ja links neben dem dsky nimmt den ganzen platz an den lichtern [21:15:31] ja das hatten wir uns auch gewundert [21:15:39] vielleicht kann man die Lichter noch leicht sehen [21:15:53] außerdem ist die cue card da nur während des starts und TLI [21:16:59] und sowieso optional [21:17:32] verschiedene Crews haben die cue cards mehr oder weniger genutzt [21:20:47] ist in bearbeitung..... [21:21:31] danke!! [21:24:40] ich hatte das ganze schon mal probiert als wir nur ein 2D panel hatten [21:24:47] aber das ist einfach zu klein [21:24:58] nicht genug Pixel für die DAP Monitor Card :D [21:25:01] hm.. also leider muss ich 2 meshes benutzten die cue cards haben unterschiedliche grösse. ich habe gehofft man könnte nur ein mesh benutzten und die textur einfach blitten [21:25:17] macht nichts [21:25:22] die meshes sind eh winzig [21:25:34] das stimmt. [21:26:01] die CueCard_DAP.msh von Alex ist 2kb [21:26:30] Textur 8MB oh oh [21:26:55] wenn wir mal bis zu 100 davon haben, was nicht völlig unrealistisch ist mit missions-spezifischen, ist das ein bisschen groß... [21:28:05] für die Koordinaten, links vom DSKY sind so zwei Quadrate [21:28:15] hmm nein [21:28:19] das sind die falschen [21:28:35] zwischen DSKY Lichtern und den Registern mit Noun, Verb usw. [21:28:58] das ist das Klettzeug wo die drangeheftet werden, denke ich [21:29:33] also für diese Fläche bräuchte ich vier 3D Koordinate, oben links usw. [21:37:43] https://www.dropbox.com/s/a60ta8expboh35n/Zwischenablage01.jpg?dl=0 [21:38:44] links ist richtig  positioniert. [21:39:09] ja. Größe dürfte auch etwa richtig sein. Weil, noch größer würde schlecht passen [21:39:16] wie sieht es mit der grösse aus? [21:39:19] vielleicht finde ich ja Fotos [21:39:28] ich suche mal. Sieht schon sehr gut aus! [21:40:16] ok dann positioniere ich das zweite auch aus. wie soll ich dir die datei senden? [21:40:52] was auch immer am einfachsten ist. [21:40:58] Ich benutze ja immer Google Drive für sowas [21:41:11] aber Dropbox dürfte auch gehen? Sind halt 3 Dateien... [21:41:12] 4* [21:46:01] hier sieht man nur die cue cards links daneben [21:46:02] https://www.youtube.com/watch?v=ye2xqpVDyZc&t=2141s [21:49:01] das sind aber nicht diese 2. [21:49:36] ja [21:49:38] ich lasse sie so wie auf meinen screenshot. ändern kann man es auch später [21:50:06] ja, ist erstmal ein Prototyp [21:50:25] ok damit es keine komplikationen mit der mesh hierarchie gibt werde ich meine speziele namen benutzten damit die 2 am ende der mesh datei sind. du weisst zzz... [21:50:52] ah genau. Weil du gerne schläfst :D [21:51:15] im Code ist es dann ganz einfach [21:51:17] CueCards.CreateCueCard(0, "ProjectApollo/CueCard_DAP"); [21:51:36] 0 ist der Ort (die verschiedenen Clickspots) [21:51:43] und der Name einfach die Datei [21:52:00] das ist mein Part :) [21:54:58] ok ich mach grad einen test. die cards sollten beide sichtbar sein. der code part wird deiner sein [21:56:01] ja, einfach nur als separate Meshes und der Rest wird von meinem Code gemacht. Wenn das gemerged ist dann wird es auch einfacher für dich zum testen [21:56:16] dann muss man nur noch eine Zeile Code hinzufügen [21:56:48] und für jeden neuen Clickspot halt noch den Bereich dafür [22:17:42] Jordan6469, die Datei ist mit dem ganzen CM VC? [22:17:58] die meshes müssen separat sein [22:18:09] nur richtig positioniert [22:18:23] ah ok. [22:18:31] die werden dynamisch geladen [22:18:49] ich mache es nicht mit mesh group transparent setzen oder so [22:19:01] sondern lade das mesh wenn es angezeigt werden muss [22:19:53] wie hast du denn die beiden texturen implementiert? [22:20:07] weil die beiden cue cards kommen ja an dieselbe stelle da [22:21:31] normalzustand ist das kein mesh da ist. Click auf den Klettband, ein Mesh wird geladen. Klicke nochmal, Mesh wird gelöscht, zweites Mesh (wenn es eines gibt) wird an dieselbe stelle geladen [22:22:45] Ich will halt möglichst flexibel sein mit missions-spezifischen Sachen. Sogar dass eventually die Größe eines Meshes unterschiedlich von mission zu mission ist. Darum würde z.B. nur die Textur ändern nicht reichen [22:23:50] alles schön modular :) [22:23:53] https://www.dropbox.com/s/iqckw462i93mjks/CueCardMeshes.zip?dl=0 [22:24:06] ah great, that was quick! [22:24:42] jetzt komme ich mit den Sprahcen durcheinander [22:24:46] half 12 und so :D [22:25:03] ich dachte du wolltest die einzelne gruppen ein und ausblenden. [22:25:19] habe ich dann falsch erklärt, sorry [22:25:27] letzter Schritt, clickspot Koordinaten [22:25:46] kannst du mir da irgendwas geben? Nur so ungefähr? [22:26:26] Orbiter hat eine rechteckige Fläche zum klicken. Alternativ, ich könnte auch erstmal einen einzelnen Klick Punkt nehmen [22:30:23] hast du die letzten Nachrichten von mir bekommen? [22:32:01] half 12 und so war die letzte. mein internet hat sich kurz verabschiedet [22:33:13] meines auch heute öfters... [22:33:27] habe ich dann falsch erklärt mit den Mesh vs. Mesh Gruppen, sorry [22:33:33] letzter Schritt, clickspot Koordinaten [22:33:36] kannst du mir da irgendwas geben? Nur so ungefähr? [22:33:40] Orbiter hat eine rechteckige Fläche zum klicken. Alternativ, ich könnte auch erstmal einen einzelnen Klick Punkt nehmen [22:35:53] warte mal kurz, der exporter kann auch die koordinaten speichern, das hat alex früher benutzt für die vc schalter [22:36:58] ah genau. In diesem Fall würden ich es dann noch etwas verkleinern. Die DSKY Lichter sind nicht zum klicken da :D [22:37:37] aha! [22:38:56] https://i.imgur.com/ewtIjfi.png [22:39:50] ich glaube die DAP Monitor Card ist ein bisschen zu groß [22:39:58] überlappt etwas [22:42:06] https://i.imgur.com/3TzRdDO.png [22:42:10] sieht aber gut aus! [22:43:23] die müssen so angepasst werden dass die schrift ähnlich gross ist. [22:44:26] die Scans sind unterschiedlich groß. Aber, wir haben auch andere Dokumente wie die PDF [22:44:40] da ist es glaube ich richtig relativ skaliert [22:45:03] zumindest kann man es dann aneinander anpassen [22:46:40] ok, das war doch ein Erfolg. Da können wir drauf aufbauen haha [22:47:02] danke für die Hilfe! Ich werde da in den nächsten Tagen noch ein bisschen dran werkeln [22:48:18] das mit den koordinaten habe ich nicht raus gefunden, vielleicht kannst du die in den mesh benutzten [22:49:19] ja stimmt [22:49:27] zumindest weiss ich dadurch den Bereich [22:49:37] kann ich dann immer noch kleiner machen, nur auf dem Klett [22:52:27] https://www.dropbox.com/s/9k0d1u6imkg3w1f/coord.jpg?dl=0 [22:52:47] ja, damit kann ich arbeiten [22:52:59] die markierte sind die ecken des rechtecks [22:53:27] dann vielen Dank, bis dann, und gute Nacht! [22:53:31] ok. ich sag mal gn8 viel spass. [22:53:34] good night! [16:29:36] hi [16:31:16] hey Gondos [16:35:47] my hard drive just failed me, good thing I just pushed all my stuff [16:36:31] oh no :( [16:37:47] at least I reinstalled on an SSD, way better than the old HDD [16:38:15] just the windows stuff, so I still have my keepass and github ssh key^^ [16:39:38] luckily the d3d9 beta client has been corrected on OF so I can restore my workspace [16:40:20] I had just starting working on network refactoring, nothing much lost [16:40:23] that's the Orbiter related things, I hope you didn't loose any other important data [16:40:55] no no, i installed it a couple of weeks ago for NASSP purposes^^ [16:41:16] so NASSP kills hard drives now :D [16:41:30] hehe [16:41:33] n7275, listen to your inner voice [16:54:32] Jordan64, https://github.com/indy91/NASSP/tree/CueCards [17:03:18] Hi. [17:03:58] indy91: how many cards are all together? [17:05:34] Wouldn't be better to make a separate folder inside the mesh and texture folders for the cards [17:08:44] makes sense. If we have a lot more of them, then they should be in a separate folder [17:09:33] about 30 [17:09:37] but that is per mission [17:09:47] some of them will be different from mission to mission [17:09:50] so it could be a lot... [17:10:18] and then we have the LM :D [17:19:02] 30 and about 30 for the lm? Easy job. Load the texture in gimp, make a rectangle selection with rounded corners, crop the texture, invert selection, delete the selection, export the texture as dds. Blender open vc, import images as planes, select texture, position the texture, [17:20:06] Copy the mesh in clipboard, Start new instance of blender, export mesh. [17:20:57] Forgot. Paste mesh in the new blender and then export the mesh [17:21:15] some cue cards have a whole in them :D [17:21:20] hole* [17:22:32] Ok. Make 4 loopcuts in blender, 2 horizontal 2 vertical, delete the face. Done. [17:23:16] 2 or 3 hours of work. [17:25:10] and for me it would be at least 3 hours until I have learned enough to get the first one done in a satisfying way :D [17:25:51] but yeah I would say, we can start mass production on the cards. My code can handle it. It only can't do mission specific ones yet [17:26:04] but that will come [17:26:32] like the boost card you made is for Apollo 15. Lower Earth parking orbit than the earlier missions. [17:26:39] So already not useful for Apollo 14 and earlier [17:26:58] And the same for me if i start coding 🤣🤣 [17:28:50] that's what you call team work [17:30:32] if you make me the Saturn V Boost card from the Apollo 14 PDF then I could even start implementing mission specific cards [17:31:12] they might look different from each other though, different sources and scans [17:32:39] Do we have any scans of them? [17:32:55] The real cards not the pdf [17:34:07] hmm, we mainly have that for Apollo 15 [17:36:17] indy91 which card was it? [17:36:36] Saturn V Boost [17:38:05] indy91, like in general haha, or wrt buying new hard drives? the first one could be dangerous. [17:38:30] haha just hard drives [17:45:10] Jordan6484, that extra boost card is for me testing mission specific code for the cards. But aside from that we can get started on more cards. Maybe some that aren't different from mission to mission. [17:45:55] is on the way [17:46:38] great [17:46:55] iis in the same place as the other 2? [17:46:56] one downside of the scanned cards, some are full of notes [17:47:02] its [17:47:18] notes can be erased [17:47:24] yes. In fact it is the same card as one you already made [17:47:29] just from a different mission [17:47:33] so yes, same place [17:47:39] same size... I think [17:48:10] the Apollo 15 card you already made ends up in a 90 NM altitude orbit [17:48:32] Apollo 14 and earlier they used 100 NM altitude parking orbit [17:48:42] that's why the content of the card is quite different [17:48:53] the numbers [17:52:03] I guess you can use the same size of mesh then [17:52:13] just a different texture it uses [17:54:01] https://www.dropbox.com/s/c9ok8c1gavbm4sn/SaturnVBoost_CueCard.zip?dl=0 [17:54:38] thanks! [17:55:45] Gondos https://github.com/Jordan-64/NASSP/tree/CaseSensitiveFileNamesCan you take a look and say which files are important for linux and which ones can be left out? [17:56:01] https://github.com/Jordan-64/NASSP/tree/CaseSensitiveFileNames [18:02:40] morning! [18:02:43] was \ or / the one that Linux doesn't like? [18:02:47] hey Mike [18:04:01] windows \and / linux only / [18:04:27] indy91, I have done some math and am pretty sure that this number: https://github.com/thewonderidiot/virtualagc/blob/sunrise45/Sunrise45/ORBITAL_INTEGRATION_PROGRAM.agc#L216 is exactly 0.072 hours :D [18:05:04] Can someone change the file names so that they are the same? eg saturn should be saturn. I've changed some, you can take them as an example. I want the names to be the same everywhere. My idea is that every word starts with a capital letter and the rest is lowercase. Abbreviations should be capitalized. etc. You can use a file compare program to [18:05:05] compare the differences I made. these are the files with the nassp file names. [18:05:14] https://www.dropbox.com/s/d5q3zt1j6wss4iz/FileStruct.txt?dl=0 [18:05:29] https://www.dropbox.com/s/k50xkowuvbjgexl/FileStructRenamed.txt?dl=0 [18:05:47] thewonderidiot, what was that in octal [18:06:33] saturn should be "Saturn" [18:08:01] I guess over the years people have used different conventions for that [18:08:19] in some folders all files are all lower case [18:08:24] Yes and I want to correct that [18:08:32] 11771 22015 [18:09:24] that is 0.072 hours? What a strange scaling... [18:09:57] it's not quite a scaling [18:12:08] I guess that number is an integration step size [18:12:13] yeah [18:12:20] a bit more than 4 minutes [18:12:22] and TET in Block I is in weeks [18:12:26] pretty usual for Encke's method [18:12:58] and DT/2 is multiplied by EARTHTAB before it is added to TET [18:13:23] so this number times EARTHTAB with some shifting gives you a timestep in weeks [18:14:16] and I want to know what you think about EARTHTAB [18:14:17] ah yes, time in weeks instead of centiseconds like usual, of course :D [18:14:25] why is it 400 / sqrt(mu) in Solarium? what is the 400? [18:16:36] Jordan6484, I'll look at those two text files. I'm sure people like dseagrav also have an opinion about naming conventions haha [18:16:52] it's actually a really funny numerical coincidence. remember how I saw the +00900 00033 when orbital integration exited and thought it must have been minutes, and that they set it up to exit after a single orbit? [18:16:56] I was right but for the wrong reason [18:17:02] that number is essentially TET, in weeks [18:17:16] but it just so happens that one ten thousandth of a week is almost exactly 1 minute (it's 1 minute 0.48 seconds) [18:17:31] so 0.00900 weeks is indeed 90 minutes [18:17:50] thewonderidiot, https://i.imgur.com/0b8Fn5E.png [18:18:00] this is how Luminary and Colossus determine the maximum step size [18:18:05] as a function of radius [18:18:21] if you assume the radius is nearly constant (low parking orbit only) you could use a fixed value [18:18:24] ah interesting [18:18:33] the EARTHTAB in Sunrise is also different from Solarium [18:18:41] yeah [18:18:51] everything rescaled... [18:18:56] not a clean multiple of sqrt(mu) [18:19:00] indy91 which card has a hole, i want to test one. how about the left next to the dsky [18:19:25] Jordan6484, ah I was actually looking at this one: https://readux.io/volume/v016s/page/v016s_15F.tif [18:19:28] with the text [18:21:13] yeah that is to the left of the DSKY [18:21:20] the hole is for the event timer [18:24:34] thewonderidiot, interesting that J2-J4 weren't rescaled from Sunrise to Solarium [18:24:44] just slightly different values [18:24:59] especially J4, but I think that is consistent with the state of knowledge [18:25:07] about the value of these [18:27:09] the 400 could be identical to 0.3*radius^(3/2) [18:27:11] with some scaling [18:28:36] hmm [18:29:35] the math in Sunrise is quite different [18:29:46] kind of doubting that even is 400/sqrt(mu) [18:30:25] it's definitely not [18:30:32] it could be like 468/sqrt(mu) [18:31:05] UNK6113 has a lot of interesting variables [18:31:39] oh I have almost all of those named [18:31:49] I just haven't committed/pushed that yet [18:32:01] UNK1321 is the end time of the simulation, so 0.009 weeks [18:32:10] UNK1315 is the copy of TET put up for display [18:32:24] UNK6233 is a small epsilon or something [18:33:35] but it's saying, if TET2 + UNK6233 is greater than 0.009 weeks, then stop the simulation [18:34:25] otherwise get rid of UNK6233 and see if adding UNK6231 would go past the end of the simulation. if it doesn't, you can use DT/2MAX [18:34:39] if it does, you need to directly calculate DT/2 so that it stops exactly at the end of the simulation [18:35:16] so UNK6231 and DT/2MAX are very closely related to each other. effectively the same number but with different scaling [18:37:28] hmm you seem quite convinced of that 0.009 weeks value :D [18:38:20] but yeah, UNK6223 definitely is the start time of the integration [18:38:23] 0, stored in TEI [18:38:35] and UNK6227 is the end time, stored in UNK1321 [18:41:22] https://www.dropbox.com/s/b2szvw3bvnl8wuj/SPS_Burn_CueCard.zip?dl=0 [18:41:49] ok those are 2 pages but i only did one [18:42:01] yeah the other page is the backside [18:42:09] that's why both have the velcro patches [18:42:19] I put the meshes and textures in folder called CueCards now [18:42:30] and made the necessary edits to the mesh [18:45:02] do the velcros have to be on? i removed them [18:46:19] I think so. Otherwise you would only be able to put on side on the panel [18:46:31] I'm about as convinced about the 0.009 weeks as I can be, haha. Solarium is definitely using weeks for TET, and TET=0.009 would be 90 minutes, the right time for one orbit, if Sunrise is also in weeks [18:47:27] put one side* [18:49:31] yeah you are right, 0.009*2^28 works as the scaling for UNK6227 [18:50:10] maybe velocity is also in "per week" units then [18:50:15] it totally could be [19:04:13] https://readux.io/search/?q=apollo+cue+cards&sort=_score [19:04:16] I found them as a pdf, don't have to load each one individually [19:05:31] yes I have them downloaded as PDF. Didn't want to give you huge PDF files as an example if I can directly link to an imagine :D [19:05:40] image* [19:05:59] but for "mass production" the PDFs are probably easier to handle [19:06:02] https://readux.io/volume/scnbw/page/all [19:06:07] is this also needed [19:06:23] the answer is mostly no haha [19:06:44] the thought came to me today that we could put checklists or procedures like that on meshes, too [19:06:55] but that needs better code handling that [19:07:01] for now it's only cue cards [19:07:46] ah and data cards aren't super useful if we can't draw on them [19:08:55] you can use a marker and write on the screen :-D [19:09:49] long term idea, let the MCC fill out data cards [19:09:55] and show them in-sim [19:11:02] drawing on screen reminds me of... [19:11:04] https://youtu.be/hqf2_5SwaL8?t=240 [19:16:05] it is a long time ago. great movie. [19:17:15] I'll say goodnight for now. I'm still with the mobile on if it doesn't disconnect automatically. [19:18:25] Got some work to do now figuring out the clickspot for the SPS burn card and the mission specific logic. Thanks! [19:25:14] thewonderidiot, still not getting a nice velocity vector from UNK6213. Sunrise really doesn't like me... [19:26:04] hmmm [19:26:35] Solarium has velocity in meters/second apparently [19:26:40] so maybe it won't be weeks [19:26:55] I've tried so many combinations by now [19:27:04] mostly focused on centiseconds [19:27:09] that's probably wrong [19:27:23] yeah I think it's most likely seconds [19:27:48] do you know exactly what these are in Solarium? [19:28:02] if not.... could we figure it out by looking at your Apollo 4 NASSP scenario? [19:28:29] I know I had successfully uplinked state vectors in average G and orbital coasting [19:28:33] which have different scaling [19:28:46] so probably [19:32:23] in at least one of the two it was still meters, meters/cs and cs [19:32:27] centiseconds [14:10:05] hey [14:30:42] hey Niklas [14:34:01] I was experimenting with SetVisibilityLimit() last night [14:35:36] I can make vessels show up a bit farther out, but not much. once their angular size drops below half a pixel or so. they don't get rendered. [14:35:48] hmm right [14:36:19] so there might not be much we can do? [14:38:21] we can increase the "size", the one that gets set by SetSize(), but I wasn't sure if that would have other implications [14:49:06] probably not too many [14:50:58] radiation force [14:51:27] moments of inertia if you never call SetPMI in the vessel class [14:51:31] but we do that of course [14:52:04] default attitude thrusters. Didn't even know that was a thing, but also have custom ones of course [14:52:25] the reentry particle stream [14:52:33] not sure if we always override that [14:52:38] have to check [14:57:42] maybe I should just buy a higher resolution screen haha [14:58:04] the size is used in the old aerodynamics model for generating attitude rate damping moments [14:58:45] some surface contact logic [14:58:52] if (alt > 2.0*size) return false; // no danger of surface contact [14:59:36] I think that's about it [14:59:57] so nothing super problematic but making the size huge just for visibility could lead to potential issues [15:17:21] yeah. I don't think I want to down that road. [16:24:56] morning! [16:28:07] hey Mike [16:46:28] what's up? [17:37:59] working on the cue cards code [17:38:13] not quite sure how well it will scale, some of the cards are different for every mission [17:46:32] I need to stop thinking of EARTHTAB as a unit conversion of something [17:46:40] pretty sure it's just a scaling factor [17:46:43] hahaha [17:48:04] my thought was that it essentially mu in disguise. DT/2 isn't just a delta time, it's a delta time that includes sqrt(mu) already multiplied in [17:48:40] yeah [17:48:44] and as far as I can tell it's the only place in the code where mu appears [17:49:35] the relevant calculations are done in units of mu, so calculations involving mu just have to multiply by 1 [17:49:45] That's why the RTCC uses units of Earth radii [17:49:52] right [17:49:53] simplifies certain calculations [17:50:02] have you got a name for UNK6231 yet [17:50:05] I really wish I understood the difference in EARTHTAB between Sunrise and Solarium [17:50:13] trying to figure it out :D [17:50:22] let's see, UNK6231 [17:50:51] oh UNK6231 is also DT/2MAX -- 0.072 hours [17:51:07] it's directly in weeks [17:51:17] oh they are identical? [17:51:18] while DT/2MAX includes EARTHTAB already multiplied in [17:51:20] ah [17:51:49] makes sense [17:51:57] in UNK6113 it either uses DT/2MAX [17:52:07] and doesn't have to multiply by EARTHTAB [17:52:24] or it uses the time remaining to the final time [17:52:31] in which case it divides by EARTHTAB [17:52:35] yep exactly [17:52:56] UNK6113 is basically the integration step selection [17:53:00] yup [17:53:22] what value do you have for UNK6233 if time is in weeks? [17:54:05] or have you not converted it yet [17:54:37] that one I haven't converted yet -- let's see [17:56:42] 0.6 seconds [17:56:53] yep, agreed haha [17:56:58] just got there myself [17:57:36] pretty large [17:57:47] later they use 3 centiseconds [17:58:27] oh does this have a name later that I missed? [17:59:30] I mean in Colossus/Luminary [17:59:55] just the criterion to stop integration [18:04:21] I think it's DT/2MIN [18:06:45] in Solarium it's KEPSILON? [18:06:52] looks like 2 centiseconds [18:07:56] hmmm [18:08:35] yeah you're right [18:08:46] KEPSILON might be the right name to use in Sunrise then [18:08:56] I would agree [18:13:43] I'm not quite sure what to call UNK6231 since it is the same as DT/2MAX but without EARTHTAB [18:20:20] DT/2MAX is only used as a max time [18:20:27] UNK6231 is also used for checking [18:20:38] only used for checking really [18:20:58] MAXSTEP or something maybe [18:21:10] it's the maximum step size, while DT/2MAX is the maximum value for DT/2 [18:22:05] not really a clean number of minutes or seconds haha. 0.072 hours, or 4.32 minutes, or 259.2 seconds [18:24:54] what was the ultimate proof for the weeks scaling again? :D [18:25:04] This low orbit has a period of 85 minutes btw [18:25:06] not 90 [18:25:24] I should plug that initial state vector into a script [18:25:29] maybe it does something interesting [18:25:39] like apogee exactly 100 km or something, it's possible [18:28:20] I guess no ultimate proof, but the Solarium documenation all refers to weeks being the internal time units, so I went with the assumption that they didn't change it [18:29:29] and yeah, I was planning on running a hacked yaAGCb1 build tonight that outputs the state vector at each timestep for plotting [18:29:46] which are the best variables for that? VRECT and RRECT? [18:31:11] I can also include anything you think might be interesting :) [18:32:46] thanks to Encke's method it's not so easy to tell which variable you need to look at :D [18:33:21] hahaha damnit Encke [18:36:35] I'm checking [18:37:51] RRECT would probably not change at all during one orbit of integration [18:40:42] ah btw, if you havent named UNK6146 [18:41:07] uhh [18:41:24] nevermind [18:41:28] I would have called it UNK6146 [18:41:33] no [18:41:35] RECTIFY [18:41:40] but there already is a RECTIFY [18:42:38] wait [18:42:51] what's UNK1431 again? [18:43:22] that and UNK1437 would be absolute position and velocity [18:43:35] but I don't think it's called every integration step [18:46:08] well maybe I named my RECTIFY wrong :) [18:46:22] and I think it is called at every integration step [18:47:08] during the setup up in UNK6000, shortly after setting up the initial position and velocity in RRECT, RCV, VRECT, and VCV [18:47:21] it loads the address of UNK6146 (the display routine) into STEPEXIT [18:48:26] I think your RECTIFY is correct [18:48:42] I think I called UNK6146 "FDISPLAY" locally since it ultimately ends up putting up the V07N01 display [18:48:45] UNK6146 basically does the same but stores the data else where [18:50:24] but yeah. UNK1431 and UNK1437 are position and velocity vectors that are never used. so I think they must be outputs for display [18:50:39] so I'll include those in my log [18:52:49] that's why that probably was an extra little routine [18:53:05] because normally you would have a hard time getting the absolute position and velocity vectors [18:53:17] there are only really temporary ones, changed during one step [18:53:27] ALPHAV [18:53:57] and RECTIFY also gets called when the deviations are growing too much [18:54:11] so they added their little debugging RECTIFY with UNK6146 [18:55:43] RECTIFY ONLY gets called [18:55:57] so if UNK6146 is called more often, then that's not for any calculation [18:56:05] just display/debugging [18:56:25] that makes perfect sense then :D [18:57:21] RECTIFICATION REQUIRED IF THE LENGTH OF DELTA IS GREATER THAN .5 (8 KM). [18:57:29] 8 km is pretty small [18:59:19] Colossus/Luminary check position and velocity [18:59:45] but I guess in LEO rectification mainly happens if the position deviation has grown beyond 1% of the current radius [18:59:53] so like 66 km [19:00:13] with 8 km there could be a rectification in one orbit [19:00:19] J2 is strong [19:02:12] so do you have ideas for names you like for UNK1431 and UNK1437 (and maybe UNK6146, if you don't like FDISPLAY?) :) [19:08:07] FDISPLAY is fine [19:08:18] UNK1431 is RDISP, UNK1437 is VDISP [19:08:20] or so [19:12:15] that's exactly what I would have named them :D [20:13:05] oh you probably also want a time tag for the state vector [20:13:21] but I think that would just be TET... [20:14:47] should be an interesting comparison [20:30:56] I was going to use UNK1315 [20:31:01] which I've been calling TETDISP [20:45:29] ah yes [20:45:32] that is good, too [21:24:24] hi [21:35:24] hey Jordan [21:38:33] hey [21:38:53] Jordan64, https://i.imgur.com/dsxdJQO.png [21:38:58] almost didn't work haha [21:39:18] apparently the FDAI takes a lot of panel area where other clickspots don't work [21:41:48] and the areas of the velcros? [21:42:38] the fdai shouldn't have any click points, right? [21:42:40] yeah that was the problem. I had to make the click area smaller than I wanted to [21:42:49] correct, but the FDAI has a panel area [21:42:56] I think it checks that first [21:43:16] so it sees "ah, there is a panel area FDAI where I don't need to process mouse clicks" [21:43:41] so the click area is only right under the event timer [21:43:45] not further left [21:43:48] no big deal [21:44:02] I wonder why is that? [21:44:25] when panel areas overlap it probably only processes the first one [21:44:37] your vc looks so ugly :-D [21:44:57] haha [21:45:04] maybe I can make the FDAI area smaller or something [21:45:54] that would be an option. [21:46:09] but no big problem [21:46:42] I've been looking through our documentation [21:46:56] for Apollo 8 and 10 we have no TLI cue cards and no numbers for it either [21:47:09] but for some missions we could reconstruct cue cards because we have the numbers [21:47:18] the boost card especially [21:47:24] we have the numbers for all missions I think [21:49:33] it should be that the click points are on the velcros. otherwise no one will find them [21:49:54] true. There are two velcro spots there [21:49:57] the right one works [21:50:01] just below the event timer [21:50:12] just the one further left not quite [21:51:17] because of FDAI interference, apparently [21:55:26] now I am wondering what I need for a release of the cue card update [21:56:01] mission specific cards for every mission is something that can come over time [21:56:13] maybe the back side of the SPS burn cue card [21:59:14] maybe the very long cue cards in between SPS burn and boost cards. There are boost, abort and TLI procedures there [21:59:21] but it can always be expanded over time [22:11:37] I'll send you a new texture, the one with the hole, I changed something there, you can check it [22:11:52] sure [22:14:54] https://www.dropbox.com/s/2hitxyb6gf3gzfd/SPS_Burn_CueCard.msh?dl=0 [22:15:39] https://www.dropbox.com/s/pk2qt4vxio5fz30/SPS_Burn_CueCard.dds?dl=0 [22:16:27] I have all files in CueCards subfolders now [22:16:33] so I'll change the mesh to use [22:16:36] ProjectApollo\VC\CueCards\SPS_Burn_CueCard.dds [22:16:43] ok [22:19:35] oh I thought you had added the velcro spots on the top of the card. Now I don't really know what changed :D [22:20:34] ah [22:20:36] color [22:20:46] before it was very white [22:21:11] now it looks more like the boost card [22:21:17] that's good [22:25:07] difficult to tell how much the cards went yellow in the last 50 years [22:25:11] https://www.flickr.com/photos/projectapolloarchive/21672887342/in/album-72157659052908231/ [22:25:35] fairly white, but probably not bright white, on the actual flight [22:29:01] wanted to test 2 things. firstly the color and secondly the hole is no longer a hole, i made the texture transparent at that point. it doesn't matter much compared to the rest of the VC, but it saves a few triangles :-D [22:29:28] aaah ok [22:29:46] so it passed the test, because I didn't notice a difference hahaha [22:29:54] making it white is easier, reduce saturation and maybe increase the contrast a bit. [22:30:59] the meshes consist of only 4 vertices, i think alex rounded those in the mesh. [22:31:15] yeah I noticed that his mesh had more data [22:31:50] my corners are transparent. saves triangles. [22:33:42] I have an idea. can you hide mesh groups in oapi? if so, then we could pack all the cards into a mesh and only show those that should be displayed. saves files. [22:35:14] I don't think that really helps with mission specific cards [22:35:33] eventually we will have a boost card for every mission [22:35:40] 4 TLI cards for every lunar mission [22:36:02] and no TLI card for Apollo 7 and 9 [22:37:00] well [22:37:10] maybe one mesh for each mission could work [22:37:54] I'm not so worried about number of files [22:38:07] only total size of the textures would eventually could have [22:38:16] we eventually* [22:41:03] having multiple meshes in the same place is no problem? [22:49:24] there will be as many files as cards x2. mesh and texture. The mesh sizes are irrelevant, the textures will be around 300kb, I just reduced the texture I just sent you by 50% and it has this size, the text is easy to read. with 50 cards it will total 15 maybe 20 mb because of the size of each card. [22:51:30] because the cards are different for each mission, the only way I could see to reduce number of files is one mesh per mission. And then hide mesh groups in code. That could work, but it makes the code more complicated. [22:53:17] since you write the code, you decide. It would probably be better that way, since it's easier to add new ones. we are leaving it like this. [22:55:09] I'll think about it. It's a bit of a different concept and would require rewriting most of the code. But it could be better. [22:59:19] but yeah, would be one mesh per mission. With one mesh as the default one [22:59:33] don't want to load all the meshes for all missions all the time :D [23:15:29] mesh visibility scares me [23:16:52] why? [23:19:12] n7275, this? https://i.imgur.com/yqlAVL1.png [23:19:15] :D [23:20:51] good night! [00:39:27] ahhhh [00:39:33] yes haha [06:32:46] .tell indy91 I pushed where I'm currently at on orbital integration scaling/naming -- along with my inline notes from figuring stuff out, which I'll pull out at the end: https://github.com/thewonderidiot/virtualagc/tree/sunrise45/Sunrise45 [17:29:21] hey [17:29:55] morning! [17:30:11] see Discord :D [20:07:24] hi [20:11:56] hey Jordan [20:12:24] didn't make any updates since yesterday but I pushed the latest state of my CueCards branch [20:13:05] question about texture sizes [20:13:10] dds files need to be quadratic? [20:14:14] They work the way they are, but it would be better if they were divisible by 4. [20:14:31] ah ok [20:14:39] I thought that was a general limitation [20:15:11] By the way, I took png files and renamed them to dds and they loaded without hesitation [20:15:39] ha, that's unexpected [20:15:51] Alex' DAP Monitor Card texture is a lot larger than it needs to be I guess [20:16:03] it is 4096 x 4069, that's why I asked about quadratic [20:16:08] 4096* [20:17:05] I think before the branch gets merged that texture needs to be made a bit smaller [20:18:15] they can also be 1024x4096, for example, and should be divisible by 4. many cards do not have a 1 to 1 aspect ratio [20:19:25] yeah I was worried about the very lengthy ones we haven't added yet [20:19:41] with boost, abort and TLI procedures [20:19:46] damn, i have another problem, my ems_scroll is not displayed :-( [20:20:37] with the higher resolution? [20:20:58] yes. it worked a few days earlier. [20:28:27] it's all white now? [20:29:27] yes, but I didn't make any changes to the ems. [20:30:03] as i sayd, a few days back it worked [20:30:09] code wise Gondos made changes, but they only should affect scroll saving [20:30:30] did you switch branches since then? [20:33:04] I try to keep my branch up to date with nassp [20:33:12] can i revert my local git to an earlier point in time? [20:33:51] without changing my remote branch [20:34:01] yeah you can checkout an earlier commit [20:34:07] but I would only do that for testing [20:34:37] not starting to do commits from an earlier point [20:34:55] I have several copies on the hard drive. i use a dummy for this [20:35:38] like, this previous commit from Gondos [20:35:39] https://github.com/orbiternassp/NASSP/commit/9ecfd401afe6b0034a06be6578e9558efe30cc7e [20:35:47] that long ID at the end [20:35:50] you can do [20:35:53] git checkout 9ecfd401afe6b0034a06be6578e9558efe30cc7e [20:36:08] just have to know the commit ID for where you want to go back to [20:36:40] can definitely help tracking down the change that broke something [20:39:22] git.exe archive --output="D:\OrbiterSVN\jordan.zip" --verbose 8ab97a13c4a60c54f5a7cff225e25681664267b1 -- [20:39:58] i made this. will try it on my dummy folder [20:40:49] everyone has their own method haha [20:41:15] I'm not sure many people beside me use this weird mixture of git bash and git GUI... [20:43:05] For me as a beginner "programmer" it's the easiest way. :D [20:48:19] thank god it's back :-D [20:49:24] but what is the error now? is it due to gondo's changes? are they not compatible with mine? [20:51:24] it can't be those changes [20:51:39] it's really just in the way the scroll is written to a file with the PAMFD [20:57:24] our current scroll works? [20:57:32] but not yours? [21:01:52] I have to check what I've changed in the meantime. [21:02:26] unnecessary work again :-( [21:07:08] yeah annoying when this happens. sometimes it's an innocent change, but you have to trace down so many things [21:09:49] can I help? I see you have HighRes_VC_Textures on Github [21:11:54] haven't had a look at that yet anyway [21:12:00] so I'll check it out [21:16:22] ooh [21:16:26] looks quite different [21:16:28] especially the EMS [21:16:31] so white :D [21:16:34] but no, looks great! [21:22:10] ok, your previous commit, still worked [21:22:19] so what could have happened in between... [21:25:52] experiment, all the code from the current commit, but your textures from the previous commit that still worked [21:26:56] I made some changes to the TALKBACKS. just checked everything again. I'll recompile it, let's see if it works now [21:29:04] ok, with my test EMS is still white [21:29:19] that means you didn't break the textures themselves [21:29:37] it has to be any of your code changes or any that came from the Orbiter2016 branch [21:30:48] it's definitely not because of the textures. that must have something to do with the code. [21:33:16] oooh [21:33:27] it must have been the change to sketchpad after all [21:36:15] https://github.com/orbiternassp/NASSP/commit/494e23257364b832803d272f4d52998d88e0d29a [21:37:46] I see that I deleted the one line 2079 , but it's in lempanel.cpp [21:38:15] ah [21:38:19] yeah that's not good [21:38:25] but wouldn't cause this [21:39:55] so sketchpad only affects the lines that were already drawn onto the scroll [21:39:58] not the scroll itself [21:40:07] if I comment out that drawing code the textures is still white [21:44:32] let me try to confirm again when exactly it broke [21:46:52] before Gondos thread PR, already broken [21:48:49] before an RTCC fix of mine, already broken. Would have been a surprise lol. [21:48:56] now comes the sketchpad PR [21:52:46] yeah confirmed [21:52:57] the merge commit of the sketchpad PR is what broke it [21:54:21] ich habe die von vorhin genommen git.exe archive --output="D:\OrbiterSVN\jordan.zip" --verbose 8ab97a13c4a60c54f5a7cff225e25681664267b1 -- hab meine letzten änderungen dort übernohmen und es funktioniert [21:55:50] talkback und so funktionieren, auch die im lm, die habe ich gestern gemacht, danach ist mir erst aufgefallen das ems nicht funtioniert [21:56:10] aber da sind nicht die Änderungen vom dem Sketchpad PR drin, oder? [21:56:23] nein [21:56:41] wie gesagt die letzte,  plus nur meine änderungen [21:57:22] leider ist das nicht so sehr zielführend. Sketchpad PR ist schon gemerged. [21:58:27] Wir müssen herausfinden warum es damit nicht funktioniert. Eine ältere version des codes zu benutzen wird es nur unmöglich machen dein Projekt je zu mergen [22:00:07] ich weiss nicht wie die ems im code funktioniert. der einzige unterschied ist doch nur das die texturen größer sind. [22:00:24] ist irgendwas hardcoded? [22:00:46] ja und selbst wenn, Gondos hat nicht wirklich was daran geändert [22:01:17] er hat mehr auf dem 2D Panel an dem EMS geändert [22:02:09] ach ich bin so dumm [22:02:39] https://github.com/orbiternassp/NASSP/pull/890#issuecomment-1374269116 [22:03:21] https://github.com/Jordan-64/NASSP/blob/HighRes_VC_Textures/Orbitersdk/samples/ProjectApollo/src_csm/saturnvc.cpp#L558 [22:03:40] Gondos musste ändern wie die Textur geladen wird [22:03:48] wir haben noch drüber gesprochen... [22:04:17] habe ich mir jetzt etwa umsonst den kopf zerbrochen? :-D [22:04:39] wir beide [22:04:46] und ich hätte es noch wissen müssen [22:04:59] shame on you [22:05:15] wenigstens bin ich erleichtert [22:05:17] ich glaube man muss da nur die *TexMul machen [22:05:29] dann wird es funktionieren [22:05:44] kannst du es testen? [22:05:48] bin dabei [22:06:20] srf[SRF_VC_EMS_SCROLL_LEO] = oapiCreateTextureSurface(4096, 256); [22:06:35] das ist wohl der fehler, hardcoded [22:07:22] ja [22:07:50] naja [22:07:51] Fehler [22:08:05] in unserer branch gibts es ja nicht diesen TexMul [22:08:19] funktioniert [22:08:37] also viermal * TexMul dranhängen [22:08:42] und es läuft [22:08:46] richtig [22:09:18] Rätsel gelöst! [22:09:33] last es bei euch wie es ist, ich ändere es bei mir und füge die fehlende fehlende zeile im lm cde wieder ein [22:09:37] code [22:10:25] ja macht Sinn [22:11:12] wie gesagt, Orbiter2016 branch hat keinen TexMul [22:11:35] noch nicht [22:11:47] dann "*TexMul" einfügen würden im Moment zu nichts Gutem führen :D [22:12:45] ich glaube das Problem war mit Sketchpad das auf der Textur herummalen nicht funktionierte [22:13:06] darum musste er da diesen Workaround einfügen, scheint ja ein Orbiter Problem zu sein [22:13:10] ich habe in nasspdefs.h eine static int TexMul, die kann man eigentlich übernehmen [22:13:35] ja, kommt ja dann wenn deine branch gemerged wird [22:14:15] Das soll auch optional bleiben? [22:14:29] Dann fügen wir es im Orbiter launchpad als option für NASSP hinzu [22:14:33] was passiert wenn ich orbiter2016 bei mir merge, werden dann meine überschrieben? [22:15:08] müsste eigenlich nicht weil bis jetzt ist nichts überschrieben worden [22:15:09] nein, nur wenn in der gleichen Zeile nochmal was geändert würde [22:15:16] ah ok [22:15:23] dann gekommst du einen merge conflict denke ich [22:15:26] bekommst* [22:15:54] hast du in diesem Fall nicht weill du ja bisher keine Änderungen beim dem Textur laden hattest [22:16:39] nee ich hab nur den multiplikator  eingefügt [22:17:53] achso ich dachte du meinst mit den *TexMul hinzufügen [22:18:32] ja :-D [22:18:33] Gondos PR zu mergen hatte ohne Konflikt funktioniert weil du ja nichts bei dir geändert hast mit dem oapiLoadTexture [22:19:01] TexMul ist der "multiplikator" [22:19:15] Ja, ich meinte vorher [22:20:25] Wenn du das commitest und später nochmal Orbiter2016 merged passiert nichts, was du geändert hast bleibt erhalten [22:20:40] Weil du hast den Sketchpad PR ja schon drin [22:20:52] und Orbiter2016 auch [22:21:22] hauptsache nicht von einer alten Zip Datei alte Dateien laden und das committen :D [22:22:18] ah, sehe schon, alles richtig [22:22:55] so jetzt wird es neu kompiliert...... [22:27:04] ...funktioniert [22:27:39] super! [22:27:47] dann sage ich mal Gute Nacht [22:28:02] good night! [22:28:07] n8 [14:39:10] good morning [14:40:21] hey Matt [14:51:12] started playing around with variable liquid density again, as a potential stop-gap solution [14:52:22] and, is it doing good predictable things? [14:54:40] it is. the cryo tanks need to be a bit warmer than they are now. need to make some minor adjustments [14:56:18] at 60% the O2 tanks should be around -180F to maintain pressure. in our current model they're at -290 [14:57:09] with mine, -160. so some slight changes to a few coefficients and we'll be there [14:57:46] ouch, quite off [14:58:52] right now I mean [14:59:44] this was the primary reason I couldn't do proper modeling of fuel cell reactant heating/cooling. the oxygen was too cold [15:01:00] ah so one big change was nearly done, but it kind of requires another one [15:01:16] reminds me of my drag and S-IVB venting updates [15:01:40] drag is essentially ready, venting not. But with 90 NM parking orbits I don't really want to put in the drag update right now without venting pushing it up [15:05:10] yeah, I imagine those need to balance each other to make sense [15:06:23] oh the venting is about 40x stronger actually [15:06:44] and it's not like you drop from orbit like a stone at 90 NM from the drag [15:06:52] but it's kind of enough to dislike the effect [15:07:08] they only went down to 90 because they knew they would be gaining altitude, not loosing it [15:08:09] lol, this photo is confusing me: https://nassp.space/index.php/File:FDAI.gif [15:08:14] apparently it's from Apollo 15 [15:08:28] nowhere else have I seen a black DAP monitor card [15:08:40] and the crew must have been photo shy [15:08:52] very little photos from inside from the mission [15:10:38] Apollo 17 on the other hand, half the photos seems like selfies [15:14:25] like the ones where they look like they've just come in from literally rolling around in the dirt haha [15:15:31] in our LM texture we have a bunch of black "decals" on the panels. could this have been something similar. [15:16:27] yes [15:16:36] not an actual card, but something glued to the panel. why would you have the information duplicated on a card though [15:18:23] well I think this decal might have been put there after the flight [15:18:33] oooooooh [15:18:36] hmm [15:18:38] Apollo 15 did have the white card like all other missions [15:18:43] it's part of the scanned cue cards [15:19:09] but what it also could be is, Apollo 15 had a black decal in that spot and they never used the white one [15:19:35] but that would be Apollo 15 only then [15:20:08] that's why a video or photo from the mission would clear it up [15:39:35] yeah, all the photos and 16mm film I'm seeing, they're taking pictures of the moon [15:45:48] yeah [16:48:23] hi [16:48:36] hi Jordan [16:49:39] how can i make TexMul global but no const? [16:56:50] hey [16:56:52] uhh [16:57:07] not constant in what way. Where do you want to change it? [16:59:38] I think one Solution for TexMul to work in both 2d and vc is, make TexMul global and change it when switching from 2d to vc [16:59:41] bool Saturn::clbkLoadPanel (int id) { [16:59:42]     if (InVC) [16:59:42]     { [16:59:43]         TexMul = 2; [16:59:43]     }else{ [16:59:46]         TexMul = 1; [16:59:46]     } [16:59:55] bool Saturn::clbkLoadVC (int id) [16:59:56] { [16:59:56]     TRACESETUP("Saturn::clbkLoadVC"); [16:59:57]     if (InVC) [16:59:57]     { [16:59:58]         TexMul = 2; [16:59:58]     }else{ [16:59:59]         TexMul = 1; [17:00:00]     } [17:01:11] hmm [17:01:24] why not use it for 2D? [17:02:02] oapiBlt is the same code for vc and 2d [17:02:49] when i use it in vc it also changes  it in 2d too, so that 2d isn't working [17:03:43] ah yeah, some bad code by us. Some of the code that was meant only for 2D is also required for VC [17:03:58] yes [17:04:28] so we need TexMul global and no const [17:07:45] I don't quite understand how that works yet [17:09:20] your update will only be for the VC, right? [17:09:31] 2D panel has half res textures, including talkbacks [17:09:49] you could make a separate (temporary) variable from TexMul and check if(TexMul != 1) [17:09:53] talkback textures are separate for VC and 2D, but it uses the same coordinates right now for the oapiBlt [17:10:08] is that correct? [17:10:11] that is the problem? [17:12:33] indy91 exactly [17:12:44] in SetSwitches [17:12:53] how does that even get called from the VC [17:25:12] the same code is called as in 2d, only the parameters when calling the function will be different. I think in 2d the id's for the 2d textures are passed and in vc the id's for vc textures. [17:46:54] morning! [17:53:01] hey Mike [17:54:03] Jordan64, I think your idea with the variable TextMul isn't going to work [17:55:39] the function where you added the TexMul for the talkbacks isn't called when you switch between VC and 2D... I think [18:01:06] might make more sense to separate those [18:02:49] I wonder how the Delta Glider handles this, also has fully functional 2D and 3D [18:04:40] Jordan64, the VC textures, are they bad for performance? [18:04:54] in other words, would they be optional in the long term? [18:04:57] or only for testing now [18:05:08] if only for testing, I would get rid of TexMul entirely [18:05:18] and fix the code where 2D and VC need different numbers [18:05:22] I can do that for your branch [18:06:54] I didn't notice a performance impact on my system. 8k textures would probably have one though [18:07:49] as I said yesterday, we could add it as a performance option for users in the Orbiter launchpad [18:08:06] otherwise, for the 2D vs. VC thing, that really should be a code fix [18:08:10] I think that was the plan [18:08:49] not to add extra work, but we could remove the oapiBlit calls by using animations and meshes [18:08:56] oh god [18:09:10] or not... [18:09:12] haha [18:09:19] I mean, in the VC yes [18:09:26] don't think there are too many oapiBlt [18:09:38] yeah, that's what I meant haha [18:09:52] you know you can do 2D meshes, it's a whole different 2D panel system [18:10:02] just talkbacks, tapes etc [18:10:37] the function for the talkbacks is only called in the Saturn constructor and in clbkLoadPanel [18:10:54] oh ok, I see now [18:12:03] yeah clbkLoadPanel is not called if you are in the VC [18:12:08] that's only 2D [18:14:29] sorry for the delay i had to recompile , i get about 150 +- on my pc i6700k nvidia 1060 4k resolution [18:15:26] so tell me how you want it to work, I can help with the code. VC texture size can be optional or not? [18:15:29] just* [18:15:46] or does that require two sets of textures [18:16:03] two sets for the VC I mean [18:17:37] as matthew said make this optional in project apollo configurator wich texture size is the best for the pc [18:18:16] ok, so that TexMul would be the multiplier for that [18:18:24] so in terms of textures for e.g. talkbacks [18:18:44] there would be 1x size bitmap for 2D, 1x size DDS file for VC [18:18:48] and 2x for high res [18:18:54] right? [18:19:14] exactly [18:21:47] oapi has the function clbkLoadPanel for 2d and clbkLoadVC for the VC. I think as soon as these functions are called you can change TexMul accordingly. [18:22:21] the problem I am seeing is this [18:22:23] FuelCellRadTempIndicator.Init(174*TexMul, 0, 23*TexMul, 23*TexMul, srf[SRF_INDICATOR], FuelCellPhRadTempIndicatorsRow); [18:22:28] that is in SetSwitches [18:23:08] SetSwitches is only called when the simulation loads are if you switch to 2D or to a different 2D panel [18:23:19] loads or* [18:23:32] haha, bad correction [18:24:01] if you are in 2D [18:24:06] and it has TexMul = 1 [18:24:10] and then switch to VC [18:24:16] then SetSwitches is not called again [18:25:47] I would make this a different code change [18:26:00] there are separate functions to draw talkbacks for 2D and VC already [18:26:03] IndicatorSwitch::DrawSwitchVC [18:26:10] maybe the TexMul needs to be applied there [18:26:19] in the blit [18:26:29] and none at all in SetSwitches [18:27:04] and your special code for the beginning of the clbk function isn't required then [18:27:10] functions* [18:28:47] and TexMul stays a constant [18:28:58] eventually being moved to ProjectApolloConfigurator [18:30:35] https://www.dropbox.com/s/hyfobd6p9z3oumw/Zwischenablage02.jpg?dl=0 [18:31:00] if i remove TexMul from this line this happens [18:32:33] right [18:32:37] go to toggleswitch.cpp [18:32:46] function [18:32:48] IndicatorSwitch::DrawSwitchVC [18:32:57] has a oapiBlt at the end [18:34:10] I think there the TexMul should be applied [18:34:20] instead of the Init functions [18:34:48] I'm already there [18:35:52] hmm how does that need to be changed... [18:37:33] oapiBlt(drawSurface, switchSurface, x*TexMul, y*TexMul, TexMul*width * (int) displayState, 0, width*TeMul, height*TexMul); [18:37:34] maybe [18:37:42] that's a lot of added multiplications... [18:38:00] but probably not much of a performance impact [18:38:14] for that it would be better to have different x and y [18:38:57] other solution would be [18:39:08] have a different set of x, y, width and height for the VC [18:39:22] and calculate them in IndicatorSwitch::Init [18:39:35] x_vc = x*TexMul; [18:39:38] for example [18:39:56] wouldn't need the multiplications every timestep like the oapiBlt change [18:40:03] but more variables [18:42:18] the code i have now also has a lot of multiplications and i have around 150 fps in 4k [18:42:57] but if it is possible i to reduce it would be better [18:43:39] what i'm doing now is actually meant to see if the textures are working as they should [18:47:51] right [18:48:14] I think the best, if maybe temporary solution is to change the oapiBlt as I wrote above [18:48:53] and no TexMul in SetSwitches [18:51:19] there also is TexMul in RenderS1bEngineLight [18:51:45] ah yeah, same function gets called for 2D and VC [18:53:48] ah ok, but that can be solved [18:53:58] remove the TexMul from it [18:54:15] and then apply TexMul to xoffs and yoffs in the function call [18:54:20] instead of in the function itself [18:54:38] but only in the VC of course [18:57:53] that looks like a lot of work :-( [19:05:00] I don't think it's that much [19:05:26] more reverting something you already did than lots of new code I guess [19:07:02] So first I have to remove the TexMul from the inits and put them in IndicatorSwitch::DrawSwitchVC because the inits are only called once [19:07:40] only called once if you are in the VC [19:07:46] they get called on 2D panel switches [19:07:52] but not back and forth in the VC [19:23:02] if you want a "quick" side project [19:23:04] https://i.imgur.com/G2IhoDJ.png [19:23:11] small texture issue [19:23:18] says Close, where it should say Cabin [19:23:19] that's it [19:23:42] zzzECS.dds [19:50:57] oops, that was my mistake [20:40:19] indy91_ I corrected it, unfortunately did it twice, hope it doesn't cause any problems [21:21:42] I see two commits. How did you do it twice? [21:28:31] just checked, was already fixed in the first of the two commits :D [21:28:35] what changed in between? [21:29:09] the two commits doesn't bother me at, just curious [21:33:51] there was a transparent part i forgot. i am not sure if it is necessary [21:34:24] i want to get rid of those zzz [21:35:26] ah ok, then it's all good, so just a small correction and not some git issues that can break everything haha [22:00:37] night! [16:10:06] hey [16:10:20] hi [16:11:28] hey guys [16:11:35] all TexMul under control now? :D [16:12:04] Oh thank you :-) [16:12:55] I take that as a yes [16:13:56] no, that's not an easy job for me [16:14:41] multiplications can be done with shifting right? [16:14:50] oh god [16:15:02] I mean, integer, yes [16:15:17] one bit to the left means *2 2 bits *4 [16:15:40] so we can shift instead of multiplying [16:15:43] But doing that is not often a good idea. Where do you plan to use that? [16:15:57] *TexMul [16:16:00] hmm [16:16:16] texmul is integer the coordinates too [16:16:25] https://stackoverflow.com/questions/6357038/is-multiplication-and-division-using-shift-operators-in-c-actually-faster [16:17:09] even if it was more efficient, I think that will just make the code look a lot worse [16:17:52] as long as the TexMul is done almost exclusively during view switching and not on every timestep I have no problem with *TexMul [16:21:14] What about oapiBlt? the function is executed often. [16:21:44] so far you only use TexMul in oapiBlt for the talkbacks, right? [16:22:26] hmm [16:22:30] and a few others I guess [16:22:33] talkbacks, mission timer, [16:24:29] hmm [16:25:38] Talkbacks are not executed often, missiontimer, dsky and so on, more often [16:26:42] but i have no performance impact with all the multiplications [16:28:28] I think you never see an impact from this sort of thing. But it accumulates [16:29:01] the next 9 people making such a change also see no change [16:29:18] but then if you would compare between the beginning and the end... [16:30:21] so we just need to be a bit careful [16:34:40] what is about this init "SMRCSHelium1ATalkback.InitVC(srf[SRF_VC_INDICATOR]);" ? [16:37:49] what about it? [16:39:18] can i put TexMul here? [16:39:26] somewere? [16:39:35] hmm, could work [16:39:41] that is called every time you switch to the VC [16:39:44] or within the VC [16:41:55] I think you would need to keep track of the current texture scaling [16:42:21] like, in clbkLoadPanel there would be a CurrentTextMul = 1 [16:43:30] in clbkLoadVC there would be a check on CurrentTexMul [16:44:06] and then CurrentTexMul is set to TexMul [16:44:23] but the InitVC are called so that it doesn't multiply the scaling more than once [16:47:01] and then in InitVC it rescales it [16:47:37] the concept would be. Add a "double CurrentTexMul" to Saturn class. [16:47:47] on top of clbkLoadPanel, CurrentTextMul = 1.0; [16:47:58] on top of clbkLoadVC: [16:48:12] "double Apply TexMul = TexMul/CurrentTexMul;" [16:48:16] "double ApplyTexMul = TexMul/CurrentTexMul;" [16:48:22] and then [16:48:30] CurrentTexMul = TexMul; [16:48:41] and then InitVC have ApplyTexMul as input [16:49:00] ah, should be integers I guess [16:49:42] and it shouldn't be in clbkLoadPanel but in SetSwitches [16:51:24] CurrentTexMul=1.0; this is float? Yes they  should be integers [16:51:35] yeah, integer [16:52:12] ApplyTexMul basically needs to be only 1 or 2, integer [16:52:21] if you switch from 2D to VC it should be 2 [16:52:25] if TexMul is 2 [16:52:36] if you switch between VC positions it should be 1 [16:52:49] then you can safely call InitVC [16:52:52] with ApplyTexMul [16:55:07] not a super clean solution, but it would work [16:55:37] you avoid doing TexMul every timestep and you also avoid having a separate set of variables for the texture sizes [16:56:11] ok i don't know what i have done, removed all the Init stuff, and the talkback works in both vc and 2d also the ems works [17:00:14] but you have the TexMul right now in the talkback class with oapiBlt, right? [17:00:34] that's what makes it work [17:00:48] even if it could be inefficient. But solving that would be the next step [17:02:54] i can update my branch so can take a look [17:03:42] dsky, missiontimer, control lamps, works only in vc [17:03:51] sure, I can take a look [17:05:22] btw, what are your main sources for the texture update? [17:05:42] I've seen some things like font changes, or at least it looks like it to me [17:06:06] like on the LV Engines display [17:06:11] looked strange to me at first [17:06:19] but then I find photos like this, Apollo 11: https://airandspace.si.edu/sites/default/files/images/news/11909h.jpg [17:06:35] and your update definitely makes it more accurate :D [17:14:33] I was only first only that the text (font) looks more like the original and is easier to read. I chose the fonts that fit the most. well in the meantime i have improved even more things like the ems scroll, better rotarys and so on [17:14:55] this line makes the job [17:14:56]     oapiBlt(drawSurface, switchsurfacevc, x*TexMul, y*TexMul, width * (int)displayState*TexMul, 0, width*TexMul, height*TexMul); [17:15:24] toggleswitch.cpp line 3636 [17:15:41] the talkback are done. :-) [17:18:44] nice! [17:19:05] efficiency can come, important is that it works ;) [17:19:07] branch updated [17:20:08] you have a slower pc than i, can you check for performance? [17:21:56] did we make a PC comparison? I can't remember hahaha. Sadly I can't right now, working on something. I can check later. [17:26:15] no problem, i made it one step further, that was important to me. a small step for me, a giant leap for ProjectApollo :-D [17:36:08] I think so, too. Just need to make sure the code is good :) [17:50:14] indy91, we're we looking for this https://ntrs.nasa.gov/citations/19670081851 [17:50:32] I just got an email saying they'd made it available [17:52:35] uhh [17:52:45] I guess you requested that at some point haha [17:53:12] probably when we were stuck with those MSC FORTRAN routines [17:54:39] oh probably haha. wow that was a while ago [17:57:03] a real rarity, a document they made available again [18:06:44] I fixed some code, then changed it a little bit back for more backwards compatibility, and now I can't remember why it even needed to be fixed in the first place [18:18:57] oh that's never good [18:20:05] morning! [18:20:08] haha oh no [18:20:12] https://github.com/orbiternassp/NASSP/issues/861 [18:20:33] Is H2 even misaligned? [18:20:38] O2 is, I know why [18:20:52] VC assumes linear scaling of the meter [18:20:54] but H2... [18:20:59] I thought I saw a difference [18:21:14] maybe that was a wrong solution I had in between I was looking at [18:21:24] but I think H2 meters were never off between 2D and VC... [18:31:34] maybe i found a solution. this is for the mission timer and it works [18:31:36] virtual void Render(SURFHANDLE surf, SURFHANDLE digits, bool csm = false, int ivc = 0); [18:31:37] ---------------------- [18:31:38] case AID_VC_MISSION_CLOCK: [18:31:40] MissionTimerDisplay.Render(surf, srf[SRF_VC_DIGITALDISP2], true, 1); [18:31:41] ---------------------- [18:31:42] void MissionTimer::Render(SURFHANDLE surf, SURFHANDLE digits, bool csm, int ivc) [18:31:43] { [18:31:44]     if (!IsPowered() || !IsDisplayPowered()) [18:31:44]         return; [18:31:45]     int xTexMul = 1; [18:31:46]     if (ivc == 1) xTexMul = TexMul; [18:31:46]     const int DigitWidth = 19*xTexMul; [18:31:47]     const int DigitHeight = 21*xTexMul; [18:32:27] added a new parameter "ivc" [19:02:36] hmm [19:03:10] why not have xTexMul directly instead of ivc [19:03:29] virtual void Render(SURFHANDLE surf, SURFHANDLE digits, bool csm = false, int xTexMul = 1); [19:04:03] called with TexMul for xTexMul from the VC [19:12:37] got it, you're right ;-) [19:17:42] So now I have to add a parameter to all calls for the vc [19:19:35] for which functions? [19:23:08] all functions for the vc  that calls oapiBlt [19:24:11] hold on [19:24:49] so you are not going to use my idea with the InitVC? [19:25:11] to complicated for me :-( [19:29:16] we can always rewrite it when the update is ready for merging [19:29:32] when everything works [19:30:34] if i call a function like this "    case AID_VC_DSKY_DISPLAY2: [19:30:38]         dsky.RenderData(surf, srf[SRF_VC_DIGITALDISP], srf[SRF_VC_DSKYDISP], 0, 0, TexMul);" [19:30:49] is TexMul a local Variable? [19:31:05] so i dont need xTexMul? [19:55:14] TexMul is your global constant. But when you call RenderData it makes a copy. So inside of the RenderData function it is a separate variable [19:55:25] that you could even safely change within RenderData [19:59:23] can be called TexMul or something else, maybe better if it's not called TexMil [19:59:32] like in this [19:59:36] Render(SURFHANDLE surf, SURFHANDLE digits, bool csm = false, int xTexMul = 1) [20:00:16] call that with TexMul and then inside the function use XTexMul, which is a copy of the input variable. Or has the default value 1 [20:42:08] indy91 Kann ich beim Funktionsaufruf zb. test(1, 1, , , , 2)? [20:42:33] parameter überspringen, also nichts angeben [21:08:16] Jordan64, nein, nur wenn du wie bei deiner Render Idee zum Beispiel "int ivc = 0" hast [21:08:19] Branch Updated. Lots of things work in VC and 2D. [21:10:22] Ok. Also muss ich dann die Default parameter extra  eingeben. Habe es so gemacht. Es Funktioniert vieles mittlerweile. naja wenn man erst den faden gefunden hat, geht's leichter :-D [21:11:54] ja, genau wie du es mit cws.RenderLights gemacht hast [21:12:08] DSKY Lights gehen noch nicht, die Alarm Lampen auch nicht. und dann ist noch ein zähler unterhalb von abort der geht auch nicht. Im LM gehen auch viele, nur ein paar nicht. [21:12:12] für 2D ändert sich nichts wegen int xTexMul = 1 [21:13:04] genau. und ich hab den TexMul parameter direkt übernommen, muss also nichts vergleichen [21:14:03] mit Zähler meinst du wahrscheinlich den Event Timer [21:14:06] EventTimer::Render [21:14:09] hat noch TexMul [21:14:18] in missiontimer.cpp [21:14:41] das ist der zähler unterhalb von abort, in VC  geht alles, nur in 2d nicht [21:15:08] ja, ich denke mal EventTimer::Render wird von 2D und VC benutzt [21:15:49] also das gleiche Prinzip [21:16:16] überall wo ich jetzt was geändert habe wird der code für beide benutzt, deshalb das mit der  TexMul parameter übergabe. [21:16:37] und es funktioniert [21:17:02] ich denke ein paar tage als anfänger werde ich noch brauchen. [21:17:13] ja, lass dir Zeit [21:17:57] die texturen kann man ja schon jetzt benutzen, es ist der code der angepasst werden muss. [21:18:05] und hinterher, wenn ich dazu komme, kann ich die Änderung mit meiner Idee zu TexMul selber implementieren [21:18:44] du meinst mit InitVC? [21:19:02] ja, damit nicht so viele TexMul jeden timestep gemacht werden müssen [21:20:28] aber hauptsache es funktioniert erst mal. Ist zwar vielleicht mehr Arbeit das hinterher zu ändern, aber auch einfacher wenn man weiss es funktioniert schon [21:20:59] ich kann auch pull request für deine branch machen [21:21:03] sozusagen PR-ception [21:21:04] also ich hab mir das mit dem InitVC angesehen, das ist ein bisschen verzweigt [21:21:51] oh, sehe einen VC Fehler [21:22:00] Liftoff/No Auto Abort button [21:22:33] das ist mir bekannt, hab noch nicht gefunden wo ich das ändern muss. [21:22:45] das ist aber auch der komplizierteste button [21:22:53] zwei unabhängige Lichter... [21:23:23] hat eine eigene Klasse deswegen [21:23:28] SaturnLiftoffNoAutoAbortSwitch in saturnswitches.cpp [21:24:25] class SaturnLiftoffNoAutoAbortSwitch :public GuardedPushSwitch [21:24:27] { [21:24:28] public: [21:24:29]     SaturnLiftoffNoAutoAbortSwitch(); [21:24:30]     void Init(int xp, int yp, int w, int h, SURFHANDLE surf, SURFHANDLE bsurf, SwitchRow &row, SECS *s, [21:24:31]         int xoffset = 0, int yoffset = 0, int lxoffset = 0, int lyoffset = 0); [21:24:32]     void DoDrawSwitch(SURFHANDLE drawSurface); [21:24:32]     void RepaintSwitchVC(SURFHANDLE drawSurface, SURFHANDLE switchsurfacevc); [21:24:33] protected: [21:24:34]     SECS * secs; [21:24:35] }; [21:24:35] ist das der code? [21:24:46] ja, hat seinen eigenen DoDrawSwitch und RepaintSwitchVC [21:24:55] RepaintSwitchVC ist wahrscheinlich wo du gucken musst [21:25:43] ah ok, das schaue ich mir morgen an. [21:26:52] klingt gut [21:27:27] void SaturnLiftoffNoAutoAbortSwitch::RepaintSwitchVC(SURFHANDLE drawSurface, SURFHANDLE switchsurfacevc) [21:27:31] { [21:27:33]     int ofs = 4; [21:27:34]     if (secs->LiftoffLightPower()) { [21:27:35]         if (!secs->NoAutoAbortLightPower()) [21:27:36]             oapiBlt(drawSurface, switchsurfacevc, 0 + ofs - 1, 0 + ofs, 117 + ofs, 1 + ofs, width - ofs, height - ofs, SURF_PREDEF_CK); [21:27:36]         else [21:27:37]             oapiBlt(drawSurface, switchsurfacevc, 0 + ofs - 1, 0 + ofs, 273 + ofs, 1 + ofs, width - ofs, height - ofs, SURF_PREDEF_CK); [21:27:38]     } [21:27:39]     else { [21:27:40]         oapiBlt(drawSurface, switchsurfacevc, 0 + ofs - 1, 0 + ofs, 39 + ofs, 1 + ofs, width - ofs, height - ofs, SURF_PREDEF_CK); [21:27:41]     } [21:27:42] } [21:28:03] mehr TexMul Spass... [21:28:13] was ist dieses ofs? musste es auch 4*TexMul sein? [21:28:56] int ofs = 4; [21:28:58] wie dumm [21:29:06] unnötig das zu haben [21:29:20] sollte direkt in den oapiBlt calls sein [21:29:42] du kannst gerne ein paar mal +4 machen und ofs löschen :D [21:29:44] ich mache mal einen test bevor ich schlafen gehe [21:30:59] es geht [21:31:24] ich muss mal sehen ob es beim start der saturn 5 auch leuchtet [21:33:57] bin dann schon mal weg. Bis bald! [21:34:07] good night! [16:17:20] hey [16:19:01] hey Matt [16:19:54] right, the code that you linked is used to kind of convert voltage back to temperature [16:20:10] but only DoDrawSwitch for the 2D panel scales it properly for the meter [16:20:16] while for the VC it's an animation [16:21:07] that only linearly converts the QueryValue number to animation range [16:21:19] so the conversion for the meter has to be in QueryValue [16:21:36] did I link the wrong thing? [16:21:49] no, both QueryValue and DoDrawSwitch needs changes [16:22:02] oh okay. [16:22:25] basically moving the code making the meter non-linear from DoDrawSwitch (only 2D) to QueryValue (used by both) [16:22:36] basically need the shift the scaling into QueryValue, if I'm understanding correct? [16:22:41] yep [16:22:44] haha [16:22:53] I would have liked to make that 0 to 1 or so [16:23:01] but, there is a funny problem I had with my branch [16:23:13] we simulate that needles don't move instantly [16:23:33] there is a value, for most meters it is 10 seconds, it takes from min to max value [16:23:52] in the scenario the meters save both actual and currently displayed value [16:24:18] if I had changed the scaling from pressure (0 to 1000 PSI) to something like 0 to 1 then there would be an issue [16:24:33] displayed value would still be 900 something [16:24:55] and the "needle speed" it calculates is 0.1, because of the 10 seconds [16:25:25] so when you load an old scenario it would have a display state of 900 and only very slowly going down haha [16:25:42] and there is a flaw in the system, it doesn't care for time acceleration [16:26:03] so you can't even accelerate that at all, takes lke 10 minutes either way... [16:30:07] so I chose scaling 0 to 1000 instead of 0 to 1 [16:30:42] there wouldn't be much of a point to convert a voltage that was already converted from temperature or pressure back to temp or press [16:33:56] yeah, if anything I'd probably aim more in the direction of it whatever voltage was driving the gauge. [16:34:28] I would think in the case of linearly scaled meters it is just 0-5V that decides the needle deflection [16:34:44] hi [16:34:55] non-linear depends. Sometimes the input sensor voltage is non-linear, too. [16:34:57] hey Jordan [16:37:21] hi Jordan [16:37:49] are they eObjects? I can't remember [16:37:53] yes [16:38:09] in a way it does a double check on voltage now [16:38:24] Meter checks if it has voltage, but whatever it shows is separate [16:38:40] which is not the case. I think it's only the input sensor voltage that drives the needles [16:39:10] so we should probably make the meters a bit dumber [16:39:34] don't require any additional electrical source [16:40:26] yeah. I would imagine most of them are basically just an analog voltmeter with psi, degrees, etc printed behind the needle [16:40:59] SCE provides the output for all of these (in the real one)? [16:41:11] no, only some [16:41:16] SCE in the CSM is quite limited actually [16:41:32] cryo pressures don't need it [16:41:42] so the sensors already have to output 0-5V [16:44:56] ahh okay [16:53:41] "fuelCellStatus" is something I want to look at removing, and reimplementing in a more realistic way [17:32:12] yeah, like I have removed the TankPressures struct in the update for the meters [17:32:17] doing more with sensor classes [17:32:29] the only slight downside, it is a few more calculations [17:32:57] each sensor is used 3 times, CWS, telemetry and the meter [17:33:15] and when you check on the voltage it doesn't just access a voltage variable but does a bunch of calculations [17:33:28] but it's not so bad [17:33:47] now you can pull instrumentation circuit breakers and you would get the fuel cell light [17:33:55] uhh [17:33:56] cryo press [17:35:36] Jordan64, https://airandspace.si.edu/sites/default/files/images/news/11909h.jpg [17:35:45] that card above the FDAI [17:35:57] it's not a cue card, but it seems to be permanently fixed there [17:36:09] and I have seen it on basically all missions [17:36:27] so that might be something we want to add to the CM VC. So not a cue card, but permanently part of the CM [17:37:13] That looks like a sticker. I do it. [17:37:32] no rush :) [17:38:12] the backside of the SPS burn cue card is more important to me, so I can get the cue card branch in a releasable state [18:35:56] I think I'm done with the code. It seems that 2D and VC both work. If someone tests it it would be appreciated. I update my branch. [18:45:03] yeah I will [16:44:47] morning! [16:59:13] hey Mike [17:04:10] hey guys [17:51:33] Jordan64, I see a strange issue on the ASCP in the VC [17:55:06] Oh yeah, found some in the LMVC too. [17:55:48] you are updating the LM VC, too? I hadn't even checked to be honest [17:58:19] yes [18:00:34] all of the code issues you mentioned so far were CSM [18:03:32] what is your main source for the updates again? [18:03:51] The H2/O2 pressure meters in the CSM have some errors I believe [18:04:01] even the Systems Handbook has them partially wrong [18:04:15] Almost, but there are similarities between the two [18:04:17] wrong scale [18:04:44] but maybe doing changes like that is a bit beyond the scope of your update [18:04:54] it's already huge as it is [18:04:56] main sources was the default ProjectApollo textures [18:07:19] hi [18:08:29] hey Gondos [18:09:40] so I've been working on the network stuff for telemetry. Since I can't seem to co;pile the telemetryclient with VS2019 I'm using the LMTelemetryClient2 [18:10:16] but I keep getting D3D9 assert when loading the apollo11 - 16 scenario [18:10:23] is it a known issue? [18:10:27] no [18:10:30] happens maybe one time out of 5 [18:10:53] 000000.010: D3D9: ERROR: D3D9ClientSurface: GetDC() Failed [18:10:54] 000000.010: D3D9: ERROR: Surface name is clbkCreateSurface Handle=0x4E1894E0 (245,245) [18:10:55] 000000.010: D3D9: ERROR: Surface Has a Surface Interface [18:10:55] 000000.010: D3D9: ERROR: Surface Has a Rendering Interface [18:10:56] 000000.010: D3D9: ERROR: Surface Is Lockable [18:10:57] 000000.010: D3D9: ERROR: Surface is in a DefaultPool [18:10:57] 000000.010: D3D9: ERROR: Surface has RENDERTARGET usage [18:10:58] 000000.010: D3D9: ERROR: Surface Format is 22 [18:11:00] 000000.010: D3D9: ERROR: ActiveFlags( ) [18:11:05] hope it's not related to the sketchpad stuff [18:11:11] the getdc is used for the FDAI texture [18:12:09] is that with the scenario loading the 2D panel? [18:12:22] yes it starts in the 2d cockpit [18:12:36] oh I thought you meant Apollo 11 through Apollo 16 and I was confused [18:12:42] you mean mission scenario 16 for Apollo 11 [18:13:02] no no it's a LEM scenario to test the telemetry with the LMclient [18:13:06] let me rebuild and load that some times [18:14:05] ok [18:16:44] regarding the filenames branch, I can't do much right now, I must wait till the Orbiter2016 branch is closer to my linux one so I can just try to compile it on linux and see if it fixes the path issues [18:18:22] can't reproduce it [18:18:32] although I do on occasion get crashes when loading a scenario [18:18:36] hum, good news but strange... [18:18:46] not as often as 1 in 5 though [18:18:59] you get an assert popup or a CTD? [18:19:09] popup [18:19:15] although your error seems more debuggable [18:19:29] I think what I usually get is pretty useless for tracking down an issue [18:19:45] it's from the orbiter.log, the popup just says assert in D3D9Surface [18:20:16] are the source from r40 available somewhere so I can compile it in debug mode? [18:20:21] we are also not deleting surfaces properly [18:20:32] if you don't exit Orbiter completely you get this [18:20:34] D3D9: ERROR: UnDeleted Surface(s) Detected [18:21:14] not sure if that is related [18:21:23] don't know about DX9 client sources [18:21:28] don't think so, I get the crash on first startup [18:22:08] wait, r40? [18:22:55] sorry, wrong number this one : D3D9ClientBeta30.7-forBETA r90(r1436) [18:23:03] yeah, that's the one I use, too [18:37:52] indy91_ ASCP  Fixed [18:45:23] telemetry looks good, how does the uplink works though? [19:00:06] Gondos, you type DSKY commands [19:00:53] nothing much happens [19:01:05] but sometimes there is a "LM: Ready for uplink?" message on the top [19:01:09] do you have uplinks allowed in the LM? [19:01:22] Ready for uplink is a MCC message [19:01:25] hehe, I guess you nailed it [19:01:36] MCC also wants to uplink :D [19:01:49] panel 12, UPDATA LINK in DATA [19:03:23] thanks, it works! [19:08:07] the current network code treats "unknown errors" differently and display them as debug messages. Is it something you still want? [19:10:51] hmm, not sure. probably [19:11:49] makes the code uglier^^ [19:12:23] ok, i'll try to figure out something [22:04:55] hi [14:09:04] hey [17:00:54] morning! [17:21:04] hey Mike [17:22:40] what's up [17:25:39] hey [17:26:08] hey guys [17:28:20] thewonderidiot, nice to see Frankenstein's CDU again [17:28:47] hah yeah [17:28:53] Marc has been sitting on that footage for a while :P [17:29:25] although I guess we know that Frankenstein is equal to AC Electronics [17:30:48] ooo I need to watch that later [17:32:37] the most impressive part of these videos is always how Mike can make any connections from part number to spacecraft/lab using the completely uncomprehensible documentation about that [17:32:51] I've tried and failed [17:44:34] hahaha [19:43:56] hi [20:00:47] hey Jordan [20:04:51] indy91 Has anyone checked my code for the highres textures? I've just started extracting the cuecards from the pdf file and trimming them, meaning the textures will be ready to position in the vc. do you also need the backs of the cuecards? there is usually only a single-colored surface with the velcros. [20:05:49] I was away for the past 2 days, so no, didn't have time yet to check it more [20:05:59] for the cue cards, I don't usually need the backside [20:06:05] I also removed the handwritten text that is on it. [20:06:24] but I think there are some reversable cue cards [20:07:20] yeah, the SPS burn cue card has things written on both sides [20:07:27] that's also why it has velcro spots on each side [20:07:35] but it should still be two separate meshes I think [20:07:38] just easier to handle [20:07:43] So I leave out the ones that don't have text on the back [20:08:25] treat it as if there is no backside [20:08:40] there are also some that are taped together in the middle [20:09:05] should they stay glued together? [20:09:08] right, they are so long I think you have them folded to be stored [20:09:28] yeah I think that could just be one single, long cue card [20:09:38] you don't take them apart [20:09:39] ok [20:10:02] seems like it is only the SPS burn and the T&D card that are two sides [20:10:21] but just treat them as if they were two separate cards [20:10:34] but maybe don't remove the velcro that is visible on those [20:10:51] like you did with the SPS burn cue card, I think that wasn't the accurate thing to do [20:11:50] since I am making them all new I will leave the velcros [20:12:05] i remove only the handwritten text [20:12:08] great [20:12:18] yes, I think that makes sense [20:12:27] we basically want them as they were at launch [20:12:39] or before launch really [20:12:46] ah, TPF card is also two sided [20:12:54] also has velcro on it [20:13:23] there might be some for the LM, but let's not think about that just yet :D [20:16:21] AC power/loss of comm also two-sided. But it doesn't really matter haha [20:26:10] i have thoose pdf files "0021400402_V.0.pdf", "510712945837_V.0.pdf", "49943672248685497042_V.0.pdf", "4994367224868549736b_V.0.pdf" I think I'll need everyone from here [20:28:32] I renamed them on my end [20:28:55] but I think there are 3 PDFs with CSM cue cards [20:29:22] one of them is mixed CSM and LM [20:29:29] and two more with just LM [20:29:41] so 5 PDFs with cue cards from Apollo 15 [20:30:56] oh and separately there is the EVA 1 cue card for the LM [20:31:02] not very well organized... [20:32:53] the Apollo 14 document is the guideline [20:33:04] where what goes, which are for the CSM etc [20:37:44] https://github.com/orbiternassp/NASSP/compare/Orbiter2016...Jordan-64:NASSP:HighRes_VC_Textures [20:37:54] I guess I will spend a lot of time on this page :D [20:46:14] you can also build it first and see if everything works [20:48:17] usually it makes sense to do both. There are things you easily notice in-sim, other issues are more easily seen in code [20:49:20] so, what is missing in this update still? It only has the 2x resolution VC textures, right? [20:49:42] so the TexMul thing right now doesn't do much, because TexMul = 1x wouldn't work [20:50:26] I can work on adding the option for that to the Orbiter launchpad [20:50:47] so that TexMul would be a user specified constant [21:01:17] TexMul in nasspdefs.h ist  "const int TexMul=2" [21:01:26]  jede funktion hat bei der deklaration als default 1"int xTexMul=1" [21:01:43] nur  beim aufrufen der funktionen für den vc wird der parameter "TexMul" übergeben, also der, der  als "const int TexMul=2" definiert ist [21:02:39] ansonsten für die 2D ansicht  wird der default übernommen und demensprechend mit 1  multipliziert. [21:02:50] ja, aber TexMul ist nur nötig wenn im VC die Auflösung vom Benutzer wählbar ist [21:03:07] 1 oder 2 [21:03:54] you could have the PA - Configurator const-cast it temporarily [21:04:29] yeah, it shouldn't be a problem to add that in some way, I can do that [21:04:39] but it requires both sets of textures I would think. No? [21:05:47] so that you can also choose whether you want to have the old or the new highres, you would also have to keep the old textures. [21:06:44] but do we want/need that? [21:07:06] if we don't the code can be made a lot simpler [21:07:21] if it works in terms of performance with the new ones, then you don't need the old ones [21:07:23] fixed 2x resolution in VC, 1x in 2D panel [21:07:59] we should probably decided that before we proceed [21:08:02] decide* [21:08:40] You can also do this if you don't want to change to a higher resolution later [21:10:06] for me in 4k screen resolution the new textures are sufficient. [21:13:32] indy91 https://www.dropbox.com/s/13ij4yolwx3qq9c/Images.7z?dl=0 [21:13:34] you can delete the card that you don't need here and send me the file again. that saves me a lot of work. [21:14:34] I think modern GPUs are still laughing about NASSP [21:15:01] CPUs not so much... but with the Sketchpad update it's a lot better now for the 2D panel [21:16:15] "you can delete the card that you don't need here and send me the file again. that saves me a lot of work." I'm sorry, I don't quite get what you mean. [21:16:23] what do you want me to send? [21:17:14] ich habe alle cuecards die ich habe in der datei https://www.dropbox.com/s/13ij4yolwx3qq9c/Images.7z?dl=0 kopiert. lösche die die nicht gebraucht werden, packe die datei und sende sie mir [21:18:05] ok, das wären dann erstmal all für das CSM [21:18:46] dann lösche ich alle raus für das LM [21:22:48] und die leeren Rückseiten von cue cards [21:27:01] du kannst auch die mitpacken, die du hast und ich nicht [21:28:28] das einzige was ich hatte bevor du angefangen hast war die DAP Monitor Card von Alex [21:28:40] alles andere stammt von dir :) [21:29:14] aber the DAP card ist ein bisschen zu groß denke ich [21:29:19] 8 MB Textur [21:29:43] würde also nicht schaden die nochmal neu zu machen [21:35:27] die texturen können skaliert werden ohne das mesh editieren zu müssen. das heisst wenn alles fertig ist und funktioniert,  können die texturen einfach  herunter skaliert werden [21:47:20] Soll ich die Cue Cards die du schon gemacht hast in der Datei beibehalten? [21:49:21] ja, lass sie drin, ich werde dann sehen welche ich fertig habe. hab mittlerweile weitere 15 zurechtgeschnitten. [21:49:59] das schlimmste ist die handschrift zu entfernen. [21:50:40] hab schon von der eine pdf datei 21 von 34 fertig [21:51:16] da ist eine card mit dem coas, wird die gebraucht? [21:51:27] nein [21:51:39] da steht coas boresight log [21:51:44] bin gleich soweit [21:51:48] ist die rückseite [21:52:07] einfach die Datei die du mir geschickt hast, mit allen LM und Rückseiten entfernt [21:52:22] ok [21:53:18] COAS boresight log ist glaube ich auch LM [21:53:35] Rückseite von einer LM ascent cue card [21:54:08] https://drive.google.com/file/d/1si1kwSaCk4UDBqylGAsz5PKJZ9Oe4N0e/view?usp=share_link [21:54:30] Also in der Gesamtzahl anscheinend 47 [21:54:37] für eine Mission... [21:55:30] glaube trotzdem insgesamt noch dass es einfacher ist alle meshes separat zu haben [21:55:42] mal sehen ob ich am Ende immer noch dran glaube haha [21:58:07] es ist einfacher sie in ein mesh zu packen. aber wenn es für dich besser wäre jede card separat als mesh zu haben ist es kein problem. [21:58:28] immer noch einfacher wenn man 10 meshes alle an einer Stelle hat? [21:59:28] was mich überzeugen könnte wäre Texturengröße. Wenn alles in ein mesh gepackt ist, kann man dann auch Texturen in eine oder mehrere Dateien packen und insgesamt Dateigröße sparen? [22:07:10] Naja, vielen Dank auf jeden Fall nochmal dass du daran arbeitest. Cue cards wollte ich schon seit Jahren in NASSP haben. Egal wie es am Ende implementiert ist, es wird bestimmt sehr hilfreich. [22:07:48] Good night!