| Time |
Nick |
Message |
| 00:01 |
|
Noisytoot joined #minetest |
| 00:18 |
|
Noisytoot joined #minetest |
| 00:26 |
|
Noisytoot joined #minetest |
| 00:33 |
|
ShadowBot joined #minetest |
| 00:35 |
|
vampirefrog joined #minetest |
| 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 |
<wsor4035> [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 |
<wsor4035> 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 |
<wsor4035> 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 |
<jordan4ibanez> You have awoken me |
| 01:10 |
MTDiscord |
<jordan4ibanez> It's my old game |
| 01:12 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> 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 |
<wsor4035> basically |
| 01:14 |
MTDiscord |
<jordan4ibanez> 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 |
<wsor4035> ive thought of adding gravatar like support to cdb, but that projects on the backburner atm |
| 01:15 |
MTDiscord |
<wsor4035> . s/cdb/skinsdb |
| 01:17 |
MTDiscord |
<jordan4ibanez> 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 |
<wsor4035> 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 |
<wsor4035> 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 |
<wsor4035> 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 |
<wsor4035> 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? |
| 01:53 |
|
Noisytoot joined #minetest |
| 03:25 |
MTDiscord |
<jordan4ibanez> The only way to do this would be a reverse lookup table |
| 03:25 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> You could be the one that fixes that |
| 03:27 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> No seriously there are a lot of mods that use that I think it'll be accepted |
| 03:28 |
MTDiscord |
<jordan4ibanez> Turn that vector into a deque and insert that one into the front cause it was your idea lmao |
| 03:30 |
MTDiscord |
<jordan4ibanez> "mantar, the one that made our mods that poll the local player area for node groups not run horrible" |
| 04:35 |
|
oneeyedalien joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:17 |
|
Leopold joined #minetest |
| 05:19 |
|
fluxionary joined #minetest |
| 05:34 |
|
gregon joined #minetest |
| 05:34 |
|
tarsovbak joined #minetest |
| 05:53 |
|
gregon joined #minetest |
| 06:17 |
|
v-rob joined #minetest |
| 06:43 |
|
nopjmp joined #minetest |
| 06:46 |
|
Noisytoot joined #minetest |
| 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 |
<greenxenith> 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 |
<greenxenith> 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:43 |
|
Glaedr joined #minetest |
| 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 |
<greenxenith> updating the properties should be the only time it gets sent |
| 07:44 |
MTDiscord |
<greenxenith> The server doesnt re-send the texture when the player comes into view |
| 07:44 |
MTDiscord |
<greenxenith> The client should have it cached |
| 07:45 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> Therefore the skin is only sent across the network when setting player properties |
| 07:48 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> Im checking to make sure one doesnt already exist |
| 07:50 |
MTDiscord |
<greenxenith> If only I had the time, man |
| 07:51 |
MTDiscord |
<greenxenith> #9934 |
| 07:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/9934 -- object:set_properties() generates excess network packets |
| 07:52 |
MTDiscord |
<greenxenith> 4 years ago :] |
| 07:53 |
MTDiscord |
<greenxenith> sort of roundabout issue name unfortunately |
| 07:54 |
sfan5 |
well that's not the exact issue you mean |
| 07:55 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> Yeah, its the same issue. Like I said, roundabout name |
| 07:56 |
sfan5 |
it's not tho |
| 07:57 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> not send* |
| 07:59 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> So, different solution which solves both problems I guess |
| 08:19 |
MTDiscord |
<greenxenith> #14418 |
| 08:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/14418 -- object:set_properties() should only send changed properties |
| 09:45 |
|
cation joined #minetest |
| 10:25 |
|
TomTom joined #minetest |
| 10:52 |
|
tarsovbak1 joined #minetest |
| 10:56 |
|
s20 joined #minetest |
| 11:03 |
|
tarsovbak joined #minetest |
| 12:13 |
|
definitelya joined #minetest |
| 12:44 |
|
s20 joined #minetest |
| 13:48 |
|
Lunatrius` joined #minetest |
| 14:27 |
|
Pokey joined #minetest |
| 14:28 |
|
appguru joined #minetest |
| 14:46 |
|
Thermoriax joined #minetest |
| 14:56 |
|
jaca122 joined #minetest |
| 15:04 |
|
sparky4 joined #minetest |
| 15:43 |
MTDiscord |
<paradust> https://blog.opencollective.com/open-collective-official-statement-ocf-dissolution/ |
| 15:44 |
|
fluxionary joined #minetest |
| 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 |
<paradust> 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 |
<paradust> 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:05 |
|
fluxionary joined #minetest |
| 16:30 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Set VBO hints in more places 5280863 https://github.com/minetest/minetest/commit/5280863300e88c6e42c320115a53f0957e113589 (2024-02-29T16:20:49Z) |
| 16:30 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Drop enable_vbo setting 09d542d https://github.com/minetest/minetest/commit/09d542dfe0d7c29ff5f479e2fe2903ebda40400d (2024-02-29T16:20:49Z) |
| 16:30 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Properly warn that shader queue is unimplemented 5da18d3 https://github.com/minetest/minetest/commit/5da18d34ba326ce214e2f427af4cd8bdec219560 (2024-02-29T16:20:49Z) |
| 16:30 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Factor shadow constants out of MainShaderConstantSetter e9ab5bc https://github.com/minetest/minetest/commit/e9ab5bc223dab08fb936b3cc9f08f95a7b801e04 (2024-02-29T16:20:49Z) |
| 16:30 |
MinetestBot |
[git] (5 newer commits not shown) |
| 16:59 |
|
proller__ joined #minetest |
| 17:14 |
|
mrkubax10 joined #minetest |
| 17:35 |
|
SFENCE joined #minetest |
| 17:37 |
|
v-rob joined #minetest |
| 17:53 |
|
SFENCE joined #minetest |
| 17:53 |
|
SFENCE joined #minetest |
| 18:02 |
|
SFENCE joined #minetest |
| 18:03 |
|
Talkless joined #minetest |
| 18:25 |
|
oneeyedalien joined #minetest |
| 18:25 |
|
sparky4 joined #minetest |
| 18:26 |
|
appguru joined #minetest |
| 18:29 |
|
SFENCE joined #minetest |
| 18:42 |
|
SFENCE joined #minetest |
| 18:46 |
|
SFENCE joined #minetest |
| 18:51 |
|
SFENCE joined #minetest |
| 19:08 |
|
v-rob joined #minetest |
| 19:09 |
|
SFENCE joined #minetest |
| 19:22 |
|
nuala joined #minetest |
| 19:53 |
|
Desour joined #minetest |
| 19:56 |
|
SFENCE joined #minetest |
| 20:43 |
|
SFENCE joined #minetest |
| 20:54 |
|
v-rob joined #minetest |
| 21:25 |
|
TheSilentLink joined #minetest |
| 21:44 |
|
jaca122 joined #minetest |
| 22:15 |
|
TomTom joined #minetest |
| 22:33 |
|
bodiccea_ joined #minetest |
| 22:52 |
|
sparky4 joined #minetest |
| 23:33 |
|
panwolfram joined #minetest |
