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 (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: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 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. 02:53 MTDiscord lhofhansl: Can you check out https://github.com/x2048/minetest/tree/octablock on a new world? 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 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: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:58 MTDiscord Hi guys 15:58 MTDiscord I'm getting this error: 15:58 MTDiscord [ 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 How do I change the library order? 15:59 sfan5 why are you linking a static libpq? 16:00 MTDiscord In the past there Minetest wasn't able to finde PG itself 16:00 MTDiscord How do I link it dynamic? 16:01 MTDiscord Okay got it 16:01 MTDiscord 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 It didn't sometime around March last year 16:15 MTDiscord Seems like I can't disable Prometheus with -DENABLE_POSTGRESQL=OFF 16:16 MTDiscord Jeez, please ignore that 16:16 sfan5 that option does indeed not disable prometheus :) 16:17 MTDiscord Today is not my day :^) 17:17 MTDiscord 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: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 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 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 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 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 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 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: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 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 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 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 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 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 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: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 > tiles;` in ContentFeatures, instead of `std::array`. 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 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: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 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: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 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 lhofhansl: Thank you! I'll make a PR 20:25 MTDiscord Andrey01, I've started looking at it. 20:27 MTDiscord 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 Andrey01, it makes sense to have a different Lua API, but reuse implementation where possible, that's the conclusion. 20:34 MTDiscord 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 That's what it does in this PR. 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 I've rebased 13020