Time Nick Message 00:01 [MatrxMT] qualitative discussion can go before the voting 00:01 [MatrxMT] why you feels something is key 00:01 red-001 one day desktop linux will know how to manage a swap file.. till that day 00:01 MTDiscord ? 00:01 red-001 in reference to the joke about windows 00:01 MTDiscord pro tip: you can mount a file as a partition 00:02 MTDiscord In my own voting, I won't just prioritize things that have an impact on me, but ones that actually seem feasible to fix with the right skillset. That means I'm willing to suffer an annoying heisenbug like that "player teleport sometimes randomly just doesn't work" one in order to get something more major like "images remain in the cache forever" 00:03 red-001 most distros handle memory pressure poorly, you get swap trashing which on the other hand just doesn't seem to happen under NT - at least not in the desktop configuration 00:03 [MatrxMT] maybe, limiting the list to 5 complex, 5 simple. that way, it keeps the demands down in terms of size, and we can decide what big stuff we actually care about 00:03 MTDiscord If I had to pick only one today, I think I'd go with that image caching one. If I could pick two, having ABMs go into a queue and get spread out over multiple steps would be the 2nd one. I might need more time to think if I had to pick 3. 00:03 [MatrxMT] oooh, i like your abm one 00:03 MTDiscord can we get this stuff noted and voted somewhere 😂 00:04 [MatrxMT] it's not like most don't start with abms and just abandon it for for death by globalstep 00:04 MTDiscord write a gist as a proposal, and submit it to c55, thats what typically happens 00:04 MTDiscord nah the generate decorations thing 00:04 [MatrxMT] nothings been more abused than the global step 00:04 MTDiscord i'm a bit surprised frankly that the image caching one was that important for nodecore? 00:04 MTDiscord that needs to get back 00:04 MTDiscord I think for me the dichotomy that's important isn't so much "complex vs simple" as it is "stand-up fight or another bug hunt." Where it's clear what work needs to be done and we're not just struggling to reliably repro something helps a lot. 00:05 MTDiscord Lars: Players really hate the "navigate by the stars" feature, and a lot of it is because I majorly curtailed it to deal with the fact that redrawing the skybox fills up player RAM. 00:05 MTDiscord ah, i see 00:05 MTDiscord To me, image GC is a bugfix, not a new feature, and I prioritize it accordingly. 00:05 [MatrxMT] the thing that bugs me most is the weird loading of chunks, in any order and the blue light in the middle of 2 rendered ones. it's so weird and ugly 00:06 MTDiscord pretty sure that got improvements in 5.9, citation needed tho. might be misremembering 00:06 MTDiscord AM, I'd love to vote for better chunk loading stuff, but stuff like that is like half way down my own list 😄 00:06 [MatrxMT] lol 00:06 red-001 oh btw re those discussions about whatever SRP is secure enough: https://arxiv.org/abs/2003.07421 00:06 red-001 it's verified if that weird operation v + g^b is considered to be encryption 00:06 MTDiscord Actually I am only like half as concerned about mapblock rendering, for me it's more important to load them for collision purposes. 00:06 [MatrxMT] well, let's see your list and you can convince the steering committee (self-appointed) 00:07 [MatrxMT] everyone grab a wheel 00:07 [MatrxMT] wsor, there is something on the mapgen multithreading, hopefully it has an impact, but i don't know much of the detail 00:07 MTDiscord I haven't updated the nodecore list for a while, but it's probably the most robust list I have right at this moment: https://gitlab.com/sztest/nodecore/-/blob/dev/WISHLIST 00:08 MTDiscord am: dont think mapgen mutlithreading helps with rendering at all. the multithreading is more targeted at moving lua mapgen off the main thread to prevent blocking(lag) of the main env 00:08 [MatrxMT] ah, ok 00:09 [MatrxMT] is prioritised abms a concept that has been discussed? 00:09 MTDiscord heh, I don't even have any solid plans to move to the new async mapgen stuff, myself. It sounds cool, but I'm satisfied enough with the optimization I already did on my main-thread mapgen that a lot of other things are more pressing. 00:09 [MatrxMT] if a number get jettisoned after the allotted time, surely we can hint at what most we care about? 00:10 MTDiscord if by "prioritized ABMs" you mean "make certain ABMs more likely to run than others if some need to be skipped" I don't know if that's feasible; the way it works is always all ABMs per mapblock. There are performance implications of breaking that assumption. 00:10 MTDiscord Right now though the ABM scheduler is TERRIBLE 00:11 [MatrxMT] but the way it works, just pushes people to prioritise via globalstep 00:12 [MatrxMT] your suggestion for delaying could work well with prioritisation 00:12 MTDiscord What basically happens is that with default settings at ABM saturation, you're running one tick a second that has an extra 200ms of ABMs in it, and then the other 800ms each second, no ABMs are running, so you can have your globalstep bumped way up, still not spend 80% of your CPU available on ABMs that need it even if nothing else does, and you get a big step jitter that makes server-side animations janky. 00:13 MTDiscord What I think we should do is shove the mapblocks into a queue when the timer fires, in random order, and then spend X ms each step dequeueing them. They may have gotten unloaded during that time, so we need to validate them a bit. 00:13 MTDiscord Well, actually, I think I already filed an issue about this years ago. 00:13 MTDiscord #14011 00:13 MTDiscord while where talking about steering, id like to minetest prollers expand the world size stuff, not sure where that should fit in from a management perspective, but i dont think having it closed or leaving it open forever is a good idea. so dunno what the best would be 00:13 ShadowBot https://github.com/minetest/minetest/issues/14011 -- Spread ABM scheduling across multiple globalsteps without lagspikes 00:14 MTDiscord wsor: I think that's 6.0 work, right? We'd have to decide how often we're okay with making major breaking changes like that. 00:15 MTDiscord tbh I think the decision of how to handle major releases is a lot like the decision for minor ones: there are a number of ways you could do it, like based on the total amount of value/change, or purely based on time as long as anything is ready to go. 00:15 MTDiscord its not actually breaking iirc 00:15 MTDiscord I don't see how you could NOT break a ton of stuff by allowing coords outside of int16 00:15 MTDiscord been a while since i looked, but more so structured in that old clients can only go to +/- 30k, and newer clients can go further 00:15 MTDiscord I mean any mod or game that uses hash_node_position is probably going to break, let alone all existing worlds that have node pos hashes in metadata... 00:16 MTDiscord tbh i have given up hope on that 00:16 MTDiscord it's somewhat breaking ... as in old clients can't go out of the old box 00:17 MTDiscord It feels like it could be done like the way the 5.0 release was done, where there were some holdouts on 0.4 and we had a backport/bugfix release or two to ease the transition, and people mostly just gradually moved to the new stuff when it became clear that it was the inevitable future. 00:17 [MatrxMT] i guess that's what deprecation is for. if it needs to go, deprecate and nudge people off it. if they ain't done it in 2 years. ah well 00:17 [MatrxMT] and mt-mods can do it later ;) 00:17 MTDiscord and yeah probably lots of "minor" stuff like that 00:17 MTDiscord As a gamedev I already have to support a few versions of MT. I might have to fork the game if the API changes are drastic enough, I dunno. I could handle that though, I think. 00:18 MTDiscord also many mods and games have 31000 hardcoded as limits 00:18 MTDiscord am mt-mods can do it later? what is this coming from? 00:18 [MatrxMT] but if people are playing on really old clients, should we care? i mean, if you're on windows xp, i'm sorry, get viruses 00:18 [MatrxMT] it's not like you cannot get it from flatpak 00:18 MTDiscord The way I see it, there's a path forward. I think it's stickier than some people thing, but not as hopeless as others think. It seems like it's got a lot of bad inertia right now though, and its picking up some political opponents. 00:18 MTDiscord anyways, some breakage on the server side, but at least client compatiblity could be kept. also could merge it in under feature flags or something compiled off by default, so people could test it 00:19 MTDiscord am: the issue is more with distros that love shipping old stuff, cough debian cough 00:19 [MatrxMT] i think the most important thing, is make a decision, and then take slow steady steps towards it. otherwise 10 years later, and you're in the same place 00:19 MTDiscord well the reason this won't get merged isn't bc of compat though but because the general wisdom appears to be 62k ought to be enough for everyone 00:19 [MatrxMT] mc had issues with caves and cliffs, but they made that decision and migrated towards it 00:19 MTDiscord AM: a lot of the "old client" thing has to do with how well MT is able to get downstream package maintainers to update. I support current release and one older. At one time I supported like a span of 4 releases, because android was stuck on 5.0 until like 5.3 or 5.4 or something. 00:20 [MatrxMT] but fair point, and i don't really care about more than 32k myself lol 00:20 [MatrxMT] life is too short to go to the edge of the world 00:20 MTDiscord i once said "look i cant go more than like 4 hours in one direction" the answer was "go in circles then" 😛 00:20 MTDiscord if your doing planes or trains, the world is tiny 00:21 MTDiscord yeah 00:21 [MatrxMT] vl also supports last 2, but if you're on debian sluggish, just flatpak it 00:21 MTDiscord calling it a world is a huge stretch too as i like to say it should be renamed "metropolitan area" 00:21 MTDiscord I'm on debian release as well, and yeah, I use a mix of flatpaks and src builds across the machines I support. 00:22 [MatrxMT] but planes and trains are quite niche 00:22 MTDiscord I really don't mind the world size. It works fine for the games I maintain. 00:22 [MatrxMT] it's not like mapgen speed is great for fast speeds anyway 00:22 MTDiscord If somebody wants to change it I'm cool with that as long as they don't break a ton of other stuff JUST for that. 00:22 red-001 or map block loading great in general 00:22 red-001 what about stacking the world in multiple layers? that seems more fun 00:23 MTDiscord you run into minetest lovely lighting mess with that 00:23 red-001 that could be fixed with engine changes to support that sort of world 00:23 red-001 and without breaking well everything 00:23 MTDiscord Anyway, Lars already said at one point that if we want this to become a thing, we should at least start by recording some votes or something. Maybe we need somebody with GH access to either create some permission for the voting members, or to be willing to do the work of marking down votes for them or something. 00:24 MTDiscord We could create an external place to record this stuff but I don't know what direction to take that; seems like there's too much choice 00:24 MTDiscord make a doc with the concrete proposal and submit it to cdb 00:24 MTDiscord . s/cdb/celeron55 00:24 MTDiscord my bad 00:24 MTDiscord cdb55 00:24 red-001 poor c55 is a content db now 00:25 MTDiscord it doesnt help that im looking at cdb on my other monitor atm 00:25 MTDiscord I think I'd like to hear from people like green who have suggested they have some idea who should be on there, including people I might not have visibility for. 00:26 [MatrxMT] i don't mind who's on there as long as they're factoring in what others are raising 00:26 [MatrxMT] i'd nominate warr if i had to pick 00:27 [MatrxMT] but we may need a steering committee steering committee 00:27 [MatrxMT] (maybe i'm joking, maybe i'm not ;)) 00:27 MTDiscord Oh, server owners, right. They tend to maintain complex games that often just aren't feasible to publish on CDB, but they also represent a big slice of the communtiy. 00:27 [MatrxMT] good call 00:27 [MatrxMT] maybe it's a few modders, a few game devs, a few server owners 00:27 MTDiscord more complex modpacks than games, but yeah 00:27 [MatrxMT] and they can kind of lead those sub groups 00:27 [MatrxMT] and pull it all together 00:28 MTDiscord If a modder makes enough mods they often end up becoming a de facto game dev, even if nobody actually realizes it 😆 00:28 [MatrxMT] tenplus1? 00:29 MTDiscord We don't want to include everyone though, or else we've got the problem again of having too large a group to tell what level of committment is behind these votes. 00:29 MTDiscord I'd say honestly if it's not something that you'd be willing to jump on if it were added to the engine (at least, if you were able to EOS versions that don't have it) then you shouldn't vote on it. 00:29 [MatrxMT] at the risk of it being cliquey, maybe people in groups vote on who represents that group 00:30 MTDiscord If there's some kind of structure to the community where that makes sense, that could work. 00:30 [MatrxMT] if people put there name down, then if we have more than 2/3, vote on it 00:30 MTDiscord I mean it'd be nice if rather than having every modder jump in on their own, we had a few people to represent that segment who were trusted by other modders to represent their interests. 00:31 [MatrxMT] if they ignore folk, people who just vote for others 00:31 MTDiscord I might say we just start out with a target size, like 10 or 20 or something, and try to narrow it down and see if we're able to do so without somebody being glaringly left out or something. 00:31 [MatrxMT] maybe every 3/4 months you pick reps 00:32 MTDiscord I don't think modders will be underrepresented if we have some "soup" maintainers, who have to deal with integration work AND also have to often fix things at the individual mod level, and work with mod providers. 00:32 [MatrxMT] but then mod stew folk may feel left out 00:32 [MatrxMT] and this could be a problem 00:33 MTDiscord I don't know if I want to go full blown representative democracy with formal voting structures quite at this point though. This is more like an executive body like a cabinet than a legislative one. This group is serving as advisors to the core devs as much as representing groups of people. 00:34 MTDiscord Like, we're not here to fight for stuff we want done, we're here to help the core devs know which things they can focus on that will result in the most value for their work, often due to the work we do when it lands in our hands. 00:34 MTDiscord I want to make sure this doesn't devolve into a popularity contest. 00:35 [MatrxMT] true. i don't think many will volunteer, some it'll probably just be rubber stamping 00:36 [MatrxMT] but it just gives an opportunity if folk aren't happy and want to have a go 00:36 MTDiscord Dunno if you were serious about the "stew vs soup" thing but I don't make very strong differentiation. I assume even "soup" maintainers do some integration work, especially if they run a server and have to eat their own soup. 00:36 [MatrxMT] how many are going to run to do work? 00:36 MTDiscord i think this would maybe work best: have a channel or forum or whatever for that group that everyone can join and everyone who has a maintains a mod or game or whatever on cdb gets a vote for a representative they send to mt dev meetings 00:36 [MatrxMT] sorry, i was joking about the soup and stew thing as i remember your discussion on them :) 00:37 MTDiscord a lot of us probably can't reliably attend meetings and cast a vote every time; I'd like a more async kind of thing, like where our advice is tracked in GH or something. 00:37 [MatrxMT] i think that's a fair suggestion cora 00:37 MTDiscord well you could do the voting fairly asynchronously 00:37 MTDiscord the dev meeting thing ofc not so much 00:38 [MatrxMT] maybe give 2 weeks to put your name forward, and if more than 3, poll it 00:38 MTDiscord but thats the beauty of it if you dont have time this time you just say that 00:39 [MatrxMT] i think the work will get easier after initial discussions, once you have your initial lists of features/ bugs, it's just debating if some things could jump up those lists or slot in somewhere 00:39 MTDiscord and ofc if the rep doesn't rep they wont get voted for again 00:40 [MatrxMT] i thin most would just be happy to feel their feedback could go into shaping priorities in mt 00:40 MTDiscord I guess, though in a way I'm not sure if that's part of the manifest purpose of the group. 00:40 MTDiscord Like, it's not for airing grievances or something 00:41 MTDiscord It's more like if you make this change -> you break this game, and if you break this game -> it makes the whole ecosystem look this much worse. 00:42 [MatrxMT] i'm not sure anyone mentioned airing grievances? 00:42 MTDiscord The idea is that engine devs and game devs are really all in the same boat, so if anybody has navigational insight then we'd like to make sure everyone has access to it. 02:08 v-rob > "i do not understand a person who could be ignored for months about something they were enthusiastic about, then given feedback and jump in with the same energy" 02:08 v-rob I may be an outlier, but I do that all the time. 08:56 [MatrxMT] In short: 08:56 [MatrxMT] - what's the difference between the game dev committee and #14004? Feature requests can be included as well, I guess? I fear that this initiative might be yet another thing died before starting, like the Minetest docs initiative, and adding another layer of complexity... Heeeh. Maybe having a similar issue (14004) which includes feature requests might be a compromise not to overcomplicate things and avoid the risks of wasting time 08:56 ShadowBot https://github.com/minetest/minetest/issues/14004 -- :bug: Name the 3 most annoying bugs you'd like to see fixed 08:56 [MatrxMT] - every core dev has a vision of their own, the issue is having a shared vision 08:56 [MatrxMT] - in all honesty another thing that slows down development is celeron55 unavailability. It takes months to receive an answer when new core devs are proposed, so basically it doesn't matter how fast we go, if the decision is up to him. I'd personally happier if someone experienced like sfan5 or SmallJoker could call the shots in this situation, or a majority core dev vote to avoid the same problem 08:56 [MatrxMT] - I invite to continue the debate on the forums, as it's really hard to keep track of all these messages in here when more topics get touched 08:58 [MatrxMT] (There are also other things I haven't addressed) 09:06 [MatrxMT] Also note that 14004 is how we got most of the "High priority" labels 09:08 [MatrxMT] Note: I'd create the forum topic myself but I'm not at home and on the phone it's quite frustrating. So please don't see it as a way to get rid of the conversation 09:10 celeron55 i wouldn't mind sfan5 adding core devs. even just for the simple reason that the times i disagree with sfan5 are incredibly rare 09:11 celeron55 and overall the process is independent of me. someone just has to run through the few steps required 09:14 celeron55 1) check that the person is making good contribtions and communicates well, 2) ask the person privately whether they'd like to be core dev and confirm that they know the rules, 3) if so, request comments from the core team publicly somewhere, 4) if nothing comes up, add to the github organization 09:28 Krock will merge game#3125 #14807 and #15077 in 15 minutes 09:28 ShadowBot https://github.com/minetest/minetest_game/issues/3125 -- Simplify Butterfly and Firefly codes by Emojigit 09:28 ShadowBot https://github.com/minetest/minetest/issues/14807 -- Add new vector utils (ceil, sign, abs, random_in_area) by kromka-chleba 09:28 ShadowBot https://github.com/minetest/minetest/issues/15077 -- Disable CRT security warnings in MSVC. by red-001 09:28 Krock #15080 too 09:28 ShadowBot https://github.com/minetest/minetest/issues/15080 -- Debloat IVideoDriver and IrrlichtDevice includes by SmallJoker 09:42 Krock merging 09:43 Krock skipped the MSVC PR due to comment 09:44 Krock done 10:39 cx384 @Krock do you want to re-review #14321 or is approval still valid? 10:39 ShadowBot https://github.com/minetest/minetest/issues/14321 -- Add hotbar Lua HUD element and replace hardcoded hotbar by cx384 10:39 cx384 * the approval 10:57 Krock re-reading 11:22 [MatrxMT]

I may be an outlier, but I do that all the time. 11:22 [MatrxMT] i guess you've got a level of stoicism and patience that many aren't capable of :) 11:23 [MatrxMT] btw, how's your enthusiasm for formspecs replacements at this time? 11:25 [MatrxMT] on the topic of each core dev having a different vision of the project. is it worth each core dev knocking up a few sentences on their vision or focus and what they'd love to see improved? it'd really help to understand that vision and those working on it, or what they specialise in 11:26 Krock #12746 11:26 ShadowBot https://github.com/minetest/minetest/issues/12746 -- Roadmap brainstorm (5.8+) 11:26 Krock there you have some vision 11:27 [MatrxMT] ah good point. i'll check it out. it's almost 2 years old now, is there plans to revamp or update it? 11:27 [MatrxMT] how frequently is the roadmap usually updated? 11:28 Krock https://github.com/minetest/minetest/blob/master/doc/direction.md check the history 11:28 [MatrxMT] thanks. i need to bookmark this 11:29 Krock at the end it boils down to the person who's got time to implement a feature that's generally liked 11:30 [MatrxMT] true 11:30 [MatrxMT] for the next roadmap, is it worth drawing a little summary together of progress from the last version, to celebrate steps taken in that regards 11:31 [MatrxMT] i guess 2 years is a long time to forget prs and where mt was 2 years ago 11:32 [MatrxMT] (not trying to create work for folk, but it could be nice to see) things like the debundling and settings work have been really good steps forward 11:32 [MatrxMT] and i guess many may not always understand the less visible stuff. it may not get the credit it justifies 11:38 [MatrxMT] i was going to say something, but i think i better exit the dev channel as others could answer it. thanks for the patience 11:39 [MatrxMT] and openness 11:39 Krock !next 11:39 ShadowBot Another satisfied customer. Next! 11:47 sfan5 @Zughy I don't disagree in principle but I would not like to take on another responsibility 12:37 cx384 I wonder how many issues were never opened because minetest still uses github. https://forum.minetest.net/viewtopic.php?t=30939 12:38 cx384 probably not many 12:38 sfan5 inversely, how many contributions or even contributors did get we gain because Minetest is on github? 12:39 MTDiscord probably zero. i don't think anyone stumbles across a repo for a game and starts coding. they play the game because it's open source, and then reach out to it 12:39 MTDiscord most open source games are found through word of mouth 12:40 [MatrxMT] I'm on GH just for Minetest and rubenwardy is using it for the same reason 12:40 MTDiscord but i wouldn't underestimate animousity and lack of trust to ms, especially with co-pilot 12:41 sfan5 someone stumbling upon a random repo and deciding to contribute is not realistic 12:41 MTDiscord i'm on github to auth across to mesehub 12:41 [MatrxMT] @cx384: I thought `type` for HUDs were retrocompatible. If I use it, 5.8< versions won't render it 12:41 sfan5 what I mean is someone who uses or mods MT anyway and files an issue or PR because they already have a github account and it's quick and easy 12:42 sfan5 vs. registering a new account on some platform they have never heard of before 12:42 MTDiscord i think there is also the option of gitlab, or ideally codeberg 12:42 [MatrxMT] cx384 https://gitlab.com/zughy-friends-minetest/arena_lib/-/issues/334 12:42 [MatrxMT] Maybe I've misunderstood 12:42 MTDiscord both have a reasonable chance of people having accounts or not having reservations. codeberg is the daddy of open source now 12:43 MTDiscord so anyone who cares about open source will either have an account or be open to getting one 12:43 rubenwardy Gitlab is not totally free and may end up with us in the same situation 12:44 [MatrxMT] sfan5: from my experience, not a lot of modders open issues on GH. When I start working on a new area of expertise, I usually find many bugs and I can't believe NOBODY have ever noticed 12:45 [MatrxMT] most mod bugs are probably by Wuzzy, Warr and me 12:45 cx384 @Zughy no `type` only works for newer versions, the main reason why it had to be changed was that `hud_get` already used `type` instead of `hud_elem_type` 12:45 sfan5 this is anecdotal but I deal with lots of other stuff besides MT and I don't remember ever coming across a codeberg repo 12:45 MTDiscord I wouldn't trust any git platform that caters to enterprise, be it GitHub or GitLab the praise that underpaid copywriters (and now AI) keeps giving to GL doesn't make it any better 12:46 sfan5 @Zughy indeed, I wager almost all modders just go "huh it's broken, guess I have to find a different way" and never consider filing a bug 12:48 cx384 @Zughy the issue if you are interested: #14043 12:48 ShadowBot https://github.com/minetest/minetest/issues/14043 -- `player:hud_get(id)` returns a table with `type` instead of `hud_elem_type` 12:48 [MatrxMT] sfan5: I've met only one person playing MT instead of MC in real life (before I told them about MT), so I don't think that the comparison "knowing people on Codeberg" really applies 12:48 MTDiscord it's undeniable that github has first mover advantage and inertia. it will also have more registered people. but that won't neccessarily mean the landscape now will be the same in 5-10 years. especially with increasing enshittification 12:48 [MatrxMT] Also Codeberg devs were always nice with us, also at FOSDEM 12:49 [MatrxMT] *have always been nice 12:49 MTDiscord i think open source stands on the shoulders of giants, and i think solidarity is important if we'd want some in the future 12:49 MTDiscord for example if ms vaguely decides that there is a copyright violation due to mc, blocks it and takes ages to unban 12:50 MTDiscord a "sorry, my bad" after 6-24 months will not undo the damage of that 12:50 MTDiscord see play store for more details 12:51 [MatrxMT] @cx384: heh.. Now devs are forced to put an if, because if we don't use "type", it spams warning in consoles; on the contrary, if we use only "type", it's not retrocompatible 12:53 cx384 @Zughy you can also do it in one line with an or https://github.com/minetest-mods/areas/pull/78/files 12:54 [MatrxMT] Still an if :P 12:54 cx384 And no you are not forced to do it, you will just get a deprecation warning ... 13:09 [MatrxMT] Warr1024, ancientmariner etc.: thoughts on the "name the 3 feature requests you'd like to see prioritised" issue? Maybe asking people to identify what's their content/server contribution to the community when they post 13:18 rubenwardy Yeah for the hud_elem_type thing I think we could have delayed the deprecation warning for a release or so. Or maybe a development mode that enables warnings might be nice, if it's set up in a way that modders won't miss it 13:19 rubenwardy Another idea would be to have API versioning, where mods ask for a particular target 13:22 MTDiscord i don't think that would necessarily work on the issue tracker. it feels like a we'll only consider the feedback based on how much you make. it probably isn't the intent, but it feels more exclusionary than inclusionary. i'd say it's better to ask for examples in which it has impacted on something you've worked on or played on 13:24 MTDiscord to understand the use case and the need of it 13:26 [MatrxMT] I can ask for examples. I'd stick with the issue because it makes my life easier. Having discussions around different platforms is a mess 13:46 cx384 Merging #14321 in 15 min 13:46 ShadowBot https://github.com/minetest/minetest/issues/14321 -- Add hotbar Lua HUD element and replace hardcoded hotbar by cx384 14:05 cx384 *merged* 14:16 [MatrxMT] @cx384 so calls like set_hotbar are just diverted towards the builtin? 14:17 [MatrxMT] *set_hotbar_foo 14:23 grorp2 my "rebase" of #15022 means that it now reverts and reapplies #14321 14:23 ShadowBot https://github.com/minetest/minetest/issues/15022 -- Restore proportional minimap scaling by grorp 14:23 ShadowBot https://github.com/minetest/minetest/issues/14321 -- Add hotbar Lua HUD element and replace hardcoded hotbar by cx384 14:24 grorp2 I don't see how we can keep consistency otherwise 14:24 grorp2 except if we manually bumped from 44 to 45 in the 5.9.1 backport PR 14:25 cx384 @Zughy no it still in C++, the element does not have this features, yet: https://github.com/minetest/minetest/blob/master/doc/lua_api.md#hotbar 14:26 grorp2 cx384: how did you imagine this would work? 14:27 cx384 I reserved protocol version 45 14:27 grorp2 sure, but how did you imagine this would work? 14:29 cx384 A new branch for version 5.9.1? 14:30 cx384 Which only has the bugfix commits. 14:30 grorp2 sure, the fix will be merged into master and later cherry-picked into stable-5 as the "5.9.1 branch" 14:32 cx384 While cherry picking you have to adjust the protocol version? 14:36 grorp2 https://github.com/minetest/minetest/pull/15022#issuecomment-2322917598 14:39 grorp2 tell me what approach you prefer 14:51 cx384 @Zughy the HUD element is only meant to describe how it should be displayed, like inventories in formspec. When #8297 gets resolved we will have more features in this regard. 14:51 ShadowBot https://github.com/minetest/minetest/issues/8297 -- Add support for combining multiple inventory lists into the hotbar 14:54 grorp2 I'll merge #15022 later today with approach 2. Really should just have been merged before #14321 :\ 14:54 ShadowBot https://github.com/minetest/minetest/issues/15022 -- Restore proportional minimap scaling by grorp 14:54 ShadowBot https://github.com/minetest/minetest/issues/14321 -- Add hotbar Lua HUD element and replace hardcoded hotbar by cx384 15:16 Krock you could push the main commit for proto ver 45 (overwrite), and a 2nd for back to 46. that way you might still get conflicts in cherry-pick but at least it won't be forgotte 15:16 Krock °n 15:20 [MatrxMT] that would be inconsistent: the master branch would have a commit with proto ver 45, but a server-side builtin hotbar. 15:21 [MatrxMT] to avoid it being forgotten, we can add a reminder issue to the 5.9.1 milestone 15:30 Krock or a general todo list for 5.9.1 15:35 cx384 Sorry that I already merged the PR, I thought that you have to adjust the commits for version 5.9.1 anyway and that reserving the protocol version would be enough, and nobody complained when I announced to merge it. 15:36 cx384 I was concerned that my PR would not get merged any time soon, since it is very old. Initially, I meant it to be merged for the same protocol version as the builtin minimap PR. 15:40 Krock mhm I didn't think far enough to place such reminder 15:45 [MatrxMT] There for feature requests: #15092 15:45 ShadowBot https://github.com/minetest/minetest/issues/15092 -- :sparkles: [Modders and game devs] What's the 3 features you need the most? 15:46 Krock please make a counterpart for "Which 3 features would you like to implement?" 15:47 Krock (provocative joke. not meant seriously) 15:54 grorp merging #15022 in 15 min 15:54 ShadowBot https://github.com/minetest/minetest/issues/15022 -- Restore proportional minimap scaling by grorp 15:55 sfan5 requesting reviews on #15009 and #14659 15:55 ShadowBot https://github.com/minetest/minetest/issues/15009 -- [no sq] Small network-related changes by sfan5 15:55 ShadowBot https://github.com/minetest/minetest/issues/14659 -- [no sq] Generic IPC mechanism between Lua envs by sfan5 15:57 Krock more lines removed than added. that's lovely. testing.... 16:06 sfan5 we should remove code more often, it's good 16:07 sfan5 I guess I need to merge it now or the comment about "August 2024" won't be true anymore 16:09 [MatrxMT] Krock: haha. I bought a C book last year and I always tell myself I'm gonna study it, but then life happens every time 16:45 Krock sfan5: "5.10.0-dev" might've been a better considering how long PRs might stall (for multiple reasons) 16:50 MTDiscord K&R, Zughy? 16:54 rubenwardy Wouldn't surprise me if zughy meant c++ 😅 16:54 Krock or with two + more it would be C# 16:54 rubenwardy I learned from a book called "Teach yourself C++ in 24 hours". Those were some long 24 hours... 17:03 cx384 Will minetest switch to C++20 any time soon? There are some features I would like to have e.g. std::span 17:05 Krock the further C++ develops, the more scared I am of all those new "fancy" notations that IMO make the code ugly and unreadable 17:05 ROllerozxa https://github.com/minetest/minetest/blob/master/doc/developing/os-compatibility.md#a-concrete-example 17:10 MTDiscord Krock: std::span ("pointer + len") is a pretty fundamental feature, not very fancy IMO. other systems programming languages such as rust or zig even have real language support with syntactic sugar and all (not just stdlib) for this. 17:11 Krock @luatic Interesting how this general concept wasn't used to implement string_view 17:11 MTDiscord IMO C++, like MT tbh 😅, has always suffered a bit from the "inverted pyramid" syndrome, where some "higher-level" features are available, but lower-level basics are not. 17:11 MTDiscord Krock: it should have been indeed. zig has no string view, you'd just use a slice ("span") of chars there. 17:14 v-rob > "btw, how's your enthusiasm for formspecs replacements at this time?" 17:14 v-rob Very good. I've been hacking away at my TODO list for the past few weeks. I also got a bunch of initial feedback from grorp on my PR, which is really nice. 17:18 red-001 spans are really nice to finally have, it's finally a sane way to represent arrays. I think the whole string_view without span thing happened because they couldn't agree on the standard for span? 17:19 red-001 string_view anyways is a bit special, being a string not just a generic data slice. 17:21 v-rob Arguably, std::string could be a std::vector, but std::string has a few special differences, like null terminators and extra methods. I imagine we would have gotten a std::string_view as a result in any case. 17:24 red-001 it being printable is a pretty big change too 17:28 Desour std::span and similar could be added with a polyfill 17:32 sfan5 ^ 17:32 sfan5 v-rob: honestly it's weird how they recognized that std::string_view is useful and didn't decide to add std::span in the same standards version 17:32 v-rob I totally agree 17:38 Desour btw. speaking of newer std lib features: having fmtlib would be cool. stream formatting is so cumbersome to type and read 17:39 Desour consider `warningstream << "bla " << var << std::endl;` vs. `print_warn("bla {}\n", var);` 17:47 Krock It might be more interesting to have a mechanism to skip all those function calls (that are written to /dev/null depending on the settings) to speed up code execution of critical parts, such as network debugging 17:56 Desour that's orthogonal. but it would probably also be easier to do with function call syntax than with overloaded << operator 18:05 sfan5 Krock: we have that 18:06 sfan5 https://github.com/minetest/minetest/blob/master/src/log.h#L244 18:08 Krock oh nice 18:09 Krock DummyStreamBuffer discards all inputs 18:14 sfan5 implemented by paradust7 2 years ago 18:19 sfan5 merging #15090, #15089, #15094, #15079, #15077, #15009 in 12m 18:19 ShadowBot https://github.com/minetest/minetest/issues/15090 -- TouchControls: Fix outdated player controls in TOSERVER_INTERACT by grorp 18:19 ShadowBot https://github.com/minetest/minetest/issues/15089 -- Basic unittest for HP change calculation by grorp 18:19 ShadowBot https://github.com/minetest/minetest/issues/15094 -- Fix uninitialized SkyboxParams::fog_color by grorp 18:19 ShadowBot https://github.com/minetest/minetest/issues/15079 -- [no-sq] Minor networking code cleanup by red-001 18:19 ShadowBot https://github.com/minetest/minetest/issues/15077 -- Disable CRT security warnings in MSVC. by red-001 18:19 ShadowBot https://github.com/minetest/minetest/issues/15009 -- [no sq] Small network-related changes by sfan5 18:20 [MatrxMT] @josiah_wi: ANSI C 18:43 [MatrxMT] sfan5 forgot? 18:44 sfan5 yes 18:52 Noisytoot Desour: why not just use printf? 18:53 sfan5 it has no flexibility to print c++ objects 18:53 Desour Noisytoot: printf requires you to specify the type you want to print, e.g. %d for integers. and ^ 18:55 MTDiscord printf is worse than both << and fmtlib. it lacks both in terms of safety (no real type safety, you're just passing a vararg on the stack and hoping you got the specifiers right, though to an extent linters can help with that) and performance (it basically has to parse the format string and interpret the vararg accordingly at runtime). 18:56 sfan5 given all the clutter streams have I wouldn't be surprised if printf is actually faster 18:58 Desour apparently stringstream is slower: https://fmt.dev/11.0/ , see # Performance 19:01 red-001 I wonder why they used that benchmark 19:06 Desour hm, minetest.net should probably also show some benchmark case where minetest is magnitudes faster than minecraft 19:06 Desour but right, sorry for linking a biased statistic 19:19 sfan5 any easy statistic would be lines of open source code 19:19 sfan5 some number for MT and put zero for MC 19:49 MTDiscord Tbh out of C++20 a feature I particularly like is the Coroutine support 19:50 MTDiscord I've been playing with it lately, and it makes some code a lot cleaner. Needs some boilerplate header(s), sure, but resuming a function from an entirely different place is very useful. 19:51 MTDiscord You can cleanly wait for whatever to happen and return to it when ready. 20:58 red-001 what are you using coroutines for? I'm quite used to using async-await in UI code, but not sure what else is well suited for it 21:05 MTDiscord somewhat random question: has anyone gotten something useful out of hotspot's disassembly view? it seems to lack information which perf annotate shows 21:12 sfan5 unrelated: apparently 10% of meshgen time is the constructor for ContentFeatures ?! 21:13 sfan5 what specifically are you missing? I see cycle values on some instructions 21:19 Desour sfan5: I haven't seen relevant ContentFeatures constructor calls in meshgen parts of flamegraphs 21:19 Desour but it might depend on the scene 21:20 Desour i.e. one drawtype accidentally copies content features 21:24 MTDiscord Stuff like animation and timing stuff. Potentially schedulers, even stuff like ABMs. Of course could be used for Lua async environments communication, network awaiting, mapgen... there are tons of possibilities, and the main benefit is cleaner syntax. 21:28 MTDiscord I managed to attach it to Godot's signal system (in case anyone is familiar with that) with an 80 loc header. Including a bunch of empty lines. And in case anyone wonders why Godot's c++ bindings don't use it yet if it's so simple, the answer is: because they're stuck on c++17 compatibility. I.e. you can use newer standards in your libraries and it will work, but they're not using newer stuff in their API. And apparently the only reason 21:28 MTDiscord they have for it is that some console toolchains haven't been updated beyond c++17. 21:33 MTDiscord Async-yield may be useful too, but I'm not sure how much really. It's mostly for generators (UUID?), I think I had some more uses for it, but don't remember now. Anyway it's theoretically cleaner for generators, because it does the job of storing the state for you. You just need to store the handle. 22:16 red-001 btw congrats sfan5 on 1000 commits to the main minetest repo 22:17 red-001 was just taking a look at the stats page 22:17 red-001 https://github.com/minetest/minetest/graphs/contributors