| Time |
Nick |
Message |
| 00:34 |
|
Lone-Star joined #minetest-dev |
| 02:08 |
|
Tmanyo joined #minetest-dev |
| 02:12 |
|
turtleman joined #minetest-dev |
| 03:13 |
|
EvergreenTree joined #minetest-dev |
| 03:52 |
|
QwertyCool joined #minetest-dev |
| 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:00 |
|
torgdor joined #minetest-dev |
| 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. |
| 05:26 |
|
behalebabo joined #minetest-dev |
| 06:09 |
|
nerzhul joined #minetest-dev |
| 08:26 |
|
YuGiOhJCJ joined #minetest-dev |
| 08:40 |
|
Darcidride joined #minetest-dev |
| 08:45 |
|
Krock joined #minetest-dev |
| 09:58 |
|
Darcidride joined #minetest-dev |
| 09:59 |
|
Darcidride joined #minetest-dev |
| 10:03 |
|
Darcidride joined #minetest-dev |
| 11:30 |
|
nerzhul joined #minetest-dev |
| 11:46 |
|
Fixer joined #minetest-dev |
| 12:01 |
|
Lunatrius` joined #minetest-dev |
| 12:23 |
|
lisac joined #minetest-dev |
| 12:30 |
|
Krock joined #minetest-dev |
| 12:58 |
|
Darcidride joined #minetest-dev |
| 13:25 |
|
EvergreenTree joined #minetest-dev |
| 13:35 |
|
ThomasMonroe joined #minetest-dev |
| 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 |
| 14:23 |
|
antims joined #minetest-dev |
| 14:24 |
|
EvergreenTree joined #minetest-dev |
| 15:02 |
ThomasMonroe |
rubenwardy, sofar, any thoughts? |
| 15:35 |
|
juhdanad joined #minetest-dev |
| 15:44 |
|
BakerPrime joined #minetest-dev |
| 15:59 |
|
ThomasMonroe joined #minetest-dev |
| 16:00 |
|
ssieb joined #minetest-dev |
| 16:07 |
|
ThomasMonroe joined #minetest-dev |
| 16:14 |
|
EvergreenTree joined #minetest-dev |
| 17:05 |
|
ThomasMonroe joined #minetest-dev |
| 18:05 |
|
paramat joined #minetest-dev |
| 19:05 |
|
ThomasMonroe joined #minetest-dev |
| 19:30 |
|
ThomasMonroe joined #minetest-dev |
| 19:36 |
|
Gael-de-Sailly joined #minetest-dev |
| 19:37 |
|
Gael-de-Sailly joined #minetest-dev |
| 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 |
| 19:51 |
|
nerzhul joined #minetest-dev |
| 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 |
|
octacian joined #minetest-dev |
| 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:42 |
|
jin_xi joined #minetest-dev |
| 20:44 |
* sofar |
goes to judge cafeteria lunch offerings |
| 20:45 |
Shara |
:D |
| 20:50 |
|
ThomasMonroe joined #minetest-dev |
| 21:09 |
|
Darcidride_ joined #minetest-dev |
| 21:43 |
|
ThomasMonroe joined #minetest-dev |
| 21:53 |
|
jcalve joined #minetest-dev |
| 21:57 |
|
TMcSquared joined #minetest-dev |
| 22:01 |
|
Foz joined #minetest-dev |
| 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:25 |
|
ThomasMonroe joined #minetest-dev |
| 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:55 |
|
paramat joined #minetest-dev |
| 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:04 |
|
ThomasMonroe joined #minetest-dev |
| 23:08 |
|
nerzhul joined #minetest-dev |
| 23:27 |
|
Andrej11 joined #minetest-dev |
| 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:32 |
|
Tmanyo joined #minetest-dev |
| 23:44 |
Fixer |
found related issue https://github.com/minetest/minetest/issues/6886 |
