Time Nick Message 00:02 rubenwardy It may be worth discussing cleaning up player related flags 00:03 rubenwardy we currently have HUD flags, player object properties, and privileges 00:05 paramat oh crumbs, it needs a lot of justification though 00:05 paramat it works ok so why? 00:06 rubenwardy it may be worth making HUD flags just flags 00:07 rubenwardy means you can reuse the sending code 00:08 paramat ok, no harm discussing 00:09 rubenwardy it's best to do this before 0.5, to not break zoom and minimap too much 00:10 paramat yes, consider now is best, but it needs a reason 00:11 rubenwardy makes it easier to add flag like properties in the future 00:12 rubenwardy should reduce code 01:54 paramat will merge game#1911 in a moment 01:54 ShadowBot https://github.com/minetest/minetest_game/issues/1911 -- Map mod: Remove confusing 'use', reduce update interval by paramat 02:05 paramat done 06:15 Hijiri #5612 just needs one more approval 06:15 ShadowBot https://github.com/minetest/minetest/issues/5612 -- Allow overriding tool capabilities through itemstack metadata by raymoo 17:21 DTA7 Is it ok to make a setting variable thread_local? 17:21 DTA7 Like in https://github.com/minetest/minetest/blob/4e19791cde6b203ad853905d8c1481c43004a7ea/src/mapblock_mesh.cpp#L259-L260 17:22 sfan5 yes 17:23 DTA7 Ok, thanks 17:30 paramat on that subject. in rapidly used code, is 'static const thing = g_settings->get..()' just as optimal as using a cache variable that does 'g_settings->get..()' once outside the rapidly used code? 17:32 DTA7 Yes, it is only initialized once per thread 17:34 DTA7 http://en.cppreference.com/w/cpp/language/storage_duration 17:35 DTA7 In the section "Static local variables" 17:38 DTA7 (with thread_local I mean, otherwise once per program) 17:48 paramat yea i know, but i was wondering if despite that one is slightly more optimal than the other 18:32 DTA7 Oh ok, I don't know, where else would you cache the setting? 19:38 paramat dunno :}