| Time |
Nick |
Message |
| 01:29 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:06 |
MTDiscord |
<mnh48> anyone know if the builtin locale files & template are up to date? |
| 04:06 |
MTDiscord |
<mnh48> if the strings are freeze'd then might want to run the translation script for builtin so translators can start translating builtin for next release |
| 04:06 |
MTDiscord |
<mnh48> (looking at repo the template is like 8 months old) |
| 04:06 |
MTDiscord |
<mnh48> if the strings are not freeze'd yet, please remember to run the translation script against builtin when nearing the day of release to give time for translators making PR for it |
| 04:59 |
|
srifqi joined #minetest-dev |
| 05:00 |
srifqi |
last time I checked it (a few days ago), there are no new strings in builtin |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:02 |
srifqi |
ah, the Discord bridge just disconnected right before I sent it |
| 05:02 |
srifqi |
last time I checked it (a few days ago), there are no new strings in builtin |
| 05:04 |
srifqi |
running `python util\mod_translation_updater.py builtin` does not add nor remove any string |
| 05:04 |
srifqi |
the order is different, though |
| 05:05 |
srifqi |
yup, just run the script and there are no new strings |
| 05:15 |
MTDiscord |
<mnh48> ah, so it's just some kind of shuffling around of the existing strings |
| 05:28 |
srifqi |
I wonder whether we should just use the ordering from the script (when a new string is added) |
| 05:30 |
srifqi |
since the script orders it based on string location and file name |
| 05:38 |
MTDiscord |
<jordan4ibanez> I was wondering if there was any support/excitement for https://github.com/minetest/minetest/issues/14040 because I know exactly what I need to do and how I need to do it. I am checking this information before I start working on the PR |
| 05:42 |
Mantar |
not sure there's a big demand; I think most people are waiting for gltf to get here, or they have b3d tooling set up already |
| 05:43 |
Mantar |
but easier tooling would answer one of the major complaints about b3d |
| 05:46 |
Mantar |
The other major complaint I've heard is its inefficiency. Apparently file size grows too quickly with increasing poly count, much more than other formats. That might be something to do with the binary exporters, and if so, JSON could fix that too |
| 05:50 |
MTDiscord |
<jordan4ibanez> I think this has to do with the fact that b3d is embedding a tree list with C strings and byte counts within it |
| 05:51 |
MTDiscord |
<jordan4ibanez> If you load up a b3d file in vscode, you can actually see the cstrings everywhere |
| 05:51 |
Mantar |
ah |
| 05:52 |
Mantar |
interesting |
| 05:52 |
MTDiscord |
<jordan4ibanez> I think I'm just going to be dumb and make the PR anyways |
| 05:54 |
Mantar |
yeah, it might help somebody out there get modelling |
| 07:42 |
MTDiscord |
<jordan4ibanez> If at least one person's day has been improved by the modeling format, I will have done my job correctly |
| 08:11 |
|
calcul0n joined #minetest-dev |
| 08:27 |
Mantar |
that's a good way to think about it! ^_^ b |
| 09:22 |
|
Warr1024 joined #minetest-dev |
| 09:28 |
|
calcul0n joined #minetest-dev |
| 09:46 |
|
Warr1024 joined #minetest-dev |
| 11:46 |
MTDiscord |
<luatic> Mantar: I think that might be due to the exporter writing weights for every vertex for every bone. |
| 11:46 |
MTDiscord |
<luatic> (the blender exporter, that is) |
| 11:47 |
MTDiscord |
<luatic> you can often achieve significant space savings just by re-encoding with modlib, since it strips zero weights |
| 12:27 |
|
appguru joined #minetest-dev |
| 14:12 |
|
Desour joined #minetest-dev |
| 14:21 |
Krock |
Meeting in ~40 minutes |
| 14:50 |
|
srifqi joined #minetest-dev |
| 15:00 |
srifqi |
hello |
| 15:00 |
Krock |
Meeting ping for those who reacted. sfan5 Desour srifqi |
| 15:01 |
Krock |
hello srifqi :) |
| 15:02 |
srifqi |
:D |
| 15:02 |
Krock |
First topic: https://github.com/minetest/minetest/milestone/22 |
| 15:02 |
Krock |
!topic |
| 15:02 |
ShadowBot |
Krock: FEATURE FREEZE IN EFFECT | Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 15:02 |
Krock |
!title |
| 15:02 |
ShadowBot |
5.8.0 Milestone · GitHub |
| 15:03 |
Krock |
#13961 is slightly annoying but not a blocker |
| 15:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/13961 -- Strange behavior when dragging&dropping from MTG creative inventory (since #13146) |
| 15:03 |
srifqi |
issue 13822 already has fixes: PR 13872 and even PR 14029 |
| 15:03 |
Krock |
so far only #13872 and the credits are open tasks |
| 15:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/13872 -- Formspec: Pass the second-touch event as is by srifqi |
| 15:04 |
srifqi |
i don't know enough to have opinion about issue 14007 |
| 15:04 |
Krock |
I tried to find a difference between that issue and the PR that is supposed to fix it |
| 15:05 |
Krock |
apparently I did not do it properly because there was no difference |
| 15:06 |
srifqi |
... and i don't have device with older OpenGL version |
| 15:07 |
Krock |
it would be possible to use OpenGL's environment variables to force a version by software |
| 15:07 |
Krock |
although that does not emulate whatever bugs there are with old hardware |
| 15:08 |
Krock |
I see. Desour also couldn't reproduce on the (presumably) AMDGPU driver, just like me |
| 15:08 |
Desour |
if you use the mesa software renderer, (or zink, I think), you can get the issue that anisotropic filter enables bilinear filter |
| 15:08 |
Desour |
I could not yet reproduce the other fixed issue(s) |
| 15:11 |
srifqi |
which issue? |
| 15:11 |
Krock |
it would also be interesting to know whether the "LGTM" in #14016 are actually tested or just a "code LGTM, ship it." |
| 15:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/14016 -- [no squash] Return texture filter settings to previous state by sfan5 |
| 15:12 |
Krock |
srifqi: #14007 there are a few filtering issues, apparently. |
| 15:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/14007 -- Texture filtering regressions (biilinear and trilinear filtering broken, anisotropic filtering results inconsistent depending on GPU) |
| 15:12 |
srifqi |
oh, i thought it was another issue |
| 15:14 |
Desour |
one other issue is that for Warr1024 apparently the bilinear minification doesn't work anymore |
| 15:15 |
Krock |
what does "minification" mean in this context? |
| 15:15 |
Desour |
the 3rd issue is, I think, just that some users liked the smooth look |
| 15:16 |
Desour |
Krock: when the texel (pixel of the texture) is smaller than a screen pixel, minification happens |
| 15:16 |
Desour |
aka downscaling |
| 15:16 |
|
BuckarooBanzai joined #minetest-dev |
| 15:16 |
Krock |
alright. I just saw the relevant comment |
| 15:19 |
Krock |
there should be a difference in the wielded item rendering depending on the filter settings |
| 15:21 |
Krock |
lol I'm not sure whether this guy is serious or not: https://github.com/minetest/minetest/issues/13822#issuecomment-1813864090 |
| 15:22 |
Krock |
haha anyway. the remaining issues should be pretty close to be fixed |
| 15:22 |
srifqi |
i mean, that is still a valid workaround :D |
| 15:23 |
Krock |
sure they're technically not wrong |
| 15:24 |
srifqi |
by the way, why is PR #13872 in 5.9.0 milestone while the issue that will be fixed by it is in 5.8.0? |
| 15:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/13872 -- Formspec: Pass the second-touch event as is by srifqi |
| 15:24 |
Krock |
srifqi: do you have an idea why #13872 is marked as 5.9.0 milestone but its issue got the 5.8.0 milestone? something must've gone wrong there |
| 15:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/13872 -- Formspec: Pass the second-touch event as is by srifqi |
| 15:24 |
Desour |
haha |
| 15:24 |
srifqi |
that is also my question |
| 15:24 |
Krock |
good timing. I think it should be set to 5.8.0 |
| 15:24 |
Krock |
I don't know why rubenwardy changed it |
| 15:25 |
Krock |
objections? |
| 15:25 |
rubenwardy |
I don't remember changing that, maybe it was accidental |
| 15:25 |
Krock |
alright :) so 5.8.0 it is. |
| 15:26 |
Krock |
this is somewhat important for 5.8.0 to not ruin the Android players' experience |
| 15:26 |
Krock |
also rubenwardy while you're here .. would you like to review/test the PR in the next few days? |
| 15:27 |
Krock |
assuming the texture filters PR also makes it way through in that time span we could finally head towards a release |
| 15:30 |
Krock |
is there any other PR that should be discussed? |
| 15:30 |
Krock |
bugfixes, maintenance, ...? |
| 15:33 |
srifqi |
none from me |
| 15:37 |
Krock |
alright then. thank you for participating. I'll head over to propose a fix for #14044 |
| 15:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/14044 -- ParticleSpawner (and maybe sound) IDs Reused |
| 15:38 |
srifqi |
thank you for organising |
| 15:39 |
Krock |
np |
| 15:40 |
srifqi |
oh, i just remembered. will the next meeting about releasing 5.8.0? |
| 15:40 |
srifqi |
... or that depends on the milestone (which already past 7 days)? |
| 15:41 |
Desour |
iirc someone wanted that we release before november, because of the game jam |
| 15:41 |
srifqi |
... and it's already November |
| 15:41 |
Desour |
december* |
| 15:41 |
srifqi |
ah, i see |
| 15:42 |
srifqi |
so ... as soon as the milestone is achieved? |
| 15:42 |
Desour |
Krock: FYI, for server sound handle reuse, there was already #12780 (not merged) |
| 15:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/12780 -- Put server sound handles into userdata by Desour |
| 15:42 |
Krock |
srifqi: hopefully the release is before the nex tmeeting |
| 15:42 |
Krock |
depends on the milestone progress. |
| 15:43 |
Krock |
Desour: sound IDs were recycled too? |
| 15:43 |
Desour |
(someone was ruben: <https://irc.minetest.net/minetest-dev/2023-11-19#i_6134124>) |
| 15:44 |
* srifqi |
is looking forward to the release |
| 15:44 |
Desour |
Krock: they still are, but only after the counter would overflow. so it wasn't considered worth fixing, iirc |
| 15:45 |
Krock |
well okay that's not too much of a concern |
| 15:45 |
Krock |
unless those IDs are not skipped and forcefully reused |
| 15:45 |
Krock |
in that case it should be fixed |
| 15:48 |
Krock |
Server::nextSoundId() |
| 15:48 |
Krock |
they are forcefully reused, which is pretty bad |
| 16:03 |
rubenwardy |
Krock: if it's ready then don't wait for me |
| 16:04 |
Krock |
rubenwardy: okay thank you for clarifying. It was mainly a question because you requested a review. |
| 16:06 |
|
Desour_ joined #minetest-dev |
| 16:24 |
|
appguru joined #minetest-dev |
| 16:28 |
|
[MTMatrix]_ joined #minetest-dev |
| 17:32 |
MTDiscord |
<greenxenith> I, too, hope for a release in November for the sake of the jam, if at all possible :] |
| 17:53 |
sfan5 |
do we have a changelog yet? |
| 17:54 |
MTDiscord |
<wsor4035> start of one: https://dev.minetest.net/Changelog#5.7.0_.E2.86.92_5.8.0 |
| 18:13 |
MTDiscord |
<luatic> Krock: I think the proper solution would be to autoincrement IDs, keeping the ID -> spawner mapping in an unordered map. Then the logic in nextSoundId becomes trivially. Overflowing is not a problem if you use a 64-bit type. On the Lua side of things, ints up to 2^53 will be accurate. Both of these numbers are high enough that I can guarantee you that it is not physically possible to hit them. |
| 18:14 |
Krock |
@luatic I already opened a PR. feel free to comment.#14045 |
| 18:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/14045 -- Server: avoid re-use of recent ParticleSpawner and Sound IDs by SmallJoker |
| 18:19 |
MTDiscord |
<luatic> commented |
| 18:21 |
Krock |
oh that was already the reply to my PR? sorry. I misunderstood the intend. |
| 18:21 |
Krock |
it would be possible to increase the bit with, but only for newer clients due to network protocol limitations |
| 18:21 |
Krock |
because particle spawners are not only removed on server/lua side but also client-side |
| 18:47 |
MTDiscord |
<luatic> ah I see, of course 🤦 |
| 18:48 |
MTDiscord |
<luatic> deleted my comment |
| 18:58 |
MTDiscord |
<warr1024> It's probably not a problem (just a little suboptimal) if deletion requests are sent to the client when things already expired client side. The client needs to be able to gracefully handle receiving requests to delete things "late" due to network latency anyway. |
| 20:17 |
sfan5 |
I didn't know multicrafts mainmenu looked that good |
| 20:22 |
MTDiscord |
<wsor4035> what specifically looks good/the best about it to you? |
| 20:24 |
sfan5 |
proper and consistent design, font, reasonable use of icons |
| 20:24 |
MTDiscord |
<wsor4035> ah, thanks |
| 22:27 |
|
appguru joined #minetest-dev |
| 22:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
| 23:33 |
|
[MTMatrix] joined #minetest-dev |
