Time Nick Message 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:22 sfan5 ah indeed 15:22 sfan5 maybe color that 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 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 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 Are you sure though? 22:32 MTDiscord 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 For that to be the case, wouldn't the media sending process have to take place after on_joinplayer is called? 22:33 MTDiscord before* 22:34 sfan5 obviously 22:34 MTDiscord 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 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 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 Don't worry, there's the boot for them :) 22:44 MTDiscord 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 protocol version got bumped somewhen though 22:45 MTDiscord what is the 5.3 protover? 22:45 MTDiscord >bloated feature table 22:45 MTDiscord there should be a handy protocol version table somewhere else than the code... 22:45 sfan5 create one in the wiki ;) 22:45 MTDiscord the wiki :o 22:45 MTDiscord 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 thanks 22:48 MTDiscord i actually want to retire protocol_version 22:49 MTDiscord and rather switch to a per packet versioning system that can support multiple modes or clientside changes 22:49 MTDiscord and just clear out the no longer required ones with each release 22:49 MTDiscord awww, neither disconnect_player nor kick_player offer an option to allow the client to reconnect 22:51 MTDiscord dynamic media v2 takes care to support v1, right? 22:52 sfan5 yes 22:53 MTDiscord nice