[13:14:07] NASSP Logging has been started by n7275 [13:14:09] hello [13:29:36] hey Matt [13:36:17] ah at least the Apollo 17 LGC padload agrees bit by bit with the IMU bias compensation [13:36:23] so the scaling and such is probably all good [13:37:00] I'll push that update. In a next step I would add input boxes for the GUI and mission specific numbers for the flown missions. [13:39:39] the Apollo 17 LM seems to have had a terrible PIPA looking at these large values :D [13:43:36] what was the acceptance criteria for these values? certainly above some value they would've just been rejected [13:55:07] hmm, haven't seen any numbers on that before [14:56:46] I will probably run all my numbers through your padload calculator before we even think about merging, just to double check. [14:58:52] yep, I am approaching it purely from a padload perspective. Then we will see if we have agreement about scaling and all that [15:03:57] I did try letting the Apollo 11 CMC drift for 24 hours with compensation. The misalignment at the end was so small I thought I was in the wrong branch [15:05:35] that's how it should be haha [15:52:30] I tried flying PDI with no compensation [15:52:50] it doesn't seem to like it very much [16:01:57] with Apollo 11 biases? [16:02:37] yes [16:03:48] around 2:50 into PDI the LM which had been in a stable attitude up to that point decides to do some flips [16:05:33] hmm [16:05:44] that doesn't really sound like a drift issue to be honest [16:06:56] no [16:07:24] alignment is only 0.03° off [16:13:16] I can't think why it would be doing this. I'm just using our saved scenerio. I should try in the Orbiter2016 branch [16:13:31] was the FDAI doing anything weird? [16:13:53] maybe one of your changes affects the IMU attitude given to the LGC somehow [16:15:33] FDAI looked normal [16:17:52] hmm, if I push the abort button, it recovers and gets me back into a normal looking post-abort orbit [16:22:40] so probably not a PIPA issue [16:25:09] yeah, I would suspect not [16:44:54] Orbiter2016 branch, around PDI+6 https://imgur.com/a/DaY596A [16:46:09] oh [16:46:56] hmm, there really hasn't been any change recently that could do this [16:47:02] could it be a build issue? [16:47:07] I will try it in a bit as well [16:49:31] It was holding the descent attitude then, then very slowly tipped backwards (pitch up) did a single flip and stabilized again. The same thing happened twice more, until fuel ran out [16:53:01] ok, rebuilding to check for myself [16:53:08] Apollo 11 Before PDI scenario, right? [16:53:51] yes [16:54:43] I am not all that convinced it will happen to me, but we will see :D [16:58:53] The likelyhood that I just did something dumb is statistically, at least, a significant posibility [17:05:14] morning! [17:05:46] mascons have gotten to your head (or rather your LM) [17:05:53] hey Mike :D [17:09:47] yeah, mascons: the real cause of space-madness [17:14:01] I'm at TIG+3min, all good so far [17:16:26] when I tried in the main branch it was around +6 [17:17:55] all good here at throttle down [17:18:30] weird [17:19:21] joystick connected? This is Orbiter Beta and Orbiter2016 branch, right? [17:19:31] anything with the mission file... [17:19:42] no local changes [17:19:48] ? [17:21:19] I do have a joystick connected. hmmmmmm speaking of biases, I need to check something [17:22:20] maybe you did what I did in Elder Scrolls Oblivion many years ago then :D [17:22:29] it took my connected joystick instead of my mouse [17:22:33] took me a while to figure out... [17:22:54] there was a slight drift all the time which confused me a lot more than mouse not working at all [17:23:04] "why am I walking sideways" [17:28:49] well it looks pretty well centered. maybe it is a "hero of Kvatch" problem though [17:37:56] and aside from hardover, the ACA input shouldn't really matter in PGNS Auto [17:45:28] yeah [17:45:34] it didn't fix the issue [17:45:44] and I missed something [17:46:31] the FDAI needles are deflecting rather significantly before the attitude departure [17:50:44] the needles, hmm [17:50:53] so the PGNS does want to do something [17:51:16] the IMU pitch is fine before that happens? I was sort of thinking the LGC gets bad IMU input somehow [17:52:54] could LR data be doing this? [17:53:45] no [17:53:52] would have messed up the state vector [17:58:53] it appears fine. the needle definitely moves first, then the ball as far as I can tell visually, follows spacecraft attitude. your IMU alignment debug tool confirms this [17:59:22] seems more like a state vector thing [18:01:22] and you definitely did a rebuild after switching branches [18:01:32] VS open with unsaved changes? That has caused me trouble one time [18:01:54] and the scenario is also stock [18:01:59] Git GUI shows no local changes [18:02:11] yeah definitely did a rebuild all and confirmed that everything built [18:02:17] no local changes [18:03:03] I can send you a scenario in a little bit saved right in the middle of the flip [18:03:28] I'm out picking up lunch right now, back in a few minutes [18:16:58] Maybe gravity gradient torque or radiation pressure or something weird like that [18:20:07] i sent it on discord [18:20:55] got it [18:26:38] hmm [18:26:51] the state vector seems pretty bad, but otherwise I can't tell much from it yet [18:41:51] have you tried it without LR yet? [18:46:55] not yet [18:47:21] didn't you have a flip at 2:50 though [18:47:23] before LR data [18:47:29] before the 180° yaw even [18:48:36] well yes [18:48:42] so that rules out LR data [18:49:36] accidentally merged something to the Orbiter2016 branch? [18:50:58] oh possible haha. let me check [18:51:34] it sounds like a OO sort of issue :D [18:51:39] Do we normally get RCS flring during descent? [18:51:46] yep, a bit [18:51:50] in yaw anyway [18:52:00] also, is our DPS animated? [18:52:09] but if the DPS gimballing isn't quick enough for the DAP then it fires RCS [18:52:11] DPS is animated [18:52:39] I'd need to check somedebug info, but I swear it's not doing much [18:53:23] it shouldn't [18:53:36] it's slow any should only really point along the longitudinal axis [18:53:42] full LM CG is still centered [18:53:50] slow and* [18:53:54] ahh [18:54:05] you can do a V48 if you want to see it move the 6° [18:54:20] in fact I have a scenario from you before DOI where I can show you that :D [18:55:53] you could watch PIPA pulses next attempt [18:55:55] N21 I think [18:55:58] haha, oh yeah [18:56:33] My Orbiter2016 branch exactly matches upstream/Orbiter2016 [18:57:33] I need one of those LGC telemetry printouts [19:02:21] maybe it's some Orbiter setting [19:02:51] What should I be seeing for PIPA pulses [19:02:59] I'm not sure actually haha [19:03:52] R3 is jumping between -0056X and -1160ish [19:04:23] reading data might clear these registers every 2 seconds [19:05:24] oo we pitched down this time [19:05:46] nothing remarkable in N21 beforehand [19:13:49] how is the Eagle? Landed? [19:14:00] oh [19:14:12] by "pitched down this time" you meant flipped around, but the other way [19:14:22] not "normal pitchover" [19:17:23] and the flipping is done by RCS? [19:17:30] or the DPS, can you tell at all? [19:17:39] or some magic external torque [19:42:14] seems to be a combination of DPS and RCS [19:53:52] I guess that indicates the LGC wants to point the LM somewhere else [19:53:59] not a DPS or RCS or IMU problem, right? [19:54:15] I still find it suspicious that you worked on an IMU topic and now get this issue [19:54:24] feels related [20:09:46] yeah [20:14:00] I had two more theories, but both of them are wrong according to your scenario [20:16:59] if this is "real" behavior, then it would have to do with too much/too little thrust or mass or so [20:17:40] LGC trying to compensate for it and eventually flipping around [20:33:18] the thrust command is doing some odd things [20:33:24] needle that is [20:36:05] interesting [20:36:16] if it's not at 100% all the time that could be the cause [20:37:13] hmm [20:37:17] the actual thrust would [20:37:29] thrust command points to the LGC being confused about something [20:40:04] yeah, thrust command looks like it's trying to throttle way down too early [20:40:51] this has to be a PIPA scale thing [20:42:07] which can't really be because you aren't in your branch [21:30:46] this defies logic. [21:31:37] I would go through all the Orbiter settings, if there is anything unusual [22:06:33] night! [22:47:02] n7275: do you know anything about the uplink side of things? or have you been only focusing on downlink? [22:49:07] I know less than I'd like, but I've tried to pay attention to both in the documents I've looked through [22:49:32] What are you interested in [23:00:00] There's a document I'm trying to find " Command Flow" or something similar [23:11:19] we're trying to get our UDL working and have some evidence that the sub-bit patterns shown in the system handbooks may not be correct [23:15:09] This may have some info: https://www.ibiblio.org/apollo/Documents/Apollo%20Command%20System%20-%20Ground%20Net%20Data%20Flow.pdf [23:20:33] hmm, maybe not [23:36:25] I'm pretty sure the sub-bits are added to the Univac 642s to the incoming command message [23:36:43] by the 642s [23:45:59] there's a better document, and now I can't find it. it's the one I always find when I'm looking for downwind stuff, but it covers mostly uplink [00:10:27] oh actually thewonderidiot, page 20 of that document [00:10:49] "typical sub bit patterns" [00:18:16] amazing [00:18:24] different from the systems handbook, and also different from the actual hardware :D [00:20:14] oh interesting [00:21:11] so I take it you figured out what they actually are? [00:23:50] yep, we just flipped our first UDL relay [00:25:35] for vehicle code: 1 = 11000, 0 = 00111; for the rest of the bits: 1 = 01011, 0 = 10100 [00:34:04] interesting that there's so much variety in something where there's only 32 possibilities [00:36:40] hahaha yeah [02:44:01] .tell indy91 Aparently my joystick is sending out some random commands, *and* in addition to that: https://github.com/orbiternassp/NASSP/pull/1030/commits/e9c78884657e89fcb956f668ec761e4faaa819a7 [02:48:53] oh man :D [02:49:13] that will definitely make a difference haha [03:17:56] yeah, I was looking at PGNS vs AGS VI and finially noticed that my acceleration was about double what it should be [15:50:07] hey [15:54:19] but that's a commit in your branch not in Orbiter2016 [17:15:38] hello [17:17:23] indy91 this was two seperate issues, one of them affecting everything, and one of them only affecting the IMU branch [17:17:35] yep, makes sense [17:17:44] annoying joystick :D [17:18:01] so it did what, caused hardover? [17:18:21] yep, random full deflection ACA input [17:19:01] I need a better joystick [17:20:49] I had one, and I misplaced it the last time I moved [17:21:03] my joystick is old, but thanks to force feedback there have never been any centering issues. The ACAs have fairly strict deadzone limititations, so most people have had some trouble, usually in yaw. [17:21:21] deadzone requirements I should say [17:21:26] so now I'm using an old RealFlight controller + Vesim [17:22:36] it has some weird features that I dont understand like (I believe, at least) biasing the analog values as a form of trim [17:22:47] as spurious as certain abort buttons [17:24:38] Once I fixed that, I flew a few landings in Orbirer2016 [17:25:17] the accleration issue was a pretty easy find too. AGS/PGNS disagreement by a factor of 2 [17:25:23] VI [17:26:28] and those N21 values I shared yesterday were likewise twice as big as they should've been [17:27:26] morning! [17:27:44] But I was finially able to answer the question I started yesterday with: "Can I fly a landing with no compensation, if I start PDI with a good state vector and allignment" [17:28:02] hey Mike [17:28:05] to which the answer is, "Yes" [17:28:09] Hi Mike [17:28:31] yeah I would have been surprised otherwise. If any real IMU would have been that bad it wouldn't have flown. Compensation or not. [17:30:15] That was my assumption too. [17:44:06] down to 2200 differences, with I think all major new features implemented. my Skylark is becoming pretty Skylark-y :) [17:44:17] ooooh nice :D [17:44:44] is that a lot of small differences or is anything going to still make a big difference instantly? [17:44:58] I think it is mostly a log section ordering problem [17:45:32] I have some evidence that e.g. log section A comes before log section B in Skylark, but other evidence that log section B comes before log section A [17:45:38] which means one of them probably split up somehow [17:45:57] ah yeah, not that surprising with Skylark [17:46:23] so at this point I think I need to catalog all of the log sections that are present in the three banks that still have major errors, and figure out how to get them in the right order [17:47:41] is it some rendezvous related sections? [17:48:55] the little bit I looked into it suggested that it was P20 and P34 [17:49:10] which got R27 and major changes, respectively [17:49:23] hmm yeah [17:50:09] I'm uploading the video of the docked Skylab burn. Not much fancy editing, just showing that the DAP modifications from the deorbit study work and docked SPS burns are stable. I'll link the document in the description of course. [17:50:19] nice :D [17:50:48] the burn is the shaping burn as that is what procedures were given for [17:50:58] there would have been a second burn for the actual deorbit [17:51:38] I'm not even really sure what the plan was. Quickly undock after the deorbit burn? Or a stabilizing SPS burn to stay in orbit [17:51:47] that's one of the reasons why they abandoned the plan, too risky [17:52:01] undocking has to work quickly or you are in trouble [17:54:01] hahaha yeah [17:54:44] but in either case, they better had that relative motion worked out [17:55:32] sadly this document is the only one so far I have found about this topic. And it doesn't give much more about the deorbit burn than the Delta V of it [17:57:17] personally I have a better feeling with staying in orbit. The residuals are a bit higher with the docked burn, so you might not reenter as precisely as usual [17:57:26] and you have to get away from Skylab, changing the orbit [17:58:03] if I had to design the sequence, I would have done undocking, bit of SM RCS to get away and then a quick SCS SPS burn for staying in orbit [17:58:35] although, the TVC DAP should be fine, only the CSM+"LM" padloads are changed I think [17:58:45] so CSM only TVC DAP would work [17:58:59] even without reverting the erasable changes [18:02:06] right, yeah that makes sense [18:03:23] sounds like quite a sequence of events :D [18:07:57] the thread on NASASpaceflight mentions someone has actually seen a document that gives a sequence of events... I'll have to look a bit for anything [18:08:04] about that [18:28:17] https://www.youtube.com/watch?v=_ay5bK091oA [18:32:03] that's a long title [18:33:09] :D [20:44:05] personally I'd be more interested in docked skylab burns in the other direction :) [20:45:51] right? [20:45:56] seems more useful [20:46:54] or maybe a module that gets delivered to Skylab to do the job [20:46:57] like [20:46:59] https://en.wikipedia.org/wiki/Teleoperator_Retrieval_System [20:47:39] but weren't there also talks to do it with Skylab 4 or an extra launch or something [20:49:24] ah but Skylab 4 actually did a reboost [20:49:27] just with the RCS [20:51:21] about 10 ft/s of reboost, 180 seconds burn time [21:03:41] night! [15:44:25] good morning [15:45:46] hello hello [15:46:31] I think I will send some NARA requests today [15:46:54] before that also stops being a source we can access, better not wait... [16:26:33] done. Somehow I have the feeling I am going to have to pay this time haha [16:27:38] 80 cents per page is steep, but what I requested is probably just under 100 pages, so I think I am prepared to spend that on this [16:28:49] yeah, that could be a lot worse [16:30:48] I would like it more if I was sure what I am getting [16:32:13] and often new documents make me find more new documents I want, so it's dangerous :D [16:38:46] morning! [16:38:56] very dangerous :D [16:39:01] what did you request? [16:39:30] hey Mike [16:39:43] not one I had put on the shopping list, but related [16:39:56] Basically the 1970-1972 version of the AEG [16:40:29] https://archive.org/details/68fm119images [16:40:41] this is the 1968 version that Ron scanned for me a few years ago [16:40:56] sadly it has a few too many errors to implement it [16:40:59] from just this [16:41:18] and the equations are super complicated and not really possible to derive myself without all the sources it would use, so [16:41:32] I hope from getting a revision of this that I can maybe implement it properly [16:41:49] https://archive.org/details/NARASWSelectedApolloBoxes/page/n851/mode/2up?view=theater [16:41:51] ah nice, yeah, hopefully they fixed the errors and didn't just add on to it haha [16:41:57] this is what I requested specifically [16:42:19] this version mainly added another atmosphere model for drag, but, it should include everything [16:43:05] sometimes it's also not really an error but a scan where e.g. a minus sign has vanished [16:43:27] did you request all three of these? [16:43:29] if I have 2+ copies of nearly the same thing I can surely extrapolate what I need :D [16:43:54] I requested 70-FM-166 including all change documents to it, knowing that there are at least 2 changes [16:44:14] cool [16:44:38] revisions are always good to have [16:44:51] Apollo 14 LOI Targeting? Too many issues, couldn't implement it [16:44:58] Apollo 14 LOI Targeting Revision 1? Flawless [16:45:55] they made that a whole new document with the revision [16:46:01] instead of change documents [16:46:17] shows the amount of things that changed in between :D [16:46:34] hehehe [16:46:51] the two change documents shown here look pretty extensive [16:47:27] yeah [16:47:31] almost would have been easier to just republish change 2 haha [16:50:16] With the DKI, they published a new document in late 1969. Then Change 1 and 2 are two small additions. Then Change 3 has the changes for the Skylab rendezvous profile! And there even is a 4th change :D [16:52:22] oh man, lots of revisions [16:53:05] they squeezed the Skylab profile into the DKI somehow. Probably not much cleaner than how I did it. [16:53:15] No wonder they chose to develop a more generic system afterwards [16:53:52] hehehe [16:54:31] The first Shuttle rendezvous profile they came up with in the early 1970s already couldn't be supported anymore. [16:54:49] although, I have been thinking if it wouldn't be possible somehow to trick Skylark into calculating it [16:55:25] I have some dreams of writing an EMP for it, but, that seems farfetched [16:56:22] hahaha oh man. using those building block functions you were talking about? [16:56:28] yeah [16:57:37] once your disassembly is done I will look at the code, just to get some ideas for something like that [16:57:43] well, speaking of Skylark, my build is now 100% correct [16:58:00] and I have built up questions to ask you haha [16:58:27] awesome [16:59:30] so I am actually able to keep the Artemis log section ordering, with only additions and removals, if I split up two things [17:00:42] first, the routine DELRSPL moved from after P20-P25 to before it. in Comanche and Artemis it's located in section P30-P31, and claims some relevance to those, but I haven't figured out how haha [17:00:51] it seems like it's part of R30, that only is used for P11 [17:01:16] so I'm wondering if they might have moved it into the R30 log section [17:03:46] ah, DELRSPL is what calls AUGEKUGEL [17:04:33] the wrapper function that calculates estimated splashdown coordinates [17:04:37] mostly for Mode III aborts [17:06:24] has DELRSPL itself been changed in Skylark or only moved? [17:07:43] only moved [17:08:05] yeah in P11 you would use it for a Mode III abort. Burn the SPS until splashdown range error is zero [17:08:27] splashdown coordinates are padloaded to the end of the East Atlantic abort zone [17:10:08] relevance of DELRSPL to P30-P31... [17:10:11] uhh [17:10:46] none unless the Apollo 1 software calculates estimates splashdown coordinates with it in P30 :D [17:10:55] estimated* [17:11:06] the problem could also be my P20-P25 log section. but DELRSPL needs to come before a bunch off stuff in P20-P25, and P30 itself needs to come after. so if P20-P25 has not been split up, then DELRSPL needs to be separated from P30 [17:11:46] haha yeah, and since DELRSPL has nothing to do with P30 as far as I can tell, I feel like moving it makes sense [17:11:52] R30 is V82, right? I would say DELRSPL belongs to R30 or P11 [17:13:00] yeah, I couldn't make a decision there. I went with R30, since it's only called from there [17:14:38] next, related question: I also am pretty sure log section P34-P35, P74-P75 split up. this is perhaps less surprising haha [17:15:46] specifically, R36 (stared by V90) appears to be in the same place as Artemis, while a lot of the code for the rendezvous programs themselves moved to later in the listing [17:16:20] so the question is, does R36 deserve its own small log section like R30 and R31, or do you think it would have been co-located with one of the specific rendezvous programs? [17:16:24] I can confirm that in the Apollo 1 software P32 (prethrust for deorbit) a noun is displayed with splashdown error [17:16:36] oh interesting! [17:16:46] so the version of this routine would be called there [17:19:46] is the Norton manual of any help with the code order? [17:20:03] zero help [17:20:11] Norton makes his own groupings and order :D [17:20:21] thematically R36 almost belongs to P38 [17:20:25] both for plane change stuff [17:21:48] ah, I have a related question for P38. in Artemis, P36 is located in the P30,P31 log section along with P30 and P31. I left it there in Skylark. so maybe either R36 should go into there, or P38 should come out and join with R36? [17:22:15] (I mean, left it there and renamed to P38) [17:23:29] what do you have in "P30,P31". P30 and P38? [17:24:15] currently, yeah. and I even renamed the log section to "P30,P38", to deconflict it with my new "P31-P33" log section [17:25:00] if it works out with the order of things, P30, P38 and R36 could be together [17:25:28] I think putting R36 in that section would probably solve my order problem. let me see [17:25:45] I mean, you would only ever call in all P3X programs except for P30 and P38 :D [17:25:50] call R36* [17:26:59] oh no, that doesn't work [17:27:14] R36 also needs to be before P20-P25 [17:27:25] and P30-P31 (now P30,P38) comes after [17:28:08] R36 is an extended verb, V90 [17:28:22] maybe somewhere where extended verbs are living? [17:28:50] oh that's an interesting point. extended verbs come very early in the listing [17:30:08] nope, that is too early :D [17:31:56] thematically R36 also belongs to V83, V85, V89 [17:32:06] which are routines R31, R34, R63 [17:32:53] in the GSOP section 5 R31, R34, R63 and R36 are in one category [17:33:53] and in code, R34 is in the R31 section, R63 is in P20-P25, and R36 is in P34-P35,P74-P75 [17:33:59] I would not have guessed relatedness there haha [17:34:41] yeah R31 and R34 are very closely related [17:34:55] just have a different register 3 [17:35:58] I might just leave it how it is for now, giving R36 its own log section where P34-P35,P74-P75 used to be [17:37:19] so then last question: I currently have the rendezvous programs divided in to sections as follows: P31-P33, P34, P35-P37 [17:37:40] does that division make sense? I'm pretty sure P31-P33 as a unit is correct based on code structure. P37 is probably the easiest to move [17:42:19] P33 is quite different than P31/P32, but I guess there are some similarities in the subroutines it is using [17:42:32] P34 alone makes sense [17:42:38] P35 and P36 are closely related [17:42:57] P37 is a bit of a transitional program, not doing that much. I think that can stay with P35 and P36 [17:45:23] great, thanks! [17:45:44] one thing they introduced in Artemis is that the CSI and CDH programs sort of do a V90 calculation automatically and apply the out-of-plane DV. They retained that for Skylark's NSR (P34) calculation [17:45:58] so I guess R36 (V90) and P34 also have something in common [17:46:12] hmmm interesting [17:46:42] even if that relation make sense, doesn't necessarily mean that this translate to code structuring :D [17:46:46] haha yeah [17:47:02] well, like naming things, without a source for log section names the best we can do is get close [17:47:15] log section names and division of the code into them, that is [17:47:45] that's my current source build, complete with HTML files, if you want to start poking around [17:48:20] I left myself over 200 FIXMEs related to naming things, organization, and comments that need updating, so there will be a decent bit of churn still before I send it in to Ron :) [17:49:01] oh yeah I will look at this, thanks! [17:50:27] ## FIXME REVISIT [17:50:39] what sort of thing has to be fixed there? [17:51:39] that's on COE right? I don't remember, past me should have been more descriptive. I think it might have been that Norton was using names instead of numbers for pushdown list locations, and I wanted to see if it made sense to use names in the actual code [17:53:05] yeah, COE [17:57:38] yeah, if you look at COE in Norton (pages REND-24 and REND-25), he's using a bunch of names like PDRM, PDRA, PDCA, PDCAD, etc. for pushdown locations [17:58:01] which raises two questions: 1. did the listing also use names? 2. if it did, do they have the PD prefix or was that a Norton-ism? [17:58:37] neither of which was immediately pressing for disassembly or source reconstruction, thus the note to come back and try to answer those questions :) [17:59:41] I see [18:13:35] RM is already the name of a variable, so I guess that one would need the PD prefix [18:15:47] see but one of them is called PD8D [18:16:00] surely they wouldn't have equated a variable called PD8D to 8D [18:16:22] so was that just Norton not being creative for a name, or what [18:34:56] yeah PD8D is a bit of a useless variable name [18:39:33] another weird example, PDA in REVUP [18:39:56] what Norton calls PDA never has a chance to even have a name, because it's never referred to by address. it's just pushed onto and popped off of the stack [18:40:02] so surely that one came out of Norton's head only [18:40:38] see why I was confused and just put the pushdown list address numbers on my first pass? haha [18:41:02] Norton is simultaneously incredibly useful and incredibly infuriating as a source [18:51:45] Norton knows better, and half the time that is actually true :D [18:51:54] hehehe [19:16:25] hmm [19:16:35] "it will cost $116.00 as there are 145 pages" [19:17:13] slightly more than I had hoped [19:19:36] also, I'm not sure these payment options will work for me [23:04:19] oooo Fortran :) [15:43:23] hey [15:43:27] thewonderidiot, I got the document! [15:49:38] hello [15:51:33] hey Matt [15:56:00] looks useful [15:59:20] nice! [15:59:30]