Time Nick Message 07:33 nrz_ hello, i'm not so active, but i want to say it's great to see that there is a monthly blog post about minetest, it's a very nice addition for the community. Who manages it ? ? 07:38 MTDiscord I believe MisterE was the one who started it, but rubenwardy manages it in addition now when it's been made official 09:15 nrz_ it's pretty nice addition ? 09:15 nrz_ I should take some time at a point to lookup again on core engine performance, but not sure it has badly evolved in 2 years, and the issues remains the same, too much lua :p 09:18 erle nrz_ are you interested in improving engine performance? 09:18 erle nrz_ like, since you wrote “again”, did you do it in the past? 09:19 MTDiscord client performance has seen some great improvements as lately as only the recent weeks, it's wonderful :) 09:21 erle ROllerozxa tell me when i can remove the ground content check from the studs mod to make the entire world into legos ;) 09:21 rubenwardy nrz_: just use a profile, don't guess 09:21 erle ROllerozxa (which improvements do you mean?) 09:27 MTDiscord well there was #12231 being fixed which I felt caused a significant improvement in performance when there is a lot of geometry that is being rendered, but also making logging cost-free when it is not being written, nodebox culling, and then sfan's misc. performance improvements PR 09:27 ShadowBot https://github.com/minetest/minetest/issues/12231 -- HWBufferMap causes periods of low framerate and stutter 09:28 MTDiscord oh and fixing mapblock geometry optimisation, that was broken for a while, oops :P 09:30 MTDiscord and of course there's the irrlicht array rewrite and whatever else that hasn't been merged yet 09:45 MTDiscord nrz_: Too much Lua isn't the issue, Lua can be pretty fast. Too bad algorithms (crafting, entities inside radius, etc.) are the problem. 09:46 MTDiscord erle: your studs would require actual culling checks (checking whether the studs are occluded / "stuck" in another block) which haven't been implemented yet 09:47 erle luatic you forgot to mention 1 billion drawcalls [puts pinky finger on mouth like doctor evil] 09:47 nrz_ luatic, entites inside radius function call has been heavily optimized on my side, but maybe it's not the right solution to use, and if we can know which generic function is needed from core engine to solve this issue, let's implement it 09:47 nrz_ what is the issue with crafting algorithm ? 09:47 erle luatic yeah x2048 focused on the snow layers 09:48 MTDiscord nrz_: The hashes are too poor 09:48 erle luatic explain “too poor”? 09:48 MTDiscord It often falls back to hashing only by item count 09:48 MTDiscord Which obviously means lots of collisions 09:48 MTDiscord i.e. you get a linear search in the end 09:48 nrz_ on my side, 5 years ago i implemented the item pickup algorithm (which is in lua and pretty well written) in C++ and it make it blazing fast whereas it's pretty close algorithm ? 09:48 MTDiscord How could item pickup be slow in either Lua or C++? 09:49 nrz_ same for node falling, it's pretty slow as lua, too much c++ <-> lua cross calls 09:49 MTDiscord Did you benchmark using LuaJIT? It often provides a 5x speedup. 09:49 MTDiscord Ah yes, the cross calls. 09:49 nrz_ i don't like using luajit, it's better yes, but i prefer a vanilla lua ? 09:49 MTDiscord My solution would be to make more in Lua, not less 09:49 MTDiscord Reducing the amount of cross calls and the maintainabiltiy :) 09:49 nrz_ also optimizing calls is very painful when you do flamegraphs and you have the lua VM inside ? 09:50 MTDiscord (improving the maintainability) 09:50 nrz_ lua VM memory amount is limited and GC is not good 09:50 MTDiscord GC is good :P 09:50 MTDiscord It means less memleaks 09:50 MTDiscord Also no, Lua VM mem isn't limited 09:50 MTDiscord That's a LuaJIT restriction 09:50 MTDiscord And there even exists a patch to fix it 09:51 erle bad algorithms trump everything 09:51 MTDiscord (and if your Lua takes more than 2 GB mem you've probably messed up anyways) 09:51 MTDiscord erle: agreed 09:51 erle luatic i wonder why so few people agree in general though 09:51 MTDiscord is there even any single reason to use PUC Lua over LuaJIT other than "it's bundled and can't be arsed to install LuaJIT"? it's only got improvements it seems 09:51 MTDiscord Because writing good algorithms can be pretty hard :P 09:52 erle ROllerozxa luaJIT is not the same 09:52 MTDiscord Brute forces / linear searches / whatever inefficient algorithm you can immediately come up with are just too easy to implement correctly 09:52 MTDiscord erle: well yes, but is there anything you're losing? 09:52 MTDiscord LuaJIT has more features :) 09:52 MTDiscord I suppose LuaJIT might have more crashes 09:52 nrz_ no GC is not good, when you manage properly the memory, there is no overhead, and we are in a game. GC is not good. reactivity >> all 09:53 MTDiscord Right, you're concerned with "stop-the-world" pauses of the GC? 09:53 MTDiscord Valid point. If those GC pauses are < 5ms though, they're very much acceptable in terms of reactivity. 09:54 nrz_ everything which impact latency. I agree GC on web is fine, and majority of the app cases, but game are real time and require the lesser latency you can, 09:54 erle i mean right now i take “oh your stuff is written in language X, it must be slow, I use C / C++” as a shibboleth for “i have no idea what algorithms are” 09:54 MTDiscord Especially considering that Lua usually runs on the server. 09:54 nrz_ 5ms lag is big for a game, especially when rendering depend on it 09:54 MTDiscord We don't have proper CSM yet 09:54 erle lua is server side 09:54 erle most of the time 09:54 MTDiscord And only CSM have the potential to slow down the client 09:54 nrz_ yeah i know my work on CSM has not been finished ? 09:54 MTDiscord lol 09:55 erle nrz_ what is your opinion on waspsaliva? 09:55 nrz_ waspaliva ? wtf is that 09:55 MTDiscord Anyways, TBF designing a good algorithm for MT crafts is hard 09:55 MTDiscord cheat client 09:55 MTDiscord erle constantly advertises it here lol 09:55 nrz_ i have no opinion except cheat is bad :p 09:55 erle nrz_ it comes with a bunch of CSMs and better CSM APIs 09:55 MTDiscord well, it does appear to have a feature-fledged CSM API, but I haven't really looked into it 09:56 nrz_ we fixed many cheating issues in the past, with some network required breakage. Some are not fixed yet, sfan5 did some things years ago but not merged, to try to solve paret of them 09:56 erle i constantly advertise it so that people take a look at it and cherry-pick the stuff that is good https://repo.or.cz/waspsaliva.git 09:56 erle it is about engine development after all 09:56 nrz_ CSM has some interesting tiny feature, the main problem which stopped the dev was there is no consensus or CSM code deployment to clients 09:56 MTDiscord (and there still is no SSCSM consensus) 09:56 nrz_ in years it's ... argh ? 09:56 MTDiscord (mainly because we hardly know how vulnerable PUC Lua / LuaJIT are) 09:57 erle nrz_ no one knows how to make SSCSM secure or performant. but stuff like hosting CSMs on CDB should be possible. fleckenstein made something called cheatDB which is like contentDB for cheats. it shows it is possible. but it is useless (bc only cheats) and often down. 09:57 MTDiscord The Minetest CSM API would also need to be properly secured. 09:57 MTDiscord I agree with the CSM on CDB approach 09:57 nrz_ erle, it was my primary idea, use CDB (which was pretty vanilla when i developed CSM) to host it 09:57 nrz_ but server owners said, wtf we cannot control mods isntalled on clients 09:57 MTDiscord What? 09:58 erle nrz_ server owners that say that are by and large idiots 09:58 nrz_ my approach when design CSM was like World of Warcraft one, client should be able to tweak UI or some things to improve his experience 09:58 MTDiscord ^ 09:58 erle nrz_ that is eactly what waspsaliva does 09:58 MTDiscord so we can't have fun because server owners said so 09:58 erle nrz_ it has stuff like autofly, where you select a waypoint and then it flies there (which obv only works when you can fly, but is a quality of life improvement) 09:58 nrz_ now you have the history from a 9 years old coredev on this project ? 09:59 nrz_ and honestly this CSM drama tired me so much that i nearly stopped the dev on the project, but it sounds healthier today ? 09:59 erle nrz_ if you want to make a minetest fork that has better CSM support and no SSCSM, count me in. 09:59 nrz_ no i don't want to fork project, i had similar idea 5 years ago, but no 10:00 nrz_ as i'm (maybe removed ?) a coredev i prefer to work on upstream and try to change things, my ideas were sometimes opposed to the project. 10:00 erle i think listening to server owners that think that CSM = cheat is the most stupid design decision ever 10:00 nrz_ i always have the idea that coreengine should own the most critical performance prone algorithm and no the lua part 10:00 erle nrz_ are you still a coredev? 10:01 nrz_ https://github.com/orgs/minetest/teams/engine i'd say yes ? 10:01 erle nrz_ if you want to look at performance critical stuff, maybe improve particle rendering lol 10:01 nrz_ the most interesting part is that the core engine part has never moved in 3 years ? 10:01 erle ROllerozxa https://blog.separateconcerns.com/2015-06-18-love-hate-luajit.html 10:01 nrz_ for particle rendering o presented a very big particle draft years ago, but paramat blocked it 10:02 erle nrz_ show 10:02 nrz_ i presented meteo system through core engine ? 10:02 erle nrz_ meteo? 10:02 nrz_ weather: sorry taked in french ? 10:02 erle nrz_ the problem with particles is that every particle is a billboard scene node abomination thingy with its own drawcall overhead. 10:02 nrz_ https://github.com/minetest/minetest/pull/7519 10:03 erle ROllerozxa “When you find a bug in LuaJIT, understanding it and fixing it is terribly complicated. The best I can do is usually to try to produce a small test case that reproduces the bug (even that is not always easy) and hope Mike Pall finds a fix. With PUC Lua I could probably fix it myself - but of course PUC Lua is so simple that I have never found a bug in it!” 10:03 nrz_ pretty vanilla but working ? and client side handled with high level api from server 10:04 erle nrz_ that reminds me of when very early (when i was maintaining minetest delta) someone submitted a weather system. that person neer cleared up their whitespace, so it never got merged! 10:05 erle neer → never 10:05 erle nrz_ i urge you to try out waspsaliva to see at least some of your vision of CSMs 10:06 erle it has automatic building from schematics (if users have the resources) and even e2e-chat 10:06 erle and stuff like “set a waypoint where you have last seen a user” 10:06 erle so you can seek them out or avoid them 10:12 erle ROllerozxa see also https://web.archive.org/web/20220509101211if_/https://news.ycombinator.com/item?id=12574290 10:13 erle > We still would like to hire someone to work on LuaJIT. We've found it very, very hard to find anyone suitable. There are few people who understand LuaJIT internals and few who want to get into it. 10:13 erle https://web.archive.org/web/20220509100404if_/https://news.ycombinator.com/item?id=12573981 10:13 erle > I love commentary on LuaJIT, it's like a discussion of the subtleties of an acient game whose practitioners understand and enjoy, and everyone else ignores. 10:17 nrz_ sorry but not interesting on looking for a fork or work on it ? 10:29 rubenwardy [10:47] <+nrz_> luatic, entites inside radius function call has been heavily optimized on my side, but maybe it's not the right solution to use, and if we can know which generic function is needed from core engine to solve this issue, let's implement it 10:29 rubenwardy Pffft. You only did a superficial optimisation of the Lua binding iirc. The algorithm is still O(n) over all loaded entities, rather than using a spatial partition. Wouldn't consider this heavily optimized 10:31 nrz_ no one optimized it more than 3 years after i did this ? ? 10:32 rubenwardy It's nontrivial, requires changing how objects are stored or adding an index 10:32 MTDiscord erle: I see. yeah LuaJIT is of course larger and more complex than PUC Lua (it even has assembly code last I checked! madness!)... and maintenance is of course quite an important issue, I don't see cloning mike being viable anytime soon :P 10:50 MTDiscord ^ 10:51 MTDiscord Worth mentioning that libspatialindex is too weak for this 10:51 MTDiscord So we'd have to swap that out with something like https://github.com/tuxalin/THST 10:54 rubenwardy you don't need a library for spatial paritions. MapBlocks are an example of a spatial partition 10:54 nrz_ rubenwardy, ok, i have an idea in mind, let's see if i can poc it during the week or not 10:54 rubenwardy but an oct-tree is more efficient when you have a lot of objects at varying densities 10:55 MTDiscord ^ 10:55 MTDiscord that 10:55 rubenwardy see #11973 10:55 ShadowBot https://github.com/minetest/minetest/issues/11973 -- WIP: Performance improvements for entity collision by JosiahWI 10:55 MTDiscord although I don't want an oct-tree, I want an R-tree 10:55 celeron55 take into account also that there will be large amounts of objects added and removed from the spatial index 10:55 celeron55 so adding and removing has to be fast 10:55 MTDiscord rubenwardy: yes, we collaborated on that PR 10:55 MTDiscord it uses an R-tree 10:55 MTDiscord and as said, we need THST unless we want to reimplement R-trees 10:57 sfan5 would reimplementing r-trees be that bad or 10:58 rubenwardy using a fixed partition (like MapBlocks do) gives you the best case for add/remove time, and the lookup case isn't that bad if the density doesn't vary insanely 11:01 sfan5 couldn't a simpler data structure work too? something like std::map> 11:01 rubenwardy that's a fixed partition 11:01 sfan5 yes 11:01 rubenwardy We had a PR for that in the past by numberZero, it was merged and then reverted 11:01 sfan5 though the issue you have regardless of approach is keeping the data structure and object position in sync 11:03 erle why was it reverted 11:03 rubenwardy there were some issues and it was a week before a release 11:03 rubenwardy it being the revert 11:04 rubenwardy #6587 and #7539 11:04 ShadowBot https://github.com/minetest/minetest/issues/6587 -- Optimize entity-entity collision by numberZero 11:04 ShadowBot https://github.com/minetest/minetest/issues/7539 -- Revert 6587 - Optimize entity-entity collision by lhofhansl 11:05 erle ROllerozxa basically every comment on LuaJIT is a variation of “you need to have a deep understanding of *both* lua and JITs before you even try to make sense of this” 11:06 erle does anyone have an opinion on strict mode? i.e. not turning typos into nils? 11:07 erle https://web.archive.org/web/20200131012133/http://metalua.luaforge.net/src/lib/strict.lua.html 11:18 MTDiscord Sfan is thinking along the same lines as me. I want an unordered map aligned with mapblocks, because objects get unloaded with mapblocks, and so we should align the index to that. But having a vector for every single mapblock is quite memory intense, so obviously any empty mapblock is just going to be a null pointer. But even that 8 bytes • number of possible mapblocks is like 393 GB, so we need a fixed octtree hierarchy of 11:18 MTDiscord mapblocks. There are 3750 by 3750 by 3750 total mapblocks, and so having probably two more levels is reasonable, say one of 50•50•50 and each of those made up of 75'75'75 mapblocks. The only level that must be loaded in ram is the top, which 50 • 50 • 50 • 8 bytes = 1 MB. We can do a vector or a map as the bottom storage container, probably map for fast insertion and deletion. That's just my design, focusing on fixed box sizes so 11:18 MTDiscord we can do math really fast. I believe R trees are flexible in size, and so we can't optimize for it nearly as well. (Goes my thinking) 11:19 MTDiscord Then, entities must store their previous index position, and update it each of their steps. 11:20 celeron55 and then, what about the case where we extend the node space to more than 16^3 bits? 11:26 erle ROllerozxa given that issues like https://github.com/LuaJIT/LuaJIT/issues/203 exist, i bet the end game of “hard depend on LuaJIT” would be to integrate it into the minetest codebase to make it less modular hehe ;> 11:28 nrz_ i think we can do simpler, and remember that you just offload the position radius check to mapblock search + inside radius checking. The kissier (and thread_safe) we can do is the better 12:15 Zughy[m] so, should we warn players that maps are not compatible anymore between a version and another? #12005 12:15 ShadowBot https://github.com/minetest/minetest/issues/12005 -- Old maps are upgraded to ZSTD block compression, making it impossible to load the world in 5.4 12:17 rubenwardy Given 5.5 has been released, looks like no 12:20 erle it still has not been widely packaged 12:20 Zughy[m] closing then 13:42 sfan5 Zughy[m]: the release notes contain warning 13:44 sfan5 +a 14:17 josiah_wi irr#84 is ready for review, or if it's unlikely to get reviewed it'd be good to know so I can stop working on it. 14:17 ShadowBot https://github.com/minetest/irrlicht/issues/84 -- Restore some unit tests by JosiahWI 14:24 erle josiah_wi, wasn't it RFR months ago? 14:25 josiah_wi RFR? 14:25 erle josiah_wi, why did you remove the driver thing? apart from it not belonging in a test arguably, isn't it important info? 14:25 erle ready for reviewo 14:25 erle ready for review 14:25 josiah_wi Yes, but it wasn't passing. 14:26 josiah_wi The CI that is. 14:26 josiah_wi I removed the driver test temporarily because it was segfaulting on MacOS. 14:26 josiah_wi I still have it in my working tree to fix. 14:27 erle i absolutely hate the “you are not allowed to add tests that are not passing” idea, but i see why you did it 14:27 erle i think that “does the CI pass tests” should not be intimately coupled with “is this mergable” 14:28 erle at least not to this degree 14:28 erle simply making sure that a test that passed last time is not non-passing this time would be enough IMO 14:28 erle (then you could add new tests that fail before fixing the implementation all the time) 14:28 erle so, bad CI if you ask me 14:28 erle bad CI *policy* 14:29 rubenwardy You are allowed to add tests that are not passing if they're whitelisted/skipped and about a planned feature 14:30 nrz_ strange way of development :p 14:30 josiah_wi I opted not to add it yet because I don't know why it isn't passing, and at this point I just want to get something useful merged. 14:46 MTDiscord celeron55: in that case, the 50•50•50 top level just gets increased, the question is, are we trying to go full infinite size or just a larger world? Either way 50•50•50 leaves room for a solid 206 more slots for the same efficiency, and there's nothing except ram stopping us from going larger. The ram requirements for 256•256•256 Is 16 MB, and that gets you a 300,000 node cube width... The second layer could also be 14:46 MTDiscord larger, with little to no cost, raising from 75 to 256 and yielding a 1.2 million edge side. I really can't think of a case where you don't hit computer limits of RAM and Storage for such a large map before this index hits issues 14:58 erle exe_virus just how many mapblocks do you want to forceload at the same time? (or does this even matter) 15:06 erle rubenwardy this is funny because both minetest 5.3 and minetest 5.4 were released with tests not passing on my machine and tests passing even if they should not have passed (test contains unconditional UB) ^^ 15:06 erle i.e. the CI is both too strict and not strict enough :P 15:06 rubenwardy your machine is a bit of an edge case 15:06 erle nah, most of it has nothing to do with the gcc x86 rounding stuff 15:07 erle if anyothing is an edge case, it's me complaining about it 15:08 erle also the “tests passing if they arguably should not” is a general thing that is hard to address as long as merges are not allowed with failing tests, unless you commit the fix for it at the same time. 15:08 erle after all, any fix would literally make the test fail haha 15:09 erle (i have no good solution for this) 15:14 josiah_wi One "fix" would be to intentionally break the test once before committing it, to verify that it fails correctly. 15:14 josiah_wi If we know of some tests that are passing even though they shouldn't, perhaps we should remove or rewrite them (depending on why they are passing). 15:24 MTDiscord Erle: none, the thinking is the top level stores just null pointers for empty areas, but areas that are filled go down the tree. I might make a gif explaining it or something 15:32 erle josiah_wi i'll wait with any concrete actions regarding testing until your stuff is merged. if it is not merged, there is simply not enough interest IMO. 15:41 josiah_wi At the moment I'm interested in figuring out what things are highest priority for increasing the project quality. I think testing is probably pretty low priority. 15:42 erle well, they are low priority, but that's a policy decision, not a technical one 15:42 erle IMO you don't get much better low-effort QA than having a bunch of automated tests 15:43 josiah_wi What long-term result are we expecting from having more automated tests? 15:43 erle i expect fearless refactoring 15:43 erle if a component is well-tested, you can be sure it behaves similarly 15:43 erle before and after a refactor 15:43 sfan5 so people stop accidentally breaking things 15:44 erle that's a different way to phrase it, yes 15:44 sfan5 (not necessarily during refactors) 15:44 erle true 15:44 sfan5 but irrlicht tests are indeed low-priority, most code is known to work and either 1) planned to be kept unmodified or 2) not planned to be refactored but rather be replaced entirely 15:45 josiah_wi That's fair. If we can implement the tests necessary (for Minetest) for that then maybe it's higher priority than I thought. 15:45 josiah_wi Are there areas of Minetest that aren't tested well? 15:46 sfan5 yes, almost everything 15:46 josiah_wi Yikes. Can we write those tests without restructuring anything? I'd be quite surprised if that's possible... 15:46 erle tests also make it easy to find more crashes through fuzzing the remains of irrlicht 15:47 sfan5 depends on which part 15:47 sfan5 for example the devtest unittests could be expanded greatly to test the interaction and functioning of large parts of lua_api.txt 15:48 nrz_ yeah devtest is one of the best addition we did to replace minimal, when we refactored the part to have some lua tests for new features. If i remember i started with some new functions and wuzzy followed and then everyone ❤️ 15:48 josiah_wi If I'm seeing this right, paradust7 pulled in the Catch2 library recently. 15:49 erle wuzzy has many good ideas for testing, i suggest to ask wuzzy 15:49 nrz_ for the C++ part it's not so easy to test. our codebase is huge and the object separation is not sufficient to cover so much code 15:49 erle one of the funniest was “attach entities in circles like A → B → C → A” 15:51 erle there is a lot of low-hanging fruit though. about every function that processes coordinates for example. 15:54 josiah_wi Has there ever been a discussion of replacing Minetest's test runner with a framework? I can't find any issues about it, but it'd make it a lot easier to write tests. 15:55 sfan5 would it? 15:56 josiah_wi Good question. IIRC Minetest does have macros for doing assertions. 15:57 rubenwardy Self-registering tests are very nice 15:57 rubenwardy not that you need a framework for it https://blog.rubenwardy.com/2019/02/17/cpp-self-registering-test-macros/ 15:57 rubenwardy the bigger reason would be IDE integration and report generation 15:58 rubenwardy and assert utils 15:58 rubenwardy might take a while though 15:59 josiah_wi Yes, I like the example outlined by Ruben. Self registering tests would be very convenient. 16:00 josiah_wi Report generation can be done by CTest and shouldn't depend too much on how the tests are set up internally. 16:00 erle there are some cases that need to be addressed by a test framework though 16:01 josiah_wi It looks like there's never been an issue opened to discuss using ctest. 16:01 erle for example, optimization-unstable code. 16:01 erle josiah_wi usually requirements come first (i.e. what we are doing now), are you sure you are not putting the cart before the horse? 16:02 josiah_wi Writing all the tests before deciding how to structure them would certainly be putting the cart before the horse. 16:02 erle rubenwardy i am a big fan of test frameworks being small and fitting a single header file 16:02 josiah_wi erle, have you seen doctest (for C++)? 16:05 erle josiah_wi i have looked it up just now. never heard of it before. i am a bit rusty on this kind of thing: i might have used µnit once, not sure. 16:06 erle no, i think it was minunit? 16:06 erle josiah_wi, basically this https://github.com/siu/minunit/blob/master/minunit.h 16:06 erle anyways, good luck! 16:12 erle josiah_wi you wrote “There's a lot of unnecessary media that I accidentally committed. I'll be removing that.” – are you aware of interactive rebase? you can remove them from the history entirely. if you add something in a commit and remove it later, it may still bloat the repository 16:12 sfan5 we don't do merges so that's irrelevant 16:13 josiah_wi git is hard. I goofed up quite a bit in that PR. 16:14 erle josiah_wi i wanted to point you to something that may help you to fix similar things in the future, not chastise you. 16:14 josiah_wi Yep, thank you! 16:20 josiah_wi Hey, we have some new warnings in master, one of which looks serious. 16:20 erle show and tell 16:20 josiah_wi There's a comparison in the serverpackethandler I think it was that is always false due to the range of the data type. 16:20 josiah_wi I may need to recompile to get a log. 16:22 sfan5 the code works as intended, it just so happens that the lowest support version is 0 which is also the lowest possible number 16:22 sfan5 +ed 16:23 josiah_wi Ah, shouldn't the warning be fixed? 16:24 sfan5 how? 16:26 josiah_wi By changing the data type? If that isn't a solution, then there should be a comment in the code. Maybe there is - I haven't found the line yet. 16:27 josiah_wi But wait, if the comparison is always false, then why have it at all? 16:28 sfan5 I will be useful in the future if the minimum version becomes > 0 16:28 sfan5 it* 16:30 josiah_wi There's probably a way to declare the minimum version so that the compiler understands it won't always be 0. 16:31 MTDiscord Makes sense. In real world project, "code" and "configuration" are not really separate things but exist on a continuum, and you choose a more or less arbitrary cutoff for what gets done in a code language and what is done in a config language, if you employ one. A compiler can't tell the difference, though. 16:32 josiah_wi Ah, I see now. 16:33 josiah_wi What about the -Wmaybe-unititialized warnings in e.g. frame_length_ms, nodedef.cpp line 727? 16:34 erle i think such a warning is probably there because it ensures you take into account the dead code elimination will make the compiler emit no machine code for stuff that the compiler knows to be always true or always false 16:35 erle josiah_wi by “changing the type” you mean having an enum instead of a number, right? 16:35 josiah_wi sfan5, Minetest master just segfaulted 16:35 josiah_wi I was trying to join YourLand server with a clean build. 16:36 josiah_wi erle, "changing the type" was due to a misunderstanding of the warning. 16:36 josiah_wi I see now that it can't really be avoided. 16:37 MTDiscord Re: segfaults, it's a bit of a PITA to run MT under gdb, so generally you'd only do it if you're anticipating a crash, but there's this nice catchsegv program that you can just run it under always, and at least get some useful information out of unexpected/rare crashes. I haven't seen a measurable performance impact. 16:38 josiah_wi Sounds good. I need to rebuild in Debug mode first anyways, and I should probably rebuild the Release build because I had a duplicate config that was causing some warnings. 16:43 josiah_wi Nevermind, those weren't due to the other config. 16:43 josiah_wi Some symbols are redefined in a few places. 16:44 josiah_wi Anyway, is the world creation menu not scaling to the resolution a bug? 16:45 josiah_wi Warr1024, this is not necessarily an "unexpected/rare" crash. It happens on singleplayer as well. 16:45 josiah_wi I assume I can reproduce this crash consistently with this build. 16:47 josiah_wi "0x0000555555cb9093 in irr::scene::COBJMeshFileLoader::cleanUp() () 16:47 josiah_wi 0x0000555555cb9093 in irr::scene::COBJMeshFileLoader::cleanUp() () 16:47 josiah_wi Whups, sent twice. 16:47 josiah_wi That's what gdb reports. 16:47 josiah_wi Perhaps I should rebuild IrrlichtMT. 17:01 erle josiah_wi depending on what kind of crash it is, you might get some very nice messages with ubsan or asan (though the latter makes the game unreasonably slow, so while it is useful for stuff like “crash during join”, i would not want it for much more) 17:13 josiah_wi Sorry, it works with irrlicht master. 17:20 sfan5 by the way you can use the "RelWithDebInfo" to get a release build but with debug symbols = meaningful backtraces 17:21 sfan5 and you can run gdb in batch mode to automatically generate a backtrace upon crash but not interfere with program execution otherwise 17:26 josiah_wi Excellent. 17:27 josiah_wi Would it be helpful for me to submit a PR to fix a bunch of these warnings? Is someone else already doing it? 17:29 sfan5 sounds good 17:32 sfan5 don't bother with the one in src/server.cpp, a future commit by me will fix it anyway 17:52 Zughy[m] should Devtest related issues be subject to the "Roadmap" approval rule? Like #12307 17:52 ShadowBot https://github.com/minetest/minetest/issues/12307 -- DevTest: Add item meta editor by Wuzzy2 17:53 Zughy[m] Also, "Devtest game" could be a component of its own ("@ Devtest game") 17:53 Zughy[m] *on 17:57 rubenwardy It probably comes under maintenance/code quality 17:57 rubenwardy And yeah, it should be @ 17:58 Zughy[m] yeah, almost every issue/PR with "Devtest game" has no other component, that's why I said that 18:04 josiah_wi I did fix the -Wtype-limits warning: the cleanest solution I could find was to define a constexpr function that simply returns the constant. 18:08 erle i think devtest would work much better on cdb tbh 18:09 erle rubenwardy i have a mod dependency riddle: why does my mod mcl_lever_status_indicator lead to installing doors? 18:10 erle rubenwardy oh i figured it out just now, it depends on mesecons_wallleve, which is provided by mcl5 but also by mesecons, but the mesecons draws in doors lol 18:10 erle mesecons_walllever 18:10 erle rubenwardy do you think minetest should maybe evaluate the dependencies for download differently, if the base game selected already has them? or did i do something wrong maybe? 18:16 rubenwardy Already does 18:27 Krock will merge #12270 #12241 #12239 and game#2951 in 15 minutes 18:27 ShadowBot https://github.com/minetest/minetest_game/issues/2951 -- Carts: Improve movement behaviour by SmallJoker 18:27 ShadowBot https://github.com/minetest/minetest/issues/12270 -- HUD: Update selection mesh every frame by appgurueu 18:27 ShadowBot https://github.com/minetest/minetest/issues/12241 -- Fix Minetest blaming the wrong mod for errors by appgurueu 18:27 ShadowBot https://github.com/minetest/minetest/issues/12239 -- Docs: Recommend `entity.name` by appgurueu 18:41 Krock merging 18:44 Krock done 19:19 sfan5 merging #12274 19:19 ShadowBot https://github.com/minetest/minetest/issues/12274 -- Add more Prometheus metrics by sfan5 19:24 rubenwardy Are there any plans to add more benchmarks? Having e2e stress tests for block emerging would be useful 19:25 rubenwardy Although I can see that being painful to set up 19:26 sfan5 you want to test mapgen or just how long it takes from a disk read to the client in general 19:26 sfan5 ? 19:26 rubenwardy Haven't thought about it that much tbh 19:29 erle rubenwardy emerge stress tests, you mean like mcl_engine_workarounds? https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/mods/MISC/mcl_engine_workarounds/init.lua#L141 19:30 erle you can easily modify the loop there to emerge more stuff (i.e. let it take longer) 19:53 erle rubenwardy amazing news: if you modify mcl_engine_workarounds just a little bit, i think you can trick minetest into running an emerge callback forever 19:53 erle rubenwardy, you just need to give it a minpos with x=32767 19:55 erle then minetest will do nothing except try to emerge this thing, fail at it, then try to do it again. possibly several times a second. 19:57 erle tested with commit a66e6d4df 19:57 erle i hope this is enough stress testing for you :) 20:03 rubenwardy just for context, I was thinking about more things to add to https://www.minetest.net/benchmarks/dev/bench/ 20:08 josiah_wi :q 20:08 josiah_wi Whups, pretend you did not see that. 21:00 rubenwardy Isn't "No core dev support long term" kinda redundant given "Won't add" and "Won't fix" 21:00 rubenwardy last used 2020-09-10. Delete? 21:00 rubenwardy also only on closed issues 21:01 erle rubenwardy i guess a WONTDO file would be a better idea. but why remove it? 21:01 erle it sounds broader than a WONTFIX 21:02 erle also if you remove it wouldn't you need to tag all the issues it was used for as WONTFIX 21:02 rubenwardy removing unnecessary labels is good 21:02 rubenwardy GH has some bulk functionality 21:02 rubenwardy won't add and won't fix can probably be merged 21:28 erle rubenwardy any issues with me submitting mods to CDB that a) trigger engine crashes b) apply workarounds for those, mainly checking arguments? i think that's the easiest way to get engine updates to older versions of minetest. 21:28 erle i was thinking of two modpacks, one that you can use to check if your engine version crashes, then the other you install to make it not crash anymore. 21:36 sfan5 the simplest way to get engine updates is to update 21:41 erle i think you have extremely unrealistic expectations about what kind of update a typical user is going to do 21:41 erle laste i checked, there were *still* people complaing that mineclone5 does not run with minetest 5.3 21:41 erle on their raspi or something 21:45 sfan5 and why is that? is it because users do not want to update? 21:50 erle since minetest has not suddenly increased any HW requirements, my suspicion is that their distribution is not remotely up to date 21:50 erle but given that ubuntu LTS users will be on minetest 5.4.1 for the forseeable future, i doubt this will change much 22:23 Zughy[m] rubenwardy: "No core dev support long term" sounds redundant indeed 22:25 Zughy[m] The other two, heh, I guess there is a difference as for the current names, but maybe another name can be found to represent both and remove one of them 22:27 Zughy[m] also, "Incompatible change" was last used in 2015 22:30 MTDiscord My understanding of "no core dev support long term" is that it basically means "probably won't fix but I'm not willing to like commit to that." Seems reasonable to remove it since leaving things in a non-committal state is sort of a thing the new triage system is supposed to get rid of, right? 23:29 Pexin the impression I got when I ran into ncdslt was, "it might be a neat addition, but will require a coredev to care enough to be sufficiently familiar with its complexity for - in this case - obviously inevitable refactoring later" 23:30 Pexin or more briefly "I *kinda* like it, but I don't want to get stuck maintaining it" 23:31 MTDiscord Haha, I thought that was the criteria for "one approval" :-) 23:31 rubenwardy ncdslt? 23:32 MTDiscord ncdslt. 23:34 rubenwardy oh the tag 23:34 rubenwardy maybe say "the label" 23:35 Pexin the cumbersome length of The Tag may itself be an indicator it should be dropped :]