| Time |
Nick |
Message |
| 00:16 |
|
T4im joined #minetest-dev |
| 00:41 |
|
kilbith joined #minetest-dev |
| 00:57 |
lisac |
#10240 is ready for review :S |
| 00:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/10240 -- Return to main menu if shaders fail to compile, and display an error message. by lisacvuk |
| 01:06 |
|
Taoki joined #minetest-dev |
| 02:06 |
hecks |
what's the biggest known minetest world size in GB? |
| 02:08 |
hecks |
a rough calculation gives me about 100 GB for a world's whole explored surface, 40 mapblocks thick, with some margin |
| 04:31 |
MTDiscord |
<exe_virus> I should not be a core dev, but I should start helping review PR's that's something I think I can do. |
| 04:33 |
MTDiscord |
<exe_virus> Also, kilbith, minetest is a game that comes and goes for most people. We get excited, do a lot of work, get bored/burnt out. and revolve back. I would expect the same from core devs. Only the spurts get longer and longer as MT develops for me haha |
| 04:55 |
|
Seirdy joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:13 |
|
jonadab joined #minetest-dev |
| 07:25 |
|
m42uko joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 09:01 |
|
absurb joined #minetest-dev |
| 09:28 |
|
calcul0n joined #minetest-dev |
| 10:53 |
|
proller joined #minetest-dev |
| 11:20 |
|
Fixer joined #minetest-dev |
| 11:49 |
|
calcul0n_ joined #minetest-dev |
| 12:38 |
|
pmp-p joined #minetest-dev |
| 12:46 |
MTDiscord |
<Apelta> Fair idea, more people reviewing PRs will help the core devs decide whether a change (especially larger ones) are stable and wanted by the community |
| 12:47 |
MTDiscord |
<Apelta> I encourage more people do it if they have time to kill lol, just write a useful review that outlines any problems you may have encountered as a direct result of the change or modification if you notice any |
| 12:57 |
rubenwardy |
I did reviews long before I became a core dev |
| 12:57 |
rubenwardy |
https://forum.minetest.net/viewtopic.php?t=19877 |
| 13:03 |
|
proller joined #minetest-dev |
| 13:48 |
|
Wuzzy joined #minetest-dev |
| 15:07 |
|
Taoki[mobile] joined #minetest-dev |
| 15:15 |
|
lisac joined #minetest-dev |
| 15:20 |
Wuzzy |
@sfan: Why is there an action/change needed for #10690? |
| 15:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/10690 -- Fix misleading chat messages of /clearobjects by Wuzzy2 |
| 15:20 |
Wuzzy |
@sfan5 ↑ |
| 15:20 |
sfan5 |
I thought that was obvious from the discussion in #minetest |
| 15:21 |
Wuzzy |
<celeron55> well if you want to clean up a map for sharing |
| 15:21 |
sfan5 |
for example it clears all objects, but your change removes that from the description |
| 15:21 |
Wuzzy |
oh right... |
| 15:21 |
Wuzzy |
yeah, it technically does remove all objects, even if just time-deleay |
| 15:50 |
Wuzzy |
ok i force-pushed to #10690 now |
| 15:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/10690 -- Fix misleading chat messages of /clearobjects by Wuzzy2 |
| 17:02 |
|
lhofhansl joined #minetest-dev |
| 17:37 |
|
m42uko joined #minetest-dev |
| 17:56 |
|
mizux joined #minetest-dev |
| 18:22 |
|
proller joined #minetest-dev |
| 18:31 |
|
fluxflux joined #minetest-dev |
| 19:02 |
|
homthack joined #minetest-dev |
| 19:51 |
|
fluxflux joined #minetest-dev |
| 20:02 |
|
fluxflux joined #minetest-dev |
| 20:05 |
rubenwardy |
It would be interesting to have Minetest report crashes to mod authors on ContentDB. The error dialog could include a report button when the mod name is detected and was installed from ContentDB, which sends the error message and a list of enabled mods. Although, attributing fault can be painful |
| 20:05 |
rubenwardy |
in any case, supporting dependency installation is more important |
| 20:06 |
Krock |
but only if the mod is up to date |
| 20:07 |
rubenwardy |
it can send the contentdb release number |
| 20:07 |
rubenwardy |
and ContentDB would ignore if it's not the latest |
| 20:07 |
specing |
rubenwardy: you could host a redmine/bugzilla/etc instance and have the client automatically use its API to submit errors |
| 20:09 |
specing |
SpringRTS has something half-assed: https://logs.springrts.com/ that lobby client[s] use to auto-report issues |
| 20:10 |
rubenwardy |
nice |
| 20:10 |
specing |
(half-assed because I'm not sure if there is any nice frontend to help developers) |
| 20:13 |
specing |
I remember look into autoreporting briefly, and I couldn't find any system for preprocessing bug reports - removing duplicates, marking how many clients had this issue (with a graph over a time period), correlating bug reports to client-submitted identifiers (OS, version, hardware vendors...)... |
| 20:33 |
|
proller joined #minetest-dev |
| 20:39 |
Krock |
avoiding the 1000th open issue: #10692 |
| 20:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/10692 -- Various documentation fixes by SmallJoker |
| 20:40 |
lhofhansl |
Maybe we should all do a sweep through all open issues and close them as appropriate. |
| 20:40 |
lhofhansl |
Or close any issue older than 1 year. |
| 20:40 |
lhofhansl |
The oldest open issue is from 2011! |
| 20:41 |
MTDiscord |
<Jonathon> i plan to open a PR to close my issue soon (just one of two) |
| 20:48 |
Krock |
you could mark unpopular feature requests as [Possible close] |
| 20:48 |
Krock |
which are then closed after the next iteration |
| 20:54 |
specing |
lhofhansl: reminder that closing issues like that discourages further contributions |
| 20:56 |
lhofhansl |
I think an issue that has been lingering for a year does not encourage contributions either. |
| 20:56 |
lhofhansl |
or for 9 years :) |
| 20:58 |
rubenwardy |
Wuzzy, Calinou, fancy looking through issues? |
| 20:59 |
Wuzzy |
hi |
| 20:59 |
Wuzzy |
i am currently making another attempt in translating builtin. so no (for today) |
| 20:59 |
Wuzzy |
currently testing ... |
| 20:59 |
specing |
lhofhansl: regardless, if someone invested their time opening it, then they deserve a good response (other than "closed after 1 year of inactivity") |
| 21:01 |
lhofhansl |
I do not feel strongly. Most open source project automatically close old issues. Clearly nobody will pick up an issue now that is multiple years old, nor will the person who opened care after that time. |
| 21:07 |
Wuzzy |
it is very frustrating tho if a PR dies due to ignorance |
| 21:09 |
Wuzzy |
i am also against the idea of "closing old issues". issue age is not a justification. an ancient issue might still be relevant, for example, if its a crasher. bugs dont disappear just because you ignore them. ? |
| 21:10 |
Wuzzy |
a better justification is for example when there's too little information, hard to reproduce, obscure, its not clear if the claimed bug exists at all |
| 21:12 |
Wuzzy |
i really, really hate bots that auto-close old issues. i have seen stupid bots close relevant, proven, well-documented but unfixed bug reports more than was healthy ... |
| 21:23 |
|
twoelk joined #minetest-dev |
| 21:32 |
twoelk |
maybe work in small steps from the oldest onwards in organized events? only closing the obvious, searching for the easiest to address, just to get the number down |
| 21:46 |
MTDiscord |
<appguru> rubenwardy: PLEASE |
| 21:46 |
MTDiscord |
<appguru> getting users to properly file bugs can be quite a hassle |
| 21:47 |
rubenwardy |
auto reports in Android is nice for finding out how well your mod performs |
| 22:36 |
Wuzzy |
My 2nd attempt of translating builtin is now ready for review: #10693 |
| 22:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/10693 -- Builtin translate (2nd attempt) by Wuzzy2 |
| 22:44 |
sfan5 |
wasn't there a fundamental problem last time? |
| 23:04 |
|
T4im joined #minetest-dev |
| 23:28 |
|
hecks joined #minetest-dev |
| 23:30 |
hecks |
Any netcode gurus around? I need help debugging a "zombie" client state |
| 23:31 |
sfan5 |
hi |
| 23:31 |
hecks |
hi =] |
| 23:31 |
MTDiscord |
<oneplustwo> is it the thing where you die but can't respawn? |
| 23:31 |
hecks |
so I got this server and a lousy connection to it... say, roughly 200 ping |
| 23:32 |
sfan5 |
minetest doesn't cope well with packet loss if you're about to say that too |
| 23:32 |
hecks |
after a while, certain kinds of packets start... piling up? I don't know what's happening to them |
| 23:33 |
hecks |
let's say that the part of the game that checks a selected item (client to server) and toggles hud (server to client) still works |
| 23:33 |
hecks |
but the part that detects input and sets animation, attaches, detaches, moves - this one goes to hell |
| 23:33 |
hecks |
pretty much until relogged |
| 23:34 |
hecks |
I've seen it replay things I've done minutes before, and it never catches up |
| 23:34 |
sfan5 |
yeah that's possible |
| 23:34 |
hecks |
so is there anything special about those kinds of packets in particular? |
| 23:34 |
hecks |
like does it rigidly enforce a certain queue for them and doesn't ever purge it |
| 23:35 |
hecks |
because this sort of behavior might not be necessary for most of them |
| 23:35 |
sfan5 |
some packets (this doesn't apply to movement) are guaranteed to deliver and only delivered in-order |
| 23:36 |
sfan5 |
can't say what those are in your case without seeing them |
| 23:36 |
hecks |
maybe not movement, but perhaps attachment and animations |
| 23:36 |
hecks |
do they at least get separate queues? |
| 23:36 |
sfan5 |
"they"? |
| 23:37 |
hecks |
one kind of guaranteed packet and another |
| 23:37 |
hecks |
or is there just one guaranteed queue and it's getting clogged? |
| 23:37 |
sfan5 |
there's three channels and what the games does it somewhat distributed to them |
| 23:37 |
sfan5 |
(with a fixed mapping) |
| 23:38 |
hecks |
and where can I check which opcode is bound to which one? |
| 23:38 |
hecks |
I'm starting to get why this is happening, maybe more channels are needed |
| 23:39 |
sfan5 |
you can't just throw more channels at the problem, some packets need to be ordered relative to eachother |
| 23:39 |
sfan5 |
rather the netcode needs to cope with packet loss better |
| 23:39 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/network/serveropcodes.cpp#L124 |
| 23:39 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/network/clientopcodes.cpp#L140 |
| 23:39 |
hecks |
well I think that loosening up animation somehow might eliminate most of the problem |
| 23:39 |
hecks |
because in reality, only the last issued animation range should matter |
| 23:40 |
hecks |
and previous, lost packets can be safely dropped |
| 23:40 |
sfan5 |
true |
| 23:41 |
sfan5 |
but that currently doesn't exist |
| 23:42 |
hecks |
oh, hud is a separate channel, that would explain its magical resistance to gremlins |
| 23:43 |
hecks |
and the trailing boolean is reliable, gotcha |
| 23:43 |
lhofhansl |
Did some tests this the zlib settings. The only change with an effect is the compression level. If I change it to 3 from the default of 6 (picked 3, because that is the highest compression level that uses deflate_fast internally), compression is 3x faster and the database is 34% larger. |
| 23:44 |
hecks |
lhofhansl: would turning off compression make map saves less painful? |
| 23:44 |
lhofhansl |
Generating a large new scene went from taking 120s to 80s (because the emerge threads are blocked during safe. |
| 23:44 |
sfan5 |
of course |
| 23:44 |
lhofhansl |
Yes. But turning it off is not a good option. |
| 23:44 |
lhofhansl |
we might want to make 3 the default, or at least make it configurable. |
| 23:44 |
hecks |
well I have a pretty big hard drive to spare, I might do this as a workaround |
| 23:45 |
sfan5 |
you really don't want to disable it outright |
| 23:45 |
lhofhansl |
I can test 3 again 0 and see what it does. |
| 23:45 |
sfan5 |
any time saved you'll pay back tenfold due to limited IO bandwidth |
| 23:45 |
lhofhansl |
or 6 against 0, rather |
| 23:45 |
sfan5 |
lhofhansl: don't think the default should be changed, settings makes more sense to accomodate save-heavy usecases |
| 23:46 |
sfan5 |
a setting* |
| 23:46 |
hecks |
what if this could be autodetected? |
| 23:46 |
lhofhansl |
going by what indicators? |
| 23:46 |
lhofhansl |
(autodetection is better obviously) |
| 23:46 |
hecks |
bench some r/w on all 9 levels in the world's directory |
| 23:47 |
hecks |
pick the minimum |
| 23:47 |
hecks |
I'd much rather wait an extra half a second while starting a world than fiddle with the setting manually and have to tune it for every new hard drive |
| 23:47 |
lhofhansl |
end-to-end write performance improved 3x from level 6 to 3. That is the time the server "hangs" when exiting. |
| 23:48 |
sfan5 |
so if you have an SSD the engine will automatically waste lots of disk space because it's fast |
| 23:48 |
hecks |
maybe the setting can be a minimum then |
| 23:48 |
lhofhansl |
30-40% is not the end of the world. No compression would 10x, that'd be bad. |
| 23:48 |
sfan5 |
really the "saving blocks takes too long" has never come up before so it should neither be autodetected nor should the default be changed |
| 23:49 |
lhofhansl |
It's starting because I am testing with large viewing_ranges... 500 and more. There's a whole new set of bottlenecks. This is one. |
| 23:49 |
sfan5 |
does making background saves more frequent help? |
| 23:49 |
lhofhansl |
It has always bugged me that you cannot set the viewing_range to 1000. :) |
| 23:50 |
lhofhansl |
It does not help in aggregate (just to state the obvious). So yeah, it helps with server hangs since it spreads them out more. |
| 23:50 |
lhofhansl |
I also now always have my MAP_BLOCKSIZE set to 32. |
| 23:51 |
sfan5 |
maybe logic could be added to "speed up" autosaving if the server detects its never gonna catch up at the current rate |
| 23:52 |
lhofhansl |
yeah, but that complicated to get right. We simply picked zlibs default speed/compression trade-off. I'm suggesting that for MT it's not the right trade-off. |
| 23:52 |
hecks |
an extra 30% world size is acceptable if it means doing something about the dreadful map save |
| 23:53 |
hecks |
it's not just horrible on exit, map saves are capable of just stalling the whole game |
| 23:53 |
sfan5 |
how do you know 6 wasn't picked intentionally? (I don't know either) |
| 23:53 |
lhofhansl |
map save and map generation and active objects, etc (since that's blocking during save) |
| 23:53 |
lhofhansl |
sfan5: Fair enough. :) I was assuming, since we use -1, which let's zlib pick its default, which is 6. |
| 23:54 |
sfan5 |
yeah it *is* the default but I don't know if anyone has looked at changing it before |
| 23:55 |
lhofhansl |
Now I looked at it :) |
| 23:56 |
hecks |
regarding saving blocks never being a problem before: minetest_game didn't show it as much |
| 23:56 |
hecks |
mtg has enough supporting client features to hide the lag, but the lag was always there |
| 23:57 |
hecks |
the more you rely on the server step being responsive, the worse the map lock feels |
| 23:57 |
lhofhansl |
Best would be to change the DB schema anyway - as I suggested in a github issue. No need to save the blob of mapnodes when only the block's TS changed. |
| 23:57 |
hecks |
as for frequent saves: I tried that, and while it never got bad enough to throw a fit, it still resulted in uncomfortable spikes |
| 23:58 |
lhofhansl |
and - for that matter - why do we need to persist the timestamp anyway? |
| 23:58 |
hecks |
saving every 10 or 5 seconds would be a viable strategy if the saving process was just a bit leaner |
| 23:59 |
sfan5 |
timestamps are used for clearobjects and probably nodetimers too |
