Time Nick Message 09:56 sfan5 huh 09:57 sfan5 i need to stop before I surpass c55 10:08 chmodsagtwas According to https://dev.minetest.net/Code_style_guidelines, one should never put an opening brace on the same line as an if-statement ("Putting the body of an if statement on the same line as the condition is strictly prohibited."), but what about else? I've seen both "else {" and "else {" in minetest-sources... 10:09 [MatrxMT] sfan55 10:10 sfan5 it is talking about the body, not the brace 10:10 sfan5 putting the brace on the same line is actually encouraged if you look here https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces 10:11 chmodsagtwas nevermind, my bad. Thanks for clarifying though. 12:53 sfan5 Desour: so i investigated drawing order and solid stuff is indeed drawn front-to-back 12:54 sfan5 it just happens that lots of irrelevant stuff is drawn first before we get to the stone wall that's covering half the viewport 12:54 sfan5 if that could be improved via some heuristic I think that could save some gpu work 13:04 sfan5 i guess prioritizing whatever buffer group draws the most nodes (not vertices) would work 13:10 Desour sfan5: we draw block chunk meshes first that we iterate to first, and all block meshes that use the same material. so, it's not *completely* unordered. but idk if one can call that front to back 13:11 Desour anyway, it's likely this doesn't influence rendering performance much anyways 13:13 sfan5 the per-material list is ordered front-to-back 13:14 sfan5 I'm not sure about performance. rendering useless could be much worse on a low-end gpu with low fill rate 13:14 sfan5 (since the depth test would just discard it if occluded) 13:49 sfan5 also the way our code is written now we're assuming that material swaps are more costly than rendering fragments twice (or more) 13:54 Desour it would be interesting to see if for some low end gpus number of fragments is actually more important indeed, and by how much 13:57 sfan5 okay so https://github.com/minetest/minetest/commit/ee2d9d973a0397ce244f05d49083250956578780 introduced that 13:57 sfan5 but it made in sense back in the day because the drawlist wasn't yet ordered 13:58 sfan5 we have that since https://github.com/minetest/minetest/commit/f5040707fe7cf9f24274379598527d6298c5818c 14:00 sfan5 anyway the optimization I proposed is free. we're just rendering solid buffers in a different order 14:00 sfan5 the other thing depends heavily on the scene and probably the gpu (driver). 14:03 sfan5 speaking of other things: does anyone want to create a backport branch? 15:06 rubenwardy [10:57] <+sfan5> i need to stop before I surpass c55 15:06 rubenwardy Or maybe c55 needs to start again! 15:18 Krock I missed the opportunity to blaze 15:45 [MatrxMT] Reminder meeting today in a few hours 16:00 MTDiscord Dont forget discuss how to merge https://github.com/minetest/minetest/pull/11843 16:05 Desour !title 16:05 ShadowBot Breaking world limits. Part 1 by proller · Pull Request #11843 · minetest/minetest · GitHub 16:32 sfan5 i wonder if we could use test scenes and software rendering to reasonably measure rendering performance and detect regressions 16:32 sfan5 hell just having test scenes would be good 16:34 Krock read-only maps exist but they'd be somewhat heavyweight for git 16:44 v-rob I'll be attending the meeting today, but will probably be a half hour late. 17:31 Mantar Krock: that's what LFS is for 17:39 Krock Mantar: if we'd want to add another dependency, then yes. 17:39 Krock Meeting in 20 minutes 17:51 sfan5 i will not be there 17:57 Krock good to know. thanks. Pinging people who reacted. In advance. @sfence sfence v-rob (joins in 30 mins) Desour Zughy 17:57 Desour o/ 17:59 Krock might grorp / @grorp be available too? the more, the merrier. 18:00 Krock Meeting start. https://dev.minetest.net/Meetings#2024-09-01 I'll be going through the milestone ( https://github.com/minetest/minetest/milestone/27 ) one by one 18:01 Krock > #15000 18:01 ShadowBot https://github.com/minetest/minetest/issues/15000 -- Major Server Performance Regression 18:02 Krock there does not seem to be any definite explanation for this issue 18:02 Krock perhaps it's touching multiple issues at the same time without any reasonable way to debug it 18:04 Krock almost as if there's a new time catch-up mechanism that causes permanent lag 18:05 Krock there's the glibc memory-free triggering function - which however should leave enough memory as a buffer 18:09 Desour has there been anyone else than Warr1024 who was able to reproduce? 18:11 Desour (oh, yes: https://github.com/minetest/minetest/issues/15000#issuecomment-2295272574 ) 18:11 SFENCE This looks like we should develop some performance test for server-client or something like it. 18:12 Krock I suppose it's difficult to catch memory usage spikes which could be a cause of such issue 18:15 Krock Hopefully we'll get a lead on this. Until then I don't see a way to possibly fix it for 5.9.1. 18:16 Krock If there's inputs from affected and unaffected server owners, please leave a comment. Maybe that could help to narrow down the issue. 18:16 Krock > #14765 18:16 ShadowBot https://github.com/minetest/minetest/issues/14765 -- New 5.9.0-dev networking is not allowing legitimate players to connect under some rare circumstances 18:17 Krock s.f.a.n.5 is mostly on it. Same issue as above; difficult to reproduce. 18:18 Desour #15087 18:18 ShadowBot https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5 18:19 Desour ^ he is on it 18:19 Krock good. let's see what the testing yields 18:20 Krock > #14999 18:20 ShadowBot https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view 18:22 Krock Same reproduce issue as already seen; also waiting for testing results. 18:23 Krock more precisely - tests with software render and (partial) revert of 5280863 (which is apparently the first bad) 18:24 Krock > #15005 18:24 ShadowBot https://github.com/minetest/minetest/issues/15005 -- Touchscreen can be enabled when device doesn't support touchscreen 18:27 Krock solvable by additional settingtypes.txt "requires:" filters. not important from what I can see. 18:28 Krock ^ would need proper touch detection code that was previously discussed before the 5.9.0 release 18:30 [MatrxMT] that issue is not about physical device touchscreen support, but about Irrlicht device touchscreen support. win32 and osx Irrlicht devices don't support touchscreen input, so you could just hide the setting there. 18:30 [MatrxMT] but I agree with not important 18:31 [MatrxMT] well, actually it's bad UX if you have a Windows laptop with touchscreen, enable touch controls and it's just broken 18:33 Krock I see. Thanks for explaining. It should be rather simple to implement a per-device function to A) inform about touch support and B) the primary input device 18:34 Krock where A) is used for settingtypes.txt and B) for the default 18:35 v-rob I'm here now 18:35 Krock hello v-rob. and also proper hello grorp. 18:36 Krock B) ignores that there's #14542 that should fix the issue differently 18:36 [MatrxMT] "the primary input device" goes into #14933 terrain. detecting the last used input method is simpler and more useful. 18:36 ShadowBot https://github.com/minetest/minetest/issues/14542 -- [no squash] Auto-toggle TouchScreenGUI in-game when receiving touch/mouse input by grorp 18:36 ShadowBot https://github.com/minetest/minetest/issues/14933 -- Implement an editor to customize the touchscreen controls by grorp 18:36 [MatrxMT] Krock: wrong PR number? 18:36 [MatrxMT] also, hello :) 18:37 [MatrxMT] ah, no, wait I linked the wrong one 18:37 [MatrxMT] (I'm here as well, just reading) 18:37 Krock you had me confused for a moment 18:38 [MatrxMT] I was confused by ShadowBot being late 18:39 Krock however that PR is not labelled for 5.9.1 18:41 Krock so having a fix in 5.9.1 is currently not planned, unless that's at least linked in the issue 18:41 [MatrxMT] your B) or that PE isn't necessary for 5.9.1 18:41 [MatrxMT] *PR 18:44 Krock commented. 18:44 Krock > #15056 18:44 ShadowBot https://github.com/minetest/minetest/issues/15056 -- Android media timeout loading no longer allows me to join public servers 18:45 Krock asked for more information. I've seen similar issues in the past. It seems to be recurring every now and then 18:46 v-rob "Things are slower" issues always feel so nebulous 18:46 Krock my toaster does not toast please fix 18:46 Krock > #15087 awaits inputs from affected people https://github.com/minetest/minetest/issues/14765#issuecomment-2322913501 18:46 ShadowBot https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5 18:47 Krock skipping #15095. it's a reminder. 18:47 ShadowBot https://github.com/minetest/minetest/issues/15095 -- Bump protocol version to 45 for 5.9.1 18:47 Krock > #15097 18:47 ShadowBot https://github.com/minetest/minetest/issues/15097 -- touch_punch_gesture not only applied for actual punching 18:48 Krock I'm out of the loop on that topic but reviews for #15098 are welcome 18:49 ShadowBot https://github.com/minetest/minetest/issues/15098 -- Only apply "touch_punch_gesture" when item has no on_use callback by grorp 18:49 Krock mostly on the topic "whether it makes sense" and whether there's any new strange side-effect (hopefully not) 18:50 Krock end of milestone. 5.9.1 is not realistic today. adding a few weeks. 18:51 v-rob I definitely don't understand how short vs. long taps on touchscreens work 18:51 [MatrxMT] it's magic 18:51 v-rob Goody, my favorite 18:52 Krock at least it cannot be more cursed than inventory itemstack movements 18:52 v-rob Those scare me 18:52 v-rob And to think: I have write inventory code for the UI API at some point *shudder* 18:53 Krock think of a PoC. it does not need to be feature-complete from day 0. it might be better to have the documentation separate so that modders do not take features for granted. 18:53 [MatrxMT] since there are already many fixed regressions, we could just do a 5.9.1 release with these fixes. if we manage to fix one of the yet-PR-less issues at a later point, we can still do a 5.9.2. thoughts? 18:54 Krock for context: so far there's 9 merged PR's assigned to 5.9.1 18:55 Desour could add #14969 to make it 9 18:55 ShadowBot https://github.com/minetest/minetest/issues/14969 -- Fix CMeshBuffer::append reallocating too eagerly by Desour 18:55 Desour 10* 18:56 MTDiscord do it 18:56 Desour did it 18:57 Desour we could also already make a branch for 9.1, so users can already test 18:57 v-rob Minetest 9.1.0 18:57 Desour 5.9.1* 18:57 v-rob We're moving fast 18:57 Krock they're already testing those in 5.10.0-dev, and rc builds are an option too, based on the 5.9.1 18:57 Krock PR that someone is going to open 18:59 Krock I could open such PR until the next meeting if that's wanted. 19:01 Krock normal meeting points. I did yet not set up a poll for the development cycle idea so that's a skip 19:01 Krock > #11568 19:01 ShadowBot https://github.com/minetest/minetest/issues/11568 -- Consider a separate repo for requesting and discussing new features 19:02 Krock Zughy: the matrix link is dead 19:03 Krock I took the liberty to use the first post as a poll :3 19:05 MTDiscord Fwiw, #14999 reminds me an issue we had once in VL with messed up animations. Bisect led me then to an unrelated commit. Commenting out lines led me to a mod.conf file. Issue was that mod load order got changed, which caused globalstep registration order to change, which caused globalstep execution order to change, which caused bone override order to change, which messed up some animations. 19:05 ShadowBot https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view 19:06 MTDiscord So maybe it's about some code execution order changing under some circumstances? 19:06 Krock @herowl that's a nice input but unfortunately entirely unrelated in this case. it's rendering related, which cannot easily be changed by mods 19:07 MTDiscord Yeah, but rendering pipelines also have execution ordering by different things 19:07 Krock if it's execution order related, then many more people should be active in that issue 19:07 MTDiscord You're overestimating the amount of people reporting such issues. It's a graphical glitch 19:08 Krock retry with (partial) reverted 5280863. If reverting the entire thing does not solve it, then the earlier bisect is wrong. 19:08 v-rob Zughy: What was in that matrix link? 19:10 SFENCE In the case of moving features somewhere, I am afraid about users ability to follow that. Users can be confised by it. 19:12 v-rob They might be somewhat confused, but we can easily redirect them: if you click "New Issue" in the Minetest repo, one of the options is a link to Minetest Game's repo. You could turn the feature request issue into a redirect to the features repo. 19:14 [MatrxMT] sorry, internet hiccups 19:14 [MatrxMT] v-rob, Krock: people debating about having two separate repos 19:14 SFENCE It will require some issue auto moving... sometimes someone report bug, and it is labeled as feature request and etc. 19:15 v-rob Is it easy to move issues between repos in GitHub? 19:15 v-rob We have to tag new issues/feature requests anyway 19:15 Krock yes but you need to have member access to both 19:15 Krock MTG issues are moved there from the engine on a regular basis 19:17 [MatrxMT] https://matrix.org/_matrix/media/v1/download/matrix.org/UksrVxBQieecMsnyPAxmWoXH 19:17 v-rob That link works 19:19 Krock "too many open issues bury the actual problems" - this is not quite true, assuming that people can find their issue and leave a "me too, reproduced on X, Y and Z with A B and C" to bring the issue forwards. That's also why there's priority labels and milestones. 19:19 SFENCE So, we will have ability to ignore feature repo issues. Will it help users? 19:20 v-rob Can issues be added to milestones in another repo? 19:21 [MatrxMT] https://matrix.org/_matrix/media/v1/download/matrix.org/QKznVFyhVzTPPILFzJafUOBY 19:21 [MatrxMT] https://matrix.org/_matrix/media/v1/download/matrix.org/qmJrdJUbPuczznvAcvjBPmxn 19:21 Krock v-rob: milestones are on a per-project basis and I don't see any option to include such from other sources 19:21 [MatrxMT] the end 19:23 Krock SFENCE: what helps the users is if they can find an issue they discovered quickly. 19:23 v-rob Milestones are rather important for project management. If we have a separate repo, we need to have a replacement. 19:23 MTDiscord I don't think separating it is a good idea. 19:24 Krock separating feature requests and issues can help in this regard but only to a limited degree 19:24 v-rob It would be nice if GitHub had separate "Issues" and "Requests" sections in the same repo. 19:25 v-rob Or if there were a more hierarchical way to organize issues 19:25 v-rob Labels are a rather "flat" means of organization 19:26 SFENCE I do not think that it will help to find some issue much quicker with separate repo. There is many of feature request still. It will be still best to use filtering by name, I expect. Now you should filret by name and label. 19:26 Krock combining related issues is kind of possible with the "Projects" page 19:27 v-rob The problem with projects is that issues can get "lost" if they aren't added 19:27 Krock it's not a hierarchy, though. and dividing it into such is extremely difficult because issues can touch more than one code area, depending on how you interpret the issue or solution 19:28 MTDiscord Projects should be used for what their name implies IMHO. 19:28 [MatrxMT] v-rob: make a PR to GitHub to implement th.. Oh, wait, it's proprietary, you can't 19:28 v-rob Some things are hierarchical, like bug vs. feature vs. meta discussion, also high vs. med vs. low priority. Things like the @ labels are definitely better as labels, not hierarchy though 19:28 MTDiscord Minetest move to Codeberg when? 19:29 v-rob Bascially, I'd love it if mutually exclusive labels could have their own sections. 19:29 v-rob But this is all wishful thinking. I don't know of any git platform with such a means of organization 19:30 v-rob Anyhow, it seems that quite a few people disagree with separating issues and features. 19:31 Krock Zughy: if you'd like to have a definitive answer, please set up a poll in the issue or forums 19:31 v-rob Agreed 19:31 Krock > Thoughts on the latest proposed core dev 19:31 Krock wasn't this already discussed? 19:33 Krock In either case - the meeting is already going on for 1.5 hours and I think that's a good summary for 5.9.1 19:33 Krock I'll include a few meeting notes in the wiki and close it at this point. If you have any other topics, please bring them up. 19:34 v-rob I had a few things I wanted to talk about for #14263. 19:34 ShadowBot https://github.com/minetest/minetest/issues/14263 -- Formspec/HUD replacement, part 1 by v-rob 19:34 v-rob It's currently milestoned for 5.11.0, which seems reasonable enough. 19:35 v-rob In the meantime, what should be done about formspec PRs? I don't want to stop them altogether, but it would be nice if we could slow down adding features 19:36 v-rob For instance, #14728 is a large new feature 19:36 ShadowBot https://github.com/minetest/minetest/issues/14728 -- [NO SQUASH] Add hypertext support to tooltips by Wuzzy2 19:37 v-rob Whereas #14840 is an important quality-of-life thing for formspecs 19:37 ShadowBot https://github.com/minetest/minetest/issues/14840 -- Improve formspec scaling by grorp 19:38 v-rob The UI API is obviously not going to be finished for a while yet, so the latter is important, but I think we should avoid merging ones like the former. If we get a new API soon, then extra formspec features just means more work when making formspec compatibility code. 19:40 Krock I think we should begin to discourage entirely new formspec features as soon the replacement is on a condition where we are sure to build onto 19:40 v-rob (Although, since hypertext is technically experimental, it could be nuked entirely, though that would make quite a few people unhappy) 19:40 v-rob What point do you think that would be? 19:44 Krock I'd say when the basic formspec replacement (it does need a fancy name, maybe formspec2 :P ) is in master for at least a release for modders to check it out and provide suggestions. 19:45 Krock You surely spent many hours on the concept and implementation, and yet, the best testing is done by modders who try to find its limits 19:45 v-rob That's definitely true 19:45 Krock and such limits are likely discovered by wrapper mods that provide formspec + formspec2 support 19:45 v-rob I've been calling it the UI API in the official docs 19:46 Krock (to convert into both, for client compatibility) 19:46 Krock of course, for the transition phase it would be amazing if formspecs could be included as a separate element in the UI API 19:46 Krock but that might as well come with an entire can of worms 19:47 v-rob If you have a formspec -> UI element converter function, it should be more or less doable. 19:48 v-rob How far do you think basic support would be for modders to get a good feel for the UI API? Obviously things like buttons and scrollbars and edit boxes, but what about more complicated things like inventory lists, tooltips, and tables? 19:49 v-rob Sizer support is also a definite must. 19:50 v-rob (I keep trying to keep sizers as simple as possible, but I keep finding that there's some features that are indespensible for good layout, so I have to do some reworking again. Most annoying.) 19:50 Krock depends on how you'd first want to use them. The UI API is supposed to replace formspecs, thus it should work on node-bound basis and in their "detached" form. Nodes generally need inventory lists, but for a PoC that's IMO not needed. 19:51 v-rob Aside from finishing up sizers, text is the only other large feature that I have quite a bit of work for 19:51 Krock (where "should work on" can also be answered by the design of the API, i.e. how the data is saved to the metadata) 19:52 rubenwardy I don't think it's necessary to have table support if you have primatives like flow, grid, and clickables 19:52 v-rob I personally want to deprecate node metadata formspecs entirely, though they'll stick around for compatability. You can't put the UI API into node metadata because it isn't string based. The UI API makes things really easy in an `on_rightclick` handler, so I don't see the need. 19:53 Krock aligning, aspect ratio, and callbacks are probably the most important 19:53 v-rob Callbacks are fully implemented, and very nice to use compared to formspec events 19:54 rubenwardy s/flow/flex 19:54 v-rob Callbacks are placed directly in the element: `ui.Checkbox{id = "check", on_change = function(e) if e.selected then print("Checked") else print("Unchecked") end end}` 19:57 v-rob I can give a basic timeline: 1) Current PR (windows, buttons, events, styling) is basically done, I just need to address any review comments that come up and make a test suite 19:58 v-rob 2) PR with scrollbars, scroll containers, and other simple elements that don't require text would take a few weeks 19:59 v-rob 3) Sizers are 90% done, but the last 10% takes 90% of the time, as they say :) Still, a few weeks is a good estimate. If modders find problems with sizers, I can always make more PRs that incorporate their feedback. 20:01 Desour tbh, I kinda like that in formspecs you don't define the callback inside the form definition. the separation feels somewhat clean 20:01 v-rob 4) Text will take a few months. This includes incorporating a text layout library, making a serialization format to handle rich text like bold and italics, hopefully bidi support at the UI level, and so on. A PoC doesn't need every feature, however. 20:02 v-rob After that, I think the UI API is ready enough for modders to use and give feedback on 20:02 v-rob Even without text, there's a lot to give feedback one 20:02 v-rob *on 20:03 [MatrxMT] Re 5.9.1: I don't think we should delay it even more, +1 for a hypothetical 5.9.2 to release 5.9.1 soon 20:03 [MatrxMT] I really don't want to rush the name change for the reasons listed in the internal discussion, nor to postpone it for the same reason 20:04 [MatrxMT] And it's not like it gonna takes a couple of days to rename everything 20:04 Krock I'll have to check out the UI API PR in a while. Your most recent summary is a great overview. 20:05 v-rob Desour: I didn't opt for a single separate callback for a few reasons. One good reason is that it allows modders to add and remove callbacks at will when they update the window. Another is that it reduces network traffic: the client only sends the events that the server is listening for. 20:06 v-rob Krock: I'll be pushing my changes for grorp's review in a few days. Give it another week or two and I'll have a test suite ready out-of-the-box in devtest and documentation included in the PR as well. 20:08 SFENCE If 5.9.1 comes quickly, I want to add one trivila PR to it to improve MacOS support to MacOS 12 and later. 20:08 [MatrxMT] v-rob: also take in consideration a PR to edit the roadmap, so to state that big formspec PRs are a no no 20:08 Krock v-rob: wow that's great news. 20:09 SFENCE We should mention it somewhere that we dont want other features for formspec to be done for now. 20:09 v-rob The documentation already exists, but it includes some features that aren't in the current PR yet :) 20:09 v-rob So I need to prune it a bit 20:10 [MatrxMT] If the roadmap is modified, I can manually go through every issue/PR to close them (with a message ofc) 20:10 [MatrxMT] There's already a list by v-rob I can use 20:10 v-rob https://github.com/minetest/minetest/pull/14263#issuecomment-2322659272 20:10 v-rob How convenient :) 20:10 Krock gtg 20:11 v-rob Bye then 20:11 v-rob Guess I'll get back to work myself. Those reviews aren't fixing themselves. 20:12 celeron55 i have a late thing for the agenda of the meeting, now that many people are still around 20:13 celeron55 ok that's two gone already 20:13 celeron55 well anyway... 20:14 celeron55 i talked with y5nw about adding them to the core team. y5nw would be starting slowly as they don't know that much of the codebase but would be ready to join. so, i'm asking for comments from the core team 20:16 celeron55 y5nw is also fine with joining later. so alternatively we can e.g. schedule it, or whatever. but that feels awfully arbitrary to me, so i'm proposing just adding to the team 20:17 [MatrxMT] Can't judge their coding skills but I've met them at FOSDEM and they're cool 20:18 celeron55 (looks like i'm way too late here, maybe i'll ask again tomorrow. the reason for the timing is, i just managed to get to my computer...)