[11:27:23] *** Quits: Guenter (~Guenter@NASSP/bot/Guenter) (Quit: Closing) [11:27:24] *** Quits: Thymo (~Thymo@88-159-60-197.fixed.kpn.net) (Quit: ZNC - http://znc.in) [14:39:59] *** Joins: indy91 (~indy91@NASSP/developer/indy91) [14:39:59] *** ChanServ sets mode: +o indy91 [14:41:03] hey Nik [14:41:40] hey [14:43:42] i was looking through some of my old posts and threads on the forum and found an intereating one on vessel-vessel communications [14:43:48] https://www.orbiter-forum.com/threads/ports-an-addon-idea.22656/post-350491 [14:44:21] that is probably the cleanest way to upgrade our connectors [14:44:49] ah that sounds useful [14:47:14] I'm still learning new stuff about how the 2D panels even work haha [14:47:27] so, still in the learning phase more than in the solution phase [14:50:26] i'm sure going through that code is like an archaelogical dig, complete with layers [14:51:04] a little bit, yes. There is some rarely used features that get in the way a little bit, too [14:52:01] on the left rendezvous window in the CSM, you can active a MFD there [14:52:13] and there is a switch to change between rotation and translation mode [14:52:26] and that switch is the only one in NASSP that uses the "visible" flag [14:52:33] which sets a switch visible/invisible [14:52:56] but that boolean is something every single panel element has because of that [14:53:58] and it's slightly getting in the way because it sits in DrawSwitch [14:54:55] on the other hand, FailedState is also rarely used but doesn't really get in the way [14:55:14] that only gets used in the GetState function where other systems check in which position a switch is [15:08:23] and of course it also helps to be able to read the Orbiter code [15:08:57] yeah thats a huge plus now that we can do that. [15:12:02] I didn't really understand the return value for the redraw function, but now I know that I have to return false if nothing was drawn. If I don't do that the performance gain would only be half [15:13:08] Orbiter keeps a surface for each panel and a separate surface for each panel area [15:13:36] and a background surface with the original state of the panel, so as in the loaded bitmap [15:14:53] Orbiter manipulates the panel area surface itself first depending on the type. And then the user draws on it, like the current state of the panel [15:15:04] and then in the last step it draws the panel are on the panel itself [15:15:17] and that is what the return value in the redraw function controls [15:16:05] so in my current version it would not redraw the panel area if it hasn't changed, but because it was return true, it would have still drawn the panel area on the panel, which hadn't actually changed [15:16:55] panel area* [15:17:51] it helps me understand it better by explaining it haha [15:53:55] thats a pretty effective approch [16:19:48] oh wow [16:20:22] i was just looking at the log file for when the repo switched to orbiternassp [16:21:10] about 2 years ago - 1 week [16:21:29] thats also aparently when i joined the channel for the first time haha [16:23:17] i did not realize it had been that long [17:25:55] so you have been with us for one Covid :D [17:26:06] or one pandemic really [17:27:29] morning! [17:27:37] hey Mike [17:29:07] I finished putting together my little test rope setup :D [17:29:57] hey Mike. nice. [17:30:05] so you got 2 bits working correctly then :D [17:30:54] 8 bits! [17:31:11] 4 different addresses each storing 2 bits [17:31:28] ah [17:32:48] https://i.imgur.com/MpA9jG1.png [17:32:55] hours and hours of work, for 1 byte of storage :P [17:33:18] you have reached the late 1940s then [17:34:40] a full core rope is a bit larger :D [17:34:52] yes just a little bit [17:34:52] I guess your reader will take one module, right? [17:34:59] not the full memory [17:35:12] yeah, just one module at a time [17:35:16] it simplifies a lot of things that way [17:35:20] how many was it, 6 modules? [17:35:23] yup [17:35:54] so what's the next step then? [17:36:28] finish the tuning process for this (still waiting on resistors for the inhibit drivers), then characterize the crap out of it to make sure everything is working exactly how I expect [17:37:05] and then probably doing the board layout for the backplane, so I can get the ideal pinout for the driver board's backplane connector based on rope pin placement [17:38:08] and then scaling up this driver board to have all of the circuits needed for a 6,144-location 16-bit memory, instead of the 4-location 2-bit memory that this one can handle [17:39:12] that is some scaling up [17:39:29] yeah -- but maybe less than it sounds [17:40:07] I go from 2 set/reset drivers to 6, 4 inhibit drivers to 16, 2 strand select switches to 12, and 1 sense amp circuit to 8 [17:40:59] exponential growth working in your favour [17:41:11] yup exactly [17:41:31] I also have a scaling up issue. I would like to have a designated panel area for each switch and meter and not one for each row of switches. I'd say on average there are 6 panel elements per switch row. [17:41:53] I checked a while ago, the full CSM 2D main panel has 300 something switch rows [17:42:24] and it's all going through one interface [17:42:37] oh wow [17:42:40] so then clbkPanelRedrawEvent would be called about 2000 times instead of 300. [17:43:00] I better make sure that works efficiently or I am entirely defeating the purpose of doing it [17:43:24] there is an alternative. Redraw everything in a switch row when one switch or so changes [17:43:50] then the number of panel areas stays the same, there just needs to be a bunch of code checking if the state of a switch or meter has changed [17:44:01] so both ways have advantages and disadvantages... [17:48:26] *** Joins: lightbulbmoment (~lightbulb@185.169.233.163) [17:48:54] There is a better way with newer panel area functions, but they don't work with our old method of everything being bitmaps [17:49:12] what do they need instead of bitmaps? [17:49:22] 2D mesh and dds files [17:49:58] to be honest, I don't really know if it would really be super hard to convert what we have [17:50:04] not really my area of expertise [17:50:23] but it will probably require changing everything at once [17:52:24] with the new method Orbiter can store a void pointer for each panel area [17:52:45] so all you have to do in the redraw function is convert that a point to e.g. the switch and call its redraw function [17:53:18] then having 1000s of panel elements loaded is no problem, it doesn't have to go through lengthy code to even find its redraw function [17:53:43] that pointer* [17:54:36] possibly I could replicate that system in NASSP code [19:27:55] I can replicate that system in NASSP code [20:16:48] *** Quits: lightbulbmoment (~lightbulb@185.169.233.163) (Quit: Connection closed) [20:37:39] night! [20:37:41] *** Quits: indy91 (~indy91@NASSP/developer/indy91) (Quit: Leaving)