Minetest logo

IRC log for #minetest-dev, 2021-12-27

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

All times shown according to UTC.

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

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