Time Nick Message 03:52 QwertyCool hey folks. 03:53 QwertyCool Inquired last night about contributing to the dev team, but it was pretty late. if anyones around, give me a shout, or mayve let me know what a good time to reach out would be. 04:03 sofar QwertyCool: any time is as good as anything 04:04 sofar QwertyCool: mind you, this hour it's not many folks around due to time zone 04:04 sofar QwertyCool: however, I'll be around for a while if you want to chat 04:23 QwertyCool Hey sure that'd be great! should we take it private or just here 04:24 QwertyCool @sofar 04:32 QwertyCool sorry i missed you, give me a slap when you're here again 04:33 ssieb QwertyCool: what exactly are you wanting to do? 04:34 QwertyCool I'd love to contribute somehow with c++ 04:34 QwertyCool I haven't investigated to much by myself yet, I wanted to ask before I invested time in the wrong place. 04:35 ssieb You're always welcome to contribute. Pick something you want to change or fix and make a pull request. 04:35 ssieb If it's a larger change, you might want to check here first to make sure it's likely to be accepted before you do a lot of work. 04:36 QwertyCool Most of my experience coding is in python to be 100% honest - I'm working my way through C++ primer and I'm hoping to be done by end of FEB 04:36 ssieb For most of my personal coding I like to use Python. 04:37 QwertyCool Gotcha, I thought that was pretty much the gist. I know this is probably a direct no, but since I'm new I'd be honored to have a mentor or someone to communicate with while i work, give me directon on things and help me improve over time. 04:38 QwertyCool super dope that u you use python too! 04:38 ssieb You can certainly ask here for help. 04:39 QwertyCool Awesome. Could you reccomend a smaller fix or upgrade that you think would be a good starting project that no one else is already working on? 04:42 ssieb sorry, no idea. You can look through the issues on github to see if you can find something interesting. 04:52 QwertyCool good idea yeah. 04:52 QwertyCool how long have you been programming for? 04:53 ssieb around 30 years 04:56 QwertyCool mind = blown 04:56 QwertyCool ]wow dude thats amazing 04:56 QwertyCool seriously that's so cool 04:58 QwertyCool What projects have you most enjoyed working on? 05:00 ssieb I don't know. I dabble in a lot of things... 05:06 QwertyCool is there a way to see a todolist or something (or is that just the open issues) 05:08 ssieb Pretty much just the open issues. 05:10 ssieb The main minetest repo is mostly C++ coding for the core system. There's also the minetest_game repo which is the base game content which is mostly lua coding. 05:11 ssieb mods are lua. 13:39 ThomasMonroe sfan5, any thoughts on #6969? 13:39 ShadowBot https://github.com/minetest/minetest/issues/6969 -- F3 enable/disable fog info not accurate 15:02 ThomasMonroe rubenwardy, sofar, any thoughts? 19:47 juhdanad I have an idea how to allow more uses of param2 without needing to increase the size of MapNode. 19:48 juhdanad So there could be colorfacedir nodes with full 256 color palettes. 19:49 paramat interesting 19:49 juhdanad I created a forum topic, and I'm interested in what do you think: https://forum.minetest.net/viewtopic.php?f=7&t=19549 19:50 paramat game#2016 excellent optimisation and improvement for our most intensive ABM, please review 19:50 ShadowBot https://github.com/minetest/minetest_game/issues/2016 -- Flower spread ABM: Optimise by paramat 19:50 paramat next time i merge PRs i'll merge game#2030 19:50 ShadowBot https://github.com/minetest/minetest_game/issues/2030 -- Intersects_protection(): Remove from Minetest Game by paramat 20:01 paramat wow. theoretically clever but a radical change with performance loss, change of world format, lots of code rewrite. not worth it i feel 20:02 paramat modders just have to accept and work within limits 20:03 paramat also of course, this is the last thing we need with our severe lack of dev time, unnecessary fancy features is what we need to avoid 20:04 juhdanad Yes, this is why I posted it on the forum, then it has a chance to be requested by as many modders/users as required to merge the changes. 20:04 paramat more than ever now we need to concentrate on simplicity, after losing so many devs 20:04 sofar everyone who wants to contribute can focus on anything they want 20:05 paramat i don't care how many modders or players request it :) 20:05 juhdanad sofar: I agree. If you code what you would like, your progress is faster. 20:06 paramat but yes, you are free to experiment if you want, but i will probably be strongly opposed 20:07 sofar please, stop that attitude 20:07 sofar that's the BEST way to kill motivated contributors 20:08 paramat the need really isn't there, hardware colouring is a special feature not meant for all nodes, the limitation due to splitting param2 is a minor issue and just has to be accepted 20:08 sofar stop it 20:09 sofar you're being judgemental 20:09 paramat it's ok to have an opinion 20:09 sofar either people do the work and find it out for themselves, or they do the work and it's fantastic, or they don't do the work 20:09 sofar it's not ok to be repulsive 20:10 paramat i'm not being repulsive, that's in your head, i am calm and thoughtful on this 20:10 sofar your first reaction was to state your opposal 20:11 juhdanad Well, I don't feel myself repulsed. Paramat judged the hardware coloring PR too, and in the end it resulted in better overall colors. 20:11 paramat just rational and realistic, calm down. and juhdanad i'm sorry for disagreeing, i think it's clever and appreciate your thoughts 20:11 sofar oh, NOW you say that 20:12 paramat it's ok to judge things, that's what devs do 20:12 sofar no, it's not ok 20:12 sofar you're not the judge 20:12 sofar you're a peer 20:12 sofar we're all peers 20:12 sofar you could express concern in carefully worded phrases, or ask critical questions 20:12 paramat clever, but unfortunately not practical 20:13 sofar read your first 3 sentences on the topic again 20:13 sofar clearly you're judging 20:14 paramat i'm not overruling anyone and making a final judgement. sofar you're being irrational 20:14 sofar "this is the last thing we need" 20:14 paramat yes, it's my opinon 20:14 paramat opinion 20:14 sofar you're being repulsive, my opinion 20:15 sofar and it's detrimental to attracting new developers 20:15 paramat nothing wrong with judging, devs judge ideas and PRs 20:15 sofar there's no code yet, there is nothing to judge 20:15 paramat we discuss and judge ideas often before code has been written 20:15 sofar discuss, sure, judge? no, we don't, and we shouldn't 20:16 sofar if someone really writes up all the code for some terrible idea, it's their perogative 20:16 sofar then we judge whether to *merge* the change, or not 20:16 sofar but, heck, if they want that code so badly, we shouldn't prevent them from experimenting and doing the work 20:16 paramat yes we judge, that's our job 20:17 sofar well, then, in my opinion you shouldn't be here 20:17 paramat i'm not preventing anything 20:17 sofar this is a community project where we should foster development and experimentation 20:17 sofar and you're doing the opposite 20:17 paramat you're acting strange 20:17 pgimeno_ sorry for getting in the middle, but I have something to say 20:18 pgimeno_ as someone who may want a certain feature, I'm interested in whether it will be accepted or not 20:18 pgimeno_ if it won't be accepted, I better not even try 20:18 sofar opinions about whether something is mergable can change over time 20:19 pgimeno_ from that point of view, paramat was helpful in some sense, though I'd of course prefer to see the general opinion, not just his 20:19 sofar lots of really great ideas ("we'll merge it!") often don't work out ("this isn't the right way") in the end 20:19 octacian pgimeno_ makes a good point. However, as sofar has stated development and experimentation should be encouraged. And opinions can change. Plus, if a feature is completely turned down it can always be kept in a fork. 20:20 juhdanad In fact I would like to do this for the joy of coding. This is an interesting problem to solve. 20:22 octacian huh. Now I'm interested. I have no clue what ya'll are talking about, just saw the last 20 messages or so. 20:22 octacian Someone care to enlighten me? 20:22 juhdanad Octacian: https://forum.minetest.net/viewtopic.php?f=7&t=19549 20:22 octacian Thanks. 20:23 octacian Ah, saw that earlier but didn't have time to read it. 20:23 octacian Been pretty inactive in MT lately, so not very aware of most things that are going on. 20:23 pgimeno_ For me, it's much worse to be turned down after taking the work to implement something, than before. If I know that something isn't worth doing, that's helpful and I can focus on something else. I hate when it ends up being a wasted effort. 20:24 sofar pgimeno_: that's a reasonable concern, but it's up to you to either accept or ignore it 20:25 sofar I'd rather see lots of experiments that produce working code that don't get merged, than no experiments at all 20:25 sofar the latter will just result in stagnating development 20:25 sofar the former is the recipe to a lively growth of the project 20:25 paramat i agree 20:26 sofar take for instance, the idea to make MT map coords larger than 16^3 20:26 sofar I'd sure as hell would run a fork that implemented that 20:27 sofar I'm sure dozens of people would like to see what it takes 20:27 sofar yet, it'll never happen because it's been killed already dozens of times 20:27 sofar https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_with_the_bathwater 20:29 pgimeno_ all I say is that an advance opinion is valuable, like with my LuaJIT PR, which indeed met some opposition which, by the way, is well reasoned. 20:29 paramat no one's stopping you, it's just that many devs have serious concerns about it, rightly 20:30 paramat (re: larger co-ords) 20:30 sofar there's a big difference between concerns and outright rejection 20:30 paramat i can't reject anything, on my own i have zero power 20:30 sofar you've already rejected it with your wording 20:31 sofar "the last thing we need" 20:31 paramat ok, personally, yes 20:32 paramat we all do it when we feel strongly about something, you have certainly :} 20:32 paramat which is ok 20:32 sofar well if I have, then I was wrong 20:32 sofar no, it's not 20:33 sofar rejecting code, sure 20:33 sofar you'll have a hard time finding PR reviews for me where I'm extrenely negative about PRs that are functionally complete 20:33 sofar s/from me/ 20:34 sofar but imho everything juhdanad has proposed so far has value 20:36 sofar and if his ideas are getting this amount of criticism within 10 minutes, what does that say to interested new developers? 20:37 sofar if I ever did the same, please, slap me in the face with it 20:37 * Shara slaps sofar 20:37 sofar I feel something, but I don't know what it is 20:37 Shara You made me feel like dirt that wasn't welcome here when I started making PRs :) 20:37 sofar :P 20:37 sofar ouch 20:38 sofar yeah, that's disgusting 20:38 sofar repulsive attitude 20:38 sofar guilty, probably 20:38 sofar no time as good as now to attempt to rectify that 20:38 Shara Yup, which makes it all good with me. 20:39 Shara But paramat has made others feel welcome in turn, so there's some balance then. 20:39 Shara Every single one of us has things to learn 20:40 nerzhul i just read the conversation, but sorry to say that, i'm fine with sofar 20:44 * sofar goes to judge cafeteria lunch offerings 20:45 Shara :D 22:18 nore concerning >2^16-wide maps: I have to say, I would greatly like it -- but last time I tried, 4 years ago or so, it was a sad failure, because after changes to several thousand lines, I still had segfaults :'( 22:18 nore still, freeminer merged these changes and they didn't have problems with them -- so I figure it should still be possible 22:26 sofar I wonder if you could get efficient packing if we'd use a 64bit value for position and use 24bits for x and z and 16 for y 22:27 sofar 16777km2 with 64km elevation 22:27 Krock RIP multiple realms 22:27 nore well that can be done, but some way to have configurability would be better 22:28 Krock or the idea of multiple worlds inside one map 22:28 nore hmmm 22:28 nore if we do this, do the multiple-realms part at the same time 22:28 nore both are quite extensive change to positions 22:28 Krock ..and thus, map breakage 22:29 nore let's do that change once instead of twice :) 22:29 nore well 22:29 nore map version is stored 22:29 nore but, map storage protocol bump 22:29 Krock and soon enough the discussion of other compression algorithms starts :< 22:30 nerzhul please use zstd for map compression instead of gzip 22:30 nerzhul :D 22:30 Krock sofar, that idea sounds very good but first we need to find a solution for the float network code 22:30 nerzhul Krock, agreed 22:30 sofar Krock: right 22:30 nerzhul your idea was quite good Krock many protocols can do it, why we don't ? 22:30 sofar tbh positions can be anything, it's just more efficient to pack it smart 22:31 Krock nerzhul, I don't have the testing equipment and none bothers 22:31 nore ah yes float need change as well 22:31 sofar you could do 32bits * 3 for position and 32 bits for param1/2 22:31 nore they are limited to +-200k for the position, IIRC 22:31 sofar that would be just fine for most network packets as well 22:31 nerzhul sofar, s32 or f32 ? 22:31 Krock I've thought of simply passing the floats into a fast sqrt function and then pow them again at the end. not too precise or fast but portable :3 22:32 nore hmmmm if we move to 32bits for param1&2, means we could have coloured lights 22:32 Krock instead of messing around with bitops and re-building our own float format 22:32 nerzhul param1 and param2 are part of MapNode structure right ? 22:32 Krock nore, juhdanad had a great suggestion here: https://forum.minetest.net/viewtopic.php?f=7&t=19549 22:32 sofar they are 22:32 nerzhul if it is all the code should be changed to use references instead of copy as mapnode can be trivially copied now 22:32 nerzhul but it will not be after that 22:32 sofar 16 bits content type, 16 bits param1/2 22:33 sofar could go to 64bit mapnode 22:33 nore yeah, I saw that 22:33 nore if it is done, I guess it should be done with the other mapnode changes if possible 22:34 Krock 64bit mapnodes and X/Z then Y compression may result in a quite acceptable ratio 22:34 nerzhul do you really want to break map now ? can we release 0.5 at a point ? :p 22:34 Krock nothing stops us from breaking it after 0.5.0 again 22:34 Krock >:D 22:34 nore exactly :3 22:35 nore let's make 0.6.0 the next release after 0.5.0 :p 22:35 Krock where it = the protocol, followed by map breakage 22:35 nerzhul we can, it breaks our old compat model but if it's needed... 22:35 Krock players will hate it, however 22:35 nerzhul for protocol we are near the solution but the windows crash anoy me 22:35 Krock nerzhul, asio troubles? 22:36 nore Krock: if we have backwards compatibility for importing old maps, I guess it will be no problem 22:36 nerzhul Krock, i don't know i think it can be the problem yes 22:36 sofar reading a smaller data type into a larger one seems like a small risk 22:37 nore I'm wondering how should the position be made 96 bits if we want to integrate a 4th dimension 22:38 nore (for different "realms"/whatever) 22:38 sofar then I'd make position 3x32bits and 32bits for "realm" 22:38 sofar but tbh I'd rather see a separate server thread for each realm 22:39 red-001 ^ 22:39 sofar or even separate process 22:39 nore hmmmm 22:39 sofar loading screen or not 22:39 red-001 I would prefer if we implemented server to server travel 22:39 red-001 and made realms just a front-end to that 22:39 nerzhul merging #6964 22:39 ShadowBot https://github.com/minetest/minetest/issues/6964 -- Make chat command + privilege help slightly more accurate by Wuzzy2 22:39 nore would make it harder to have a global lua state though 22:39 nerzhul sofar, server thread is sufficient, no need for fork 22:40 sofar players are already almost sharable between servers 22:40 sofar with some locking it would be safe, too 22:40 ThomasMonroe ^ 22:40 red-001 plus then we can have seperate mods for every "realm" 22:40 nore actually, if we have a 32*3 bits position, would be quite safe to go to 32*4 regarding alignment 22:40 nerzhul guys can i get the approvals on #6958 ? all points are solved 22:40 ShadowBot https://github.com/minetest/minetest/issues/6958 -- Add minetest.bulk_set_node call + optimize Environment::set_node call by nerzhul 22:41 red-001 sofar, how hard would it be to change the network protocol so multiple servers can listen on the same port? 22:41 nerzhul red-001, not related to network 22:41 nerzhul just have a realm id in session if you are on the same binary 22:42 Krock 24 bits X, 24 bits Z, 16 bits Z -> 64 bits, works for me. If realms, then sending them to another server/port directly might be an easier choice 22:42 nerzhul and change on which server thread we push the packet 22:42 nerzhul Krock, the problem is the inventory sync 22:42 nerzhul who own the inventory ? 22:42 Krock ah right 22:42 nerzhul souce server ? dest server? 22:42 nerzhul what about incompat inventories (armors etc...) it's not simple 22:44 Krock nerzhul, if you target on speed, then you could read the table index and place the node instantly instead of loading them into the vector. 22:45 nerzhul Krock, it's a bulk add_node, not a LVM or VM :) 22:45 Krock plus looping it through again. the side effect will be already placed nodes if there's one malformatted entry in the list 22:46 nerzhul if i can read mapnode before the vector isn't needed 22:46 nerzhul i should test it 22:49 nerzhul Krock, okay it works, but difference in terms of performance is not changed :) 22:50 nerzhul i pushed the change 22:55 Krock uh well, I hoped that it would make it a little faster 22:56 nerzhul it seems no, in release mode compiler seems to optimize that part 22:56 nerzhul 16s set_node vs 12s bulk_set_node, like previously, ~25% 22:58 sofar bummer, that's not a lot 23:00 Krock well yeah - slow callbacks 23:00 nerzhul yeah it's callbacks, and depend on the callback complexity, but 25% on standard MTG is quite nice to have :) 23:01 sofar ah so all the on_construct() stuff gets called with that? 23:02 nerzhul it's like set_node, but the deserialization is optimized, we have a position list and only one mapnode deserialize 23:03 nerzhul and it permits to do random nodes editions in bulk mode, unlike other VM and LVM which works on a specific area 23:29 nerzhul merging #6958, ty Krock 23:29 ShadowBot https://github.com/minetest/minetest/issues/6958 -- Add minetest.bulk_set_node call + optimize Environment::set_node call by nerzhul 23:30 Krock np & gn 23:31 Fixer observation: "when I walk and jump diagonally across blocks, it seems it shifts me to the side" (cross-posted here) 23:44 Fixer found related issue https://github.com/minetest/minetest/issues/6886