| Time |
Nick |
Message |
| 00:01 |
[MatrxMT] |
<AncientMariner> qualitative discussion can go before the voting |
| 00:01 |
[MatrxMT] |
<AncientMariner> 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 |
<corarona> ? |
| 00:01 |
red-001 |
in reference to the joke about windows |
| 00:01 |
MTDiscord |
<corarona> pro tip: you can mount a file as a partition |
| 00:02 |
MTDiscord |
<warr1024> 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 |
|
Pexin joined #minetest-dev |
| 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] |
<AncientMariner> 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 |
<warr1024> 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] |
<AncientMariner> oooh, i like your abm one |
| 00:03 |
MTDiscord |
<luatic> can we get this stuff noted and voted somewhere 😂 |
| 00:04 |
[MatrxMT] |
<AncientMariner> it's not like most don't start with abms and just abandon it for for death by globalstep |
| 00:04 |
MTDiscord |
<wsor4035> write a gist as a proposal, and submit it to c55, thats what typically happens |
| 00:04 |
MTDiscord |
<corarona> nah the generate decorations thing |
| 00:04 |
[MatrxMT] |
<AncientMariner> nothings been more abused than the global step |
| 00:04 |
MTDiscord |
<luatic> i'm a bit surprised frankly that the image caching one was that important for nodecore? |
| 00:04 |
MTDiscord |
<corarona> that needs to get back |
| 00:04 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<luatic> ah, i see |
| 00:05 |
MTDiscord |
<warr1024> To me, image GC is a bugfix, not a new feature, and I prioritize it accordingly. |
| 00:05 |
[MatrxMT] |
<AncientMariner> 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 |
<wsor4035> pretty sure that got improvements in 5.9, citation needed tho. might be misremembering |
| 00:06 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> 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 |
<warr1024> 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] |
<AncientMariner> well, let's see your list and you can convince the steering committee (self-appointed) |
| 00:07 |
[MatrxMT] |
<AncientMariner> everyone grab a wheel |
| 00:07 |
[MatrxMT] |
<AncientMariner> 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 |
<warr1024> 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 |
<wsor4035> 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] |
<AncientMariner> ah, ok |
| 00:09 |
[MatrxMT] |
<AncientMariner> is prioritised abms a concept that has been discussed? |
| 00:09 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> if a number get jettisoned after the allotted time, surely we can hint at what most we care about? |
| 00:10 |
MTDiscord |
<warr1024> 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 |
<warr1024> Right now though the ABM scheduler is TERRIBLE |
| 00:11 |
[MatrxMT] |
<AncientMariner> but the way it works, just pushes people to prioritise via globalstep |
| 00:12 |
[MatrxMT] |
<AncientMariner> your suggestion for delaying could work well with prioritisation |
| 00:12 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> Well, actually, I think I already filed an issue about this years ago. |
| 00:13 |
MTDiscord |
<warr1024> #14011 |
| 00:13 |
MTDiscord |
<wsor4035> 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 |
<warr1024> 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 |
<warr1024> 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 |
<wsor4035> its not actually breaking iirc |
| 00:15 |
MTDiscord |
<warr1024> I don't see how you could NOT break a ton of stuff by allowing coords outside of int16 |
| 00:15 |
MTDiscord |
<wsor4035> 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 |
<warr1024> 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 |
<corarona> tbh i have given up hope on that |
| 00:16 |
MTDiscord |
<corarona> it's somewhat breaking ... as in old clients can't go out of the old box |
| 00:17 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> 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] |
<AncientMariner> and mt-mods can do it later ;) |
| 00:17 |
MTDiscord |
<corarona> and yeah probably lots of "minor" stuff like that |
| 00:17 |
MTDiscord |
<warr1024> 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 |
<corarona> also many mods and games have 31000 hardcoded as limits |
| 00:18 |
MTDiscord |
<wsor4035> am mt-mods can do it later? what is this coming from? |
| 00:18 |
[MatrxMT] |
<AncientMariner> 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] |
<AncientMariner> it's not like you cannot get it from flatpak |
| 00:18 |
MTDiscord |
<warr1024> 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 |
<wsor4035> 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 |
<wsor4035> am: the issue is more with distros that love shipping old stuff, cough debian cough |
| 00:19 |
[MatrxMT] |
<AncientMariner> 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 |
<corarona> 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] |
<AncientMariner> mc had issues with caves and cliffs, but they made that decision and migrated towards it |
| 00:19 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> but fair point, and i don't really care about more than 32k myself lol |
| 00:20 |
[MatrxMT] |
<AncientMariner> life is too short to go to the edge of the world |
| 00:20 |
MTDiscord |
<corarona> 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 |
<wsor4035> if your doing planes or trains, the world is tiny |
| 00:21 |
MTDiscord |
<corarona> yeah |
| 00:21 |
[MatrxMT] |
<AncientMariner> vl also supports last 2, but if you're on debian sluggish, just flatpak it |
| 00:21 |
MTDiscord |
<corarona> calling it a world is a huge stretch too as i like to say it should be renamed "metropolitan area" |
| 00:21 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> but planes and trains are quite niche |
| 00:22 |
MTDiscord |
<warr1024> I really don't mind the world size. It works fine for the games I maintain. |
| 00:22 |
[MatrxMT] |
<AncientMariner> it's not like mapgen speed is great for fast speeds anyway |
| 00:22 |
MTDiscord |
<warr1024> 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 |
<wsor4035> 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 |
<warr1024> 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 |
<warr1024> 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 |
<wsor4035> make a doc with the concrete proposal and submit it to cdb |
| 00:24 |
MTDiscord |
<wsor4035> . s/cdb/celeron55 |
| 00:24 |
MTDiscord |
<wsor4035> my bad |
| 00:24 |
MTDiscord |
<warr1024> cdb55 |
| 00:24 |
red-001 |
poor c55 is a content db now |
| 00:25 |
MTDiscord |
<wsor4035> it doesnt help that im looking at cdb on my other monitor atm |
| 00:25 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> i don't mind who's on there as long as they're factoring in what others are raising |
| 00:26 |
[MatrxMT] |
<AncientMariner> i'd nominate warr if i had to pick |
| 00:27 |
[MatrxMT] |
<AncientMariner> but we may need a steering committee steering committee |
| 00:27 |
[MatrxMT] |
<AncientMariner> (maybe i'm joking, maybe i'm not ;)) |
| 00:27 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> good call |
| 00:27 |
[MatrxMT] |
<AncientMariner> maybe it's a few modders, a few game devs, a few server owners |
| 00:27 |
MTDiscord |
<wsor4035> more complex modpacks than games, but yeah |
| 00:27 |
[MatrxMT] |
<AncientMariner> and they can kind of lead those sub groups |
| 00:27 |
[MatrxMT] |
<AncientMariner> and pull it all together |
| 00:28 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> tenplus1? |
| 00:29 |
MTDiscord |
<warr1024> 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 |
|
SFENCE joined #minetest-dev |
| 00:29 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> at the risk of it being cliquey, maybe people in groups vote on who represents that group |
| 00:30 |
MTDiscord |
<warr1024> If there's some kind of structure to the community where that makes sense, that could work. |
| 00:30 |
[MatrxMT] |
<AncientMariner> if people put there name down, then if we have more than 2/3, vote on it |
| 00:30 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> if they ignore folk, people who just vote for others |
| 00:31 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> maybe every 3/4 months you pick reps |
| 00:32 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> but then mod stew folk may feel left out |
| 00:32 |
[MatrxMT] |
<AncientMariner> and this could be a problem |
| 00:33 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> I want to make sure this doesn't devolve into a popularity contest. |
| 00:35 |
[MatrxMT] |
<AncientMariner> true. i don't think many will volunteer, some it'll probably just be rubber stamping |
| 00:36 |
[MatrxMT] |
<AncientMariner> but it just gives an opportunity if folk aren't happy and want to have a go |
| 00:36 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> how many are going to run to do work? |
| 00:36 |
MTDiscord |
<corarona> 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] |
<AncientMariner> sorry, i was joking about the soup and stew thing as i remember your discussion on them :) |
| 00:37 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> i think that's a fair suggestion cora |
| 00:37 |
MTDiscord |
<corarona> well you could do the voting fairly asynchronously |
| 00:37 |
MTDiscord |
<corarona> the dev meeting thing ofc not so much |
| 00:38 |
[MatrxMT] |
<AncientMariner> maybe give 2 weeks to put your name forward, and if more than 3, poll it |
| 00:38 |
MTDiscord |
<corarona> but thats the beauty of it if you dont have time this time you just say that |
| 00:39 |
[MatrxMT] |
<AncientMariner> 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 |
<corarona> and ofc if the rep doesn't rep they wont get voted for again |
| 00:40 |
[MatrxMT] |
<AncientMariner> i thin most would just be happy to feel their feedback could go into shaping priorities in mt |
| 00:40 |
MTDiscord |
<warr1024> I guess, though in a way I'm not sure if that's part of the manifest purpose of the group. |
| 00:40 |
MTDiscord |
<warr1024> Like, it's not for airing grievances or something |
| 00:41 |
MTDiscord |
<warr1024> 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] |
<AncientMariner> i'm not sure anyone mentioned airing grievances? |
| 00:42 |
MTDiscord |
<warr1024> 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. |
| 01:08 |
|
SFENCE joined #minetest-dev |
| 01:55 |
|
SFENCE joined #minetest-dev |
| 02:00 |
|
fluxionary joined #minetest-dev |
| 02:07 |
|
v-rob joined #minetest-dev |
| 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. |
| 02:29 |
|
SFENCE joined #minetest-dev |
| 02:30 |
|
v-rob joined #minetest-dev |
| 02:37 |
|
SFENCE joined #minetest-dev |
| 02:55 |
|
SFENCE joined #minetest-dev |
| 03:13 |
|
SFENCE joined #minetest-dev |
| 03:30 |
|
SFENCE joined #minetest-dev |
| 03:54 |
|
SFENCE joined #minetest-dev |
| 03:58 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:01 |
|
v-rob joined #minetest-dev |
| 04:03 |
|
SFENCE joined #minetest-dev |
| 04:52 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:15 |
|
SFENCE joined #minetest-dev |
| 06:21 |
|
SFENCE joined #minetest-dev |
| 06:26 |
|
v-rob joined #minetest-dev |
| 08:56 |
[MatrxMT] |
<Zughy> In short: |
| 08:56 |
[MatrxMT] |
<Zughy> - 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] |
<Zughy> - every core dev has a vision of their own, the issue is having a shared vision |
| 08:56 |
[MatrxMT] |
<Zughy> - 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] |
<Zughy> - 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] |
<Zughy> (There are also other things I haven't addressed) |
| 09:06 |
[MatrxMT] |
<Zughy> Also note that 14004 is how we got most of the "High priority" labels |
| 09:08 |
[MatrxMT] |
<Zughy> 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:15 |
|
cx384 joined #minetest-dev |
| 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:08 |
|
SFENCE joined #minetest-dev |
| 10:20 |
|
SFENCE joined #minetest-dev |
| 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] |
<AncientMariner> <v-rob> I may be an outlier, but I do that all the time. |
| 11:22 |
[MatrxMT] |
<AncientMariner> i guess you've got a level of stoicism and patience that many aren't capable of :) |
| 11:23 |
[MatrxMT] |
<AncientMariner> btw, how's your enthusiasm for formspecs replacements at this time? |
| 11:25 |
[MatrxMT] |
<AncientMariner> 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] |
<AncientMariner> 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] |
<AncientMariner> 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] |
<AncientMariner> 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] |
<AncientMariner> true |
| 11:30 |
[MatrxMT] |
<AncientMariner> 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] |
<AncientMariner> i guess 2 years is a long time to forget prs and where mt was 2 years ago |
| 11:32 |
[MatrxMT] |
<AncientMariner> (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] |
<AncientMariner> and i guess many may not always understand the less visible stuff. it may not get the credit it justifies |
| 11:38 |
[MatrxMT] |
<AncientMariner> 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] |
<AncientMariner> and openness |
| 11:39 |
Krock |
!next |
| 11:39 |
ShadowBot |
Another satisfied customer. Next! |
| 11:40 |
|
SFENCE joined #minetest-dev |
| 11:47 |
sfan5 |
@Zughy I don't disagree in principle but I would not like to take on another responsibility |
| 12:26 |
|
hwpplayer1 joined #minetest-dev |
| 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 |
<marinerdev> 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 |
<marinerdev> most open source games are found through word of mouth |
| 12:40 |
[MatrxMT] |
<Zughy> I'm on GH just for Minetest and rubenwardy is using it for the same reason |
| 12:40 |
MTDiscord |
<marinerdev> 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 |
<marinerdev> i'm on github to auth across to mesehub |
| 12:41 |
[MatrxMT] |
<Zughy> @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 |
<marinerdev> i think there is also the option of gitlab, or ideally codeberg |
| 12:42 |
[MatrxMT] |
<Zughy> cx384 https://gitlab.com/zughy-friends-minetest/arena_lib/-/issues/334 |
| 12:42 |
[MatrxMT] |
<Zughy> Maybe I've misunderstood |
| 12:42 |
MTDiscord |
<marinerdev> both have a reasonable chance of people having accounts or not having reservations. codeberg is the daddy of open source now |
| 12:43 |
MTDiscord |
<marinerdev> 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] |
<Zughy> 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] |
<Zughy> 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 |
<rudzik8> 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] |
<Zughy> 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 |
<marinerdev> 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] |
<Zughy> Also Codeberg devs were always nice with us, also at FOSDEM |
| 12:49 |
[MatrxMT] |
<Zughy> *have always been nice |
| 12:49 |
MTDiscord |
<marinerdev> 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 |
<marinerdev> 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 |
<marinerdev> a "sorry, my bad" after 6-24 months will not undo the damage of that |
| 12:50 |
MTDiscord |
<marinerdev> see play store for more details |
| 12:51 |
[MatrxMT] |
<Zughy> @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] |
<Zughy> Still an if :P |
| 12:54 |
cx384 |
And no you are not forced to do it, you will just get a deprecation warning ... |
| 12:55 |
|
SFENCE joined #minetest-dev |
| 13:05 |
|
SFENCE joined #minetest-dev |
| 13:09 |
[MatrxMT] |
<Zughy> 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:21 |
|
Desour joined #minetest-dev |
| 13:22 |
MTDiscord |
<marinerdev> 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 |
<marinerdev> to understand the use case and the need of it |
| 13:26 |
[MatrxMT] |
<Zughy> 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 |
| 13:56 |
|
behalebabo joined #minetest-dev |
| 14:05 |
cx384 |
*merged* |
| 14:16 |
[MatrxMT] |
<Zughy> @cx384 so calls like set_hotbar<something> are just diverted towards the builtin? |
| 14:17 |
[MatrxMT] |
<Zughy> *set_hotbar_foo |
| 14:22 |
|
vampirefrog joined #minetest-dev |
| 14:23 |
|
grorp2 joined #minetest-dev |
| 14:23 |
|
SFENCE joined #minetest-dev |
| 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 |
| 14:54 |
|
grorp2 left #minetest-dev |
| 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] |
<grorp> that would be inconsistent: the master branch would have a commit with proto ver 45, but a server-side builtin hotbar. |
| 15:21 |
[MatrxMT] |
<grorp> 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:38 |
|
red-001 joined #minetest-dev |
| 15:40 |
Krock |
mhm I didn't think far enough to place such reminder |
| 15:45 |
[MatrxMT] |
<Zughy> 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:48 |
|
grorp joined #minetest-dev |
| 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] |
<Zughy> 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 |
<josiah_wi> 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:04 |
|
v-rob joined #minetest-dev |
| 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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:20 |
|
SFENCE joined #minetest-dev |
| 17:21 |
v-rob |
Arguably, std::string could be a std::vector<char>, 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:02 |
|
grorp left #minetest-dev |
| 18:05 |
sfan5 |
Krock: we have that |
| 18:06 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/log.h#L244 |
| 18:06 |
|
SFENCE joined #minetest-dev |
| 18:08 |
Krock |
oh nice |
| 18:09 |
Krock |
DummyStreamBuffer discards all inputs |
| 18:14 |
sfan5 |
implemented by paradust7 2 years ago |
| 18:17 |
|
SFENCE joined #minetest-dev |
| 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] |
<Zughy> @josiah_wi: ANSI C |
| 18:43 |
[MatrxMT] |
<Zughy> sfan5 forgot? |
| 18:44 |
sfan5 |
yes |
| 18:44 |
|
SFENCE joined #minetest-dev |
| 18:51 |
|
SFENCE joined #minetest-dev |
| 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 |
<luatic> 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:32 |
|
Sokomine joined #minetest-dev |
| 19:42 |
|
Desour joined #minetest-dev |
| 19:49 |
MTDiscord |
<herowl> Tbh out of C++20 a feature I particularly like is the Coroutine support |
| 19:50 |
MTDiscord |
<herowl> 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 |
<herowl> You can cleanly wait for whatever to happen and return to it when ready. |
| 20:14 |
|
v-rob joined #minetest-dev |
| 20:17 |
|
SFENCE joined #minetest-dev |
| 20:37 |
|
SFENCE joined #minetest-dev |
| 20:53 |
|
v-rob joined #minetest-dev |
| 20:55 |
|
SFENCE joined #minetest-dev |
| 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 |
<luatic> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> 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. |
| 21:51 |
|
SFENCE joined #minetest-dev |
| 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 |
| 22:18 |
|
SFENCE joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:36 |
|
Lupercus joined #minetest-dev |
| 22:54 |
|
SFENCE joined #minetest-dev |
| 23:04 |
|
SFENCE joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:22 |
|
SFENCE joined #minetest-dev |
| 23:40 |
|
SFENCE joined #minetest-dev |
