| Time |
Nick |
Message |
| 00:11 |
|
rubenwardy_ joined #minetest-dev |
| 00:23 |
|
Void7 joined #minetest-dev |
| 00:26 |
ssieb |
Fixer: After the inventory mesh change, my inventory pages are really fast. It used be slow like that. |
| 00:30 |
Fixer |
ShadowNinja, "jumping at node edge", what kind of bug was that? i don't remember |
| 00:31 |
ShadowNinja |
Fixer: Go up to the edge of a node (on an edge that drops off) and try to jump, the input is ignored. |
| 00:31 |
Fixer |
interesting |
| 00:31 |
ShadowNinja |
You have to get right up on the edge though. |
| 00:33 |
Fixer |
ShadowNinja, made 1 flying block, can jump right on the edge, stable 0.4.13 |
| 00:34 |
Fixer |
oh wait |
| 00:34 |
Fixer |
i see, ok |
| 00:34 |
Fixer |
reproduced |
| 01:39 |
|
fling joined #minetest-dev |
| 01:45 |
|
Miner_48er joined #minetest-dev |
| 03:42 |
|
celeron55 joined #minetest-dev |
| 03:53 |
|
Dragonop_ joined #minetest-dev |
| 04:03 |
|
werwerwer joined #minetest-dev |
| 04:07 |
|
pozzoni joined #minetest-dev |
| 05:11 |
Hijiri |
ShadowNinja: if you spam sneak button you can also get the walk sound to play over and over |
| 05:11 |
Hijiri |
when you are on the unjumpable edge |
| 06:18 |
|
Hunterz joined #minetest-dev |
| 07:48 |
|
est31 joined #minetest-dev |
| 08:44 |
|
technics joined #minetest-dev |
| 09:09 |
|
est31 joined #minetest-dev |
| 09:12 |
est31 |
I'll push this patch in one hour: https://github.com/minetest/minetest/issues/3863#issuecomment-197133987 |
| 09:14 |
|
nrzkt joined #minetest-dev |
| 09:49 |
|
linkedinyou joined #minetest-dev |
| 09:59 |
|
proller joined #minetest-dev |
| 10:15 |
|
srifqi joined #minetest-dev |
| 10:29 |
|
Calinou joined #minetest-dev |
| 10:34 |
|
proller joined #minetest-dev |
| 10:36 |
|
twoelk joined #minetest-dev |
| 10:40 |
|
Amaz joined #minetest-dev |
| 10:53 |
|
Megaf joined #minetest-dev |
| 11:05 |
|
Calinou joined #minetest-dev |
| 11:31 |
|
Player_2 joined #minetest-dev |
| 11:58 |
|
blaze joined #minetest-dev |
| 12:10 |
celeron55 |
client_mapblock_limit is dumb as hell |
| 12:10 |
celeron55 |
what is the server supposed to do when the client keeps deleting the blocks that it sends to it? |
| 12:11 |
celeron55 |
currently it just sends then again and again and the whole system just works 100% of the time against itself |
| 12:12 |
celeron55 |
them* |
| 12:12 |
celeron55 |
i now made it so that the client tells the server that value, and now i can't walk anywhere because the server refuses to send blocks to the client because it knows they would go over the limit |
| 12:13 |
celeron55 |
this is wasteful as fuck |
| 12:17 |
|
est31 joined #minetest-dev |
| 12:17 |
celeron55 |
well i know what i will do |
| 12:17 |
est31 |
celeron55, before it was a memory leak |
| 12:17 |
celeron55 |
but this is dumb anyway |
| 12:18 |
est31 |
you explored the map fast enough, you hit the memory limit of your CPU |
| 12:18 |
celeron55 |
i'm going to float up the value told to the server based on a new heuristic value collected by the mapblock draw list generation |
| 12:19 |
est31 |
you mean meshgen? |
| 12:19 |
celeron55 |
nope |
| 12:19 |
celeron55 |
soon nobody can understand how this works 8)) |
| 12:19 |
est31 |
xD |
| 12:20 |
celeron55 |
mapblock draw list generation is a thing that exist that is needed but which nobody knows nothing about except me |
| 12:20 |
celeron55 |
exists* |
| 12:20 |
est31 |
its part of farmap? |
| 12:20 |
celeron55 |
no |
| 12:20 |
est31 |
secret part of minetest lol |
| 12:21 |
celeron55 |
i'm improving it otherwise too now though |
| 12:22 |
est31 |
fine |
| 12:22 |
est31 |
i gotta go again |
| 12:23 |
est31 |
will push that change later this day |
| 12:23 |
est31 |
https://github.com/minetest/minetest/issues/3863#issuecomment-197133987 |
| 12:27 |
|
dfelinto joined #minetest-dev |
| 12:38 |
|
Fixer joined #minetest-dev |
| 13:05 |
|
nrzkt joined #minetest-dev |
| 13:13 |
|
Megaf joined #minetest-dev |
| 13:23 |
|
Megaf_ joined #minetest-dev |
| 13:25 |
dfelinto_vnc |
does anyone know how complicated would it be to have camera roll support in minetest? |
| 13:25 |
dfelinto_vnc |
it seems that part of the problem is that irrlicht itself is only using camera pitch and yaw (if I got it right) |
| 13:28 |
|
Darcidride joined #minetest-dev |
| 13:33 |
|
STHGOM joined #minetest-dev |
| 13:40 |
|
Darcidride joined #minetest-dev |
| 14:02 |
celeron55 |
so, the next problem is that 5000 is good enough for only a draw range of like 160 |
| 14:02 |
|
kaadmy joined #minetest-dev |
| 14:02 |
celeron55 |
5000 is the current default and there's no user-friendly way to change it, and no automation to change it |
| 14:03 |
VanessaE |
how much RAM would it cost if you, say, bumped it up to 25K/ |
| 14:03 |
VanessaE |
? |
| 14:03 |
celeron55 |
i don't think a static value like this makes any sense |
| 14:03 |
VanessaE |
hm |
| 14:04 |
VanessaE |
well remember the reason it had a static measure is OOM crashes before, as I recall |
| 14:04 |
VanessaE |
(I'm not opposed to just using however much it needs, though) |
| 14:04 |
celeron55 |
i think it chould be calculated from the user's draw range |
| 14:04 |
celeron55 |
and there could possibly be a setting to increase it beyond that |
| 14:05 |
celeron55 |
i guess it could be this exact setting |
| 14:05 |
celeron55 |
it should be just be automatically overridden to a higher value if that is needed for rendering how much the thing is set to render |
| 14:06 |
VanessaE |
problem is, you have to account for the user gallivanting around the map, so view range alone won't do, I think. |
| 14:06 |
VanessaE |
but I agree in principle. |
| 14:06 |
celeron55 |
of course it will do |
| 14:07 |
celeron55 |
what does that word even mean |
| 14:07 |
VanessaE |
? |
| 14:07 |
celeron55 |
if you mean like teleporting, then maybe a value of 2x what works for hanging around at a single-location |
| 14:08 |
VanessaE |
oh, nono. I mean running around like crazy, going all over the place (not even teleporting). pretty common in multiplayer servers |
| 14:08 |
dfelinto_vnc |
are you talking about culling? |
| 14:08 |
celeron55 |
that's the issue i am solving |
| 14:08 |
celeron55 |
not something i am breaking |
| 14:08 |
VanessaE |
ok. |
| 14:08 |
VanessaE |
I'll just leave it to you then |
| 14:09 |
dfelinto_vnc |
is there a quick place I can hack to bump it to 10x? |
| 14:09 |
* dfelinto_vnc |
wants to understand this part of the code better |
| 14:11 |
VanessaE |
client_mapblock_limit = xxxx |
| 14:11 |
VanessaE |
(if that still works; my engine is outdated) |
| 14:11 |
dfelinto_vnc |
thanks |
| 14:50 |
|
srifqi joined #minetest-dev |
| 15:05 |
|
hmmmm joined #minetest-dev |
| 15:13 |
|
DI3HARD139 joined #minetest-dev |
| 15:34 |
|
Darcidride joined #minetest-dev |
| 15:35 |
|
Samson1 joined #minetest-dev |
| 15:44 |
|
Amaz joined #minetest-dev |
| 16:01 |
|
Darcidride joined #minetest-dev |
| 16:02 |
|
Obani joined #minetest-dev |
| 16:05 |
nore |
sofar: btw, for the beds, I was able to put an attached node there using a mesecons piston |
| 16:05 |
nore |
but I would like to be able to attach nodes to the sides of the beds (like signs for example) |
| 16:05 |
* nore |
is still wondering on how to do it |
| 16:20 |
sofar |
nore: just like doors it's pretty much impossible unless we make some sort of API for it |
| 16:20 |
nore |
yeah :/ |
| 16:21 |
nore |
either we would need something like multinode support |
| 16:21 |
nore |
or horrible hacks |
| 16:33 |
VanessaE |
secondary_nodes_sides = {xp=true, yn=nil, zn=true, ...} |
| 16:33 |
VanessaE |
seems reasonable to me anyway |
| 16:34 |
VanessaE |
(xp = x positive, yn = y negative, etc) |
| 16:35 |
VanessaE |
seems to me that if a node is placed with one of those flags, there ought to be callbacks attached to those nodes, e.g. is_secondary = func(pos,dir) or some such |
| 16:36 |
VanessaE |
that way they're still distinct nodes. problem is you'd need the secondaries to have some sort of back-link to their "root" nodes for easier destruct |
| 16:37 |
|
Dragonop_ joined #minetest-dev |
| 16:37 |
VanessaE |
that last part would not work though for mods that have a common "placeholder" airlike node used to fill the space taken by the "root" node |
| 16:39 |
|
rubenwardy joined #minetest-dev |
| 16:40 |
VanessaE |
the only other way would be for the engine to treat collision box data (or the model itself) as an indicator that a node space is already filled |
| 16:40 |
VanessaE |
and that could be...complicated. |
| 16:42 |
|
enesbil joined #minetest-dev |
| 16:45 |
sofar |
I wouldn't necessarily implement it that way |
| 16:46 |
VanessaE |
it's just the first thing that came to mind |
| 16:46 |
sofar |
I was thinking of looking into something like an on_place_onto() callback that would return a modified pointed_thing |
| 16:47 |
VanessaE |
on place ONTO? |
| 16:47 |
sofar |
on_place_pointing() |
| 16:48 |
sofar |
that could then be called by builtin or core to receive a different pointed_thing.under and pointed_thing.above |
| 16:48 |
sofar |
and then the normal core code can resume |
| 16:49 |
sofar |
it would be a very minimal method. the callback would have to do some math though to properly determine where the player is looking |
| 16:54 |
nore |
sofar: that looks like a good idea |
| 16:54 |
sofar |
nore: and doable, too |
| 16:54 |
nore |
maybe the callback could pass the intersection of the player view with the collision box |
| 16:54 |
VanessaE |
for placing a node I guess that works |
| 16:54 |
nore |
that would avoid a lot of math |
| 16:54 |
VanessaE |
but what about destroying a node? |
| 16:55 |
VanessaE |
you can't even begin to rely on player yaw then |
| 16:56 |
sofar |
core.on_dig_node wouldn't call it |
| 16:56 |
sofar |
it wouldn't need to, anyway |
| 16:57 |
VanessaE |
well I'm talking about the case for beds when, for example, a piston or nodebreaker or even just a growing tree somehow destroys half. the engine should detect that and destroy (or drop) the other piece(s). |
| 16:59 |
|
Dragonop joined #minetest-dev |
| 16:59 |
sofar |
that part ... making the secondary node an "attached" node that drops nothing would already fix that |
| 16:59 |
sofar |
can't believe I've not thought of that before, either |
| 16:59 |
VanessaE |
how would that work? "attached" nodes only matter if they are hanging from the wall |
| 17:00 |
sofar |
hang bed tops off bed bottoms? |
| 17:00 |
VanessaE |
but they'd still be sitting on the ground |
| 17:00 |
sofar |
anyway, that issue I've fixed |
| 17:00 |
VanessaE |
I get where you're going though |
| 17:00 |
sofar |
PR pending, don't think it's merged tho |
| 17:04 |
sofar |
I don't think that PR will miss the release, it's too trivial |
| 17:04 |
sofar |
actually, that part is already in |
| 17:08 |
|
Dragonop joined #minetest-dev |
| 17:11 |
|
Krock joined #minetest-dev |
| 17:20 |
|
Dragonop joined #minetest-dev |
| 17:22 |
|
Hunterz joined #minetest-dev |
| 17:29 |
|
Void7 joined #minetest-dev |
| 17:40 |
|
Obani joined #minetest-dev |
| 18:30 |
Fixer |
https://github.com/minetest/minetest_game/issues/940 confirmed by other person |
| 18:34 |
everamzah |
#game941 |
| 18:35 |
everamzah |
game#914 ? |
| 18:35 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/914 -- Option to disable bone drops by tenplus1 |
| 18:35 |
everamzah |
heya! |
| 18:35 |
everamzah |
https://github.com/minetest/minetest_game/pull/941 *takes a walk* |
| 18:50 |
sofar |
thanks |
| 18:56 |
Fixer |
sofar, remember your "Allow digging of protected doors with "protection_bypass"" ? now i wonder if steel trapdoors are affected by this too, will test it later. |
| 18:56 |
sofar |
I checked the code, it's not |
| 18:56 |
sofar |
but, please test |
| 18:56 |
Fixer |
ok |
| 18:56 |
* sofar |
puts QA hat on Fixer |
| 19:02 |
|
Obani joined #minetest-dev |
| 19:08 |
|
Void7 joined #minetest-dev |
| 19:26 |
|
Void7 joined #minetest-dev |
| 19:30 |
|
Miner_48er joined #minetest-dev |
| 19:33 |
Fixer |
wooden sign is not diggable by mese axe? o_0 |
| 19:36 |
sofar |
it no longer is dig_immediate |
| 19:36 |
sofar |
try digging longer |
| 19:39 |
Fixer |
nope, it is a buuug |
| 19:40 |
Fixer |
damned, another two issues :/ |
| 19:40 |
Fixer |
steel one is fine though |
| 19:42 |
|
fling joined #minetest-dev |
| 19:52 |
Fixer |
sofar, wooden one is only diggable by axes |
| 19:53 |
sofar |
so it needs to become oddly_diggable_by_hand = 1 |
| 19:53 |
sofar |
can you try that? |
| 19:53 |
sofar |
I gotta run afk a bit |
| 19:53 |
Fixer |
don't work |
| 19:54 |
sofar |
oddly_breakable_by_hand = 1 in groups, sorry |
| 19:55 |
Fixer |
another bug about the bad :S |
| 19:56 |
Fixer |
sofar, steel trapdoors are ok btw |
| 19:57 |
|
Amaz joined #minetest-dev |
| 20:14 |
|
turtleman joined #minetest-dev |
| 20:14 |
|
hmmmmm joined #minetest-dev |
| 20:19 |
|
hmmmmmm joined #minetest-dev |
| 20:23 |
|
hmmmmm joined #minetest-dev |
| 20:25 |
|
Calinou joined #minetest-dev |
| 20:27 |
|
Void7 joined #minetest-dev |
| 20:41 |
|
Void7 joined #minetest-dev |
| 20:46 |
|
DFeniks joined #minetest-dev |
| 21:01 |
nore |
< VanessaE> well I'm talking about the case for beds when, for example, a piston or nodebreaker or even just a growing tree somehow destroys half. the engine should detect that and destroy (or drop) the other piece(s). <-- according to me, tree growing should call nodeupdate |
| 21:01 |
|
twoelk joined #minetest-dev |
| 21:01 |
nore |
so that falling nodes fall and attached nodes are dropped, if needed |
| 21:14 |
|
nrzkt joined #minetest-dev |
| 21:22 |
|
est31 joined #minetest-dev |
| 21:25 |
Fixer |
i see that obsidian is distractable by tnt now, is this correct behaviour? |
| 21:28 |
est31 |
using only a viewing range based check is dumb |
| 21:28 |
est31 |
you go to a place, you come back |
| 21:28 |
est31 |
but the server has to re-send the area because it got deleted because it was outside of the viewing range |
| 21:29 |
celeron55 |
how i did it now was that the setting which defaults to 5000 is used unless it's too low for the viewing range |
| 21:30 |
est31 |
it should be something like if (inside viewing range) { don't delete } else if (count limit exceeded) { delete } |
| 21:30 |
celeron55 |
so assuming 5000 was somehow chosen wisely, then it all is wise now |
| 21:30 |
est31 |
paramat chose it i think |
| 21:31 |
est31 |
how do you calculate the number of the blocks inside the viewing range? |
| 21:31 |
celeron55 |
basically just double it and cube it up |
| 21:31 |
celeron55 |
works fine |
| 21:31 |
est31 |
ah okay |
| 21:31 |
est31 |
yeah thats the maximum then |
| 21:32 |
Fixer |
celeron55, i do have memory problems with new farmap, if you talking about it |
| 21:32 |
celeron55 |
this isn't about farmap |
| 21:32 |
Fixer |
ok |
| 21:32 |
est31 |
celeron55, your key privs are needed: https://github.com/minetest/minetest/pull/3865 |
| 21:44 |
sofar |
celeron55: since I can't transfer to you directly, I've transferred it to your personal account, you can then transfer it to the minetest org |
| 21:44 |
sofar |
since I can't transfer to *minetest* directly... |
| 21:48 |
celeron55 |
i wonder when and where is it going to tell me about it |
| 21:50 |
sofar |
e-mail |
| 21:50 |
sofar |
and then you have to click the link |
| 21:50 |
|
Void7 joined #minetest-dev |
| 21:52 |
|
paramat joined #minetest-dev |
| 21:57 |
paramat |
celeron55 we jointly chose 5000 because that would use 2GB of memory |
| 21:58 |
|
Sockbat joined #minetest-dev |
| 21:59 |
|
dulrich joined #minetest-dev |
| 22:01 |
Fixer |
cpu usage is quite high with farmap, up to 80%, in default mt it is closer to 30-40%. |
| 22:10 |
est31 |
okay last chance to say no, will merge this fix in 10 mins: https://github.com/est31/minetest/commit/3132bcb3732df51c08c8b2f34781e463cd94fe7f |
| 22:10 |
paramat |
2GB seems a lot for 5000 blocks though, and 5000 is not much world |
| 22:10 |
est31 |
i have been announcing this for the whole day now :) |
| 22:10 |
paramat |
looks |
| 22:11 |
celeron55 |
whether 5000 blocks takes 2GB largely depends on what they contain |
| 22:11 |
est31 |
yeah |
| 22:11 |
celeron55 |
could be more like 100MB or less in another case |
| 22:13 |
paramat |
it was chosen for average mgv7 with it's massive forests |
| 22:13 |
est31 |
the limiting is not perfect, i originally wanted to use the real memory demands for each block |
| 22:13 |
Fixer |
massive forests are no go for 32 bit builds |
| 22:14 |
est31 |
but i didn't find a way to measure it |
| 22:14 |
celeron55 |
sofar: done |
| 22:14 |
paramat |
i noticed that limit wasn't acting on farmap, luckily. will farmeshes be limited or are they super-compact? i didn't notice much memory use even with a huge view |
| 22:15 |
Fixer |
paramat, try recent farmap, it just eats memory like crazy |
| 22:15 |
est31 |
the problem about farmap is the big texture cache. no? |
| 22:16 |
est31 |
well not problem |
| 22:16 |
paramat |
yes i'll be testing again |
| 22:16 |
est31 |
s/problem/memory demanding part/ |
| 22:16 |
est31 |
so store each texture in each brightness 4 times |
| 22:16 |
celeron55 |
est31: it actually really doesn't eat a lot of memory |
| 22:17 |
celeron55 |
back then it used much higher resolutions by default |
| 22:17 |
sofar |
celeron55: cool, thanks. |
| 22:18 |
celeron55 |
farmap's memory consumption mostly consists of the meshes on the client side |
| 22:18 |
est31 |
do the core devs have write permissions for the repo ? https://github.com/orgs/minetest/teams/team-minetest/repositories |
| 22:19 |
celeron55 |
just like mapblock memory consumption, in fact |
| 22:20 |
celeron55 |
est31: now they do |
| 22:20 |
est31 |
fine |
| 22:22 |
celeron55 |
i guess farmap needs some kind of thresholds for unloading stuff up to completely unloading stuff |
| 22:22 |
|
nrzkt joined #minetest-dev |
| 22:23 |
celeron55 |
it's not my priority now because i'm finding so many other issues in the PR after i started beating more speed out of it |
| 22:34 |
|
Void7 joined #minetest-dev |
| 22:45 |
paramat |
ShadowNinja some simple reviews for you game#932 game#935 game#941 game#931 |
| 22:45 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/932 -- Allow digging of protected doors with "protection_bypass" by sofar |
| 22:45 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/935 -- Walls: Don't connect to group:cracky by sofar |
| 22:45 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/941 -- Rename argument to priv check by everamzah |
| 22:45 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/931 -- Re-export character.b3d without texture linkage. by sofar |
| 22:53 |
|
est31 joined #minetest-dev |
| 23:04 |
paramat |
any approval for #3862 ? simple review |
| 23:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/3862 -- Mgv7: Limit pseudorandom caves to surface mapchunk or below by paramat |
| 23:39 |
Fixer |
paramat, "In stable 0.4.13 it was breakable by hands, wooden tools/swords (and stronger), except of hoes" |
| 23:39 |
paramat |
wooden sign? |
| 23:39 |
Fixer |
paramat, yes, wooden sign |
| 23:40 |
Fixer |
checked it few minutes ago in stable one |
