Time Nick Message 03:21 MTDiscord Use msys 04:08 MTDiscord ExeVirus, it's the mingw CI build. :| 04:18 erlehmann sfan5 you closed this, but i am pretty sure that this is not a GPU driver bug. rather, i think that 512 instructions is the minimum (many cards have more) https://github.com/minetest/minetest/issues/12035#issuecomment-1027306600 04:20 erlehmann e.g. you are guaranteed 512 instructions for your shader in OpenGL 2.0, i am not sure about this. 04:22 erlehmann wtf is OpenGL 2.0a https://en.wikipedia.org/wiki/High-level_shader_language#Pixel_shader_comparison 04:22 erlehmann oh, hlsl vs glsl 04:22 erlehmann i should sleep 04:24 erlehmann https://stackoverflow.com/questions/2617957/glsl-maximum-number-of-instructions/5601884#5601884 04:24 erlehmann > 512 instruction slots for vertex and pixel shaders on OpenGL 2.x (SM3) capable hardware 04:25 erlehmann maybe there are different limits for OGLES 04:25 erlehmann anyway it seems like a good idea to stay under the limit maybe? 04:26 erlehmann https://github.com/hrydgard/ppsspp/issues/1816#issuecomment-517872311 07:12 sfan5 erlehmann: I (and I hope nobody else) is going to spend any time moving shader things around to make some underpowered hardware work 07:13 erlehmann uh i do not understand, you are or you aren't? 07:14 erlehmann i mean, from context i guess you aren't. but i can't parse the sentence. 07:14 sfan5 +am not 07:14 erlehmann ok 07:14 erlehmann thx 07:26 erlehmann there is one problem though; i can't find the OGLES2 limits right now, but the spec for GLSL ES says that it the limits are determined by the conformance tests, and the mali gpu is conformant. 07:27 erlehmann or at least so says the vendor https://en.wikipedia.org/wiki/Mali-400_MP 07:27 erlehmann > world’s first OpenGL ES 2.0 conformant multi core GPU 07:27 erlehmann so i'm pretty sure you can't say that you are doing OGLES2 if an OGLES2 conformant thing doesn't work with it 07:32 erlehmann regardless, a better error message may make sense here. i.e. blacklisting the mali GPU. 07:49 sfan5 @josiah_wi nothing to do with mingw, it just expects to be able to set various libraries directly. these same options are also documented in the readme 10:23 Baytuch Good evening 10:31 MTDiscord good day 11:53 MTDiscord @Josiah 13:23 MTDiscord sfan5, I tried to support that, I don't understand yet why my fix doesn't work. I added those variables to the PATHS to search; am I missing something? 15:27 sfan5 not sure what exactly PATHS does but note that the variables contain exact file paths, not folders to search 18:25 MTDiscord https://forum.minetest.net/viewtopic.php?f=6&t=27616 - is anybody able to confirm this? 18:26 MTDiscord cant confirm, but it was brought up in the past 18:30 fluxionary is there a way to get wireshark to re-assemble "split" packets and parse what's in them? (using the minetest plugin) 18:31 Wuzzy Is it normal that minetest.set_mapgen_setting does not actually set the mapgen setting after launch? 18:32 Wuzzy Try this test code in a test mod and start MTG: minetest.set_mapgen_setting("mgv6_spflags", "nomudflow,nosnowbiomes,notrees,nojungles") 18:32 MTDiscord its per world, not global 18:32 Wuzzy no. 18:32 Wuzzy it does literally nothing 18:32 Wuzzy not even per-world 18:32 rubenwardy you need to pass `true` to override 18:32 rubenwardy https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L5306 18:33 rubenwardy according to the docs 18:33 Wuzzy but this doesn't make sense. it's a NEW world oO 18:33 rubenwardy I think 5.5.0 writes those settings directly to the file 18:33 rubenwardy this override param is weird 18:33 rubenwardy set mapgen setting should set it... 18:34 Wuzzy by that logic, the only way to call this function correctly for ANY mapgen setting is to set overrride_meta to true... *shrug* 18:34 Wuzzy this is strange 18:34 Wuzzy also, won't override_meta force the mapgen setting on existing worlds as well? 18:34 Wuzzy what if i change the mapgen setting in future? This will lead to map breakage 18:34 Wuzzy right? 18:35 Wuzzy but ok, I can set override_meta anyway, my game is still in alpha, so who cares? ? 18:35 Wuzzy it "works" but it feels wrong :/ 18:35 Wuzzy I feel like the docs only tell half of the story. there is somehing missing 19:18 Krock will merge #12037, #12025, #12046 and #12029 in 10 minute 19:19 Krock shadowbot do be dead sometimes 19:20 Krock Wuzzy: yes, that API sucks but it used to be similar if not identical in earlier MT versions 19:21 Wuzzy at least i deployed a hotfix now 19:21 erlehmann wasn't there a change for the world creation dialog bc setting it in one game set it for other games? 19:22 erlehmann i forgot how it was handled, but given how refactorings or fixes sometimes touch related stuff for convenience, i'd look there first 19:23 rubenwardy Already mentioned, erlehmann 19:24 erlehmann Krock 12037 is something we have waited for a long time in mineclonia. lots of games do this wrong! thank 19:24 rubenwardy Oh, in #minetest 19:25 Krock erlehmann: then propose patches to fix those games. it's not minetest's job 19:26 sfan5 commented on 12037 with a suggestion 19:26 Krock did too 19:27 erlehmann Krock imo engine should warn in this case in debug builds, bc otherwise ppl do not realize that they have insanely wasteful globalsteps set up. what do you think? 19:28 Krock that's the profiler's task 19:28 Krock merging the 3 other PRs 19:28 erlehmann oh, i did not konw the profiler can warn you about doing no-ops! let's continue it in #minetest then 19:29 rubenwardy Disagree, the engine should track changes and batch updates 19:29 rubenwardy More of a problem with object properties 19:29 Krock done 19:30 Krock I'd rather opt for incremental updates 19:30 Krock as for HUD flags there's no point due to low data 19:31 rubenwardy That's can be done nicely with batch updates 19:31 rubenwardy Send a package with a series of opcodes and values. Opcode=0 sets object id, other opcodes set properties 19:31 rubenwardy *packet 19:32 sfan5 question is how much more work is that 19:33 erlehmann Krock we have actually debugged this in mineclonia and the amount of packets is the problem, not the payload https://git.minetest.land/Mineclonia/Mineclonia/issues/111 19:33 sfan5 not necessary to implement but to maintain e.g. if you want to add a new one 19:33 Krock yes I know 19:33 Krock too many packets may clutter the queue 19:34 erlehmann now that i see it: https://github.com/minetest/minetest/issues/11459 can prob be closed if you merge #12037 ig 19:34 Krock no 19:34 Krock this is about HUD elements, and not flags 19:36 erlehmann oh sorry then 19:37 rubenwardy The add a new one, you'd extend the switch. You'd only send opcodes to clients that support it 19:37 rubenwardy Are object property updates multicast? 19:37 rubenwardy because you'd need to send per-client. Or at least per protocol version 19:38 rubenwardy otherwise you'd need someway of encoding length 19:39 Krock yes, multicast because it contains collision box and selection box information 19:39 MTDiscord the problem i have with not sending flags/properties/etc if the same is sometimes its necessary to work around broken parts of the engine 19:39 Krock and all other visuals 19:39 rubenwardy I don't see why that requires multicast 19:39 erlehmann just so i understand it: right now, what is preventing the engine from just not sending anything if an object property is set but it already has that same value? that someone might not be in range and then come in range or something? 19:39 rubenwardy by multicast, I mean the same packet content sent to subscribed players 19:39 rubenwardy rather than a packet per player 19:39 erlehmann Jonathon which kind of broken parts? they should have to be fixed first 19:39 Krock rubenwardy: if one updates, all clients must be aware of it 19:40 rubenwardy you can do that as a packet per player, rather than a multicast 19:40 Krock https://github.com/minetest/minetest/blob/master/src/object_properties.cpp#L119 19:40 rubenwardy but you can lose some performance - but you gain performance with batching and incremental updates 19:40 Krock except that there's currently no way of marking this stuff as dirty 19:40 rubenwardy yeah that would be needed 19:41 erlehmann ohhh, i get it. damn. 19:41 Krock 1 bit per parameter.. this would be feasible 19:41 rubenwardy yeah, a bitset 19:42 Krock although it may get out of hand very quickly. int128 needed, if not more to be future-proof 19:42 rubenwardy doesn't need to be future proof, as it's not part of the network 19:42 rubenwardy just use std::bitset 19:42 Krock it is literally the network 19:42 rubenwardy you don't need to send modified bit flags 19:42 erlehmann well if you are not sending anything bc nothing is dirty, nothing is part of the network? 19:42 Krock how would you let the clients know of updated fields? 19:43 Krock there must be a scheme to it 19:43 rubenwardy <+rubenwardy> Send a packet with a series of opcodes and values. Opcode=0 sets object id, other opcodes set properties 19:43 Krock it's exactly that 19:43 Krock except that you've got bitfields rather than opcodes 19:43 rubenwardy enum class ObjectPropertyId { OBJECT_ID=0, VISUAL_SIZE=1, TEXTURE=2 } 19:43 rubenwardy you don't want bitfields, that's wasteful 19:43 sfan5 bitfields are a better design if you often set multiple at once 19:43 Krock not if stuff updates in bulk 19:44 rubenwardy right 19:44 erlehmann i guess it's time to gather some realworld data on how object property network spam actually looks like 19:45 erlehmann any way i can assist there? 19:45 Krock in this case it's less spam, and more data amount 19:45 rubenwardy for bitfields to be worth it, you need to send more than 16 changed fields on average 19:46 rubenwardy assuming 16 byte (128bit) bitset vs 1 byte opcode 19:46 Krock there'c approx. 40 frields currently 19:46 erlehmann someone who knows go could prob use the anon5 lib to make a proxy to measure this tbh 19:46 Krock *fields 19:47 sfan5 you can easily make some tradeoffs and do one bitfield per 8 properties 19:47 Krock that's definitely not me who would do that. also wireshark could do that too 19:47 erlehmann https://github.com/anon55555/mt 19:47 sfan5 in which case a bitfield is always equally or more efficient even at 1 op 19:47 erlehmann Krock i believe the dissector is not up to the task rn or is it? 19:48 Krock erlehmann: not quite, but for packet sizes and occurrences it should suffice 19:53 erlehmann Krock i am *very* sceptical of having an opinion in the bitfield vs opcode debate without some actual data on the issue – and given that packet spam has not been solved in years, there seems to be no hurry. i'll read up a bit on dissectors now. 20:48 MTDiscord sfan5, thank you very much, that explains what the issue is. 22:58 MTDiscord Don't object properties have the same issue of unnecessary resending?