| Time |
Nick |
Message |
| 00:26 |
|
Soni joined #minetest-dev |
| 00:50 |
|
JCM joined #minetest-dev |
| 03:47 |
|
JCM joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:23 |
|
JCM joined #minetest-dev |
| 04:58 |
|
JCM joined #minetest-dev |
| 05:13 |
|
fluxionary joined #minetest-dev |
| 05:55 |
|
cranez joined #minetest-dev |
| 06:05 |
|
JCM joined #minetest-dev |
| 06:27 |
|
JCM joined #minetest-dev |
| 06:41 |
|
JCM joined #minetest-dev |
| 06:47 |
|
gnumoo joined #minetest-dev |
| 07:15 |
|
JCM joined #minetest-dev |
| 07:39 |
|
gnumoo_ joined #minetest-dev |
| 07:50 |
|
JCM joined #minetest-dev |
| 08:25 |
|
JCM joined #minetest-dev |
| 09:38 |
|
Noisytoot joined #minetest-dev |
| 09:48 |
|
gnumoo_ joined #minetest-dev |
| 10:07 |
|
Noisytoot joined #minetest-dev |
| 11:55 |
|
JCM joined #minetest-dev |
| 12:30 |
|
JCM joined #minetest-dev |
| 12:38 |
|
gnumoo_ joined #minetest-dev |
| 13:02 |
|
JCM joined #minetest-dev |
| 13:30 |
|
gnumoo_ joined #minetest-dev |
| 13:38 |
|
JCM joined #minetest-dev |
| 14:16 |
|
JCM joined #minetest-dev |
| 14:42 |
|
Noisytoot joined #minetest-dev |
| 15:17 |
|
gnumoo joined #minetest-dev |
| 15:47 |
|
stormchaser3000 joined #minetest-dev |
| 16:02 |
|
fluxionary joined #minetest-dev |
| 16:48 |
|
Noisytoot joined #minetest-dev |
| 17:12 |
|
Pexin joined #minetest-dev |
| 17:13 |
|
Noisytoot joined #minetest-dev |
| 17:44 |
|
JCM joined #minetest-dev |
| 18:19 |
|
JCM joined #minetest-dev |
| 18:20 |
|
libera-staff joined #minetest-dev |
| 18:54 |
|
JCM joined #minetest-dev |
| 18:56 |
MTDiscord |
<nrz0> sfan5, Krock i commited on #14793 regarding your changes. Cumulating all comments i think i found the best solution to have std::variant, c++ std::function and parserData use 🙂  Now we have a common proper interface for all in pure C++ and optional std::string,bool third arg |
| 18:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/14793 -- refacto: rework the GUI element handler function by nerzhul |
| 19:06 |
|
fluxionary_ joined #minetest-dev |
| 19:28 |
|
JCM joined #minetest-dev |
| 19:32 |
MTDiscord |
<exe_virus> What makes LBMs not 100% reliable? |
| 19:38 |
MTDiscord |
<warr1024> That's an interesting question, but probably the wrong one. Â What would cause them to be 100% reliable? Â Nothing else in MT is. Â While we use some components, like SQLite, that are designed to offer that kind of transactional reliability, not only are they not relevant here, but we generally defeat those reliability mechanisms in the interest of performance. |
| 19:38 |
MTDiscord |
<warr1024> You'd think that it should be possible to 100% reliably perform some action on load since, if something crashes before it completes, it would just run again next load anyway, but 🤷 the fact that we allow some leakage is at least consistent with our overall approach to reliability anyway. |
| 19:40 |
MTDiscord |
<warr1024> As for specific causes, somebody would probably have to investigate which is seriously annoying to do because (1) the problem is quite rare, happening some 0.001% of the time or something, and (2) it's hard to tell when something has loaded but LBMs have not run because the problem of detecting things that are loaded is basically the same as for setting up LBMs, so whatever we do has a problematic chance of failing exactly where LBMs |
| 19:40 |
MTDiscord |
fail. |
| 19:41 |
MTDiscord |
<warr1024> If you're looking for hypotheses, Â couple things to check would be race conditions between blocks becoming loaded/unloaded and LBMs actually being scheduled/ran, and resource use limitations, possibly intentional, like the way we abort ABM runs if they would exceed a time limit, or we delete entities or node timers if there are too many in any mapblock. |
| 20:00 |
sfan5 |
I don't think there's any reliability problem with LBMs |
| 20:03 |
|
JCM joined #minetest-dev |
| 20:07 |
MTDiscord |
<warr1024> https://cdn.discordapp.com/attachments/747163566800633906/1258514530342797454/iu.png?ex=6688527e&is=668700fe&hm=9b45ed470de0f1d3cfb4b54c3a8d10aea1a70e8a4a7df32e641ddb641a849fce& |
| 20:07 |
MTDiscord |
<warr1024> Maybe that's the real answer to ExeVirus' question 🤔 |
| 20:41 |
|
JCM joined #minetest-dev |
| 21:13 |
|
JCM joined #minetest-dev |
| 21:49 |
|
JCM joined #minetest-dev |
| 22:23 |
|
JCM joined #minetest-dev |
| 22:29 |
MTDiscord |
<exe_virus> Yep, could be the answer. The question is, how to test.... Â LBMs happen when a block is loaded, correct? Â So I could set a consistent distance, and teleport via script at the exact time blocks come unloaded... Then have an LBM that is just a counter, and ensure the counter is always some multiple of the expected count. If the count is not a multiple (i.e. less) then something was unreliable |
| 22:31 |
MTDiscord |
<exe_virus> And to test under heavy load is trivial, just spawn a 500 mob fight like I already am for the entity performance improvement testing |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:00 |
|
JCM joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:34 |
|
JCM joined #minetest-dev |
| 23:51 |
MTDiscord |
<warr1024> The problem is that I've never seen anyone identify the conditions that aggravate it, and it might not be just generic "heavy load", but specific situations like having a lot of mapgen running, or having a lot of external background load outside of MT, or disk latency vs CPU load, etc. |
