| Time |
Nick |
Message |
| 00:47 |
|
_10KBps joined #luanti-dev |
| 00:47 |
|
Lai0602 joined #luanti-dev |
| 00:49 |
|
user333_ joined #luanti-dev |
| 01:40 |
|
erbium joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 06:20 |
|
book`_ joined #luanti-dev |
| 09:02 |
|
AliasAlreadyTake joined #luanti-dev |
| 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:08 |
|
Panquesito7 joined #luanti-dev |
| 17:29 |
MTDiscord |
<luatic> 👁️ |
| 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 |
<luatic> yeah that's annoyed me a couple times as well |
| 17:35 |
MTDiscord |
<luatic> already figured that was holding you up 😄 |
| 17:45 |
sfan5 |
we still need to update the credits for release btw |
| 17:54 |
MTDiscord |
<luatic> 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:12 |
|
BuddyTheBud joined #luanti-dev |
| 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 |
| 21:41 |
|
Panquesito7_ joined #luanti-dev |
| 22:42 |
|
panwolfram joined #luanti-dev |
