| Time |
Nick |
Message |
| 00:04 |
Desour |
>Client render thread spends 25-35% receiving and unpacking network data | en-/decompression could be done in a different thread (actually, block serialization isn't optimized much (I've recently tried to improve to-disk serialization, see <https://github.com/Desour/minetest/tree/mapblock_serialize_opt> (by removing useless copies and 0-inits and using a simple identity name-id-mapping) (haven't measured very noticeable improvements, probably |
| 00:04 |
Desour |
because I also meassured the non-disk stuff) (dont try that branch with maps you want to keep))) |
| 00:06 |
Desour |
btw. would it make sense to use copy-on-write mmappings instead of copying mapblock data? |
| 00:27 |
|
AliasStillTaken joined #minetest-dev |
| 00:29 |
|
lhofhansl joined #minetest-dev |
| 00:30 |
lhofhansl |
Hello. About to merge #13105 (trivial) |
| 00:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/13105 -- Report collisionMoveSimple for client and server. by lhofhansl |
| 00:30 |
MTDiscord |
<x2048> Desour: It turned out we more time queueing blocks in memory than deserializing https://irc.minetest.net/minetest-dev/2023-01-07#i_6045673 |
| 00:34 |
Desour |
ah right, I somehow mistakenly thought that were separate statistics |
| 00:37 |
lhofhansl |
Block serialization should be much better since I've added Zstd (de)compression. Can still be improved, of course. |
| 00:38 |
lhofhansl |
Curious, do other folks see a lot of time spent on the render thread is skinned meshes? |
| 00:39 |
Desour |
(using zstd dictionaries would be a cool thing) |
| 00:39 |
lhofhansl |
Irrlicht reskins every animated mesh twice (!) per frame. |
| 00:40 |
lhofhansl |
Desour: Yes. How would you seed the dictionaries? |
| 00:42 |
Desour |
lhofhansl: start with an empty dict, then train it on each de/compression (but still use the old dict), and send the current dict in regular intervals |
| 00:43 |
lhofhansl |
We could also switch to new versions of Zstd. I could not even use the new APIs they weren't available everywhere. |
| 00:45 |
lhofhansl |
Some zstd stats here btw: #10788 |
| 00:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/10788 -- Switch MapBlock compression to zstd by lhofhansl |
| 00:47 |
lhofhansl |
Been mostly focusing on the server side of things. There are other things to do. For example all block data is save as a blob into the database. The timestamp of the block is updated very frequently and each time we need to re-save the entire block to disk. If we changed the schema and just stored the ts in a separate column we'd save that. (Won't help on the client, though) |
| 00:50 |
Desour |
could we maybe do something like a write-ahead-log for disk saving? i.e. have a separate WAL file where we write uncompressed block data, which can be the full block, but also just small diffs, like only timestamp updates or single setnode |
| 00:51 |
lhofhansl |
That won't reduce overall DB throughput to the DB, though, unless you merge multiple changes together before you write to the DB. |
| 00:52 |
lhofhansl |
I actually had a branch that allowed the block to be done without holding the env lock... With zstd I found it did not help that much. |
| 00:52 |
Desour |
"block to be done"? |
| 00:53 |
lhofhansl |
oops. "... to be saved ..." |
| 00:54 |
Desour |
of course it would merge changes. doing everything in one db commit also probably speeds things up. and throughput doesn't really matter if you do the periodic saves in a separate thread |
| 01:00 |
lhofhansl |
For the skinned mesh thingy... Super-trivial change here: https://github.com/minetest/irrlicht/pull/154 in case you wanted to try. |
| 01:38 |
|
HuguesRoss5 joined #minetest-dev |
| 01:38 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:53 |
MTDiscord |
<x2048> lhofhansl: Can you check out https://github.com/x2048/minetest/tree/octablock on a new world? |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:12 |
|
fluxionary joined #minetest-dev |
| 07:08 |
|
olliy joined #minetest-dev |
| 07:11 |
|
calcul0n_ joined #minetest-dev |
| 09:17 |
|
Fixer joined #minetest-dev |
| 09:22 |
|
Warr10246 joined #minetest-dev |
| 10:04 |
|
Warr1024 joined #minetest-dev |
| 11:28 |
kilbith |
tested x2048' octablock branch, I get ~40 FPS @ 1000 nodes viewing range (with medium quality shadows and bloom), that's extremely impressive: https://i.imgur.com/xheIZRz.png |
| 11:28 |
kilbith |
and on 4K resolution |
| 11:34 |
|
ivanbu joined #minetest-dev |
| 12:24 |
rubenwardy |
:O That's awesome |
| 12:46 |
rubenwardy |
kilbith: what do you get on master? |
| 12:53 |
Krock |
will merge #13098 and #13123 in 10 minutes |
| 12:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/13098 -- Clamp player wieldindex when processing hotbar item selection by iliekprogrammar |
| 12:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/13123 -- Fix crash on Android with IrrlichtMt9 by rollerozxa |
| 13:03 |
Krock |
merging |
| 13:04 |
Krock |
done |
| 13:28 |
kilbith |
rubenwardy: approx. same scene on master: https://i.imgur.com/SXRh8Sk.png |
| 13:29 |
kilbith |
twitce as less FPS, and much more mapblock meshes to draw |
| 13:29 |
kilbith |
-t |
| 13:34 |
celeron55 |
nice work. how is the update speed when placing/digging? |
| 13:35 |
celeron55 |
and are there any glitches |
| 13:36 |
celeron55 |
(edge glitches, that is) |
| 13:36 |
|
appguru joined #minetest-dev |
| 13:37 |
kilbith |
haven't noticed any glitch |
| 13:38 |
kilbith |
it's getting closer to MC bedrock' engine |
| 13:38 |
celeron55 |
edge glitches could be lighting or fencelike gliches or some such |
| 13:40 |
kilbith |
while you are there btw: https://github.com/minetest/minetest/pull/13052#issuecomment-1374612981 |
| 13:41 |
celeron55 |
make sense |
| 13:43 |
celeron55 |
in my PR i implemented a method of the client asking specific mapblocks from the server by sending the server a queue. it could be useful here, as then the server doesn't have to come up with the blocks itself but instead can just do any checks it wants (cheating and abuse related checks, maybe) and then just send them |
| 13:44 |
celeron55 |
but the server also will pick them on its own using an algorithm not entirely different from the current one |
| 13:44 |
celeron55 |
it could be a useful model if processing on the server needs to be decreased per camera |
| 13:46 |
celeron55 |
*but the server also can, based on the client's request, pick them on its own using an algorithm not entirely different from the current one |
| 13:47 |
celeron55 |
of course when dealing with huge amounts of mapblocks the bottleneck will become the level of detail especially in mapgen but also in just moving the data around but on high end systems we're not there yet. but that limit will be hit |
| 15:52 |
|
fluxionary joined #minetest-dev |
| 15:58 |
MTDiscord |
<Juri> Hi guys |
| 15:58 |
MTDiscord |
<Juri> I'm getting this error: |
| 15:58 |
MTDiscord |
<Juri> [ 1%] Linking CXX executable ../bin/minetestserver /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libpq.a(fe-gssapi-common.o): undefined reference to symbol 'gss_acquire_cred@@gssapi_krb5_2_MIT' /usr/bin/ld: /lib/x86_64-linux-gnu/libgssapi_krb5.so.2: error adding symbols: DSO missing from command line |
| 15:58 |
MTDiscord |
<Juri> How do I change the library order? |
| 15:59 |
sfan5 |
why are you linking a static libpq? |
| 16:00 |
MTDiscord |
<Juri> In the past there Minetest wasn't able to finde PG itself |
| 16:00 |
MTDiscord |
<Juri> How do I link it dynamic? |
| 16:01 |
MTDiscord |
<Juri> Okay got it |
| 16:01 |
MTDiscord |
<Juri> Thanks for the hint sfan5, you are king! |
| 16:01 |
Krock |
the shipped cmake configuration should already work as-is ... I'm a bit confused |
| 16:08 |
MTDiscord |
<Juri> It didn't sometime around March last year |
| 16:09 |
|
proller joined #minetest-dev |
| 16:15 |
MTDiscord |
<Juri> Seems like I can't disable Prometheus with -DENABLE_POSTGRESQL=OFF |
| 16:16 |
MTDiscord |
<Juri> Jeez, please ignore that |
| 16:16 |
sfan5 |
that option does indeed not disable prometheus :) |
| 16:17 |
MTDiscord |
<Juri> Today is not my day :^) |
| 16:35 |
|
diceLibrarian joined #minetest-dev |
| 16:41 |
|
diceLibrarian joined #minetest-dev |
| 16:51 |
|
appguru joined #minetest-dev |
| 17:13 |
|
olliy joined #minetest-dev |
| 17:17 |
MTDiscord |
<MisterE> When is the meeting today? |
| 17:21 |
Krock |
> Time 18:00 UTC |
| 17:21 |
Krock |
https://github.com/orgs/minetest/teams/engine |
| 17:23 |
Krock |
after the meeting points it would be important to go through the milestone PRs so that 5.7.0 can be planned ahead |
| 17:23 |
Krock |
so see whether Jan 22 feature freeze makes sense |
| 17:28 |
|
lhofhansl joined #minetest-dev |
| 17:45 |
|
jwmhjwmh joined #minetest-dev |
| 17:49 |
pgimeno |
I'm quite interested in #13017 but I'd like to review it. FFI in builtins would be very nice to have, and can speed up a number of functions. Unfortunately I will probably lack time until next weekend. |
| 17:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/13017 -- Implement `minetest.get_node` and `minetest.get_node_or_nil` with LuaJIT FFI by TurkeyMcMac |
| 18:01 |
Krock |
=== Meeting time. pings for @x2048 jwmhjwmh |
| 18:02 |
Krock |
#13072 |
| 18:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/13072 -- Host the generated Lua API documentation under api.minetest.net |
| 18:02 |
MTDiscord |
<x2048> I'm here |
| 18:03 |
rubenwardy |
!dev Meetings |
| 18:03 |
ShadowBot |
Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings |
| 18:03 |
Krock |
Q: Is a hosted Lua API wanted? If so, in which form? |
| 18:03 |
lhofhansl |
x2048: What am I looking for in the octablock tree? Better client rendering, less network communication? |
| 18:04 |
rubenwardy |
See issue. https://minetest.gitlab.io/minetest/ -> api.minetest.net is a the request |
| 18:04 |
Krock |
correction: the API already exists. it seems to be up to the website managers to put up a redirect |
| 18:04 |
rubenwardy |
celeron55 or I can do that. Needs celeron55's permission |
| 18:04 |
Krock |
according to him it's green light |
| 18:05 |
rubenwardy |
#13072 |
| 18:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/13072 -- Host the generated Lua API documentation under api.minetest.net |
| 18:05 |
Krock |
that's what I interpret from the answer on the issue |
| 18:06 |
Krock |
if still in doubt, I assume you can have a look at it with c55 at a later time? I think it would be great to have this subdomain associated with it for consistency. |
| 18:07 |
Krock |
needs proper linking on the main website.. but that's for another topic |
| 18:08 |
Krock |
> Feature freeze starting on January 22? |
| 18:08 |
ROllerozxa |
If Gitlab pages works like Github pages then it should be able to redirect old minetest.gitlab.io/minetest/ URLs to api.minetest.net. the website footer link should still be updated alongside of course |
| 18:08 |
MTDiscord |
<x2048> lhofhansl: You should get similar performance to your current setup, without bumping mapblock size to 32 |
| 18:09 |
lhofhansl |
Nice! |
| 18:09 |
lhofhansl |
scanning through the code right now |
| 18:10 |
MTDiscord |
<x2048> Is the source code for API gen. hosted on gitlab? |
| 18:10 |
sfan5 |
oops im late |
| 18:11 |
ROllerozxa |
yeah so it gets generated with mkdocs and gets hosted on gitlab pages with gitlab's CI |
| 18:11 |
Krock |
sorry sfan5. I was not sure whether you'd have time (also no reaction in the teams/engine post) |
| 18:11 |
Krock |
hence no ping |
| 18:11 |
MTDiscord |
<Jonathon> isnt the gitlab syncing currently broken? |
| 18:11 |
sfan5 |
gitlab mirroring stopped working entirely btw, we probably have to apply for the OSS plan |
| 18:11 |
MTDiscord |
<x2048> Do we want to keep it there or move to github? (The rest of the dev. resources seem to be on Github) |
| 18:12 |
rubenwardy |
ah, in which case it's probably best to move to GH |
| 18:12 |
Krock |
the gitlab pipeline is dead too |
| 18:12 |
ROllerozxa |
the reason it's on gitlab currently is because you can deploy to their static hosting without making a commit, though I think github might have made this possible as well recently |
| 18:12 |
rubenwardy |
Yeah, GitHub supports that now |
| 18:14 |
MTDiscord |
<Jonathon> https://github.blog/2022-08-10-github-pages-now-uses-actions-by-default/ |
| 18:15 |
Krock |
so setting up the correct GitHub action configuration file should then suffice? |
| 18:17 |
Krock |
¯\_(ツ)_/¯ well whatever. is there anything more or might be proceed with the next topic? |
| 18:17 |
|
x2048 joined #minetest-dev |
| 18:19 |
x2048 |
If on GH, do we put it in the main repo, minetest.net or a completely new one? |
| 18:19 |
Krock |
there is https://github.com/minetest/minetest.github.io |
| 18:19 |
rubenwardy |
it's already in the main repo |
| 18:20 |
rubenwardy |
you'd just need to make a github work flow |
| 18:21 |
rubenwardy |
it's currently in the main repo being built by GitLab |
| 18:21 |
x2048 |
that's an option, but will it publish under its own hostname? |
| 18:21 |
rubenwardy |
the change is to build using GitHub instead |
| 18:21 |
rubenwardy |
yes, you can have per repo hostnames |
| 18:22 |
x2048 |
Then it's a PR to the main repo + DNS work + redirects from Gitlab + main website links |
| 18:22 |
x2048 |
right? |
| 18:22 |
sfan5 |
to summarize: let's move to github, it's capable of doing everything we need; not sure who does the work, maybe some community member can |
| 18:23 |
x2048 |
let's move on? |
| 18:23 |
rubenwardy |
sure |
| 18:24 |
rubenwardy |
is anyone making an issue for the move to GH thing? |
| 18:24 |
MTDiscord |
<Jonathon> seems it should just be a comment on the existing issue? |
| 18:24 |
Krock |
there's already an issue.... |
| 18:25 |
Krock |
assigned you. I hope that solves it :P |
| 18:25 |
nrz |
Noted 😉 bye gitlab, you nuked yourself |
| 18:25 |
Krock |
> Feature freeze starting on January 22? |
| 18:26 |
sfan5 |
might be too early but idk, what do we have planned? |
| 18:26 |
Krock |
topic N°2. and the most crucial part seems to be #12809 |
| 18:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/12809 -- Add Privacy Policy (now required by Google Play) |
| 18:26 |
Krock |
I don't think we need to set a date yet but this needs addressing |
| 18:26 |
Krock |
otherwise it'll drag on forever |
| 18:26 |
sfan5 |
https://github.com/minetest/minetest/milestone/20 hmmm |
| 18:27 |
Krock |
srifqi provided a good sample which can be repurposed for all builds |
| 18:27 |
sfan5 |
given all the stuff and new PRs currently being discussed I don't think we should freeze anytime soon |
| 18:27 |
sfan5 |
(also considering that personally I have much fewer time I can allocate to MT than before) |
| 18:27 |
rubenwardy |
yeah agreed |
| 18:27 |
|
Desour joined #minetest-dev |
| 18:27 |
sfan5 |
otoh we should release early, release often |
| 18:28 |
sfan5 |
#12809 should indeed be solved asap, as Krock said |
| 18:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/12809 -- Add Privacy Policy (now required by Google Play) |
| 18:28 |
rubenwardy |
that doesn't actually require a release to be fixed |
| 18:28 |
sfan5 |
I say that we should start adding important PRs to the milestone however |
| 18:28 |
sfan5 |
to keep track |
| 18:29 |
x2048 |
Shall we create 5.8.0 and start splitting stuff between the two? |
| 18:29 |
Krock |
5.8.0 milestone already exists and I agree with you |
| 18:29 |
rubenwardy |
I'd really like to get some of x2048's optimisations in |
| 18:29 |
rubenwardy |
settings PR likely won't make 5.7 |
| 18:29 |
Krock |
I think the dual wielding PR also needs some work, hence probably 5.8 unless its problems can be fixed earlier |
| 18:30 |
x2048 |
Some of them are already in, but the octablock branch is too early to merge |
| 18:30 |
x2048 |
And #13124 is on its way to be merged |
| 18:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/13124 -- Remove mapblock cache for mesh generation. by x2048 |
| 18:32 |
x2048 |
There's more, but I also have visual stuff in the pipeline, like shadow lights, gordays and control for bloom |
| 18:32 |
x2048 |
*godrays |
| 18:33 |
Krock |
that sounds interesting. take your time to work on it. I don't see any need to rush towards a certain milestone |
| 18:35 |
x2048 |
My point is, we can aim to cut 5.7.0 now, it adds the pipeline and some effects, and all the other effects could go to 5.8.0 |
| 18:35 |
sfan5 |
sure |
| 18:36 |
Krock |
while we're at it, #12315 rubenwardy, considering the 3 week inactivity - do you have time/motivation to work on this PR for 5.7.0 |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/12315 -- Add world-independent storage directory for mods by rubenwardy |
| 18:38 |
Krock |
it does not look overly complicated, hence I'd first have to follow the conversation to see what's wrong with it |
| 18:38 |
rubenwardy |
I could just remove the warning |
| 18:38 |
|
appguru joined #minetest-dev |
| 18:38 |
rubenwardy |
I don't think that PR is vital for the release though, compared to #12367 |
| 18:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/12367 -- Add minetest.get_player_window_information() by rubenwardy |
| 18:39 |
sfan5 |
I can prioritize reviewing that one |
| 18:39 |
Krock |
great. thank you. |
| 18:39 |
MTDiscord |
<Jonathon> could someone potentially look at https://github.com/minetest/minetest/pull/10100 for 5.7 since its a client side feature and the oldest pr? |
| 18:39 |
Krock |
https://github.com/minetest/minetest/pull/12367/files#diff-07463202a6243bf71605306af9d74c0205134d28705596296145adb1f0bc52beR15-R16 |
| 18:40 |
Krock |
std::abs is not the same as cmath abs() |
| 18:40 |
Krock |
just something I quickly found. I won't review this PR due to differences in opinions |
| 18:40 |
rubenwardy |
I added the max_formspec_size like you requested |
| 18:41 |
Krock |
looks like I was inactive for too long then |
| 18:42 |
Krock |
noted for later review. |
| 18:42 |
Krock |
is there anything else important on the milestone? |
| 18:43 |
sfan5 |
#11016 already mentioned but we sort of promised this to players (especially MCL) |
| 18:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by LizzyFleckenstein03 |
| 18:43 |
sfan5 |
haven't looked recently so don't know what potential problems the code has |
| 18:43 |
Krock |
the issue mainly lies in compatibility with existing mods |
| 18:43 |
sfan5 |
#11465 probably fine if wuzzy has fixed the code |
| 18:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11465 -- New physics overrides by Wuzzy2 |
| 18:43 |
sfan5 |
Krock: hmm, potentially tricky |
| 18:43 |
Krock |
the "hand" slot and "offhand" now were a mistake |
| 18:44 |
Krock |
they should never be submitted as item stacks to the Lua API |
| 18:44 |
rubenwardy |
I don't believe that PR adds actions? It's just a new slot and a new rendered HUD element, no input changes |
| 18:44 |
|
Menchers_ joined #minetest-dev |
| 18:44 |
Krock |
it uses the offhand to place items from there, which can confuse mods |
| 18:44 |
rubenwardy |
oh interesting, that's new from when I last checked |
| 18:45 |
sfan5 |
not really |
| 18:47 |
Krock |
I suppose the only concern is g/setWieldItem() (and the index getter). aside that I don't see much notable about the PR |
| 18:48 |
nrz |
sfan5, about release early/often, you think debian will follow ? i think not, then what's the solution for end user version fragmentation ? |
| 18:49 |
rubenwardy |
telling users not to use debian |
| 18:49 |
rubenwardy |
release early/often is a mantra for our own sanity, it doesn't matter if users delay updating so much |
| 18:49 |
sfan5 |
the closest thing to a solution we have is promoting snap/flatpak |
| 18:49 |
nrz |
not a solution, ti's like saying use linux instead of windows because windows is borked 😄 |
| 18:49 |
sfan5 |
also next to mobile our largest user base is windows |
| 18:49 |
nrz |
do we have flatpack ready for end users already ? |
| 18:50 |
nrz |
(i think flatpack is the most important userbase of the two |
| 18:50 |
sfan5 |
i believe the ones on flathub work yes |
| 18:50 |
sfan5 |
(we link them on our website) |
| 18:50 |
nrz |
who provide them ? us or third party ? |
| 18:50 |
x2048 |
I use the flathub one |
| 18:50 |
sfan5 |
latter |
| 18:50 |
nrz |
for the gitlab to github, if you want i can take a look, just remember we'll need to tell users to update the docker part to another registry |
| 18:50 |
sfan5 |
yeah docker is another issue |
| 18:51 |
sfan5 |
maybe applying to the OSS plan is easier? |
| 18:51 |
nrz |
then maybe for a chain of trust we should at a point take the responsiblity of the flathub part ? 🙂 |
| 18:51 |
rubenwardy |
I use flatpak on my steam deck |
| 18:51 |
rubenwardy |
and on my laptop when I want to use latest stable |
| 18:51 |
nrz |
for gitlab i'll try to ask for OSS part |
| 18:52 |
sfan5 |
👍 |
| 18:53 |
sfan5 |
okay, anything else? |
| 18:54 |
Krock |
been adding a few comments to the meeting notes to save later. I assume we can go ahead |
| 18:54 |
sfan5 |
please do |
| 18:54 |
Krock |
#13037 |
| 18:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/13037 -- Static binary builds for Linux on common architectures |
| 18:54 |
Krock |
> yes, no? (Zughy) |
| 18:54 |
nrz |
sfan5: sent, just i cannot provide the first screenshot as gitlab doesn't recognize our license directly |
| 18:55 |
nrz |
(this one: https://docs.gitlab.com/ee/subscriptions/#screenshot-1-license-overview) |
| 18:55 |
Krock |
appimage could solve that without reinventing the wheel |
| 18:55 |
sfan5 |
for client we have snap/flatpak as mentioned, for server this is potentially useful but I think we shouldn't do it |
| 18:55 |
nrz |
for server, docker is clearly the best option |
| 18:55 |
rubenwardy |
Ah yeah, this is why I didn't apply for GitLab OSS. GitLab requires that LICENSE.txt be just the text of LGPLv2.1.txt for detection |
| 18:55 |
rubenwardy |
I believe |
| 18:56 |
nrz |
let's try with 2 screens, i hope it can work as we are recognized publicly |
| 18:57 |
Zughy[m] |
Sorry don't have time, I'll just say this: settings AND dual wielding PRs postponed again? OH COME ON, that's a joke |
| 18:57 |
Zughy[m] |
Especially the latter |
| 18:57 |
Krock |
Zughy[m]: latter is not postponed |
| 18:57 |
sfan5 |
postponing PRs that the author can't finish in time isn't our fault |
| 18:58 |
|
izzyb joined #minetest-dev |
| 18:58 |
Zughy[m] |
Krock: oh, sorry then |
| 18:58 |
Krock |
dual wielding is a tricky situation and I'd have to write up some snippets to check compatibility |
| 18:58 |
Krock |
hence I was kinda hesistant to actually review it properly |
| 18:59 |
pgimeno |
what's the settings PR? |
| 19:00 |
rubenwardy |
#12480 |
| 19:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/12480 -- [No Squash] Redesign/unify mainmenu settings interface by rubenwardy |
| 19:00 |
pgimeno |
thanks |
| 19:00 |
rubenwardy |
I'm feeling a bit burned out with all the small things that need fixing |
| 19:00 |
Krock |
sfan5: is flatpak updated regularly? the author indicates that they might be outdated |
| 19:00 |
x2048 |
Can we just ask the dual wielding to be behind a setting, so that unaware games won't break? |
| 19:00 |
Krock |
or not available |
| 19:01 |
Krock |
x2048: if we go on like that, the settings mess will be impossible to fix later on |
| 19:01 |
sfan5 |
Krock: each release |
| 19:01 |
sfan5 |
and afaict they do it on time |
| 19:01 |
Krock |
sfan5: great. so that means they are kindly invited to provide an appimage build script if they want. there's already enough options out there to obtain the binaries, right? |
| 19:02 |
x2048 |
Krock: not a setting, an API call, or would that still be a bess? |
| 19:02 |
Krock |
if so, I'd take that as the reason to close the issue |
| 19:02 |
x2048 |
*mess |
| 19:02 |
sfan5 |
who is "they" here |
| 19:03 |
Krock |
sfan5: the issue author or the people who are facing the issue of not having enough permissions server-side |
| 19:03 |
Krock |
meanwhile #13078 already exists |
| 19:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/13078 -- fix(misc/AppImageBuilder.yml): add script section and update to Jammy by cat-master21 |
| 19:03 |
sfan5 |
Krock: yeah, sure |
| 19:03 |
|
olliy joined #minetest-dev |
| 19:04 |
Krock |
x2048: the edge-case I imagine with g/setWieldItem() is a new logic issue that is very annoying to fix or workaround with a setting. there's no way to know whether mods are compatible or not |
| 19:04 |
Krock |
I suppose the easiest approach is to merge the PR and fix the few mods later on... |
| 19:05 |
x2048 |
but then it needs time to catch an fix the broken mods |
| 19:05 |
x2048 |
otherwise it will be again 'engine developers break our games' situation |
| 19:06 |
pgimeno |
do that early in the 5.8 cycle maybe? |
| 19:06 |
x2048 |
which means no dual wielding for 5.7 |
| 19:06 |
sfan5 |
technically that means dual wielding for 6.0 |
| 19:07 |
jwmhjwmh |
I remember reading dual wielding must be enabled by a game/mod. |
| 19:08 |
jwmhjwmh |
So it wouldn't break mods by default. |
| 19:08 |
sfan5 |
that is true |
| 19:08 |
sfan5 |
the small problem remains that it will affects all other mods if one mod/game enables it |
| 19:08 |
sfan5 |
but you can blame the user for that ;) |
| 19:08 |
x2048 |
I don't see how it should be enabled, it's not in lua_api.txt |
| 19:09 |
rubenwardy |
by placing an item stack in offhand |
| 19:09 |
rubenwardy |
I gather |
| 19:09 |
Krock |
to be fair, the "hand" slot suffers from a similar problem (although is used less often and has less impact) and yet I haven't seen any big deal about it |
| 19:09 |
x2048 |
No, found now. "Use InvRef:set_size" |
| 19:10 |
x2048 |
"hand" slot has different semantic |
| 19:12 |
Krock |
as said, I'll have to write some sample code to showcase the actual problem. I wasn't in the mood so far, but I'll give it a shot this week to make some progress |
| 19:12 |
Krock |
#12953 |
| 19:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/12953 -- Allow zoom even with overwritten default FOV by SmallJoker |
| 19:12 |
Krock |
> There seems to be some disagreement on this in the comments. Is the change acceptable? |
| 19:12 |
Krock |
this is so old I forgot that it even existed. jwmhjwmh: what's the deal with it again? |
| 19:13 |
jwmhjwmh |
I just put it there because some people seemed to disagree with the change. |
| 19:14 |
Krock |
I moreover cannot understand what they mean or what they did/expect |
| 19:16 |
sfan5 |
... |
| 19:16 |
Krock |
I'll write an answer to clarify that later. in the meantime I suppose we can go on with #12928 |
| 19:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/12928 -- Add node texture variants by TurkeyMcMac |
| 19:16 |
Krock |
> What item properties should be allowed to vary by variant? |
| 19:16 |
sfan5 |
haven't looked at that at all yet |
| 19:17 |
sfan5 |
are there suggestions other than `tiles`? |
| 19:17 |
Desour |
"mesh", for example |
| 19:18 |
x2048 |
Then all the visual ones: scale, wield_*, color? |
| 19:18 |
sfan5 |
how much more work is that would be my next question |
| 19:19 |
x2048 |
color is solved by palette, right? |
| 19:19 |
jwmhjwmh |
Letting any given property vary by variant would be a substantial amount of work, but not huge. |
| 19:20 |
Desour |
you can't combine color arbitrarily with other paramtype2s |
| 19:20 |
jwmhjwmh |
It just takes work to add stuff to the API and document it. |
| 19:21 |
jwmhjwmh |
Color is basically solved because there is already a "color" paramtype2 for every regular paramtype2, almost. You could also use colorized variant textures. |
| 19:21 |
Desour |
IIRC, I asked about other possible variant fields because I was worried if the API would become spaghetti if more variant fields are added in the future |
| 19:23 |
x2048 |
Would it make sets to have 'variants = { tiles = { } }' instead of variant_tiles in this PR? |
| 19:23 |
x2048 |
And then add more properties to variants as we get requests |
| 19:23 |
Krock |
x2048: I just thought about the same |
| 19:23 |
Krock |
this renaming scheme is way too complicated right now. Please nest it and re-use existing terminology if that's possible |
| 19:24 |
jwmhjwmh |
So we should go with `variant = { }`? |
| 19:24 |
Krock |
+1 from my side, definitely. that'll simplify the naming scheme a lot |
| 19:24 |
x2048 |
+1 from me too |
| 19:24 |
sfan5 |
+1 |
| 19:25 |
Krock |
also what about efficiency? I remember previous metadata-related dynamic changes that turned out to be rather inefficient in rendering |
| 19:25 |
Krock |
i.e. speed loss due to variant number lookup in the metadata |
| 19:25 |
sfan5 |
this doesn't use metadata so that's fine |
| 19:26 |
sfan5 |
or "less of a problem" rather |
| 19:26 |
Desour |
it's looked up in nodedef, with param2, not in the metadata hashtables |
| 19:26 |
Desour |
one thing I'm worried about there though is that even nonnodes |
| 19:26 |
Desour |
oops |
| 19:27 |
Krock |
oh. I was looking at the ItemStack code and thought it were entirely metadata.based |
| 19:27 |
Desour |
even non-variant nodes now have a vector of tiles |
| 19:27 |
Krock |
what prevents you from re-using place_param2? |
| 19:28 |
Desour |
i.e. the `std::vector<std::array<TileSpec, 6> > tiles;` in ContentFeatures, instead of `std::array<TileSpec, 6>`. it might be worth using a union there |
| 19:28 |
Desour |
(sry, too specific) |
| 19:29 |
x2048 |
We will be able to optimize that if it's a problem |
| 19:29 |
jwmhjwmh |
It would be nice to have a vector class which stored its elements inline when it had a small number of them. That would work here. |
| 19:29 |
jwmhjwmh |
Like strings. |
| 19:30 |
sfan5 |
std::basic_string<TileSpec> clearly |
| 19:30 |
sfan5 |
jk |
| 19:30 |
Krock |
lmao |
| 19:30 |
Krock |
the code expects 6 tiles per whatever container you give it |
| 19:31 |
jwmhjwmh |
6 * variant_count tiles in total |
| 19:31 |
Krock |
also make sure "variant" never gets too high or that'll cause some fancy out-of-bounds weads |
| 19:31 |
Krock |
*reads |
| 19:32 |
jwmhjwmh |
It's stored as a u16 right now IIRC. |
| 19:32 |
x2048 |
param2 is u8 |
| 19:33 |
Desour |
so max size is 256, u16 is good |
| 19:34 |
Krock |
depending on the drawtype, it might be even more limited (for future changes) |
| 19:34 |
|
appguru joined #minetest-dev |
| 19:37 |
Krock |
feel free to bring this up again in the next meeting. it it's a big PR already and I would recommend you to not add too many new features into it |
| 19:37 |
Krock |
but rather make it future-proof to open the possibility for further variants later on |
| 19:37 |
Krock |
otherwise it'll become an unreviewable monster of a PR |
| 19:39 |
jwmhjwmh |
Alright, I will stick with the current variant properties for now. |
| 19:39 |
Krock |
jwmhjwmh: I can see a few questions on the meetings page - which ones do still need feedback and/or addresing? |
| 19:40 |
jwmhjwmh |
None of them are very important. |
| 19:40 |
Krock |
alright then |
| 19:41 |
Krock |
Are there any non-roadmap PRs that need processing/considerations? https://github.com/minetest/minetest/pulls?q=is%3Aopen+is%3Apr+label%3A%22Roadmap%3A+Needs+approval%22 |
| 19:41 |
Krock |
there's quite a few hanging around and if someone would like to discuss, please bring it up |
| 19:42 |
x2048 |
3d lines? |
| 19:43 |
Krock |
#13020 |
| 19:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/13020 -- 3d line rendering. by Andrey2470T |
| 19:43 |
sfan5 |
x2048 is probably the right person to look at that |
| 19:44 |
Krock |
I wish this were implemented as a new ActiveObject type |
| 19:44 |
x2048 |
the big question is - are they entities or a new type of object? |
| 19:44 |
Krock |
new type |
| 19:45 |
Desour |
line_obj:set_velocity(...), oops what's happening? |
| 19:45 |
Krock |
3D lines have an entirely new API |
| 19:45 |
sfan5 |
flying lines? |
| 19:46 |
Krock |
Desour: https://github.com/minetest/minetest/pull/13020/files#diff-da915d7065166fede89169efbfe67ec7016a1458fa6a553443039f2f1ef7a779R7650-R7654 |
| 19:47 |
Krock |
it re-invents many of the existing UnitSAO functionalities, including attachments |
| 19:47 |
Desour |
lines can't simply reuse all of the active object api, because of parent stuff, IIRC |
| 19:48 |
x2048 |
I'm thinking SAO concept should be common for lines, entities and players |
| 19:50 |
x2048 |
Is it a good idea to have polymorphic API, like minetest.create_object({ type = "..."}) would return one of many possible APIs |
| 19:50 |
Desour |
in the ideal case we'd already have SSCSM and there would be no need for a server-side API. lines could in that case be a purely visual thing |
| 19:51 |
celeron55 |
rubenwardy: you have permission for setting up api.minetest.net to point to gitlab |
| 19:53 |
rubenwardy |
thanks |
| 19:55 |
Krock |
correction: UnitSAO does handle attachments differently, so (Server)ActiveObject might be a better basis. The current code should be re-used so that the entities/lines also load/unload correctly when players are far away |
| 19:56 |
rubenwardy |
how would you handle a line between two objects? |
| 19:56 |
Krock |
cyclic position updates of both ends |
| 19:56 |
x2048 |
Would it make sense to make every line end an (active?) object? |
| 19:56 |
Krock |
just like attachments - unless there's a bone we can use to attach them with irrlicht |
| 19:57 |
pgimeno |
would it allow attaching to hand? |
| 19:58 |
Desour |
what hand? |
| 19:58 |
Krock |
player model hand |
| 19:58 |
Desour |
so, to hand bone |
| 19:58 |
sfan5 |
but it's supposed to attach to the hud hand, not the "real" hand |
| 19:58 |
Krock |
x2048: the line itself (perhaps taking its center point as origin) should be an object that then gets its length from the attachment points |
| 19:58 |
pgimeno |
I'm thinking a leash for a dog :) |
| 19:59 |
Krock |
sfan5: I suppose that could be solved with some 1st person client side hackery where it remaps the hand bone to the wieldmesh |
| 20:01 |
Krock |
that's just a few ideas.. not like that I'm going to implement it, hence I'm also not sure whether to comment further on their PR |
| 20:02 |
|
Fixer joined #minetest-dev |
| 20:02 |
Krock |
Are there other PRs to discuss? |
| 20:03 |
x2048 |
#13052 |
| 20:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/13052 -- Camera API by kilbith |
| 20:05 |
x2048 |
I proposed a plan for it https://github.com/minetest/minetest/pull/13052#issuecomment-1374612981 |
| 20:05 |
sfan5 |
didn't look at it at all yet either |
| 20:05 |
|
lhofhansl joined #minetest-dev |
| 20:06 |
Krock |
I've seen many interesting showcases of this feature but haven't actually looked at the PR yet |
| 20:06 |
Desour |
having multiple cameras is a pretty nice, but advanced feature. requires more refactoring IMHO (i.e. remove the camera class) |
| 20:08 |
x2048 |
Do you mean removing the Camera's current responsibilities? |
| 20:09 |
x2048 |
Like drawing wield mesh |
| 20:10 |
Desour |
I mean the whole Camera class in src/client/camera.h, AFAIK that's only the main camera |
| 20:11 |
Desour |
but not sure |
| 20:12 |
x2048 |
I want draw lists for scene and shadows as well as SM texture to be per-camera, so we'll need some container for that. |
| 20:18 |
x2048 |
Looks like we need to stop here :) |
| 20:21 |
Krock |
thanks for participating in the meeting. the next one will be on 22 Jan, if it goes as usual. I already moved the Meetings section in the wiki a while ago |
| 20:21 |
lhofhansl |
Hey... Sorry I had to off the keyboard to do repair on the house. |
| 20:22 |
lhofhansl |
x2048: I did try your octatree branch... Rendering is actually faster than with MAP_BLOCKSIZE = 32. |
| 20:22 |
lhofhansl |
I think you propose a PR! |
| 20:24 |
lhofhansl |
(should) |
| 20:24 |
MTDiscord |
<Andrey01> Core devs, could you please review #12828 ? It is laying unapproved yet already for few months |
| 20:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/12828 -- Add vector variation for ContentFeatures 'visual_scale' property. by Andrey2470T |
| 20:25 |
MTDiscord |
<x2048> lhofhansl: Thank you! I'll make a PR |
| 20:25 |
MTDiscord |
<x2048> Andrey01, I've started looking at it. |
| 20:27 |
MTDiscord |
<Andrey01> Also, as to my 3d line PR I think it is reasonable to add a new type of objects since it differs much from the luaentities in many relations which I described in the PR |
| 20:27 |
Desour |
yey, bigger meshes |
| 20:29 |
MTDiscord |
<x2048> Andrey01, it makes sense to have a different Lua API, but reuse implementation where possible, that's the conclusion. |
| 20:34 |
MTDiscord |
<Andrey01> In any case I hope is my current implementation accepted as it is now and won't require moving it to the subclass of the ActiveObject? |
| 20:42 |
lhofhansl |
x2048: Of course now the ray traced culler has problems. It has to allow a mesh when any of the 8 blocks are visible. |
| 20:44 |
lhofhansl |
(actually same for the recursive descent one. |
| 20:56 |
MTDiscord |
<x2048> That's what it does in this PR. |
| 21:04 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:58 |
|
appguru joined #minetest-dev |
| 22:18 |
|
Fixer joined #minetest-dev |
| 22:18 |
|
lhofhansl joined #minetest-dev |
| 22:19 |
lhofhansl |
x2048: Then there must be a bug lurking in there... :( I've seen chunks of 8 blocks disappearing and reappearing as I move around. |
| 22:22 |
MTDiscord |
<Andrey01> I've rebased 13020 |
