Time Nick Message 17:03 sfan5 merging #17684, #17683, #17649 in 15m 17:03 ShadowBot https://github.com/luanti-org/luanti/issues/17684 -- Ignore packets with bad blockpos by paradust7 17:03 ShadowBot https://github.com/luanti-org/luanti/issues/17683 -- Rename custom gettext header to 'X-Source-Language' by SmallJoker 17:03 ShadowBot https://github.com/luanti-org/luanti/issues/17649 -- Improve 'About' tab styling by sfan5 17:29 MTDiscord 👁️ 17:29 sfan5 👀 17:32 sfan5 Checking for the ability to merge automatically... Hang in there while we check the branch's status. 17:35 MTDiscord yeah that's annoyed me a couple times as well 17:35 MTDiscord already figured that was holding you up 😄 17:45 sfan5 we still need to update the credits for release btw 17:54 MTDiscord merging #17691 #17690 #17685 in 10m 17:54 ShadowBot https://github.com/luanti-org/luanti/issues/17691 -- [no sq] Two fixes (local animations, minimap format string) by appgurueu 17:54 ShadowBot https://github.com/luanti-org/luanti/issues/17690 -- Builtin: Remove "full | quick" translations by Wuzzy2 17:54 ShadowBot https://github.com/luanti-org/luanti/issues/17685 -- Fix matrix-to-quaternion conversion near 180 degree rotations by bjorn 18:31 sfan5 i started thinking about what if the server thread could offload work to background threads just like Lua can 18:31 sfan5 but then realized the most important and impactful refactor we need to do is divorcing the server and emerge threads 18:33 sfan5 ...compared to writing something new and cool that is quite the annoying task 18:37 sfan5 I think it's actually not possible to fix for mapgen atm, because we need to run old on_generated 18:37 sfan5 ... 18:37 sfan5 *I think it's actually not possible to fix for mapgen atm, because we need to run the old on_generated callbacks - which expect mapgen objects and stuff to be available - so you do actually need to halt the emerge thread to do this the way it's supposed to work, and can't use a result queue 18:39 MTDiscord <.zenonseth> not quite the same but a month or so ago i started doing some work for #15125, def not the same amount of timesave but offloading those to their thread helps a fair bit especially on slow disks 18:39 ShadowBot https://github.com/luanti-org/luanti/issues/15125 -- Busy Disks Cause Lag (map loading/saving in server thread) 18:40 MTDiscord <.zenonseth> cause that seemed definitely doable 18:42 MTDiscord <.zenonseth> *offloading those = offloading mapblock writes to their own thread 18:44 sfan5 yeah having a worker thread handle map writing would help too. an important point to deal with is "what if the queue just keeps growing" tho 18:46 MTDiscord <.zenonseth> ideally wouldn't happen a lot but i guess at some point if too large then a write request should just become blocking like it is now and cause lag? I did test what i had btw, with simulated slower disk writes since im on an ssd, and flying through the world def had a much faster emerge, thouguh i didn't log the queue size 18:48 MTDiscord <.zenonseth> er faster emerge meaning less lag as i was flying towards ungenerated land on local server it manifested as looking like faster emege 18:50 MTDiscord <.zenonseth> oh i did have something about queue size limit, i don't know how close i got to a PR, but i can make one prob this weekend - I'm more or less trying to avoid too many PRs and now my goal is trying to help close PRs but this may be worth it 18:53 sfan5 hmm another problem is that deserializing blocks can modify the nodedef (due to unknown nodes) 18:56 MTDiscord <.zenonseth> that's just on the load side right? what I have only moves writes to a worker thread, shouldnt mess with that 18:58 sfan5 sure, was thinking about my idea earlier, not yours. 18:58 MTDiscord <.zenonseth> ah ok 19:03 sfan5 so I think the first is actually adding an rw-lock to the nodedef 19:05 sfan5 and i guess itemdef too 19:06 sfan5 >TODO: these should be made const-safe so that a const IGameDef* is actually usable 19:06 sfan5 :s 19:06 MTDiscord <.zenonseth> couldn't resolution of unknown nodes be deferred until emerge is done and given to be inserted in the map data? like even skip resolving ids entirely? 19:06 Krock apply "mutable" to problem area 19:08 sfan5 in theory yes, however 1) the edge case (unknown nodes) now dictates the performance of the common case 2) this pulls apart the block deserialization process across different queues and threads, will be hard to understand 19:15 sfan5 https://github.com/luanti-org/luanti/blob/32bb549cff23249c11c6be301d0c2270caaab627/src/gamedef.h#L28-L29 this comment is a blatant lie 19:16 Krock the pointer is perhaps only set once, which is the only true thing 19:16 Krock it's only 15 years old 19:56 celeron55 it used to be true, then someone changed something and didn't update the comments. that's the lifecycle of comments in general 19:58 sfan5 to be fair it was correct in 0.3 20:07 sfan5 it's funny how //lua core.get_craft_result({items={[999999999]=""}}) causes an out-of-memory error 20:24 sfan5 moving the entire block deserialization outside of the lock is actually reasonably achieveable. you "only" need an rw-lock in NodeDefManager