Minetest logo

IRC log for #minetest-dev, 2019-11-14

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:29 Lone_Wolf joined #minetest-dev
01:23 NoctisLabs joined #minetest-dev
01:48 Miner_48er joined #minetest-dev
01:55 tuedel joined #minetest-dev
02:00 tuedel joined #minetest-dev
03:20 Ruslan1 joined #minetest-dev
03:27 Wuzzy joined #minetest-dev
03:36 questionguy joined #minetest-dev
03:48 Foz joined #minetest-dev
03:50 questionguy left #minetest-dev
04:07 NoctisLabs joined #minetest-dev
05:49 fluxflux joined #minetest-dev
06:56 ensonic joined #minetest-dev
08:38 ShadowNinja joined #minetest-dev
08:53 NobleTechie left #minetest-dev
08:54 NobleTechie joined #minetest-dev
09:25 ensonic joined #minetest-dev
09:52 ssieb joined #minetest-dev
10:34 proller joined #minetest-dev
10:53 Fixer joined #minetest-dev
11:18 proller joined #minetest-dev
11:30 tomraceror joined #minetest-dev
12:06 kilbith joined #minetest-dev
12:19 proller joined #minetest-dev
12:32 Fixer joined #minetest-dev
12:53 proller joined #minetest-dev
12:53 Foz joined #minetest-dev
12:53 pyrollo joined #minetest-dev
12:53 p_gimeno joined #minetest-dev
12:53 Edgy1 joined #minetest-dev
12:53 Hijiri joined #minetest-dev
12:57 tomraceror joined #minetest-dev
13:03 Fixer_ joined #minetest-dev
13:11 proller joined #minetest-dev
13:32 Fixer joined #minetest-dev
14:09 CrazyDave joined #minetest-dev
14:44 tomraceror joined #minetest-dev
15:42 Ruslan1 joined #minetest-dev
15:44 Lunatrius joined #minetest-dev
16:13 AkRa_ joined #minetest-dev
16:21 Lone_Wolf joined #minetest-dev
16:36 Wuzzy joined #minetest-dev
17:25 Krock joined #minetest-dev
17:34 ssieb joined #minetest-dev
17:36 ensonic joined #minetest-dev
17:43 fluxflux joined #minetest-dev
18:08 Krock Not a blocking receive IIRC, but the server only processes very few data per step
18:41 kilbith joined #minetest-dev
19:06 Krock sfan5: any chance to make use of std::chrono in semaphore.cpp? That time calculation looks awful and attractive for bugs
19:07 sfan5 not really since you need it in a struct timespec in the end
19:11 Krock I just hope that time calculation is correct
19:14 Krock okay. looks correct
19:16 sfan5 merging #9115 in a few minutes
19:16 ShadowBot https://github.com/minetest/minetest/issues/9115 -- Optimize semaphore wait with zero timeout on POSIX by sfan5
19:17 Krock > Note that this function can potentially wait infinitely
19:18 Krock Does it? Semaphore in "m_signal.wait" (container.h) should actually prevent that
19:18 sfan5 it does continue on certain events
19:19 Krock right. added and removed peers
19:20 Krock No, that's not a problem for now
19:26 Krock ... the local server runs at some weird non-linear speed (steps). anoying
19:30 fwhcat joined #minetest-dev
19:38 Krock sfan5: "immediately available". Are these packets already cached and ready to process?
19:41 sfan5 yes
19:41 sfan5 it's the packets that are already inside the m_event_queue
19:41 Krock ah right. filled by ConnectionReceiveThread::receive()
19:44 Krock nice work
19:49 sfan5 now the issue reporter just needs to say that this fixes the issue
19:50 ensonic joined #minetest-dev
19:51 sfan5 thanks for reviewing
19:54 sfan5 re dtime accuracy: what about making dedicated_server_loop increment dtime more often, but having AsyncRunStep() only do something when `m_step_dtime> dedicated_server_step`?
19:56 Krock np. these were straight forward rather easy fixes
19:58 Krock well, that would also be an option. I didn't want to rely more than necessary on delta time values. Sleep is not always so accurate after all
20:02 Krock and currently the function mostly just returns instantly due to "if((dtime < 0.001) && !initial_step)"
20:02 Krock caused by setting m_step_dtime to zero each step
20:04 Krock rather than "m_step_dtime -= dtime;" it would mean "m_step_dtime -= fixed_server_step"
20:04 sfan5 well then dtime would be exactly the fixed step again
20:05 Krock yes, in any case. regardless how much time actually has passed. until AsyncRunStep is called again, m_step_dtime might already be incremented twice by dedicated_server_step
20:10 Krock after all it comes down that it's inaccurate by +/- 1 server step. two steps which take 10ms might be run instantly after each other if there's a m_step_dtime increment after 1..9ms
20:10 Krock given that a previous step took longer than usual
20:44 kilbith it's good to be sfan5
20:44 kilbith your PRs only opened for a few hours
20:45 kilbith if only it was like that for everything else ...
20:45 sfan5 that's also due to the size of my PRs
20:45 sfan5 but yes, there is an obvious advantage if the PR submitter is a coredev
20:45 kilbith like the CSM PR
20:46 kilbith caring more of your own PRs yes
20:52 rubenwardy that was also a fix to a fairly critical bug
20:53 rubenwardy wait, different PR
20:53 sfan5 you're not wrong
20:54 sfan5 well not really "critical", but some CSM things were badly broken too
20:57 kilbith the other ppl fixes are obvously dubious yeah
20:57 kilbith /s
21:12 proller joined #minetest-dev
21:34 proller joined #minetest-dev
22:11 proller joined #minetest-dev
22:54 longerstaff13 joined #minetest-dev
23:11 Fixer joined #minetest-dev
23:21 Ruslan1 joined #minetest-dev
23:58 NoctisLabs joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext