| Time |
Nick |
Message |
| 00:00 |
|
v-rob joined #minetest-dev |
| 00:08 |
|
AliasAlreadyTake joined #minetest-dev |
| 01:06 |
|
v-rob joined #minetest-dev |
| 02:12 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:03 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:08 |
|
Taoki joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:39 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:40 |
|
calcul0n_ joined #minetest-dev |
| 10:29 |
|
Fixer joined #minetest-dev |
| 12:17 |
|
calcul0n joined #minetest-dev |
| 12:24 |
|
calcul0n_ joined #minetest-dev |
| 12:50 |
|
appguru joined #minetest-dev |
| 14:11 |
|
Fixer_ joined #minetest-dev |
| 14:52 |
|
Extex joined #minetest-dev |
| 15:18 |
sfan5 |
rubenwardy: do you plan to display some of the CDB tags inside Minetest? I can see especially the WiP tag being useful |
| 15:18 |
rubenwardy |
That's displayed as part of the short description currently |
| 15:21 |
|
YuGiOhJCJ joined #minetest-dev |
| 15:22 |
sfan5 |
ah indeed |
| 15:22 |
sfan5 |
maybe color that |
| 15:53 |
|
calcul0n__ joined #minetest-dev |
| 16:05 |
|
olliy1or joined #minetest-dev |
| 16:34 |
|
troller joined #minetest-dev |
| 16:48 |
|
olliy joined #minetest-dev |
| 18:03 |
|
fluxionary joined #minetest-dev |
| 20:13 |
|
v-rob joined #minetest-dev |
| 21:01 |
|
Alias joined #minetest-dev |
| 21:24 |
sfan5 |
bump -> #11778 #11848 #11853 #11866 |
| 21:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/11778 -- Restore GCC 5 compatibility by JosiahWI |
| 21:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/11848 -- Improve TTF support for pixel-style fonts by v-rob |
| 21:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/11853 -- Automatically use SSE registers for FP operations on i386 by neoh4x0r |
| 21:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/11866 -- Raise max mapgen limit constant to align with MapBlock by sfan5 |
| 21:46 |
Krock |
sfan5: should your PR generate more terrain, i.e. outside of 30900 m? That seems to be untouched |
| 21:46 |
sfan5 |
it shouldn't |
| 21:47 |
Krock |
then why exactly is this change necessary? |
| 21:48 |
Krock |
even with "mapgen_limit = 33000" (map_meta.txt) there's no difference |
| 21:49 |
sfan5 |
broadly speaking for correctness |
| 21:49 |
sfan5 |
although the last mapblock is never generated having the limit end in the middle of one is still wrong |
| 21:52 |
sfan5 |
also #6765 |
| 21:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/6765 -- Add more neighbors on mesh update by numberZero |
| 21:53 |
Krock |
hmm. the world generates until 30927, which is an entire mapblock away from the 31007 limit |
| 21:53 |
Krock |
s/mapblock/chunk/ |
| 21:54 |
Krock |
if the limit is 31007, I would also the mapgen to generate that. |
| 21:55 |
sfan5 |
https://github.com/minetest/minetest/blob/0c4929f0252811d9715b96379973929053d32ef0/src/map.cpp#L1324-L1327 this could be removed |
| 21:55 |
sfan5 |
assuming the chunks fit properly inside the limit |
| 21:56 |
sfan5 |
not sure about this calculation but 30927 % (5*16) == 31007 % (5*16) so I guess it would? |
| 21:58 |
Krock |
yes, it should fit. I wonder why this radius check was added. maybe for oversized decorations which might otherwise overlap? |
| 22:28 |
MTDiscord |
<luatic> The docs say that the callback of dynamic_add_media is called as soon as the player gets the media. Will the callback be called if later players join and receive the media on join already? |
| 22:30 |
sfan5 |
no |
| 22:30 |
MTDiscord |
<luatic> I'm not quite sure how to ensure that all players have received a media file then. I could keep a table of players who have not received it yet and remove players as the callback is called. But what if a player is in the join process while the dynamic media is being added? When can I be sure that they will receive the media over the joining as opposed to over the callback? |
| 22:31 |
sfan5 |
this is ideally supposed to match up with when on_joinplayer is called |
| 22:31 |
MTDiscord |
<luatic> Are you sure though? |
| 22:32 |
MTDiscord |
<luatic> So if on_joinplayer is called after dynamic_add_media, is the player guaranteed to have received the dynamic media? |
| 22:32 |
sfan5 |
that's how it should be |
| 22:32 |
sfan5 |
no, I'm not sure |
| 22:32 |
MTDiscord |
<luatic> For that to be the case, wouldn't the media sending process have to take place after on_joinplayer is called? |
| 22:33 |
MTDiscord |
<luatic> before* |
| 22:34 |
sfan5 |
obviously |
| 22:34 |
MTDiscord |
<luatic> Hmm, I'll just assume that players have the file if on_joinplayer is called after the addition of the dynamic media. Worst that can happen should be missing textures. |
| 22:37 |
MTDiscord |
<luatic> sfan5: but if that's the case, then can't the following happen: 1. Media sending happens 2. dynamic_add_media happens 3. on_joinplayer is called 4. Media is considered safe to use for the player, as on_joinplayer was called after dynamic_add_media 5. Player is missing media 6. Player receives dynamic media |
| 22:39 |
sfan5 |
currently no |
| 22:40 |
sfan5 |
the media packet is only set to clients that are past on_joinplayer, I checked |
| 22:40 |
sfan5 |
this of course means there is potential for desync |
| 22:41 |
sfan5 |
but if you "fix" this there's another problem, you don't want the callback to be called before the player has "officially" joined |
| 22:41 |
sfan5 |
though the client code can't handle this either |
| 22:42 |
MTDiscord |
<luatic> sfan5, if I get this right, the following code should work: https://gist.github.com/appgurueu/e89a2f067bca6d07e0b0f1d7da7e5618 |
| 22:43 |
sfan5 |
you forgot to account for clients that can't receive the media (<5.3) |
| 22:44 |
MTDiscord |
<luatic> Don't worry, there's the boot for them :) |
| 22:44 |
MTDiscord |
<Jordach> oh wait we can't because we don't actually know their version unless the server runs -debug |
| 22:45 |
sfan5 |
of course you can, that's what the protocol version is for |
| 22:45 |
MTDiscord |
<luatic> protocol version got bumped somewhen though |
| 22:45 |
MTDiscord |
<luatic> what is the 5.3 protover? |
| 22:45 |
MTDiscord |
<Jordach> >bloated feature table |
| 22:45 |
MTDiscord |
<luatic> there should be a handy protocol version table somewhere else than the code... |
| 22:45 |
sfan5 |
create one in the wiki ;) |
| 22:45 |
MTDiscord |
<luatic> the wiki :o |
| 22:45 |
MTDiscord |
<luatic> why can't we let it die |
| 22:46 |
sfan5 |
no media packet is sent for < 39 so that'll be it |
| 22:46 |
MTDiscord |
<luatic> thanks |
| 22:48 |
MTDiscord |
<Jordach> i actually want to retire protocol_version |
| 22:49 |
MTDiscord |
<Jordach> and rather switch to a per packet versioning system that can support multiple modes or clientside changes |
| 22:49 |
MTDiscord |
<Jordach> and just clear out the no longer required ones with each release |
| 22:49 |
MTDiscord |
<luatic> awww, neither disconnect_player nor kick_player offer an option to allow the client to reconnect |
| 22:51 |
MTDiscord |
<luatic> dynamic media v2 takes care to support v1, right? |
| 22:52 |
sfan5 |
yes |
| 22:53 |
MTDiscord |
<luatic> nice |
