| 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 |
