| Time |
Nick |
Message |
| 00:47 |
|
proller joined #minetest-dev |
| 00:54 |
|
Baytuch joined #minetest-dev |
| 01:05 |
|
Baytuch joined #minetest-dev |
| 01:08 |
|
panwolfram joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:21 |
|
Baytuch joined #minetest-dev |
| 04:58 |
|
calcul0n joined #minetest-dev |
| 05:01 |
|
calcul0n joined #minetest-dev |
| 06:21 |
|
Baytuch joined #minetest-dev |
| 06:24 |
|
Baytuch joined #minetest-dev |
| 06:36 |
Krock |
will merge #12540, #12632 and #12682 in 15 minutes |
| 06:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/12540 -- Textures: introduce world-align overrides by SmallJoker |
| 06:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/12632 -- Remove default keybind for range select by fluxionary |
| 06:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/12682 -- Allow buffer argument to VoxelManip:get_light_data by TurkeyMcMac |
| 06:37 |
|
cranezhou joined #minetest-dev |
| 06:37 |
Krock |
celeron55: 1,691 src/session.vim.meshgen_cache this file should probably not be there, right? |
| 06:51 |
Krock |
merging |
| 07:10 |
|
Baytuch joined #minetest-dev |
| 07:13 |
|
Baytuch joined #minetest-dev |
| 07:24 |
|
Baytuch joined #minetest-dev |
| 07:33 |
|
Baytuch joined #minetest-dev |
| 07:55 |
|
Baytuch joined #minetest-dev |
| 08:10 |
|
proller joined #minetest-dev |
| 09:05 |
|
cranezhou joined #minetest-dev |
| 09:09 |
|
cranez joined #minetest-dev |
| 09:17 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:21 |
|
Baytuch joined #minetest-dev |
| 09:21 |
celeron55 |
Krock: yeah i need to clean it all up, there's all kind of crap still |
| 09:22 |
celeron55 |
kinds* |
| 09:22 |
|
Baytuch joined #minetest-dev |
| 09:23 |
|
Fixer joined #minetest-dev |
| 09:25 |
celeron55 |
literally the first line shown in "files changed" on github is trash |
| 09:25 |
|
Baytuch joined #minetest-dev |
| 09:27 |
celeron55 |
one thing i'm not sure about is whether this fits the current roadmap. I guess it's close enough given it's meant to support a reduced-level-of-detail rendering method |
| 09:28 |
|
Baytuch joined #minetest-dev |
| 09:31 |
|
Baytuch joined #minetest-dev |
| 09:51 |
|
Baytuch joined #minetest-dev |
| 09:53 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:55 |
|
Baytuch joined #minetest-dev |
| 09:58 |
|
Baytuch joined #minetest-dev |
| 10:03 |
|
appguru joined #minetest-dev |
| 10:06 |
Zughy[m] |
I didn't know that if people block a PR with a discussion, that is a valid reason to remove an approval and also put a possible close, when no reasons are provided: #12417. This is fucking ridiculous |
| 10:06 |
Zughy[m] |
That PR is a compromise to make everyone happy, so why exactly I have to lose all my ground because of that? |
| 10:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/12417 -- Docs: add "flip moon texture" into breakage file by Zughy |
| 10:07 |
Zughy[m] |
I already had to deal with a lot of bikeshedding/erle-like arguments in the prior PR, I don't think I deserve this treatment |
| 10:09 |
Zughy[m] |
also because I am the one who improved the sky API, because of the fact I actually I had had to work on it. Contrary to them |
| 10:10 |
Zughy[m] |
*I actually had |
| 10:12 |
celeron55 |
i don't see the big deal, isn't it just rubenwardy adding an approval and then removing his approval. the possible close is weird without more comments though. but rubenwardy is right in that too much time has been used for that issue already |
| 10:13 |
celeron55 |
s/\./?/ |
| 10:13 |
Zughy[m] |
yes, and it's been used because of erle poisoning discussions with arguments that made no sense. Plus two more users jumping on the like-wagon |
| 10:14 |
Zughy[m] |
This passes the message that if I act like erle on whatever PR I don't like, there is actually a chance to see it closed because of me |
| 10:15 |
celeron55 |
i'm not thinking this in terms of erle's arguments or user likes. i barely read those to begin with |
| 10:16 |
Zughy[m] |
lucky you |
| 10:17 |
celeron55 |
i could make an argument about this from the "i made it this way and it made sense" point of view, but that would mean i'd continue the discussion i don't want to be continued to save time from everyone |
| 10:17 |
celeron55 |
save? i mean waste |
| 10:17 |
celeron55 |
wait |
| 10:17 |
celeron55 |
well you get the point |
| 10:18 |
sfan5 |
it will be reassesed anyway when the time actually comes so we can just add it to the file |
| 10:18 |
celeron55 |
https://github.com/minetest/minetest/pull/11902#issuecomment-1008064540 |
| 10:19 |
Zughy[m] |
what sfan has said |
| 10:19 |
celeron55 |
i think this comment from me should enable you to look it from a far enough standpoint |
| 10:19 |
celeron55 |
i'm fine with adding it to the file. didn't mention that yet. but also fine with not adding 8) |
| 10:21 |
celeron55 |
anyway, for that reason i'll go cleaning up my rebase instead |
| 10:22 |
celeron55 |
i have an unhealthy relationship with files that have lists of things to do |
| 10:23 |
celeron55 |
in my use, those get completely out of hand and become almost useless as there is not enough time in a human lifetime to do everything that ends up there |
| 10:26 |
Zughy[m] |
yes, that's why I've opted for 6.0. It's a silly thing so there is no hurry to add it now (the PR you've linked shows that we've already had enough chatting about compatibility). But I think that, for the sake of modder experience, having the two celestial bodies acting in the same way is an improvement (why exactly if I apply the same texture to both the bodies, when these rise one of them is upside down?). And I rest my case, I don't |
| 10:26 |
Zughy[m] |
wanna fill the chat nor make anyone waste more time |
| 10:26 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:30 |
celeron55 |
because you asked it as a question, my short explanation as the one who originally wrote it is: because when both of them are visible at the same time, they are oriented the same way when you yaw around and look at them. but this has been already discussed in the long PR so whatever |
| 10:32 |
Zughy[m] |
16 one approval PRs with 87 PRs open, we're potentially facing a new record of least PRs open in years. N I C E |
| 10:33 |
Zughy[m] |
issues are doomed though |
| 10:36 |
celeron55 |
sfan5: do you want my approval to merge 12417? |
| 10:36 |
celeron55 |
because if i comment "i'm fine either way" that's considered an approval |
| 10:37 |
celeron55 |
well whatever, did it anyway |
| 10:37 |
|
HuguesRoss joined #minetest-dev |
| 10:51 |
|
fluxionary_ joined #minetest-dev |
| 10:55 |
|
Baytuch joined #minetest-dev |
| 10:59 |
|
Baytuch joined #minetest-dev |
| 11:08 |
Zughy[m] |
was there an issue about freeing more AUX keys? I can't find it |
| 11:13 |
Krock |
yes I remember there's one |
| 11:13 |
Krock |
#11446 Zughy[m] |
| 11:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/11446 -- Add Aux2 key for games to use freely, and maybe Aux3, Aux4, etc.? |
| 11:51 |
appguru |
Zughy: The problem with your PR still is that there are no good reasons for the change (vs. the reasons against the change) - as ruben said, he's fine "either way" - and making the change is always more effort than leaving it as is, thus ruben should have closed the PR. |
| 11:56 |
Baytuch |
gday, MineTest developers |
| 12:04 |
celeron55 |
Minetest |
| 12:04 |
celeron55 |
Copyright (C) 2010-2022 celeron55, Perttu Ahola <celeron55 gmail.com> |
| 12:04 |
celeron55 |
holy shit that's a long time |
| 12:05 |
celeron55 |
i'm just making a new file and using the opportunity |
| 12:05 |
celeron55 |
new file based partially on old files |
| 12:43 |
|
Fixer joined #minetest-dev |
| 12:52 |
|
Alias joined #minetest-dev |
| 13:30 |
Zughy[m] |
Is #1414 still true after the huge particle PR we've seen in 5.6? |
| 13:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/1414 -- Particles are very slow |
| 13:39 |
Krock |
paricles were made fancier, not faster. |
| 13:49 |
rubenwardy |
unfortunately |
| 14:13 |
Fixer |
I reproduce https://github.com/minetest/minetest/issues/10844 shader related error, ask me anything |
| 14:13 |
Fixer |
another question: how taxing are shadows? I've turned them to very low and got 3 fps o_o |
| 14:15 |
rubenwardy |
merging #12678 and #12667 |
| 14:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/12678 -- Reassure previous `nil` behaviour for `tiles` and `special_tiles` by Zughy |
| 14:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/12667 -- Check hp_max > 0 for entities by appgurueu |
| 14:15 |
rubenwardy |
in 10 |
| 14:15 |
rubenwardy |
Fixer: quite, you'll need a recent GPU |
| 14:15 |
Fixer |
i have to say minetest is waaaaay moooore smoother these days, silky smooth |
| 14:15 |
Fixer |
ah, my Intel HD gives me 3 fps, but very solid fps with it turned off |
| 14:15 |
rubenwardy |
shadows are an optional feature very much not for lower end or older hardware |
| 14:16 |
rubenwardy |
I get decent FPS with shadows on my Intel iGPU |
| 14:16 |
Fixer |
i5-3450 (almost 10 yr old cpu) |
| 14:18 |
Krock |
pretty sure this is limited to Intel HD every time |
| 14:19 |
Krock |
send a memo to their headquarters to finally fix their buggy drivers |
| 14:23 |
Fixer |
i'm still waiting for proper rx6400 price |
| 14:25 |
Krock |
you could as well get a used GTX 16XX or RX4XX / RX5XX card which still hold well nowadays |
| 14:26 |
Zughy[m] |
is it random that all the people who reported the bug are on Windows? |
| 14:28 |
Krock |
give my laptop a few minutes and I'll tell you if the same issue happens on Linux |
| 14:32 |
Krock |
9 FPS on Intel HD 4000 with highest shadow setting. no shader error, this is the Windows driver's fault |
| 14:33 |
Krock |
correction: it's just set to "High" and not "Very High" |
| 14:34 |
Zughy[m] |
I'll label it |
| 14:34 |
Krock |
60 FPS with all shaders enabled, and shadows to "Very Low" |
| 14:36 |
Krock |
that's at range 100. 61 FPS without vsync. that's the most I can get out from this 3rd gen i7 |
| 14:38 |
Krock |
updated my post accordingly too, for the sake of completeness. |
| 15:13 |
|
proller joined #minetest-dev |
| 15:13 |
Krock |
hmm. interestingly on Linux it reports OpenGL 3.0 whereas TechPowerUp lists 4.0 as supported version |
| 15:13 |
Krock |
presumably the additional OpenGL extensions are flawed |
| 15:14 |
Krock |
Fixer: if you can figure out how to force OpenGL 2.1 or 3.0 on your Intel HD iGPU. please report if anything changes |
| 15:15 |
Fixer |
I don't know if this is possible, maybe some irrlicht option? |
| 15:15 |
Krock |
on Linux it can be done using an environment variable... but that's Mesa3d-specific |
| 15:16 |
Krock |
no idea though how to do that on Windows. hopefully Google knows more |
| 15:28 |
Fixer |
it probably requires editing mt sources |
| 15:30 |
Fixer |
interestingly i don't have this error on 5.5.1 with same confug |
| 15:32 |
Fixer |
updated my post: so something was changed in those 3 months that causes this error on my system, funny enough original user had this same error on 5.4.0 |
| 15:33 |
Fixer |
5.4.0-6d7067f to be precise |
| 16:08 |
MTDiscord |
<savilli> Any objections to fixing android build for x86? |
| 16:17 |
sfan5 |
the x86 build probably already works just isn't enabled by default |
| 16:18 |
MTDiscord |
<savilli> nope, it doesn't, it has linker problems |
| 16:18 |
sfan5 |
we can fix that then |
| 16:18 |
MTDiscord |
<savilli> okay, I almost have a fix |
| 17:05 |
|
Fixer_ joined #minetest-dev |
| 18:44 |
MTDiscord |
<x2048> Just added #12692 which improves performance of shadow-enabled worlds significantly. It's tiny. |
| 18:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/12692 -- Limit force shadow update to urgent blocks by x2048 |
| 18:45 |
rubenwardy |
do you observe an FPS improvement? |
| 18:46 |
MTDiscord |
<x2048> from 25 to 50+ fps. especially with longer view ranges. |
| 18:46 |
rubenwardy |
nice |
| 18:47 |
MTDiscord |
<x2048> the problem was, I force full SM update every time a mesh arrived, but 99% of them are distance meshes, and it happens on every move. |
| 18:47 |
MTDiscord |
<x2048> the change is to force only when an 'urgent' mesh arrives, like digging or building. |
| 19:24 |
|
appguru joined #minetest-dev |
| 20:31 |
MTDiscord |
<x2048> Merging #12679 in a min |
| 20:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/12679 -- Reduce the use of porting::getTimeMs() when rendering frames by x2048 |
| 20:34 |
MTDiscord |
<x2048> Merged |
| 20:40 |
|
proller joined #minetest-dev |
| 20:41 |
|
calcul0n_ joined #minetest-dev |
| 21:11 |
|
cranezhou joined #minetest-dev |
| 21:24 |
Zughy[m] |
sfan5: should I close #12680 ? |
| 21:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/12680 -- fix: update Gitlab CI by cat-master21 |
| 21:28 |
|
Taoki joined #minetest-dev |
| 21:29 |
sfan5 |
eh, we can wait for them to do it themselves |
| 21:35 |
sfan5 |
can anyone look at #12616 |
| 21:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/12616 -- Move some CI jobs to newer compiler versions by sfan5 |
| 21:38 |
rubenwardy |
what's our minimum compiler requirements? |
| 21:38 |
schwarzwald[m] |
They're listed in the README.md |
| 21:39 |
rubenwardy |
surely that's outdated |
| 21:40 |
sfan5 |
no its accurate |
| 21:40 |
sfan5 |
just not regularly tested |
| 21:41 |
rubenwardy |
well, given that the compilers aren't the min already then +1. But it's probably worth having CI checks on the minimum compiler versions as most devs will be using something newer |
| 21:41 |
rubenwardy |
for building packages, using the most recent compilers makes the most sense |
| 21:42 |
schwarzwald[m] |
The last time I tried to test the minimum GCC version there was a dependency with a version I couldn't get IIRC. I had to install the old version of the compiler on a newer system before it worked. I think we may have bumped the version since then, though. |
| 22:03 |
|
cranezhou joined #minetest-dev |
| 22:12 |
sfan5 |
merging #12616 in 5m |
| 22:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/12616 -- Move some CI jobs to newer compiler versions by sfan5 |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
AliasAlreadyTake joined #minetest-dev |
| 23:13 |
|
proller joined #minetest-dev |
