Time Nick Message 04:37 erle we should really have a reference rendering of devtest nodes that can at least be compared manually 04:38 erle }ah, but why even compare manually? if you do mesa software rendering and output to an uncompressed bitmap, i see no reason why a render for the same circumstances should not be bitwise identical 06:58 sfan5 you see no reason why something as complex as OpenGL rendering would not be deterministic even if done in software, really? 08:35 erle oh, i bet there exist tons of reasons why stuff could not be deterministic – especially in minetest. but i believe that outside very carefully considered situations, rendering a static scene in a non-deteministic way is most likely a programming error. 08:36 erle in fact, while openGL rendering is not pixel exact between different GPUs, i would be surprised if mesa would accept if their software renderer behaved in random ways. 08:37 erle and if i am not mistaken, software rendering is taken as a baseline to verify hardware implementations 08:38 erle anyways, on the same hardware with the same drivers and inputs i fully expect openGL rendering to give me the same result for the same inputs, every time 08:42 erle and by “same inputs” i mean stuff like “mesa uses a 16-bit depth buffer by default, but the dev expected a 32-bit one” 08:42 x2048 Merging #12558 in 2 min 08:42 ShadowBot https://github.com/minetest/minetest/issues/12558 -- Offset cuboid origin after scaling the cuboid. by x2048 08:43 erle (a wrongly-sized depth buffer will lead to issues, but it will be the same issues every time) 08:48 x2048 Merged now 13:21 ROllerozxa is there anywhere in the main menu where the settings with the key type show up other than the hardcoded change keys dialog? 13:22 erle ROllerozxa what is your reason for the query? 13:35 ROllerozxa lol yeah I probably should start from that angle. the generate_from_settingtypes.lua script includes titles and descriptions for settings with the 'key' type in settings_translation_file.cpp. however the advanced settings menu excludes 'key' type settings, and the change keys dialog use their own strings. so from what I can see these strings go completely unused outside of minetest.conf.example, but still get translated which is a bit of a 13:35 ROllerozxa waste (~100 unused translation strings) 13:36 ROllerozxa so basically, 'else' => 'elseif entry.type ~= "key" then' @ builtin/mainmenu/generate_from_settingtypes:112 18:14 kilbith I've got around a much simpler implementation of `core.wrap_text`: http://codepad.org/8jcrG48f 18:14 kilbith bonus: it's UTF-8 aware 18:14 kilbith Luatic ^ 18:19 MTDiscord kilbith: you don't need the brackets around the pattern 18:21 x2048 Merging #12560 in a few minutes 18:21 ShadowBot https://github.com/minetest/minetest/issues/12560 -- Restore flags texture to fix interlaced stereo mode by x2048 18:23 MTDiscord kilbith: I highly doubt that your implementation could be used as a drop-in replacement for core.wrap_text 18:23 kilbith core.wrap_text has more parameters, so indeed no 18:24 kilbith hmm no 18:24 kilbith it doesn't have 18:24 MTDiscord it doesn't have what? 18:24 kilbith mind performing some tests? 18:24 kilbith more parameters 18:25 MTDiscord table.insert(buf, j + 1, "\n") definitely seems fishy to me 18:26 kilbith it's religion, not science until you perform some actual testing 18:27 x2048 ...done 18:27 MTDiscord first you have to define what you want your line wrapping to do :P 18:28 MTDiscord also why are you only checking against " " (ASCII space) rather than all forms of spacing (%s pattern item) 18:28 kilbith ... wrapping 18:28 kilbith yeah, right 18:29 kilbith in the real world you meet 99% of the time a ASCII space tho 18:29 MTDiscord anyways gtg 18:29 kilbith but you're right that it doesn't cost much more to check against %s 18:34 kilbith btw current wrap_text checks against " " as well 21:31 rubenwardy argh, I want 5.6.0 to be over already