[16:27:08] NASSP Logging has been started by thymo [16:29:30] the AAPO LEM has a basic VC [16:29:43] with working switches [16:34:27] yeah [16:49:42] https://www.dropbox.com/s/dzc5amu5pjufijo/Screenshot%202018-11-20%2011.49.28.png?dl=0 [16:51:17] do the measurements of it fit? [16:51:26] e.g. RCS positioning [16:51:30] no [16:51:35] but I can easily fix that [16:51:51] he included the source code with AAPO [16:52:27] I think the thing is originally based on NASSP, because theres a lot of NASSP textures used [16:52:54] I think the model might originally been the NASSP one, which he must of worked on [16:53:30] interesting [16:53:45] ill try and contact the author [16:55:48] Terms of use: [16:55:49] Orbiter Space Flight Simulator is the property of Professor Martin Schweiger. The Apollo Application Project for Orbiter (AAPO) is the property of Greg Hlynka. Individual components of this addon and it's source code may be re-used and re-distributed under the terms of the Creative Commons liscence. CC BY-NC-SA. http://creativecommons.org/licenses/ [16:57:37] CC BY-NC-SA: [16:57:42] "This license lets others remix, tweak, and build upon your work non-commercially, as long as they credit you and license their new creations under the identical terms." [16:57:49] doesn't really matter if you get permission [17:02:53] hmmm [17:04:16] I am trying to understand, does this mean we can use them, but just need to credit him? [17:04:47] maybe [17:05:03] but the licence is irrelevant if we get permission, which we should do anyway [17:05:49] yeah [17:06:50] What do you mean by irrelevant? It does say "and license their new creations under the identical terms: [17:07:17] I guess our license has identical terms [17:07:50] If you gain explicit permission from the author you are obliged to use his work based on what he tells you instead of the license. [17:07:54] as in we let others remix, tweak, and build upon your work non-commercially [17:08:14] right [17:08:29] That does not mean you can ignore it, he can change certain bits of the license just for you so you are able to use the work. [17:08:42] like what Virtual AGC does for us [17:08:44] Just like we got an exemption to the GPL for Virtual AGC. [17:26:33] ok I sent an message [17:26:37] a* [17:40:01] one nice thing about the VC is a working FDAI [17:41:11] morning! [17:42:19] hey [17:55:27] hey Mike [18:03:29] so, potentially bad news for me [18:03:44] NARA had one of the documents I requested yesterday, on aperture cards mixed in with their drawings [18:03:50] ND-1002009 [18:04:01] it's a G&N specification procedure for encapsulating modules with silicone [18:04:16] but.... this could mean that their drawings include other ND- documents [18:04:33] and if they have ND-1021040, that contains schematics for all of the test equipment [18:04:42] so bad news for your $$$ [18:04:44] yes [20:25:58] https://www.dropbox.com/s/x13lx2l1aa40m70/Screenshot%202018-11-20%2015.25.28.png?dl=0 [14:30:19] hey [14:32:19] hey Alex [14:37:12] most of the SCE is implemented, minus the power supply switching logic [14:37:37] it's quite complicated [14:38:03] oh nice [14:38:10] it's about 40 measurements [14:38:11] that was qick :D [14:38:13] oh [14:38:28] not quite like in the LM haha [14:38:39] if you loose the SCEA there then almost every display is off [14:38:51] yeah [14:38:52] but it's really not that many in the CSM [14:39:01] some of the most important ones for telemetry though [14:39:25] AOH says about the SCE switch that multiple selections of the Aux position switch back and forth between the two power supplies [14:39:38] I don't quite see that yet from the schematics [14:56:18] unless [14:56:36] well, I'll have to play around with it, haha [14:56:48] I also don't know yet why Apollo 12 needed to switch to Aux [14:58:36] http://www.spaceaholic.com/csimages/apollo_blockII_sce_uncovered.jpg [14:58:41] nice pictures of its inner workings [14:58:49] http://www.spaceaholic.com/csimages/apollo_blockII_sce_lateral.jpg [15:25:45] mice [15:37:42] hmm [15:37:51] I think I know now why Aux might be necessary [15:38:04] there is a possibility that both SCE power supplies get a power off signal [15:38:09] switching to Aux fixes that [15:38:32] yeah, it makes total sense [15:38:45] it would happen if the SCE technically has power, but also detects low voltage [15:38:58] and that's what happened [16:22:46] but I still don't get how Aux would "provide manual switching of SCE power supplies by repeated selection of this position" [16:23:13] doesn't that sound like this: Aux -> Supply 1, then off, then Aux -> Supply 2 [16:23:15] and so on? [16:25:23] yeah, weird wording [16:25:41] there is a flip flop involved [16:25:46] but it has no reset [16:25:55] so it would only reset when the breaker is cycled [16:26:14] and I think the breaker is only for the normal switching of power supplies [16:26:36] when the voltage from the bus is normal, but one power supply has a failure, then it automatically switches to the other one [16:26:51] caused by the FF getting set [16:27:25] the SCE also has a bus over and undervolt detector [16:27:31] that caused the Apollo 12 trouble [16:27:44] to protect the SCE power supplies that turned off both of the supplies [16:27:55] switching to Aux overrides that [16:42:55] seems like there is a specific voltage where the issue can occur [16:43:30] if the bus voltage is very low then everything would be off anyway [16:44:19] if the bus voltage is enough to power most circuits, but not enough to pass the check in the SCE (below 22.9V as per mission report) then the SCE turns itself off, despite it being able to run, in theory [16:45:01] if John Aaron remember this case, then this must be a usual case for the complete CSM load suddenly being on two batteries [16:45:05] remembered* [18:53:00] been playing with mesh animations today [18:54:42] oh, animations? Awesome [18:54:44] what kind? [18:54:58] I really want those antennas to move around :D [18:57:38] well that might be possible [18:57:51] but we need better meshes for them :D [18:59:37] AAPO's code has a lot of animations already implemented, so I am learning a lot just by looking at it. He also took the time to comment a lot of the source code which is helpful. Even if we dont get permission Ill be able to use this as a template for making new meshes/animations [19:00:08] hopefully we will though [19:00:25] yeah, I am often looking at SSU code how they do things, also helpful sometimes [19:08:28] the AAPO mesh already has animations defined for the S-BAND and RR [19:09:22] I don't know much, but I think it's important that the mesh has the right mesh groups to be able to animate them, right? [19:09:33] yeah [19:09:56] the geometry can always be worked out some way [19:10:07] but the mesh must be right [19:10:19] there seems to be a reference to a certain app in the code [19:10:27] "// Mesh resource file for descentstage.msh [19:10:28] / Generated with meshc on Wed Sep 12 10:28:11 2012" [19:10:56] oh of course, that one we have [19:11:12] yeah [19:11:41] if you can edit meshes into these mesh groups that would be awesome [19:12:10] the order of antennas to be animatet derives from their complexity, haha [19:12:20] RR -> Steerable -> HGA [19:12:39] HGA is three axis, that will be quite tricky [19:12:53] the Steerable S-Band antenna in the LM is at an 45° angle [19:13:00] so RR should be easiest [19:16:21] 3D panels are also just meshes being manipulated [19:16:33] so could also play around with the LRV, if you want [19:34:12] https://www.dropbox.com/s/y2ebi7iy7evetbg/legext.gif?dl=0 [19:45:42] oh nice [19:49:32] any idea how long that took in reality? [19:50:11] I recorded it at 0.1x [19:50:31] ah [19:50:57] but I dont know what is realistic, im guessing it would be pretty fast in reality [19:51:02] yeah [19:51:08] I'm trying to find something [19:51:28] complete LM Data Book probably would have something [20:17:17] let's see what voltage we get when we disconnect the FCs during launch... [20:19:31] 26V on MNA [20:20:33] not small enough to cause many issues, haha [20:21:02] but that wasn't the whole issues of course [20:25:06] when I pull a bunch of MNB breakers I get the MNA Undervolt [20:25:28] but not below 22.9V yet [20:30:15] interesting [20:31:27] but in general, not sure the power load is high enough at liftoff [20:32:52] also, the flight bus is powered by both main buses equally [20:33:21] so shifting the power to MNA wouldn't help unless I pull the flight bus MNB breaker [20:40:12] ok, got SCE to Aux to work [20:40:46] voltage dropped enough for the low voltage sensor to fail, but not enough for a complete SCE power loss [20:41:14] still a bit confused about the "repeated" selection of Aux [20:41:57] I bet this SRT Flip-Flop has to do with it [20:42:08] it has no reset input, which is weird [20:52:02] I'll ask Mike about next year :D [20:52:06] about it* [20:52:19] now I just need to wire all the SCE measurements in the CSM and PCM [20:55:36] are the PCM and SCE now complete? [20:56:48] CSM PCM still needs many more measurements not coming through the SCE [20:57:15] and the SCE is fairly complete, but still some things missing [20:57:20] inverter temperatures [20:57:29] SPS injector temperatures [20:57:53] and the pressures from the Saturn stage is its own project [20:58:09] because most of the logic should actually be in the IU [20:58:36] it's a switch selector channel even, so the LVDC switch from S-II pressure to S-IVB pressure for example [20:58:50] switches* [20:58:57] so lots of subsystems involved in that one [20:59:59] but I can see why an EECOM wouldn't like the SCE to go offline [21:00:19] main bus voltages, bat bus voltages, bat relay bus voltage [21:00:23] battery and FC currents [21:01:00] FC currents will have been what made the EECOM notice that the FCs were offline [21:01:18] well [21:01:22] and high battery currents of course [21:36:03] night! [18:34:37] good evening [18:49:53] hey Niklas [19:04:12] any more progress with animations? [19:06:57] not really. I am going to try to get good at making models 1st [19:07:38] Ive been practicing with blender today making various models [19:07:40] sounds good [19:08:05] SCE just needs FC measurements wired up to gauges and the CWS [19:08:30] while waiting for permission, im going to re-create my own LM models, using the AAPO one as a template [19:08:32] when you loose the SCE you will get a master alarm due to FC temps [19:08:55] but that was hardly something they would have noticed among all the other lights :D [19:09:00] nice stuff [19:12:01] I might have to rework the way that other systems get FC measurements in general [19:12:26] there is a function GetFuelCellStatus which was used for displays, PCM etc. [19:12:36] which just dumps all the measurements as a package [19:12:58] kind of hard to work with that and still require the SCE, instrumentation power [20:47:23] heres a start: https://www.dropbox.com/s/xm10s3lgj0qovyh/Screenshot%202018-11-22%2015.46.25.png?dl=0 [20:56:53] https://archive.org/details/Apollo_blueprint_archive [20:56:57] maybe this helps a bit [20:59:05] hmm thanks [21:16:17] seems like all sensors that the SCE uses also get powered by the SCE itself [21:17:14] all the others would be using one of the 4 instrumentation circuit breakers on panel 276 [21:19:00] classic CSM vs. LM design difference [21:19:11] where there is one CB in the LM, the same function in the CSM is done by 4 [21:28:46] night! [11:57:01] hey [12:01:38] hey [12:04:04] should get the SCE done today [12:04:19] just fuel cell measurements for the CWS missing [12:04:20] nice [12:04:44] so SCE to AUX should now do something? :D [12:06:20] yep it will [12:06:37] still not entirely sure it's behaving right, the flip-flop involved still confuses me a bit [12:06:46] the specific Apollo 12 behavior will also happen [12:07:01] right now only between a voltage of 20-22.9 [12:07:11] 20V is the usual voltage we use for systems being able to run [12:07:30] and 22.9V is a threshold in the SCE for it to shut off the power supplies completely [12:07:37] maybe to protect them from low voltage [12:08:02] when you switch to aux the auto power off is disabled [12:08:16] so between 20-22.9V the SCE fails, switch to Aux, works again [12:09:44] on Apollo 12 there is not much reference to the SCE after orbital insertion [12:09:48] that I could find [12:10:05] CAPCOM explains it a bit after TD&E [12:10:14] and even later they check what position the switch is then [12:10:17] which is Norm [12:10:24] no idea when they switched back [13:08:31] when researching new systems it helps going through the procedures to get the exact behavior right [13:08:49] but I don't think the SCE switch is mentioned anywhere in the AOH Volume II [13:08:59] only in the liftoff switch position check [13:11:53] yeah I guess you're kind of going blind with that one, procedure-wise [13:14:25] SCE in barely even mentioned in malfunction procedures [13:14:36] just a few occurances of "signal conditioning failure" [13:40:42] SCE is done [13:41:06] cool [13:41:33] I think I can add a few more things to the telemetry client then [13:41:35] may as well take a small break from blender to try out the SCE [13:41:49] sure [13:42:03] it's not easy to trigger the Apollo 12 behavior [13:42:04] I am about to put my fist through my monitor trying to get the shading of my model to appear right in orbiter :D [13:42:14] haha, ok [13:42:30] I'm sure you'll figure it out [13:42:34] yeah [13:42:57] I am close [13:44:05] I pulled the flight bus MNB breaker and moved every system I could to MNA [13:44:16] at some point you get MNA undervolt, but even that isn't enough [13:44:21] you need to go below 22.9V [13:44:26] then the SCE will fail [13:44:47] if the voltage is still above 20V then you can switch to Aux and it works again [13:45:03] you also should be able to see everything blank in the telemetry client [13:45:05] on the EPS page [14:11:52] hmm [14:12:07] I think I'll have to check some telemetry stuff [14:12:13] FC3 current is 0 [14:13:29] got the channels wrong on all of them it seems [14:16:52] brb [14:21:17] hmm, I think it might make sense to implement a generic sensor class [14:34:44] hmm [14:34:59] I am having a weird issue with reloading a saved state [14:35:26] I thought it was my meshes crashing orbiter, but Ive reset all the original meshes and its still happening [14:36:47] If I load a saved state from before the SCE commit, it loads fine [14:37:02] I probably made an error with it then [14:37:06] but anything I save now, I reload and it hangs when loading "Kitty Hawk" [14:42:54] haven't found the issue yet, but it should be an easy fix [14:43:56] null pointer maybe? [14:46:13] unfortunately I have broken my Orbiter just in time debugging somewhat, so I have to run it in full debug mode [14:48:43] ah, lol [14:48:58] some systems are simple enough so that you can save it in a single line [14:49:35] probably should make the SCE saving that way as well, it only saves a flip flop [14:49:48] but in those case when it loads it just needs to process a single scenario line [14:49:54] so the bug is [14:49:55] sce.LoadState(line); [14:49:59] but it should be [14:50:01] sce.LoadState(scn); [14:54:51] interesting that it didn't even give a compiler warning [14:55:33] fixed version pushed [14:56:32] it was funny because I was specifically reading a post about exporting blender models into orbiter, and how sometimes a model can cause orbiter to crash on loading... and I just so happened to read that as I was compiling your SCE update, haha [14:57:18] haha, sorry [14:57:29] no worries lol [18:13:40] Hello [18:16:05] hey [18:17:32] Might have found something, have you seen revision a of the Apollo 11 flight plan? With the pen ink changes? [18:18:16] Dated July 8 I believe.. [18:18:28] The copy I usually use includes Revision A, not sure about pen ink changes [18:19:36] I even have revision A as a separate document [18:19:38] What did you find? [18:20:23] oh, hmm [18:20:27] that's interesting [18:20:37] So I found an incomplete copy but it has an enclosure listing all the pen and ink changes, one of them being to mcc2 [18:20:54] there aren't only replacement pages, but also stuff only changed in that way [18:21:13] Says to avoid burning mcc3, mcc2 will be non free burn [18:21:31] I assume non free return [18:21:38] yeah [18:21:55] so, MCC-1 and MCC-2 are usually targeted for free return [18:22:21] 3 and 4 only correct the course for optimal approach of the Moon, but don't ensure free return [18:22:32] Right for 8 10 and 11 [18:23:19] So would they have used option 4 for mcc2 in this case? [18:23:28] yeah, general strategy stayed the same later. MCC-1 and 2 DV optimized (free return or not), MCC-3 and 4 just correct the trajectory to the Moon [18:23:40] possibly, yes [18:24:35] to avoid MCC-3, hmm... [18:25:22] I calculated it, the resulting mcc2 dvs are nothing like actual with either option 2 or 4, but loi dv with option 4 is way closer to actual [18:25:55] interesting [18:26:53] I think our S-IVB is generally overburning, so the MCC might not be similar anyway [18:28:51] it was close to free return still at least [18:29:31] mission report says -10.25° flight path angle at entry interface after MCC-2 [18:29:33] not so bad [18:30:08] another factor might also be that they used a biased landing site for LOI targeting [18:30:48] Not sure I follow [18:31:05] so, our LOI targeting and the real one have the same issue [18:31:16] they don't take into account the weird gravity field of the Moon [18:31:27] Oh mascons [18:31:47] yeah, but also the general perturbances (also simulated in Orbiter) of the Moon [18:32:01] what they did on Apollo 11 for the first time is use a biased landing site latitude in the LOI calculation [18:32:07] for LOI itself, not the MCC [18:32:25] that way they got closer to flying over the landing site at the planned time of landing [18:32:33] that also has an influence on LOI DV [18:33:01] so the LOI DV being different with free vs. non-free targeting and the real mission might simply come from that [18:33:38] all the mission control tapes from Apollo 11 are available, we can probably check them and find what they really used in real time [18:33:44] vs. planned [18:34:08] if we find no easier source [18:35:07] also, the non-free MCC-2 might only apply to larger calculated MCC-3 DVs [18:35:13] Ya the tapes not exactly an easy reference finder to use [18:35:14] might not have actually been done [18:36:00] yeah, that is probably it [18:36:09] it only applies to a special case [18:36:22] where MCC-1 must have been burned, but quite accurately [18:36:40] because if they were to do MCC-2 anyway, then MCC-3 DV is irrelevant [18:36:56] so I think it's for the case: MCC-1 was burned, but bad [18:37:07] they wouldn't want to do MCC-2 [18:37:11] but MCC-3 DV is high [18:37:22] so they do a non-free MCC-2 to save on DV [18:37:50] otherwise the "non-free MCC-2 to avoid MCC-3" doesn't make much sense to me [18:38:28] MCC-2 is a preferred execution point [18:38:31] MCC-4 as well [18:38:36] as per mission rules [18:38:38] So the just bumped mcc3 up to 2? [18:39:02] Using option 1 I mean? [18:39:38] no, I think it woulod be MCC-2 with option 4 [18:39:43] but only in this specific case [18:39:46] Right ok [18:39:50] MCC-1 with option 2 [18:39:55] burn doesn't go so well [18:40:08] or ground supplied SV was bad or something [18:40:24] then normally they would want to do MCC-4 next [18:40:26] DV too high [18:40:31] MCC-3, also quite high [18:40:40] even free return MCC-2 would be likely quite [18:40:54] so in that case they would allow a non-free return MCC-2 [18:41:07] reoptimized probably [18:41:11] so option 4 [18:41:37] I don't think this applies to the case where MCC-1 wasn't burned [18:41:56] because then MCC-2, being a preferred execution point, would be done in any case [18:42:10] oh [18:42:11] haha [18:42:19] mission rule 5-57D [18:42:31] The evasive manouver burn was already factored in I think right? In other words tli would have been slightly overburned to compensate? [18:42:35] A non-free MCC-2 of 3 sec SPS will be executed to avoid MCC 3 when feasible [18:42:59] quote mission rules, so basically the same as the flight plan update has [18:43:40] I always get confused with thos evasive burns, different procedure on every mission, haha [18:44:15] Yeah 8 they were pretty much guessing [18:44:34] I think it's the same as Apollo 10, which has a bias on the cutoff transient DV that the LVDC uses to cut off TLI [18:44:50] 2 m/s it was in the spacecraft operational trajectory [18:45:06] I have listened to the Apollo 11 tapes a bit and they talked about the evasive maneuver [18:45:17] the TLI bias does not account 100% for the evasive maneuver [18:45:24] it doesn't increase DV a bit for the MCC [18:45:28] does* [18:46:13] So maybe that’s why the change then? Almost like they messed up mcc1? [18:47:41] it's for the case they messed up MCC-1, yes [18:47:52] the pen and ink changes are still preflight of course [18:48:07] just on pages that didn't need complete replacement in the revision [18:48:31] it's good that you mentioned that, because the flight plan I usually use might be missing that list of smaller changesd [18:48:33] changes* [18:49:26] Ya i just found it last night I always use the remastered flight plan that has a bunch of typos, was looking for the original [18:49:42] yep, it looks nice but has errors [18:49:58] I have a copy from the Honeysuckle Creek website [18:50:19] I think that's missing revision A completely [18:50:30] and then one probably from the AFJ [18:50:36] which has the revisions [18:50:38] Ya I had that one b4 my iCloud deleted I found it again last night [18:50:44] but maybe not the pen&ink changes? I have to check [18:50:47] Afj link doesn’t work [18:50:58] At least not for me [18:51:51] yeah, some of those links got broken a bit ago [18:52:30] Also found an incomplete preliminary one dated April 15, has a lot more detailed mission notes section [18:52:52] oh nice, where did you find it? [18:53:07] Such as comm configs, lm activation detail, etc. [18:53:08] the not-reformatted version of the flight plan I sometimes use also doesn't have the revisions [18:53:31] Not sure I downloaded it tho can put it on Dropbox [18:53:35] the reformatted one doesn't seem to either [18:54:31] ok [18:54:39] no idea where you got it from? [18:55:33] https://www.dropbox.com/s/bwn9ak6624cor51/a11-fltplan1.pdf?dl=0 [18:55:56] I’ll search my history one sec [18:56:33] https://www.hq.nasa.gov/alsj/a11/a11-fltplan1.pdf [18:56:40] I just google the document name :D [18:56:48] so this part: a11-fltplan1.pdf [18:56:50] https://www.pdfdrive.com/apollo-11-flight-plan-april-15-1969-e55471151.html [18:57:08] so it was on ALSJ [18:57:17] Oh ok [18:57:44] Reminds me do you have to link for the lm gnc checklist? [18:57:53] oh, we have 3 of those by now [18:57:56] do you want 11, 12 or 17? [18:58:26] Sorry 11, google won’t give it to me [18:59:01] I had it b4 my iPhone decided to delete my collection about a month ago [18:59:12] it was hard to find, but it was actually in the collection of one of the physicians working on Apollo [18:59:23] Ya like a dentist school right? [18:59:29] https://utmb-ir.tdl.org/handle/2152.3/9629 [18:59:43] Beautiful thanks [18:59:58] yeah, some library of a medical school [19:00:16] preliminary flight plan is interesting, I downloaded the other parts as well [19:00:22] it has different options [19:01:31] Oh you found the other sections? On alsj? Or the site I found it on [19:02:00] https://www.hq.nasa.gov/alsj/a11/a11-fltplan1.pdf [19:02:06] I just changed the 1 to 2-5 [19:02:11] has several sections [19:02:24] Nice [19:02:50] the "option 1" spends a few more hours in lunar orbit after LM jettison [19:04:04] I thought they wanted out of there ASAp to avoid another “rendezvous” [19:04:05] also LM liftoff 2 hours earlier, but I think that is when the lunar landing also was supposed to be 2 hours earlier [19:04:28] yeah, the normal preliminary plan has the early TEI [19:04:32] They didn’t do a deorbit burn for the ascent stage right? [19:04:36] nope [19:05:05] nothing exciting, just a full 8 hour rest period in lunar orbit before TEI [19:05:22] instead of the looooong day and sleep only after TEI [19:05:41] Would have been tough to do one even if it was planned since Neil locked up the platform [19:05:54] true [19:06:03] although they could have put the LM in att hold [19:06:09] maneuvered with the CSM [19:06:12] and burned with the AGS [19:06:21] after jettison then [19:06:30] Ya but you can do sightings and mess around with p37 then right? [19:07:01] with the flight plan option 1 after TEI? [19:07:49] not much there after TEI [19:08:26] but they could have added P23s and P37s I guess instead of crew sleeping [19:09:50] Ya that’s what I meant [19:10:16] guess that also depended on how much they still wanted to do that after Apollo 10 [19:10:28] hmm, now that I realized that there were meaningful revision to the flight plan, it looks they changed the PTC REFSMMAT [19:10:38] I have to look at that in some more detail [19:11:11] They gave the csm solo it’s own mission time [19:12:39] where? [19:13:41] Oh wait no sorry the option 1 flight plan has a lunar orbit time listed in the same Margin as the mission time [19:14:20] Thought it was the csm solo time at first glance [19:14:33] sounds like a J-type mission kind of thing :D [19:14:51] hey CMP, you got your own CAPCOM, own schedule and now also your own mission time [19:15:59] brb [19:19:19] Well they had the two mission timers, actually I think they were supposed to set the Leb one to nominal lunar lift off time prior to lunar lift off. I assume that means 0:0:0? [19:20:02] I’m off to work anyways will ttyl! [19:48:31] http://reentrygame.com/ [19:48:41] a new game/simulator [19:48:45] and from the FAQ: [19:49:09] I’m a big fan of flight simulators... I had been playing NASSP and Orbiter, [19:49:11] and then [19:49:18] What about NASSP for Orbiter? [19:49:21] I’m a huge fan of the NASSP project (and Orbiter) and I really hope that Reentry – An Orbital Simulator can be a springboard for those who wish to take Apollo simulation to the next level. Reentry – An Orbital Simulator is simpler to get started with, and won’t be as realistic as NASSP. If you master the Apollo module in Reentry, it should be simple to get started with NASSP. [19:49:47] so it looks like there now is a game just so that people can get easier into NASSP :D [19:56:27] haha [19:57:29] kind of makes me feel bad about the state of NASSP. Not so easy to set up, a bit buggy right now, bad performance etc. [19:58:05] or rather, it makes NASSP look amateur-ish. Which it essentially is [19:59:47] nothing against you and Ryan, but if I of all people have to be the guardian of coding style then it's very much an amateur project :D [20:00:04] really wish dseagrav was around more... [20:00:32] yeah [20:18:14] best thing we could do for performance is move away from bitmap panels [20:18:52] and while the wiki isn't so accessible, how about you make a thread on the forum how to install NASSP 8? With the Orbiter Beta etc. [20:19:22] Mike or Thymo can sticky it [20:24:55] yeah I was thinking of doing exactly that [20:25:01] so sure [20:25:53] awesome [20:25:56] also with my increasing ability with blender, it could be feasible for me to make new models or NASSP of similar quality to the ones in AAPO [20:26:07] awesome as well [20:26:29] maybe get the LEM external model done in time for NASSP 8 [20:26:47] then right after release I could start on the VC [20:27:18] also, Id like to re-make the SPS engine [20:27:30] its a bit oddly shaped [20:27:40] sure [20:27:56] maybe I could also animate it with TVC [20:28:03] and of course animate the HGA [20:28:31] yeah, but as I said, probably easier to start with the Steerable or the RR, because they only need two axis [20:28:41] yeah [20:28:51] HGA is a separate mesh [20:29:19] which makes it easier too, because I dont have to modify the SM mesh itself [20:29:27] yeah [20:29:31] same for the SPS, a separate mesh [20:29:52] for all those SPS-less missions :D [20:34:16] not too unrealistc for an Earth orbit mission actually [20:39:17] yeah [20:41:08] fun fact, simulating the ASTP CM properly would be a bit of a nightmare, because all of the cockpit references to the LM have been changed to DM [20:41:28] well, it would need a different main panel bitmap [20:42:27] the CSM/LM TVC switch was changed to ATVC Gain with the settings Low/High [20:50:04] I think I finally fixed my normals issue in blender [20:51:01] The issue was that my model was showing up correctly in Orbiter, after recalculating the normals in blender, however the wrong side of it was being lit by the sun [20:51:40] huh [20:51:47] what fixed it was exporting it as a mesh, re-importing the mesh into blender, then exporting it again. Sounds weird but it worked [20:53:44] twice holds better [20:53:52] if that is a saying that works in english [20:54:54] never heard of it, but I think I catch what you mean ;) [20:57:17] doppelt hält besser [20:57:42] although there is a saying like that for multiple numbers [21:03:20] night! [18:37:41] hey [18:43:23] hey [18:43:40] https://www.dropbox.com/s/cwlc3jvfg02ev6j/Screenshot%202018-11-24%2012.12.56.png?dl=0 [18:46:39] looks similar to what we had a year ago :D [18:58:05] yeah nothing too visually appealing yet haha [19:03:19] looks good so far [19:04:30] https://www.dropbox.com/s/1cnoujt1kywzqv5/Screenshot%202018-11-24%2014.04.24.png?dl=0 [19:05:20] the list you see on the right is the AAPO model mesh list, which is hidden from view right now, that model is one I made from scratch frefernecing the AAPO model [19:05:26] referencing* [19:05:42] oh, great. That should be helpful with any animations [19:06:06] the mode there looks like Andre the Giant is the astronaut and needs a rather large hatch [19:06:09] model* [19:07:08] haha yeah, thats actually the outline for the whole cabin :D [19:09:13] didn't have much time today, I was just still thinking about how to handle sensors in the CSM [19:09:44] most of the unused CSM circuit breakers are probably instrumentation related now [19:10:38] so a generally applicable approach is probably the best. Most sensors will need power from some CB, and some will be in the SM, so that also requires some logic [19:12:27] I started wiring breakers in my CM_EPS_fixes branch [19:12:44] and from when is that branch? [19:13:37] I haven't done any updates specifically for that, but I did wired some things together whenever they were required [19:13:38] Last merge was in march [19:13:44] wire* [19:13:49] https://github.com/Thymo-/NASSP/commits/CM_EPS_fixes [19:13:52] e.g. the SCE breaker recently [19:14:03] also the SCS logic buses [19:14:23] good luck with merging :D [19:16:15] but instrumentation updates for the CSM would be less wiring CBs together, more like currently CBs with no function finally getting something to do [19:42:20] back in a bit [21:53:50] found a solution for sensors I am happy with [21:53:57] there already was a transducer class [21:54:13] overloaded it to a sensor attached to a specific tank [21:54:26] and made a temperature sensor out of it, outputting 0-5V [21:55:17] and in the CheckSMSystems function, where SM stuff gets disconnected after staging (or when a scenario with just the CM is loaded), it also disconnects the sensors from the CBs [21:55:54] so it fullfills all the requirements: outputs already scaled voltage, is wired to a breaker, can handle the SM being separated [21:58:02] cryo tank temperatures just was first on the list of measurements not implemented yet [21:58:11] it's on telemetry only [21:59:55] great [22:01:59] Shuttle actually uses the same kind of telemetry system with 0-5V sensors [22:02:57] but more streamlined, no need for the SCE. The SCE is for subcontractors who didn't get the memo about 0-5V sensor :D [22:18:18] night! [13:16:04] hey [13:18:07] hey Alex [13:18:20] CSM EPS instrumentation is done as far as possible now [13:18:45] nice [13:19:33] there seems to be a little bit of bugginess going on in high bitrate. Some voltages are displayed as 0 or very low. But only sometimes. [13:28:59] I'm just making my way through the telemetry list now [13:29:01] ECS is next [13:29:48] and giving the instrumentation CBs something to do [14:45:10] more progress [14:45:11] https://www.dropbox.com/s/wruka8e0th2ax62/Screenshot%202018-11-25%2009.44.42.png?dl=0 [14:47:19] very nice [16:18:05] ouch, I think the sensor voltage from the CO2 sensor is non-linear [16:18:18] so not just the gauge, but the sensor itself. And telemetry [16:19:33] looks like it's exactly quadratic though [16:34:01] haha, a document might be useful that I found a bit ago. Never thought there was an application for it. [16:34:18] 1200 pages of calibration curves for CSM-113 (Apollo 16) [16:42:59] yep, a curve for every single telemetry item [16:52:47] morning! [16:53:11] holy wow that is crazy [16:54:47] hey [16:55:01] yeah, all of that was probably processed in real time in Houston [16:55:15] to get from telemetry readings back to the actual one [16:55:58] for most the assumption of a linear function is definitely good enough though [16:57:41] CO2 level in the cabin even has three different curves, because it apparently depends on cabin pressure [16:58:10] property of the CO2 partial pressure sensor I guess [17:08:37] hmm, yeah, makes sense [17:12:08] the main reason this is relevant is that the sensor is also used for the CWS, where it was easily noticable that it's non-linear [17:13:45] 0V = 0 MMHG, 5V = 30 MMHG [17:13:52] but 2.5V = 7.6 MMHG [17:15:35] and converted to digital (0 to 255) any reasonable range of CO2 levels is then also measured more accurately [17:18:30] cya [17:28:03] how is the erasable memory research going? [17:31:56] oh, and I saw your idea to run Sunburst on the AGC, that sounds fun [18:02:47] indy91: pretty well, although I haven't worked directly on it the past few days [18:02:58] I've been working on designing a Monitor [18:03:26] monitoring? [18:03:57] that's what they called the main AGC test equipment / core rope simulator [18:04:02] ah right [18:04:19] I've gotten the core rope simulation aspect of it working in simulation, and aaaaaalmost have it able to simulate erasable memory as well, just going through the test connector [18:05:38] oh, that works? external erasable memory through the test connector? [18:06:04] it's a major pain to implement, but it can be done using the wire they added to the test connector for the auxiliary memory [18:06:14] ah, I see [18:06:30] (our AGC was made before that wire was added, though, so we'd have to add it ourselves) [18:07:05] if repairing the erasable memory fails, then that's the only way I guess [18:07:10] yep [18:07:21] well, if repairing fails and we don't find another module to use [18:08:14] right [18:09:14] I do need to order some more things for the erasable memory practice modules though [18:09:32] RTV-11, some G10 boards, and a drill bit that can make a 0.01" hole [18:16:42] a core rope simulator emulator [18:17:02] sounds just a little bit crazy :D [18:19:42] hehehe [18:22:03] running Sunburst would mostly need IMU data being input [18:22:28] also, there are some long periods of coasting, so even if it's automatic, it's not doing stuff all the time [18:22:33] and it's lazy about updating the DSKY [18:23:54] the registers at least [18:26:12] yeah, but we can get downlink [18:26:27] that should be interesting enough [18:26:30] yeah, downlink will have all the fun stuff [18:27:23] we need to have downlink working anyways for the one burn to work :P [18:27:33] very true, hehe [18:27:43] tumbling out of control is fun as well [18:27:47] haha yes [18:27:52] not a very good demonstration though [18:27:55] right [18:31:34] how well would it run CMC software? [18:32:00] hmm, dumb question [18:32:26] all the extra electronics that are usually connected to the AGC are probably still in LTA-8 or somewhere else :D [18:33:39] hahaha yes [18:33:45] we have to simulate everything [18:37:00] sounds like you need NASSP lite [18:41:19] yup [18:41:25] pretty much [19:11:31] man [19:11:37] erasable memory simulation is such a pain [19:11:49] I bet [19:12:22] largely because somebody (coughHUGHcough) had to be really clever with the DV instruction :P [19:12:55] DV is a lot of lines of code in agc_engine :D [19:13:06] you didn't make it better [19:13:09] and it breaks almost every single generalization I try to make about AGC instructions [19:13:54] it's the only thing that doesn't generate the control pulse sequence RSC WG, which means I can't feed erasable data into G directly [19:14:03] it doesn't advance the stage counter on MCT boundaries [19:14:12] it modifies the S register in a way that is invisible to the Monitor [19:14:20] it uses G for temporary storage [19:14:28] it is a mess :P [19:14:35] sounds like it, haha [19:16:20] S and G registers? Where are those? [19:17:21] they're internal registers the program can't see -- S stores the address that's being read/written, and G is the memory buffer register, so the instructions get data by reading from G at certain times, and write data to erasable by putting that data into G at a particular time [19:18:50] "program can't see" that's why I didn't know, haha [19:19:17] yep [19:19:53] there's also SQ, B, X, Y, and U [19:20:12] but B you can kind of see because of BRUPT [19:21:33] oooo, I just got a run with simulated erasable that doesn't appear to have outright crashed [19:23:06] the bank registers are doing kinda weird things at the end though so there may still be something subtly wrong... [19:24:23] oh shit maybe not [19:25:45] .....huh [19:25:58] so, behavior between the two is extremely similar [19:26:09] with and without erasable simulation active [19:26:39] but with it active, for some crazy reason the timing... shifted [19:27:15] hmm [19:27:49] something might still be broken with INDEX [19:29:51] hold on, let me take pictures [19:31:14] https://imgur.com/a/Q1rLCfE [19:31:30] so if you look at the bit where I have positioned the orange line... everything up to there is identical [19:31:56] and then there's a small block that is much shorter in the first picture (erasable simulation active) than the second (inactive) [19:32:06] and then after that everything is identical again, just pulled forward in time [19:32:13] it must not be looping for as long as it should or something [19:33:44] what's SA? [19:34:00] Sense Amplifier outputs [19:34:24] since in the first picture I'm using the Monitor to replace both fixed and erasable memory, nothing at all happens on the AGC's own memory lines [19:34:35] right [19:35:37] most of the stuff just looks delayed, yeah [19:37:24] extra 00+ in X [19:38:19] yeah, this is doing a CCS loop, using the loop counter for INDEX [19:38:23] so what is going wrong... [19:48:02] oh god damnit [19:48:18] this is such an incredible pain lol [19:48:57] the problem is with CCS, not INDEX [19:49:22] CCS is trying to figure out how many instructions to skip [19:49:39] and part of how it does that is with the TPZG control pulse... which tests to see if G is positive zero [19:50:12] thanks to DV making it so I have no way to get data into the G register in all cases, I've been bypassing G [19:50:18] but CCS can't work if the data is not in G [19:50:25] so my special cases need more special cases [19:51:12] extra special cases [19:51:21] maybe I will just put the data into the G register for everything except DV, and just do things even more different for that than I already am [19:51:53] I think my current logic doesn't work well for counter instructions that happen next to a DV anyways [19:52:12] I think it might think that they are DV as well and do weird things to them [19:54:35] yeah, SQ is unaffected by counts, so I need to explicitly make sure counts aren't happening when doing the funky DV logic [20:03:03] yeah, I gotta get rid of all of this and start over :D [20:03:11] ouch [20:03:52] just the erasable side of it, the fixed memory side is working great... I think [20:04:49] oh btw, the Auxiliary Memory Unit even cheated for this [20:05:09] I was getting really confused reading the final report from Raytheon, until I found this line [20:05:41] where was it... [20:06:16] here we go [20:07:21] "The ACM, if addressed, provides the data and forces it into G at any convenient time before T07 during these cycles. This is accomplished by the addition of a wire from the test connector to the WG/ gate in the AGC. Such a signal from the ACM, if a '1', will force WGG = 1. This opens the G register to the write busses, thereby making possible a data transfer from GAM in the ACM, to G in the AGC." [20:07:49] whatever works [20:07:55] they weren't satisfied with just MAMU and ended up modding the AGC they were testing with with another wire, that never became standard [20:08:02] but this sounds similar to your case [20:08:22] and their own listing of test connector pins at the bottom of the same report doesn't say which pin they used for it [20:08:23] lol [20:08:36] similar, ish [20:08:37] the cheaty one [20:08:47] but I don't want to cheat quite this much [20:09:06] we're going to add MAMU to our AGC, but that was a standard thing in all flown AGCs [20:10:35] although we're not going to add it in quite the original way [20:10:54] if we did it the original way, it would involve adding one wire and cutting one [20:11:06] but we can get the same effect by adding three wires and not harming any of the original wiring [20:11:39] sounds reasonable [20:44:42] alright, RTV-11 ordered [21:35:14] good night! [20:31:59] afternoon! [20:40:01] hey [20:47:11] what's up? [20:47:54] Finished implementing CSM ECS telemetry, but high bitrate seems to be buggy in general right now [20:48:32] randomly measurements get 0 as their telemetry value, so they are offscale low [20:48:43] at least I think that is what happening [20:50:55] unfortunately I don't understand enough how the sending and receiving works [20:54:33] hmm, CMC data doesn't seem to be affected, so I don't think it's a general issue [20:55:34] hmm, weird [20:55:57] might be something like a missing break; [20:56:05] it's using a lot of switch-cases [20:56:42] missing breaks are the worst [20:56:52] yep [21:07:02] let's see if I broke it or if it was like this before [21:08:23] lol, I downloaded the exe file on Github from a previous commit and Windows warns me about executing [21:08:33] no, it's literally not an unknown source [21:08:36] I build it myself! [21:19:03] old build still has the same issue [21:19:11] I'll research that tomorrow. Good night! [22:35:30] .tell indy91 I just checked and I was indeed unable to merge my EPS changes. I'm not sure how big the conflict is, can't tell from just Github. [18:55:33] morning! [18:57:14] hey Mike [18:58:14] what's up? [19:01:33] why am I not surprised. That's the most part of a year in development. Of course that causes merge issues :D [19:01:45] lol [19:01:55] an incredibly busy year even [19:02:20] yeah [19:02:35] although the merge issues might only be a few CBs that were wired because they were now needed [19:02:55] ah that wouldn't be too bad [19:03:21] hopefully [19:03:56] NASSP development is fast enough that taking a few months time for an update doesn't work too well [19:04:20] yeah [19:04:41] so unrelated, but I have good news and bad news from NARA [19:04:59] bad news other than their prize? [19:05:14] well, that is the bad news, lol [19:05:39] I have attracted the attention of the archives director [19:05:42] oh boy [19:06:02] and either she, or somebody higher up than here, realized they have been using the wrong pricing scheme for all of these aperture cards I've been having scanned [19:06:22] they have been charging me $0.80 per card, but the official pricing is, and they should have been charging, $4.00 per card [19:06:56] so uh [19:07:03] I probably won't be doing this as much anymore [19:07:05] you actually made them do work [19:07:08] that's what you get [19:07:12] yeah [19:07:14] damn me [19:07:38] the price for self-scan is only $0.40 per card though so more incentive for me to go there [19:07:50] but while we were discussing this she sent me an interesting link [19:08:03] https://www.archives.gov/research/hire-help [19:08:36] apparently there are professional researchers nearby that you can hire to go in and scan things for you, and they are only charged the self-scan fee [19:08:54] so that can allegedly be pretty cost-effective compared to having the archivists do it or flying there yourself [19:09:03] so I'm going to send a couple of emails and see what they say [19:09:31] interesting [19:10:04] I definitely can see how it might be cost effective :D [19:10:11] for sure [19:10:42] anyways the good news is, as you may have seen on the virtualagc website, it turns out that NARA has very nearly complete original schematics for the Block I (100) AGC [19:10:47] and both DSKYs [19:10:52] missing only logic module A23 [19:11:23] so Ron is having them digitized... and I hope he got quoted a price before I triggered the price jump [19:11:43] yeah [19:11:46] that's great [19:12:09] so we have a project for post 2019 to have nice automated Apollo 4 and 6 missions that work without Virtual AGC bugs :P [19:12:21] yep :D [19:12:48] and then maybe a year or so after that I'll get in contact with somebody that has such a computer that wants it powered up, lol [19:12:50] although I don't really know the Block I AGC versions. Did 100 fly? [19:12:54] yep [19:13:05] on at least Apollo 4 and 6 [19:13:16] AS-202 may or may not have had a series 50 computer [19:13:20] if not it was also 100 [19:13:41] I think we talked about the AS-202 version before [19:13:46] yeah [19:13:52] ah right, something was in the mission report or so [19:13:54] the AC final report seems to indicate it was 50 [19:14:02] oh right, also that mission report you found [19:14:20] I still don't have a clear idea of how 50 and 100 differed [19:14:24] 50 is barely documented [19:14:38] Block I, series 50 [19:14:58] so definitely 50 [19:15:11] and that's specifically for the AGC and not the guidance system as a whole? [19:16:16] whole thing I think [19:16:43] "The spacecraft 011 G & N equipment, Block I, series 50, consisted of a navigation base, IMU" etc. [19:16:57] that leaves open the possibility that AGC was 100 and everything else was 50... although I guess that is probably not likely [19:25:04] yeah [20:45:40] stycast 1090 was just delivered! [20:46:32] haha, it worked [20:46:57] that's what they didn't want to deliver to your home address, right? [20:48:33] yep! [20:49:07] they put me down on the shipping label as the "receiving department" for the company I work for :P [20:49:17] but whatever, I got it :D [20:49:27] the remaining materials are coming in the mail some time this week [20:49:38] then I just need to get a vacuum chamber and toaster oven, and I should be good to go [20:49:58] haha, vacuum chamber? [21:32:00] yeah, I need to de-air the epoxy after mixing and before pouring :P [21:52:05] of course :D [21:52:07] good night! [14:31:40] Hey [14:32:01] Last parts of my new pc should be coming in today :) [15:04:16] great [17:48:52] morning! [18:06:36] hey [18:14:47] what's up? [18:17:29] oh, not much [18:17:45] got a vacuum chamber yet? :D [18:21:01] no [18:21:16] but I, or rather Ron, got something else that is quite interesting [18:23:09] https://docs.google.com/spreadsheets/d/1DOwUA86ieQYosAoKf344AnlLbywgvx0-02Guc9StOfA/edit?usp=sharing [18:24:09] aperture cards [18:26:49] these are all of the drawings they have [18:26:57] that's a lot [18:27:04] I was told some years ago they had no Block II drawing numbers [18:27:10] but they appear to have found them [18:27:19] also JDCs! [18:28:10] what are JDCs? [18:28:35] job description cards -- procedures for performing tasks with the PGNCS [18:28:51] http://www.ibiblio.org/apollo/Documents/apollo_jdc_index.pdf [18:30:03] ah, I see [18:33:06] good to have the complete index [18:33:29] that's why I scanned that at Don's place [18:33:41] I never expected we would be able to use it... but I figured if we could it would be incredibly useful [18:36:18] indeed [18:45:12] the third AGC video was also great [18:45:21] but at this pace there must be about 10 more, lol [18:47:55] hehehe [18:48:03] I would say there are probably 2 more from that week [18:53:33] ah right, at the end it was basically ready for the non-memory power up [18:53:41] yeah [18:53:48] and the rest of the week was spent with it in that configuration [18:53:59] just pushing it further with things like the memory simulator [18:54:33] right [18:58:05] do you already have the next time working on the AGC planned? [18:58:13] not really [18:58:28] before the 5th decade is out [18:58:33] Jimmie let us bring the rope simulator boxes and erasable memory home with us [18:58:41] so we are plenty entertained without the rest of it, for the time being [18:58:58] oh, even the erasable memory [18:59:05] yeah [18:59:05] so basically once it is working then [18:59:11] yep, that's the plan [18:59:14] both fixed and erasable [18:59:34] in the meantime I'm working on being able to simulate both fixed and erasable memory through the test connector [18:59:42] in case either plan fails [19:00:00] yeah, figured out that delay thingy yet? [19:00:10] delay thingy? [19:00:29] where you showed me some screenshots from [19:00:47] delayed response by something [19:01:01] I don't have the technical terms :D [19:01:05] mmm, I think I must have figured that one out [19:01:28] the current problem is the four editing locations [19:01:33] CYR, SR, CYL, and EDOP [19:01:47] and how those interact with CCS and DV [19:01:48] there always is a next problem [19:02:03] oh I remember! [19:02:19] I know what you're talking about now :D [19:02:25] so yeah, I figured out the cause of that problem [19:03:04] that was a CCS loop [19:03:30] it was exiting after a single iteration with simulated memory, but going through 10 iterations with the "real" memory [19:03:44] the problem is that CCS uses the TPZG control pulse to detect +0 [19:03:51] TPZG looks directly at the contents of the G register [19:04:06] and because with DV I can't put data into G at all, I was bypassing G for all instructions [19:04:12] right [19:04:21] which means G was *always* +0 in simulation, and therefore CCS *always* took the +0 branch [19:04:41] so now I'm putting the data into G for all instructions except for DV [19:04:53] and for DV there's a special case where I respond to "read G" directly [19:04:59] so the special case of the special case you were talking about [19:05:02] yeah [19:05:05] so now the problem is [19:05:22] every single write to G triggers editing on CYR, SR, CYL, and EDOP [19:05:49] so because I am now writing the data into G, for those locations it is edited as I do so [19:06:15] so my first thought was to just store the data unedited and let the AGC do the editing when I stick it into G [19:06:39] but that doesn't work because DV, MASK, and MP don't trigger editing when they address those locations, so I'd need to know what the last instruction that touched that location was [19:07:00] and also DV doesn't load from G, so I'd have to do the editing myself in that case [19:07:06] sounds like a special case of a special case of a special case [19:07:20] so what I think has to happen, is I have to do the editing myself, and store the data edited [19:07:36] and then for all instructions except for DV, un-edit the data before I write it out to the G register [19:07:43] so if editing was supposed to have happened, it will re-happen [19:07:55] ....which sounds kinda crazy but I'm like 95% sure it will work out [19:08:03] yeah, sounds a bit messy [19:08:13] the test connector was not meant for this [19:08:16] all normal cases having to go through stuff for the space case [19:08:21] special* [19:08:26] space works [19:08:53] the AMU only extended the available erasable memory, it didn't replace the internal memory, so they didn't have to worry about this editing nonsense [19:09:21] and even then they decided that the wires available on the test connector weren't enough and added a nonstandard wire to their backplane that gave them an additional control signal for dealing with erasable [19:09:39] and the test set and monitor only ever simulated fixed memory [19:12:02] would be really unfortunate if that all becomes necessary just to run the AGC [19:12:09] yeah [19:12:15] better get that erasable fixed [19:12:21] definitely [19:12:59] I can deal with unreliable erasable memory, the G&C Checklist has procedures for that :D [19:13:41] if it's not working at all I am out [19:13:48] yeah this is not working at all [19:13:53] there is not even a chance the computer could run with this [19:14:02] yeah [19:15:54] dumb question, why can't you build an erasable memory simulator? [19:16:05] instead of going through the aux memory connection [19:16:50] didn't you start building your own AGC with lots of cores? [19:17:36] well it's possible, but would involve wiring 36 thousand cores with tiny wire and then building a module with compatible pins and things [19:17:45] and the cores would have to have the exact same magnetic properties as the AGC's [19:18:16] we could also put some modern electronics in there with transformers and things [19:18:32] I guess the pins are the problem [19:18:40] but we haven't explored it too much, since the primary mission is to fix the real one [19:19:06] AGC pins plus modern hardware (not cores)? [19:19:55] hm? [19:20:31] well, I am imagining some device using the same connector as the erasable memory module [19:20:39] but not using 36k cores [19:20:57] but something more modern [19:21:06] just using the same interface [19:21:21] right, that's what I meant with transformers and things [19:21:26] ah, ok [19:21:41] we'd need to use pulse transformers to give the appearance of a magnetic core switching polarity [19:21:48] I guess right now it's less effort trying to make the aux memory connector solution work :D [19:22:17] yeah, and we're going to need to use this test connector tool anyways [19:22:30] for dumping memory and single-stepping and things [19:22:35] general debugging [19:22:41] erasable simulation is just more FPGA code [19:22:48] right [17:02:35] hey [17:11:44] hey Alex [17:20:06] I'm researching the oapiRegisterPanelArea options to maybe improve performance [17:24:04] cool [17:25:20] ive got a few weeks off now, ill be able to continue work on he new meshes [17:26:24] great [17:55:10] morning! [17:55:36] hey Mike [17:55:41] what's up? [17:56:01] see 5 lines above [17:57:21] hey mike [17:57:33] oh nice [18:00:45] Basically, NASSP is about as bad as it gets performance wise in Orbiter [18:00:54] 2D bitmaps, redrawn every timestep [18:01:07] and big panels, especially the CSM main panel [18:01:37] all while running potentially two emulators [18:01:38] very CPU intensive [18:01:46] up to 3 [18:02:01] ah right [18:02:04] yeah [18:02:26] the standard way to build panels in Orbiter has changed long ago [18:03:09] but you can imagine it would be to change every panel and every switch :D [18:03:14] how fun it* [18:04:06] sounds like a blast [18:21:10] it would be better to just make a VC for NASSP 9 and get rid of 2D panels [18:21:49] the more I get familiar with blender, the more I think I could take on that job of making a VC [18:22:39] I would definitely need help on the programming side, but the modelling side should be no issue [18:24:50] we have good examples for VCs [18:25:00] and the good thing is, it doesn't have to be exclusive [18:25:09] for the transition period we can have both 2D and 3D [18:25:44] also, the CSM already has a 3D cockpit [18:25:59] and it has defined panel areas for DSKY and master alarm button [18:26:05] not sure if those actually work [18:29:36] getting the FDAI to work would be a fun challenge [18:30:24] the 3D panel texture doesn't even look half bad. I wonder if we could fairly simply create mesh and texture for the newer 2D panel architecture [18:30:52] if the conversion is simple then it's just coding. A bunch of it, but not that bad [18:31:00] and it would definitely improve performance [18:31:03] I'll look into it [18:49:27] indy91, I noticed something interesting in one of the memos about k-start tapes last night [18:49:54] ok [18:50:04] apparently when a erasable memory k-start tape is played to perform a padload, the tape makes numbers appear on the DSKY [18:50:21] I'm kinda curious how it did that [18:50:31] maybe like an uplink? [18:51:16] V72 [18:51:31] how does it interface with the AGC? [18:51:45] I'm not entirely sure [18:52:12] I'm hoping we might be able to get some of these tapes from NARA [18:52:34] that would be fun [18:52:36] https://history.nasa.gov/afj/ap15fj/csmgc/9-04.gif [18:52:39] the tapes all had drawing numbers associated with them, and those drawing numbers fall into ranges that NARA has on file [18:52:48] this is the flown backup erasable load update [18:52:51] maybe it is similar to that [18:53:08] could be [18:53:20] the numbers that show up on the DSKY are the type and revision of the tape being played [18:53:26] oh [18:53:28] uhh [18:53:34] that's different then [18:53:52] so not the actual data on the DSKY [18:53:58] right [18:54:49] would that apply to Luminary and Colossus? [18:56:10] so when doing a padload, R1 shows the program and revision (e.g. Comanche 67), R2 is the tape number, and R3 is the program revision revision (e.g. 1 for luminary 99r1) and tape number [18:56:29] +11067 apparently decodes to "Comanche 67" [18:56:31] that's really weird [18:56:32] in R1 [18:56:38] yeah [18:57:57] could that be running a non-flight program? [18:58:12] unlikely [18:58:31] from what I can tell they eventually stopped using Aurora/Sundial even at the Cape and just did their checkouts with Luminary and Colossus [18:58:59] with the help of EMPs that could be loaded through other K-start tapes [18:59:07] which I'm also hoping we can get... [18:59:09] so it could be an EMP [18:59:13] possibly yeah [18:59:23] I wonder if there's a JDC for performing a padload [19:04:17] that would be quite interesting for me as well [19:24:54] https://www.dropbox.com/s/v2zosucexolpt95/Screenshot%202018-11-29%2014.24.34.png?dl=0 [19:25:40] uh oh [19:25:47] looks like you've had a catastrophic depress [19:26:13] windows seem to be still unreliable [19:27:26] must be LM-1 [19:27:53] hehehe [19:28:05] I know they lost control of LM-1 but they must have *really* lost control for it to end up there :P [19:30:13] yeah, not quite enough DV to do this [19:30:28] a LM alone might be able to do a lunar flyby [19:30:35] also oh man, now that I compare the Don's JDC index booklets and the ND-1021042 table of contents... I think the even numbered JDCs in this area are themselves program listings [19:30:44] it is actually looking really likely that we'll get these [19:30:57] I could see that [19:31:02] what programs [19:31:19] like the padload one? [19:31:38] these are AGC checkout programs, more self-test kind of things [19:32:11] they are called: [19:32:51] INSTRUCTION CHECKS, TIME & WARNING CHECKS, MEMCHECK BANKS 0 AND 1, MEMCHECK BANKS 2 THRU 7, CHANNEL INST CHECKS, IN-OUT CHECKS, and ALLEREST [19:33:46] so extremely interesting to me, less so to you :P [19:34:10] what could ALLEREST mean [19:34:22] I think it's an abbreviation of "all the rest" [19:34:28] haha, ok [20:36:43] cya [10:49:44] .tell AlexB_88 From the Orbiter API Guide: "The panel can be saved in 8-bit or 24-bit mode, but 8-bit is strongly recommended to reduce the size of the resulting vessel module, and improve simulation performance." [14:01:11] hey [14:02:41] so 8-bit was the preferred one [14:18:00] yep [14:18:13] so I'd say go ahead and change them to 8 bit if you want [14:31:02] I'm still testing and researching panel redrawing [14:31:15] I think especially with all the switches there should be a lot to gain [14:31:23] they don't need to be redrawn until switched [15:20:19] nice [15:20:33] btw I am pretty sure that all bitmaps are 8-bit already now [15:21:50] maybe in your local copy [15:22:00] the ones you changed say 8 bits for me [15:22:06] yeah [15:22:12] the others are 32-bit [15:22:22] e.g. CSM main panel says 32 actually [15:22:23] yeha [15:22:28] yeah* [15:22:31] but there should be no 24-bit ones left [15:22:50] ah, ok [15:22:57] the thing is the 32-bit ones are actually smaller sized then 8-bit [15:23:08] however that works, haha [15:23:09] its like if they are already 8-bit [15:56:51] the new meshes im making will actually be a fraction of the size of the old ones, as they actually seemed to have every polygon doubled to have both outward and inward sides showing. We of course do not need every surface of the LM to be that way so most of my LM is one sided [15:57:12] which is the way the AAPO mesh is too [15:58:52] that of course means that if you try to view the inside of the LM from the outside, you will see through it entirely, but I am making an interior mesh as well so that wont be a problem [16:08:35] sounds good [16:10:48] if I manage to get the Checklist MFD to work with it then I'll probably be able to make all the switches ony be redrawn on mouse click [16:11:34] I'm still not fully understanding the order in which some things are drawn, but if I figure that out then I can do some nice changes that hopefully improve performance [16:13:50] great [16:13:52] and any of the meters only have to be redrawn, if their needle actually move a pixel [16:13:59] I think that is the ideal setup [16:14:35] so only a small part of the panel elements should even be redrawn per timestep [16:27:21] I am actually surprised that it gets redrawn every time step [16:27:39] would definitely make sense that the fps would suffer [16:28:09] I think it's the worst combination performance wise [16:28:17] every timestep, not just with mouseclicks [16:28:25] so PANEL_REDRAW_ALWAYS [16:28:57] and also it copies a surface from the background bitmap every time for every panel area [16:29:03] PANEL_MAP_BACKGROUND [18:34:10] morning! [18:36:34] hey [18:52:40] how's things? [18:53:53] still improving my knowledge of Orbiter panel redraw stuff, haha [19:05:45] hehehe [19:34:36] so, I got really good news this morning [19:34:42] NARA has a bunch of drawings that I asked about [19:34:48] 2003011, our broken erasable memory [19:35:12] ND-1021039 and ND-1021040, which are the GSE manuals from AC Electronics [19:36:00] logic drawer assembly drawings for the computer test set [19:36:09] at least some K-Start tapes [19:36:22] I am incredibly excited for Monday [19:41:05] sounds awesome [20:49:43] the classic daily "I have learned some things about the Orbiter API, now revert all the changes I made today" [21:21:56] hahahaha [21:22:03] yay learning! [21:26:29] looking at SCS instrumentation now, with that at least I know I can make easy progress [21:26:50] SCS has its own signal coniditioning equipment, no wonder it's not using the SCE [21:32:22] that confused me a lot a few days ago. Switches called SIGCondDriverBiasPower1Switch and SIGCondDriverBiasPower2Switch [21:32:36] nope, not SCE, that's for SCS instrumentation [22:03:02] SCS is a very modern system, it has about 40 transistors :D [22:25:53] night! [14:18:07] morning [14:18:52] Hey [14:24:19] hey guys [15:06:47] whats up? [15:22:53] Currently installing Win10 to my new pc. [15:27:05] got annoyed with panel stuff, looking at SCS instrumentation now [15:34:30] haha yeah that panel stuff is complicated [15:37:01] unfortunately SCS instrumentation needs a bunch of changes before anything useful can be done :D [15:37:24] the logic for the FDAI switches in the CSM is done in panel code [15:38:03] so the scaling for e.g. the attitude rate displayed is also done there, but should be done in the EDA [15:38:07] Electronic Display Assembly [15:38:35] telemetry gets the already for the FDAI scaled attitude rate [15:39:05] so before that can be properly telemetered, the logic has to be moved to EDA code [15:39:52] some of the scaling is even done in FDAI code itself, which is why it currently has special code for CSM and LM [15:41:19] at least with these changes the SCS logic buses are getting something to do [15:54:52] AlexB_89, did you start on the installation guide post for the forum yet? [16:06:06] no not yet, but I can do it soon for sure [16:07:26] yeah, would be great to have that, with Orbiter Beta and all [16:12:31] I think I'll write one with all the keyboard commands [16:13:02] no good central place to find a list, and some were added recently for the DEDA anyway [18:34:41] morning! [18:42:26] hey [18:42:41] remember that you got us LM ECS schematics from NARA some time ago? [18:42:47] yep [18:43:09] are there any CSM ones there as well? [18:43:23] possibly [18:43:27] got a drawing number? :D [18:43:31] haha, nope [18:43:50] all I have is the system name really [18:44:27] I have the same issue as the one that lead us to request the LM-8 Systems Handbook actually [18:44:36] two relays with the same name on a schematic [18:44:49] and I don't know which subsystem they belong to [18:44:59] there are at least some boxes there whose numbers are NAA numbers [18:45:06] CSM Systems Handbook is even more lazy mentioning that than the LM one [18:46:04] hmm [18:47:00] really what I would like is a list of relays [18:47:19] like the LM elementary functional schematics docs have [18:48:56] hmmmmmmm [18:50:26] surely there must be a drawing number somewhere out there [18:52:05] the SCS training manual just has reference to some more detailed training document [18:52:24] "BG 285 Electronic Display Assembly TDS 1004" [18:52:28] whatever BG and TDS are... [18:52:42] probably just more training material [18:54:49] http://media.liveauctiongroup.net/i/26155/23434037_5.jpg?v=8D2CA69B3844C30 [18:55:30] hmm, actually [18:55:38] I know which relay is definitely in the EDA [18:55:45] so anything about the EDA wouldn't help me really [18:55:59] the other relay must be somewhere else [18:57:33] how much did the ECS differ between Block I and Block II? [18:58:34] ECS? [18:58:44] this is CSM SCS [18:58:58] not sure about CSM Block I ECS [18:59:09] oh [18:59:29] the LM ECS question was just to refresh your memory :D [18:59:33] I see, lol [19:00:39] well, I found some ECS numbers, and it looks like the answer is yes, they will have it if you have a number [19:00:50] oh great [19:00:54] how did you find ECS numbers? [19:01:24] https://app.box.com/s/d8ecxw99mg9ucjeomw0m [19:01:51] there's a references section at the end [19:02:05] everything listed falls in ranges shown in the NARA drawing index [19:03:10] what kind of number am I looking for? [19:03:44] the NAA/SID ones? [19:03:57] it'll probably start with an M [19:04:03] like MA xxxx [19:04:05] or MC xxxx [19:04:39] like this: [19:05:01] "Stabilization and Control Subsystem, Procurement Specification MC 901-0594E" [19:05:11] I'm not sure how useful a procurement specification would be... [19:06:10] hm [19:08:16] seems like not really [19:09:33] and googling that number gets nowhere [19:09:46] these were called "level iii" schematics at grumman [19:15:18] it would help to find a drawing like this for any subsystem, not just SCS [19:15:27] I found the LM ECS one by knowing the PGNCS one... [19:15:42] yeah [19:16:17] as I said, the drawing of that specific subsystem would only really confirm what I already know [19:16:53] which subsystem? [19:17:08] Electronic Display Assembly (EDA) [19:17:10] part of the SCS [19:17:13] right [19:17:28] I know which of the two A9K1 relays is definitely in the EDA [19:17:46] weird enough the naming scheme is different for the other SCS subsystems [19:17:53] weirdly* [19:18:10] so it can't really be in those [19:22:01] aha! [19:22:14] numbers -- not for the SCS as a whole, but at the subsystem level (like EDA) [19:22:16] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19760019157.pdf [19:22:25] page 42 [19:22:31] pdf page [19:23:08] it looks like NARA probably has all of these [19:23:29] so ME901-0710-0202 [19:23:59] my best guess the relay is either [19:24:10] the relay is in the EDA but they both have "fuller" names [19:24:19] or it is in the attitude set control panel [19:24:56] lol, why has a ECS testing experience port this complete list [19:25:57] this is environmental acceptance testing, not ECS testing [19:26:11] think thermal vacuum testing of the whole spacecraft [19:26:21] ah, I see [19:27:17] good to have that list [19:30:44] hmm [19:30:53] the last part of the number must be the actual part number or so [19:31:09] the picture I posted earlier also has this number: http://media.liveauctiongroup.net/i/26155/23434037_5.jpg [19:31:18] just with 0502 in the end [19:31:21] not 202 [19:31:26] could also be a revision [19:32:18] yeah, that must be revision [19:32:27] the NARA drawing index doesn't include that last number [19:32:50] so just ME901-0710 is the EDA [19:32:58] yep! [19:35:23] I still haven't gotten over this drawing index [19:35:43] all of these things they said they didn't have over the years that they actually have [19:37:38] you are on level 2 now [19:37:45] higher prices, more documents [19:39:03] haha [19:39:32] but also a Ron who has been finally lured into going back to NARA himself [19:39:42] oh really [19:39:59] starts working on his list again [19:40:02] yeah, Ron is going there on Monday to begin digitizing as much of the MIT drawing boxes as he can [19:40:18] wait, Monday? [19:40:22] ... [19:40:24] as in two days [19:40:30] there's a really solid chance that on Monday we're going to get our first dimensioned drawings of the AGC and DSKY on Monday [19:40:36] er [19:40:36] yea [19:40:57] then I better assemble a Top 10 list and ask Ron if he would consider scanning some of it [19:41:11] some of the stuff where he scanned the first pages many years ago [19:41:30] I've already confirmed with them that they have 2003011, the drawing for our bad erasable memory module [19:41:38] oh, that's really good [19:41:55] but Mike [19:41:58] RTCC Requirements [19:42:00] :D [19:42:12] lol [19:42:28] I'm sure he can spare the time to get us 1 or 2 of the most important stuff [19:43:13] I dunno, he already has... maybe getting close to 10,000 aperture cards worth of stuff to scan on his list [19:43:28] haha [19:43:38] what's 100 pages then [19:43:41] nothing [19:43:50] https://docs.google.com/spreadsheets/d/10PD7-78qzQAwlWoVeKaLOTOpzTK-m29iUJhcjOyAzL0/edit?usp=sharing [19:44:26] and I'm about to send him more, for the Computer Test Set [19:44:32] I like the lower part of that list [19:44:36] "Skylark?" [19:44:54] Skylark and Digfly might be transposed, I don't know which came first [19:45:01] but it won't be code [19:45:11] the only code on the list is the JDCs [19:45:18] what would it be? [19:45:22] assembly? [19:45:30] a 2 page ad? [19:45:36] https://archive.org/stream/agc_handbook_jp2#page/n507/mode/1up [19:46:02] module part numbers and serial number assignments [19:46:27] boring [19:46:28] :D [19:47:00] but it will help us complete our mapping of module part numbers to programs [19:47:04] yep [19:52:57] let's see, what were my 10/10 priority documents [19:58:53] hmm, do I choose Revision 1 of a document and risk it only has changes [19:59:45] finishing the interior of the LM today, all that is left is modelling the antennas, RCS quads, engine bell and a few other things and I can start texturing [20:00:35] LM ascent stage [20:02:36] and the antennas are going to be nice separate mesh groups for animations? [20:03:54] yep [20:04:37] awesome [20:04:51] that's really most I want from your project, haha [20:06:10] would be awesome to see those antennas slew around [20:07:40] for sure yeah [20:23:47] send Ron my two most desired documents at NARA [20:23:56] I call it the contingency sample [20:35:12] https://www.dropbox.com/s/yecnrytp797b7je/Screenshot%202018-12-01%2015.34.52.png?dl=0 [20:36:12] https://www.dropbox.com/s/0i63zjsamila3qk/Screenshot%202018-12-01%2015.36.02.png?dl=0 [20:48:39] looks better every time [20:51:33] nice! [20:52:09] its nice to actually see something nice inside the LM, unlike the old mesh lol [21:22:44] thewonderidiot, Ron answered, documents are low priority and won't be free because he won't use his own equipment. But I could ask him for the SCS drawings, right? He is accessing that stuff anyway!? [21:23:21] I don't know what the plan is -- I know he requested all of the MIT boxes in advance [21:23:27] or at least some of them [21:24:17] ah, right [21:47:00] launch of our satellite is confirmed for tomorrow [21:47:05] next two days are going to be crazy [21:47:10] launch tomorrow, drawings monday :D [21:49:42] yeah, lots of good stuff, haha [21:53:11] good night! [14:01:04] hey [14:04:55] hey alex [14:04:57] Alex [14:05:59] sent Ron my list of documents to scan [14:06:22] starting tomorrow he will mostly scan aperture cards [14:06:38] but if he has the time he will do a few documents as well [14:07:04] I requested LOI targeting and moon-centered RTE abort RTCC requirements, both from Apollo 14 [14:07:29] I think there is a chance that he will get to scanning at least those two [14:08:08] oh nice [14:08:12] if it's 100 pages, then him scanning it himself will only be $25 instead of $80, so there is that :D [14:09:40] priority is AGC and DSKY stuff though [14:09:46] lots of new schematics etc. [14:10:05] should be quite exciting, especially for him and Mike [14:40:32] so with trying to implement SCS instrumentation I somehow got myself into implementing some SCS subsystems relay by relay... [14:40:41] it just might become a bit excessive [14:50:14] haha, of course you would, you usually go all in ;) [14:53:54] yeah [14:54:28] in the case of the LM that approach has certainly helped [14:54:40] in the long run [14:57:26] working on the RR in blender [15:05:02] btw I had a question for you: Have the NASSP LM RCS thruster positions been verified to be accurate since the recent major LM work? [15:41:46] sorry, was afk [15:42:09] the thruster positions of the mesh or also of the thrusters as used by Orbiter? [15:42:21] in any case, I haven't verified them [15:42:46] we should have good sources for it, so I can easily do that [15:45:31] hmm [15:45:42] first check isn't so good [15:47:12] haha [15:47:37] yeah I meant just the actual positions used by Orbiter [15:48:04] it's two different functions, for descent and ascent stage [15:48:58] which is already weird [15:51:24] I used the MIT hybrid sim data, let me find a second source [15:52:26] for the CSM there are mission specific numbers in the Data Book actually [15:54:07] brb [16:29:00] back [16:29:18] I'll have to test what happens with the coordinates at staging [16:29:32] RCS locations are not just different in one axis [16:29:43] and even then they seem to be wrong somewhat [16:36:40] oh, haha [16:37:01] the input to the RCS creation function isn't in the longitudinal axis [16:37:08] it's "forward" and "backwards" [16:37:23] 1cm difference used between descent stage and ascent stage [16:37:29] weird [16:37:40] the CoG isn't shifted that way [16:38:09] I'll implement a new function with corrected RCS positions [16:38:21] it might be wrong by as much as 12cm [16:39:41] connection issues? [16:47:52] yeah [16:50:13] so the thruster positions are definitely off, more or less [16:50:35] I'll fix that [17:09:09] morning! [17:19:17] hey Mike [17:19:39] what's up? [17:20:19] wrote Ron a list of documents I'd like to be scanned (eventually) [17:20:40] and now I am fixing the LM RCS thruster locations, because apparently they are a bit wrong [17:23:21] looks like another scrub today [17:24:25] yeah :( [17:24:45] so it's all happening on Monday [17:25:32] yuuup [17:25:35] hopefully [17:26:07] Tuesday and Wednesday look bad for weather and if we go back any further than that we're going to run up against the Delta IV, which has priority [17:26:23] ...which means we'll probably be pushed back to Christmas and have to cancel all of our holiday plans [17:27:23] damn, hoping for tomorrow then [17:27:33] that's a rather long list of payloads... [17:27:59] 90 payloads, wow [17:28:02] all on one rocket [17:28:04] everybody is on this launch, haha [17:29:15] Delta IV would be another NROL launch, obvious priority [17:29:23] yup [17:56:18] if I am working on this anyway, then I'll probably implement two new things [17:56:43] the thruster effect not being at the same place as the thrust position [17:57:14] and plume impingement [17:59:26] https://www.dropbox.com/s/astvo0moqj61kzi/Screenshot%202018-12-02%2012.59.04.png?dl=0 [17:59:42] woah, awesome [18:01:26] very nice!! [18:03:00] thanks [18:09:22] S-band antenna next [18:11:04] it's 45° angles all the way iirc :D [18:12:35] well, one 45° angle mostly [18:51:36] I guess the AAPO meshes had it at 30 [18:51:43] Ill set it to 45 [18:57:54] definitely 45° [19:00:23] V64 in the LGC has to take that into account as well and I used those equations for the antennas code, so I remember that well [19:01:25] antenna* [19:05:52] just to be sure, you are talking of the angle which the antenna assembly is attached to the support spar...dipping downwards 45 degrees [19:06:43] correct? [19:06:47] let's see... [19:07:16] yeah, I think that's the one [19:07:34] the support spar is horizontal and then dips down [19:07:44] so that last part directly at the antenna [19:08:05] making the antenna itself angled 45° [19:08:21] yeah [19:08:24] LM-8 Systems Handbook PDF page 31 [19:08:44] the right of the two schematics, looking at the antenna from behind, that's where you can easily see it [19:13:28] yeah those plans are helpful [19:18:04] I'm working on the RCS still, have figured out the coordinates now. Next I'll look if the moment arms are correct with that [19:19:24] probably would look weird if I use those, so the thrust effect will need some offset [19:35:50] let's see how these new thrusters look in Orbiter [19:41:20] tomorrow is a manned Soyuz launch. 3 weeks ahead of schedule due to the failure of the last mission. [19:41:38] And I thought they would postpone that one, lol. Forgot this was the Russians [19:44:28] haha [19:44:54] oh... our current mesh might be quite wrong [19:45:11] thrust bursts don't line up [19:45:19] not even close [19:46:11] when you tried the AAPO mesh, did you get as that well? [19:50:04] yeah, up to 20cm difference [19:50:09] from before [19:50:33] I will of course check all the thruster positions again, but I'm pretty sure they are correct [19:50:47] confirmed by MIT and Grumman [19:51:14] generally our mesh seems to be a bit too big [20:00:58] yes the AAPO meshes did not line up well with the RCS plume positions [20:01:16] I wonder if they would with the new positions you came up with [20:02:31] do you mind committing your changes so I can compare them the AAPO mesh? [20:25:12] I'll add the new function, but unused in code, you will just have to uncomment it [20:25:47] ok perfect [20:25:55] yeah becasue were still using the old mesh [20:26:05] I'm not 100% yet on the coordinates in the x-axis (Orbiter y-axis), but that can be tweaked [20:26:24] depends on the relative positioning of the CoG to the general LM coordinate system [20:26:41] almost done making the S-band antenna [20:27:51] great [20:28:42] I can't even properly line it up to the old mesh [20:29:07] with the old thrust definitions, the forward/left/right/aft thrusters are not in a plane [20:30:12] but it's using an average value for now. So if it doesn't perfectly line up in the Orbiter y-axis ("up"/"down") then that can still be adjusted [20:30:26] what do you use as the origin of your mesh right now? [20:32:30] probably doesn't matter yet [20:34:01] I have it: [20:34:01] VECTOR3 mesh_asc = _V(0.00, 1.00, 0.00); [20:34:01] VECTOR3 mesh_dsc = _V(0.00, -1.24, 0.00); [20:34:25] ah, in code [20:34:56] the ascent and descent stages will be 2 separate meshes [20:35:01] and then stacked in code [20:35:01] right [20:36:08] just adjusting the height of the RCS for the ascent stage right now [20:37:54] ah, in our mesh the forward and aft quads are not at the same height [20:38:07] that's why that is done with the thruster positions in code as well [20:38:55] so it lines up with the aft quads right now, in height [20:39:01] you will see [20:39:54] update pushed [20:40:02] in lemmesh [20:40:18] you will just have to comment the AddRCS_LMH or AddRCS_LMH2 function and uncomment the AddRCS_LMH3 function directly below it [20:44:07] thanks [20:47:38] https://www.dropbox.com/s/msktkvuefdbkkum/Screenshot%202018-12-02%2015.47.19.png?dl=0 [20:52:14] looks good [21:05:55] the LM coordinate system origin is 200 inches below the ascent stage base [21:06:03] that should help figuring things out [21:06:37] we might even want to adjust the CoG location (Orbiter vessel origin) with a new mesh [21:06:42] might help with early PDI [21:07:31] thewonderidiot, https://3.bp.blogspot.com/-P4v_vUkEyGM/XAGqcfc-sZI/AAAAAAAAGTQ/MMczxDXzg3g-gG5QRXK4L8ANHvvjVrkpACLcBGAs/s1600/IMG_4247.jpg [21:07:46] Is that an actual DSKY case that Carl is using? [21:08:02] did Jimmie buy one with the AGC? :D [21:15:49] Jimmie's friend made it at some point [21:15:57] it's not original and not dimensionally accurate [21:16:02] but it looks good enough :) [21:16:09] indy91, do I comment the old AddRCS_LMH(-1.85); afterwards? [21:16:30] yeah, or else you get 32 RCS thrusters [21:16:42] haha [21:16:43] comment AddRCS_LMH, uncomment AddRCS_LMH3 [21:16:48] ok I will [21:17:13] thewonderidiot, I was about to say that he wouldn't have to worry about dimensions if it was a real one, haha [21:19:25] like our LM mesh doesn't seem to have the right dimensions... [21:19:33] anyway, good night! [01:15:50] indy91, the new thrusters positions line up perfectly with my new mesh [17:14:20] morning! [17:24:44] hey Mike [17:32:16] what's up? [17:33:36] just finishing up the new LM ascent stage mesh [17:33:48] going to start texturing soon [18:11:19] hey [18:12:01] hey Niklas [18:12:11] finished making the ascent stage [18:12:19] next up is tecturing [18:12:23] texturing* [18:12:37] good that the thruster positions are lining up [18:12:43] to be expected really [18:12:54] the effects can still get a small offset [18:13:02] that wouldn't be difficult to implement [18:13:13] what did you use as reference? [18:13:29] AAPO LM [18:14:11] so not any actual LM schematics or so [18:15:56] well I referenced that as well [18:16:32] but the AAPO model was already the correct dimensions [18:18:08] https://www.dropbox.com/s/avlktc1bchuitkv/Screenshot%202018-12-03%2013.17.45.png?dl=0 [18:18:13] https://www.dropbox.com/s/zjnqa9jab5xt7cu/Screenshot%202018-12-03%2013.17.23.png?dl=0 [18:18:20] https://www.dropbox.com/s/pzlir51nnkxcidv/Screenshot%202018-12-03%2013.17.09.png?dl=0 [18:18:26] https://www.dropbox.com/s/yiwff8wnm32owcu/Screenshot%202018-12-03%2013.16.59.png?dl=0 [18:18:32] https://www.dropbox.com/s/j93efycey1vli5z/Screenshot%202018-12-03%2013.16.50.png?dl=0 [18:24:05] very nice [18:25:34] that Falcon 9 looks a little bit used [18:26:57] just a little bit [18:27:19] 3 flights within a year. Most impressive thing since STS-3 :D [18:27:35] probably slightly cheaper [18:27:41] just a bit [18:37:25] that first stage really wasted no time turning around [18:51:25] now where can I watch the live feed of Ron scanning aperture cards [18:55:07] hahaha [18:55:13] I haven't heard from him yet today [20:31:03] thewonderidiot, I have 4 photos of an "AGC Data Load" from December 2017. I don't remember what the source of that was. [20:32:02] link? [20:32:11] saved in my Apollo 8 folder [20:32:50] https://i.imgur.com/BpHUVsH.jpg [20:34:02] uhhhh [20:34:10] what did we get last year, hmm [20:34:16] I don't think it's any of the Margeret Hamilton stuff from NASM [20:34:24] so the two possibilities are the C237 sim from NASM [20:34:54] I remember renaming the photos at some point [20:35:02] and the stuff that Chuck Dietrich gave me at spacefest [20:35:04] but it's definitely phots, nothing we got as PDF [20:35:11] but I think that was just a maneuver pad [20:35:15] when was Spacefest? [20:35:23] July 5-8ish [20:36:03] The change date is from December 2017 [20:36:06] of the photos [20:36:30] 6000x4000 pixels, interesting format [20:37:45] but the photos might actually solve the Colossus 237/249 DAP uncertainties, and now I am really confused why I didn't find that earlier [20:37:50] and also where I got this :D [20:39:36] potentially from Ron when he was in Huntsville [20:41:12] https://www.ibiblio.org/apollo/ScansForConversion/Colossus237DigitalSimulation-Anomaly45.pdf [20:41:15] it is this [20:41:21] that was from NASM [20:41:53] I also remember slightly dismissing that document because it wasn't for Apollo 9 [20:42:07] so no need to have working CSM/LM TVC DAP [20:42:48] but it's the best we have and it agrees with what we currently use in all but one gain [20:45:02] we have the two parameters that are unique to C237/249 [20:45:13] we have them correct I mean [20:45:45] what seems wrong is exactly the same gain that caused confusion in later versions as well [20:46:04] which was finally solved, at least for Apollo 10 and later, when you got us the Apollo 11 CM padload [20:48:22] what? why is it different in our launch scenarios. Now I am really confused... [20:58:59] guess I have some docked Apollo 9 burns to do [21:01:39] and I'll practice my AGC code reading along with it [21:01:47] yes you heard that right :P [21:10:07] yep, we have it wrong [21:12:23] it will not switch to the high bandwidth mode [21:12:32] or 100x later rather [21:12:40] normally after 6 seconds [21:12:50] don't think there is a 600 seconds burn on Apollo 9 :D [21:13:18] the padload has to be 6 and not 600 (octal 01130) [21:13:33] just watched that counter in a debug string [21:16:06] it is 6 in the AGC data load from the Colossus sim [21:28:14] now a test [21:31:21] nice and stable, behaves as advertised [21:33:27] 0.1 ft/s residuals, despite using a weaker gain and the more sluggish control mode after 6 seconds [21:37:09] and it's commited and pushed [21:38:02] the only question now is about the engineering value of one of the gains. I consider the octals for the DAP gains as 100% known now, for all CMC versions [22:15:42] night! [12:55:48] hey [12:58:19] hey Alex [13:10:16] while I am doing padload fixes I am taking a look again at the Apollo 10 LR issues [13:18:17] hmm, what issues again? [13:20:04] when you try P63 with Luminary069 and enable LR updates bad things happen :D [13:20:29] in V16 N68 R1 showed +800 feet though [13:20:36] so I think it's only a velocities issue [13:21:02] I remember that I tried a descent with velocity data disabled, but I don't remember what the result was [13:21:47] it doesn't help that the Luminary memo for revision 70 and later are full of "anomaly XX fixed" without any description [13:22:01] so it could be any of them. Or still a padload issue [13:22:57] or a flag issue, even 99 still has those [13:43:23] interesting [13:43:30] I have yet to fly Apollo 10 [14:03:46] btw I still havent gotten a reply from the author of AAPO for usage of the LM meshes so I guess its a good thing I made some from scratch lol [14:10:05] also easier to make any improvements that way [14:10:34] yeah [14:10:53] and I have learned a lot by making this model [14:15:16] when we start using the new RCS locations it will be interesting to see if the behavior is any different [14:15:23] like RCS usage etc. [14:15:33] it's different by up to 20cm, not a small difference [14:24:48] and about yesterday, I'm glad the CMC TVC DAP stuff is now mostly solved [14:25:10] Colossu249 is now using a mode what we have never even used in NASSP before [14:25:25] more stable, but sluggish says the GSOP [14:25:52] and the gain is smaller as well, attitude rates are simply lower [14:38:22] nice [16:18:30] gotta go cya [18:29:20] hey [18:31:42] just started the SpaceX webcast to see a first stage doing pirouettes [16:14:31] hey [16:17:42] hey Alex [16:20:35] let's see, what do I have in terms of updates... [16:20:58] I had requested a document from UHCL called "flight program verification for Apollo 8" [16:21:08] thought this was going to be LVDC related, but it's CMC [16:21:27] compares reentry simulations done at MIT and MSC [16:22:04] there was a Colossus bug with reentry that would be easy to trigger [16:22:24] lunar entry, -7.35° angle, 1750NM range [16:22:41] something overflows in the AGC and it will land short of the target by 125NM [16:22:52] P65 bug really [16:28:30] I had some weird stuff happen with Artemis072 using ~1500NM entry range a while back [16:28:36] but I guess thats not the smae issue [16:28:42] same* [16:29:21] yeah, I was just looking that up, it seems similar, but it's a separate Colossus anomaly [16:29:25] this is 37 [16:30:01] Artemis program notes say the bug there is Comanche anomaly 43 [16:30:32] the Artemis bug is that P65 should be started, but it's not [16:30:41] so a bug in the decision logic for switching to P65 [16:31:21] it says avoid 1215 to 145NM ranges [16:31:47] the Apollo 8 bug must happen because it's long range, but also steep [16:31:53] so a border case for P65 [16:33:30] and the other news, I have been working more on the EDA logic. There won't be many new features, but there are a few [16:33:37] CMC ATT switch will have functions [16:33:53] rate display disabled on a switched off FDAI (right now it still shows the rate) [16:34:05] and also, I don't think the CSM FDAIs actually had a power off flag [16:34:21] can't find anything in the schematics or any pictures [16:52:18] interesting stuff [16:56:21] I was on a short trip the last few days but I will start texturing the ascent stage now [16:56:47] great [16:57:56] oh and there was a bit of back and forth with Ron. I think there is a decent chance we will get a few new MSC memos (like RTCC requirements), but only in a few weeks. [16:58:18] for now he is doing a lot of AGC schematics scanning at NARA Fort Worth [16:58:25] oh nice [16:58:36] so just aperture cards, more cost and time effective, haha [16:59:39] so at least LOI and RTE requirements [16:59:52] but the box has a lot from Apollo 14, TLMCC and more [17:00:06] the box with those two documents I mean [17:00:47] he has to order each box separately, so realistically, we will get zero to all of the documents from that one box only [17:03:23] we'll see [17:52:50] I had trouble relating two relays to the right SCS subsystem, but I found a list with the modules of the subsystems that would help. It's missing one page, exactly the one I could have used... [17:59:56] bummer [18:00:30] although the list of modules for the GDC is complete, so I might be able to figure it out that way. [18:00:44] Anything that doesn't fit with the modules there is going to be in the EDA [13:36:12] morning [13:55:00] hey [13:55:42] figured out another error in the FDAI logic we currently have [13:56:10] attitude error display with the 50/15 scale setting [13:57:21] there is a setting that gets only used with the CMC [14:01:30] ah nice find [14:01:52] roll only, it's a weird combination of what the CMC does and what the EDA does [14:02:25] so it might also be CMC version dependant [14:02:42] but I know what the display electronics do [14:03:12] AOH Volume II PDF page 217 has the resulting attitude errors being displayed [14:03:55] Boost and entry can be different, because the CMC outputs an attitude error scaled by 4x during P11 and P6X I guess [17:07:33] good morning [17:11:14] hey [17:12:07] going to start getting back into nassp again [17:12:23] have there been any significant changes in the past 2 or 3 months? [17:15:05] hmm, let's see [17:15:47] some Virtual AGC fixes which I consider important [17:15:58] so I would use the latest version, yes [17:16:31] okay [18:08:33] https://www.dropbox.com/s/y52r269pxptiud2/Screenshot%202018-12-07%2013.08.19.png?dl=0 [18:08:43] hey astronauthen96__ [18:08:50] hey Alex [18:09:26] I am working on a new LM model so that will be a nice visual improvement which should be ready in the coming weeks [18:09:34] it has colors [18:09:40] very cool [15:10:35] good morning @AlexB_88 [15:10:41] hey [17:06:10] good evening [17:29:19] hey [17:30:47] almost finished the ascent stage, just the hatch to texture and a few other minor details [17:30:59] https://www.dropbox.com/s/v02opbj1su2svax/Screenshot%202018-12-08%2012.30.21.png?dl=0 [17:31:13] then Ill start on the descent stage [17:31:27] looks good [18:06:11] trying to figure out how the displays behave with the logic bus breakers pulled [18:06:47] FDAI scale should be as if the switch was in the 5/1 position [18:07:28] CMC Att fails to the GDC position, so goodbye FDAI attitude display [19:59:22] brb [20:03:50] lol, I think I finally figured out how the FDAI scale factor switching actually works in the schematic [20:04:35] there is an amplifier, a bunch of resistors and 1-2 transistors. Couldn't quite figure out what exactly switching the transistor on does [20:05:07] probably would have taken Mike only a few looks at the schematic to figure it out [20:06:20] haha [20:07:02] sounds like a lot of our FDAI implementation must of been simplified [20:07:49] it's fairly accurate I would say, but when including the SCS logic buses and the CMC Att switch it becomes about 2 magnitudes more complicated [20:08:20] so not the switch setting itself is deciding, but the wire going through a switch setting as powered by logic bus [20:08:45] for example, FDAI scale 5/1 setting is completely unwired [20:08:58] that's why if the logic buses would fail, it fails into that setting [20:09:59] and in the end relays and transitors are the logic behind the current configuration, not switch settings [20:10:14] active configuration rather [20:10:44] where I have made it more complicated than probably necessary is with the pitch and yaw axis [20:11:09] most of the circuits are completely identical for those two, but it's separate circuits with separate relays and transistors anyway [20:11:39] so from a coding standpoint it's not that necessary to treat those separately, but if I am going for a relay by relay approach anyway... [20:12:27] what I have working right now is attitude, attitude rate and CMC attitude error. And the logic for the other attitude error settings, but there I need to work a bit on the signals it's getting I think [20:12:47] like, one calculation should be rather in the GDC than in the EDA as it's currently, that kind of thing [20:23:41] yeah [20:24:19] I guess the advantage of a relay to relay implementation is when it come time to implement failures and what not [20:25:06] yep [20:25:33] give those malfunction procedures some use as well [20:27:05] right now I am mainly doing this for realistic instrumentation and giving the SCS logic buses something to do [20:27:38] like, the EDA didn't even have a timestep. It only calculated something when the FDAIs were specifically requesting it. That's of course no good for telemetry [20:38:33] right [21:14:04] cya tomorrow evening [17:45:08] hey Niklas [17:45:20] working on the descent stage now [17:45:30] hey [17:45:33] great [17:45:37] https://www.dropbox.com/s/dm52js40w383ul3/Screenshot%202018-12-09%2012.17.02.png?dl=0 [17:46:18] the spacecraft handbook cross-sections are pretty handy [17:47:08] yeah, I bet [19:43:13] IMU-ASCP error display is also wrong right now [20:34:46] Descent stage is coming along faster then the Ascent Stage [20:35:03] https://www.dropbox.com/s/78o9ttiqxlgbr4o/Screenshot%202018-12-09%2015.34.23.png?dl=0 [20:35:35] mainly because I am getting more and more comfortable with blender/3D modelling [20:38:01] I even made it modular [20:38:31] like the corner panels can be removed and there is compartments inside [20:38:44] side panels* [20:39:26] of course probably wont be much use for NASSP 8, but at least the mesh will be ready for J mission additions [21:00:10] yes, that's good thinking ahead [21:02:28] looking forward to seeing the progress on the new mesh. Good night! [13:37:36] hey [13:38:44] hey Niklas [14:00:59] 3/4 attitude error sources done [14:01:46] we had a lot of complicated looking calculations for this, to get the specific behavior right, so in some cases it will actually be a simplification [14:02:52] and some of it was even wrong. IMU-ASCP attitude error should be showing euler angle differences, not body error [14:03:13] so it shouldn't be accounting for the actual attitude [14:03:34] so when roll is >90° the needles become fly-from, instead of fly-to [14:26:49] very interesting [14:27:05] almost done texturing the descent stage [14:27:24] after that only the ladder and porch to add, then this thing is ready for test flying! [15:06:37] https://www.dropbox.com/s/ouggo3q4n14bunx/Screenshot%202018-12-10%2010.05.51.png?dl=0 [15:06:43] https://www.dropbox.com/s/u6qtykf1xq5c5z1/Screenshot%202018-12-10%2010.05.23.png?dl=0 [15:10:30] looks like a Lunar Module [15:14:03] thanks [15:14:22] maybe not AMSO-good but I think you guys will like the new meshes ;) [15:14:48] I even managed to give the descent stage panels a slight wrinkle effect [15:18:20] brb [15:42:36] https://www.dropbox.com/s/gmdsk1mhygk3xqg/Screenshot%202018-12-10%2010.42.23.png?dl=0 [15:42:53] showing the mesh without side panels for future expansion [15:45:12] like 4 LRVs [15:46:19] haha [15:50:09] unfortunately it's full of stuff [15:50:25] so only 1 LRV possible [18:51:28] almost finished the mesh [18:53:16] I might be able to commit them tonight or tomorrow. They need new code for them to load correctly in NASSP, so I wont tie the meshes to anything yet, they have different file names for now so they wont replace the old ones yet [18:55:10] and in the next few days after I will work on new code to stack the new meshes and create animations. Once thats all tested and working then Ill commit the change from the old mesh to the new mesh [18:57:05] sounds good. So basically as already has happened to the RCS thruster location. Code is there, but will only be used in the final step before it gets commited [18:59:45] right [19:18:31] and new EDA is also approaching its final stages [19:31:15] great [19:58:00] and done! [19:58:20] https://www.dropbox.com/s/9agqbc7a7yiik33/Screenshot%202018-12-10%2014.57.50.png?dl=0 [20:04:20] very good [20:05:12] now the hard part: animations [20:10:09] haha, yeah [20:12:36] not sure we have many examples of that in our code [20:12:42] the DeltaGlider has [20:24:02] oh, the S-IVB panels of course [20:24:09] in the S-IVB class [20:25:09] and the API guide also has some helpful tuff [20:25:14] stuff* [20:36:40] Ill PR the meshes shortly, just the .msh/.dds files themselves not replacing any others [20:36:50] for now [20:37:04] brb [20:53:14] night! [12:44:40] hey [12:46:58] morning [12:47:11] I just had the most annoying bug [12:47:27] if (SCS_INERTIAL_BMAGS) [12:47:28] errors = sat->eda.AdjustErrorsForRoll(sat->bmag1.GetAttitude(), errors); [12:47:31] these two lines [12:47:42] the second line didn't apply anymore, so I commented it out [12:47:50] I did not comment out the if though [12:48:05] so whatever next line comes after the if was now conditional [12:48:26] and somehow that managed to break SCS attitude hold, which is rather annoying to track down [12:49:47] sounds fun [12:50:40] I made a PR with the new meshes, but before you commit them I have a few fixes + some initial code to integrate them in lemmesh.cpp [12:50:47] too late [12:50:51] haha [12:51:02] its ok, Ill make another PR [12:51:12] but I guess it's unused right now anyway, so it wouldn't break anything [12:51:23] yeah [12:51:47] I will make a legs closed version of the descent stage for now, while I work on animations which is of course the goal [12:52:35] will the legless LM-1 work? [12:53:12] ah [12:53:19] that uses an entirely different mesh in code [12:53:25] yeah [12:54:15] I wont change that for now, but at some point I will make an LM-1 mesh from the new mesh [12:55:36] only differences are the legs and the windows I think [12:56:50] it looks now very likely that we will get some RTCC Requirements as Chrismas presents [12:57:16] or maybe a bit after Christmas [13:58:52] that would be a nice present ;) [14:30:42] indy91, with the new RCS positions for the lunar module, the ascent stage RCS seems to be a tad low [14:32:50] hmm, ok [14:33:09] I think it was based on the distance that the ascent stage gets moved on staging [14:33:17] maybe you changed that? [14:34:00] I thought it was that too, but its not [14:34:17] in fact changing the CoG at staging seems to have no effect on the RCS psoitions [14:34:24] positions [14:34:30] ooh [14:38:17] it should be just like before [14:38:24] how much off is it? [14:39:29] I'm having trouble getting the dx9 client running on my new pc. As soon as I want to load the module orbiter just shuts down. Would you guys have any clue what might be the issue? [14:40:24] indy91, its off by say half a foot too low [14:41:03] its alligned very well in all other axis, its just along the Z axis that its off [14:42:48] and you didn't change the offset inputs? [14:43:05] Thymo, what does the Orbiter log say? [14:43:33] -7.2966 and -5.4516 [14:44:18] like, those two numbers have to be exactly -1.845 apart, because that's how much the CoG is shifted at staging [14:44:22] indy91: Nothing. The last line logged is it loading the scenario editor plugin. Orbiter doesn't get a chance to log anything else. [14:44:25] AddRCS_LMH3(-7.2966); [14:46:04] btw is 1.845 CoG shift value from actual documentation? [14:46:17] oh no [14:46:22] the CoG is shifting all the time [14:46:27] that's just what we use [14:46:36] hmm [14:46:42] of course with different meshes [14:47:18] did you test staging or a scenario with the ascent stage already loaded? [14:48:04] yeah [14:48:05] Thymo, how about DX9 Client log? [14:48:33] lol, that was a either/or question, yeah doesn't work :D [14:49:29] Is that log supposed to be in the root orbiter directory? I don't have that log. [14:49:52] Modules\D3D9Client [14:50:44] There's only fc and hlsl files there. [14:50:50] s/fc/fx [14:51:51] then you didn't use the DX9 Client yet [14:52:26] when exactly does it crash again? [14:52:44] As soon as I click on it in the modules tab [14:52:49] oh [14:52:50] hmm [14:52:56] which Orbiter and DX9 Client versions? [14:53:29] Latest Orbiter beta and r995 [14:53:39] Downloaded from tuttovola [14:54:45] 996M has the same issue [14:55:31] https://www.tuttovola.org/index.php?PHPSESSID=hl0clhtrm2tli3dscnh25b8ts3&action=downloads;cat=64 [14:55:33] here? [14:55:51] where does it say r995 there [14:56:20] Navigate to D3D9Client2016-R3.2 per Orbiter2016 and look at the filename [14:56:28] D3D9ClientR3.2-forOrbiter2016(r995).zip [14:57:13] well, you want the DX9 Client for the Orbiter Beta [14:57:14] not 2016 [14:57:33] so "D3D9ClientBeta28 per Orbiter Beta Rev. 84" [14:57:38] Yes, that's the one on the top. r996M [14:57:46] That doesn't work either [14:58:09] it certainly will be the only one that works, so don't even bother with r995 [15:00:08] I've never had your specific issue before [15:00:18] maybe search in the DX9 Client thread if anybody had that before [15:01:55] Yeah. I'll do that. I'm not sure how to debug this, as there's nothing logged. [15:02:31] yeah, it's not even getting to that point [15:02:46] I thought there would at least be some error in the Orbiter log [15:06:26] Here's one thing. It does work with r995 on Orbiter 2016. [15:07:37] maybe a problem with the Orbiter Beta install? [15:08:15] AlexB_88, how does it work with the meshes, is it completely separate ones for ascent and descent configuration? [15:08:54] What rev of the client are you on? [15:09:48] R28.0 [15:10:17] indy91, yes [15:10:25] Fresh beta install is a no joy [15:10:26] so probably the same one as that r996M, but I got it from the Orbiter Forum [15:10:37] oh sorry no [15:10:50] its just a ascent mesh, descent mesh [15:10:57] no combined meshes [15:11:06] Im staking them in code [15:11:33] so that's different from before [15:11:42] and I am adding a descent stage with legs retracted (not yet committed) for now while we wait for animation [15:11:50] yes [15:12:52] I wonder if it is a coordinate system thing with the meshes [15:17:15] again, did you try a scenario with the ascent stage or did you load a scenario with the descent stage and then did staging? [15:18:38] oh, hmm [15:18:46] in lemmesh [15:18:52] there are a few instances of mesh_dir [15:19:17] did you tweak that offset vector? [15:20:12] yeah Ive been working on it, getting not bad results now [15:21:03] of course that might not properly solve the issue [15:21:27] I just have to tweak the CoG shift a little [15:21:39] not a good idea [15:22:04] hmm [15:22:06] I mean 1.845 was for the old ascent mesh, which I had come up with before [15:22:10] it's all quite confusing for me still [15:22:34] with the order of things, it first shifts the CoG and then builds the RCS from scratch [15:22:58] so the RCS will always be the same relative to the CoG [15:24:01] right [15:24:45] I am playing with the CoG in the separate stage function btw [15:25:17] which is a number I had tweaked previously anyway I think [15:25:33] you did? [15:25:45] 1.155 [15:26:15] ShiftCentreOfMass(_V(0.0, -1.155, 0.0)); [15:27:29] ok [15:28:23] I guess it shouldn't change anything about the actual RCS position [15:28:47] so tweak as you like, as long as the mesh looks right in all situations [15:28:53] staging, docked etc. [15:29:35] yeah [16:54:46] indy91, things are looking good now. I adjusted the ascent stage LMH3 to -7.2016 which is -5.4516 (descent stage value) minus the new CoG shift of 1.75 (instead of 1.845) [16:58:35] I guess if the RCS was off, then other distances were wrong as well [17:00:26] yeah like docking port, etc, I am adjusting all those [17:01:58] ah right [17:02:20] uhhh [17:02:26] that has a lot of implications though [17:02:28] a loooot [17:02:39] I even need to change the RTCC for that [17:05:41] luckily only in one place [17:05:58] the distance between the CSM and LM CoGs is needed for the calculation of SPS trim gimbal angles [17:06:11] and if you change the docking port position then that will change as well [17:06:19] ok [17:06:29] actually only seems necessary for the ascent stage [17:07:48] yeah, I guess the height of the stages has changed a bit [17:08:05] if it's only the ascent stage then no RTCC change is needed [17:08:58] and most other problems go away as well [17:16:38] finally found the last big issue with the attitude error display [17:23:19] just needs more testing and code cleanup now [17:29:45] great [17:37:06] almost ready to PR my code changes [17:37:25] doing lots of testing now to be sure I didnt break anything [17:40:44] yeah, there are a lot of situations that could be broken with a mesh change [17:40:58] one thing that will still be to do is sit the new LM mesh in the SVIB project [17:42:22] yeah [17:58:08] so here I am trying to add if elses and checks to avoid using the new mesh and force it to use the old mesh when using LM-1...and I am like, you know whats easier? Just make a new damn LM-1 mesh :D [17:58:34] not like its hard, its just taking my new descent stage and deleting the legs [17:59:26] and the windows shouldn't be transparent [18:00:06] yeah [18:17:31] morning! [18:17:54] hey Mike [18:18:36] what's up? [18:23:01] hey [18:26:06] how is the fake erasable memory going? [18:26:51] thewonderidiot, new LEM! https://www.dropbox.com/s/aa5hkty4l1ieeee/Screenshot%202018-12-11%2013.26.38.png?dl=0 [18:50:56] indy91, do you have any scenarios before staging with Apollo 5? [18:58:12] actually I just added NOLEGS 1 to my scenario, good enough [19:03:02] indy91: no time [19:03:13] and nice! that looks great :D [19:34:01] indy91, PR sent [19:38:10] merged [19:39:06] thanks [19:39:13] enjoy the new meshes! [19:40:19] I will test them a bunch tomorrow [19:56:26] one thing about the RCS... [19:56:29] https://www.dropbox.com/s/j9gz84c1c6ymbzy/Screenshot%202018-12-11%2014.55.39.png?dl=0 [19:56:49] yep, that's exactly what I was talking about a few days ago [19:56:57] the plume seems to come from the center of the RCS assembly [19:57:01] the thrust effect might need a small offset [19:57:08] right [19:57:15] what I used was the actual center of thrust [19:57:21] so where the thrust develops [19:57:56] I'll implement that offset, it should simply be the same distance from the center of thrust for all of the thrusters [19:57:57] ok [19:58:05] sounds good [19:58:29] is it exactly the same for the top and bottom thrusters? [19:58:35] also maybe the DPS and APS thrust locations might need some adjustments for the new mesh [19:58:53] it already looks good so maybe not though [19:58:54] hmm [19:59:03] I'd be careful about that [19:59:17] Its just hard to tell how far inward in the bell the plume should start [19:59:36] it's been wrong for the SPS since forever as well [19:59:42] especially when it's gimballing a lot [19:59:51] you can see some thrust effect outside of the SPS nozzle [20:00:16] once I get good at animations Id like to animate the DPS and SPS [20:01:25] one thing that would help to get the offsets right is to define specific points for the CoG in the LM coordinate system [20:02:12] I've already done that with the RCS locations, the number you input in the lemmesh functions is the difference between the general LM coordinates and the CoG [20:04:25] so I'll calculate new numbers for the CoG location of ascent and descent configuration [20:04:37] and all the engines will have very specific locations relative to the CoG then [20:05:00] and then the mesh might have to be moved a little bit [20:05:27] but at least with that approach there is no guessing [20:06:30] meanwhile in space: https://pbs.twimg.com/media/DuKS4GtW4AA-UP6.jpg:large [20:08:20] yeah makes sense [20:08:54] hmm scissors is what I needed in blender! [20:09:14] yeah, I bet that would be a useful tool [20:23:17] btw before you ask, no I didnt forget to texture the APS :D [20:25:33] haven't looked at it yet [20:33:56] am I dreaming or is ascent ascent stage translation thruster usage now more stable with the new RCS positions? [20:34:44] doesnt torque as much as it used to it seems. I am however testing with a fully fueled ascent stage [20:36:17] hmm just tried with my Apollo 14 TPF scenario, yeah its similar to before...probably just because I was heavy on the last test [20:37:09] there definitely could be some behavior changes [20:37:17] some thrusters have moved quite a bit [20:48:42] I think I'll give the rest of the SCS the same treatment as the EDA [20:49:12] giving the SCS logic buses something to do, fixing small and big inaccuracies, implementing telemetry signals [20:52:45] nice stuff [20:53:26] next would be GDC, did some stuff there already for the EDA and ASCP interaction [20:53:29] then the ECA [20:55:49] I think the RSI alignment is still pretty wrong [20:58:03] and I might even make the GDC work as it really does, by integrating BMAG rates [21:03:40] thewonderidiot, one thing that might be interesting for you, I had requested another document from UHCL [21:03:52] Flight Program Verification for Apollo 8 [21:04:09] I thought it was gonig to be LVDC, but it's about Colossus 237 [21:04:25] compares simulation runs done at MIT and at MSC [21:04:39] entry simulations that is, nothing else [21:04:56] and it has some info on two Colossus anomalies, so Ron is going to put it on the website [21:05:18] always good to have more about those anomalies... [21:07:22] anyway, good night! [13:20:18] hey [13:21:35] hey Alex [13:29:45] just merged my SCS development branch. Now I can take a look at the new mesh [13:37:04] I like it a lot [13:37:24] I've never noticed those two extra antennas before in the old mesh [13:38:47] ah, that's the VHF ones [13:39:29] yeah [13:39:47] I think the 1st thing Ill try and animate is the RR [13:39:57] sounds great [13:40:05] I'll implement the thrust effect offset [13:40:48] should be easier then the gear deploy, ill save that for when im more experienced with animations [13:41:50] theres one minor bug I found after I PRd my changes yesterday, when you stage the probes appear too low under the staged descent stage [13:41:54] Ill fix that asap [13:41:59] ok [13:42:21] I thought you already had gear deplyoment, didn't you show me a gif or so? [13:42:55] ah, AddExhaust already supports a simple longitudinal offset, that makes it much easier [13:43:27] oh that was just a gif showing the AAPO model gear deployment [13:44:16] ah, ok [13:44:39] well, you can probably learn from that code [13:44:43] yeah [13:47:14] did you also have problems with the AAPO solution file? [13:48:07] solution file? [13:48:29] sln [13:48:37] when you wanted to look at the AAPO code [13:48:59] oh [13:49:12] I just went to the source code folder [13:49:22] all the VS projects are in there [13:49:51] I opened the individual .cpp's [13:49:56] ok [13:50:32] but to answer your question, yeah I did have problems when opening the .sln [13:51:21] looking at the code, it seems like a pretty good example to work with [13:51:52] using a function DefineAnimations() called in the post creation callback [13:53:31] the static variables can be annoying, but if it is handled properly it should be ok [13:54:07] had some trouble with that when I did the little bit of animation work necessary for Apollo 5 [13:56:04] 0.12 meters offset is a good compromise for the RCS. [13:56:29] it still shines through a little bit, but you could interpret that as nozzle glowing :P [13:56:45] if I make it any larger then it will look like it's burning through the plume deflectors [13:56:48] yeah [13:58:07] pushed the LM updates and more importantly the fully functional Electronic Display Assembly [13:59:28] great [13:59:44] anything in particular to test for the EDA? [13:59:58] any display mode you can imagine, haha [14:00:10] you can play around with the SCS logic bus breakers and the CMC ATT switch for example [14:00:34] that will disable all the FDAI switches [14:01:11] CMC ATT to GDC just disables the FDAI total attitude display [14:01:41] because the IMU is considered failed in that mode and the GDC just supplies data to the CMC, so it doesn't properly keep an own attitude reference [14:02:08] feeding GDC data to the CMC isn't done yet [14:02:33] but it was working for all flown missions I think. There just never was a CMC program that actually was using the BMAG registers [14:02:37] not any I am aware of [14:03:56] hmm, interesting, with all the logic bus breaker pulled you get: no attitude display and CMC attitude error on FDAI 2 [16:05:45] Ill have some adjustments for the docking/tracking lights ready soon [16:05:57] and ill try and put the new LM mesh in the SIVB project [16:07:31] https://www.facebook.com/pg/airandspace/videos [16:07:38] they are showing the flown Apollo 8 flight plan right now [16:08:51] very cool [16:13:06] very interesting [16:17:13] with the docking and tracking lights, I guess that's expected when the mesh gets changed [16:21:38] yeah [17:55:20] good morning [18:03:41] hey [18:17:27] Hey [18:19:13] just wondering have any of you flown on the 737 MAX? [18:24:11] nope [18:24:42] I don't think I have flown anywhere since that one started flying commercially [18:24:52] Thymo, got Orbiter working yet? [19:23:26] ok got the lights working, now adding the new LM to the SIVB [19:23:33] also forgot something with the APS [19:23:54] http://img.photobucket.com/albums/v316/Rhinehornet/AscentEnginetilt.jpg [19:26:11] so basically tilted 1.5 degree back [19:28:10] rightz [19:28:13] right* [19:32:06] wait [19:32:21] this one seems to say +Z is forward, im confused [19:32:22] https://www.google.com/search?rlz=1C1CHBD_enCA744CA744&biw=1920&bih=1007&tbm=isch&sa=1&ei=jGARXJKoEMGW8QX71I3gBg&q=apollo+spacecraft+axis&oq=apollo+spacecraft+axis&gs_l=img.3...3565.6178..6770...0.0..0.255.2754.2-11......1....1..gws-wiz-img.9iG3FcDOHdU#imgrc=zvD88WzIZ104lM: [19:34:03] yes, +Z is through the forward hatch basically [19:34:30] ok so it tilted 1.5 forward [19:34:39] yeah, I think so [19:35:40] hmm I actually have other side shots of the LM that shows it tilted back [19:36:20] you can see the 1.5°? [19:36:29] also, I think it's not directly centered [19:36:52] a its confirmed in the systems handbook [19:37:03] you can clearly see it in the side views [19:37:18] its tilted aft [19:37:42] I guess the centerline in the +Z direction means the line extending up from it is towards the front [19:37:45] MIT simulator has a -1.5° angle applied as a rotation around the +Y axis [19:38:10] which is the same as tilted backwards [19:38:12] yes [19:39:47] location of thrust in the Z axis is at +3.75 inches [19:40:02] so it's not only tilted, but also slightly moved forward [19:40:20] 0.09525 meters [19:43:44] I'm making good progress with the GDC [19:43:56] the most noticable difference will be GDC alignments [19:44:33] it gets driven by a signal from the ASCP which is the sine of the attitude error (ASCP setting minus GDC attitude) [19:44:46] so it will be slower towards the end of the alignment [19:44:51] looks really smooth and nice [19:45:22] and it will actually not keep a cheaty attitude reference anymore [19:45:39] but using the rotation equations as mechanized [19:46:12] so just driven by BMAG body rates [19:48:56] which over a long time will probably make it drift somewhat [19:49:09] but not more than in reality, lol [20:17:35] nice [20:17:50] Ive got the LM added to the SIVB project [20:18:15] I also made put the no leg version as well and made a separate LM_parkedNoLeg mesh [20:25:25] great [20:26:31] through researching the GDC I also finally figured out why the RSI is aligned with the yaw and not the roll axis of the ASCP [20:27:31] in entry mode the pitch axis is disable and yaw and roll axis both calculate roll stability rate [20:27:41] one driving the RSI the other a FDAI [20:27:55] so yaw is driving RSI [20:28:26] but it's still the same roll stability rate as in the roll circuits [20:28:29] just redundant [20:30:10] there also is some tricky to implement power switching in the GDC, so that the RSI and the GDC driven FDAI never get power from the same AC bus [20:30:32] because single bus failures shouldn't disable the SCS entry capacblity [20:41:27] I did manage to get Orbiter to work yet. The release version works great. It's just the beta that doesn't want to work. [20:42:18] very weird [20:59:38] night! [13:15:58] hey [13:16:05] hey Alex [13:16:22] have a PR [13:16:55] right [13:17:14] the view offset for docking is interesting [13:17:19] I remember adjusting those numbers [13:17:49] I think I couldn't use the proper numbers because the docking target was off a bit from where it should be [13:17:58] probably better now [13:18:01] yeah [13:18:16] anyway, merged [13:18:44] GDC is also coming along very nicely [13:18:53] we also had the CSM COAS not aligned vertically [13:19:00] oh [13:19:01] it was too low by 8 pixels [13:19:17] so I changed the offset [13:19:41] renderViewportIsWideScreen [13:19:49] is that 16:10 and 16:9? [13:19:55] when it's 1 or 2 [13:22:43] yeah, I think so [13:22:47] 0 is 4:3 [13:22:55] 1 is 16:10 [13:22:57] and 2 is 16:9 [13:23:55] yeah [13:24:01] and with the GDC, the other thing you will notice is during reentry on the FDAI only roll is driven [13:24:18] I suspected that for a while, but now that I have done the research it is confirmed [13:24:22] I tested both 16:10 and 16:9 with the new offset and its good [13:24:29] great [13:24:40] it will likely keep the current yaw and pitch angles and just roll as a second RSI [13:25:23] in general the GDC attitude is motor driven [13:25:41] SO if no rate is supplied it will not change the attitude [13:25:58] right now if you unpower the GDC it would set the attitude to 0,0,0 [13:26:24] the resolvers also get unpowered, so on the FDAI it would show 0,0,0 angles [13:27:25] a backup procedure confirms this. If your GDC alignment doesn't work you can: 1. Maneuver to the attitude you want the GDC aligned to (e.g. 0,0,0) then disable the GDC, maneuver to where you want the GDC attitude to be valid (e.g. thrust direction) and then enable the GDC again [13:27:38] If "GDC align" doesn't work I mean [13:40:37] oh, and another fun thing, with the CMC ATT switch to GDC the GDC does still keep an attitude. I said something different before. [13:41:01] However, it doesn't calculate the attitude properly with Euler calculations [13:41:15] so what you have to do is only do 1-axis maneuvers, or else it looses accuracy :D [13:41:26] in the order pitch, yaw, roll [13:44:19] one thing I still have to research is the GDC equivalent of a gimbal lock [14:18:25] thats quite interesting [14:18:43] so the accuracy loss with CMC ATT to GDC will be simulated? [14:26:23] yeah [14:26:33] the GDC is driven by BMAG body rates [14:26:44] and it does a conversion to translate that to Euler angles [14:27:15] so e.g. at high yaw angles a small body pitch rate becomes a large pitch Euler attitude rate [14:27:33] ah i see [14:27:37] in the non-Euler mode, the GDC just uses the body rates directly [14:27:51] because that's what the CMC would get as an input [14:28:11] but the GDC itself will also use that to determine its attitude. Non-Euler mode [14:28:24] or single axis mode [14:28:41] that's why you would have to do 1 axis maneuvers in a specific order of axis [14:29:01] only that way the body rates = Euler rates [14:30:29] so that's even simpler than the Euler mode [14:30:56] and about GDC gimbal lock, the main issue there is that it needs to calculate (in an analog way) the secant of the yaw angle [14:31:07] secant is the inverse of cosine, so nearing 90° it becomes infinite [14:31:27] there is an amplifier for this, which probably gets saturated at some high yaw angle [14:31:37] or even before that, it becomes less accurate [14:34:16] have found various angles where it might becomes less accurate, (60°/75°/80°), but nothing specific [14:56:53] doing various maneuvers now to test how accurate the GDC is keeping its attitude [15:18:25] good morning [15:22:10] hey [15:32:26] AlexB_88, have you ever aligned the RSI for a lift vector down reentry? [15:32:37] nope [15:34:03] I wonder how that is done. The RSI tracks around the same amount as you set with the ASCP yaw [15:34:10] but it also says to avoid the FDAI gimbal lock area [15:34:45] you could do it in intervals. Rotate the RSI, EMS roll off, align GDC back to 0° yaw, EMS roll up and so on [15:36:51] hmm, no [15:38:25] well, kind of like that [15:38:38] just GDC align pressed the whole time [15:39:32] yep, that works [15:39:38] probably has to be done like that [15:40:36] might not work with the current implementation actually, but it works with my development branch [15:53:16] Hey [15:54:57] what's up? [15:58:52] Getting slightly annoyed with dx9 [15:59:12] People keep telling me to double check if I have the runtime installed properly. [15:59:36] But they don't get that 2016 is working fine and just the beta is not working. [16:00:06] have you tried running the Beta with the MOGE? [16:00:15] default graphics that is [16:00:55] if that works fine, then the problem is probably not the Orbiter Beta [16:02:16] I thought it did. Albeit at a lower resolution. [16:02:22] Let me double check [16:03:11] Wait [16:03:25] That's similair behaviour. [16:03:45] As soon as I launch a scenario it loads for a second and shuts down. [16:03:54] Nothing shows in the logs [16:03:57] that's different though, right? [16:04:11] you couldn't even select the DX9 module in the other exe [16:04:39] Yeah. But considering dx7 is not a module. [16:04:55] right [16:05:05] do you have the textures installed? [16:05:14] I don't think the Orbiter Beta comes with any [16:06:29] you can just link to your Orbiter2016 folder for that, I think [16:07:36] or copy them over [16:07:53] I only put it in the orbiter_ng config [16:08:03] Let me test it after I finish dinner in a minute [16:08:04] ah [16:08:07] ok [16:08:15] then at least the default client should work [16:08:57] That makes me wonder where dx9 reads the texturedir config from [16:10:13] could even be a corrupted config [16:10:43] Doubt it. [16:10:50] I fresh installed trice. [16:11:14] haha [16:12:52] You do have the texturedir line in your orbiter_ng.cfg right? Or should it be in orbiter.cfg? [16:13:36] I don't need that line [16:13:43] I have a weird setup, haha [16:14:06] I have a separate Orbiter Beta folder and when that gets updated I just copy that whole folder on top of my NASSP install [16:14:26] I have one separate Orbiter 2016 release version install, but just with the low res textures [16:19:58] Well adding that line to orbiter.cfg didn't work. [16:20:32] huh [16:21:38] wow [16:21:43] Wait a second now [16:21:50] It works [16:22:04] I removed those lines and moved my textures folder over. [16:22:07] It loads now [16:22:49] Add the line [16:22:50] TextureDir = \Textures\", [16:22:50] where is the full path to your Orbiter2016 root installation directory. [16:22:58] that's what the website says [16:24:07] I did that [16:24:17] But that didn't work [16:27:08] weird [16:27:15] but I remember peopel having trouble with that [16:28:32] and does that also solve your DX9 Client issue? [16:39:27] Both dx7 and dx9 [16:39:37] Gotta head to work now. bbl [16:40:46] indy91, just updating the LPD view meshes [17:00:48] ah right, I forgot about those [17:14:27] large attitude rates will probably make the GDC less accurate, but that should be rather realistic [17:22:38] people will just have to do GDC Align a bit more often [17:39:20] looking forward to trying that' [17:40:27] with the new meshes, LPD mesh position vectors are much easier, I can use the same vectors as the meshes themselves instead of what was used before (lpd_dir) [18:48:53] easier is good [18:49:19] GDC update might be ready tomorrow, already very happy with it [18:52:19] nice [19:40:39] tumbling the CSM around for a while, GDC attitude still good [19:43:27] so definitely no issue with the equations [19:48:26] almost ready with my LPD mesh update [20:08:29] indy91, PR sent [20:09:14] btw there are now 3 LPD meshes, Ascent Stage, Descent Stage extended and Retracted [20:16:02] merged [20:16:11] thanks [20:36:28] morning! [20:38:01] hey [20:43:52] what's up? [20:44:26] working on the systems to fly an Apollo spacecraft without an AGC [20:44:30] so the SCS :P [20:45:19] Ive always thought of that challenge, fly a full lunar mission without an AGC [20:45:56] theoretically possible [20:45:57] good luck with the landing [20:46:19] no accurate landing of course [20:46:41] but in AGS mode and following the H/HDOT timeline its doable [20:46:41] it's basically like a normal mission, just more effort and less accurate, haha [20:47:19] backup GDC alignments should be possible with the data from the Maneuver PADs [20:47:20] yeah :D [20:47:36] one thing that wouldn't work very well is SCS Auto TVC [20:47:47] at least for longer docked burns [20:47:58] yeah like LOI [20:48:12] the trim gimbal angles shift during that burn [20:48:38] that needs a bit of work on the SCS, which I will do soon [20:48:48] I've done sucessful SCS LOIs [20:48:58] not very accurate, but survivable [20:49:25] with Apollo 8, so a shorter burn [20:49:52] the SCS Auto TVC could actually keep the thrust vector inertial, that hasn't been implement yet in NASSP [20:50:03] it needs a gimbal angle feedback [20:50:45] and it also still needs the I in PID controller :D [20:52:55] a few other small items with the SCS TVC also need work, I'll get to that after the GDC work [21:03:39] Back from work [21:04:30] wb [21:05:43] I guess you can tell the Orbiter Forum people what solved your DX9 Client issue, haha [21:07:41] what was the fix? [21:08:45] texture directory in the config was the issue [21:15:59] Not entirely. Ideally I want my Texture dir to remain in my 2016 dir. Now I need it in the beta one [21:16:06] And maybe make 2 copies [21:16:09] ah I see [21:16:39] btw the default VC position in the LM is set to LMP, I think Ill set it to CDR [21:16:58] yeah [21:18:16] night" [21:18:20] ! [14:44:57] hey [14:50:58] morning [14:52:32] I made a PR with a few more adjustments to VC views. I also changed the order which the meshes are loaded: Its now the descent stage 1st, then the ascent stage. This is due to the fact that the ascent stage needs to be loaded last if we want to be able to see the descent stage through its windows [14:54:25] I thinks its because if a mesh has a material with transparency defined, everything behind it has to be already rendered before, for it to be displayed through that materiel [14:54:59] interesting [14:55:45] I'll just trust you on this, haha, it's merged [14:56:16] I even noticed that with the mesh groups in my ascent stage mesh, if I set the windows to one of the first mesh groups in the mesh, then when you look at the windows in-sim then you see straight through the LM [14:56:31] But if I set the windows to the last mesh group, then all is good [14:58:33] btw try a landing from the VC view! [14:59:04] no panel yet obviously, but the VC is lloking better now for sure [14:59:10] looking [15:00:58] I am now starting on animating the RR. Looking through the AAPO code [15:02:39] I'll try that for sure [15:26:08] ok, last few GDC tests [15:26:32] oh, Ron had requested and got one of the MSC boxes with RTCC Requirements [15:26:46] turns out, despite them saying the contrary, the box numbers seem to have changed [15:26:57] so box 45 was the wrong one... [15:27:47] but then they also had said they have no further AGC schematics. Which are getting scanned by Ron right now :D [15:31:27] it's never aligning the wrong way around it seems. Must be already taken care of by using the sine of ASCP setting minus current attitude [15:52:43] I guess thats a good thing? [15:56:52] yep [15:57:18] the training manual mentions a lot of voltages, currently trying to figure how fast GDC aligning actually would be [16:01:36] so I have created a mesh resource file for the ascent stage, with the meshc utility [16:01:56] It defines all the mesh groups cleanly [16:02:37] what does the resource file consist of? [16:02:40] I just need to figure out how to add it to NASSP...I guess I can just copy it to the LM source code folder, then add an include to it in LM.cpp? [16:02:53] a list of mesh groups that can be used in code? [16:03:15] https://www.dropbox.com/s/ca8j9pruu1qbl1d/Screenshot%202018-12-14%2011.02.54.png?dl=0 [16:03:53] yeah [16:04:20] oh awesome [16:04:54] should also be named something with resource [16:05:33] ok [16:05:49] yes, add it to the LM folder [16:05:55] ok [16:05:56] then it needs to be included in git [16:06:05] and then in VS as a header for the LM project [16:06:06] right [16:06:17] and in code, not sure [16:06:18] in LEM.cpp? [16:06:21] wherever it is needed [16:06:25] right [16:06:47] so in VS as a header, where would I go for that? [16:06:48] after you have added it to the LEM VS project, close VS [16:07:00] sometimes it needs that to be saved [16:07:14] well, LEM project and then Header files [16:07:19] right click, add file [16:07:24] ah ok [16:07:50] and the actual #include line will only be needed where the list gets used [16:07:54] so nowhere right now [16:08:08] maybe in lemmesh when you start using it [16:08:15] ok [16:08:26] but that's step 2 [16:10:47] yeah [16:11:02] I am adding it to the VS project now [16:11:24] called it LM_AscentStageResoucre [16:11:30] LM_AscentStageResoucre.h [16:11:40] hopefully without that typo :D [16:11:45] ah haha [16:11:47] fixed [16:20:05] looks like I need a factor of 3.33 for the GDC align [16:20:17] from ASCP: 19.1V * sin(error) [16:20:24] from BMAG: 0.1V per °/s [16:20:53] and the ASCP input is used as the same input as an attitude rate [16:21:32] so I think that's how it works if it was voltages and not rad/s [16:21:55] just makes a bit quicker, it seemed quite slow before [16:22:00] nice and smooth, but also slow [16:22:08] makes it* [16:23:05] especially those final few degrees were slow [16:23:25] checklist for the GDC align just before launch already wanted me to release the button [16:30:39] ok, about to push the GDC update [16:31:32] done [16:32:03] awesome [16:32:08] if you want to test it, you can a few things [16:32:24] first don't wonder if both FDAIs will move to their current position in old scenarios [16:32:31] that's caused by the EDA updates I did [16:32:37] will only happen once in old scenarios [16:32:50] it's rendering the FDAI before the EDA code is used the first time [16:33:02] EDA now saves the FDAI data [16:33:07] and about the GDC [16:33:08] ok [16:33:18] you can maneuver around a bit to see if it's holding attitude [16:33:55] then, when you test GDC align, use: Select - FDAI 1, Source - Att Set, Att Set - GDC [16:34:25] GDC align doesn't happen instantly anymore, so you can actually watch it happening by looking at the error needles in that mode [16:34:41] when they are null, GDC align is done [16:34:56] and then maybe test a reentry [16:35:29] the update is probably obvious enough so that I should make a post on the forum [16:36:01] also, I haven't done any long term testing with the GDC attitude yet [16:36:23] it's not using a cheaty attitude reference anymore, which was essentially perfect [16:36:35] it works how it actually will have worked [16:37:00] minus the bad drift of course [16:37:18] only errors due to the operation principle [16:43:09] GDC align actually only works with the Att Set switch in GDC, even when that switch doesn't have a function for the FDAIs when FDAI 1/2 is selected [16:47:30] nice, I will try that out [16:47:32] I think I have my RR animations almost ready for a 1st test [16:50:34] oh great [16:50:47] so you added a function like the Add Animations one? [16:50:54] in clbk post creation? [16:51:20] I put it in lemmesh.cpp [16:51:52] maybe I can call it from clbk post creation? [16:53:15] that's the better place, yes [16:53:22] does the LM even have that function yet? [16:53:45] yes [16:53:53] I added it when MCC support was added [16:54:08] just call the "add animations" function in there [16:54:17] it's really the best place for it [16:54:24] clbkPostCreation [16:58:38] ok and how about the actual animation state changes? clbkPostStep? [16:59:14] or maybe that should be called from the systems themselves (RR) [17:01:15] hmm, yeah [17:01:28] I'll look how other vessels do that [17:01:56] the AAPO has some code in pre-step to set the RR to an initial state [17:04:53] initial state? Isn't that done with CreateAnimation? [17:05:38] yeah [17:05:52] maybe pitch 0 and yaw 0.5 [17:06:31] sorry dont know how "maybe" go it there [17:06:45] meant to say "pitch 0 and yaw 0.5" [17:06:57] what's the range of values for those? [17:06:58] in CreateAnimation [17:07:03] 0 to 1? [17:07:37] but he added some stuff in pre-step to set it to pitch 0.28 yaw 0.5 [17:07:48] yes [17:08:39] to animate what? The RR? [17:09:29] yes [17:10:19] I think 0 to 1 should correspond to -180° to 180°, that makes things easier [17:10:29] CreateAnimation has to be set to correspond to the unmodified mesh, so I guess not necessarily the desired initial RR state [17:10:32] or did he use the hard stops of the RR? [17:10:38] oh, ok [17:11:06] I would expect that to be 0.5 and 0.5 [17:11:11] no [17:11:17] it doesn't start at 0/0 [17:11:32] I think its yawed 180 [17:12:00] yes [17:12:02] trunnion [17:12:36] but does that need to be set? I think it will be getting the variable from the RR itself [17:12:45] right [17:12:52] mesh is 0/0 I guess [17:12:59] that's still not 0.5 and 0.5 actually [17:13:14] because trunnion is different [17:13:26] if we assume 360° animation, then it would go from -270° to 90° actually [17:13:39] so 0.25 is -180° [17:13:53] and 0.75 is 0° [17:14:09] maybe he animated it backwards [17:14:19] that would explain the 0.28, close to 0.25 [17:14:38] and shaft would still be 0.5 [17:18:16] well I got the thing moving in-sim, thats a start :D [17:19:08] haha, great [17:19:48] Ill show you the code [17:20:13] https://www.dropbox.com/s/n9g7l77moslypb1/Screenshot%202018-12-14%2012.19.50.png?dl=0 [17:20:37] and the variables are defined in the same new resource header I added [17:20:48] https://www.dropbox.com/s/bngon6t64vhzkr8/Screenshot%202018-12-14%2012.20.16.png?dl=0 [17:21:16] some of those need to be changed I guess [17:22:26] the which variables are defined there? the GRP ones? [17:22:32] -the [17:23:00] the GRP ones, and the animation axis definitions [17:23:32] like pivot point in the mesh, rotation axis and rotation range [17:23:47] hmm, I think maybe this should be in RR [17:23:49] code [17:24:19] ok [17:24:21] makes the state variables less messy [17:25:01] so I can pull it directly from the RR code, into the MGROUP_ROTATE function? [17:25:24] yeah [17:25:38] all the code you have there in the RR constructor [17:25:45] which those variables probably already exist [17:25:45] except the SetAnimations [17:25:56] ok [17:26:00] those in a clbkPostCreation function you create for the RR [17:26:14] which gets called in the LEM::clbkPostCreation [17:28:31] and what drives the RR will be a SetAnimation at the top of the RR timestep [17:30:11] but the variables that define the rotation of the mesh itself in the MGROUP_ROTATE, I am confused about where to get them from [17:33:33] what even are those [17:33:39] the mesh groups are clear [17:33:43] what is LM_RADAR_PVIOT? [17:33:47] PIVOT* [17:34:17] and what is the range? [17:36:14] pivot is the coordinates on the mesh of the pivot point [17:36:26] range is the range of motion for the axis [17:36:36] so yaw is wrong it should be 360 I guess [17:37:06] I mean, it might be easier to define it like that for the math [17:37:12] but the actualy range is of course not 360° [17:37:18] on neither axis [17:37:40] what is the range currently? [17:38:01] it was 48 for some reason [17:38:06] this is copied from AAPO [17:38:10] yeah [17:38:13] for yaw [17:38:35] the default state it definitely 0/0 [17:38:37] ? [17:38:46] on the mesh [17:38:58] and does range count in both directions? [17:40:13] what's the range on the other axis? [17:41:06] pitch is set to 90 [17:43:26] hmm [17:43:31] so to get a 360 rotation, I set the range to 360, and the variable is 0 to 1, so 0 is 0 0.25 is 90 0.5 is 180 0.75 is 270 etc [17:44:15] yes [17:44:28] both axis have more than 180° movement [17:44:33] so might as well make it 360 [17:45:01] but 360° total might mean you have to use 180° as the input for the mesh group [17:46:06] do we have the value for the actual range? [17:46:27] sure [17:46:44] search for limits in lm_rr [17:47:56] so -250 to +70 [17:48:02] for the trunnion [17:48:09] yes [17:48:14] aka yaw [17:48:28] so that would be 180 [17:48:56] 70- -250 = 320° [17:49:22] 320° possible movement [17:49:44] but if you use that the conversion from angle to 0-1 will get more complicated [17:50:00] I mean I can just use 360 all around [17:50:08] to be easier for the math [17:50:09] yeah [17:50:19] or 180°, depending on what the range means [17:50:36] range is the total range [17:50:40] ok [17:50:42] then 360° [17:51:59] is 0 input the default state? [17:52:07] input for SetAnimation [17:54:24] well it has to be the same as the unmodified mesh's state [17:54:30] ok [17:54:44] which the RR is pointing forward in the mesh so I guess it should be set to 180, or 0.5 [17:55:15] as the initial state, as aset in PostCreation? [17:55:18] as set* [17:55:26] yeah, I think so [17:55:37] CreateAnimation(0.5); in DefineAnimations() [17:56:01] ah right [17:56:05] which gets called in psot creation [17:56:10] post creation [17:56:16] thats how I have it set up anyway [17:58:07] yeah [17:58:39] constructor or PostCreation probably doesn't matter much for most of the code [17:58:46] just SetAnimation can't be in the constructor [18:00:10] for performance reasons the RR code probably should keep track of "animated" RR angles, so that it doesn't do SetAnimation every timestep. But that comes later [18:01:36] so right now the code is all defined, it just needs the RR to feed the variables to the animations [18:01:42] rr_proc[0] = 0.0; [18:01:43] SetAnimation(anim_RRPitch, rr_proc[0]); [18:01:43] rr_proc[1] = 1.0; [18:01:44] SetAnimation(anim_RRYaw, rr_proc[1]); [18:01:54] ok [18:01:57] with the rr_proc variable [18:02:07] rr_proc is just simple doubles? [18:02:20] doubles yes [18:02:26] not static or so [18:04:00] its defined as a double [18:10:10] in that case [18:10:23] rr_proc[0] = shaftAngle/PI2; [18:10:24] I think [18:10:35] oh, and [18:10:46] if (rr_proc[0] < 0) rr_proc[0]+=1.0; [18:10:58] to make a negative angle not result in a negative animation state [18:11:07] ok [18:13:01] in the RR timestep? [18:13:22] yeah, at the very top of it [18:19:13] Ca marche! [18:20:10] awesome [18:20:28] the sign of the animation state could of course still be wrong [18:20:50] so it's pointing left when it should be pointing right [18:20:51] or so [18:20:59] should be easy to figure that out though [18:21:17] it is haha [18:21:32] Ill fix that [18:21:54] I can do the S-band next [18:21:54] rr_proc[0] = -shaftAngle/PI2; [18:22:00] simple as that, haha [18:22:17] well, first commit and PR it please [18:22:45] also, the performance thing I mentioned [18:23:09] it should check if it even has to do SetAnimation in the current timestep [18:23:21] something like: rr_proc_last [18:25:11] yep Ill PR it in the next few minutes [18:25:51] some axis are still inverted though [18:26:45] just another minus then [18:39:15] still having trouble with this [18:39:47] pitch is fine but its the yaw that is not working correctly, its 180 off in orbiter from what it should be [18:39:57] Ill PR it for you to take a look if you want [18:40:09] just push it to your repo [18:40:15] doesn't need to be a PR yet [18:40:48] ok [18:48:11] indy91, https://github.com/jalexb88/NASSP/commit/2f5e81fae5a8ae58c008484693ad5fb59127d5b9 [18:49:10] you still need to add LM_AscentStageResource.h with git [18:49:59] lem->rr_proc[1] = trunnionAngle / PI2; [18:50:00] if (lem->rr_proc[0] < 0) lem->rr_proc[0] += 1.0; [18:50:03] second line [18:50:07] [0] [18:50:10] should be [1] there [18:50:46] you current have "if (lem->rr_proc[0] < 0) lem->rr_proc[0] += 1.0;" twice [18:50:50] currently* [18:50:55] hmm thought I added the file in git already [18:51:07] ah, might be a previous commit [18:51:26] with "git add" etc? [18:51:37] oh wait [18:51:38] haha [18:51:41] I'm dumb [18:51:43] it's there [18:51:49] haha its ok [18:52:12] usually when I had added new files they were too large, so they only showed them in short form on Github [18:52:17] that is what I was looking for [18:52:31] so yeah, just fix those [0] to [1] [18:52:34] that should do it [18:52:49] ok [18:53:38] it was basically not doing that correct for rr_proc[1] [18:53:43] just for rr_proc[0], twice, haha [18:53:49] correction* [18:54:29] then next [18:54:30] UINT anim_RRPitch, anim_RRYaw; [18:54:30] double rr_proc[2]; [18:54:35] those can be in RR code I think [18:54:45] currently in LEM [18:58:35] the RR yaw is still backwards in-sim [18:59:19] I think the code in the RR timestep thinks 0 is facing forward [18:59:28] but 0.5 is facing forward [19:00:19] can you push your latest state? [19:00:54] and I fixed the rr_proc[1] thing and ill transfer the variables to the RR code] [19:00:56] sure [19:01:56] 0 should be right for facing forward? [19:02:41] 0 is facing backwards [19:03:02] weird [19:03:12] is that hope the mesh is by default? [19:03:14] how* [19:03:30] facing forward by default [19:03:50] anim_RRYaw = CreateAnimation(0.5); [19:03:58] this is probably doing that? [19:04:23] but it should be overwritten on the first timestep, so that's weird [19:04:50] initial_state the animation state corresponding to the unmodified mesh [19:04:54] uhh [19:05:02] that was a quote from the Orbiter API [19:05:05] so it should be 0.0 there [19:05:37] I guess setting it to face backwards will only done on the first timestep [19:06:10] yeah, that 0.5 is probably giving it a 180° offset, which is your issue [19:07:06] Create animation should have it in the state of the mesh itself [19:07:14] but I guess I could make the mesh have it backwards [19:07:30] heres a picture showing the current setup: [19:07:31] https://www.dropbox.com/s/xlzyfyoyhky861t/Screenshot%202018-12-14%2014.03.09.png?dl=0 [19:08:12] trust me, anim_RRYaw = CreateAnimation(0.0); will fix it [19:08:25] ok [19:09:02] well, I don't know anything about animations in Orbiter, but it looks like the cause :D [19:09:45] another thing, with the variables in the RR class, they were called in lemmesh, but now are undefined [19:10:31] right [19:10:41] that will need the animation definition in the RR constructor [19:13:54] brb [19:25:23] morning! [19:25:45] hey Mike [19:28:58] what's up? [19:30:53] got the RR animated! [19:31:25] back [19:31:32] got it working [19:31:36] ah, great [19:31:47] you were right about CreateAnimation [19:31:52] thewonderidiot, Ron got a box full of MSC memos that I requested... and it was the wrong one! [19:31:57] they changed the numbering system [19:32:08] I could be having some RTCC Requirements maybe even right now... [19:32:13] hahahaha [19:32:25] before they said they didn't change the system [19:32:34] lol [19:32:36] so I guess that means they changed the numbering on everything? [19:32:40] but then they also said there are no further AGC shcematics... [19:33:01] he'll talk to them if they have some new list or so [19:33:10] it might still be in chronological order [19:33:16] what he got were 1968 memos [19:33:23] I can extrapolate from there :D [19:34:18] it was late 2016 when they told me they definitely, 100% did not have any 20xxxxx schematics [19:34:42] haha [19:34:49] so... LVDC code when? [19:35:16] heheh well [19:35:25] not in Fort Worth [19:35:25] we'd need a drawing number [19:35:35] maybe in NARA Atlanta [19:35:38] but also there are some incredibly cruel things that Ron has scanned so far [19:36:10] like first pages of all MSC memos... [19:36:21] no that was helpful [19:36:27] and cruel [19:36:28] both [19:37:04] anything hinting at, but not actually showing erasable memory stuff? [19:37:37] indy91, repo updated [19:37:39] thankfully they had complete schematics for all of the parts of the erasable memory module [19:37:49] but the schematic is confusing on encapsulants [19:38:13] because the original drawing shows that it should be encapsulated with polyurethane foam [19:38:22] but the computer design review book says epoxy twice [19:38:32] so I'm not sure which to believe [19:39:45] maybe both are true, just not for the same time [19:39:55] unlikely [19:40:02] there would be different dash numbers [19:40:13] right [19:40:19] AlexB_88, looks all good, except [19:40:20] lem->SetAnimation(anim_RRPitch, rr_proc[0]); lem->SetAnimation(anim_RRYaw, rr_proc[1]); [19:40:25] in the RR constructor [19:40:33] https://ia801502.us.archive.org/BookReader/BookReaderImages.php?zip=/18/items/AgcApertureCardsBatch3Images/AgcApertureCardsBatch3_jp2.zip&file=AgcApertureCardsBatch3_jp2/AgcApertureCardsBatch3_0128.jp2&scale=6.536023054755043&rotate=0 [19:40:34] first, rr_proc is not initialized there [19:40:39] ^^ that is the kind of cruel I was talking about [19:40:39] that can't be good [19:40:47] ah right [19:41:03] give RR a post creation function [19:41:06] put it in there [19:41:20] call that in LEM post creation [19:41:24] thewonderidiot, oh nooo [19:41:44] but it's available at MIT/IL, no big deal :D [19:42:01] >:( [19:42:07] I have 1967 phone numbers I can call for help with the RTCC, should be still good [19:42:26] about as useful as that schematic [19:42:28] I may actually ask Debbie about that one [19:42:38] yeah [19:42:43] can't hurt [19:42:55] there was another cruel one from yesterday [19:43:20] https://ia801500.us.archive.org/BookReader/BookReaderImages.php?zip=/21/items/AgcApertureCardsBatch6Images/AgcApertureCardsBatch6_jp2.zip&file=AgcApertureCardsBatch6_jp2/AgcApertureCardsBatch6_0128.jp2&scale=6.916426512968299&rotate=90 [19:43:41] I was almost positive this was going to be a program listing, but it's just a dumb piece of paper claiming it is a mylar tape [19:43:44] :P [19:44:22] Block II-C? [19:44:28] never heard that before [19:44:44] pretty sure that means a C-series computer -- C1, C2, etc. [19:44:55] i.e. not one of the original 15 like we have :D [19:45:01] not that it should make a difference... [19:45:14] ah right, those [19:45:20] is that the flight spec? [19:45:28] were C1 and so on the ones flown? [19:49:50] indy91, where do I call the new post-creation function from? [19:50:04] I have added it to the RR [19:53:24] LEM::clbkPostCreation calls RR::clbkPostCreation [19:54:40] automatically? Or do I have to add something in LEM::clbkPostCreation, for it to call RR::clbkPostCreation? [19:55:10] oh yeah, that's what I meant. In LEM::clbkPostCreation add a line [19:55:17] rr.postcreation() basically [19:56:17] LEM::clbkPostCreation gets called by Orbiter automatically. But only because it's an overloaded function of the VESSEL class and Orbiter does that for every vessel [19:56:57] the RR function is just conveniently called the same, but it could be anything [19:57:37] hmm its not working for some reason..identifier rr is undefined [19:58:33] probably not called exactly that [19:58:50] LEM_RR RR; [19:58:54] so RR [19:58:55] not rr [19:59:28] ok got it [19:59:34] so RR.clbkPostCreation(); [19:59:48] yep [20:03:27] so I guess all future animation definitions should be added directly into the system in question [20:05:52] yes [20:05:56] getting a CTD at start now [20:06:00] great :D [20:07:04] so, the DG defines some animations directly and not in a subsystem, but those are directly connected to flight control surfaces [20:07:15] all others are in subsystems [20:07:33] indy91: C8 and up were flown [20:07:39] C1-C7 were 2003200 [20:07:44] I see [20:07:59] so C is late revision, but not last [20:08:05] not generally last [20:08:23] something like that [20:08:28] right :D [20:08:36] AlexB_88, figured out why yet? [20:08:37] I am pretty sure the C isn't even a revision letter [20:08:47] I'm 90% sure it just stands for "Computer" [20:09:15] because the DSKY designations changed to D1, D2, etc. at the same time the computers changed to C1, C2, etc. [20:09:59] nope [20:10:21] push latest state [20:10:30] what is "Block II-C" then [20:11:11] like I said before, a Block II C-series computer :P [20:11:24] but it says [20:11:34] "Block II-C Computer" on that last scan you posted [20:11:47] yep [20:11:54] so it's... double computer [20:11:58] yeah [20:12:23] like the LM "stability and control control assembly" :D [20:12:31] or an ATM Machine [20:12:33] lol [20:12:35] haha [20:14:13] indy91 pushed [20:15:11] are rr_proc[0] and rr_proc[1] initialized to 0 in the RR constructor? [20:15:18] probably won't fix it, but it's good style [20:15:27] not sure when the init function gets called [20:15:31] before or after post step [20:15:39] probably before, so it wouldn't fix this [20:16:38] and it's only this last commit with the post creation stuff that broke it? [20:16:43] seems so simple... [20:20:35] I reverted it and it still happens [20:20:50] only the LM though, scenarios with no LM are fine [20:22:49] must be something unsafe [20:23:04] can you try to debug it? [20:23:32] with the VS debugger I mean [20:25:45] does commenting out that RR clbkPostCreation line fix it? [20:27:29] no, you reverted and it still happened [20:27:35] yeah [20:27:59] Ill do a clean then rebuild evrything then if that doesnt do it Ill debug [20:32:31] sp for VS debugger I just build in debug mode? [20:32:35] so* [20:33:13] keep forgetting how to do that [20:34:36] yeah, but you can also first try release mode actually [20:34:47] open Orbiter, but don't start the session yet [20:35:14] then in VS, debugging/attach to process and choose the Orbiter exe [20:35:21] you can find some bugs that way [20:35:37] some, maybe most, need to be build in debug mode, yes [20:37:31] ok it found something [20:37:38] https://www.dropbox.com/s/ff0xs7jeuhuafao/Screenshot%202018-12-14%2015.37.31.png?dl=0 [20:39:08] ah, good [20:41:02] so [20:41:07] there is &meshgroup_RRPivot [20:41:11] but then [20:41:12] meshgroup_RRAntenna [20:41:14] no & there [20:41:18] which one is right? [20:41:51] ah wait [20:41:55] it's a array [20:41:59] so that is right [20:43:33] ah, I see [20:43:55] RR constructor is called through LM constructor [20:44:04] that is before the RR init is called [20:44:15] so the lem pointer in the RR is undefined [20:44:27] hence the access violation [20:46:22] what is all done with LEM::ascidx? [20:46:40] thats the mesh index [20:47:45] ah, right [20:47:58] hmm [20:48:48] I guess you could probably put all of the animation code currently in the RR constructor in the post creation code [20:49:09] yeah [20:49:14] try that [20:49:18] everything after "//RR animation definition" [20:49:31] just put that in the other function [20:49:56] basically as we had it at first [20:50:07] animations being created in post creation [20:50:13] just in the RR, not the LEM [20:50:19] yeah [20:50:47] works [20:55:59] I am quite happy with this now [20:56:12] Ill amend my repo and PR [20:57:37] maybe it could use some save/load though [20:58:18] does it need that? [20:58:44] all I would like added is some code checking if the RR was actually moved, so that the animation doesn't happen every timestep [20:59:30] post creation actually gets called loading [20:59:39] so it might as well set the current RR angles [20:59:48] I think [20:59:51] well you do see it pop into position at session start if you look at it closely [21:00:20] ah [21:00:22] first timestep [21:00:28] yes [21:00:33] try using the actual angles then [21:00:45] in SetAnimation in RR post creation [21:00:52] that might do it [21:00:57] uhh [21:01:04] well, the transformed angles with rr_rpoc [21:01:06] proc* [21:02:34] right [21:02:51] so [21:02:52] rr_proc[0] = shaftAngle / PI2; [21:02:52] rr_proc[1] = -trunnionAngle / PI2; [21:03:00] in RR psot creation [21:03:03] post [21:04:24] before the set animation, yes [21:04:50] simply copy the 4 lines from the beginnning of the timestep there [21:06:14] ok [21:06:15] maybe I should put the 4 lines into a function, and call that where needed [21:06:37] nah, it's only needed in two places [21:06:42] ok [21:06:50] it wouldn't hurt to do that of course [21:08:34] nah ill leave it [21:10:36] DG is a single mesh [21:10:41] does nothing fancy there [21:10:59] that's why it can simply put a 0 instead of the mesh index in that function [21:11:09] so that's how it can use the constructor for the mesh animations [21:11:34] or maybe it's a separate mesh for the gear, but nothing like stages [21:12:30] PR sent [21:12:50] I'll look over it in the morning [21:13:30] can't wait to see that animation! [21:13:35] good night! [21:13:45] night [00:24:39] .indy91, I found another issue with the RR animations: When staging, the mesh index (ascidx) loses its animation definitions and the RR reverts to 0 on the mesh. I have fixed this by changing the AddMesh function to load the new ascent stage to InsertMesh, this seems to make ascidx keep the animation definitions. [00:25:27] .tell indy91 I found another issue with the RR animations: When staging, the mesh index (ascidx) loses its animation definitions and the RR reverts to 0 on the mesh. I have fixed this by changing the AddMesh function to load the new ascent stage to InsertMesh, this seems to make ascidx keep the animation definitions. [10:32:50] . [11:07:10] hey [11:07:50] hey Alex [11:08:02] just merged your PR and doing a few style fixes to it :D [11:08:28] haha sounds good [11:08:36] I am working on the S-Band now [11:08:46] the way the LM assembles itself is pretty messy. Like the order of e.g. mesh definitions [11:08:54] yeah [11:08:57] it always first calls the descent stage function in lemmesh [11:09:18] that's the only way your PR was safe, because the ascent stage function there only calls insert mesh [11:10:20] but the mesh indizes you added were already initialited in SetLmVesselDockStage(), so that's how it doesn't give undefined behavior [11:10:47] you also forgot to give the indizes an initial value in the LEM constructor [11:10:51] not for the first time :P [11:11:11] mesh indizes are usually set to -1 [11:11:19] that gives a hard CTD if they are used [11:11:26] instead of undefined behavior [11:11:41] if they are used before they got a value that is [11:12:01] better to have crashes every time and not randomly [11:12:06] yeah [11:12:22] I'll put of a few corrections like that soon [11:12:30] put up* [11:12:56] now let's see how it looks :D [11:13:17] also, you said "this seems to make ascidx keep the animation definitions." [11:13:31] ascidx is just an integer [11:13:50] maybe the number changed? Then the animation wouldn't know what mesh to animate anymore [11:14:15] loading a scenario in darkness, very useful... [11:15:51] love it [11:17:29] can't wait for the other antennas to also be animated [11:19:16] it looks good eh? I have the S-Band already working [11:24:03] also, when staging sometimes the position of the RR on the ascent stage does not match what it was before staging [11:26:33] that seems to happen when staging with the RR in mode 2 region [11:27:10] but if its facing forward then the state of the RR is copied correctly to the new one on the ascent stage at staging [11:27:30] just not when the RR was facing backwards [11:27:37] ok, I'll check that [11:28:08] in NARA news, they put the MSC memos in new boxes in 2010, Ron scanned the first pages in 2004 [11:28:13] soooo [11:28:20] the box numbers are mostly useless [11:29:09] bummer [11:30:02] and my list as well, it was based on getting one box at a time [11:30:20] the two high priority documents I requested are probably not in one box anymore [11:31:07] not getting LOI Targeting would be sad, but I told him, if he still wants to scan something for me, to get the box with the Return to Earth RTCC Requirements [11:31:31] and scan anything with RTCC in the name from that. Or just the one document [11:49:17] it seems those docs are always just out of reach lol [11:52:57] btw any chance you could push the fixes of my PR? [12:11:34] sure [12:13:35] done [12:18:03] thanks [12:18:52] I see you added the code to only update when its actually moving [12:19:39] yes [12:20:07] great, I can add that to the S-Band too [12:21:12] yeah, the DG is always checking if it even needs to do the animation, so it's good to do that as well [12:22:15] have you done any GDC testing yet? [12:24:23] a bit yes [12:25:13] I did a GDC align to see the new functionality [12:25:45] I noticed how you have to keep GDC align pushed the whole time [12:26:10] yeah, previous it instantly set the new attitude and calculated the matrix for the next attitude reference [12:26:17] previously* [12:26:24] new* [12:26:41] now it works with attitude errors from the ASCP [12:26:49] so it can take a few seconds [12:27:05] and it will get much slower when it's approaching the new attitude [12:27:42] right [12:28:31] fairly sure I got the speed of it right [12:28:42] by comparing voltages [12:43:08] so I added a postcreation function in the SBandSteerable, and put the animation definitions in there [12:48:27] ok [12:59:49] apparently there is a risk of a government shutdown in the US starting on December 21st, which would mean NARA is closing down for that time. [13:00:08] so the documents might be an early Christmas present or not at all [13:14:57] and S-Band is up and running [13:15:58] gave it the proc_last code too [13:17:13] does auto-tracking work on it yet? [13:23:21] nope [13:25:54] well I guess now you have some motivation :P [13:30:29] hmm my contact probes are no longer loading [13:32:39] hmm [13:32:50] in what state? Just a random pre landing scenario? [13:33:40] yeah [13:33:46] P64 [13:33:47] SetMeshVisibilityMode(probeidx, MESHVIS_VCEXTERNAL); [13:34:17] that should make it visible from the external view, right? [13:34:23] yes [13:34:40] from any scenario with the LM not landed yet [13:37:10] hmm, probeidx is a local variable [13:37:22] shouldn't hurt I would think [13:37:32] the insertmesh change I did is the culprit [13:37:44] I reverted it and it works [13:38:19] probably some indexing madness [13:38:28] yeah [13:39:22] one thing I notice is we use ClearMesh() a lot, but apparently thats an obsolete function [13:39:50] do you think at Every ClearMesh() the indexes are reset? [13:40:09] the Orbiter internal index, yeah [13:40:13] ClearMeshes* [13:40:19] but not the integers in the LEM class [13:40:26] right [13:41:08] msligo, welcome! Thanks for that PR earlier, I've never used XRSound before, so I hadn't noticed that issue. [13:41:58] AlexB_88, ah, the new Clear Mesh has a retain animation thing [13:42:03] so maybe try that [13:42:09] I did [13:42:29] the order of AddMeshes is important [13:42:32] didnt work, but it says that if the indexing is wrong then [13:42:35] it wont work [13:42:36] yeah [13:43:09] so I could try that again, and make sure the order of the addmeshes are good [13:43:38] yes [13:43:41] ascent stage stuff first [13:44:24] so I will revert the insertmesh change back, then and ClearMeshes(true) and adjust the addmesh order [13:45:02] yeah, that could fix it [13:45:04] @indy91 thank you! I only downloaded Orbiter a couple of months ago, and I think XRSound is the new version of the old OrbiterSound. I don't have much development experience, but I thought that might be useful. [13:45:28] yeah, there is no proper OrbiterSound for Orbiter2016 [13:45:48] it works, as long as you don't touch the radio MFD [13:45:52] then Orbiter crashes :D [13:46:14] but if XRSound is the only one being developed then we should probably start using that and make NASSP more compatible to it [13:49:47] msligo_, if you have any questions about NASSP you can always ask them here or in the forum [13:52:41] indy91, so I got a CTD I was able to catch in the debugger [13:52:42] https://www.dropbox.com/s/yjz31lc38hnluaq/Screenshot%202018-12-15%2008.51.13.png?dl=0 [13:52:58] happens at staging, semi-randomly [13:53:16] probably an out of wack mesh order [13:53:24] yeah [13:53:41] @indy91 thank you. At the moment I'm just trying to work out how all the source files fit together. I know c++, but I've never worked on a large c++ project before. Can you suggest a good place to start? [13:56:28] yeah not quite sure what causes that, maybe using SetMeshVisibilityMode on a wrong index? [13:56:56] good place in the NASSP code? [13:58:13] yes please, at the moment I'm just trying to learn how the simulator works. [13:59:05] that is also a good thing to do, haha. Yeah, NASSP is quite the large C++ project [13:59:19] lots of projects in the VS solution file and many files over all [14:01:05] haha yes of course. I opened up the solution file, but in the folder structure it didn't have a CSM section, although it had several other components of the spacecraft (LEM, S-II, etc.) [14:01:16] oh right, that [14:01:30] as many things with NASSP that is due to it being an oooold project [14:01:45] Saturn and CSM project are the same thing [14:02:07] so all the CSM systems are actually part of the Saturn class [14:02:26] ahh right, that makes more sense, I'll take a look now [14:02:29] we want to separate that eventually, but that is probably a multi year project [14:03:19] since Orbiter 2016 you can have docked stages while landed, so it would now be possible to have the CSM and all the Saturn stages as completely separate entities [14:03:43] but for now it's basically a Saturn IB or V built around a CSM, essentially [14:04:46] and the separate projects for S-II etc. are only used after staging [14:05:45] before those stages get dropped they are part of the Saturn (aka CSM) vessel [14:06:05] right ok. So does that mean that the code for the csm is in a different place for Apollo 7 vs Apollo 8, since they used a different Saturn variant? [14:06:08] so usually they don't have much more than rudimentary code for shutting down the engines [14:06:25] indy91, about the mesh indexing order, do they just have to be called in the same order, that they are defined in the header? [14:06:59] all of the common code is in the Saturn class [14:07:45] there are of course the two separate projects for Saturn IB and V [14:08:01] but any CSM system will be common to them [14:08:24] AlexB_88, which header? [14:08:32] ok then, I'll have a look around and let you know if I have any questions. Thanks for the help! [14:08:35] lem.h [14:08:45] no, that's irrelevant [14:08:54] I mean I am wondering what does having it in the proper order imply [14:09:02] when AddMesh gets call it creates an Orbiter internal index of meshes [14:09:06] starting with 0 [14:09:22] and the function returns that index [14:09:25] 1,2, 3 and so [14:09:37] which gets saved in the index integers like ascidx [14:09:43] e.g. ascidx could be 13 [14:09:58] and in the animation definition you give it that index number [14:10:11] so it knows that it should be animating mesh number 13 [14:10:19] now you do staging [14:10:23] all meshes get cleared [14:10:36] some meshes aren't loaded anymore [14:10:46] so ascidx could get a different number [14:11:02] I think that is what should be taken care of, so that it doesn't get a different number [14:11:16] so the order should be the same in the 3 functions in lemmesh [14:11:23] ok [14:11:35] and any descent stage stuff should be last [14:11:51] btw in the header, dscidx and ascidx are UINT, while the other indexes are int [14:11:57] does that matter? [14:12:00] probably best if you look at a few indizes in a debug string while staging [14:12:09] hmm [14:12:13] not really sure [14:12:22] it's signed int vs. unsigned int [14:15:26] I think it's good to make then UINTs [14:15:34] ok [14:15:36] all? [14:16:04] sure [14:16:16] ok [14:16:23] I doubt it will fix any issues though [14:16:33] and why descent stage must be last? [14:16:38] more important is that ascidx has the same mesh ID after staging [14:17:05] right [14:17:06] all the meshes get cleared and it will assign new numbers for the meshes, starting with 0 again [14:17:14] at staging [14:17:21] the order is already the same in all 3 functions [14:17:24] if you use the retain animation option in ClearMesh [14:17:37] then ascidx needs to have the same ID again [14:18:04] and that only would work if the AddMesh for the descent stage stuff is last [14:18:41] do you still have any InsertMesh? [14:18:50] changed them all back [14:19:11] so you moved the descent stage mesh loading to a later point now? [14:19:19] in my local copy it is still before the ascent stage [14:19:36] just look at the indizes in a debug string and test staging [14:19:40] that should make things clear [14:19:51] ok [14:22:13] or any other mesh index that is making problems [14:40:03] ok got my debug string setup [14:42:08] I put it in post step [14:42:40] there actually is a dedicated space for it [14:42:51] search for "Debug tests" in lemsystems [14:43:11] ah [14:43:21] and I can leave it there, commented after [14:49:42] ok making progress [14:49:43] what is the issue you have right now? [14:49:58] I got the order right [14:50:16] of course putting the ascent stage before the descent stage was needed as you said [14:51:39] yeah [14:52:00] or else the ascent stage mesh gets a higher ID when it is loaded with the full LM [15:00:25] here is the order I have it in now: [15:00:26] https://www.dropbox.com/s/he6meigs6msr65h/Screenshot%202018-12-15%2010.00.05.png?dl=0 [15:01:05] Ive set that order for all the stages [15:01:50] ok [15:02:16] fwdhatch and so on will then get a new ID at staging [15:02:20] and not keep the one they hadf [15:02:28] yeah [15:02:41] but I guess it doesnt matter if they dont have animations [15:02:45] yep [15:02:54] but ascent stage is retaining its animations now! [15:02:58] great [15:03:01] and probe is loading? [15:03:04] or showing [15:03:31] yep [15:04:13] good [15:04:22] there is still the issue that the animations on the new stage are not quite the same as the before, but thats a separate issue I think [15:04:37] I think the pivot points need updating at staging maybe [15:05:17] interesting [15:05:22] maybe because of the changed CoG? [15:06:47] maybe [15:07:37] btw I added the true to ClearMeshes() of LmVesselHoverStage and LmAscentHoverStage [15:07:44] yeah [15:07:49] but not VesselDockStage [15:08:15] since it shouldnt have any animations there yet anyway [15:08:26] but I guess it wouldnt hurt to have it there too? [15:08:51] probably not [15:17:41] so I think I have managed to send some calmness in the index madness :D [15:20:14] very nice [15:24:53] so the issue with the RR orientation going out of whack after staging is not due to CoG shift as the same thing happens at gear deploy when it goes from DockStage to HoverStage [15:25:24] hmm [15:25:59] when you reload the scenario everything is ok again? [15:26:40] and can you describe again what happens? [15:26:40] yes [15:26:58] the RR just randomly shifts to a weird orientation [15:27:29] but when I reload its back to the orientation it was before staging [15:59:38] it only happens in the Shaft (pitch axis of the RR it seems) [16:05:07] what happens to the RR at staging, is the system re-initialized or does nothing happen at all? [16:05:25] in the system code I mean [16:06:42] shouldn't initialize again [16:10:19] yeah thats what I thought [16:13:50] so if I give rr_proc[0] a hard number like rr_proc[0] = 0.5; then at staging the RR does not change position [16:14:26] but when its using the rr_proc[0] = shaftAngle / PI2; thats where it shifts [16:14:34] I find that weird [16:14:57] because shaft angle is a number thats not changing either [16:15:27] shaftAngle [16:15:51] look at those in a debug string at staging [16:15:55] I did [16:16:25] could it be an issue with rr_proc_last? [16:16:30] I looked at both shaftAngle and rr_proc[0] [16:16:41] nope because it was happening for me before you added those [16:16:48] did you try to manually move the RR? [16:16:53] oh, ok [16:31:12] Ill push my mesh index changes and SBand antenna animations [16:32:36] ok [16:34:00] its up [16:34:11] do you want to take a look before I PR it? [16:35:49] I'll look at when you have PRed it [16:36:08] don't think it will need changes [16:36:15] ok [16:36:26] PR sent [16:37:48] does the Steerable have the same staging issue? [16:38:35] const VECTOR3 LM_RADAR_PIVOT [16:38:49] the const is a nice idea, but it won't fix anything, haha [16:39:05] but it's valid to use const there, definitely no issue [16:39:14] some would even prefer it that way [16:39:42] good PR, merged [16:42:51] thanks [16:47:05] yes it happens with the steerable [16:47:22] damn [17:19:22] closing in on 3000 commits since NASSP 7 [17:23:09] haha, nice [17:41:29] so when I get around to animating the legs extension, that presents a new question: Should we merge DockStage and HoverStage into one? [17:42:30] and then have the leg extension call also update the touchdownpoints [17:44:13] yeah, I think I'd prefer those being merged [17:44:27] yeah [17:46:00] I think theyre pretty much identical right now, save for td points and meshes [17:46:09] yes [17:46:20] moments of inertial would also be different [17:46:55] it'll probably be good to just do the cleanup of the LM initialization while we are at it [17:46:58] I'll look into it [17:51:46] so for hatch, and leg extension, should the animations definitions for that be in lemmesh or somewhere else [17:53:40] yeah [17:53:48] those are of course not continuous [17:54:06] so they just have two states, with a transition state [17:54:17] the DG code has good examples for that [17:54:50] right [17:54:59] well the AAPO one too ;) [17:56:24] right [17:56:33] how is the AAPO code doing the animations? [17:56:43] where does it have the SetAnimation? [18:00:15] In its timestep [18:00:40] ok [18:01:02] if (HatchStatus == OPENING) [18:01:03] { [18:01:03] if (hatch_proc < 1) hatch_proc += delta; // If process value is less than 1 add delta to process value [18:01:04] else HatchStatus = OPEN; // If process value is greater than 1 set status to OPEN [18:01:06] I mean, it could go into LEM::SystemsTimestep [18:01:12] ok [18:13:42] so can I make hatch_proc listen to an already existing variable on the state of the hatch? [18:13:52] or do I have to make new ones [18:17:04] it should definitely be connected directly to the hatch state [18:19:01] right [18:19:28] that's why I was referring you to the DG code, it has some good code for that [18:19:34] ok [18:21:01] where it basically takes a discrete state (hatch open or not) and gives it animation state, that takes a bit of time for opening/closing [19:19:15] ok I got the hatch working [19:19:28] Ill push to my repo what I have [19:47:20] ok [20:03:18] ok sorry for the wait, took some time to get my head around the code [20:07:58] indy91, how does this look? https://github.com/jalexb88/NASSP/commit/53429e8430a0b727c30c0da3aa69e32a59bb1baf?diff=unified [20:13:43] the stuff you put in SystemsTimestep should probably be in a class or so [20:14:26] like the DG does with animstate [20:15:02] AnimState2 class I mean [20:17:35] AnimState2 is basically the hatch_proc made into a class [20:19:39] hmm cant find it [20:19:55] AnimState2 in the DG [20:20:23] search for [20:20:23] class AnimState2 [20:20:37] it's in Instrument.h [20:23:15] of the DG? [20:23:22] hmm I cant see it at all [20:23:22] yes [20:23:33] Orbiter2016 version of the Delta Glider? [20:23:47] yeah [20:24:05] in the DG solution [20:24:10] DeltaGlider project [20:24:13] then Source [20:24:18] Instruments [20:24:22] Instrument.h [20:24:32] lines 73 [20:24:35] line* [20:25:04] my instrument.h has only 47 lines [20:25:10] in the DG project [20:25:11] uhhh [20:25:38] ughhhh [20:25:43] i am stupid [20:25:47] yes, that's the Orbiter 2010 version [20:25:59] Ive been looking at the Orbiter 2010 version all this time [20:27:16] ok yes now I have it [20:27:23] class AnimState2 [20:28:19] just steal the whole thing :D [20:29:11] I'm looking at GearSubsys [20:29:16] as an example on how to use it [20:29:45] there would be a AnimState2 hatch_state in the LEM class [20:30:00] it's in a GearControl class here, but that's not so important [20:30:33] in the LEM init you have to give it a operating speed [20:30:50] hmm, where should AnimState2 go... [20:31:51] and yes, I want you to copy that whole class [20:32:20] maybe in new files [20:32:26] for any animation utilities [20:32:41] like animation.h and animation.cpp [20:32:54] added to the LEM project, later also the Saturn ones [20:35:03] ok [20:35:22] so my whole hatch changes so far are out the window haha [20:36:15] not at all [20:36:23] just hatch_proc and hatch_status will be different [20:36:35] hatch_status is probably unnecessary then [20:36:49] hatch_proc replaced by the class [20:37:17] well, and justt like lem->ActivateHatch(lem->OPENING); [20:37:22] stuff* [20:37:55] ok, that is quite different :D [20:38:11] but it will be one elegant solution that applies to all other animations with discrete states [20:38:53] actually [20:39:05] so everything in the lemsystems timestep I can get rid of I guess [20:39:12] AnimState2 hatch_state should probably live in the LEMForwardHatch forward hatch class [20:39:17] yeah [20:39:31] if you have code in LEMForwardHatch already anyway [20:40:20] the whole animation code can be in LEMForwardHatch [20:40:52] if you want I can do a PR to your dev branch tomorrow with the changes, haha [20:41:02] yes please :D [20:41:09] I have a helmet fire here... [20:41:11] haha [20:41:55] it will be very easy to apply for you in the future [20:42:09] just setting it up for the first time is the tricky part [20:42:09] right [20:42:45] I agree that its the best patch [20:42:49] path* [20:43:10] I think my brain is saturated though for today :D [20:43:22] C++wise anyway [20:44:05] haha [20:44:19] all I did was ECA control logic, so it's only saturated logic wise [20:46:21] I have all your repos set up on a first name basis [20:46:26] so I just did "git fetch Alex" [20:46:45] sounds simple [20:46:52] ah, hmm, you are on the Orbiter2016 branch... [20:46:57] how do I deal with that [20:48:55] development branch, easy [20:57:05] any luck? [20:58:16] started working on it, yes [21:01:03] ah ok good, I was referring to just getting my branch, but even better haha [21:01:56] so I guess we'll be able to use the new class for leg extension [21:03:37] yeah, I made a new dev branch instead of also using Orbiter2016 [21:03:49] then I'll PR my dev branch into your Orbiter2016 one on Github [21:04:06] then you can try it and then the proper PR [21:04:25] ok [21:16:59] got something working. I'll PR it and if it is broken somehow I can do fixes tomorrow. [21:20:56] sounds good [21:22:36] pushing new branch to Github is slow [21:28:47] very slow [21:31:29] done [21:31:47] if anything doesn't work or you have questions, just .tell me during the night [21:32:12] ok [21:32:21] good night! [03:55:41] .tell indy91, new animation class is working great, I even made the gear deploy work with it! [11:54:04] morning [11:55:54] hey [12:00:50] where did you put the gear deploy timestep code? [12:01:38] EDS [12:03:47] yeah, good choice I think [12:03:58] see how easy it is now to add animations? :D [12:04:10] well, the ones with discrete states [12:05:20] well, easy now :D [12:05:30] I guess we just needed a good function for it [12:06:04] yeah, that's very C++ like [12:06:21] if you put in the effort to create useful classes many things become easy [12:06:39] right [12:07:47] I think the only thing missing for the hatch is save/loading [12:08:46] ah [12:08:56] the AnimState2 class supports that [12:09:59] right [12:10:51] loading function might have to be adjusted to how we do that [12:42:01] Ill push what I have so far to my repo [12:51:51] indy91, heres what I did for the gear deploy: https://github.com/jalexb88/NASSP/commit/3c077ff62f2a17fbd5d203925a1b81c3c6d929d6 [12:53:22] I added the gear_state.Open(); to the deploy call, but left it commented because we still go through SetLmVesselHoverStage(); [12:55:02] So just for testing purposes in the current state: I uncomment that and comment lem->SetLmVesselHoverStage(); and I change the Addmesh in the DockStage to use the gear extended mesh [13:01:07] I'm confused why there would be a problem [13:02:28] first, eds.DefineAnimations(dscidx); should only be called before staging [13:04:06] so put it in a if statement? [13:04:45] if (stage < 2) eds.DefineAnimations(dscidx); [13:05:11] I guess it does need to have the animation after gear deploy to properly display the gear [13:05:17] or no [13:05:21] the default state is deployed? [13:05:46] yes [13:06:01] then the animation only needs to be used before that [13:06:05] so stage < 1 [13:06:08] ok [13:06:29] people might do saving/loading during the gear deployment [13:06:40] but then they will just miss the animation [13:06:42] makes things easier [13:07:21] thats what they get for saving mid gear deploy :D [13:07:26] yep [13:07:31] gear_state.Open(); should also be no problem [13:07:54] just put it at the top to the rest of the animation code [13:08:01] if (LG_Deployed) gear_state.Open(); [13:08:44] so below the part with gear_state.Process(simdt) [13:08:48] not in the if of course [13:09:08] and then that whole part still needs another if to check that stage < 2 [13:12:03] hmm [13:12:11] maybe it should just delete the animation at staging [13:12:31] yeah [13:13:24] we probably should have merged the hatch animation first, now the PR becomes a bit messy [13:18:07] yeah [13:18:20] sorry haha [13:21:04] I put it to this: if (stage < 1 && !NoLegs) eds.DefineAnimations(dscidx); [13:22:56] ah, right [13:23:34] it's probably good to delete the animation at staging [13:23:35] also could I change things like: RR.clbkPostCreation(); to something like RR.DefineAnimations(idx) [13:23:42] sure [13:24:12] and change the class in RR from postcreation to defineanimations [13:33:45] you mean the function? [13:34:43] you can do it that way, when it's merged then I'll look at it how to best deal with the descent stage being gone [13:34:51] I think it should delete the animation at that point [13:35:02] yeah the function [13:35:08] and anim_gear be set back to -1 [13:35:29] and it should check anim_gear then, instead of stages, leg less etc. [13:35:40] but that is just a bit of cleanup, can be done later [13:35:56] any other descent stage animations planned? [13:36:03] DPS [13:38:36] right [13:39:25] yeah, basically a "delete descent stage animations" function [13:39:50] hmm [13:39:59] aren't they UINTs? [13:40:07] what happens when you set a UINT to -1 :D [13:40:43] everything blows up? [13:41:53] definitely shouldn't be done [13:42:08] either we have to use int after all or it should be set to 0 [13:43:08] are we talking about MGROUP_ROTATE stuff? [13:43:40] the indizes [13:43:49] I think it is safe [13:44:07] setting a UINT to -1 should result in 2^32 - 1 [13:44:39] so basically the max number a UINT can hold [13:44:51] should be ok to do [13:45:01] however [13:45:09] not sure if later == -1 will work [13:47:46] Im checking the SIVB project to see how it deletes its animations [13:48:19] it doesn't [13:48:36] the separated panels are just hidden iirc [13:50:30] there is a commented " // Define all animations here and delete the unneeded later, [13:50:30] // otherwise Orbiter crashes" at the top of the animations section [13:51:26] this is AAPO: [13:51:28] https://www.dropbox.com/s/k7u9l8kenvqt8rk/Screenshot%202018-12-16%2008.39.42.png?dl=0 [13:53:50] yeah, those have to be deleted as well [13:54:08] that's just the mesh group transformations though [13:55:02] how does AAPO make sure that the animation isn't used after staging? [13:58:56] in any case, make the MESH indizes to an int [13:59:02] not UINT [13:59:11] if that doesn't break the animations [13:59:29] doesnt clearmesh() take care of deleting the animations? [14:00:05] not when you use the retain animation option [14:00:25] do you use true or false as the input for ClearMesh? [14:00:33] ah right, we use true [14:00:52] but we can get rid of ClearMesh and use DelMesh on a mesh per mesh basis [14:01:05] noooo [14:01:06] which also has the retain flag [14:01:37] that just creates more problems [14:01:43] ok [14:02:22] how does it assign the indizes? [14:02:26] does it start with 0 or 1 [14:02:50] 0 I think [14:03:38] mesh indizes start at 0 [14:04:31] ok [14:05:48] what about DelMesh(dscidx); just before the ClearMeshes(true);? [14:06:41] no, no. Just make sure for now that the animation code isn't used after staging or when it has no legs [14:06:52] ok [14:07:10] we can find a solution that is elegant enough later [14:07:19] about the mesh groups [14:07:39] you have those defined in LM_EDS, right? [14:07:57] MGROUP_TRANSFORM *mgt_Leg[4], *mgt_Strut[4], *mgt_Downlock[4]; [14:07:58] yeah [14:08:00] these guys [14:08:03] need to be deleted [14:08:20] if they are defined [14:08:28] yep [14:08:45] so null them in the LM_EDS constructor, which currently isn't done [14:09:08] and it should be sufficient to implement a LM_EDS destructor [14:09:21] where they get deleted like in AAPO [14:09:57] but with a check, if they still point to something [14:10:02] so not [14:10:07] delete mgt_Leg[i]; [14:10:09] but instead [14:10:17] if (mgt_Leg[i]) delete mgt_Leg[i]; [14:21:27] ok 1st to NULL them in the constructor [14:21:41] something like the lem = NULL;? [14:27:37] yep [14:27:45] each component though [14:27:53] not just the array pointer [14:28:26] so mgt_Leg[4] = NULL; etc [14:29:15] yes [14:29:19] 0 to 3 though, right? [14:29:44] yeah, just 0 to 3, not 4 [14:30:07] you can make it the same for loop as in the desctructor [14:34:24] what do you mean? [14:34:35] by the loop [14:34:53] oh the if (mgt_Leg[i]) delete mgt_Leg[i]; [14:34:57] setting each part of the arrays to null [14:35:12] instead of that mgt_Leg[i] = NULL; [14:35:15] in the constructor [14:37:27] hows this? https://www.dropbox.com/s/gfklkjbigq9ken4/Screenshot%202018-12-16%2009.37.11.png?dl=0 [14:37:52] that doesn't do what you think it does [14:38:09] mgt_Leg is an array with 4 entries [14:38:25] there is mgt_Leg[0], mgt_Leg[1], mgt_Leg[2] and mgt_Leg[3] [14:38:35] mgt_Leg[3] = NULL; only sets the last one to zero [14:38:49] you need a for loop like AAPO does [14:38:55] both in constructor and destructor [14:39:07] so I need to add for (int i = 0; i < 4; i++) [14:39:13] yes [14:39:19] ok [14:39:43] and then set them all to [i] [14:39:55] yep [14:41:20] alright done [14:41:44] so I added the destructor, btw where is that actually called from? [14:41:51] ~LEM_EDS() [14:42:46] automatically in the LEM destructor [14:43:01] LEM owns an LEM_EDS objects [14:43:09] the one defined in the LEM header [14:43:12] object* [14:43:49] ok [14:44:04] so I will test this and should be ready to push [14:44:16] yeah [14:46:09] actually, one more thing, I need to make the probes only display once the animation sequence has finished [14:57:13] something is screwing up the animation when lem->SetLmVesselHoverStage(); is called [14:57:32] like if I comment that then the animation is fine [14:57:48] if I leave it then it deploys but the animations are all weird [14:58:09] lem->SetLmVesselHoverStage(); called from the EDS that is [15:04:56] the order of meshes being loaded is the same in the two descent stage defining functions? [15:10:29] in SetLmVesselHoverStage() it uses ClearMeshes(true)? [15:11:23] both yes [15:11:48] ill push what I have [15:15:20] indy91, pushed [15:18:57] what does using a negative animation range? [15:19:00] -63 * RAD [15:20:59] I'm not seeing any obvious problem [15:21:21] the support struts [15:22:13] Im thinking this may be related to the issue where the RR and SBand suddenly shift positions after geardeploy/staging [15:22:28] yeah, I was just thinking the same [15:24:49] the RR/S-Band thing happens with gear deploy as well? [15:25:01] yep [15:25:08] but not in all axis [15:25:54] Like if the RR yaw is 0 then it wont shift, but if its 180, then the pitch will shift by a lot [15:26:50] another thing, do you get any build warnings? [15:27:09] yes, probably [15:27:10] (float)45 * RAD [15:27:12] has to be [15:27:15] (float)(45 * RAD) [15:28:24] ah yes I did [15:28:26] I correct that one already with the hatch I think [15:28:32] corrected* [15:32:03] probably for the RR too [15:32:19] still has (float)RAD * 360 [15:34:29] yes [15:42:43] I'll build your branch and look how it behaves myself [15:45:57] ok [15:47:06] fixing those warnings didn't solve it, right? :D [15:47:43] nope [15:50:53] what exactly is happening? Tried a gear deployment, didn't notice anything unusual [15:52:25] really? [15:52:54] one of my support struts was rotating weirdly [15:53:05] let me clean and rebuild [15:53:32] tried staging, now I got it [15:53:46] with the RR? [15:53:51] maybe I just had the animated stuff in weird directions in the first placre [15:54:03] yeah, definitely the RR, I think also the other stuff [15:54:17] the antenna is laid down flat on the LM basically [15:59:08] aha [15:59:31] it's an issue with parent/child system of animation components [15:59:39] ach_RadarYaw = lem->AddAnimationComponent(anim_RRYaw, 0.0f, 1.0f, &mgt_Radar_Antenna, ach_RadarPitch); [15:59:42] if I make that to [15:59:45] ach_RadarYaw = lem->AddAnimationComponent(anim_RRYaw, 0.0f, 1.0f, &mgt_Radar_Antenna); [15:59:49] then the issue doesn't happen [16:00:05] of course that is what couples the two animations together in the first place, right? [16:00:26] yeah [16:10:13] hmm [16:10:21] didn't I have this exact same issue with Apollo 5 [16:10:32] I had screwy S-IVB panels [16:16:47] I wonder if this has some clues: https://www.orbiter-forum.com/showthread.php?t=36332&highlight=child+animations [16:17:00] under Item3 he describes a problem [16:18:39] interesting [16:18:49] so, maybe it reloads the mesh in the default state [16:18:58] but still thinks it is in the zero state [16:19:12] no [16:19:17] that the animation is in the previous state [16:19:51] so it then applies that as a wrong offset [16:22:31] ah, I found a solution for the int/UINT thing [16:22:45] SSU defines a variable for that [16:22:46] const UINT MESH_UNDEFINED = (UINT)-1; [16:23:03] and initializes the mesh indizes to MESH_UNDEFINED [16:23:05] we'll do the same [16:23:13] ok [16:26:49] aha! [16:27:00] API Guide [16:27:18] top of PDF page 23 [16:27:39] "Note that in this case wheel isn't defined static" etc. [16:28:29] awesome [16:28:39] I think that is the issue [16:29:42] I think I know a good solution for that [16:31:07] first a check if that actually solves it [16:35:42] it doesn't actually [16:36:05] so it's probably that state thing after all [16:37:26] one test I did was to comment ClearMeshes() and all of the meshes section of SetHoverStage [16:37:34] that makes it work [16:38:08] but thats obviously because the meshes are never cleared/reloaded [16:38:12] yeah [16:38:34] I think Orbiter isn't able to keep track of the animation state, somehow [16:39:23] either a bug or something we do wrong [16:41:32] yeah [16:41:42] if I slew the RR to its default state then there is no problem [16:41:54] wasn't I reading something about this... [16:45:12] maybe we can merge SetLmVesselDockStage() and SetLmVesselHoverStage() right now [16:46:06] no, not in an animation development branch [16:46:08] too much at once [16:46:38] ok [16:46:42] I have an idea [16:48:10] idea didn't work [16:50:38] maybe I can get it to work, but we should probably ask on the forum anyway [16:51:40] yeah [16:51:51] I tried resetting the state of the animation just before ClearMeshes [16:51:53] doesn't work [17:02:17] bummer [17:08:43] there either is a way around this or it's a bug [17:08:54] the retain animations option should be able to deal with it [17:09:20] we'll see what the Doctor has to say about it. Are you making a post or should I do that? [17:10:03] hmm could you? Im sure you would paint a better picture of whats the issue then I can at this point [17:11:30] ok, will do [17:11:48] in the mean time, what do we do with the branch? [17:13:04] well for me it is a development branch, you were just using Orbiter2016, right? [17:13:20] yeah [17:13:51] I want to do a few changes and then we might as well merge it [17:13:57] only one specific thing is broken [17:14:09] yeah I agree [17:14:44] the gear deployment will look a bit off but it still works [18:41:48] ibdy91, I want to call the mesh visibility on the probe idx to only be set to visible after the deploy sequence is complete [18:42:34] I tried to use if (gear_state.IsOpen()) Doesnt seem to work [18:43:11] I wonder if theres something else in AnimState2 to return if the gear is deployed or not [18:43:34] indy91* [18:43:55] hmm, IsOpen should be working [18:45:02] where did you put that? [18:51:20] how does that work with the probes anyway [18:51:32] are they really deployed in some way during gear deployment? [18:52:35] yeah they are folded before gear deployment in reality [18:53:46] I see [18:54:05] I put it lem->SetProbeMesh(); in the EDS timestep, and in the SetProbeMesh(); [18:54:06] if (eds.gear_state.IsOpen()) { [18:54:07] SetMeshVisibilityMode(probeidx, MESHVIS_VCEXTERNAL); [18:54:58] well, in SetProbeMesh(): [18:55:04] if (probeidx == -1) [18:55:05] return; [18:55:06] if (eds.gear_state.IsOpen()) { [18:55:06] SetMeshVisibilityMode(probeidx, MESHVIS_VCEXTERNAL); [18:55:07] } [18:55:08] else { [18:55:08] SetMeshVisibilityMode(probeidx, MESHVIS_NEVER); [18:55:09] } [18:55:52] and how often does SetProbeMesh() get called [18:57:41] once in lemmesh and in the EDS timestep [18:58:55] you posted a lot of code but I don't know where that is [18:59:02] eds.gear_state.IsOpen() [18:59:08] wouldn't make sense in the eds anyway [19:00:08] what is in the EDS timestep? [19:00:33] // Animate Gear [19:00:34] if (lem->stage < 2) { [19:00:34] if (gear_state.Process(simdt)) { [19:00:35] lem->SetAnimation(anim_Gear, gear_state.State()); [19:00:36] } [19:00:37] lem->SetProbeMesh(); [19:00:37] if (LG_Deployed) gear_state.Open(); [19:00:38] } [19:01:49] just look at gear_state.IsOpen() in a debug string to find out if that is the issue [19:03:45] ok [19:13:47] so IsOpen() is an inline bool [19:13:50] I don't have any commit to add right now for the animations btw. [19:14:05] want to hear back on the forum first [19:14:33] sounds good [19:15:41] I wonder if I can at least revert my branch to the Orbiter2016 one and keep the dev branch separate in the mean time [19:16:47] in future always a development branch. I am often too lazy with that as well. [19:16:53] hmm [19:17:26] branching off from your current state should be no problem [19:17:40] but getting back to the old state might be [19:20:00] depends on what you want to do [19:20:17] do you want to do work on code in the current Orbiter2016 branch? [19:20:27] or just want to get back to the state of that in your local copy [19:21:44] well, ideally yes, its just if I have other things to PR in the mean time, I have to PR the whole thing [19:22:25] What do I need from VS again. Tried compiling NASSP but I'm missing the Win8.1 SDK [19:22:42] I guess I can keep my repo as it is and just work from it [19:22:42] Are we using toolset v140 still? [19:23:20] don't think so [19:23:29] but I had trouble with that as when I last set things up [19:23:38] randomly choosing VS extensions :D [19:24:24] I tried retargeting the solution to the Win10 SDK but orbiter wouldn't see the modules. [19:26:40] AlexB_88, put your stuff in a development branch first [19:26:43] that has to be done anyway [19:26:59] for example: git checkout -b AnimationWork [19:27:31] and then the usual [19:27:33] git fetch origin [19:27:42] git reset --hard origin/Orbiter2016 [19:27:43] I think [19:27:52] careful with that though [19:27:57] probably deletes all local changes [19:28:18] origin or upstreams, depends [19:28:22] upstream* [19:31:34] well I didnt have much new work on my local copy anyway [19:33:31] ok followed all those steps [19:37:13] you should now have the same state as dseagrav/Orbiter2016 [19:37:31] hmm nope [19:38:09] c:\Orbiter1>git reset --hard origin/Orbiter2016 [19:38:10] HEAD is now at 4c03a50e More animations fixes [19:57:01] Got it working. More texture BS [19:57:13] Btw, NASSP works when build with the Win10 SDK. [20:01:36] Performance appears to be the same. Would there be any benefit to retargeting to that SDK apart from being up to date? [20:13:23] AlexB_88, is your origin your own repo? [20:13:42] Thymo, what do you mean with performance? [20:15:21] indy91, this is the command I usually use when pushing to my online repo, if that sheds some light: [20:15:22] git push origin Orbiter2016 [20:15:29] Well I just quickly took a look if I wasn't having major FPS differences between the two. [20:15:50] https://github.com/Thymo-/NASSP/commit/4220d02b27ae74430725b31d94367f53a3593adf [20:15:54] then you want: git reset --hard upstream/Orbiter2016 [20:16:19] does retargeting to Win10 SDK give magic FPS boost? [20:16:25] and what again does that do? [20:16:49] it resets the state of your local repo to the one in dseagrav/NASSP [20:16:59] It does not. On the Apollo 7 launch scenario I'm hanging around 17 FPS. [20:17:04] what you did before with origin reset it to jalexb88/NASSP [20:17:28] I'm still tuning Orbiter. But 17 is a bit dramatic. Since my CPU and GPU are basically idling. [20:17:43] yeah, that's weird [20:17:58] usually one CPU core is at 100% on the main panel, because it's bad [20:18:35] well, depends if you are running anything else [20:18:39] Nope [20:18:41] sometimes I do get 60 fps [20:18:56] There's this new panel thing without blitting right? [20:18:59] and you build release mode? [20:19:14] new since about Orbiter 2010, yes :D [20:19:36] I'm building in debug [20:20:14] haha [20:20:29] I've never even seen double digit FPS in debug mode [20:20:40] I think it's because of some of the logs? [20:20:41] Not sure [20:21:07] but unless I am trying to find a loading bug I never build in debug mode [20:23:25] if you can find a way to improve that, great, but I don't really know [20:23:38] just build in release mode is my advice [20:24:17] We've had nasty issues in the past with undiscovered bugs in release mode. [20:24:19] damn now I think my AnimationWork branch was reset to yesterdays state [20:24:34] Getting 70 fps in release mode [20:24:45] thought it was supposed to be the other way around [20:24:46] Oh wow [20:25:05] In debug mode I got around 20 fps in external view. [20:25:10] AlexB_88, you needed to go back to the Orbiter2016 branch before resetting [20:25:13] In release mode I get 600. [20:25:48] AlexB_88, but you can recover by pulling from your Github repo [20:25:54] yeah [20:25:57] Are we doing any conditionally compiled code in debug? [20:26:03] Thymo, yeah, outside view is good fps [20:26:08] CSM main panel is terrible fps [20:26:15] yes we do [20:26:21] IMU and Virtual AGC logs [20:26:26] maybe some other things [20:26:36] it gets better if you comment that stuff out [20:26:45] not much in my memory though [20:27:02] ok got it back [20:27:23] sorry I am really bad with git :D [20:27:36] I saw those logs. I had the idea of moving those to their own directory like the dx9 client? Now they're in the root dir. [20:28:08] but I think I got my Dev branch how I want it. Now I will switch to my Orbiter 2016 branch and do the reset [20:29:03] Thymo, they never bothered me in the root dir. Where do you want to put them? [20:29:21] guess that also applies to the LVDC logs [20:30:55] I was thinking either Modules\ProjectApollo or some custom dir like \PALogs [20:31:19] Does SSU do logging? Maybe it could be standardized. [20:33:06] not sure [20:38:11] https://github.com/dseagrav/NASSP/pull/428 [20:38:58] looks simple enough [20:39:18] merged [20:39:23] Thanks. [20:39:42] At least it saves a little disk space because you don't need two separate SDKs. [20:40:04] Do note that you will need to install the Win10 SDK in the VS installer if you don't already have it. [20:41:48] I really hope the auto build thing has that as well [20:44:12] AppVeyor is compiling now. Looking good. [20:55:54] no problem here either [20:56:42] good night! [21:13:42] oh now I cant build anymore [21:14:09] Thymo do I need a new SDK version? [21:29:10] ah ok the win10 SDK [21:29:15] isntalling now [13:20:14] morning [13:20:17] hey [13:24:49] I think I have discovered some flaw in the SCS attitude hold calculations [13:24:53] flaws* [13:26:01] a bit difficult to untangle because of the pseudo rate/limit rate functionality, but I think I can do some improvements [13:26:22] might help with e.g. roll attitude hold stability [13:27:23] interesting [13:28:16] it doesn't do proper coupling with the attitude rate I think [13:29:00] so in the low rate setting it probably only works with the attitude error, not the rate, which of course makes it less stable [13:29:23] there are some factors being used to help with the stability, but that doesn't make it work any more correct [13:30:18] and the comments wrongly assume that the attitude rate deadband somehow contributes to the attitude error deadband [13:30:51] so, along with the SCS logic bus and general ECA logic implementation, I'll try to do some fixes there [13:31:16] good to know its being worked on [13:31:21] on my end I pushed some updates to my AnimationWork branch, mainly getting the gear extension sequence visuals perfected but also I tried an experiment where I commented all the mesh reloading in SetHoverStage save for probe and LPD [13:31:39] how does AAPO deal with staging and meshes? [13:32:03] it just does a DelMesh on the descent stage at staging [13:32:10] then reconfigures itself [13:35:12] or rather the other way around, reconfigures itslef (ShiftCG,SetPMI, etc,etc) [13:35:17] then the DelMesh [13:37:52] hmm [13:38:55] btw I was thinking last nigh tand I think I figured a way we could simplify our meshes down to just 2 meshes, ascent and descent stages [13:39:53] and just hide parts of the mesh? [13:40:26] yes and make the upper hatch and drogue part of the ascent stage mesh and animate it like the forward hatch [13:41:30] and the LPD mesh is now redundant because we have 2 separate meshes for ascent and descent stage [13:42:06] I had thought of that until now but we can just show/hide ascidx and dscidx and that would do the smae thing [13:42:37] even better is that you would see the leg extension from the LPD window because you are now looking at dscidx and not LPDext [13:44:29] and maybe with just 2 meshes we have more of a case to do it like AAPO, where we just DelMesh dscidx at staging [13:47:55] not clearing all the meshes would certainly fix the animation issue [13:48:40] and for the contact probe I would animate it as well and have it part of the descent stage mesh [13:51:19] sounds good [13:51:30] can you easily hide a mesh group in Orbiter? [13:52:19] I looked into it but havent found how yet [13:56:55] if that doesn't work then there isn't much of a point to making it all one mesh [13:59:56] yeah [14:00:22] you mean hiding the probes? [14:02:00] yeah, hiding the probes when they are a mesh group of the descent stage mesh [14:02:35] right [14:02:53] well we could always fold them inward or something [14:03:26] it might look kind of weird though [14:05:17] or we could have it as a separate mesh, hide it at contact and delete it at staging [14:08:00] hmm [14:08:06] can you quickly test something for me? [14:08:10] with the animation [14:08:24] the RR snaps into a weird position at staging [14:08:42] but the SetAnimation isn't used every timestep [14:08:54] does manually moving the RR fix the position of the RR? [14:09:59] nope [14:10:09] tried that already [14:10:12] right [14:10:30] so it's not that you just have to do SetAnimation once after the clear meshes and everything is good [14:13:33] I think I actually tried putting SetAnimation after the clearmesh in a stest before [14:13:38] test* [14:15:11] same [14:50:30] so this is the code I made that is called after ascent stage/descent stage mesh loading [14:50:37] to replace LPD mesh functions [14:50:55] for some reason the whole mesh is not visible in-sim though [14:51:42] https://www.dropbox.com/s/xrqyw5ipeidjod5/Screenshot%202018-12-17%2009.49.31.png?dl=0 [14:56:06] that will only set the visibility mode when you are on the LPD panel when it is loaded [14:59:10] right [15:00:55] lol obviously haha cant see why I didnt catch that [15:02:51] hmm but the else statement tells it if not InPanel && PanelId then set it to MESHVIS_VCEXTERNAL [15:07:34] in what cases do you want it to be visible? [15:08:46] I want it to be visible from the VC and External view in all cases except for in LPD window [15:09:00] that I want it in cockpit mode [15:09:24] and it's not visible in cockpit mode right now? [15:09:34] which I assume is 2D panel [15:09:39] it is [15:09:44] but not from outside [15:10:24] Im thinking the function is not getting called everytime I actually switch to external view [15:10:57] yes [15:11:15] the new function is called after mesh loading, and I added calling of the function everywhere ehre LPDmesh used to be called [15:11:24] but also, you might rather want MESHVIS_ALWAYS instead of MESHVIS_COCKPIT? [15:11:25] where* [15:11:30] hmm yes [15:11:50] but that presents one problem, in cockpit mode without 2D panel, you see the mesh [15:12:25] oh you mean in the LPD window part [15:13:44] ohh that worked I think [15:13:58] so using: [15:13:59] if (InPanel && PanelId == LMPANEL_LPDWINDOW) { [15:14:00] SetMeshVisibilityMode(dscidx, MESHVIS_ALWAYS); [15:14:15] yes [15:14:36] but that also will probably not work generally, because it depends on the panel you are on when it's loaded, right? [15:14:59] hmm [15:15:05] I don't really understand why this all is a problem in the first place [15:15:13] why do you have to load separate meshes for separate views? [15:16:21] well thats what was done before with LPD meshes [15:16:50] But thats one I am trying to get rid of and just play on the mesh visibilities of the ascent and descent stage meshes themselves [15:16:59] shouldn't it be possible to just work with the right view points and visibility flags? [15:17:33] the code might have been so old, that it preceeds these Orbiter API options, maybe [15:17:47] you mean have it set to MESHVIS_ALWAYS from the get go? [15:19:28] yeah, shouldn't that work? [15:19:45] I've not looked into it, I'm just confused why there need to be separates meshes for the LPD view at all [15:26:22] yeah I added that a year or 2 ago, but it was probably because I didnt understand the code enough to do it otherwise [15:26:47] but I think we can change it now to just play on the visibility flags of the ascent/descent stage mesh themselves [15:28:18] btw we could do MESHVIS_ALWAYS, but then the cockpit view without panel would be obscured by the mesh [15:28:29] well, it's just a theory of mine, I'm not really sure [15:28:32] you can try it if you want [15:28:48] I'm just seeing that the special code for it gets more complex and complex :D [15:29:29] well playing with visibility flags only is exactly the change I just did so that I can remove all the LPD meshes alltogether [15:29:31] I have only vague memories of you implementing it at first [15:29:53] and its working well on initial tests [15:30:06] wasn't there also an issue with ascent vs. descent stage? [15:30:22] or was that just caused by the LPD mesh being loaded at all [15:31:06] hmm I cant recall what issue that is [15:32:32] you probably implemented the LPD mesh and it was visible with the ascent stage [15:32:47] so we had to add more special code for gear not deployed and ascent stage config I guess [15:33:18] yes [15:33:52] today Ron might be getting the right MSC memo box... [15:34:16] or not, he has to give back any box he gets before getting a new one [15:34:38] so it might come down to Friday afternoon when he is "all done" with MIT/IL schematics [15:36:16] although, he already had one box, it was just the wrong one [15:36:22] so I don't know [15:36:30] monitors the email inbox for updates... [15:37:02] heres hoping [15:39:42] the old boxes being split up into 3 new ones each probably means that we will only get one of my top priority documents, but maybe all the other documents in that specific box as well [15:40:08] I just have about zero information on how TEI was actually targeted [15:40:17] especially finding the TIG of it [15:40:40] same with LOI really, but that calculation isn't as complicated, so we already a pretty good solution [15:40:58] and what we might get is info on TEI [15:41:10] well, any moon-centered return to Earth [16:20:19] Hi [16:21:57] hey, good afternoon [16:24:08] New lm looks great! Quick question, do you know if all the textures are working for it? Legs, foot pads, Hull body are all loading untextured in the same dull gray for me, but I see the new dds files are there [16:24:56] AlexB_88, that's your department [16:25:38] hmm they should be textured [16:28:28] According to my mesh debug anything supposed to be textured with the asc.dds or dsc.dds isn’t loading. Red foil.dds, goldfoil.dds etc loads tho [16:29:39] could any files be missing that Alex only has locally? [16:31:05] LMASC.dds and LMDSC.dds are both commited [16:31:16] yeah [16:31:19] it works for me, I think [16:31:28] legs, foot pads all have textures [16:31:56] lotisully86, do you have those 2 files in Textures/ProjectApollo? [16:32:09] Yes [16:33:04] It’s like they are being ignored tho [16:33:11] do you have the latest build? Build yourself or from Github? [16:34:05] Build myself, updated orbiter2016 last night [16:34:18] hmm [16:34:30] weird that it works for me then, it's all the same for me [16:35:14] "According to my mesh debug", in what way did you debug it? [16:35:39] my DX9 log has: (178: 10.3s 01.89ms)(0x2184) Texture 0x1A5C22E8 (ProjectApollo\LMDCS.dds) added in repository [16:37:06] Eh, I meant the default meshdebug module, the one that lates you highlight different groups and meshes in sim [16:37:45] ah, right [16:38:44] Any group that is supposed to be textured with the lmasc or lmdsc is defined as not textured [16:39:17] Checking dx9 log now [16:41:49] hmm, mesh debugger isn't working for me [16:43:32] it works with the default graphics client [16:44:24] My dx9 log does not list the new dds files being loaded... [16:44:48] weird [16:45:04] maybe try a rebuild of the NASSP solution [16:45:17] but the files are definitely there in your folder, right? [16:45:51] Ya I did that, and init a clean repo, same thing [16:45:56] Yes [16:46:14] weird [16:46:45] Save after build? [16:46:45] is this with a LM in descent or ascent configuration? [16:47:19] I doubt saving/loading will do anything [16:48:00] Descent haven’t tried ascent so far, have tried a few scn in lunar orbit and from tde [16:48:23] ok [16:49:41] open Meshes\ProjectApollo\LM_AscentStage.msh in a text editor [16:49:47] all the way at the bottom it has [16:49:50] TEXTURES 4 [16:49:51] ProjectApollo\LMASC.dds [16:50:16] that should be what defines the textures loaded for the mesh [16:51:55] Ya projectapollo\lmasc.dds then redfoil, ex’s and silverfo [16:52:02] ok [16:52:14] so it's all there, loading is just not working [16:52:26] I would expect there to be some error at least [16:52:36] in the DX9 log or somewhere [16:52:40] weird [16:53:07] could it be some visual setting? [16:53:08] Ya the other three dds files load just not the asc one [16:53:45] If tried tweaking them in the advanced tab, no effect [16:54:30] then I am out of ideas [16:54:41] AlexB_88, anything else? [16:55:52] hmm very weird I cant see what would be the problem [16:56:14] and why it would only happen to some [16:58:01] I just reinstalled the graphics client and have default settings gonna try it now [16:58:45] Yup same thing [16:59:24] is the LMASC.dds being loaded? [16:59:42] No [17:00:06] The mesh is just not the texture [17:01:03] https://i.imgur.com/4SFf4Hl.jpg [17:22:27] Could it be that it’s only loading the textures from my orbiter 2016 directory and not the beta directory?? [17:23:47] yes I think thats it! [17:24:13] Because of the beta d3d9 config file has the reference to the orbiter 2016 [17:24:17] one clue: your picture shows a descent stage with the old goldfoil textures [17:24:22] Yes [17:24:23] thats the iisue then [17:24:26] issue [17:24:51] the new textures are in the beta directory most likely [17:25:09] maybe you can copy them to the orbiter 2016 directory [17:25:15] anyways gotta run, cya! [17:25:22] So copy them to orbiter 2016 Ill try that [17:28:39] Success! [17:34:14] oh, that did it, haha [18:10:13] morning! [18:11:08] getting close to being back on a regular sleep schedule :P [18:11:59] hey Mike [18:12:17] what's up? [18:12:18] what stopped your regular sleep schedule? [18:12:34] still working on SCS control electronics [18:12:38] launching our satellite! [18:12:44] ah, right [18:12:59] that first day ended up being a ~23 hour work day and then I sort of transitioned onto night shift for initial operations [18:13:31] I actually had this weekend off, and managed to sleep from 6pm Saturday to 11am Sunday [18:13:40] haha, wow [18:13:56] I just get a headache from sleeping any longer than 9 hours [18:14:05] so I just never do that, however bad I need it :D [18:14:19] haha I didn't mean to [18:14:29] I was too tired to do anything else so I was in bed watching youtube videos [18:14:31] and then it was 11am [18:15:21] sometimes that happens [18:15:27] and suddenly it's almost Christmas [18:15:38] yeah I don't know how that happened [18:17:40] did you already hear that they put the MSC memos in new boxes? [18:17:50] yep! [18:17:54] and I think Ron got a new index? [18:17:59] I haven't looked at that yet [18:18:04] don't think there is one [18:18:12] but apparently the boxes are labelled [18:18:22] and the memos are in order [18:18:37] awesome [18:18:58] they still wanted to have an approximate box number [18:19:20] could be done with some crude math [18:19:36] so, maybe Ron will get the right box some time this week [18:21:35] my top 2 documents will likely not be in a single box anymore [18:21:58] so I just told him the number 1 document and hopefully we'll get that one and some other things from that specific box [18:22:28] how many MIT/IL schematics can there even be :P [18:32:34] Evening [18:36:18] hey [18:37:40] there are so many damn drawings lol [18:37:52] I could keep Ron there for months :P [18:38:52] me too [18:39:00] I was planning on keeping you there for months [18:39:05] but Ron got there first [18:39:18] hehehe [18:39:45] they likely have copies of all the checklists that were ever flown [18:39:50] that is one week long trip alone [18:40:28] yeah no kidding [18:42:28] how much do you know about the BMAG registers? [18:43:06] anything special about them or just registers like the other ones [18:44:09] it was in the requirements for the SCS through the end of the program that the GDC can supply body attitude rates to those registers, but even then training material says that they were never used and likely would never be used by any AGC software [18:44:20] even the* [18:52:40] hmmm [18:52:42] let me see [18:52:47] I definitely tested them at one point [18:54:00] oh they're the same counters as the RHC in the LM [18:54:57] except they bypass the "A" input circuit and just cause counts directly [19:00:23] oh right, that makes sense that the LGC doesn't have any BMAG counters [19:00:33] a severe lack of BMAGs in the LM for that [19:01:24] hehehe [19:11:26] I think I solved my texture issue [19:12:10] I removed the surrounding quotes [19:12:57] TextureDir = \Textures\", [19:13:01] on the Orbiter website [19:13:07] that's not very conclusive :D [19:13:22] probably should be changed [19:13:30] TextureDir = D:\Games\Orbiter 2016\Textures\ [19:13:31] " is bad I guess? [19:13:33] yeah [19:13:33] Yep [19:14:21] I mean. Quotes in paths are used all the time on Linux to support spaces. Otherwise it'd be split into arguments instead of a path with spaces. [19:14:37] I would've assumed the same was the case with Orbiter. [19:14:48] I guess it just reads whatever until the end of the line [19:15:05] yeah [20:06:24] Hmm [20:06:28] Got another issue [20:06:38] My 8-balls are full white. [20:06:54] They are just one white texture [20:07:14] they gave you cue balls instead :P [20:07:51] I don't need no FDAI. I'll just use noun 20. :p [20:26:42] afternoon [20:27:08] did lotisully86 get the LM textures working? [20:33:17] looks like fred18 replied to the forum post about animations [20:37:12] indy91, did you try setting the animation states to 0 in your test yesterday? [20:37:17] yeah, it was the Orbiter 2016 folder thinger [20:37:20] thing* [20:37:28] I did try that [20:37:32] yeah thats what I thought [20:38:49] a timestep before would of course work [20:38:57] but that's not really feasible [20:46:05] indy91: Any idea what could be wrong with my FDAI? [20:46:49] I have the feeling I've seen that before [20:47:08] do you have smooth FDAI enabled? [20:48:31] Tried it with it on and off [20:51:56] hmm [21:04:26] night! [12:28:08] hey [12:30:38] indy91, I pushed some updates to AnimationWork, I have simplified Meshes down to just Ascent Stage, Descent Stage, VC, and probes [12:30:48] hey [12:30:57] oh, good [12:31:12] and I will try to make probes part of the descent stage and hide the mesh group at contact [12:31:14] so getting rid of LPD meshes is possible? [12:31:20] yes and its done [12:31:28] I had to add a VC though [12:31:42] but that would probably done at some point anyway [12:32:42] you mean a mesh for the VC? [12:32:50] so how it works now is LPD ascent view is now the VC, and LPD descent ext and ret is now just playing with visibility flags on the descent stage [12:32:51] yes [12:32:53] did we not have that at all for the LM? [12:33:17] we just used the ascent stage mesh and made it visible in both outside and inside [12:33:24] ah [12:33:30] inside as in VC view [12:33:50] "LPD ascent view is now the VC" I don't understand what this means [12:34:02] can you not look outside on the 2D panel anymore? [12:35:50] https://github.com/jalexb88/NASSP/commit/ce60930cfdec4ba109f6719f1f0f715d4bfcec95 [12:36:03] void LEM::SetLMMeshVisVC() { [12:36:04] if (vcidx == -1) [12:36:05] return; [12:36:05] if (InPanel && PanelId == LMPANEL_LPDWINDOW) { [12:36:06] SetMeshVisibilityMode(vcidx, MESHVIS_ALWAYS); [12:36:07] } [12:36:07] else [12:36:08] { [12:36:12] SetMeshVisibilityMode(vcidx, MESHVIS_VC); [12:36:14] } [12:36:16] } [12:37:08] LPD_window view needs a different mesh then the regular ascent stage because of the windows, they have a hue to them on the regular model [12:37:17] my issue understanding is not on a code level, but on a general level [12:37:55] we are talking about the 2D panel LPD window view, right? [12:38:00] yes [12:38:07] what does the VC have to do with that [12:38:51] so that you can see part of the wall of the ascent stage, like what LPD_Asc used to do [12:39:06] let me just look at that in Orbiter [12:39:09] but instead of using LPD_Asc, it uses the VC [12:39:12] how it works righ tnow [12:39:55] I guess for me it was VC = 3D panel, but that's not really true [12:41:17] so with the ascent stage you can see part of the "nose" of the LM [12:42:11] what part of the VC would be visible? [12:43:33] I see you deleted the ClearMeshes. Does that fix the animation issues? [12:43:38] the nose, like it used to be [12:43:44] yes it does [12:43:47] so the VC meshes has a nose [12:43:51] mesh* [12:43:58] I have extensively tested that all around actually [12:44:01] yes [12:44:15] I have made a VC mesh out of the ascent stage mesh [12:44:26] and you can not see the ascent mesh? [12:44:27] Ill show you what it looks like on my blender screen [12:45:16] https://www.dropbox.com/s/w0psnowv6wb3ucr/Screenshot%202018-12-18%2007.44.54.png?dl=0 [12:45:36] I have set the ascent stage mesh to external [12:45:59] what is the problem with setting the ascent stage mesh visible? [12:46:29] and the VC has what visibility setting? [12:47:06] Ill show you [12:47:43] https://www.dropbox.com/s/452qi2zzipyrrr3/Screenshot%202018-12-18%2007.47.35.png?dl=0 [12:47:55] oh, haha [12:47:59] is that the window? [12:48:04] this is the function for the VC visibility setting: [12:48:18] I guess adjusting the view point would be wrong [12:48:25] yeah, I see the issue now [12:48:27] if (InPanel && PanelId == LMPANEL_LPDWINDOW) { [12:48:28] SetMeshVisibilityMode(vcidx, MESHVIS_ALWAYS); [12:48:29] } [12:48:29] else [12:48:30] { [12:48:30] SetMeshVisibilityMode(vcidx, MESHVIS_VC); [12:48:58] and where is that called? [12:49:44] when the VC is created and everywhere the LPD stuff used to be called [12:49:55] LEM::clbkLoadVC [12:49:56] clbkLoadPanel [12:50:15] and for VC [12:50:17] yes, I like that [12:50:26] and clbkLoadPanel [12:50:29] yes [12:50:35] I don't understand it all, but I don't have to, good job I guess :D [12:51:06] VC mesh is never visible outside? [12:51:52] hmm [12:52:00] I think it can be done even better [12:52:23] only visible from the VC [12:52:27] sure [12:52:49] what you want is to make it visible in VC and 2D panel, right? [12:52:55] the VC mesh [12:53:16] you can "stack" the mesh visibility options [12:53:19] e.g. [12:53:43] SetMeshVisibilityMode(mesh, MESHVIS_COCKPIT | MESHVIS_VC); [12:53:51] makes it visisble in cockpit and VC only [12:54:04] would that be helpful? [12:54:11] or do you need the LPD panel specific code [12:54:22] theres one issue with that though, th VC would be visible when you are in cockpit, but no panel showing [12:54:48] oh wait, is MESHVIS_COCKPIT all cockpit views already? [12:55:01] yeah [12:55:02] yeah, right [12:55:17] including no panel and just the regular screen with the 2 MFDs [12:55:27] right [12:57:10] DG doesn't care about any meshes on the 2D panel, but that is because it also has a functional VC [12:57:21] for us the 2D LPD panel is the default [12:57:30] so the goal is to make that view decently realistic [12:57:42] I mean I could just do it that way [12:57:51] it wont bother me [12:58:00] on my 16:10 monitor I actually have to scroll to even see the "nose" [12:58:07] haha [12:58:21] just a tiny bit, but by default I see no mesh [12:58:43] I see the descent stage of course [12:58:54] I wonder if I can do something to make that better [12:59:24] only a separate panel bitmap would solve that I think [12:59:45] maybe I can show find you some good deals on 16:9 monitors :D [12:59:48] like the CSM telescope/sextant views [13:00:06] my Christmas budget is already going to a mobile phone, too late :D [13:00:10] ah yeah I can do that [13:00:16] haha [13:00:21] not worth the effort really [13:01:14] So what do you think of this new way of doing things for meshes, without the ClearMeshes? I have tested this quite a bit so far and made sure that the DelMesh does not screw up the mesh index order [13:01:33] it's feasible because you reduced the number of meshes [13:01:36] I see no issue [13:01:42] great [13:01:55] and I can reduce it even more by taking the probes out of the equation [13:02:09] I posted a question on the forums about hiding mesh groups [13:02:15] right, and you got an answer [13:02:30] with oapiEditMeshGroup() [13:03:09] so I think I will add the probes to the descent stage, animate them with the gear deploy, then hide it at contact [13:03:35] sounds good [13:03:57] so, we can not only get rid of one the pre and post gear deployment functions [13:04:04] but also the landing one [13:04:19] which is smaller and doesn't modify it much [13:04:33] oh [13:04:38] I think you overlooked that one so far [13:04:43] ClearMeshes(); [13:04:46] it still has this [13:04:53] maybe you changed that since [13:04:58] LEM::SetLmLandedMesh() [13:05:25] I took it out of there too [13:05:38] ah, good [13:05:59] this is what it is now: [13:05:59] void LEM::SetLmLandedMesh() { [13:06:00] DelMesh(probeidx); [13:06:01] probeidx = -1; [13:06:01] Landed = true; [13:06:02] } [13:06:27] haha [13:06:32] rather simple [13:07:13] yeah [13:08:04] so maybe my branch is pretty stable right now, maybe I can PR what I have, then ill work on the new probes, what do you think? [13:08:22] so my branch is pretty stable* [13:08:51] yeah, seems like you did a thorough job [13:09:59] well I made sure to test everything as I went and fixed things one by one [13:10:32] good approach :D [13:10:41] I guess im really motivated for others to see the nice animations haha [13:11:08] yeah, like me [13:11:26] I'll try some antenna auto tracking after my SCS work [13:11:58] great [13:13:25] I'm mostly done with reworking the current ECA functionality [13:13:36] however, all the SCS TVC logic should be in there as well [13:13:41] currently it's in SPS code [13:13:44] so I'll move that [13:14:17] ok [13:15:20] ok I am about to PR my AnimationWork branch [13:17:13] 725 files changed, hmm I didnt change that much :D Oh of course I need to change the base fork from Master to Orbiter 2016 [13:17:20] haha [13:17:23] yes you do [13:17:27] 23 thats better [13:17:45] well a lot but better [13:17:59] just double checking it now [13:19:00] looks good [13:19:16] PR sent [13:25:17] ah right, I had only added the animations files in your branch [13:25:39] what about animation state saving, is that already done? [13:26:17] the AnimState2 code is blatantly stolen from the DG, but it's example code and very generic code anyway, so I think it is ok [13:27:00] merged [13:27:18] animation state saving is still not yet done [13:28:03] well, for the hatches [13:28:11] and gear [13:28:42] well the gear, it might not be needed because if you save during deploy, it will just reload ad deployed [13:29:22] but for the rest, RR, Steerable... dont think its needed [13:34:51] 3000 commits since NASSP 7! [13:36:19] yay [13:52:09] something is very wrong [13:52:35] oh [13:52:38] just VS being bad [13:52:51] when I switched branches it had all the files open twice somehow [13:53:03] so it showed e.g. "sps.cpp 1" and "sps.cpp 2" [13:53:14] lol [13:54:52] I first though all files got duplicated somehow [13:54:55] thought* [14:48:13] Making new contact probes [14:48:41] https://www.dropbox.com/s/9o5t7mk4ntr7mxi/Screenshot%202018-12-18%2009.48.34.png?dl=0 [15:05:04] nice [16:53:38] probe animations coming along nicely [17:12:35] got it working nicely, the probes are folded into the proper position before extension and come into position nicely during the extension [17:16:49] great [17:18:28] now Im ready to do part 2 of this which is hide the probes at contact [17:20:07] I guess ill have to delete the probe animations in the destructor too [17:20:19] and the eventual DPS animations [18:13:23] ooh the DeltaGlider has lots of examples for hiding mesh groups [18:14:03] https://www.dropbox.com/s/2c8j1cq5uurh2hz/Screenshot%202018-12-18%2013.13.57.png?dl=0 [18:23:12] that's useful [18:27:18] hows this? Its under DefineAnimations in EDS [18:27:19] https://www.dropbox.com/s/g2rbbafvsu5x25t/Screenshot%202018-12-18%2013.26.51.png?dl=0 [18:27:30] except I get that error [18:27:45] probably just missing something obvious [18:33:02] why the &? [18:33:13] and it doesn't have to be static UINT [18:33:52] ok took them out [18:34:00] hm [18:34:01] still gives me the error [18:34:04] maybe it needs to be static [18:34:30] but it doesn't need the & [18:34:35] the DG example has it as static [18:34:36] ok [18:35:45] removing the & works? [18:36:43] hmm no [18:37:03] weird [18:37:07] what error? [18:37:29] the mesh groups don't need the address [18:37:37] it should still be &ges [18:38:46] yes [18:38:54] its the same error as the screenshot above [18:40:10] difficult to believe [18:40:42] oapiEditMeshGroup(idx, &meshgroup_Probes1[i], &ges); [18:40:47] oapiEditMeshGroup(idx, meshgroup_Probes1[i], &ges); [18:41:28] oh wait [18:41:31] idx [18:42:06] it doesn't take an int there [18:42:21] it wants a mesh handle [18:42:25] not the ID of it [18:43:30] oh [18:44:29] so DEVMESHHANDLE probes = idx; [18:44:44] then oapiEditMeshGroup(probes, meshgroup_Probes1[i], &ges); [18:44:49] that seems to do it [18:44:56] very, very wrong [18:45:08] that's like doing apples = oranges; [18:45:20] lol [18:48:17] should I send it the static MESHHANDLE hLMDescent; variable? [18:49:11] hmm, maybe [18:50:03] no, probably not [18:50:14] the problem is that the mesh might not even be loaded [18:50:28] when you are e.g. in the CSM and far away from the LM it doesn't render the LM [18:51:46] if you edit the general MESHHANDLE then it probably would do the operation with all LMs in the simulation [18:54:59] right [18:56:06] I've never done any stuff with MESHHANDLE and VISHANDLE, which you seem to need [22:54:24] .tell indy91, I think I figured it out for hiding the probes, I pushed my latest state let me know what you think: https://github.com/jalexb88/NASSP/commit/cf5b02458dcd5a2aba03a35e7f6c388be53194d3 [11:42:50] h [12:06:56] hey [12:09:07] hey Niklas [12:09:37] you've gone far beyond my understanding of this all, haha [12:10:26] I had to scout the DG code a lot to figure it out [12:11:01] but basically, I had to add this to the LEM.cpp [12:11:01] void LEM::clbkVisualCreated(VISHANDLE vis, int refcount) [12:11:02] { [12:11:03] probes = GetDevMesh(vis, dscidx); [12:11:03] if (Landed && !NoLegs) { [12:11:04] HideProbes(); [12:11:06] } [12:11:08] } [12:11:35] clbkVisualCreated is called last of the callback functions, I guess [12:11:46] after loading etc. [12:11:49] and then in the HideProbes() function, probes is used in oapiEditMeshGroup() [12:12:24] I am not sure if thats was required though, maybe I could of added that to a function already there? [12:12:47] the clbkVisualCreated I mean [12:13:17] you mean do the oapiEditMeshGroup() in clbkVisualCreated()? [12:14:29] I had to give the DEVMESHHANDLE probes a VIDHANDLE and that was done in clbkVisualCreated() [12:14:37] probes = GetDevMesh(vis, dscidx); [12:14:42] yes, I think that's right [12:15:02] and Im curious if I could have done that without adding clbkVisualCreated() itself [12:15:11] no, I don't think so [12:15:18] because of how the mesh loading is handled [12:15:22] it's a bit like MFDs [12:15:23] ok so I added it and I guess thats correct [12:15:35] anyways it works well [12:15:37] the whole MFD gets destroyed and reloaded just by closing/opening it [12:15:52] similarly that is possible with the mesh instance [12:16:34] right [12:16:45] so it needs to be handled whenever clbkVisualCreated is done [12:17:23] one thing though, the DG has the probes set to NULL in clbkVisualDestroyed function which is right under [12:17:45] well in the DG's case, not probes but vcmesh [12:17:46] yeah [12:17:55] sounds like a safe thing to do [12:17:57] I just set it to NULL in the destructor [12:18:06] but maybe I should do that [12:18:10] yeah, do that [12:18:13] ok [12:18:34] I also set it to NULL in the init [12:18:42] but dont know if that was required though [12:19:05] it's a safe thing to do [12:19:12] right [12:19:19] when you don't do that then the variable has a random value [12:19:38] as always, better causing a hard CTD than undefined behavior [12:19:47] yeah [12:23:40] implementing a RHC class right now [12:23:47] cool [12:24:01] just makes sense to use that instead of having to handle the joystick position in int all the time [12:24:34] so e.g. the ECA can call rhc.getProportionalRate() [12:24:52] here is one interesting thing about Manual TVC [12:25:06] not only Auto TVC, but also MTVC has an integrator [12:25:13] only used when the engine is actually on [12:25:42] I think you need to keep the RHC to a certain deflection for a docked SPS burn [12:25:47] in Rate Cmd MTVC [12:25:57] with the integrator that isn't necessary [12:26:29] so you will only have to do RHC deflections to actually change the attitude [12:26:45] and not keep it in a certain deflection all the time [12:28:30] that makes it very similar to SCS Auto TVC, but it doesn't try to keep the attitude at which the BMAGs were uncaged [12:28:33] BMAG* [12:29:26] so where Auto TVC is basically a PID controller, MTVC is a D controller before ignition, and a ID controller during a burn [12:33:59] like the inertial attitude hold you spoke of [12:38:03] inertial attitude hold? [12:38:45] something about that during docked burns with auto TVC [12:44:41] yeah [12:44:46] anyways I have only found one issue so far with the mesh changes. If I load a NoLegs scenario before gear deploy, the LM displays properly with no legs, even if I fire the gear deploy pyros. However, if after I fired the pyros I save and reload, when I reload the scenario the LM is now has the legs [12:44:57] our Auto TVC also has no integrator part yet [12:45:34] how is NoLegs handled [12:45:44] not by hiding the mesh, right? [12:47:04] oh, this could be a bad issue actually [12:47:20] its set to false in the init, then loaded in GetScenarioState. Then it is read in lemmesh by [12:47:20] if (NoLegs) [12:47:21] { [12:47:22] dscidx = AddMesh(hLMDescentNoLeg, &mesh_dsc); [12:47:22] } [12:47:23] else [12:47:23] { [12:47:24] dscidx = AddMesh(hLMDescent, &mesh_dsc); [12:47:26] } [12:47:28] SetLMMeshVisDsc(); [12:47:41] unfortunately that is not what happens after gear deployment [12:47:48] in SetLmVesselDockStage [12:47:55] because it doesn't reload meshes anymore [12:48:20] the mesh is only loaded in SetLmVesselDockStage [12:48:27] not in SetLmVesselHoverStage [12:48:55] SetLmVesselDockStage is always called first anyway [12:49:02] yeah [12:49:03] but before loading parameters like NoLegs [12:49:09] right [12:49:36] but for everything else, the meshes right [12:50:05] so maybe I can add an if (NoLegs) in SetLmVesselHoverStage [12:50:28] to do what? [12:50:33] the wrong mesh is already loaded [12:51:24] no, no. I think this is the point where the whole LM loading thing needs to be reworked [12:51:25] let's start that today [12:51:57] ok [12:52:14] in the mean time Ill PR my contact probes stuff [12:53:15] yeah, that PR is not what is causing the issue [12:53:25] pretty sure it will also happen in the already commited state [12:53:41] just by not clearing all the meshes in SetLmVesselHoverStage [12:55:03] what it come down to is merging the two descent stage defining functions [12:55:21] thats what I had in mind too [12:55:23] and moving some stuff that depends on loaded parameters like NoLegs to PostCreation [12:55:40] but I guess one challenge is all the stuff that rely on the stage parameter [12:55:57] that's what clbkPostCreation was added for [12:58:38] hmm [12:58:52] and of course you can do it in the loading function, just after all the parameters have been loaded [12:59:03] we just do it twice right now, which is bad [12:59:40] PR sent [13:00:41] you will notice there is still a separate contact probes mesh, but it is now only used by the staged descent stage project (Sat5LMDSC) [13:10:23] merged [13:11:50] thanks [13:12:02] you should look at a gear extension after you rebuild :D [13:23:14] I always manage to load a scenario in darkness... [13:25:12] haha [13:26:10] looks great [13:27:58] thanks [13:28:14] too bad most people will miss the animation, haha [13:31:09] yeah lol [13:39:48] I think I should slew my Steerable [13:40:59] yes [13:41:06] you are lacking auto tracking [13:41:08] my fault really [13:45:24] you are almost as young as me now [13:50:14] and back to 88, did the full circle [13:57:13] thinking about what the best method is for the new LM loading [14:03:20] the solution is probably to put all the common code in the two descent stage functions in a sub function [14:03:42] and add a separate function with everything that is common to all states of the LM, which is the one called in clbkSetClassCaps [14:25:06] right [14:26:16] while you work on that, on my end I will change the drogue animations to drogue mesh group hiding like what I did with the probes [14:26:26] Ill leave the overhead hatch animated though [14:28:47] and I will look in to the save/load of the AnimState2 stuff [14:29:57] in a way you made it worse with your changes to the LM defining functions [14:30:12] because the LM was always created from scratch in all 3 [14:30:39] now the gear deployed/ascent stage functions only have partial definitions [14:41:01] and SeparateStage also has become a bit mad [14:53:29] yeah, this will not be easy or quick to untangle [14:55:41] hmm cant figure out a way to get NoLegs to be called before the 1st call to SetDockStage? [14:58:43] and what do you eman by partial definition? [14:58:47] mean* [15:49:05] before e.g. SetLmVesselHoverStage would define everything belonging to that state [15:49:16] descent config with legs deployed [15:50:07] now SetLmVesselHoverStage() doesn't add all the meshes [15:50:17] right [15:50:23] but instead SetLmVesselDockStage() is doing that, which is called in any case [15:50:30] but it doesnt need to though right? [15:50:31] and SetLmVesselHoverStage() just deletes some meshes [15:50:41] except of course in the case of nolegs [15:50:59] well as it stands, SetLmVesselDockStage() needs to be called, even without the NoLegs issue [15:51:14] because nothing else is actually loading meshes [15:51:18] right [15:51:52] but I think its loading DockStage 1st all the time, right? [15:51:56] yes [15:52:51] and that was my understanding of it too [15:53:21] but that's causing some other issues actually [15:53:44] oh really? [15:53:47] had to add some bad code so that when the LM is created from the S-IVB it could give DPS propellant mass to the new stage [15:54:08] because it was always overwriting that [15:54:59] first the LEM object is created by the S-IVB [15:55:09] hmm but that has nothing to do with meshes? [15:55:16] no, it doesn't [15:55:31] but if we want to rework the LM loading functions, that's one of many things to consider [15:55:37] ah I see [15:57:28] now I am a bit confused about the order of things [15:57:37] LM is created in a S-IVB function [15:57:48] I think then it automatically does clbkSetClassCaps [15:58:14] and then the "SetupPayload" function is called, which is giving the parameters like the padload from the S-IVB to the LM [15:58:31] clbkSetClassCaps has already defined the DPS propellant at that point [15:58:50] and creating the DPS propellant form scratch again would screw up to the order [16:06:18] kind of surprised the order is not bad as it is right now [16:09:26] yeah [16:09:41] in the ascent stage code [16:09:51] it creates the APS first and then deletes the DPS [16:11:43] oh, I see [16:11:58] it's calling SetLmVesselDockStage() first again [16:12:29] that's how the APS always ends up last, despite in the SetAscentStage function it being before the RCS [16:12:43] yet another thing to consider [16:14:28] hmm [16:14:39] I could just move to SetLmVesselDockStage() SetGenericStageState() [16:14:50] SetLmVesselDockStage() to SetGenericStageState()* [16:15:24] it would still be called first [16:15:30] which can be improved over time [16:15:35] but it would use the loaded parameters [16:15:49] I'll try how that works [16:20:02] pretty good [16:20:12] that might be our short term solution [16:20:19] would really rather work on the SCS... [16:21:40] so pretty much all of the LM would only be defined after loaded [16:21:47] right [16:22:29] I'll try a few things with that [16:24:54] hmm, not everything works right with that [16:25:02] I just invented a new spacecraft [16:26:37] I call it the Lunar Command and Service Excursion Module: https://i.imgur.com/btPLNtQ.png [16:26:58] who needs lunar orbit rendezvous anyway [16:32:24] haha [16:35:37] must be a problem with the docking ports [16:36:12] yeah, the S-IVB tries to dock the LM to the CSM [16:36:20] and the LM doesn't have a docking port yet [16:45:28] next try [16:46:10] now the LM gets spawned with gear deployed... [16:48:32] maybe its the if (stage < 1 && !NoLegs) eds.DefineAnimations(dscidx); [16:49:21] the LM should have stage 0 though [16:51:16] reloading fixes it [16:52:42] can you try a LM extraction on your end as well? [16:52:45] or have you tested that [16:54:18] yes [16:56:28] doesn't happen on your end? [17:06:43] no it doesnt, legs are retracted on the spawned LM [17:07:38] but in your picture above, SBand is still in the mesh default position, so that tells me that I think no animations are defined at all, including the legs which would need them defined to show retracted [17:32:08] yeah, I think it's the mesh indizes [17:34:03] even if the meshes are only loaded after scenario loading, PostCreation should still be later though [17:36:14] hmm [17:36:17] it's not though [17:37:31] ah [17:37:43] the problem is that the LM is created in code [17:37:45] and not loaded [17:38:12] it does clbkPostCreation before the S-IVB calls SetupPayload [17:39:01] that's... not good [17:42:24] SSU is doing the animation definitions after loading [17:42:30] not in post creation [17:57:54] morning! [17:59:41] hey [17:59:55] what's up? [18:00:12] inventing new spacecraft [18:00:21] https://i.imgur.com/btPLNtQ.png [18:00:28] the Lunar Command and Service Excursion Module [18:02:19] oh dear [18:02:33] well as long as you get John Young to fly it I'm sure it will work [18:02:52] oh yeah, that will be no problem [18:03:00] might be tricky with the two DAPs fighting each other [18:03:16] lol [18:03:36] basically, at LM extraction, the LM gets created, together with the docking port, and then gets docked with the CSM [18:03:41] I was messing with the order of things [18:03:54] so it tried to dock CSM+LM before the LM had a docking port defined [18:03:57] so it did this [18:04:05] created the LM exactly where the CSM also is [18:04:50] makes sense :D [18:06:54] AlexB_88, got it working [18:07:05] by yet again moving where the animations are defined [18:07:21] LEM::DefineAnimations called by LEM::PostLoadSetup [18:07:37] ok [18:07:43] PostLoadSetup is kind of like PostCreation, just not a Orbiter callback function [18:07:48] gets called directly after loading [18:07:55] and I got the DPS moving :D [18:07:57] and also in the SetupPayload code [18:08:17] so I just had to add the new DefineAnimations there [18:08:20] oh, awesome [18:09:11] well "moving"... is it in the right direction? Well thats another story haha [18:09:31] but its a start [18:09:48] this is what im using: dpsgimball_proc[0] = pitchGimbalActuator.GetPosition() * RAD; [18:10:03] hey, not even Grumman + MIT got the direction of it properly right [18:10:18] there was a software issue early on related to that I believe [18:10:29] oh lol [18:10:31] + and - confused [18:12:19] yeah, that is a good function to use [18:16:55] ive got it working, but I think I need to get the signs right [18:17:31] do a gimbal drive test [18:17:40] and then start the engine :D [18:18:21] and the gimballing travel seems too high, so I can probably fix that in MGROUP_ROTATE. But the high gimbal travel makes it easy to test visually [18:18:34] I did already [18:18:57] yeah, 6° should be easy to see [18:21:19] I'll do a bit of testing, but moving the SetLmVesselDockStage() call to post loading is definitely a good idea [18:21:31] gets rid of some messy code and fixes some bugs [18:22:09] great [18:22:26] Ill do lots of testing once its done of course [18:22:30] the only thing that had to be kept in the old place is the docking code [18:22:44] or the docking port definition rather [18:23:08] might be good to move some stuff back to clbkSetClassCaps eventually [18:23:52] anything that will never depend on any loaded variables can go there [18:25:15] because you added new animation code there will definitely be a merge conflict though. Whoever merges their work next will be the one who doesn't have to deal with it [18:26:55] I volunteer for dealing with it, haha [18:27:06] so I'll wait until you have done your next PR [18:27:53] thewonderidiot, I read that the erasable memory module got X-rayed [18:28:20] hmm I only added one line , LEM.cpp [18:28:26] to LEM.cpp* [18:28:39] the rest is is lm_dps.cpp [18:28:55] I moved the animation definition code out of PostCreation [18:28:56] indy91: https://drive.google.com/drive/folders/1PqwWqoB2p-wjCEGi5PR5UYYsj58N9VaP?usp=sharing [18:28:58] definitely a conflict [18:29:42] is your repo up to date with my PR this morning? [18:29:49] yes [18:30:15] so I only added DPS.DefineAnimations(dscidx); to PostCreation since that PR [18:30:16] there will be a conflict once you do a PR with your DPS gimballing, it gets merged and I have to merge it locally [18:30:27] that's when the merge conflict will happen [18:30:38] easy to solve of course, but still, definitely going to happen [18:31:01] thewonderidiot, looks pretty detailed, but still not conclusive, right? [18:31:28] Im still working on it tbh so Id say just push your stuff 1st [18:31:29] yeah, can't see any breaks :( [18:31:44] AlexB_88, ok, pretty much done, just a bit more testing [18:32:17] where do you expect the break again? A wire directly at a core? [18:32:35] no, at the fiberglass side board [18:33:00] so, here: https://i.imgur.com/hE2wIPk.jpg [18:33:13] it'd be one of the two wires on the left, or the one on the right [18:34:25] hmm [18:36:25] if you knew where it is, then it still would be tricky to fix it, right? [18:39:53] if it's inside the core stack then it's impossible [18:39:57] here would be tricky but doable [18:40:10] ok [18:41:09] finding another module can't be so difficult. Convincing them to let you use it on the other hand... [18:41:44] yeah [18:41:50] that is the problem [18:45:22] I heard there is one in the Tonga Trench [18:52:46] indy91, I think I got the code for the gimballing set up right, but the weird thing is there seems to be an insanely high travel distance of the engine bell [18:52:56] like up to 30 degrees [18:53:29] and I think the culprit might be the value supplied by pitchGimbalActuator.GetPosition() [18:54:07] like theres no limiting in that value like the RR and steerable had [18:54:22] or maybe it needs scaling [18:55:05] ah maybe /P12 [18:55:34] instead of * RAD [18:55:48] PI2* [18:58:23] lol not PI2 [19:07:49] it returns degrees [19:08:00] so the *RAD should be right [19:08:13] in radians that is [19:08:29] what travel angle did you use in the definition? [19:09:30] of the animation [19:09:59] 360 [19:10:08] RAD * 360 [19:10:25] with a lem->CreateAnimation(0.0); [19:11:29] RAD*360 is PI2 [19:11:32] so just use P2 [19:11:34] PI2* [19:11:42] but I know the problem [19:12:06] the 360° have to be 0 to 1 for the SetAnimation, right? [19:12:12] so that is revolutions, not radians [19:12:15] so not *RA [19:12:17] *RAD [19:12:25] but instead /360 [19:12:54] so pitchGimbalActuator.GetPosition() / 360? [19:13:07] yep [19:13:23] and then the check on negative angles of course, but you probably already have that [19:13:34] 1 rev = 6.283 radians [19:13:37] 2*pi [19:13:50] so the max angle you probably had was 6x that [19:13:55] above 30°, yeah [19:15:23] ca marche! [19:16:57] ok I am happy with it I can PR it now if you want [19:19:00] haha [19:19:05] just pushed my update right now [19:19:34] so you have some merging to do first [19:19:44] well the conflict is only 1 line [19:20:01] yeah [19:20:15] might appear in two places though, because of the new function [19:20:42] so Ill just merge yours, then place my DPS animations call along with the others in the new function you created [19:21:42] yep [19:29:06] and my PR is sent [19:34:05] merged [19:39:32] thanks [19:39:40] testing the new LM changes [19:40:29] NoLegs is now working right [19:53:32] yeah, it's executing the DockStage function after loading, that did it [19:53:46] and made the custom DPS prop mass easier [20:04:52] looking at AnimState2::SaveState stuff now [20:33:37] cya! [22:13:19] .tell indy91 Fixed my FDAI. NASSP loads Textures directly from the Texture dir and does not honor the TextureDir from the Orbiter config. Worth a discussion. [22:35:18] .tell indy91 The FDAI code also doesn't do anything if the texture fails to load. I'll add some error checking to that. [13:01:20] hey [13:01:58] hey Alex [13:03:38] there is an Orbiter API function we might be able to use for that [13:03:50] Alex, how did you manage to get a Surveyor mesh in the PR? :D [13:06:58] haha that was the mesh I downloaded from orbithangar [13:21:55] btw is our initial position for the SBand steerable correct? [13:22:16] compared with the pic: https://www.facebook.com/146600305410052/photos/a.264968853573196/1914903835246348/?type=3&theater [13:25:18] ours does not seem to be in that position visually [13:28:09] https://www.flickr.com/photos/projectapolloarchive/21710770101 [13:28:15] same one, probably higher quality [13:30:32] our Antenna starts at -75° pitch, -12° yaw [13:31:38] looks quite different indeed [13:32:16] to me it should be more like 0 pitch [13:32:23] Hey [13:32:25] indy91: [13:32:50] indy91: Yeah, only thing with the API I might imagine is that git will still make a Texture folder. [13:33:07] But that's more of a dev issue really [13:34:22] there are functions like oapiLoadTexture [13:34:31] but the FDAI code seems to do it very manually [13:34:33] AlexB_88, found something [13:34:38] in the AOH Volume II [13:34:44] Yeah it just fopens the dds files [13:34:46] it's different for Apollo 12 and later [13:35:09] "PITCH cont - +255° (LM 6 and subsequent is -75°)" [13:35:17] Also, D3D9 client got an update. It will now display the texture folders it wants to use and if it can find them or not. [13:35:19] "YAW cont - +0° (LM 6 and subsequent is -12°)" [13:35:45] Thymo, yeah, that's going to be useful for people who have the same issue as you [13:37:39] AlexB_88, should w emake -255° and +0° the default? [13:38:35] hmm maybe we should leave it to what the majority of the missions had [13:39:45] we can deal with it once we have better code for mission specific stuff [13:40:25] yeah [13:40:43] another weird thing is +255 still doesnt look like the pic [13:44:37] There's indeed an oapiLoadTexture. [13:44:51] It returns a SURFHANDLE though, not a FILE*. [13:46:09] Hmm. Looks like a SUFHANDLE is a void pointer. [13:46:43] AlexB_88, I think the animation isn't right [13:48:31] the slew controls have little markers for e.g. +X etc. [13:48:35] try those, it doesn't add up [13:49:37] maybe just a wrong sign? [13:49:55] could be [13:50:48] I played around with the antenna before [13:50:56] during PDI it seemed to point in the right direction [13:51:49] you sure you got the zero position right? [13:54:44] 0/0 should be pointing forward [13:54:51] which it definitely doesn't [13:55:23] looks like it's 90° off in pitch [13:55:53] well its just reading values SBand code [13:55:58] sband_proc[0] = pitch / PI2; [13:56:14] I think the default mesh state is wrong [13:56:26] of course that could be fixed in code [13:56:33] but probably better to have the mesh right [13:56:55] yep, wrong by 90° [13:57:29] where is the antenna pointing in the mesh? [13:57:47] straight up [13:58:24] Ill change it [13:58:33] yeah, you need to rotate it by 90° [13:58:43] sure [13:58:44] so that it is almost pointing forward [13:58:51] not 100% forward, needs a bit of yaw [13:59:50] oh oh [14:00:32] animation seems to be broken when I reload from a scenario [14:01:45] somehow all animations are broken right now [14:02:28] hmm [14:02:42] I think I only broke the steerable by bad code [14:02:48] and the rest doesn't do saving/loading [14:10:03] still not quite right though [14:10:19] doesn't point in the right axis directions as indicated with the labels [14:14:11] how did the animations break? [14:14:38] It appears the FDAI uses OpenGL with the texture [14:14:59] RR snapped into position [14:15:03] the right one I think [14:15:18] maybe it didn't update for some reason [14:19:16] hmm [14:19:30] something is still off [14:21:45] in what way? [14:22:37] actually no, I was reading the label too literally [14:22:48] pointing +Z is exactly 0/0 angles [14:22:58] not a small negative pitch [14:23:45] +X is +90° pitch, -45° yaw [14:26:18] so is is it just a 90 pitch change for the mesh? [14:26:21] oy yaw as well [14:26:24] or* [14:27:10] I got it now [14:27:26] make it point forward in the default mesh [14:27:30] and then [14:27:43] -pitch and -yaw in the timestep [14:28:03] ok [14:28:04] but that can lead to animation state greater than 1 [14:28:11] so I added [14:28:12] if (sband_proc[0] > 1) sband_proc[0] -= 1.0; [14:28:16] if (sband_proc[1] > 1) sband_proc[1] -= 1.0; [14:28:52] the other thing we could of done is reverse the yaw axis in the animation code [14:29:17] ah right [14:29:19] let me try that [14:30:09] how do you do that again? :D [14:31:17] can I use -360° angle? [14:33:15] Can the Orbiter API be used to just load whatever a handle is pointing too? [14:35:06] in the MGROUP_ROTATE, 2nd last item [14:35:19] _V(0, 0, 1) to _V(0, 0, -1) I think [14:35:29] using -360° range actually works as well [14:35:42] Thymo, can you give an example? I'm not quite sure what you mean [14:37:24] AlexB_88, it's not necessary to do that anyway once the mesh is fixed [14:37:38] im working on it now [14:37:41] we can just use the -pitch and -yaw [14:37:46] very easy fix [14:37:58] just in my code where I used a 90° offset to get it right the animation state could be > 1 [14:38:20] Currently the FDAI textures are just opened and read into memory using the FILE struct. If I use oapi it gives me a SURFHANDLE. The code currently loads the bitmap into memory and does stuff with it using OpenGL. I can't do that with a SURFHANDLE. [14:38:57] And I don't really feel like rewriting the FDAI to replace OpenGL. [14:39:50] the oapi function might have the right texture path automatically, maybe there is away to get that in another way [14:39:59] a way* [14:40:52] Parsing Orbiter.cfg? Sounds dirty. [14:41:01] another API function I mean [14:42:43] how can it be in another directory anyway? [14:42:56] did you manually move the NASSP texture folder? [14:44:48] I now have a separate Texture folder in my Beta install with the NASSP textures [14:52:05] indy91, theres just one thing about having the SBand mesh pointing forward: The yaw rotation axis is no longer 0,0,1 but now needs a formula like the one or the pitch axis [14:52:18] since the yaw rotation axis is now also tilted 45 degrees [14:52:28] There doesn't appear to be such a function in the APPI [14:52:34] API* [14:52:34] the one for pitch is cos(RAD * 45),-sin(RAD * 45), 0.00 [14:52:47] AlexB_88, no, that can't be right [14:53:25] the axis haven't changed at all [14:53:29] axes* [14:53:48] the default rotational state of pitch is just wrong, nothing else [14:53:58] maybe we should just solve that in code [14:53:59] right [14:54:08] if it is difficult with the mesh [14:54:17] ok I think I was thinking it wrong [14:54:22] no its not its already done [14:55:00] https://www.dropbox.com/s/59thfv84fwihmz0/Screenshot%202018-12-20%2009.54.49.png?dl=0 [14:55:07] just needs a rotation around the already existing axis [14:55:44] how did you rotate it? [14:56:08] it needs a rotation around the pitch axis [14:56:11] 90 degrees [14:56:14] pitch [14:56:16] yes [14:56:26] so around the actual S-Band axis [14:56:31] antenna axis* [14:56:32] yes [14:56:40] ok [14:56:43] its still tilted 45 [14:56:55] https://www.dropbox.com/s/vmmmcb4g1f2x9tw/Screenshot%202018-12-20%2009.56.47.png?dl=0 [14:56:55] try that with -pitch and -yaw then [14:58:21] and try the +/- X, Y and Z axis as on the labels [14:59:15] looks right in the mesh [15:02:55] hmm no the axis are all screwed now [15:06:19] well yax axis is screwed [15:06:23] pitch is fine [15:07:12] screwed in what way? [15:08:41] say with the SBand at 0 degrees pitch, pointing forward: If I yaw right, it does not rotate on itself, it rolls right [15:09:01] hmm, ok [15:09:10] must be your mesh change [15:09:40] it can be solved in code if you can't get it working [15:10:51] its the axis that needs adjusting in code [15:10:52] sband_proc[0] = (-pitch + PI05) / PI2; [15:10:59] sband_proc[1] = -yaw / PI2; [15:11:03] that's all you need [15:11:05] with the old mesh [15:12:13] doesn't even need a check for >1 [15:12:49] ok [15:12:57] although you could be right with the axis actually [15:13:06] but only the _V(0, 0, 1) would need to be changed [15:13:16] because it's now 90° rotated [15:13:20] yes [15:13:28] to _V(0, 1, 0) or something like that [15:13:43] or in X or minus, no idea :D [15:28:22] it needs a rotated axis [15:28:26] 45 degrees [15:28:49] so like { cos(RAD * 45),-sin(RAD * 45), 0.00 } for the SBand pitch axis [15:29:05] which has the pitch axis rotated 45 degrees [15:29:35] but the yaw axis used to be already pointing straight back (on the initial mesh) so 0,0,1 worked [15:30:01] but now its the initial yaw axis is pointing 45 degrees from up [15:33:27] so it is working properly now or not? [15:33:39] could not figure out the axis [15:33:44] Ill just do it like you said [15:33:46] in code [15:33:49] with the old mesh [15:34:01] yeah, that seems to work without issues [15:34:04] ok [15:35:17] 90° rotated gives -165° to 165° animated state of the pitch axis actually [15:35:32] so in a way that is the "middle" state of the antenna [15:35:43] as it is right now in the old mesh [15:36:03] the code is still mostly from AAPO, right? [15:36:08] yeah [15:36:13] Default position probably chose because of that [15:36:23] I modified all those to match my model [15:39:16] oh of the mesh you mean [15:39:17] yeah [15:41:28] yep, works like a charm [15:41:36] yeah, not really considering how the steerable system works, but more the total movement of it [15:42:29] I will be pushing an Ascent Stage model but I did not change the steerable mesh, its just regarding some unrelated stuff [15:42:30] so the halfway point was chosen as the default [15:42:41] ok [15:45:43] got it working with my code? [15:46:02] yes [15:46:10] it works well [15:47:03] great [15:47:30] so for save loading of the RR/SBand and DPS I think thats not needed, right? [15:47:44] as the initial sate is called in DefineAnimations [15:48:21] ah yeah, that's right [15:48:44] it does need the same code as at the beginning of the timestep, so don't forget to also change that to -pitch etc. [15:49:26] yes thats done [15:51:25] so what nneds save/loading is the overhead and forward hatch [15:51:35] Id like to have that done for my PR today [15:51:43] sure [15:52:33] ah, I think we don't have to use the AnimState2 functions for that [15:53:08] just save that as another parameter in the one line that is saved for the hatches [15:55:05] I tried this last night, in say LEMOverheadHatch::DefineAnimations, add: [15:55:08] if (IsOpen()) { [15:55:08] lem->SetAnimation(anim_OvhdHatchVC, ovhdhatch_state.SetOpen()); [15:55:09] } [15:55:10] else [15:55:11] { [15:55:11] lem->SetAnimation(anim_OvhdHatchVC, ovhdhatch_state.SetClosed()); [15:55:12] } [15:56:51] uhh [15:56:53] to do what? [15:58:14] well set it open or closed based on hatch state at session start [15:58:58] did not have much luck, Ill try what you said [15:59:27] in e.g. LEMOverheadHatch::SaveState [15:59:32] sprintf(buffer, "%i %lf %lf", (open ? 1 : 0), ovhdhatch_state.State(), drogue_state.State()); [16:00:38] and the LoadState becomes [16:00:40] void LEMOverheadHatch::LoadState(char *line) { [16:00:40] int i1; [16:00:41] double a, b; [16:00:41] sscanf(line + 13, "%d %lf %lf", &i1, &a, &b); [16:00:42] open = (i1 != 0); [16:00:44] ovhdhatch_state.SetState(a, 0); [16:00:46] drogue_state.SetState(b, 0); [16:00:48] } [16:11:44] hmm added those but still no luck [16:12:07] btw I did not add drogue because its now not part of animations [16:12:26] anyways heres what it looks like: [16:12:27] https://www.dropbox.com/s/rgmxfjiqd63nnj2/Screenshot%202018-12-20%2011.12.10.png?dl=0 [16:13:11] ah yeah, I am not fully updated in my local repo [16:13:30] it seems to save it though [16:13:39] you forgot the loading code [16:13:46] ovhdhatch_state.SetState(a, 0); [16:13:54] below the "open =" [16:14:06] a is just used as an intermediate variable [16:17:33] ok did that [16:18:23] now if I save mid door animation (say door half way open and opening) when I reload its showing the door in the proper position, but its not moving IE: stuck half way open [16:18:39] ah [16:18:46] then it also needs to save the speed variable [16:19:06] drogue_state.Speed() in save [16:19:16] ovhdhatch_state.SetState(a, b); in load [16:19:20] and load a and b as before [16:19:33] well, not drogue of course [16:19:36] you get what I mean [16:19:37] yeah [16:22:07] speed is an %lf too right? [16:22:21] yeah [16:22:43] yes [16:23:33] works! [16:23:43] ill do the same for the forward hatch now [16:32:04] done [16:33:38] I just have a few tweaks to do on the SIVB LM_Parked mesh and I will PR this [16:33:45] sounds good [16:34:31] I've mostly made the RHC class being used everywhere today [16:35:00] like, changed something like "rhc_x_pos > 62798" to "rhc1.GetPlusYawHardOverSwitch()" [16:43:35] nice [16:43:58] gets rid of some messy ECA code as well [17:39:39] indy91, PR sent [17:41:17] very simple to check, that's how I like my PRs [17:41:23] merged [17:41:53] haha [17:41:54] thanks [17:42:26] anyways that marks the end of my LM visuals work for now [17:42:58] save for possible bugs or what not [17:43:38] in the next few weeks I plan on working on a few things in the CSM: New SPS mesh, animated and animate the HGA [17:45:26] sounds good [17:45:35] I'm still busy for a bit with the SCS haha [17:45:41] after that I'll fly some missions [17:45:48] 7 and 8 to do any MCC fixes [17:46:05] and if Ryan hasn't reappeared then I probably have to look at the LM ECS... [18:02:59] nmm Apollo 5 scenarios are broken [18:03:45] fun [18:04:18] probably my fault, caused by moving the LM functions [18:05:50] I tried debugging but it gives no useful info [18:06:11] basically any Apollo 5 scenario CTDs at session start [18:08:49] could also be animations [18:09:05] hmm [18:09:16] do scenarios after LM sep from the S-IVB also crash? [18:10:22] nope [18:10:38] then it's probably animations [18:11:13] no descent mesh load etc. [18:11:59] well dscidx is loaded [18:12:26] oh maybe its the mesh groups for the NoLegs descent stage being different then the regular one [18:12:46] Ill try adding a !NoLegs to the DPS animations [18:13:43] nope didnt work [18:14:15] there is no way the animations would work on the launchpad [18:14:19] ah right [18:14:20] CoG is different etc. [18:14:36] anyways ill check this more when I get back latter, gotta run! [18:14:42] might be possible to delay the animation definition in the special LEMSaturn code [18:14:43] cya [19:17:39] good morning [19:18:42] today is apollo 8's 50th anniversary [19:23:30] hey [19:23:38] yeah, that's right [19:23:55] well the launch [19:24:01] nothing special planned for NASSP, haha, too busy with pre Christmas stuff [19:25:03] i haven't done any nassp in a few months but i might start again today [19:31:10] morning! [19:31:32] good morning Mike [19:32:10] hey [19:32:48] Steve Hauer sent me a video this morning of his AGC passing the full Borealis self-test suite :D [19:34:13] that's quite advanced [19:35:07] sounds like he can start doing useful things with it soon [19:35:34] yeah! he was wondering what else he can do with it without adding in more hardware [19:35:39] I might send him your way [19:35:55] sure [19:37:50] anything that the Virtual AGC can do as well I guess [19:51:04] I've replaced all my AGC knowledge with SCS knowledge in the past few weeks of course [20:26:10] hehehe [21:26:14] night! [19:06:06] indy91: I see Ron got you a bunch of things [19:06:13] are they what you hoped? :D [19:07:50] hey [19:08:02] yes, Santa Ron came over and brought presents [19:08:17] they are as good as I could have hoped for [19:08:38] awesome! :D [19:08:59] they took the extended time between Apollo 13 and 14 to rework those documents, that's why I thought the Apollo 14 RTCC Requirements would be good to get first [19:09:05] and I was definitely right [19:09:32] in some earlier documents only new features are presented and you have to look up a whole chain of memos to get the whole picture [19:09:55] but these Apollo 14 ones are complete, especially the Return-To-Earth one [19:10:13] so, there is one funny thing [19:10:23] I've never seen that Return-To-Earth document before [19:10:29] but I've been using a routine from it all along [19:10:43] https://archive.org/details/scans_171.png/page/n155 [19:10:47] INFRV [19:11:05] INRFV* [19:11:10] and cross check [19:11:11] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_rtccmfd/OrbMech.cpp#L1031 [19:11:37] the RTCC Requirements is using a general NASA memo as the source for this [19:11:46] hahaha awesome! [19:11:58] and when I first implemented TEI targeting for our RTCC I couldn't find much [19:12:08] but there was one document on NTRS from 2010 which was helpful [19:12:25] and that 2010 document is referencing the same 1970 or so NASA paper [19:12:46] so I guess I haven't been very far off with our TEI targeting all along... [19:17:39] and that was purely by accident [19:18:03] I had no idea this was actually a routine or function associated with Apollo [19:18:05] or even the RTCC [19:19:10] I love it when stuff like that happens [19:24:07] and I can definitely use all of that stuff to improve our targeting, lots of good new stuff [19:24:24] first I have to properly understand it though, haha [19:26:12] the return to Earth document is super complete [19:26:44] definitely a good resource for many months to come [19:28:52] the LOI Targeting one is mostly handwritten and the scan quality isn't great [19:29:01] so it will take a bit to go through that [19:39:51] I think the Return-to-Earth RTCC Requirements document is the best RTCC document I've seen so far, because it is so complete, with flowcharts and lots of numbers. So yeah, definitely super happy with what Ron scanned. [20:12:05] hey [20:12:21] hey Alex [20:12:46] we got some good stuff from Ron: https://archive.org/details/virtualagcproject?sort=-publicdate [20:14:29] nice [20:14:40] are those the full docs? [20:15:19] yep! [20:15:34] except for Operational LM Abort and Rescue Plan for Apollo 11 [20:15:47] we ran out of time Friday evening when he scanned that [20:15:54] missing about 40 pages of grpahs [20:17:42] but the other stuff is super good [20:17:59] 250 pages of full flowcharts for Moon-centered Return to Earth [20:18:22] and the other documents, also for Apollo 14, answer some questions about LOI/DOI [20:19:10] so we have the stuff for LOI targeting and RTE now? [20:19:13] yep [20:20:25] I told Mike the story already, I was already using a routine from the RTE processor by pure chance [20:21:01] the RTCC document is referencing a NASA memo which was a second hand source for a document that helped me [20:23:13] of course it will take a while until any of that becomes NASSP code, but, just like the TLMCC documents, we will get burn solutions that will be very close to the historical ones [20:23:19] and new features of course [20:23:44] Preferred Targeting Point (PTP), which is specified splashdown longitude AND latitude [20:28:08] oh great! [20:28:30] or unspecified area, but very fuel optimized [20:33:15] a lot of material to digest, haha [20:38:47] I bet [20:39:04] have you looked through it a bit? [20:39:43] yeah, looked in all of the docments a bit [20:44:50] the TLMCC documents will help with hybrid trajectories, targeting to get DOI right etc. [20:45:51] e.g. better initial guesses for flybys with a high pericynthion altitude [20:46:22] I kind of expected that they would need better initial numbers for that, so that it properly converges to a solution [20:50:34] and they split up the targeting parameters in a way similar to how we have done it [20:50:39] pre and post hybrid maneuver [20:52:00] pretty awesome [21:15:15] have a merry Christmas! [21:15:24] I'll be away from tomorrow to late on the 26th [21:16:13] cya! [14:59:34] Hey Alex [15:22:46] hey [15:30:19] What's up? [15:38:27] not much just messing around with the new LM mesh [15:41:03] I saw pictures of the new model. Looks slick. [15:41:23] I'm currently putting up Apollo 7. Need new testing scenarios. [16:05:34] we'll have to make new Apollo 7/8 scenarios at some point soon [13:19:36] morning [13:21:03] hey Alex [13:25:51] was Santa generous this year? :D [13:26:05] yes, especially Santa Ron [13:26:19] haha [13:27:08] other than that, just lots of eating and drinking this Christmas, haha [13:30:26] how did it go for you? [13:37:32] did you have a good Christmas? [13:38:19] yep pretty good! [13:39:39] brb [13:52:36] hello, Merry Christmas everyone! I noticed in the NASSP V8 Release Work thread that one of the priorities is to update the NASSP documentation. Can I help with that? [13:54:05] hey [13:54:20] so, the main hub for NASSP document is the wiki we have [13:54:34] unfortunately it seems to be not possible to create new accounts there [13:54:42] that has hindered updating documentation [13:55:11] for the 7.0 release we had a quickstart guide and other than that we were referring to the wiki [13:56:03] so I'm not really sure where to start with documentation [13:56:28] ahh right ok. So even you guys don't have accounts? [13:56:42] I do [13:56:59] and Thymo also, but only after an annoying manual approval process [13:57:07] it's just the wiki system being very outdated [13:57:18] and it's hosted on Sourceforge, which no longer really supports it [13:57:58] Have there been any thoughts of moving it somewhere more accessible? [13:58:36] yeah, Thymo had some ideas how to move it, but I think even that is fairly broken, so it would be more of a manual process [13:58:57] starting a wiki from scatch and manually moving stuff over [14:00:10] so work on that topic has stalled a bit [14:00:11] ok, well I'd be happy to help with that, even if it is manual. [14:01:12] awesome. It's probably the best to coordinate that with Thymo, he can tell you how far he has thought that process through so far [14:02:44] http://nassp.sourceforge.net is the main website for NASSP, so simply hosting the wiki somewhere else wouldn't really help much [14:02:47] nobody would find it [14:02:55] but we could simply link to it [14:03:00] ok great, sounds good. Does Thymo often communicate on the irc? [14:03:28] yeah, fairly regularly [14:03:43] I'm sure he will be here today or tomorrow or so, if he isn't on vacation, haha [14:03:58] haha fair enough [14:04:32] While I was setting up NASSP, I noticed that a lot of the information on the wiki is fairly outdated, even if we linked to it, it would be confusing unless we could modify it [14:04:46] back [14:04:46] yeah, some articles are quite old [14:04:54] and nothing refers to NASSP 8 yet [14:05:03] so installation instructions would be useful as the first step [14:06:16] I can make a forum post for that [14:06:23] AlexB_89, you also have no working wiki account, right? [14:06:47] nope, I tried to make one, but without success [14:07:13] well you have an account [14:07:19] creating one isn't really the issue [14:07:30] the confirmation email and approval of the account is broken [14:07:34] yeah [14:08:13] msligo, you can create an account, maybe we are lucky and dseagrav drops by soon and can approve it [14:08:27] and Alex's account [14:09:29] does dseagrav not come around often? [14:09:38] every few months I would say [14:10:03] not active taking part in the development anymore [14:10:29] busy with other projects [14:11:29] fair enough. Given the difficulties, if Thymo has ideas about moving it somewhere more accessible, then perhaps it would just be worth doing that, rather than trying to update the old wiki [14:13:13] yeah, that was our conclusion as well. Unfortunately that's where it is still standing (like some other Thymo projects, ahem). [14:18:24] ok, well whatever you plan on doing, I'm happy to help [14:39:45] thanks for that. Unfortunately I can't really present you with an easy to start topic to help NASSP, haha [14:40:21] we could use someone who works on panels, but that also requires a lot of Orbiter and NASSP knowledge. [14:40:39] Documentation for NASSP will become more important closer to a release [14:41:58] I think ill start looking at making the new animated SPS and animate the HGA now [14:58:38] I'm still working my way through the SCS TVC [14:58:51] nice [17:05:28] I must say whoever did the SPS did not get the dimensions quite right [17:05:32] it was too small [17:16:24] well, the LM was wrong as well [17:16:35] quite wrong* [17:23:33] yeah [17:24:08] although the CSM was much better in general [17:42:54] heres what I have so far: [17:42:54] https://www.dropbox.com/s/43wqat608xfb7xj/Screenshot%202018-12-27%2012.42.43.png?dl=0 [18:21:10] doesn't look very different to be honest. But in a direct comparison photo it would probably be more apparent [18:26:24] yeah its almost the same, just a bit bigger and the curve is more even [18:33:20] "curve is more even" so what you are saying is I have to tune the thrust and specific impulse? :D [18:49:20] haha I guess I would say yes :p [19:48:30] just about ready to animate the SPS [19:48:47] now to figure out which subsystems to put it in... [19:49:48] sps.cpp I imagine [19:51:26] yeah [19:52:59] has pitch and yawGimbalActuator.GetPosition() [19:53:10] so the same way as the DPS I guess [19:53:51] I just need to figure out where to call the DefineAnimations from [19:56:40] is there something similar to LEM::PostLoadSetup in Saturn? [19:58:25] of course, I would only want it to be called after SIVB separation and deleted after SM jettison [19:59:32] maybe in Saturn::SetStage [19:59:44] in the CSM/LV separation section [20:00:08] Saturn::GenericLoadStateSetup [20:00:39] is the closest equivalent to LEM::PostLoadSetup [20:01:22] ok [20:02:19] is that function called after CSM/LV sep? [20:02:58] yes [20:03:42] after scenario and mesh loading [20:04:25] damn I see some ClearMeshes() in there [20:04:35] that may be bad news for the HGA [20:04:46] the SPS should be fine as it wont need child animations [20:13:07] it's not a child animation? [20:15:21] not the SPS [20:15:24] or the DPS [20:15:58] for the SPS its a separate mesh that rotates entirely on the same pivot point [20:16:13] ah, separate mesh [20:16:39] well even the DPS which is using the mesh group is not a child animation [20:17:57] so you can animate it in two axis, as long as the pivot point is the same [20:18:11] yes [20:18:25] one doesnt depend on the other [20:18:34] I see [20:18:41] but for the HGA, obviously it will need child animations [20:18:49] yeah [20:18:53] 3 axis even [20:18:59] right [20:19:17] third axis is only used by auto tracking [20:19:37] so I guess I should implement at least a simple for of it, or else it will be difficult to test it, without being used [20:19:44] form* [20:20:34] yeah [20:21:05] the third axis is only used close to the zenith of the antenna [20:21:21] it would need very large rates in the other two axis [20:21:39] so the third axis gets deflected by up to 10° I think [20:21:46] only when the other two axis are close to 0° [20:22:13] in the Systems Handbook the HGA electronics are a black box, which has hindered much progress there [20:22:25] but I have some other docs which help a bit [20:26:40] afternoon! [20:27:42] hey Mike [20:34:58] had a good Christmas? [21:01:01] success! [21:01:39] just need to get the axis right and we have a gimbaling SPS! [21:15:30] just doing LOI now, wow that SPS swivels around a lot, quite cool to see [21:16:39] well, it's gimballing 10x as fast as the DPS [21:19:55] and it's having lots of fun during docked burns [21:20:18] yeah it is [21:23:24] btw this is what I did initially: I added SPSEngine.DefineAnimations(SPSidx); to Saturn::AddSM [21:23:31] if (showSPS) { [21:23:32] mesh_dir = _V(0, SMVO, offset - 1.654); [21:23:34] SPSidx = AddMesh(hSMSPS, &mesh_dir); [21:23:34] SPSEngine.DefineAnimations(SPSidx); [21:23:35] } [21:23:44] what do you think of that? [21:24:49] probably ok [21:25:33] it helps that there is only one stage with the SPS visible [21:25:44] oh, doesn't that also mean that there is no issue with the HGA? [21:26:45] oh because we never reload any meshes for the SM during the session [21:27:31] yeah [21:28:11] we did ClearMesh() with the LM when going from stage 0 to 1 and 1 to 2 [21:28:24] but I guess theres none of that with the CSM [21:28:49] so maybe the HGA will be fine [21:29:44] yeah [21:29:52] the HGA may appear to switch positions at SM sep I guess (from whatever position its in, back to the mesh position) [21:30:13] but thats not too bad I think [21:30:39] unless the animations stay defined in the separted SM [21:30:48] separated* [21:30:59] SM is a completely different vehicle [21:31:04] right [21:31:19] you would need to give it the state of the HGA at sep and define animations there, too [21:31:59] not the hardest thing to do [21:33:34] yeah [21:33:40] it even has a DefineAnimations function already [21:33:46] for the umbilical [21:34:52] ah right [21:42:19] night! [23:41:55] Hey [23:42:45] .tell @indy91 getting a CTd at mcc pdi pad calculation for Apollo 11 [23:43:01] .tell @indy91 https://www.dropbox.com/s/n40gendg8wbxyiv/Apollo%2011%20-%20Post%20LM%20Inspection%20~%2055%20hrs%20EDIT%200001%200002%200001%200001%200001%200001%200001%200001%200001%200001%200001%200003.scn?dl=0 [11:36:50] . [11:37:34] .tell lotisully86 dumb bug, easy fix. Thanks for finding it! [13:17:20] Hey [13:19:02] hey Thymo [13:19:20] Had a nice christmas? [13:19:48] yeah, maybe a bit too much food, haha. Yourself? [13:21:13] Same story. The food was delicious, and it was nice to spend some time with family I don't see that often. [13:21:52] yeah [13:48:08] hey [13:50:45] hey Alex [14:10:02] just finishing up the SPS and Ill have a PR ready soon [14:16:23] argh, Systems Handbook error [14:21:29] weirdly enough that error exists in all versions we have, except a 1971 one [14:22:09] so it is wrong in the early Systems Handbooks but also the one specifically for CSM-114 (Apollo 17) [14:22:30] and correct in one a general J-Mission one, for CSMs 112 to 114 [14:22:48] only the correct one has a signature for quality control :D [15:05:25] indy91, PR sent [15:33:39] have you tested CM/SM sep with it? [15:34:49] yep [15:40:15] SPSEngine::Timestep is still called after CM/SM sep [15:40:25] so the saturn->SetAnimation will still be used [15:40:45] of course that will only be called if the gimbal position is changed [15:41:14] still, unsafe [15:41:18] put a [15:41:18] saturn->GetStage() <= CSM_LEM_STAGE [15:41:38] around the whole "Animate SPS Gimbals" [15:41:54] also [15:42:00] don't put that above the [15:42:04] if (!saturn) return; [15:42:04] check [15:42:29] that becomes pretty pointless if you are using saturn before that check [15:44:07] ok [15:51:21] indy91, PR amended [15:51:58] yep, looks good now [15:52:05] merged [15:52:25] Ill have to do the same for the DPS I think [15:53:43] yeah [15:53:52] you put it above the [15:53:52] if (lem == NULL) { return; } [15:53:53] if (lem->stage > 1) { return; } [15:53:57] just needs to be below that [15:58:34] right [15:58:48] and also a check for stage <= 1 ? [15:59:25] oh, if (lem->stage > 1) { return; } [15:59:32] that will take care of it [16:03:17] yep [16:10:13] btw I have made a big mesh clean up that I can PR soon, all the old LM meshes/Textures that arent used anymore [16:10:39] sure [16:14:46] I have double checked in code to be sure they are no longer loaded anywhere [16:26:43] the old LM textures are still used by the LM_SLA.msh which is used in the VAB project so Ill leave the old textures alone [16:27:31] except for LM1.dds which was a texture I had added to the old LM mesh [16:29:25] cleanup is never as easy as you think :D [16:30:09] true :D [16:47:45] only some SCS Auto TVC gains, saving/loading and GPI display stuff to do with my ECA update [16:47:58] there is one interesting thing that I'd like your opinion about [16:48:04] sure [16:48:11] SCS attitude hold in roll [16:48:39] if you have a light CSM and have all 4 quads enabled for roll, then it is unstable [16:48:57] that was the same before, so a factor 0.5 was in the code to get the RCS activity down [16:49:29] I probably am going to remove that [16:50:07] did a quick calculation, 4 jets firing and a normal short impulse RCS firing of 17 msec already lead to roll rates of up to 0.2°/s [16:50:18] so it's probably a realistic problem [16:50:24] right [16:50:40] it's frame rate dependant though [16:50:54] at 60fps it will be about right for the short RCS pulse [16:51:01] on for one timestep [16:52:43] most people don't get 60fps on the CSM main panel [16:52:56] so should that be removed or should we keep that factor 0.5? [16:54:20] AOH suggest to use two quads only anyway [16:54:31] and pseudo rate (limit cycle) helps a bit as well [16:54:44] although that might not be fully implemented correctly, I've mostly left it as it is [16:58:11] Id vote for the realistic option [16:58:23] and tell people to upgrade their hardware :D [16:59:07] that applies to me as well, sometimes [16:59:23] our panels couldn't be more inefficient [16:59:33] just haven't figured out a good way to improve that [17:00:03] at least not one that wouldn't require enormous amount of changes [17:00:18] I guess a total re-make for the panels is the only option which will have to wait for NASSP 9 [17:00:34] yeha [17:00:49] so some small improvements will have to be good enough [17:01:04] I'll get back to that soon, I think there are some things at least we can do [17:28:53] Im having fun [17:28:54] https://www.dropbox.com/s/h9g36jx9bj6vmr6/Screenshot%202018-12-28%2012.28.44.png?dl=0 [17:32:00] morning! [17:34:08] hey Mike [17:34:23] happy holidays :D [17:35:40] thanks! Happy Holidays to you! [17:40:39] how has your christmas season been? [17:43:33] hey [17:43:42] morning! [17:43:53] pretty good thanks and yours? [17:43:57] AlexB_88, I think I've only done that with Apollo 8, so I had no LM, haha [17:44:04] busy but good :D [17:44:11] great [17:49:59] looks like there will be no more presents from Santa Ron this year, thanks to the stupid US government :( [17:52:38] yeah [17:52:45] I got all the presents just in time [17:52:59] well, "all" [17:53:04] haha [17:53:09] everything I could reasonably expect to get from this trip [17:53:10] everything you asked for at least? [17:53:20] all the stuff on the top of my list, yes [17:53:25] awesome [17:53:39] I already know the next document I want, from reading the others [17:54:19] most importantly, I didn't steal any time from scanning of the AGC/DSKY schematics [17:54:30] "In the end, it turned out to exactly fill a scheduling gap in the other scanning anyway." quote Ron [17:55:12] indeed [17:55:23] turns out box management is really difficult, haha [17:55:32] yeah [17:55:48] I guess he couldn't get any more Friday afternoon [17:56:10] more on* [17:56:24] yeah I think he has to order boxes a day or two in advance [17:56:34] and then they take the boxes he currently has away [17:59:13] how mean [18:04:39] updated the spreadsheet accordingly. But I guess it's going to be a while now until anybody is going to NARA for scanning [18:04:59] I have enough material for now [18:05:43] my next favourite document belongs together with one that Ron scans, so it's not purely being greedy for new documents :D [18:05:48] scanned* [18:06:29] what is your next document? [18:07:15] RTCC Requirements for Apollo 14: Trajectory Computers for TLI and MCC Processors [18:07:25] so, the Return-To-Earth document of this kind is all inclusive [18:07:36] it has general descriptions and full program flows [18:07:45] the TLI/MCC processor one is split up [18:08:08] one with the overview program flow of the MCC processors [18:08:16] and one with the actual equations etc. [18:08:27] the "trajectory computers" one is the latter [18:09:13] we have two versions of that document from 1968, but some interesting changes for Apollo 14 will have been done for both documents [18:09:20] gotcha [18:09:46] so what I got is mentioning some changes, but doesn't go into much detail [18:09:56] which is ok, usually I can figure out the details myself [18:10:13] that's why it is now on the top of my list, but not urgently needed [18:10:47] indy91, I have a PR ready with the clean-up [18:10:51] https://github.com/dseagrav/NASSP/compare/Orbiter2016...jalexb88:AnimationWork?expand=1 [18:12:06] all those textures are unused? [18:12:10] like quad1 etc. [18:12:29] you will notice lots of changes in lm_dps, but most of those are typo fixes. Gimbal instead of Gimball [18:12:37] yeah, I saw that [18:12:38] yes now all unused [18:12:53] where would they be loaded? In code or in the mesh file? [18:13:06] even with the VAB project one as I gave it the new LM [18:13:12] in the mesh file [18:18:49] the quads have a new texture that I made that combines all 4 quads in one 1024x1024 texture [18:20:51] and all the other textures that were separate before are all included in the LMASC.dds and LMDCS.dds [18:21:03] like legwrap, porch [18:21:15] except rcs.dds thats still there [18:22:22] drogue, hatch, docking target are all in the LMASC.dds [18:23:58] LM1.dds,SPS1/2.dds are no longer needed because I now used materials which on the mesh itself which look better [18:29:06] ok [18:29:22] you didn't actually open the PR yet [18:30:09] done [18:30:40] should give a nice size reduction [18:30:58] +97,785 −549,102 [18:30:59] lol [18:31:15] 550k lines removed, nice job for such a short time :D [18:32:10] well I had started the process a few days ago [18:32:27] I just did not PR until I had checked everything [18:42:46] btw I think we could revive the VAB scenarios in-time for NASSP 8 as we did for lunar EVA [18:43:27] I remember doing something like that for NASSP 7 [18:44:13] just not for every mission, with padloads etc. [18:45:45] did we just outright delete the broken scenarios folder at some point? [18:45:57] seems like we don't have any of those VAB scenarios currently [18:47:20] nope, I got it out of my NASSP 7 directory [18:54:41] we still have the broken scenarios folder, but we did do a clean-up of its contents at one point I think [18:55:22] release is now 6 MB smaller [18:56:34] yeah, trying to find when we deleted the scenarios [19:01:53] one thing I am working on with the LM is getting the RR antenna mesh to be visible from the AOT view, that way we can block it if you dont set the RR angles as per the checklist before a P57 [19:02:52] oh yeah, that would be fun [19:05:38] the ascent stage visibility flag is set to external all the time right now. I just have to make it "ALWAYS" while in the AOT view, else "EXTERNAL" [19:36:33] finally! [19:36:34] https://github.com/dseagrav/NASSP/commit/6e8bf0ec3bdcdc318a9437f6e6573547bfa9ada3 [19:36:41] that took much longer it should have... [19:36:55] haha [19:37:00] dseagrav removed the files, probably when the Orbiter2015/2016 branch was very new [19:37:33] yeah [19:37:35] brb [19:37:41] in any case, we would have to create new ones, with updated padloads etc. [19:37:50] and the corrected positions in Orbiter2016 [20:09:10] back [20:09:48] yeah a bit of positions adjustments maybe but for the most part it already looks quite good surprisingly [20:10:59] next to assembly one thing I'd also like to see is stage test firings [20:11:12] should be possible when the stages all are separate vessels [20:11:35] then you just need a test stand which sends the same commands as the LVDC would [20:12:10] the S-I/II/IVB Systems classes should easily support that kind of thing [20:14:35] nice [20:34:21] hows the SCS TVC stuff coming along? [21:01:16] almost done [21:01:22] just some gains to figure out [21:02:12] it will almost seem like not much has changed, but there are lots of small additions and fixes [21:02:24] SCS logic buses being used is one of them [21:03:00] I guess if you start pulling SCS breakers then it will have more of an effect then before [21:03:08] yeah [21:03:21] until a few weeks ago they didn't have any functionality [21:03:37] after the ECA work is done only a little bit of RJEC stuff needs work, again, using the SCS logic buses [21:04:04] I'll have to go through the Systems Handbook page with the SCS logic buses to see how far it is implemented then [21:04:10] shouldn't be missing much then [21:05:33] almost done it seems [21:05:38] just the RJEC stuff I mentioned [21:06:34] one interesting thing is that the RJEC needs a +X translation command present for SCS SPS engine start [21:06:37] does the SCS auto TVC work more realistic now for long burns such as LOI? [21:06:40] either with the THC or the direct ullage [21:06:46] not yet [21:07:28] well nearly, as I said, just some gains to adjust [21:07:44] right [21:08:11] the Auto TVC takes the difference between current gimbal angle and trim setting and uses that as an input for the Auto TVC integrator [21:08:18] an exaggerated example [21:08:36] LOI burn starts at 0° pitch and ends at 1° pitch due to shifting CoG [21:08:52] trim gimbal angle is set to 0° and isn't changed through the burn [21:09:04] I have a suggestion for the trim thumbwheels: make finer adjustments possible [21:09:22] so by the end of the burn it would be pointing 1° off from the initial attitude [21:09:27] as it should [21:09:28] yes [21:09:37] that's basically required for this mode to be accurate [21:10:02] it needs to be trimmed accurately to the attitude at ignition [21:10:19] so that it can slowly move the gimbal angle through the burn [21:10:20] right [21:10:41] and I think right now you can only adjust it in 0.5 degree steps [21:10:43] I'd say it needs at least 2x as many settings [21:10:47] yeah [21:11:09] maybe 0.1° [21:11:18] should be good enough [21:12:09] that needs a lot more settings for the bitmap [21:12:41] I mean its not like on the real thing you could get it any finer then 0.1 I guess, considering its a thumbwheel on a crude looking gauge [21:12:50] yeah [21:13:21] and you would get into the accuracy range of the GDC [21:13:34] even from GDC align to LOI cutoff it will drift a bit [21:13:40] the real thing at least [21:13:50] hmm [21:13:54] not really relevant of course [21:14:06] BMAG drift [21:23:28] night!