Time Nick Message 00:50 kyle56_has_conne sfan5: thanks for your input. i will probably examine both options. for context this is for a skin mod. so i expect most if not all images to be low res. if anyone else has an opinion on png texture modifier vs dynamic media for <4kb images, i'd be interested in hearing about it. 00:53 MTDiscord [png is less code than dynamic media. only thing dynamic media has over it is you could send different players different textures for the same filename, so that they see a different texture than others do 00:54 MTDiscord in the context of textures 01:03 kyle56_has_conne the png one might be more suited to my usecase because of the less code. and my mod will be handling images from http requests so it can just base64 encode it and put it in the modifier. but also sending different textures to different players could be useful for hiding skins from certain players who may not want to see them. 01:04 MTDiscord allowing people to specify there own texture and then http fetching similar to crafter? 🤔 01:09 kyle56_has_conne i'm not familiar with that mod. but yeah something like that. but it uses my own web server. 01:10 MTDiscord You have awoken me 01:10 MTDiscord It's my old game 01:12 MTDiscord You can automatically load your skin based on your github name, it's like using github what it was designed to do, in the wrong way 01:13 MTDiscord You made some repo on your github with your skin png and it automatically reached in and plucked it out 01:14 kyle56_has_conne oh thats cool. so kinda like using github like its gravatar? 01:14 MTDiscord basically 01:14 MTDiscord Pretty much, but a lot weirder. Technically you could make custom repos so you can have a different skin on each server, but I never implemented that 01:14 MTDiscord ive thought of adding gravatar like support to cdb, but that projects on the backburner atm 01:15 MTDiscord . s/cdb/skinsdb 01:17 MTDiscord I think that would be very neat 01:17 kyle56_has_conne oh? i am not familiar with skinsdb either. i was thinking of making my own skin database for my server. 01:17 MTDiscord https://skinsdb.terraqueststudios.net/ i host it now after the orginal vanished 01:18 kyle56_has_conne im thinking mine could either work like the minecraft one where players upload a skin to their account, or it could work where they can pick any skin in my database and upload their own. 01:19 MTDiscord https://github.com/TerraQuest-Studios/skinsdb-astro is the wip replacement for the quasi static page currently 01:23 kyle56_has_conne for mine i think i think it would be cool to have ways of sorting the skins by gender and species. I like the API that yours has. i like that it has the base64 there. 01:28 MTDiscord the plan is to allow sorting by license, author, etc. could make it agnostic if you wanted to use the project as well 01:30 kyle56_has_conne not sure what you mean by agnostic 01:32 MTDiscord make the filters come from the database, rather than being hardcoded/focused. so that anyone could create there own type of filters 01:42 kyle56_has_conne ah i see. well i might have it so some filters are custom. gender could be hardcoded to male, female, and other/agender but species filter should be able to have custom ones 01:50 Mantar hey, is there a way to get a list of node defs that are in a particular group? Like, without parsing over all of minetest.registered_nodes and checking? 03:25 MTDiscord The only way to do this would be a reverse lookup table 03:25 MTDiscord You'd trade cpu time for memory at the beginning, but if you're doing it a lot it'll save you a lot of cpu time for a relatively small memory footprint 03:26 Mantar Yeah, that's what I figured. Academic question really, we just used a different method, but I was mildly surprised there's nothing in the api to do that. 03:27 MTDiscord You could be the one that fixes that 03:27 MTDiscord Go, mantar, it's up to you now 03:27 Mantar heh 03:27 Mantar I could put it on my to-do list, but that thing is scary long already 03:27 MTDiscord No seriously there are a lot of mods that use that I think it'll be accepted 03:28 MTDiscord Turn that vector into a deque and insert that one into the front cause it was your idea lmao 03:30 MTDiscord "mantar, the one that made our mods that poll the local player area for node groups not run horrible" 07:38 sfan5 kyle56_has_conne, wsor4035: the relevant difference is that [png will waste space and network traffic to send the entire skin repeatedly, even if you have not changed it 07:41 celeron55_ [png is essentially like data URLs in html5 07:42 MTDiscord The [png would only waste space for dynamic textures; It isnt much more data than sending a skin file to each client, no? 07:42 celeron55_ if you don't grasp the pros and cons, don't use it 07:42 celeron55_ but if you do, it's a good tool in the toolbox 07:42 celeron55_ with [png, any time the server has to refer to the texture, it sends the entire texture 07:43 MTDiscord And it should only be referring to it once each time it gets sent to clients, right? 07:43 celeron55_ whether this happens often or not depends on various things, but it will happen every time the player who has the skin comes into sight, for example 07:43 kyle56_has_conne i think i see what you mean. like every time an entity/player with a [png modifier is loaded onto a client, it re-sends the image each time? 07:44 celeron55_ yes 07:44 celeron55_ at least once 07:44 celeron55_ possibly multiple times per each, i don't know 07:44 sfan5 worse: when you update the object properties of an object with a [png texture, it is sent again. entirely. 07:44 MTDiscord updating the properties should be the only time it gets sent 07:44 MTDiscord The server doesnt re-send the texture when the player comes into view 07:44 MTDiscord The client should have it cached 07:45 MTDiscord Not necessarily as an image, but cached in the properties at the very least 07:45 celeron55_ [pngs are not cached, that's the entire point 07:45 kyle56_has_conne oh i think i see how that might be a problem since i change object/player properties to change their size and shrink them. 07:45 MTDiscord The strings they are a part of can absolutely be cached though 07:45 celeron55_ in [png, the data is the name of the texture. the server uses the name of the texture to refer to the texture. it is not allowed to shorten it in any way, the name is part of the protocol 07:46 MTDiscord If player properties are cached on the client (which I am under the impression that they are), a [png used as a skin is cached, as a string, no? 07:47 sfan5 player properties are "cached" on the client (for lack of a better word), but they can only be updated in whole by sending all of them again 07:47 sfan5 (partial updates are of course not technically impossible, but just not implemented) 07:47 MTDiscord Therefore the skin is only sent across the network when setting player properties 07:48 MTDiscord That would be a good issue to open if it doesnt already exist 07:49 sfan5 object properties to be precise and that is everything inside set_properties 07:49 celeron55_ a good size for a [png is maybe 50 to 200 bytes. if it's more than that, it will start to bog down the thing more than intended and that will never be fixed. the fix is always you changing to use dynamic media instead 07:49 MTDiscord No reason set_properties shouldnt do that anyway, as far as I can tell 07:50 sfan5 feel free to open an issue 07:50 celeron55_ even better, make a PR instead 07:50 MTDiscord Im checking to make sure one doesnt already exist 07:50 MTDiscord If only I had the time, man 07:51 MTDiscord #9934 07:51 ShadowBot https://github.com/minetest/minetest/issues/9934 -- object:set_properties() generates excess network packets 07:52 MTDiscord 4 years ago :] 07:53 MTDiscord sort of roundabout issue name unfortunately 07:54 sfan5 well that's not the exact issue you mean 07:55 MTDiscord Looks like exactly the issue to me 07:55 sfan5 issue: object:set_properties() should not generate packet if call did not change properties 07:55 sfan5 you: object:set_properties() should be able to send only the properties that actually changed 07:56 sfan5 (I just sneakily renamed the issue) 07:56 MTDiscord Yeah, its the same issue. Like I said, roundabout name 07:56 sfan5 it's not tho 07:57 MTDiscord Except it is. set_properties should net send properties that didnt change. It should not generate packets for properties that didnt change. 07:57 MTDiscord not send* 07:59 MTDiscord I feel like the new title incorrectly implies "when calling set_properties with nothing, dont generate packets" when that is not what the issue was about (see the discussion) 07:59 MTDiscord Excess packets meaning "we dont need the rest of these, just the ones that changed" 08:03 kyle56_has_conne i guess the dynamic add media is probably the better option but implementing it is kind of a pain. my mod has to first download the skins from my database then save them into a folder then dynamically load it to the players then wait for all the players to have it before i update the model's properties. 08:03 MTDiscord The initial point in the discussion is that setting an unchanged property sends a packet anyway, though it need not. That directly extends to "check to see if this property actually changed, otherwise dont send it". The last comment in the thread is from you, supporting the suggestion from warr to check against cached properties. 08:06 MTDiscord Perhaps the comment before that from paramat is confusing me, as he also directly addresses the issue of all properties being sent when they need not be, but it still feels like the same solution to me 08:11 sfan5 we only have a way to send all properties in one big packet. changing that is a bigger amount of work orthogonal to ensuring this one big packet is not sent when not needed 08:11 sfan5 maybe that clears it up 08:12 MTDiscord So, different solution which solves both problems I guess 08:19 MTDiscord #14418 08:19 ShadowBot https://github.com/minetest/minetest/issues/14418 -- object:set_properties() should only send changed properties 15:43 MTDiscord https://blog.opencollective.com/open-collective-official-statement-ocf-dissolution/ 15:48 sfan5 huh 15:49 ROllerozxa (only one of the three fiscal hosts are shutting down) 15:49 ROllerozxa Open Source Collective and Open Collective Europe are fine, Open Collective Foundation is shutting down 15:50 MTDiscord Yea. Probably not relevant to anyone here, since the opencollective site is a separate org. But it is interesting they were caught by surprise 15:51 MTDiscord Also interesting there is a common for-profit parent organization 15:59 sfan5 @greenxenith here you go #14419 15:59 ShadowBot https://github.com/minetest/minetest/issues/14419 -- [no sq] Fix some common SAO methods to not generate useless update packets by sfan5 16:30 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Set VBO hints in more places 135280863 https://github.com/minetest/minetest/commit/5280863300e88c6e42c320115a53f0957e113589 (152024-02-29T16:20:49Z) 16:30 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Drop enable_vbo setting 1309d542d https://github.com/minetest/minetest/commit/09d542dfe0d7c29ff5f479e2fe2903ebda40400d (152024-02-29T16:20:49Z) 16:30 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Properly warn that shader queue is unimplemented 135da18d3 https://github.com/minetest/minetest/commit/5da18d34ba326ce214e2f427af4cd8bdec219560 (152024-02-29T16:20:49Z) 16:30 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Factor shadow constants out of MainShaderConstantSetter 13e9ab5bc https://github.com/minetest/minetest/commit/e9ab5bc223dab08fb936b3cc9f08f95a7b801e04 (152024-02-29T16:20:49Z) 16:30 MinetestBot 02[git] (5 newer commits not shown)