[16:19:08] NASSP Logging has been started by thymo [16:19:13] Guenter! [17:27:15] Guenter's back! yay. [17:28:38] morning! [17:32:36] hey Mike [17:47:53] what's up? [17:52:22] just work. haven't been up to much apollo stuff recently [17:52:24] what about you? [17:55:37] what about you? [18:21:24] not too much. I've got a bunch of projects that I'm kind of taking a break from. mostly focusing on small things at the moment [18:24:35] one of my work projects is taking me very close to some real-time C programming, which is quite fun. [18:25:34] oh nice :D [13:01:48] good morning [13:02:47] hey [13:03:16] have you checked your PR after CM/SM sep? [13:03:47] in my sensor update I had to "unwire" the sensors for that case [13:04:11] because the SM systems aren't really getting deleted [13:04:14] just disconnected [13:05:35] that's possibly missing from your previous PR, too [13:05:47] CheckSMSystemsState in satsystems.cpp [13:05:58] that's where a lot of stuff is disconnected [13:06:02] at CM/SM sep [13:11:19] previously in GetTankQuantities it checked [13:11:24] if (stage >= CM_STAGE) [13:33:04] ahh. I seem to have missed that [13:46:20] I'm also not sure about your [13:46:22] dt *= oapiGetTimeAcceleration(); [13:46:24] addition [13:46:41] wouldn't it be better to replace oapiGetSysTime with oapiGetSimTime [13:48:11] and why is mass = space.GetMass(); in h_Tank::refresh necessary? [13:48:19] does that mass get desynced somehow? [14:19:18] Thymo, you requested some changes to the "Generalize usage of IsVessel" pull request and I think Gondos did the changes. Was there anything left to do? [14:59:59] I will take a look at both of those in a bit [15:01:01] I'm sure you added the " mass = space.GetMass()" for a reason. I just don't know the reason :D [15:56:08] I think I got confused about that, added it for testing, and forgot to take it out [15:56:36] mass gets updated when the flow functions are called [15:57:00] so not needed [15:58:38] ah ok [16:15:42] okay, the other sensors should be fixed now [16:29:43] oapiGetSimTime definitely works better [17:00:37] https://github.com/orbiternassp/NASSP/commit/af6db62862a4d9951ae8cc7f584db50e94a26c43 [17:00:56] maybe there was some issue with Orbiter 2005 that necessitated that [17:43:22] morning! [18:05:05] hey Mike [18:23:23] hey [18:29:26] yeah strange with the oapiGetSimTime vs oapiGetSysTime [18:31:11] must have been a first timestep thing [18:31:35] if only we could search the old forum for those terms, I bet we would get an answer [18:32:54] but I am happy with that change [18:34:02] I have changed the title of your PR to say that this change is in there [18:34:15] in case we need to track this change down when something is broken with it after all [18:34:37] merged [18:35:42] double digit open pull requests is annoying me slightly haha, I am trying to get it down [19:35:36] I need to work on getting my other 3 cleaned up. [20:00:02] my 2 are a bit hopeless as well [20:00:46] I still don't fully trust the RR inertial thing. it's not just in slew, also when the LGC designates the RR I had it twice that it got stuck [20:01:16] because it must have not expected the RR to move on its own in some way. That needs a lot more digging why it happened [20:02:01] and the cue cards were almost done, but there is a problem with fine tuning positions. Our CSM VC doesn't have the right proportions everywhere [20:02:14] and the only satisfying fix is to change the VC instead of the cue cards [20:02:36] so no idea when we are making progress with those :D [10:48:19] Morning [11:36:26] hey Gondos [11:36:56] I merged your roll indicator update [11:37:22] oh, nice [11:37:29] and for your "Generalize usage of IsVessel" pull request, Thymo was the one looking at that, so I am sure as soon as he has a chance he will merge that as well [11:37:40] did you see a performance impact on your hardware? [11:37:54] ok, thx for the update [11:38:39] I'm looking at the sprintf_s thing [11:39:08] haven't really checked for performance on that actually [11:39:15] but there is a lot of thing that would need changing beside the MS extension [11:39:44] somethime there are sprintf just to have a char * instead of a const char * I think [11:39:46] I am maxed out anyway haha, would have to uncheck V-Sync for performance testing :D [11:39:51] sometimes a const char * would do the job [11:39:57] lol [11:40:27] I am definitely a mass user of sprintf, in the MCC and the MFDs [11:40:40] I always used sprintf, but there were some bugs I couldn't really explain [11:40:54] that I thought might be caused by unsafe char arrays [11:41:07] that's when I started using sprintf_s, but not always [11:41:08] I wonder if doing a sketchpad Text helper to add format support would really lessen the need for sprintfs [11:41:47] yeah, it's really a mess^^ [11:42:19] lots of sprintf where a simpler strcpy would do the job [11:42:56] and lots of places where std::string would be better [11:46:22] std::string can perform memory allocation behind the seen so it would need some profiling [11:47:00] I would be fine with reverting to sprintf actually. The main advantage of using sprintf_s for me was hard crashes when something went wrong, which I could better debug [11:47:13] but it shouldn't be getting in that situation in the first place [11:47:18] yep [12:00:46] addMessage("You can has PAD"); [12:00:48] lol [12:03:04] dseagrav kind of added that as a placeholder. Never felt the need to change it haha [12:05:16] I think there is a dependency issue, sometimes the compilation fails "cannot find PanelSDK.lib" [12:05:31] happens once in a while [12:06:06] I've noticed that. It's rare, maybe only with rebuilds or so, but it does happen yeah [12:11:58] ok [12:16:14] BTW I wanted to try the CueCards branch [12:16:38] tried some scenarios but nothing showed up [12:16:56] is it still too much WIP? [12:17:29] there should be a bunch of clickspots that work [12:17:38] unless I forgot to include some files [12:17:55] also don't forget about the Orbiter clickspot bug when multiple VCs are in the simulation [12:18:04] so you have to switch views once or you can't click anything [12:18:49] but the version on Github should work. Click around on multiple velcro spots, especially around the DSKY [12:20:24] ah so you click the vlecro and the cards pops up? [12:20:33] yes [12:20:45] was expecting the cards to show on the 3D view directly... [12:20:49] in most spots there are multiple cards you can put there [12:20:52] oops^^ [12:20:55] so you cycle through them [12:21:05] ok, I'll try that later [12:21:29] the cue cards were very much up to the crews [12:21:54] some didn't find specific cards very useful and didn't use it much [12:22:25] also, some of the cards are only good for certain mission phases and actually block switches or lights [12:22:42] like the card for SPS burns, it's over the launch vehicle lights [12:24:08] so you definitely don't want to have that card during launch :D [12:25:48] hehe [13:24:54] hey guys [13:29:26] h [13:29:27] i [13:34:29] indy91, did anything change in the telemetry client wrt FC nitrogen pressure scaling with the last update? [14:30:20] uhh [14:30:48] no [14:35:41] re [14:36:13] I.m trying to see if the fmt lib can be used, I did a sample on MCC : https://github.com/orbiternassp/NASSP/commit/e410e6e287845584dd6773416bd550e5adc0c8e1#diff-fbcc682914be9519723bd4e392e3becb13db6714395927976862369bdb5e7eec [14:36:53] what do you think? [14:41:50] looks clean [14:42:54] yeah a bit cleaner, I'm more worried about memory allocations [14:43:21] I don't know if the code is called every frame or just when the PAD changes [14:43:49] when the PAD actually gets drawn [14:43:56] so when it first comes up [14:44:07] and then, if you display it again [14:44:21] so not every timestep [14:44:28] ok so no problem if there are a few allocation then [14:45:14] what is the advantage of this over sprintf? [14:45:23] the shame is that there is an API to use user allocated memory but it's not compatible with printf formated strings... [14:46:05] main advantage is the buffer size is handled by the lib so no memory overflow possible [14:46:57] there are lots of sprintf with MFDs [14:47:10] and those are called not every timestep, but often enough [14:47:15] understatement^^ [14:47:17] usually every 0.1s [14:48:17] maybe we should just go back to the normal sprintf and be careful with memory ourselves [14:48:26] I'm always a bit skeptical with external libraries like this [14:49:01] me too, that's why I wanted to do a test [14:50:56] I have no issue using good old sprintf [14:51:35] as long as the inputs don't come from outside my computer at least :p [14:53:33] also did this as prep work : https://github.com/TheGondos/NASSP/commit/1741882ea17099c27532dbdc3070e759a8428c5e [14:53:52] minor change just to remove a few sprintf calls [15:10:08] that's the kind of change again where I am not comfortable approving it myself, but will ask Thymo or dseagrav to take a look at it [15:10:40] especially in addMessage, I have no idea what that does haha [15:10:53] arf [15:18:27] I understand less sprintf == good [15:18:29] :D [15:18:45] less possibilities for things to go wrong [15:18:56] although, we have some rare MCC PAD CTDs [15:19:15] at this point I want to blame them on the DX9 Client or Orbiter itself more than NASSP [15:19:25] maybe some annotation bug [15:19:48] but in the end it's probably some memory unsafe thing NASSP does... [15:19:57] ok, I'll keep the standard sprintf then [15:20:24] but I think I'll add helpers to remove the clutter around skp->Text [15:20:56] stuff like that is ridiculous : [15:20:58] sprintf_s(Buffer, "%s", GC->rtcc->GOSTDisplayBuffer.err.c_str()); [15:20:59] skp->Text(1 * W / 2, 25 * H / 26, Buffer, strlen(Buffer)); [15:21:40] clutter is basically the definition of my RTCC MFD code [15:21:56] a simple function like that clears up some of the mess: [15:21:58] it's so easy to just copy and paste things I have already done [15:21:58] void skpText(oapi::Sketchpad* skp, int x, int y, const std::string &str) { [15:21:59] skp->Text(x, y, str.c_str(), str.length()); [15:22:00] } [15:22:08] yeah, that makes a lot of sense [15:22:40] hehe, I understand don't worry [15:23:20] the best thing I have ever done was to add generic input methods for double, integer and GET [15:23:44] before that I had to add three(!) functions for every MFD button that inputs some number [15:24:47] And that was even with the MFD buttons class from the LaunchMFD [15:25:14] Orbiter MFD code doesn't scale that well on its own if you get to 100+ MFD pages... [15:26:42] lol, I don't think it was intented to do that [15:48:28] there are several senses in which Orbiter MFDs don't scale well haha [16:02:20] https://github.com/TheGondos/NASSP/commit/e22de8b2b81334f2bc590f565b7908c00e47437d#diff-67b1fa4a7b00f8a3489a4f8013a550bdf300dcef0d62281a179607fd09c4fb67 [16:03:16] dry run looks like that [17:16:14] Gondos_, yeah I think that is a change I was considering doing at some point as well, don't know why I never did it [17:16:49] just cutting down on the number of lines of code would be good [17:18:00] ok, I'll do it for the MFD, we'll see from there if it's worth doing it elsewhere [18:42:16] man, so many ft/s NM comversion [18:42:47] crazy Americans with their imperial metrics, a miracle they didn't ran out of fuel halfway to the moon^^ [15:49:50] hey [17:24:48] morning! [17:29:52] what's up? [17:30:33] should be getting a LM-2 AOH vol 1 today [17:30:56] hoping it has more DFI / progamer stuff than the LM-3 one :) [17:31:43] Spider: "What's a programer?" [17:31:57] heheh [17:35:24] what are you up to? [18:00:42] eating dinner, preventing me from answering you immediately [18:00:56] haha [18:00:59] I actually reorganized the code of my AGC padload generator a bit [18:01:23] the only remaining things to do is making the GUI a bit prettier and figuring out license stuff [18:01:50] I am using Orbiter code, but that's what I all pushed into one file, with the same MIT license header as Open Orbiter [18:02:19] the old code from Jarmonik is a bit more tricky [18:02:25] I did a total rewrite really [18:02:44] oh nice :D [18:04:05] I didn't think much of the GUI when I had to quickly add support for the flown Luminary 131 [18:04:21] when I realized that we are actually getting that first [18:04:40] before Comanche 67 [18:12:21] hehehe [18:12:30] man I really hope Comanche 67 is only like a month or so away [18:15:05] by then our checklists might be done [18:15:19] and then I'll fly to check out Comanche 67 [18:15:23] the mission* [18:15:28] :D [18:15:32] so the mission should have good support in NASSP then [18:15:40] excellent [18:15:56] wasn't really my intention to support 12, but I guess that's what we get by not progressing quickly towards a NASSP 8 release [18:16:15] man depending on timing I might have a perfect storm of software to deal with soon. 3 LVDC listings and Comanche 67 all showing up at roughly the same time [18:16:17] hah yeah [18:16:37] it's been a while since 7 now [18:16:49] how long was it between 6 and 7? [18:17:27] uhh [18:18:00] I think 7 was in early, maybe January 2017 [18:18:18] there were various NASSP 6 release, I think it got up to 6.4.3 or something like that [18:18:53] yeah, looks like NASSP 6.4.3 patch was release in June 2006 [18:19:01] ever since then it was NASSP 7 Beta [18:19:16] oh wow [18:19:35] so we're nowhere near that bad for NASSP 8 taking a while haha [18:19:51] nope lol [18:20:21] I started out in mid 2014, only with the RTCC MFD at first [18:20:36] development was very slow then [18:21:21] the LVDC++ was really coming together, but everything else had stalled for a few years basically, due to Apollo 7 targeting issues mostly [18:21:49] so you could say we are almost as bad, because there was been constant development for 6 years now :D [18:21:54] has* [18:23:09] hahahaha that is a good point [21:41:05] night! [15:57:02] hey Nik [15:57:33] hey [16:23:20] is Ryan having some trouble with your new code for the cryo tanks, or is what he is seeing normal behavior? [16:30:43] did he post anything on Discord since last night? [16:30:52] I don't have it on mobile anymore [16:33:16] since he launched Apollo 12 I mean [16:33:35] the pressure fluctuations, I think he first talked about it 2 days ago or so [16:33:49] maybe when he repressed the LM or so [16:34:58] ahh [16:34:58] I fixed that. [16:35:00] we had the wrong critical pressures in hSystems.h [16:35:02] bad unit conversion between Pascals , Bar, and PSI [16:35:06] aaaah [16:35:13] yeah, that is the part that I missed [16:35:26] I guess I saw the commit for that fix though [16:35:33] I had fixed it in my Matlab code, but not in this branch [16:36:19] oxygen was condensed at like 50 psi [16:38:40] the cryo tanks are more sensitive to temperature than they were before, that's definitely true [16:39:13] but they seem to match the AOH phase plots quite well [16:43:44] as long as we stay below 200ish bar and, 1000K I think this model is a good compromise [16:55:50] I might need to make the "Boiler" class a bit more realistic [16:58:05] right now it's either full throttle or off. maybe adding some simple option for a ramp rate in the config file would probably do it [17:43:42] what is the boiler class used for [17:43:56] heaters and/or fans? [17:58:18] yeah, it's our eSystem generic heater [18:01:23] morning! [18:07:10] hey Mike [18:40:23] hey Mike [19:13:31] .tell indy91 https://gist.github.com/n7275/fdb46bb22eee1d8c3f8100108e9ff798 [16:16:30] evening [16:27:06] hey [16:28:19] I played with the sprintf stuff but the result is quite a ;onster to merge... [16:28:31] https://github.com/orbiternassp/NASSP/compare/Orbiter2016...TheGondos:NASSP:strings_rework [16:29:41] I tried to start replacing the sprintf with strcpy where possible to limit the work but it kinda got out of control... [16:31:09] haha [16:31:12] what is debugString() [16:31:18] I only know oapiDebugString() [16:33:41] not sure the strcpy stuff is worth it, it makes a lot of noise [16:34:02] in some cases you changed char array to string [16:34:03] harder to focus on the real changes [16:34:07] yes [16:34:09] but in other cases [16:34:13] char PGNS_Veh[8]; [16:34:18] to [16:34:20] const char *PGNS_Veh; [16:34:44] const char * when the string is only "driven" by code [16:35:05] so cannot take other values [16:35:33] so doing [16:35:36] res.PGNS_Veh = "CSM"; [16:35:39] is fine memory wise [16:35:44] even when done multiple times? [16:36:07] yes, "CSM" is just a pointer to readonly memory segment [16:36:35] ok. I'm never trusting myself with pointers enough to do it that way haha [16:37:12] how do you like rtcc.h, the world record holder of the most structs defined in a single file lol [16:39:33] lol [16:39:34] most of these changes are quite simple, will just be very time consuming to verify for no bugs [16:39:45] yeah, that is my fear [16:39:49] and I still have to learn how your fmt code works [16:40:55] it's basically an snprintf which returns a pointer to the buffer so you can do things like this : [16:40:57] annotation += fmt(buffer, "%02o %05d\n", i+2, form->Data[0][i]); [16:41:08] what I already don't like is that skpTextFmt does a "char buf[512]" [16:41:31] skpTextFmt would be called a lot of times possibly per MFD display timestep [16:41:41] hehe [16:41:43] in the current code it only has to define such an array once [16:41:57] it's in the stack [16:42:16] so it's just an "add esp,512" in the end [16:42:37] you will have to dumb that down for me [16:43:01] does it no reserve a fresh char array of size 512 every time you call the function? [16:43:05] not* [16:43:21] no, it's allocated in the stack [16:43:34] how [16:44:04] it reserves the space in the stack by adjusted the stack pointer (esp on x86 CPU) [16:44:26] and when the function returns, the stack pointer is set back to its original value before calling the function [16:44:27] I can tell you for sure that I have managed to make NASSP come to a crawl by accidentally defining a large char array every timestep [16:45:02] in the stack? [16:45:08] stack doesn't mean much to me lol [16:45:37] malloc and new requires heavy memory management [16:45:39] I'm an end user C++ developer, I dont understand what happens behind the curtain [16:46:30] but stack allocation is really fast [16:47:10] only drawback is that it's usually limited, you cannot reserve megabytes like that [16:47:25] and it vanishes when you exit the function [16:48:24] the alternative is passing the Buffer as another parameter [16:48:34] it will start to get messy [16:49:32] back in a bit [17:11:16] hey guys [17:12:11] hi [17:21:49] hey Matt [17:21:59] "passing the Buffer as another parameter" yeah that is what I would usually do [17:45:06] morning! [18:07:41] hey [18:07:56] what's up? [18:08:14] my AOH folder is getting too large [18:08:49] the worst one by far is the Apollo 13 one for the LM, from the AFJ [18:08:54] 650 MB [18:09:50] yeah that is excessive :D [18:11:41] and not even OCRed [18:12:29] waaaaaaait a minute [18:12:35] it's not Volume 2 [18:12:37] but [18:12:49] it has more FP7 addresses than I knew before, I think [18:13:57] oh nice :D [18:14:32] yeah I was going to mention, the LM-2 one has some AEA addresses for whatever flight program existed when it was written [18:17:50] sadly it is FP6 addresses [18:17:57] despite the change date of 1 February 1970 [18:18:18] oh that's lame [18:18:20] one features they added in FP7 is the second descent abort phase [18:18:23] feature* [18:18:32] and 673 became one of the numbers for it [18:18:40] but the AOH still says it is the FP6 one [18:19:40] the AOH lists the padloaded scaling factors [18:19:48] which were not in the G&N Dictionary [18:19:58] those addresses are quite crucial for a possible FP7 reconstruction [18:20:04] at least for the erasable memory part of that [18:20:13] but yeah, they are still like FP6 [18:21:20] in the AOH, in FP7 something has to have changed there [21:45:39] night! [14:51:37] hey [14:52:28] hey Matt [14:53:28] we don't have too many Boilers, do we? [14:53:56] always being concerned about performance I don't want to add too many "exp" that run on every timestep haha [14:54:04] just a few [14:55:01] yeah that's totally fine [14:55:06] I checked your script, nice graph [14:55:23] I guess the behavior makes sense, heating up taking time and such [15:02:07] and that should only run on Boilers that are explicitly told to in the config [15:04:12] ah [16:26:13] what projects are you working on these days? [16:32:39] hi [16:34:42] hi Gondos [16:36:49] I've reconsidered the sprintf_s thing, I may as well provide an sprintf_s clone function when compiling on linux since the fmt one is almost that already [16:37:31] that leaves only sscanf_s which is quite trivial to handle [16:41:15] hey [16:41:24] oh I barely added any sscanf_s, I think [16:43:07] yes it's less extensive a change [16:43:11] n7275, nothing for NASSP really at the moment. The AGC padload generator is basically done and my XRSound branch is what I should take a look at. It works, but it has compiler warnings I don't fully understand [16:43:33] cue cards are stuck [16:43:49] also creating a clone of sprintf_s is much easier than cloning sscanf_s [16:43:52] RR inertial slew is stuck until I do a deep dive into why RR coarse align sometimes fails now [16:44:18] in that branch [16:45:49] for the cue cards, we need some mesh changes to the VC right? [16:46:40] yeah a bunch of them don't fit because the VC doesn't have the right dimensions everywhere [16:47:32] and I think if we do a VC update now the texture update from Jordan becomes kind of unmergable. Or at least there could be problems [16:48:06] that branch has a lot of changes to the VC mesh, too, I didn't quite understand why [16:48:59] I should just withdraw into the RTCC world, I don't understand enough about the rest anyway :D [16:49:01] probably a case where we need to be very careful about the order in which things are done [17:02:54] Gondos, I guess %15s limits the input to 15 characters? [17:03:25] it should read all the characters but truncate when writing to the buffer [17:04:05] ah ok [17:04:17] I'm checking, but I think the valid inputs there are all 3 characters [17:04:22] so that will be fine [17:04:44] twas doing that already with sscanf_s :p [17:05:18] no? [17:05:38] not according to the diff [17:05:43] https://github.com/orbiternassp/NASSP/pull/912/files [17:06:26] I don't remember at all using countof, but I guess it must be standard with sscan_f [17:06:45] sprintf_s as an extra argument (unsigned)_countof(buff) to specify the buffer size [17:07:47] but I stand corrected, the man page states this : "The input string stops at white space or at the maximum field width, whichever occurs first0,00" [17:09:04] so it will stop reading and the next arguments will probably be crap [17:09:15] but no buffer overflow^^ [17:12:57] that static_assert doesn't hurt I guess, but probably not that necessary [17:13:45] I've put it because the buffer is declared far away from the sscanf [17:13:58] right [17:14:07] the other cases it's defined just above [17:14:35] text I/O is so much fun... [17:15:11] this seems simple enough, I can merge it [17:16:42] done [17:16:51] not the sprintf_s kind of breakthrough yet, but still a good step haha [17:22:34] hehe [17:40:27] Hi [17:40:48] hi [17:42:27] Gondos Have you given up working on the Linux Orbiter port? [17:49:21] nope [17:49:54] but right now I'm concentrating on NASSP [17:50:03]