[13:31:30] NASSP Logging has been started by n7275 [13:31:32] good morning [13:34:18] hey Matt [13:36:23] how's it going [13:37:04] remember that issue where the CMC is driving the optics in manual mode at times when it shouldn't? [13:37:36] I think I figured out why. In early CSMs that didn't work at all. There was a hardware change in the optics mode switch to allow that [13:37:59] just need to figure out when that happened. I never seem to be able to find the MIT schematic I need for that, but I am slowly getting closer [13:38:12] find anything in the* [13:38:45] also, there is a funny reversal of pages in the Apollo 12 mission report when I was researching it [13:38:57] in the section about anomalies [13:38:59] 14.1.9 Zero Optics Mode Fluctuations [13:39:04] there is a text about that [13:39:09] and then next page, which is the wrong page [13:39:16] "To minimize the problem, urine storage on future missions will be [13:39:18] limited to critical mission time. " [13:39:22] :D [13:41:34] I'll talk to Mike about it later, I'm sure we can figure it out properly [13:43:21] haha. [13:45:40] I found [13:45:49] Engineering Change Proposal 792 [13:45:58] "GNIC wiring change to allow computer aided optics tracking" [13:46:15] retrofit 205, 211 thru 222 [13:46:45] CSM serial number 205 is Skylab 2. 211 is Apollo 12 which is weird [13:46:52] I thought they made this change for Apollo 14. [15:08:50] did you see this https://www.orbiter-forum.com/threads/orbiter-council-to-guide-open-source-development.40409/ [15:12:56] was about time that something like that came up, makes a lot of sense [15:26:33] ok I have done the mission specific code for the rate aided optics. That should prevent that issue with the optics being driven by the CMC in manual mode when it's not desired [15:26:46] provided that the software does it properly of course [15:26:59] which I would expect from the later versions [15:27:15] just need to figure out which mission had that hardware change done to them [15:27:19] missions* [15:27:32] People have been discussing about a council on the orbiter discord too [15:30:58] for a moment I thought this was the only current AGC related issue. But I think we also still haven't figured out that IMU coarse align error we got on Apollo 7 and 9 occasionally. [15:33:22] Our current IMU is just running an equation and fiddling some IO channels. Some day I want to see if it can do some more component level simulation [15:34:03] yeah that would be nice. And use the CDU class for it, too [15:40:33] I would love if it could do this: https://www.youtube.com/watch?v=xIAQyfK4CMs [15:40:52] I'm pretty sure they had a tumbling IMU on 12 [15:45:45] yeah I think they did [16:16:08] Think I may have fixed building NASSP on Visual Studio 2022, the only build error I was getting was S1B not being able to properly link with PanelSDK.lib, which I *think* I have solved by setting the S1B project to depend on the PanelSDK project via the Solution Properties page. [16:16:32] So far it works for a clean build on Debug and Release configurations [16:18:53] But of course that's just on my machine. If anyone else could test things out that would be awesome. I have a new branch on my personal fork of NASSP called "VS2022-Fixes" which upgrades the toolchain to v14.3 and tweaks that dependency setting, and in my case it "just works" and builds perfectly, can load mission scenes just fine and systems seem to behave as expected. [16:20:33] that panelSDK dependency is probably affecting older versions too, i find i need to build 2-3 times to get all the projects sometimes. [16:27:06] For me it's a consistent "no build" unless I either manually change the linker directory to be an explicit path rather than an implicit/relative one, or forcing the two projects to be explicitly dependent [16:27:36] so I went with the latter because it means we won't have to worry about every NASSP installation needing user-specific configs [16:31:35] agreed. it should build "out of the box". i believe Thymo had done sone work on upgrading to vs 2022/newer build tools so it would be good to get his input. also, for the auto builds we would need to talk to dseagrav [16:44:39] roger [16:49:51] morning! [16:50:26] oh boy y'all are talking about ECPs :D [16:53:22] hey Mike [16:53:32] yeah I had trouble as always with the MIT drawings [16:54:02] but ND-1021043 was somewhat helpful [16:54:14] at least confirming that it was indeed a change [16:54:23] yeah ND-1021042/1021043 are the best starting places for ECPs [16:54:25] and not an error in the early Systems Handbook or so [16:54:38] Apollo 14 was the first mission to use that change [16:54:42] the compatibility charts indicate that ECP 792 was the defining change between 2021290-041 and 2021290-051 [16:54:57] and that applies to which missions then? [16:55:07] well, let's see [16:56:01] Apollo 11 had -041 [16:56:27] as did 12 and 13 [16:56:31] ooh [16:56:46] and 14 had -051 [16:56:59] I was seeing "RETROFIT 205, 211 THRU 222" [16:57:56] assuming Ron transcribed this drawing right [16:59:30] 14 makes the most sense [16:59:48] I interpreted ""RETROFIT 205, 211 THRU 222" and thought it means starting with Apollo 12 [17:00:40] yeah, looks like Ron got that right [17:00:53] did get what right? [17:01:06] those 2xx numbers are MIT guidance system numbers, not Apollo mission numbers [17:01:22] yeah [17:01:28] if you were looking at the ND-1021042, it would look like "RETROFIT 605...." [17:01:38] my quote is from ND-1021043 [17:01:47] right [17:01:48] and you said it starts with Apollo 14 [17:01:53] but 211 is Apollo 12 [17:03:01] yeah not sure what the discrepency is there, but I'd trust 2014999 over ND-1021043 [17:03:11] https://archive.org/details/apertureCardBox465Part2NARASW_images/page/n1380/mode/1up?view=theater [17:03:20] and I think Apollo 14 makes the most sense, so I'll go with that haha [17:03:31] because they added P24 on Apollo 14 [17:03:33] which this change is for [17:05:06] hmmm [17:05:18] so we don't have the revision of 2021290 that covers the -051 variant unfortunately [17:05:31] it would have had to be a schematic change though, so do we have an updated schematic... [17:06:44] yeah I tried finding any relevant schematic that actually shows the change and the switch etc [17:06:52] but I never seem to be able to find anything [17:08:24] NARA's drawing spottiness is definitely not helpful here [17:08:40] I saw the change in the Systems Handbook [17:08:50] but we only have CSM-104 vs. 112 there [17:08:58] so I couldn't tell when the change was really done [17:09:32] basically bypassing the optics mode switch, for that one signal at least [17:10:06] yeah unfortunately we don't have MIT schematics that show that [17:10:08] for the most part the early CMC software versions are good at not trying to drive the optics in manual mode [17:10:22] but we have been a few cases where the optics positioning routine was still running [17:10:26] been getting* [17:10:41] and was overriding what you did manually [17:11:43] but the answer of course is, until they added P24 on Apollo 14 this wasn't even possible, CMC driving optics in manual mode [17:12:33] right [17:13:07] hmm, what's the difference between 2014578 and 2021290... [17:13:27] and from Apollo 14 on they really needed to make sure they don't accidentally have this routine running anywhere but in P24 [17:14:50] right [17:14:53] ah, 2014578 was very early and only for the first few Block II CMs [17:14:53] I found one relevant schematic, but only in the version of the optics panel where it was still one switch with CMC, manual, zero positions, so very outdated... [17:15:03] yeah [17:15:13] yeah we're missing a lot of this one [17:15:55] we have the wiring diagram https://archive.org/details/apertureCardBox467Part2NARASW_images/page/n605/mode/1up?view=theater [17:15:57] pre-change [17:17:54] right [18:16:14] finally figured out how to tweak the DSKY EL colors in NASSP now that I have things actually compiling [18:16:27] or rather the EL digit colors overall [18:16:53] with a hue shift of -10 it looks like a perfect split between the old lime-green and the newer mostly-cyan [18:28:49] oh great. Yeah it probably makes sense to go a bit back to the old green [18:29:10] main roadblock to a PR is that I don't know how to do the same to the virtual cockpit DDS textures [18:32:41] I think my install of Paint.NET can open them with a plugin but since they're compressed I'm not sure how that's gonna work out if I edit them directly rather than regenerating them from the 2D bitmaps [18:32:54] I can actually open them in Visual Studio directly [18:32:58] but I never tried editing them [18:33:56] VS doesn't look like it can edit them, just view as far as I can tell [18:34:07] hmm ok [18:34:20] Alex would know what to do, but it's been a bit since he was here [18:37:32] okay, well I think I managed to edit them okay enough [18:37:36] let's give it a test [18:39:11] everything looks good except for the DSKY digits [18:39:20] there's some compression artifacting or something [18:43:50] fixed! [18:43:52] PR for the optics mode bypass is up [18:43:58] mode switch* [18:44:02] just had to use a different compression format for the DSKY digit texture [18:44:14] ah nice [18:44:19] also recreated it from the original source BMP rather than recompressing the existing texture just in case [18:44:48] basically you just have to take the source bitmap and pad the image dimensions until both axes are a power-of-two [18:44:56] so from 204x19 to 256x32 [18:45:23] and color the padding area to pure magenta (R 255, G 0, B 255) so it's transparent [18:45:46] uhh wait, don't merge that PR [18:47:28] mine or yours? [18:47:35] mine [18:48:24] you figured out that bitmap stuff quickly haha, I've tried a few times to do some editing there. I guess I'll stick to code... [18:48:55] Oh god you found out about hungarian notation lol [18:51:29] nah the code I was "inspired" by for the mission file used it like that [18:51:35] and I just kept it :D [18:52:12] I'll not jokinly use the word stole again, that just leads to discussions... [18:52:45] Haha [18:53:46] we have a range of styles that span idomatic C99ish to modern C++ [18:54:51] tends to happen when lots of people work on a hobby project for 20 years [18:55:38] there's no avoiding it [18:56:53] also fortran IV haha [18:56:54] I wanted to hold the PR because of [18:56:55] CSMHasHGA=FALSE [18:56:57] CSMHasHGA=TRUE [18:57:05] this is how I have done bools in the past [18:57:16] but now I have done [18:57:19] HasRateAidedOptics=1 [18:57:23] I guess I'll change that to [18:57:25] HasRateAidedOptics=TRUE [18:57:31] even if it probably works [18:58:28] which I hadn't actually tested properly either. I tested in the "broken" Apollo 8 scenario [18:58:34] but now I am checking if P24 still works as before [19:02:09] it does [19:02:15] but I'll change it all from 1 to TRUE anyway [19:02:42] that's what the Orbiter API suggests to use for oapiReadItem_bool [19:03:37] that makes sense [19:04:42] and P24 works [19:04:55] always best to give the compiler as few oportunities to mess it up [19:05:09] and the bad Apollo 8 scenario doesn't drive optics in manual mode, so all as intended [19:05:35] nice! [19:06:18] guess I was putting too much faith into the (non) fact that the J-mission Systems Handbook applied to all missions in this case [19:07:03] I was tempted for a moment to implement the full relay logic for optics modes, but this change is simpler. [19:10:27] the csm114 systens handbook is a really nice scan. i wish we had the others like that [19:20:53] okay, PR for the new EL display color submitted [19:21:23] I included a bunch of screenshots to hopefully make it easier for people to see how they like the new color in use [19:28:59] And the DSKY wars continue... [19:32:11] hahahaha [19:32:43] yeah I'm just trying to strike a balance between the perceived color and the actual color, and I think the current color is too cyan [19:36:18] that's probably correct. And on the other hand, I recently looked at my Apollo 4 videos that were made just before the change. And it looks sooooo green. [19:39:10] agreed, and same with other on-board footage from other missions tbh [19:39:35] but again that could be largely because of the way that the film and TV cameras pick up the very wide-band wavelength that the EL displays output [19:40:01] yeah, it's so difficult to really get it right [19:42:16] the changes were made in the first place because thewonderidiot had seen how an actual DSKY looks [19:42:30] but then the color probably changed over 50 years... [19:45:28] I do think the current NASSP color is probably too blue [19:47:14] the somewhat color-adjusted shot at the end of Marc's video is probably closest https://www.youtube.com/watch?v=feRCZyLzAwA&t=2064s [19:48:12] and I think James's NASSP adjustments come pretty close to that [19:49:11] great :D [20:03:49] yay :) [20:06:33] Mike, do you still have that EL display? that's something else I would love to see in person at some point, haha [20:07:00] then maybe I could finally get an appreciation for how strange the color is [20:08:19] it's still in Marc's basement [20:10:17] ah dang [20:15:53] another thing I'm considering is recreating these digit bitmaps from a vector drawing, I'm no artist but I think over the years there has been some quality loss or compression that has resulted in certain digits looking slightly crunchy when viewed up close [20:17:04] thewonderidiot, do you have the documentation regarding the shape and size of the EL displays? I could theoretically recreate them in vector form [20:17:14] specifically the digits themselves [20:17:40] of course I do :) [20:18:12] those are p/n 1006315 [20:18:22] https://archive.org/details/apertureCardBox439Part2NARASW_images/page/n222/mode/1up?view=theater [20:18:39] fantastic [20:19:07] like I said, I'm not very artistically inclined but for simple digits like this I might be able to do it [20:20:16] keep in mind that that drawing does not include the protective frame that goes over that [20:21:46] also, here's my photo album that includes some hi-res closeups: https://photos.app.goo.gl/t8maF47BxQ9DD9EP6 [20:23:34] roger, I just want to recreate the EL digits themselves as well as the other DSKY segments [20:26:28] indy91: Do you use the resource view to add a new bitmap or do you do it manually? [20:27:38] I don't think I ever added a new bitmap [20:28:04] so I don't know [20:29:40] Gotcha [20:30:53] I am really clueless when it comes to that stuff. I would love to add a mesh with texture for cue cards to add in the VC but I'm not getting very far. [20:31:11] so I need to outsource that some time :D [20:51:16] outsourcing projects? brilliant :D [21:40:58] thewonderidiot, how would I read the dimensions for these segment displays? it often has two different numbers and they use dots and hyphens next to the numbers and I'm not sure what that means. [21:41:48] I'm not sure what you mean by dots and hyphens [21:42:12] the two numbers vertically stacked are min/max dimensions -- they all have a built-in manufacturing tolerance [21:42:27] I usually split the difference and average the two numbers [21:42:57] oh hang on, I think those are for angles [21:43:08] degrees and... seconds? minutes? [21:43:17] minutes [21:43:20] okay [21:43:23] if you mean ° and ', yes that is degrees in minutes [21:43:37] so 15°30' would be 15.5 [21:43:42] awesome [21:44:22] then yeah I think I can recreate these, my vector art program of choice has variable sizing for its stuff and I can work in inches quite easily [21:56:59] CaptainSwag101, in the screenshots of your PR, it almost looks like the 2D and VC colors are different [21:57:07] is that just the different lighting in the VC? [21:57:32] I think it is, but it could also be due to the texture compression used in DDS [21:57:36] 2D panel seems more...vibrant [21:58:30] absolutely [21:59:09] I might actually hold off on having this PR merged because I wanna see if I can incorporate my new from-schematics DSKY digits [21:59:38] right [22:00:07] ah great, it's midnight already. Already hate daylight savings again. Good night! [22:00:52] night! [22:21:48] I tried to upgrade the dsky digits a few months ago but then i remembered that my artistic skils don't extend very far outside of music... [22:22:22] the first indication of which should've been my tool of choice [22:23:03] *choice of tool [22:31:31] hehehe [23:13:47] okay, gonna test these new digits [23:14:28] oh dear, the texture alignment is all wrong [23:16:17] the digits are slightly too wide horizontally [23:18:52] damn, the displays are all expecting digits skewed by 13 or 14 degrees instead of the 15 degrees in the NASA spec [23:19:38] I may need to mess with some code to fix that [23:20:08] i think you probably will [23:21:45] both the 2d and 3d cockpit use the blit method [23:22:13] argh [23:23:11] but this might be a good oportunity to upgrade [23:24:35] the newer method uses a texture on a 2d mesh for stuff like this [23:28:19] for the time being I'm just rescaling my texture lol [23:41:17] easy solution for now [23:42:58] it wouldnt hirt th reach out to Alrx on the forums though [23:43:05] *hurt [23:43:19] small keyboard... [23:48:41] yeah you have a point [23:48:57] my main concern is that it's a much bigger undertaking [00:35:28] Okay, I think my PR should be good to review now, thanks for bearing with me lol [00:35:52] I had to make several tweaks to the scaled bitmap to make things look better at that size [01:19:48] it looks great from the screenshots. will have to pull and test it out. [01:35:16] The nice thing about this is, the digits are vector graphics meaning they can be scaled infinitely as required [01:35:28] though of course they are rendered to a bitmap for actual use [01:36:16] but if we were to ever perform a texture remaster/overhaul or something, it would be trivial to re-export these digit graphics from the original source file at any new resolution [01:41:15] it would be fun to do the digits by relay-segment group, at some point [01:41:45] my original source files could handle that as well, each segment is its own object [02:09:09] nice! [02:09:56] That's actually how I created the digits in the NASSP bitmap for the PR, I just copied the whole digit over and over and switched different segments on and off to create the proper numbers [03:44:44] made a few tweaks to the original source file, looks like I had a very minor vertical misalignment which was causing the top row of pixels to be less defined in several numbers, that's largely fixed now [03:45:54] honestly I want this PR to be absolutely perfect before it's merged, since it changes visual aspects that people are going to be seeing in NASSP 8.0 stable going forward, my aim is for it to be about as good-looking as is reasonably possible [14:49:49] good morning [15:35:07] good morning [15:36:20] hey guys [15:45:19] thinking about ullage stuff [15:45:37] especially for Apollo 7 [15:45:55] RTCC MFD and MCC need to support it better. And it needs to be more consistent [15:47:01] have all checklists been updated to say that ullage should be done? For Apollo 7 as well or not yet? [15:52:10] I havent touched 7 [15:52:22] I believe I had 9 and 11 fixed to include it but I can go back to verify [15:52:30] ok [15:52:36] I am working 10 right now, it will have them when I complete the mission [15:52:38] I'll do some updates over the next time [15:52:51] then it would be good to update Apollo 7. Right now it's too early [15:53:46] sounds good [15:54:03] Right now the DV of the two minimum impulse SPS burns is calculated for 0.5 seconds and no ullage [15:54:13] if you do ullage anyway you get a shorter burntime for the SPS [15:54:19] which is actually somewhat unsafe [15:54:33] or at least it's not predictable what happens below 0.4 seconds I think [15:54:56] and we don't want to do procedures that are unsafe :D [15:55:40] I will always add ullage duration on the Maneuver PAD then [15:56:09] which is not quite correct for Apollo 7 I believe, they didn't always get a comment. Only when it deviated from 4 jets 15 seconds [15:56:31] Sounds good and they will all be on the checklists as well from the flight plans [15:56:38] Unless you want to be able to compute them [15:56:45] yeah, I'll use the flight plan values [15:56:59] they weren't super consistent with these times and 2 vs 4 jets [15:57:00] Ok sounds good [15:57:31] I'm looking at it chronological, so NCC-1. Two-impulse processor. [15:57:40] In non-MPT mode you can't select ullage thrust yet [15:57:59] and that does have a small impact on the TIG calculate of the finite burn [15:58:05] calculation* [15:58:48] isnt ullage on the maneuver pad page? [15:58:58] yeah, the Maneuver PAD can now simulate it [15:59:24] but the TIG and DV aren't calculated with that taken into account yet [15:59:40] on that maneuver transfer page [16:00:23] which in MPT mode and non-MPT mode calculates the correct TIG for the specific thruster [16:01:00] to get the same trajectory as if the burn was instant [16:01:13] ahh [16:01:14] that can't take ullage thrust into account yet in non-MPT mode [16:01:29] and with light CSM ullage is already a few DV [16:01:33] ft/s of DV* [16:02:27] of course Average G sees the ullage and then burns the SPS for a shorter time. So you apply the right total DV but not at exactly the right time if you are following what I mean [16:02:34] I doubt it's more than a few tenths of a second though [16:02:52] but the MPT takes that into account, so it should be taken into account in general [16:03:10] Looks like I need to add ullage for 8 [16:03:31] for TEI only I believe [16:04:08] other missions needed it for LOI-2 [16:04:16] but CSM only LOI-1 doesn't burn much prop [16:04:36] Let me rephrase, I need to denote "No Ullage" for many SPS burns on 8 :P [16:08:51] oh haha [16:09:19] not that it hurts to do ullage [16:09:24] only waste of gas [16:29:23] indy91: The discussion about 2010 being better than 2016 has started again in the orbiter council thread. Maybe worth mentioning the physics problems we've had the necessitates 2016? [16:31:05] Apollo 9 DPS docked burn is impossible in Orbiter 2010 [16:31:22] SPS needed to have a different gain, but that is part of the padload [16:31:28] for the LGC it's all hardcoded [16:32:24] I would also say that Orbiter 2010 was better in some ways. Better performance, less bugs. But that is things we could improve with Open Orbiter [16:47:38] the single most requested feature in orbiter from 2000-2015 was 3d terrain. then it gets added and requires a few changes to touchdown points and everyone loses it... [16:48:01] morning! [16:51:56] hey Mike [16:52:26] n7275, that's easily said, I'm not sure you understand the pain (mostly) Alex and I went through to get anywhere with the touchdown points :D [16:53:48] hehehe I remember all of the touchdown point discussion and fiddling well :P [16:54:45] fair enough. personally, i think what really slowed 2016 adoption down is that a few closed-source addons were never updated. [17:09:46] what's been going on with open orbiter anyways? I haven't really been keeping up with it [17:34:40] thewonderidiot, do you happen to know if the DSKY uses smaller digit sizes than the other EL displays? In NASSP the DSKY/DEDA/EMS digit bitmap is about 10% smaller than the texture for the other EL displays, and even if I rework the code to use digits of the same size, now we can only fit 4 digits on the DSKY's 5-digit registers [17:34:55] no idea [17:35:16] they all came from different manufacturers so the size/shape/color/etc. is pretty much guaranteed to be different [17:35:22] but without drawings we don't know different how [17:35:26] dang [17:35:46] the annoying thing is, the DSKY fits those 4 digits PERFECTLY. Problem is we need all five lol [17:41:30] well no big deal, I have reworked the drawing code to be more configureable and to match the new layout of the digits, so even if I have to resize it, it should be fine [17:45:26] the NASSP panels were also long before we had actual engineering drawings for the DSKY, so the dimensions of what you're trying to fit into could very well be off as well [17:47:28] that's a good point [17:48:18] but redrawing the DSKY would be well beyond the scope of what I can do [18:23:51] thewonderidiot, not much happening with Open Orbiter at all. I guess that is why there now is a discussion about how the further development should look like in principle. [18:31:39] does anybody know if the colon and decimal point EL digits in the existing texture are actually used? I haven't seen them used anywhere, nor have I seen special-case code in NASSP for them either [18:43:23] CaptainSwag101, I think no, none of the digital LM display use those either [18:46:02] Okay, I just checked and it looks like the EMS uses the decimal point at least [18:46:14] ah true [18:46:18] I'm gonna get rid of the colon character though [18:47:11] I'm currently reworking the drawing routines to be more configurable as well, right now we're using integer literals for all the size values and that's not ideal, so I'm adding some basic constants and using those instead [18:47:45] that is, in the DSKY and other EL digit drawing routines. Not every single drawing routine in the project lol [18:50:07] is that all for the update with the color update? [18:50:22] sounds like the scope has become a bit larger haha [18:51:17] indy91 a few maneuvers I do not have ullage in the checklist as they possibly could be P40 or P41, would ullage per maneuver pad be sufficient for those when ullages get put into SPS maneuver pads?? [18:51:43] For known SPS maneuver with ullage I have them included [18:52:17] yeah scope has creeped a bit lol [18:55:50] rcflyinghokie, yeah I can add a remark to the Maneuver PAD with ullage duration if it turns out to be P40 [18:56:38] Sounds good, and I will leave known SPS burns with the flight plan ullage [18:58:30] just testing it for the first time, Apollo 7 NCC-1. the ignition time (so SPS engine on) differs by 0.5 seconds for 0 seconds ullage vs. 15 seconds [18:59:17] so somewhat significant I would say [18:59:54] but not like you are screwing up your mission when the ullage isn't performed exactly as planned [18:59:55] how much dV is that about [19:01:40] the ullage? I am not sure, a small number of ft/s I would think [19:02:15] NCC1 still pretty full SPS [19:02:39] well yeah, but Apollo 7 only launched with 30% or so [19:02:47] Ahh thats right [19:03:13] but the ullage DV is going to be more significant later that's for sure [19:03:24] 23.9% actually [19:21:16] hmm, I can't seem to find the code that renders the LM propellant/helium EL displays [19:21:45] I've updated every other occurrence of digit-drawing code that I can find otherwise and they seem to work fine as-is, but I'd like to keep them all consistent [19:26:22] should be in lemswitches.cpp [19:26:32] LEMDigitalHeliumPressureMeter [19:26:43] awesome, thank you [19:49:46] I just found a bug, in the 3D virtual cockpit, the EMS display does not cap its negative value at -1000.0 [19:50:27] oops. That limiting code must have been in the 2D display code [19:51:24] the thing is, the actual value on the screen will go past that cap even when in 2D, it just doesn't update the displayed value. if you hold the DECR switch for several seconds at -1000.0 and switch to 3D the value is less than -1000 [19:51:47] the behavior indicates to me that the cap is only visual, not actually limiting the internal value [19:57:01] hmm ok [19:57:10] I'll have a look some time [19:59:00] It also feels like the hitbox for the EMS INCR/DECR switch is offset too low in the 3D VC, clicking on the top of the switch does nothing, clicking on the bottom increments, and clicking below the bottom decrements [19:59:32] oh weird, I switched out of VC and back, and now it's fine [20:00:36] VC isn't quite perfected yet [20:02:02] but small offset like that that suddenly goes away is unusual [20:03:04] I was loading from a quicksave made in VC [20:07:39] does the scenario have a LM? [20:07:46] yes [20:08:07] then clickspots don't work anyway before you don't switch positions once [20:08:31] had you already done that? [20:08:57] I mean they do work, they're just all vertically lower than they should be by a few inches [20:09:08] but yes, switching positions does fix it [20:09:15] right [20:09:26] yeah I think that is a known Orbiter bug [20:09:33] if two vessels with VC are in the simulation [20:09:36] #JustOrbiterthings [20:10:29] https://www.orbiter-forum.com/threads/orbiter-beta-r90-suspected-bug-with-shiftcg-call-and-vc-click-spots.40308/ [20:13:54] usually the clickspots are quite far away from where they should be with this bug [20:14:04] so that you can't even press them at all [20:14:15] in your scenario the ShiftCG must have been near 0 [20:24:29] interesting [20:25:02] also, I've finished my code changes and adjusted the new EL digit bitmaps so every digit is pixel-aligned and of consistent width. [20:25:33] I think this should be everything needed to make these new digits work properly and throughout the future [20:28:05] awesome [20:33:44] here's an unrelated question about a far-off plan that Thymo and I were wondering about: replacing the oapiBlit() calls for 2D drawing with something like oapi::Sketchpad usage. I don't really know much about the subject but according to Thymo all these blit calls are inefficient and it would be smarter to use one of Orbiter's more modern APIs for drawing [20:34:44] But naturally that would probably involve significant rework of a good chunk of the existing 2D rendering code [20:42:22] Take a look at how the deltaglider dies its 2d pannel for reference. [20:42:27] does [20:42:32] yeah I was going to say [20:42:42] we use the old 2D panel format with bitmaps [20:42:54] the DG has a 2D mesh and dds files [20:43:40] sounds complicated [20:44:08] I don't think it's super complicated. The problem is implementing that for our giant 2D panel systems [20:44:26] and not loosing any features [20:46:08] Thread 'Developer masterclass: Creating 2-D panels the new way' https://www.orbiter-forum.com/threads/developer-masterclass-creating-2-d-panels-the-new-way.38537/ [20:46:45]