[09:43:06] NASSP Logging has been started by indy91 [10:28:04] hey astronauthen96__ [10:28:09] guess what I just had [10:28:14] D3D9 CTD... [10:30:18] hey [10:30:34] at what time? [10:31:12] when the MCC calculated a PAD [10:31:17] so just like you had with the TLI PAD [10:31:21] I bet it's some MCC bug [10:31:22] I'll find it [10:31:28] were you using time acel [10:31:59] I don't think so, not at the time of the PAD calculation [10:32:19] and of course on the second attempt there is not CTD [10:32:20] classic [10:32:36] didnt get one for the evasive maneuver pad [10:38:42] and I can recalculate the PAD as many times as I want, no CTD [10:39:02] i did the same with the rtcc [10:39:06] not ctd [11:00:33] I managed to reproduce it by loading the same scenario again, which was about 2 hours before the PAD calculation [11:24:01] astronauthen96__, well I found one potential issue, but I don't think it would be an issue with the TLI PAD, as you had [11:38:35] didn't get a CTD this time with the fixes [11:38:44] so I think I've made the MCC slightly less buggy, haha [11:38:58] what was the issue? [11:39:19] well, for me it was the Block Data PAD, which is quite large [11:39:50] and the buffer saving the long string of characters for the Block Data PAD only had 512 characters [11:40:32] so in some cases it probably wrote more characters to that variable than it could hold [11:40:39] I creased it from 512 to 1024 characters [11:40:44] increased* [11:44:52] are you sure it was the TLI PAD that caused the CTD? Or a Maneuver PAD before the TLI PAD? [11:49:29] yes it was the tli [11:50:03] ok [13:10:55] morning [13:13:12] hey [13:15:59] well looks like something broke with my commit yesterday, the LM upper hatch is now gone on the LM hover stage [13:18:12] cant really explain why though [13:20:10] on LM-1 or in general [13:22:50] LM-1 is fine, its just on the normal LM in the legs extended config [13:24:02] I just used the D3D9 debug and the mesh is being loaded, its just that its visibility flag is being set to "never" for some reason even when the hatch is closed [13:24:04] guess you made it overly complicated after all :D [13:24:27] I just dont get it because I did not touch any of the hatch stuff [13:26:40] does it only happen when you do staging or also when you reload a scenario with stage 1 [13:27:37] both [13:28:06] the ascent stage is fine though so when you stage, it re appears [13:29:29] and what about the forward hatch? [13:32:35] its fine [13:36:49] the SetLPDMesh() function can't properly work right now [13:37:11] there are lpdgret and lpdgext [13:37:23] both are handled somewhat in SetLPDMesh [13:37:34] but the function at the beginning does [13:37:35] if (lpdgret == -1) [13:37:35] return; [13:37:58] can you explain to me what lpdgret and lpdgext are? [13:39:19] I really think each mesh should be handled separately. This logic has become too complicated [13:42:51] lpdret is the LPD mesh without legs (ascent stage/no legs stage) [13:43:08] lpdext is with the leg (footpad visible) [13:44:09] so a separate function for each mesh? [14:02:43] yes, I think that makes it easier [14:02:52] probably won't fix this issue with the hatch [14:08:00] so it's either that the SetOvhdHatchMesh() gets called at the wrong time [14:08:21] or there is a mesh with the same index as ovhdhatch [14:10:59] yep [14:11:07] lpdgret and ovhdhatch are both index 3 [14:11:11] now how can that happen, hmm [14:12:00] ah, I have an idea [14:14:01] although that probably shouldn't hurt [14:15:18] oh, but it does [14:15:38] here is what happens [14:15:47] during loading the LM, it always first calls SetLmVesselDockStage() [14:16:09] that's how lpdgret gets the index number 3 [14:16:22] then, with the hover stage, it calls SetLmVesselHoverStage() as well [14:16:28] it deletes all the meshes there [14:16:33] but doesn't reset the index numbers [14:16:44] lpdret is still 3 then [14:16:54] and ovhdhatch is 3 as well [14:17:07] and then it calls the SetLPDMesh function [14:17:18] where it will manipulate the hatch [14:17:24] because index 3 is now the hatch [14:18:20] / Docking probe [14:18:21] if (HasProbe) { [14:18:22] probeidx = AddMesh(hprobe, &mesh_dir); [14:18:22] probeextidx = AddMesh(hprobeext, &mesh_dir); [14:18:23] SetDockingProbeMesh(); [14:18:24] } else { [14:18:24] probeidx = -1; [14:18:25] probeextidx = -1; [14:18:27] } [14:18:29] example code from the CSM [14:18:40] so what you should do with the lpdret vs. lpdext, is set the unused index to -1 [14:19:20] and in the LPD mesh function, either split it in two, or add a check like [14:19:20] if (sidehatchidx == -1 || sidehatchopenidx == -1) [14:19:22] with an OR [14:19:30] hmm [14:19:31] no [14:19:42] and AND probably [14:26:24] ok will do [14:51:43] on another note, regarding P23s, would it be possible to modify the CMC software to have a spherical earth? [14:57:22] yes [14:57:31] it's not super easy though [14:57:42] it would have to be modified in a few places [15:00:58] I think it would be worth it at some point [15:01:48] My P23s are going good in Apollo 13 TEC, up to the point where I take earth horizon marks haha [15:02:52] I'll figure out what needs to be changed and then Thymo or Mike can create the custom Comanche055 versio [15:02:54] version [15:03:06] So I am relieving Jack of his P23 duties for now, much to his relief :D [15:03:54] great [15:04:10] I guess it would need a lot of testing too [15:06:10] also I am testing a RTCC MFD generated padload for solar/lunar ephemeris on Apollo 13 [15:06:26] works very well, P52 pointed exactly at the sun [15:06:32] good [15:07:12] question though, TIME0 is 40693.75 [15:07:22] were they not .5 before? [15:09:17] well, those are just rough first estimates anyway. They are directly customized per mission [15:09:24] not directly [15:09:33] the RTCC MFD has a Launch MJD for every mission [15:09:47] it rounds down and adds 6.75 days, or so [15:10:05] the actual padloads for Apollo 12-17 seem to be at 18:00 ephemeris time [15:10:11] hence the 0.75 [15:10:44] I haven't check them all though [15:10:49] maybe some are at noon ephemeris time [15:10:56] not sure why we were using.5 [15:10:57] .5 [15:11:38] I see [15:12:19] so I guess its not all the important as long as TIME0 is correct for the calculated solar/lunar EMEMS? [15:12:27] yes [15:12:37] they tried to make the ephemerides work for as long as possible [15:13:13] so for some missions they chose a TIMEM0 so late, that at nominal liftoff it would be more than 7 days away still [15:13:43] but after TLI, when the ephemerides would first be used, then it's within the 14 day window for which the ephemerides are meant to be worknig [15:14:31] it's a polynomial, so I bet the ephemerides would become very inaccurate very quickly outside that 14 day window [15:16:12] so, TIMEM0 should be chosen roughly 6 days after liftoff [15:16:59] a bunch of source code sections have hardcoded values regarding the Earth radius [15:17:12] won't be easy to disable all the Fischer ellipsoid calculations [15:17:16] I guess we may as well re do them for all missions [15:17:35] the solar ephemeris, sure [15:18:01] lunar one hasn't changed [15:18:10] unless you want to change the TIMEM0 [15:18:18] right, but if were using a new TIME0 [15:18:19] yeah [15:18:58] not much reason to do that [15:20:20] even Apollo 17 shouldn't run into any problems at 300 hours GET [15:21:42] well from a simplicty standpoint, the RTCC MFD is now using +6.75 for TIME0, so I can basically just open the launch scenario, verify the numbers and hit generate, and done. Instead of manually changing the TIME0s back to the current ones we have in the scenarios [15:22:20] if that makes sense [15:22:24] sure [15:22:35] but the +6.75 hasn't been checked to be completely safe [15:22:54] it's just to give a convenient number, which should work in most cases [15:23:18] you should always check if TIMEM0 is not more than 7.0 days away from the nominal time of TLI [15:23:43] right [15:23:48] I mean, I could make it calculate that [15:23:54] for the default TIMEM0 [15:23:58] for each mission [15:24:16] hmm yeah [15:25:03] the other two MJDs should always be right though [15:25:26] TEPHEM0 and the BRCS epoch [15:29:27] uhh, modifying the CMC for a spherical Earth would be super annoying [15:36:47] I think I may just revert my changes from yesterday (the LPD ones, not staging) and just have the LPD meshes not display on LM-1 [15:37:18] why? [15:37:27] I know all this LPD stuff was working fine before and I am a bit over my head on the mesh index stuff [15:37:33] the fix for the hatch wasn't all that difficult [15:37:59] but sure, LM-1 doesn't really need that [15:38:15] yeah [15:39:07] simply reverting it doesn't fully fix it though [15:39:20] lpdgret and lpdgext still need to be made safer [15:39:30] right [15:39:51] it's always lpdgret OR lpdgext, right? [15:39:59] never at the same time? [15:40:00] I'll see what I can do maybe I can fix it [15:40:06] it's really simple [15:40:20] if lpdgret is used, then lpdgext needs to be set -1 [15:40:22] and vice versa [15:40:45] and the first line of SetLPDMesh needs to be changed [15:40:47] that's it [15:41:17] hmm [15:41:28] although [15:41:46] setting an unused mesh visible is never safe [15:41:54] hoes this? [15:41:55] if (NoLegs) [15:41:55] { [15:41:56] VECTOR3 lpd_dir = _V(-0.191, 1.827, 0.383); [15:41:56] lpdgret = AddMesh(hLPDgret, &lpd_dir); [15:41:57] lpdgext = -1; [15:41:57] } [15:42:00] else [15:42:03] { [15:42:05] VECTOR3 lpd_dir = _V(-0.003, -0.03, 0.004); [15:42:07] lpdgext = AddMesh(hLPDgext, &lpd_dir); [15:42:09] lpdgret = -1; [15:42:11] } [15:42:12] SetLPDMesh(); [15:43:13] yes [15:43:35] I can just split the LPD function if it will make it safer [15:43:45] that would work, yes [15:43:49] and avoid set unused meshes to visible [15:43:53] so each would have their own check on just one index [15:45:17] So I would have SetLPDextMESH() and SetLPDretMESH() I guess [15:45:43] sure [15:47:30] and I guess I should also add the opposite state to -1 after calling the meshes in SetLmVesselDockStage() and SetLmAscentHoverStage(), too? [15:47:52] opposite mesh index to -1* [15:51:02] yes, wherever one is calling AddMesh [15:51:08] that's the safest way [15:54:42] -1 alone doesn't make it safe in any way [15:54:57] the check on the -1 in the SetLPDMesh function does [15:56:13] all the meshes are deleted when one of the stage functions is called [15:56:30] so nothing has to be set actively invisible for that [15:57:40] ok [15:58:07] that's it's always: if a mesh index is -1, don't do anything [15:58:13] also SetLPDMeshes() are called in the LM timestep [15:58:13] that's why* [15:58:18] no [15:58:32] only when the mesh configuration is changed [15:59:24] right [15:59:43] is it in the timestep right now? [15:59:44] I had added there previously because it wasnt working right without it [15:59:47] yes [16:00:00] no, that's pretty bad for the framerate I bet [16:00:40] I think its because of the if (InPanel && PanelId == LMPANEL_LPDWINDOW) { in lemmesh.cpp and I guess that is not always rechecked [16:01:27] I'm not sure what you mean [16:01:54] those are in SetLPDMesh [16:02:15] so only called, when a mesh change it happening [16:02:19] I am not sure what I mean either :D [16:02:20] yes [16:03:27] so what's the issue? [16:03:29] ah right, I remember I think the flag is set to "MESHVIS_COCKPIT" [16:04:10] but that makes it visible from every cockpit view including no panel [16:04:29] but I want it only with panel visible and in LPD view [16:04:52] hmm [16:04:56] so I guess the function needs to be called every time I change views [16:05:07] not just when mesh change is happening [16:05:53] oh, I just found that SetLPDMesh() call in lempanel [16:05:58] and my previous solution of putting it in timestep made it work right, but as you say probably not the best way [16:06:06] yeah I added it there too [16:06:48] it's getting really messy. Is there no precedent of meshes like this in the CSM? [16:07:18] dont think so [16:07:39] I guess calling it in clbkLoadPanel() isn't so bad [16:07:47] and why is that not enough? [16:08:28] hmm I will try it again with it only in clbkLoadPanel() [16:08:51] it might have been because of the messed up mesh indizes [16:10:15] right [16:12:12] there is kind of something similar in the CSM with the crew meshes [16:12:25] in Saturn::SetCrewNumber it calls SetCrewMeshes() [16:17:00] 1st test is good [16:17:26] 2nd test I removed the calling from LM timestep and it works too [16:18:24] yeah, that call in the panel update is ok [16:19:40] timestep, not so much, haha [16:22:21] so this is what I have in clbkLoadPanel(): [16:22:26] /Set visbility flag for LPD view meshes [16:22:27] SetLPDMeshRet(); [16:22:27] SetLPDMeshExt(); [16:22:47] I guess those are ok on there own [16:22:52] yeah [16:23:05] you could also have a SetLPDMesh() function that calls those 2 [16:23:21] but only really helpful, if both of those are always called [16:23:21] ok [16:23:25] which probably isn't the case [16:23:38] yeah, in lemmesh you probably only call one of them at once [16:30:03] hmm so the issue now only happens if I am in the LPD panel and cycle F8 to go to VC or no panel view [16:30:17] then you see the LPD mesh [16:31:18] but other views like main panel, etcm you can cycle through VC and no panel and it will not be visible as desired [16:32:54] thats why I had also put it in timestep originally, so that no matter what view your in it would not show unless its in LPD panel [16:33:11] ah, that's why [16:33:20] not sure how to solve this [16:34:32] I mean its not the end world, you would only see it if you are already in LPD panel, then for some reason want to change to the no panel view with F8, then you will see the LPD mesh hanging in front of you [16:35:09] you can always just switch to another window, then press F8 to go to no panel and it wont show [16:35:41] lemvc.cpp [16:35:43] clbkLoadVC [16:35:52] maybe the SetLPDMesh just needs to go there as well [16:37:29] yes [16:37:35] I think that did it [16:45:23] ok I will PR this soon just doing some final tests [16:52:12] morning! [16:52:21] hey Mike [16:56:55] jalexb88, about meshes, any idea what it would take to animate the CSM HGA? [16:57:06] first each segment would probably have to be a spearate mesh [16:58:06] PR sent [16:58:10] hmm good question [16:58:27] I dont have any experience with mesh animations yet [16:59:33] I think for once I'll dive into that Orbiter SDK stuff for it. And not delegate the task, haha [17:00:48] but you will probably have to help with the meshes [17:01:29] new code looks good [17:01:33] merged [17:01:55] thanks [17:02:07] yep I can certainly help with meshes [17:08:21] hmm, the SSU Ku-Band Antenna just uses one mesh file, but certain subgroups in that mesh [17:08:25] not sure how that works [17:08:40] is a mesh build from several sub meshes? [17:09:50] well maybe animated ones are [17:11:59] Our Saturn V ML/LUT might be a good starting point, it has a bunch of animated meshes [17:12:19] right [17:12:50] I had tired to add textures to it with Blender but the modified mesh animations were all broken, maybe those were the sub groups& [17:13:08] sub meshes* [17:13:55] yeah, the animation definition does stuff like [17:13:56] [17:14:05] static UINT swingarm_groups[6] = {15, 16, 17, 18, 19, 20}; [17:14:23] and those numbers are referencing something in the mesh file [17:16:14] yeah, when I open the mesh in a text editor I can see defined groups [17:18:44] if you don't know about them, I certainly don't either [17:20:00] what have you used to edit meshes? [17:20:03] only Blender? [17:20:43] yep [17:21:02] well text editor too [17:21:11] for the textures at the bottom [17:21:50] So Blender and Notepad++7 [17:21:59] Notepad++* [17:25:54] how can you view the separate groups? Any idea? [17:28:05] not yet unfortunately [17:28:26] I had tried to figure out the LUT animations without success [17:28:47] I have to go out for a bit, later! [20:29:25] night! [23:02:27] Woo, my patch got accepted into mainline. :) [00:08:06] thewonderidiot: You around? [00:14:52] How does yaDSKY handle lamps that should blink (key rel, opr err), does it cycle them internally or does the AGC do that? [10:16:17] good morning [10:16:24] got another ctd [10:16:38] just by simply displaying the pad [10:19:33] hmm, bad [10:19:40] the MCC seems to be buggy [10:19:45] what kind of PAD was it? [10:23:35] tli [10:23:48] that has never happened before [10:24:02] maybe it's a specific issue with the TLI PAD, I'll check [10:24:19] loaded the scenario right before tli and i simply just displayed a=it and it was the d3d9 dll [10:24:56] is it consistent? [10:25:00] probably not... [10:25:16] not really [10:25:41] annoying [10:25:59] didnt get it for the evasive pad or the block data [10:28:07] ah, I got it as well [10:28:22] loaded an old scenario [10:28:26] probably with the TLI PAD [10:28:31] do you know that this means D3D9Client destructor called [10:29:32] so, it's probably some display error [10:29:49] caused by the PAD being displayed [10:30:02] and that causes a D3D9 Client error [10:30:25] probably [10:30:38] didn't get any ctd's with the rtcc mfd [10:31:23] and of course on my second attempt I get no CTD [10:31:34] same [10:32:14] would there be anything in the d3d9 log [10:35:53] I've checked, there wasn't anything useful [12:11:08] hey [12:23:42] hi Alex [12:25:54] hey [12:33:41] AlexB_88, I finally added the real RTCC reentry target lines (velocity vs. flight path angle) [12:33:56] there is a MSFN line and a contingency line [12:34:19] there was a fairly late decision to use the contingency line for Apollo 8 [12:34:33] and that lead to the issues with P37, because the contingency line is steeper [12:35:16] it doesn't seem to make much of a different for lunar returns [12:35:35] but Earth orbit returns are now shallowed and from a circular 100NM orbit need not so much DV anymore [12:35:44] shallower* [12:43:44] now I just need to implement a generally applicable reentry range targeting [12:50:44] nice [12:51:17] Block Data are still not identical [12:51:32] so I guess these were just the Return-to-Earth Processor target lines [12:51:41] not used by the RTCC or RTACF for deorbit solutions [13:19:06] trying to connect a 2nd monitor into your windows 10 laptop is the funnest thing ever lol [13:20:25] what happens when you do that? [13:31:48] Well I got the monitor connected but its stuck at 30hz, while I am trying to get 60hz [16:02:05] AlexB_88, what would you say, is the throttle down in P63 still too late on average? [16:02:12] for most missions? [16:02:32] hmm I havent really been paying attention to that lately [16:02:43] I could test it though [16:03:32] I found one possible reason for that [16:03:56] when firing the DPS for a long time, part of the nozzle is burned off or so [16:04:11] so over time the DPS thrust slowly increases [16:04:20] hmm interesting [16:04:35] I found that in some DPS burn simulation curves for the RTCC [16:05:48] e.g. for Apollo 10 the thrust and ISP would be 9727.5lb and 303.6s at throttle up [16:06:11] and 9886.2 lb and 301.8s at 400 seconds into a burn [16:07:20] is that something we can simulate? [16:08:27] the DPS could remember how much it has been used overall [16:08:35] and adjust the parameters accordingly [16:08:57] same goes for the ISP in the throttable range [16:09:05] that should be lower [16:09:10] which is not currently simulated [16:27:00] right [16:44:58] it seems Apollo 13 still had that throttle oscillations issue [16:49:25] Luminary131 has [16:50:17] that is what we have [16:50:29] I'm not sure that Luminary 131 Revision 1 still had the issue [16:51:33] I forgot when they fixed that [17:02:58] looks like it was fixed on the last revision of Luminary before Apollo 14 [17:04:10] also fixed in that revision was the annoying "wobble" of the altitude rate meter when driven by the LGC [17:05:45] interesting [17:05:59] definitely notice that on Apollo 13 [17:06:03] back to the LR issue, I noticed something. On Apollo 13 when you land on the moon there is the latitude error which we know about and then if we then do a late PDI abort, the insertion cross-range is much higher then expected [17:06:31] but that doesnt happen on some other missions, say Apollo 17 for some reason [17:06:35] hmm [17:06:54] no insertion cross range error, but still the latitude error for the landing, right? [17:07:19] I can incorporate LR data on Apollo 17, and if I land P68 gives me the latitude error yes (and even more error then 13) [17:07:41] But If I abort and fly to insertion, almost no plane error [17:08:56] But its weird because I know that on Apollo 13, its indeed the LR thats causing it because if I omit V57, my insertion is perfect [17:10:49] there are a few small differences in Luminary 1E [17:11:06] LR angles (or rather the pointing vectors) are hardcoded and not padloaded [17:14:31] but those should be the same regardless, right? [17:16:05] yeah [17:16:50] I forgot, did you ever try a landing with the one LR angle set to 0° instead of 6°? [17:16:52] I think you did [17:17:03] yeah [17:17:09] that would have been changed in both padload and LR code [17:17:14] did that fix the issue? [17:17:27] I think it cut the error in half but not completely [17:17:31] ah, right [17:18:06] actually it cancelled out the error, then went beyond by 1 half [17:18:31]