Time |
Nick |
Message |
00:15 |
|
lhofhansl joined #minetest-dev |
00:16 |
lhofhansl |
Does anybody know why EmergeManager::pushBlockEmergeData would be called with peer_request == PEER_ID_INEXISTENT and why in that case we would not enforce the disk/emerge queue limits? |
00:17 |
lhofhansl |
I found that when emergequeue_limit_total is increase (by 10) the scene loads *much* faster, and the main reason is PEER_ID_INEXISTENT can load more blocks. |
00:18 |
lhofhansl |
I suppose this is the server itself requesting nearby blocks? |
00:27 |
lhofhansl |
Also I'd like to get #10608 in. |
00:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/10608 -- Revert #10495 and simplify. by lhofhansl |
01:15 |
|
Taoki joined #minetest-dev |
04:39 |
|
lhofhansl joined #minetest-dev |
06:29 |
|
fluxflux joined #minetest-dev |
08:00 |
|
ShadowNinja joined #minetest-dev |
08:14 |
|
calcul0n joined #minetest-dev |
08:23 |
|
fluxflux joined #minetest-dev |
09:25 |
|
amk joined #minetest-dev |
10:07 |
|
Fixer joined #minetest-dev |
11:38 |
|
lisac joined #minetest-dev |
12:47 |
|
amk joined #minetest-dev |
13:23 |
zughy[m] |
So, I have mods crashing out of nowhere when they usually work as a charm, where the lowest common denominator are these packet quota warning messages. I know nothing about networking, but... isn't this a big problem? Server is on 5.3 |
13:23 |
zughy[m] |
https://gitlab.com/zughy-friends-minetest/magic-compass/uploads/e2616653ab9b38b322ef745bdc4fc4dd/image.png |
13:26 |
|
lisac joined #minetest-dev |
13:32 |
|
T4im joined #minetest-dev |
13:39 |
sfan5 |
that sounds unrelated, what does the code around that place do? what is ID? |
14:05 |
|
Icedream joined #minetest-dev |
14:07 |
zughy[m] |
Heh, there is no easy way to explain it. A number retrieved from the name of a button clicked inside a formspec. https://gitlab.com/zughy-friends-minetest/magic-compass/-/blob/master/player_manager.lua#L15 |
14:08 |
zughy[m] |
the only thing players can interact with are buttons, and every button contain a number in its name |
14:10 |
|
m42uko joined #minetest-dev |
14:14 |
zughy[m] |
I also have another crash happened on another mod where it didn't find the player (which is kind of impossible) and an user reporting a crash where instead of ID, it didn't find "item". All these crashes can't be replicated on a local server |
14:14 |
zughy[m] |
The user I'm talking about: https://gitlab.com/zughy-friends-minetest/magic-compass/-/merge_requests/1 |
14:24 |
sfan5 |
>string.match on the entire fields sent by a client |
14:24 |
sfan5 |
uhh |
14:24 |
sfan5 |
yeah I can't think of a less reliably way of doing that |
14:27 |
celeron55 |
that's amazing |
14:27 |
|
Hijiri joined #minetest-dev |
14:27 |
celeron55 |
local ID = string.match(dump(fields), "%d+") |
14:29 |
celeron55 |
what kind of thought process results in this |
14:33 |
|
YuGiOhJCJ joined #minetest-dev |
14:33 |
celeron55 |
it might be "error correcting" in way but it's also impossible to get useful log output or anything if a problem occurs |
14:33 |
zughy[m] |
lol, fine, I'll bait. The fact the formspec is configurable, so I don't know which slot is gonna contain an item, and (if it contains it) what item. Every item teleports to a certain location when clicked (linked to the ID), so I put the ID in the field name in order to retrieve it |
14:34 |
celeron55 |
and the MT API could change to include a number in some field and then it'll grab that instead of your field |
14:35 |
sfan5 |
chances are if you add extra debug output there you'll find that the ID it matches it not what you expected |
14:35 |
celeron55 |
format the field name to include an identifier with id, like magicbutton_1337 and then detect that field and parse the id from it |
14:35 |
sfan5 |
s/it/is/ |
14:36 |
celeron55 |
or something like that |
14:36 |
celeron55 |
this might not fix your original problem but at least it's easier to debug then |
14:38 |
celeron55 |
i'd say what happens currently is that the form gets closed in some way such that (fields.EMPTY or fields.quit) == false but there's no ID in any field |
14:38 |
celeron55 |
and then your item is nil |
14:38 |
celeron55 |
and you don't check that |
14:39 |
celeron55 |
of course you could just add that check and forget about it |
14:39 |
|
proller joined #minetest-dev |
14:39 |
celeron55 |
that would be in the spirit of the existing code |
16:15 |
|
lhofhansl joined #minetest-dev |
16:26 |
lhofhansl |
Re my question yesterday about peer with id PEER_ID_INEXISTENT asking for a lot of blocks, that is related to ABMs. Loading blocks needed for ABMs competes with the loading visible blocks. |
16:36 |
lhofhansl |
sfan5: are you ok with #10608? |
16:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/10608 -- Revert #10495 and simplify. by lhofhansl |
16:42 |
sfan5 |
yes |
16:43 |
lhofhansl |
Cool. Thanks! I'll merge within the hour. |
16:44 |
lhofhansl |
Still thinking about block loading for ABMs. And the nothing-to-send timer to make this more smooth especially with more players. |
17:08 |
lhofhansl |
Should requests for loading blocks on behalf of ABM be subject to disk and generate enqueue limits? (Currently they are not) |
18:15 |
|
Flitzpiepe joined #minetest-dev |
18:25 |
|
m42uko joined #minetest-dev |
19:26 |
|
fluxflux joined #minetest-dev |
20:15 |
|
skyliner_369 joined #minetest-dev |
20:30 |
|
LoneWolfHT joined #minetest-dev |
21:37 |
|
ssieb joined #minetest-dev |