| Time |
Nick |
Message |
| 00:36 |
|
proller joined #minetest-dev |
| 00:45 |
|
YuGiOhJCJ joined #minetest-dev |
| 00:47 |
|
fluxionary joined #minetest-dev |
| 02:59 |
|
diceLibrarian joined #minetest-dev |
| 03:02 |
|
vampirefrog joined #minetest-dev |
| 03:04 |
|
luk3yx joined #minetest-dev |
| 03:44 |
|
fluxionary joined #minetest-dev |
| 03:51 |
|
Krock joined #minetest-dev |
| 03:59 |
|
celeron55 joined #minetest-dev |
| 03:59 |
|
wsor joined #minetest-dev |
| 03:59 |
|
behalebabo joined #minetest-dev |
| 03:59 |
|
Calinou joined #minetest-dev |
| 03:59 |
|
BuckarooBanzai joined #minetest-dev |
| 03:59 |
|
jojje joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:02 |
|
cheapie joined #minetest-dev |
| 04:03 |
|
asdflkj_sh joined #minetest-dev |
| 04:09 |
|
linksword[m] joined #minetest-dev |
| 04:09 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:17 |
|
LandarVargan[m] joined #minetest-dev |
| 04:19 |
|
schwarzwald[m] joined #minetest-dev |
| 04:20 |
|
programmerjake joined #minetest-dev |
| 04:34 |
|
ivanbu joined #minetest-dev |
| 04:34 |
|
bigfoot547 joined #minetest-dev |
| 04:42 |
|
izzyb joined #minetest-dev |
| 05:08 |
|
luk3yx joined #minetest-dev |
| 06:09 |
|
jojje joined #minetest-dev |
| 06:27 |
|
calcul0n joined #minetest-dev |
| 07:12 |
|
luk3yx joined #minetest-dev |
| 08:05 |
|
x2048 joined #minetest-dev |
| 08:13 |
|
cranezhou joined #minetest-dev |
| 09:02 |
|
x2048 joined #minetest-dev |
| 09:15 |
|
luk3yx joined #minetest-dev |
| 09:22 |
|
Warr10248 joined #minetest-dev |
| 09:34 |
|
eahm joined #minetest-dev |
| 10:04 |
|
Warr1024 joined #minetest-dev |
| 10:43 |
|
Fixer joined #minetest-dev |
| 10:56 |
|
proller joined #minetest-dev |
| 13:14 |
|
appguru joined #minetest-dev |
| 14:50 |
|
calcul0n_ joined #minetest-dev |
| 15:05 |
|
kilbith joined #minetest-dev |
| 15:12 |
sfan5 |
I'll try to look at them in the next days |
| 15:19 |
|
calcul0n joined #minetest-dev |
| 15:44 |
nrz |
do you have an example or too long reload ? i never saw such case ? i read the PR but i'm not sure about how client will behave for retrocompat old clients with your ideas (which sounds nice on paper) |
| 17:13 |
|
Fixer_ joined #minetest-dev |
| 17:21 |
|
calcul0n_ joined #minetest-dev |
| 18:00 |
|
jwmhjwmh joined #minetest-dev |
| 18:05 |
jwmhjwmh |
Is there a meeting here now? |
| 18:29 |
sfan5 |
no idea |
| 18:29 |
sfan5 |
we should probably decide on the new roadmap goals soon |
| 18:29 |
sfan5 |
that's been open for a while |
| 19:03 |
Krock |
sorry. I do not have much time today. perhaps someone else could start a meeting it that's wanted |
| 19:14 |
|
diceLibrarian joined #minetest-dev |
| 19:18 |
|
jwmhjwmh joined #minetest-dev |
| 19:31 |
|
lhofhansl joined #minetest-dev |
| 19:36 |
lhofhansl |
nrz: Active blocks are only checked every active_block_mgmt_interval seconds (default 2). If the block is not loaded, yet, it will be scheduled to, in which case there might be another 2s before it is actually activated. Active objects stored in the block are activated when the block is activated. Normally that is fine, but if a player just joined and was attached to an entity, that attachment can take multiple seconds to happen. |
| 19:37 |
lhofhansl |
You can observe that with any nearby entity/mobs. Takes a few seconds for them to show up. |
| 19:38 |
lhofhansl |
The two fixes are: 12925: Reduce active_block_mgmt_interval upon join and pretty quickly go back to normal. Or 12927 pass a flag along to emerge to immediately activate a block when it is loaded. |
| 19:40 |
lhofhansl |
12925 is a bit more organic (i.e. works with the existing mechanism, no extra paths, still does things in bulk, etc), whereas 12927 is perhaps more correct in that a block is immediately activated (well actually only its objects) upon load, at the expense of more machinery and more work on the emerge thread(s). |
| 19:41 |
|
appguru joined #minetest-dev |
| 19:42 |
nrz |
I think second is better, as the first one can increase load on the server more than expected |
| 19:42 |
nrz |
i didn't know that we don't emerge the block where player loads directly, we clearly should load this one and the ones around him |
| 19:45 |
lhofhansl |
Yep. At least the immediate blocks around the player. That's what 12927 does (together with sfan's earlier change to check for active blocks immediately). 12927 also does more work, it re-checks *all* active blocks immediately... But probably less than 12925. |
| 19:45 |
lhofhansl |
(Ideally would limit that the newly joined player(s), but that would need even more machinery) |
| 19:46 |
lhofhansl |
I guess I also prefer 12927 |
| 20:10 |
nrz |
why all ? we should check only those close to the current loading player no ? |
| 20:10 |
nrz |
i prefer the 12927 in terms of solution too |
| 20:23 |
lhofhansl |
nrz: active blocks are check per server, for all players. sfan's earlier change short circuits that and has the server immediately re-check when a player joins. |
| 20:30 |
|
proller joined #minetest-dev |
| 20:41 |
|
jwmhjwmh joined #minetest-dev |
| 20:48 |
|
Fixer joined #minetest-dev |
| 21:42 |
|
proller joined #minetest-dev |
| 21:54 |
proller |
sfan5, maybe its time to add 32bit worls coords to roadmap? |
| 22:32 |
|
proller joined #minetest-dev |
| 22:36 |
MTDiscord |
<savilli> You mean roadmap: needs approval? |
| 22:39 |
|
cranezhou joined #minetest-dev |
| 23:34 |
|
panwolfram joined #minetest-dev |
