| Time |
Nick |
Message |
| 03:35 |
|
SFENCE_arch joined #minetest-dev |
| 03:56 |
|
hwpplayer1 joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:18 |
|
SFENCE joined #minetest-dev |
| 07:07 |
|
SFENCE joined #minetest-dev |
| 07:46 |
|
Desour joined #minetest-dev |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:31 |
rubenwardy |
I suggest dropping #14999 from the milestone and releasing today |
| 08:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view |
| 08:36 |
[MatrxMT] |
<grorp> It's already fixed for 5.9.1 btw |
| 08:47 |
|
Warr1024 joined #minetest-dev |
| 09:10 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:16 |
[MatrxMT] |
<Zughy> It's a nightmare https://github.com/minetest/minetest/pull/15137#issuecomment-2351461045 |
| 09:19 |
[MatrxMT] |
<Zughy> But yes, please, let's release today, I don't wanna rush the name change and it's not like FOSDEM will wait for us if we decide to apply |
| 09:31 |
MTDiscord |
<andrey2470t> Please review #15061, it's basically almost finished. Only a few minor issues are left to fix. |
| 09:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T |
| 10:26 |
Krock |
updating changelog |
| 10:36 |
Krock |
sfan5: changelog is ready, draft of the forum page too. Would you have time today to provide the Windows binaries as usual? |
| 10:37 |
Krock |
as for macos - it's very likely that the users still have to sign it manually |
| 10:37 |
sfan5 |
the CI provides the windows binaries |
| 10:38 |
Krock |
oh perfect. so merge, tag and release is straightforward |
| 10:38 |
Krock |
my bad. it's even documented in the Wiki |
| 10:40 |
|
TenPlus1 joined #minetest-dev |
| 10:40 |
TenPlus1 |
hi folks o/ |
| 10:40 |
Krock |
Is there anyone who would like to have some more time for testing the backport branch? If not, I'd go ahead merging the branch and creating the release |
| 10:40 |
Krock |
hi TenPlus1 |
| 10:41 |
TenPlus1 |
hey krock :) |
| 10:41 |
Krock |
time-wise: in a few hours |
| 10:42 |
TenPlus1 |
I may have found a but in new async mapgen feature, or a memory leak at least |
| 10:42 |
Krock |
TenPlus1: a mod to reproduce it would be highly appreciated |
| 10:42 |
TenPlus1 |
https://codeberg.org/tenplus1/farming/commit/e3bf5f92a7d6faccce0f6e0f8569d43d20ddf897 |
| 10:43 |
TenPlus1 |
using yesterdays farming redo, make new world, enable mod, fly straight and soon memory shootsup past 1gb |
| 10:43 |
TenPlus1 |
today's farming redo, using older register_on_generated, enable mod, fly straight, memory sits around 600mb |
| 10:45 |
TenPlus1 |
one of my players noticed huge memory spikes just flying around and it seems register_mapgen_script was the issue |
| 10:46 |
Krock |
what's affected, server or client? |
| 10:47 |
TenPlus1 |
his tests were in singleplayer mostly, as were mines when memory shot up, xanadu server has 16gb so shouldnt be affected too much |
| 10:49 |
Krock |
the additional Lua instances do need some memory, but I don't know how much. It could be possible that 5 instances are spawned that each have a footprint of 100 MB |
| 10:49 |
TenPlus1 |
would that also be for every player connected to a server and generating new map ? |
| 10:49 |
TenPlus1 |
if so that could get scarey high in memory usage |
| 10:50 |
Krock |
the map is only generated once, then loaded from memory or disk |
| 10:50 |
Desour |
Krock: there's always only 1 emerge thread, so only 1 async mapgen lua state |
| 10:50 |
TenPlus1 |
I mean if 5 players were online all wandering around generating new map areas, would it still be around 5 instances per player ? |
| 10:50 |
Krock |
Desour: unless num_emerge_threads > 1 |
| 10:51 |
Desour |
well, yes |
| 10:51 |
Krock |
TenPlus1: not per player. global limit. |
| 10:51 |
TenPlus1 |
ah kewl, jsut checking |
| 10:52 |
Krock |
also check your num_emerge_threads setting. if that's set and >1, then it might explain a thing or two |
| 10:52 |
TenPlus1 |
num_emerge_threads is default, so 1 |
| 10:59 |
TenPlus1 |
will revert to using the older on_generated for now in my mods until the new async one is tried and tested |
| 11:00 |
Krock |
please open a new issue so that it's not forgotten |
| 11:00 |
TenPlus1 |
will do, any wording tips to get it noticed ? |
| 11:01 |
Krock |
include as much helpful information as you can |
| 11:08 |
TenPlus1 |
is this ok https://github.com/minetest/minetest/issues/15169 |
| 11:21 |
MTDiscord |
<andrey2470t> I've converted the atlas PR from the draft to the ready for review status |
| 11:29 |
Desour |
merging #15113 in 0.6 kis |
| 11:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/15113 -- Add support for Tracy profiler by Desour |
| 11:36 |
Krock |
TenPlus1: good enough. Thank you. |
| 11:37 |
TenPlus1 |
thanks dude, the comment you left, the 604mb was with today's commit, and 1.4gb was before todayt's commit ? |
| 11:38 |
TenPlus1 |
I dont understand the ~1 part |
| 11:44 |
Desour |
Krock: is this fine? https://github.com/minetest/minetest/pull/15113#discussion_r1760028819 |
| 11:45 |
Krock |
TenPlus1: use collectgarbage("collect") as a workaround at the end of the callback when running in a mapgen thread |
| 11:45 |
Krock |
commitsha~1 refers to one commit prior |
| 11:46 |
TenPlus1 |
ah kewl, thanks :) and I'll check out the collectgarbage |
| 11:46 |
Krock |
this should be triggered automatically. I don't yet know why it doesn't happen for the mapgen threads. |
| 11:47 |
TenPlus1 |
some mapgen mods I usually clear the vm data value at the end manually |
| 11:47 |
Krock |
Desour: well sure whatever. fortunately it's only for development purposes |
| 11:47 |
Desour |
merging then now :) |
| 11:47 |
Krock |
but it's strange how commits wouldn't work when branches do... |
| 11:48 |
TenPlus1 |
thanks for the help :) laters o/ |
| 11:49 |
Desour |
Krock: see https://cmake.org/cmake/help/latest/module/ExternalProject.html#git for the mentioned docs btw |
| 11:50 |
Krock |
Desour: thanks. |
| 11:56 |
Krock |
Desour: what do you mean in https://github.com/minetest/minetest/issues/15169#issuecomment-2351557530 ? The function is called. LuaJIT does not optimize that. |
| 11:57 |
Krock |
the table data is created too. the C++ side forces Lua to do it. |
| 11:57 |
Desour |
but it's only created once, not once per register_on_generated callback call |
| 11:58 |
Desour |
get_light_data() allocates a new large table if you don't pass it one |
| 11:59 |
Krock |
yes, but the memory usage would need to decrease at some point |
| 11:59 |
Krock |
there might be not enough going on in the Lua mapgen thread to give Lua a chance to run the cleanup |
| 12:00 |
Desour |
yep. and in the green area of the diff of 11's commit, there's no get_light_data() call |
| 12:01 |
Desour |
(green because it's a revert commit) |
| 12:01 |
Krock |
indeed. that's another hint for optimization in mods |
| 12:02 |
Krock |
(if get_light_data() or get_data() are used) |
| 12:04 |
|
hwpplayer1 joined #minetest-dev |
| 13:03 |
Krock |
SFENCE: https://github.com/minetest/minetest/pull/15137#issuecomment-2351461045 the only change that could possibly cause such thing in 5.9.1 is the network improvement. Did you yet reproduce the issue on 5.9.0? |
| 13:16 |
|
SpaceManiac joined #minetest-dev |
| 13:18 |
|
hwpplayer1 joined #minetest-dev |
| 13:28 |
pgimeno |
the problem at #15169 is quite common, see https://love2d.org/forums/viewtopic.php?p=259618#p259618 |
| 13:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/15169 -- async mapgen memory leak |
| 13:28 |
pgimeno |
btw I guess it can be closed now? |
| 13:30 |
Krock |
pgimeno: shouldn't the mapgen memory be freed after a while? the main Lua instance is used very often, thus this happens regularly there. but not for mapgen threads |
| 13:31 |
Krock |
on the other hand, Lua keeps the memory for re-using later thus it's also technically correct to keep it as-is |
| 13:31 |
pgimeno |
yes, it should but I don't think they generate enough garbage as to colloect it |
| 13:31 |
pgimeno |
one possible solution is to tune the mapgen threads' Lua garbage collector to be more aggressive |
| 13:32 |
pgimeno |
a more manual approach is the one that love2d took: to provide means for the user to free the bulk of the big object, leaving only the Lua side |
| 13:32 |
pgimeno |
(Object:release() is what does that in case of love2d) |
| 13:33 |
Krock |
the used memory in question is entirely on Lua side. nothing on C++ side needs cleanup |
| 13:35 |
pgimeno |
ah sorry, I didn't know that |
| 13:37 |
pgimeno |
then there's little that can be done: if that uses a lot of memory and is used by every thread, each thread needs its own copy, and if it's live (in use) then it can't be GC'd |
| 13:38 |
MTDiscord |
<et086> could luajit's table.clear somewhat work for that(?) |
| 13:46 |
SFENCE_arch |
Krock: No, i see it during playing/testing on 5.9.1. But I do not play so long on 5.9.0, so it can be also there. |
| 13:55 |
Krock |
SFENCE_arch: do you know roughly the hours until failure on 5.9.1 and how many hours that were tested on 5.9.0 ? |
| 14:15 |
|
Desour joined #minetest-dev |
| 14:43 |
MTDiscord |
<luatic> frogTheSecond: No, table.clear isn't helpful here; clearing a table also doesn't free the memory. This is about userdata objects which may be big, but Lua doesn't know that so its GC heuristic can't properly take it into account. |
| 14:44 |
pgimeno |
that was my hypothesis but according to Kroc.k it's not userdata |
| 14:46 |
pgimeno |
either way, table.clear wouldn't help |
| 14:47 |
MTDiscord |
<luatic> To begin, we should probably use collectgarbage("count") to determine whether this is a Lua heap usage problem or a C++ heap usage problem. |
| 14:48 |
MTDiscord |
<luatic> After that we'd need to look into heap profiling. |
| 14:48 |
MTDiscord |
<luatic> Ah I see Krock already did the collectgarbage("count") part, it does in fact appear to be a Lua heap usage problem. |
| 14:49 |
MTDiscord |
<luatic> That should make it easier to analyze at least. |
| 14:50 |
pgimeno |
it looks like just a case of too much garbage generated (because big tables with lots of objects get allocated on ever generate() call), so Desour's solution should suffice |
| 14:50 |
pgimeno |
s/ever/every/ |
| 14:51 |
MTDiscord |
<luatic> Still I'm surprised that the GC heuristic would be performing this poorly |
| 14:52 |
pgimeno |
tuning the mapgen threads' Lua garbage collector to be more aggressive is still an option |
| 14:53 |
pgimeno |
apparently that's one of the strong points of Luau, memory management |
| 14:55 |
Desour |
1GB memory usage doesn't sound like poor GC performance to me. why would it collect so eagerly by default? |
| 14:59 |
MTDiscord |
<luatic> Desour: GC pause and GC mul defaults are 200%. ("pause GC until memory is 200%, run GC at 200% of allocation speed"). These are both tunable btw. |
| 15:03 |
Desour |
does luajit adhere to these values? |
| 15:04 |
MTDiscord |
<luatic> this is from LuaJIT's luaconf.h, I see no indication that it wouldn't |
| 15:06 |
SFENCE |
Krock: It is hard to say. Pause time probaly has no effect on it. I played today from morning, but with long pauses between. Something like one to three hours active in game time it takes I estimate. |
| 15:07 |
Desour |
@luatic: ah, ok. (it's also documented in lua reference) |
| 15:10 |
|
cx384 joined #minetest-dev |
| 15:36 |
|
SFENCE joined #minetest-dev |
| 15:41 |
|
hwpplayer1 joined #minetest-dev |
| 15:43 |
|
SFENCE joined #minetest-dev |
| 16:04 |
|
turtleman joined #minetest-dev |
| 16:06 |
cx384 |
Interesting, not long ago I noticed high memory usage while trying out Minetest with a lot of recent and heavy mods, including mapgen mods. |
| 16:06 |
cx384 |
I thought it was the problem of a poorly written mod, but while profiling the memory I didn't find much and couldn't reproduce it consistently, so I just moved on. |
| 16:06 |
cx384 |
A async mapgen garbage collection problem would certainly explain this. |
| 16:39 |
|
hwpplayer1 joined #minetest-dev |
| 16:48 |
MTDiscord |
<herowl> Is there the meeting today? |
| 16:55 |
cx384 |
I think so. |
| 16:58 |
SFENCE |
Krock: Ok, I just reproduced it on 5.9.0. |
| 17:02 |
Krock |
SFENCE: good thanks |
| 17:02 |
Krock |
Yes, meeting today. Nothing was announced but it's good to do it before the release |
| 17:04 |
cx384 |
Can anyone here create an account on the dev wiki for me? I have one for the normal wiki, but it seems like I never got one for the dev wiki. |
| 17:04 |
MTDiscord |
<luatic> I don't have an account on either wiki |
| 17:07 |
[MatrxMT] |
<Zughy> Thanks for handling the meeting this week Krock |
| 17:07 |
[MatrxMT] |
<Zughy> Was too busy to remember |
| 17:12 |
MTDiscord |
<luatic> is it just me or is GitHub syntax highlighting on PRs broken |
| 17:12 |
MTDiscord |
<luatic> i'm looking at https://github.com/minetest/minetest/pull/14543/files#diff-eed156eda45af76b19e24f3f291ac7cd0d1986c991a4b56323f842544ceab99a for example |
| 17:15 |
cx384 |
Hm, for me it works on the .lua files, but not on the .cpp files. |
| 17:16 |
|
Sokomine joined #minetest-dev |
| 17:17 |
|
SFENCE joined #minetest-dev |
| 17:18 |
Krock |
it was broken in the past and is broken today. maybe they'll fix it next week. |
| 17:19 |
Krock |
cx384 @luatic : It might be best to ask ruben or post it here https://forum.minetest.net/viewtopic.php?p=437468 (which cx384 already did) |
| 17:19 |
cx384 |
I asked on the forum for a dev wiki account now, but I hope I don't have to wait for more than 6 months like some other people who left some post in the topic. |
| 17:22 |
Krock |
it would be nice to have the privileged people written down somewhere, such as https://dev.minetest.net/Organisation |
| 17:22 |
Krock |
in the past Calinou was the primary contact, who's now largely inactive when it comes to Minetest |
| 17:23 |
MTDiscord |
<wsor4035> iirc roller used to make people on the regular wiki, till the email part of it broke |
| 17:25 |
MTDiscord |
<luatic> frankly i'm wondering what the benefit of the (dev) wiki is at this point. the meeting notes could be kept in public github discussions just as well. |
| 17:25 |
MTDiscord |
<luatic> in fact everything could be kept on GH - in repos, issues, discussions, or wikis. and since GH has a public API there is no risk of lock-in. |
| 17:26 |
MTDiscord |
<wsor4035> i agree with you. also has the added benefit of not being galactically slow/503 (as the wiki has been multiple times in the past) |
| 17:27 |
celeron55_ |
there have been attempts to get rid of the devwiki in the past but none of them had enough punch to actually make it completely irrelevant. i'd be glad if that effort was finished some day |
| 17:28 |
[MatrxMT] |
<Zughy> Hurray, more stuff on GH for the vendor lock-in :/ |
| 17:28 |
[MatrxMT] |
<Zughy> Oh silly me not being able to read :)))) |
| 17:29 |
MTDiscord |
<wsor4035> today on reading is hard |
| 17:33 |
celeron55_ |
i'm open to alternatives which don't involve megacorporations (which always turn to crap), and also don't involve me being a web admin (which i absolutely hate doing). what i can do is pay the bills (i have a spotless track record in doing that) |
| 17:37 |
MTDiscord |
<wsor4035> what actually of value is on the dev wiki other than meeting announcements/notes |
| 17:38 |
MTDiscord |
<wsor4035> and release notes |
| 17:38 |
cx384 |
I personally like to have a wiki separate from github, but I think one wiki is enough maybe we can merge the dev wiki into the normal wiki. |
| 17:38 |
Krock |
@wsor4035 MT release process and rules |
| 17:42 |
celeron55_ |
what if there was simply a git repo which contained all of that, and it was hosted on github pages for the time being? then anyone from the core team could add stuff to it and it would be backed up everywhere as distributed repos, and vendor lock-in would be minimal |
| 17:43 |
celeron55_ |
and M$ will cover the hosting for the time being |
| 17:44 |
celeron55_ |
the only reason to not do it this way is if people who don't know git or aren't in the core team need to edit it, but that's not the case for the dev wiki content |
| 17:45 |
celeron55_ |
(and github even provides UI for editing the stuff in the browser, for when you don't want to actually use git) |
| 17:46 |
celeron55_ |
i know it's kind of lame, but it github pages is such a good deal |
| 17:46 |
celeron55_ |
-it |
| 17:46 |
MTDiscord |
<wsor4035> makes sense |
| 17:47 |
cx384 |
The most popular MediaWiki alternative is Google Docs -.- https://alternativeto.net/software/mediawiki/ |
| 17:47 |
celeron55_ |
the regular wiki is a bigger problem and it's chronically bad and my fault and i should improve it. but let's not go into that now |
| 17:48 |
celeron55_ |
that's funny, google docs is insanely clunky for almost every imaginable purpose |
| 17:48 |
celeron55_ |
it works for simple office folk though and isn't M$ so there's that |
| 17:49 |
|
SFENCE joined #minetest-dev |
| 17:49 |
MTDiscord |
<wsor4035> google docs is pretty decent. infinitely better than microsoft office online (o365) |
| 17:49 |
celeron55_ |
yes of course |
| 17:50 |
celeron55_ |
but when considering it as a wiki replacement, it's insanity |
| 17:50 |
MTDiscord |
<wsor4035> agreed |
| 17:50 |
|
SFENCE joined #minetest-dev |
| 17:55 |
MTDiscord |
<luatic> i could live with a repo + GH pages. though i don't see a significant advantage over using other GH features, both when it comes to lock-in and ease of use. |
| 17:55 |
MTDiscord |
<wsor4035> btw c55, what ever happen with yn5w becoming a core dev? |
| 17:55 |
MTDiscord |
<wsor4035> *happened |
| 18:00 |
Krock |
Who's available for the meeting? |
| 18:02 |
Krock |
meeting points: https://dev.minetest.net/Meetings#2024-09-15 |
| 18:03 |
SFENCE_arch |
I am here. Do not expect that it helps. |
| 18:04 |
MTDiscord |
<wsor4035> likewise |
| 18:06 |
|
SFENCE joined #minetest-dev |
| 18:07 |
MTDiscord |
<luatic> I am here too |
| 18:07 |
Krock |
> 5.9.1 |
| 18:08 |
Krock |
after this meeting I'll push the branch to stable-5, tag release and post the forum topic |
| 18:08 |
Krock |
thanks to SFENCE_arch for reproducing the last concern on 5.9.0, hence we are good to go. |
| 18:08 |
Krock |
comments? |
| 18:09 |
MTDiscord |
<wsor4035> seems fine |
| 18:09 |
SFENCE_arch |
I am fine with it too. |
| 18:11 |
Krock |
> next #14543 |
| 18:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus |
| 18:12 |
Krock |
@herowl what would you like to discuss? |
| 18:13 |
Krock |
and what is this? https://github.com/minetest/minetest/pull/14543/files#diff-eed156eda45af76b19e24f3f291ac7cd0d1986c991a4b56323f842544ceab99aR167 |
| 18:14 |
Krock |
a "goto" replacement, I presume |
| 18:14 |
MTDiscord |
<luatic> goto for breaking an outer loop is fine IMO |
| 18:14 |
MTDiscord |
<luatic> I'm re-reviewing the PR btw |
| 18:15 |
Krock |
same. this notation looks unusual and if the compiler isn't smart enough, it might even create a cursed, separate function for it. |
| 18:18 |
|
SFENCE joined #minetest-dev |
| 18:24 |
Krock |
no response in 10 minutes. continuing with |
| 18:24 |
Krock |
> Thoughts on the latest proposed core dev |
| 18:25 |
Krock |
Zughy: context? when it comes to internal team discussions, that page on GitHub is commonly the best choice |
| 18:25 |
MTDiscord |
<wsor4035> i assume https://github.com/orgs/minetest/discussions/81#discussioncomment-10534184 since no one responded |
| 18:25 |
MTDiscord |
<wsor4035> and might as well say the one above as well |
| 18:26 |
Krock |
question is whether we benefit from more cooks |
| 18:26 |
MTDiscord |
<wsor4035> 1,2k issues and 111 prs would say yes |
| 18:26 |
SFENCE_arch |
Is not this the same developer as celeron ask for opinions after previous meeting? |
| 18:27 |
MTDiscord |
<wsor4035> the one above is, not the linked one |
| 18:28 |
Krock |
@wsor4035 I meant it in the sense whether there will be more activity this way. It can motivate, I suppose. |
| 18:28 |
SFENCE_arch |
red-001 looks to have some knowleadge about security. it can be helpful. :) |
| 18:31 |
MTDiscord |
<wsor4035> anyways, ultimately both requires celeron55 input |
| 18:34 |
Krock |
right. It's not too urgent and it'll pop up sooner or later |
| 18:34 |
Krock |
Any other points? |
| 18:34 |
MTDiscord |
<wsor4035> nope, next topic? |
| 18:34 |
[MatrxMT] |
<Zughy> I can't think of any |
| 18:35 |
Krock |
there's the general reminder to have a look at the one approval PRs |
| 18:36 |
MTDiscord |
<wsor4035> didnt > (low priority) Future development cycle idea by pgimeno. Almost permanent feature freeze. (again, Krock) get skipped? |
| 18:37 |
Krock |
yes. honestly I have my doubts whether this is easily feasible at all |
| 18:37 |
Krock |
the development cycle is simply slow |
| 18:37 |
MTDiscord |
<wsor4035> probably more applicable to discuss when more people are here |
| 18:38 |
Krock |
Unfortunately the meetings are very poorly attended as of lately... hopefully we'll have a more active one in the future |
| 18:40 |
SFENCE_arch |
Maybe another change of time. Does last change of time helps? |
| 18:41 |
|
SFENCE joined #minetest-dev |
| 18:41 |
Krock |
The meetings used to be around this time prior to srifqi's request |
| 18:42 |
MTDiscord |
<herowl> Krock: my battery had died |
| 18:42 |
|
hwpplayer1 joined #minetest-dev |
| 18:45 |
MTDiscord |
<herowl> Anyway the whole point was to get another review round |
| 18:49 |
|
SFENCE joined #minetest-dev |
| 18:50 |
Krock |
okay. The reviews will follow. I might have a look at it too. |
| 18:50 |
Krock |
alright then. doing the release part now. |
| 19:02 |
celeron55_ |
yes please discuss about y5nw |
| 19:02 |
Krock |
rubenwardy or nrz: would you please be so nice to provide signed apk's for the GitHub downloads? |
| 19:03 |
celeron55_ |
i will quote myself: "i talked with y5nw about adding them to the core team. y5nw would be starting slowly as they don't know that much of the codebase but would be ready to join. so, i'm asking for comments from the core team" "y5nw is also fine with joining later. so alternatively we can e.g. schedule it, or whatever. but that feels awfully arbitrary to me, so i'm proposing just adding to the |
| 19:04 |
celeron55_ |
team" |
| 19:04 |
[MatrxMT] |
<Zughy> https://matrix.org/_matrix/media/v1/download/matrix.org/vFbOwsnkzXAjNRvdkHEpRAYr |
| 19:04 |
[MatrxMT] |
<Zughy> they're merging into one |
| 19:05 |
MTDiscord |
<wsor4035> i get nice json errors from that link |
| 19:05 |
MTDiscord |
<luatic> i think matrix broke the way they did images |
| 19:05 |
MTDiscord |
<wsor4035> c55, only a triager, but that makes sense |
| 19:06 |
MTDiscord |
<luatic> images used to be just plain links to images accessible to anyone, now you essentially need to auth? so hence the matrix bridge which just forwards the links is now broken. it would have to download the image and reupload it for discord. |
| 19:06 |
[MatrxMT] |
<Zughy> It's a screenshot saying |
| 19:06 |
[MatrxMT] |
<Zughy> "macOS 12 support (sfance)" |
| 19:06 |
MTDiscord |
<wsor4035> https://cdn.discordapp.com/attachments/747163566800633906/1284953581304414218/vFbOwsnkzXAjNRvdkHEpRAYr.png?ex=66e881c7&is=66e73047&hm=b20be3e57ba3195b6c0647635a9f8a5a87f95c96086e717386145bc5ede22dd6& |
| 19:07 |
MTDiscord |
<warr1024> any relation to sfen5? |
| 19:07 |
MTDiscord |
<wsor4035> will be publically viewable for whatever discords limits on images now |
| 19:07 |
Krock |
Zughy: broken link. I'll fix the typo. also adding the release date. |
| 19:08 |
|
v-rob joined #minetest-dev |
| 19:11 |
[MatrxMT] |
<Zughy> since there a few of us here, can we start talking about the rename? For instance, do we really need GitLab as a mirror due to Codeberg? |
| 19:12 |
[MatrxMT] |
<Zughy> I can personally look into the Liberapay renaming, and I invite everyone to share their two cents about the gh org name (in the internal discussion, NOT in here) https://github.com/orgs/minetest/discussions/99 |
| 19:14 |
Krock |
celeron55_: or we could add them as Triager first and then move to the core devs when they're more familiar with the codebase? I have the feeling that in the past, nominees had a longer history of minetest contributions - but that might just be me. After all there's no entrance rules. |
| 19:14 |
|
SFENCE joined #minetest-dev |
| 19:14 |
MTDiscord |
<wsor4035> triager is completely different than core dev.... |
| 19:14 |
MTDiscord |
<herowl> wsor: +1 |
| 19:14 |
Krock |
@wsor4035 allows for issue management at first, without dangerous repository access |
| 19:15 |
Krock |
granted, it's for a different purpose. you're right. |
| 19:15 |
[MatrxMT] |
<Zughy> I actually have dangerous repository access :^] |
| 19:15 |
Krock |
Zughy: oh no please don't delete the 1200 issues |
| 19:15 |
[MatrxMT] |
<Zughy> :,( |
| 19:15 |
MTDiscord |
<wsor4035> so sad |
| 19:23 |
|
SFENCE joined #minetest-dev |
| 19:26 |
[MatrxMT] |
<y5nw> celeron55: may I propose moving the discussion about me to the 2024-10-13 meeting? (mainly due to personal reasons) |
| 19:33 |
celeron55_ |
y5nw: certainly. (altough, we don't tend to have agendas set so far into the future) |
| 20:07 |
|
SFENCE joined #minetest-dev |
| 20:09 |
MTDiscord |
<andrey2470t> Rebased #15061 |
| 20:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T |
| 20:19 |
[MatrxMT] |
<grorp> merging #15163, #15164 in 30 min or so |
| 20:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/15163 -- Avoid cloud jump when switching between mainmenu and loading screen by grorp |
| 20:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/15164 -- Don't use fixed pipeline lighting for stars by grorp |
| 20:28 |
|
SFENCE joined #minetest-dev |
| 21:04 |
|
SFENCE joined #minetest-dev |
| 21:15 |
sfan5 |
https://github.com/flathub/net.minetest.Minetest/pull/67 does anyone want to test this before I merge it |
| 21:18 |
sfan5 |
also structural feedback welcome for #15151 |
| 21:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/15151 -- [no sq] Divorce map database locking from env lock by sfan5 |
| 21:22 |
|
SFENCE joined #minetest-dev |
| 21:36 |
[MatrxMT] |
<Zughy> grorp: forgot? |
| 21:40 |
|
SFENCE joined #minetest-dev |
| 21:51 |
MTDiscord |
<luatic> sfan5: installed, doesn't blow up |
| 21:51 |
MTDiscord |
<luatic> i can play CTF with it |
| 21:53 |
|
SFENCE joined #minetest-dev |
| 22:12 |
|
hwpplayer1 joined #minetest-dev |
| 22:13 |
|
SFENCE joined #minetest-dev |
| 22:33 |
|
panwolfram joined #minetest-dev |
| 22:49 |
|
SFENCE joined #minetest-dev |
| 22:56 |
|
vampirefrog joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:30 |
|
SFENCE joined #minetest-dev |
| 23:44 |
MTDiscord |
<herowl> Any ideas on what's the best way to separate the Ambient Occlusion from the light data here: https://github.com/minetest/minetest/blob/4aec4fbe6f62688bc7dee3c227c0241eee977c7e/src/client/mapblock_mesh.cpp#L148-L250 ? |
| 23:45 |
MTDiscord |
<herowl> Is making it return an u32 instead of u16 and adding it as a separate parameter a good idea? |
| 23:47 |
MTDiscord |
<herowl> Considering there are only 4 possible values of ambient occlusion in this function (none or one of the 3 from the lookup table near the bottom of function), another option would be to devote just 7 bits to light_day and light_night each and have remaining 2 bits encode the ambient occlusion... |
| 23:47 |
MTDiscord |
<herowl> Another option is passing a pointer as a parameter to place the ambient occlusion outcome directly where it'd be used later... |
| 23:52 |
MTDiscord |
<herowl> It seems that the ultimate outcome of this function ends up either at https://github.com/minetest/minetest/blob/4aec4fbe6f62688bc7dee3c227c0241eee977c7e/src/client/content_mapblock.cpp#L262 or at https://github.com/minetest/minetest/blob/4aec4fbe6f62688bc7dee3c227c0241eee977c7e/src/client/content_mapblock.cpp#L472 where it's disassembled and put in a struct anyway |
| 23:55 |
|
SFENCE joined #minetest-dev |
