Time Nick Message 06:54 celeron55_ i think just adding an api to set an effects preset, and having the default preset be "yes" or "realistic" or whatever is the most tolerable option 06:55 celeron55_ existing cartoonish games have to asd it once, and after that they're good 06:56 celeron55_ add* 07:54 Mantar sounds good to me 14:04 sfan5 merging #14582, #14603, #14600 in 10m or so 14:04 ShadowBot https://github.com/minetest/minetest/issues/14582 -- [no sq] Server/env optimizations by sfan5 14:04 ShadowBot https://github.com/minetest/minetest/issues/14603 -- Chat console: Prevent input loss on double open by SmallJoker 14:04 ShadowBot https://github.com/minetest/minetest/issues/14600 -- Warn at unknown CMAKE_BUILD_TYPE values by Desour 14:05 sfan5 @bastrabun I don't see a new debug.tgz yet 14:12 pgimeno re 14582, is `it < lights.end()` even guaranteed to work? 14:17 sfan5 https://en.cppreference.com/w/cpp/named_req/RandomAccessIterator defines ordering 14:17 MTDiscord sfan5 Apologies, it's up now 15:11 sfan5 quick takeaway: in one sample close to 40% of time is spent iterating the object list and calculating distances (getObjectsInArea et al) 15:12 MTDiscord i have a new idea for a spatial index actually 15:13 sfan5 the problem isn't the data structure, it's invalidation 15:15 sfan5 (the majority of those time is spent in situation where Lua has a chance to run inbetween lookups so "we'll just invalidate at every step" is not a possible shortcut) 15:16 MTDiscord not the shortcut i wanted to take 15:16 sfan5 just saying, it was one of my first thoughts 15:16 MTDiscord a forest of k-d-trees could provide O(log n) updates and O(k + sqrt n) queries where k is the result size 15:17 MTDiscord O(log n) amortized that is 15:18 MTDiscord that said, i'll have to test it because it's possible that for our "medium-size" problems the constant factors aren't good enough, though i am optimistic because k-d-trees are relatively simple. (this was the case when we tried a library providing R-trees for example.)