[15:21:20] NASSP Logging has been started by n7275 [15:21:22] hey Niklas [15:21:57] hey [15:22:39] coming to an end with my Apollo 11 mission today, I think [15:22:51] after that I will be having your kind of fun, fixing mission scenarios [15:23:06] any saved REFSMMAT or state vector that is actually being used by the MCC [15:24:22] in most cases MCC calculations are pulling the REFSMMAT out of the AGC memory when it is needed, but I think there are a few cases where it uses one saved in the RTCC instead [15:24:40] and those need their coordinate system changed [15:25:46] "fixing the mission scenerios" represents a significant portion of my NASSP workload on my recent projects [15:27:56] your update increases some valve sizes in code by quite a lot [15:28:35] what even is the unit of the valve sizes? [15:28:48] l/pa/sec [15:29:18] ah right, I remembered it was something "intuitive" :D [15:30:43] code also says [15:30:44] float size; //grams / second at full open.. [15:31:24] I believe that comment is wrong, but I'm not 100% Sure of that [15:33:00] oh, yeah. it is in fact wrong. definitely litres [15:35:24] if you have a chance, would you mind loading one of the old scenerios in this branch and just giving your opinion on how broken it is [15:35:35] I also like how the GetFlow function of the valve class calculates a variable called "vol" for the flow [15:35:44] and then the tank class calls it mass [15:35:49] the same thing... [15:37:31] one of these days I need to make a pass through and fix things like that *without getting any bright ideas for new features* [15:38:08] I guess what I was trying to do was, establish if the valve sizes we are using make any physical sense [15:38:20] and if not then we need to ask ourselves why that is [15:38:26] but I guess it's not so easy [15:39:24] hmm [15:39:27] size= Liters/Pa/second [15:39:31] I am not really believing in this [15:40:05] oh no [15:40:15] valve class calls it vol [15:40:23] then tank class calls it m [15:40:39] but h_volume class then calls it vol again [15:40:47] so it is a volume, not a mass [15:41:20] then it makes sense I think [15:41:39] yeah. space.Break definitely uses volume [15:42:05] it just gets called the wrong thing in part of the middle [15:42:30] seems like it [15:43:24] ok, but like. There is a valve size that changes from 15.0 to 2.25E5 [15:43:28] how did you even get there :D [15:43:42] also, the use of "temp" to refer to "temperature", and "temporary" is mildly infuriating [15:43:45] at that point some other (bad) code kicks in [15:44:04] we have code in a few places that make sure tanks don't become too empty in one timestep [15:44:10] or else you get oscillations [15:44:29] so valve size used to be in.size [15:44:41] so I am kind of wondering if valve sizes that big even make any difference [15:45:54] now, they are sqrt(in*out) so just a mattercof solving for what the new out need to be to keep thrle same effective size [15:46:30] do huge differences between in and out valves even make much physical sense? [15:46:53] I had some debug code in the pipe constructive that printed the effective size to the log, and I compared that with the old satystems.cfg [15:47:04] morning! [15:47:11] not really. id rather they be the same size when possible [15:47:18] hey Mike [15:47:21] hi mike [15:47:46] I was trying to change the least number of things. [15:48:06] LEM was less bad. [15:49:50] if it gives the right behavior it's fine I guess, but we are really going into a dead end here [15:50:06] we need to think about starting the ECS from scratch [15:50:27] or at least, go through everything and remove several layers of special code that tries to fix special behavior [15:51:14] because that special code, like preventing tanks become too empty in one timestep, is what is surely responsible for us not understanding the behavior of the whole [15:53:01] x [15:53:10] oops [15:53:43] at some point we need to stop doing band aids and start improving some things fundamentally [15:54:03] I think it can only be done with a better integration method [15:55:11] if I ever run out of projects I would try this. At the start just 2 tanks, 2 valves connected by 1 pipe [15:55:36] and make them behave realistically with any tank and valve sizes and all the substances we support [15:55:49] ignoring the sun and all that stuff at first [15:57:04] anyway, the code hasn't changed much since I last checked this PR. So from my side it is good to go [15:57:14] only numbers have changed [16:00:27] in that case we can probably merge it, with a few warnings out to the users about not updating mid mission [16:00:34] hmm, I am making Apollo 11 mission scenarios from scratch. That might be a bit of a problem with my upcoming PR. [16:00:43] do you have a scenario updater script for this? [16:00:49] your PR will probably be merged first [16:02:05] I hadn't written one for this. probably wouldn't be too hard, just very tedious [16:02:56] hmm ok, I guess we will deal with it when I have actually created a PR [16:05:20] ah you hadn't even updated the Apollo 11 prelaunch scenarios [16:06:19] no faith that your PR gets merged first? :D [16:06:23] yep, just 7 through 10. I figured we would fix 11 when you had yours ready [16:08:12] we can do it in that order, too. I won't take many days anymore [16:23:31] hmm for the Apollo 5 MCC I hardcoded a REFSMMAT. What coordinate system is that... [16:47:20] haha [16:47:42] you know an update is taking long when you have already forgotten you fixed something [16:50:17] I'm familiar with that phenomenon haha [16:51:55] I had hardcoded the proper REFSMMAT and then converted it to ecliptic [16:52:09] and removed that conversion very early on in this branch [16:52:20] so all taken care of, yay [17:04:33] hmm yeah, I think I will write a little tool to convert scenarios as well, just the REFSMMATs [17:42:23] if you write it as a Python function, we can add it to mine [17:47:30] I don't know if that is a good idea. Like, right now my new Apollo 11 mission scenarios have good new REFSMMATs, but not your pipe size PR changes [17:47:56] or do you have optional features that you can turn on/off in your script? [17:48:19] also already started it in C++. And I don't really know Python :D [18:33:19] yeah that's fine [18:33:54] I was trying to impliment mine in such a way that previous versions could be upgraded recursively [18:35:15] so the version is 80000 it will do 80000->80001->80002, but if it's at 80001 it just does the 80002 upgrade; prevents it from applying the update twice [18:43:59] yeah, updating it twice by accident is my current worry haha [18:44:22] but I still think the NASSP version number should be more for the Systems SDK [18:44:52] I have tiny RTCC incompatibilities rather often [19:17:58] indy91, there is actually a SPSDK version number too. [19:25:05] interesting. Does that get saved in scenarios? [19:25:34] 1.9.10 [19:25:36] oh this [19:30:45] yep [19:31:12] I'll probably update it once I actually nake something better [20:35:27] night! [15:15:54] hey Alex [15:18:00] hey [15:43:47] internet's being slow again... [15:44:01] I managed to write a valve size update script [15:44:16] was a lot easier than I thought [16:30:02] morning! [16:35:17] hey Mike [16:35:50] any luck on the LVDC assembler? [16:36:32] haven't had a chance [16:36:35] very busy week :( [16:57:07] what time I have had has gone towards MNG reverse engineering [16:57:52] although the fact that I haven't really understood like 12 of the 14 flags, and the very complicated branching, is making me wonder how long it will really take to understand this lacking any information about it [16:59:32] that combined with the fact that I have relatively complete source trees for Sunrise 69 and Sundial E, both of which simply have some unique chunks of code that haven't been reverse-engineered and named, is making me start to think that perhaps what I should do in the short term is create fully-correctly-building but not-fully-named source trees for all of the rope dumps [17:00:07] and submit them all to the virtualagc repository. so people can look through and use the parts of the code they care about sooner, and I can feel less bad about sitting on a pile of incomplete disassemblies [17:01:28] maybe people other than me will even be inspired to name some things :D (not likely lol) [17:04:51] it would at least open it up to being looked at [17:05:28] yeah [17:05:34] I really should put some effort toward learning more about the software [18:27:28] hey [18:34:50] hey Niklas [18:35:08] how's 11 going? [18:35:34] wet [18:36:19] time to fix some REFSMMATs in old scenarios :D [18:40:16] nice [18:40:33] as long as it is not dry :D [18:41:51] needs a mighty skip reentry to be dry [18:43:02] although if you are unlikely you might end up in Hawaii [18:44:12] ah I made extensive use of REFSMMAT scenario saving vs. pulling it from AGC memory on my last round of Apollo 9 MCC updates [18:44:28] so got a few things to fix there [18:44:45] decided against a fully automated scenario updater [18:45:10] just a little tool where you put several REFSMMATs in a text file and it converts them in an output file [18:51:12] any in progress non-MCC scenarios will need to pull a new REFSMMAT out of the AGC [18:51:16] so calculate a new one [18:51:21] so slightly annoying, but nothing major [18:51:30] or calculate* [18:55:34] hmm and saved VPS state vectors are bad too [18:55:38] and the MPT [19:25:31] hi Niklas [19:26:32] I have a scenerio updater too! it took me like 20 minutes to write...I was expecting it to be much harder [19:26:55] so MCC will now always use a saved REFSMMAT instead of downlinking from CMC/LGC? [19:36:57] n7275, mine did bad things I didn't understand, and so I decided it wasn't worth it lol. [19:37:16] Only has to update like 6 lines maximum in a scenario, so, it's a bit different [19:37:49] AlexB_88, I am not changing that with this update. It's a bit inconsistent, some MCC missions use that more than others [19:38:39] I think with Apollo 9 it's that more often than usual calculations are done with REFSMMATs that aren't being used yet in the AGC [19:39:48] ah ok [19:39:57] so it has to use a stored one in the RTCC anyway [19:40:43] the REFSMMAT converts from inertial coordinates to IMU coordinates [19:41:02] and with the inertial coordinate system being changed I have to fix them in scenarios as well [19:41:12] they will now be identical to what is getting uplinked to the AGC [19:42:24] so no annoying conversions back and forth in the RTCC with those [19:51:23] right [21:02:11] oh fun. we have duplicate tank names in the LM and CSM. well that's thrown a wrench in the works [21:09:00] oh no [21:09:12] yeah I was actually wondering how you are dealing with that yesterday... [21:09:39] you will have to teach your parser to detect in which scenario section it is, CSM vs LM [21:12:37] probably just a CSM and LM flag when we roll by the regex.match(class name) or something like that [21:13:34] probably better than my initially janky idea if lines>3800: this is *probably* the LM [21:14:09] haha [21:14:20] yeah shouldn't be too hard to detect it based on vessel class [21:17:17] I'm okay making part of this rather ad hoc, because it's for a specific update, but not *that* hoc [21:23:55] I'm sure that would give fun bugs if it decides CSM/LM based on scenario line number [21:24:02] night! [13:16:37] hey [13:17:23] hey Niklas [13:17:57] I see we both have pull requests with more than 100 files changed now :) [13:19:16] fun :D [13:19:20] yeah it's just a draft [13:19:44] next step is adding a lengthy description [13:19:49] with the how and why [13:20:07] just to have a good explanation [13:22:13] and then I will check the diff to make sure I didn't overlook anything significant [13:22:25] but from my side at least it's probably ready to be merged this weekend [13:22:55] Ii need to think about mine a bit. on one hand, I'm changing things so they work how I expected they should when I first started using this code, on the other hand it's likely that I can't check it all and guarantee that it is 100% bug free and it feels like I'm adding yet more Rube Goldberg code. [13:23:46] don't worry too much about the 100% bug free [13:23:53] mine isn't either, for sure [13:24:11] "more Rube Goldberg code" yeah that's what I am more worried about [13:24:23] I am really sorry this is always happening to your PRs [13:24:59] but we have painted ourselves into a corner for many years with the systems [13:25:28] really hard to make things better while not also making it worse at the same time [13:27:40] I'm contemplating writing a very rough outline of what it would look like to rewrite SPSDK from the ground up. mostly as an exercise in what actually needs to be fixed (rather that what's easy to fix) [13:31:07] if I were writing this for the first time myself, pipes would have a size and valves would not [13:33:02] most real world pipes I've ever seen are the same size on each end lol. and if they're not, they're not like 10 orders of magnitude different from each other [13:33:54] haha true [13:34:09] yeah valves should be much dumber [13:34:18] mostly about being open or not [13:35:51] I'd be much happier pull-requesting that. [13:36:51] much simple to update too, since we don't have any pipe sizes saved in any scenario that need updating [13:37:48] I guess in some cases you kind of want both [13:38:06] variable vale size, like a pressure equivalization valve [13:38:09] valve* [13:39:24] bit of a weird case I guess [13:39:30] as it's really only a valve [13:39:35] and not much of a pipe at all [13:39:39] true, but that's currently handles by the pipe class [13:42:56] less pointers to access too [13:56:05] need to give this more thought first [13:59:32] hey [14:00:44] hey Alex [14:00:53] I wrote an essay [14:00:56] https://github.com/orbiternassp/NASSP/pull/1008 [14:06:11] ah nice [14:06:36] maybe that PR should just say "Files not changed" :D [14:07:43] a third of it are Apollo 9 mission scenarios haha [14:07:57] REFSMMAT updates [14:08:22] oh wait you really did right an essay:D [14:08:31] I missed the comment the 1st time I looked [14:08:52] write* [14:10:37] big changes require big justifications :D [14:11:20] haha [14:12:45] and as you see from the pros and cons, it's something I was on the fence about for a long time [14:12:56] but the first pro trumps them all lol [14:23:02] just finished reading it, yeah I think its a good change [14:23:18] maybe you'll now implement PTP mode? :D [14:23:58] much more possible now with the way the real RTE did it, yeah [14:28:20] although my latest attempt at Moon centered RTE improvements stalled at like 95% finished :D [14:28:24] but I'll get back to it [15:06:12] indy91, dangerous idea number 16000: make RTCC functions dynamically linked so that different combinations of "load modules" can be loaded by config [15:07:01] haha sounds interesting. Can you elaborate? I don't think I fully understand what you mean. [15:08:01] There is the very real issue of the RTCC class having become so huge that it is somewhat slow in VS for me. But everything needs to have access to everything... [15:12:55] I still have to make the RTCC TLI files fixed width, like punch cards, to make you happy :D [15:24:23] I was semi-joking about making the IPL process somewhat OS/360ish [15:30:42] I don't even know enough about that to comment on it :D [15:30:51] although I remember reading some stuff about linking [15:31:14] one of the IBM RTCC documents we have has some flowcharts that seem related [15:33:28] which one? [15:34:10] I've yet to make many connections between RTCC documents and the OS360 source I have [15:35:18] "IBM RTCC APS AS 500 Syst Integ Miss Sys Vol 2.pdf" [15:36:53] kind of hard to find in it [16:26:41] morning! [16:56:40] hey Mike [16:57:17] apparently NASSP isn't the only one with multiple definitions of the vector and matrix types [17:00:26] https://www.orbiter-forum.com/threads/mess-with-basic-types.41237/ [17:00:52] indy91, Apollo 17 FP has "SPS constants" uplinks at various times [17:01:45] SPS burn constants* [17:02:22] do you know what those are? Sounds like the erasable for the TVC stuff [17:13:17] pretty sure it is short burn constants [17:14:47] there is a RTCC system parameter that got changed during the mission on Apollo 15 [17:15:04] EFIMP16 [17:15:09] one of the short burn constants [17:15:22] so they likely uplinked that [17:15:38] not sure what that is based on [17:15:55] maybe cutoff residuals of the previous burns or something [17:22:27] ah [19:40:00] indy91, n7275, at GET 220:00:00 PAMFD orbit is 64.5x58.6 [19:40:19] it's coming up [19:40:21] and going down [19:40:27] post CIRC was 70x54 [19:40:54] huh [19:40:57] only down then [19:41:14] I'm not sure that this is correct [19:42:21] hmm [19:42:25] how so? [19:46:42] eccentricity can periodically decrease but it always comes back up again. there's a long term periodicity to it [19:53:51] I just mathed wrong. I thought there was a difference in semi-major axis, which can wobble but should stay fairly constant over time. [19:54:01] but it's not much of a change [19:57:15] ah ok [20:10:57] indy91, also, the TEI in MCC for Apollo 8,10,11 seem to use "CMCExternalDeltaVUpdate" for the TEI uplink, shouldn't this be CMCRetrofireExternalDeltaVUpdate? [20:11:31] well, also for 12 and 17 as I didn't change it. [20:12:20] I guess that would just update the splashdown coordinates in the CMC [20:14:52] yeah should send splashdown coordinates as well [20:20:26] ok [20:20:46] Ill change it for 12 and 17 [21:32:17] night! [11:55:52] n7275, I spot an easy to merge PR! [14:20:01] hey [14:20:14] yes, that one should be easy [14:40:08] it builds and it loads [14:41:12] merged [14:41:55] yay [14:45:09] I will have another PR in a little bit. some e-system code cleanup. no functional changes. [16:02:31] good, good [17:54:26] currently trying to finish up some uncommitted changes in another branch so I can switch back and push [18:17:58] I've marked my RTCC PR as ready for review. But to be honest, I am not really sure what one could check to make sure it works haha. It's kind of everything. Pick out at random some RTCC MFD page and check if it still works maybe. [18:21:40] I'll give it a few tests [12:07:02] hey Niklas [12:25:23] hey Matt [12:26:41] about your two comments on Github [12:27:38] I believe the correct behavior for the MPT display is to not show valid HA and HP for orbits with an eccentricity of more than 0.85 [12:27:52] it would actually show ZZZZZ.ZZ or so instead of zeros [12:28:34] so depending on what kind of maneuvers you put on the MPT, it can be correct to not show anything useful [12:29:50] and about VECPOINT, it could be the REFSMMAT. What did you use as inputs and with which scenario? And did you update the RTCCs knowledge of the current REFSMMAT first? [12:29:59] I did have to make changes for VECPOINT, so there could still be bugs [12:36:59] the maneuver I was entering was a circularization burn [12:37:04] in lunar orbit [12:38:05] but the detailed maneuver page looked okay [12:39:33] and I'm pretty sure I did not update the RTCCs REFSMMAT so that's certainly my problem [12:39:44] hmm, I'll check that circ burn then [12:39:49] shouldn't fail because of that [12:41:10] hmm [12:41:15] what mission was that? [12:41:24] might only fail with a specific trajectory [12:44:29] ok, I got a case where it fails [12:44:32] with LOI-2 [12:45:46] it was one of the Apollo 10 mission scenerios [12:45:52] 03/21/47/00.09 )PMMDMT( ERROR RETURNED FROM PMMAPD - INVALID APOFOCUS / PERIFOCUS [12:45:59] shouldn't fail [12:46:08] maybe the orbit is too circular :D [12:51:44] ah, found the issue [12:52:09] state vector gets converted to orbital elements [12:52:31] but it didn't process properly that it is lunar orbit [12:52:40] and so the Earth orbit calculations were used [12:52:51] which rejected the elements due to a small semi-major axis [12:53:10] so it just got confused about Earth vs. lunar orbit [12:53:20] and this is a section I heavily revised in this update [12:53:25] so it's a new bug [12:56:57] update pushed [13:03:25] cool [13:05:32] I fear there is going to be many little things like this over the next time, even after merging the PR [13:09:29] as long as there are no major MCC failures I am happy [13:11:18] I have another PR [13:11:27] it's going to be one letter being changed [13:11:55] I can probably review that :) [13:13:01] on my Apollo 11 mission I did the EVA. CDR was called Neil Armstrong [13:13:08] LMP was called LMP [13:13:22] bug with loading the mission specific LMP name [13:13:45] ahh, haha [13:15:33] I should probably investigate next why cue cards disappear on CM/SM sep [14:27:40] hey [14:47:22] hey Alex [15:21:20] hi Alex [17:44:01] indy91, I will try out your coordinate change branch today or tomorrow, I don't have enough time to fly a whole mission with it, but is there is anything in particular that would be best to test for it so I can give my review on git? [17:44:45] ah didn't see he was gone lol [17:45:04] .tell indy91 I will try out your coordinate change branch today or tomorrow, I don't have enough time to fly a whole mission with it, but is there is anything in particular that would be best to test for it so I can give my review on git?