[10:17:28] Thymo, yay! Congradulations. [10:38:32] *** Joins: indy91 (~indy91@NASSP/developer/indy91) [10:38:32] *** ChanServ sets mode: +o indy91 [10:40:26] hey [11:25:46] hey Nik [11:30:30] I think I found a slightly ugly way to prevent everything on the 2D panel from being redrawn on every timestep [11:30:45] but I have some ideas for a better method [11:31:05] we have switch rows, so one panel area = multiple switches [11:31:25] if one of the switches changes its state the whole switch row gets redrawn [11:31:41] that is the only way because the panel background has to be printed, too, and that is a all of nothing kind of thing [11:31:55] all or* [11:32:21] otherwise only one switch shows the correct state and the others would be drawn over them by the background bitmap [11:32:54] the better method would be to have a small panel area for each switch [11:35:36] but that makes switch rows obsolete. So I need to find a solution there [12:10:42] how interwoven are is the 2d pannel code with the actual switches that systems look at? [12:11:02] whoops. few extra words thee... [12:11:06] *there [12:23:41] quite interwoven [12:23:50] the VC has a bit of a separate system [12:24:05] all switches and meters are derived from the PanelSwitchItem class [12:24:16] and they are owned by the Saturn/LM class directly [12:24:32] for 2D redraw and mouse click purposes the switches and meters are organized in SwitchRow [12:25:14] and SwitchRow is currently causing everything to be redrawn all the time [12:25:26] going through its list of associated PanelSwitchItems [12:30:11] its impressive that it even manages 20fps and not, like, 0.2 fps [12:32:22] I get 50, but sometimes it drops [12:32:29] and I don't like unsteady framerates [12:32:39] that's what converted me to a VC user [12:35:40] I have already tried, if no two position or three position switches are redrawn on the CSM main panel then I get 70 instead of 50 fps [12:36:01] I'd say the potential is a doubling of the framerate [12:36:10] very rough estimate [12:40:49] oh nice [12:44:28] Thymo, congrats on finishing your thesis! [12:45:26] I see your PR. I am slightly confused when this commit was added: https://github.com/orbiternassp/NASSP/commit/549cfadf6faa5195f209e2b3fc3027fb04908ad5 [12:45:27] [ fix a documentation issue · orbiternassp/NASSP@549cfad · GitHub ] - github.com [12:45:35] That was not part of your PR for the prank... [13:00:18] Thanks :) [13:01:35] Those were the VC textures. I forgot to add them in the PR, you weren't around when I found out so I forced them through so peoples installs wouldn't horribly break. [13:01:52] ah forced them through, right [13:02:15] I was just seeing: 14 files changed in original PR, 18 files change in current PR [13:02:20] hmmmm :D [13:02:26] but that explains it [13:38:23] *** Joins: lightbulbmoment (~lightbulb@77.74.198.233) [14:12:36] The wiki and guenter will be down most of the afternoon tomorrow. Solar panels are getting installed so the power will be disconnected for a while. [14:46:26] I should have my logger running at least until next weekend when I move it to the new apartment. I can get you any missing logs. [14:47:11] the solar pannels sound cool [14:47:31] I could use a few of those [15:06:14] Energy prices are through the roof here thanks to all the Russia business. It's well worth the investment. [15:09:49] yeah, I can imagine [15:15:42] and people are panic buying sunflower oil and flour [15:23:05] I'm the engineering manager for a small textiles manufacturing company in Maine and North Carolina. The past three years have been very eye-opening about the number of single points of failure in global trade. [15:24:03] Yeah, you don't really think about those things on the daily [15:24:11] Until the Suez canal gets blocked... [15:26:24] I bet the global economic impact of that incident is at least an order of magnitude greater than it would cost to widen it. [15:36:01] *** Quits: lightbulbmoment (~lightbulb@77.74.198.233) (Quit: Connection closed) [15:36:50] Thymo, what's your plan for the scenerio version-check code? [15:38:31] That prototype I built will only check NASSPVER against the one NASSP was compiled with. That's a good start. [15:39:04] It totally depends on if we want to support older versions and automatically port these to a new one [16:09:01] *** Quits: indy91 (~indy91@NASSP/developer/indy91) (Quit: Leaving) [16:11:43] Something like this for starters? https://puu.sh/ISOsC/fdcda99311.png [16:13:35] that would work. then we can merge the Specific heat update, and at least if (when) they have problems they will have some idea why [16:16:42] in my branch I have updated all mission scenerios. [16:17:37] and I have a python upsate script [16:17:43] Okay so implementation wise you would load everything as we do now and then knowing what NASSPVER is, have instances of a ScnUpdater(?) class use patch whatever stuff is required. [16:17:51] /s/upsate/update [16:18:11] You wouldn't need anything but the old and new NASSPVER and a pointer to the vehicle I think [16:19:50] ScnUpdater could get complicated very fast if we're not careful [16:20:44] I was just thinking of an oapiDebugString warning for outdated versions. [16:21:11] So no automatic updating of scenarios at all? [16:21:20] Basically the way I have it now? [16:26:24] I'm not against updating them, but I just worry about the state of the updater down the road. it will have to apply updates recursively and we would probably need to set a cutoff for the oldest version we support at some point. [16:26:56] maybe I'm making it more complicated than it needs to be [16:27:51] If we only do an update from one version back it would be a lot simpler. [16:28:00] Your changes will also be a good test case [16:29:03] ooookay that would be fine then [16:30:43] so it's really just applying this https://gist.github.com/n7275/8cab7e348507ff4bce4749d09e2c3894 [16:30:43] [ updatespecificheat.py · GitHub ] - gist.github.com [16:31:46] if (scn_incompatible): updateScenario() [16:31:55] And that function would basically be your script [16:32:11] But in C++ changing the runtime variables obviously [16:32:23] Hmm [16:32:31] That would only change CurrentState though [16:32:43] Not the actual scenario you loaded from. [16:33:59] We could do the conversion and then save the scenario. As long as no timestep has run overwriting the one we loaded from should be fine I think. [16:36:14] it would need to run beore the scenerio gets loaded, or at least before the NASSP-specific parts of the scenerio get loaded. [16:37:24] ...which I guess it could do when it hits the NASSPVER line [16:38:34] Then you would need to scan the file and modify it as text. You would still need to finish loading and call oapiSaveScenario though as you don't have control over the other vessels. [16:41:56] this seems messy [16:56:01] I'll work out a PoC to see how much a scenario changes if you load it and then immediately save it on the first PreStep. Hopefully not too much. [16:56:25] Then we can do the first approach of load -> patch -> save [17:05:33] okay [17:05:57] should be just the "CHM" lines [17:17:26] I'm gonna try without any changes first so I can diff them and see what changes and if those need to/can be fixed. [17:17:34] Then I'll try your changes. [17:18:13] But not tonight, I'm pretty tired :) [17:18:25] Goodnight! [17:19:27] night!