| Time |
Nick |
Message |
| 00:00 |
|
kaeza joined #minetest-dev |
| 01:02 |
|
ANAND joined #minetest-dev |
| 01:26 |
|
Cornelia joined #minetest-dev |
| 01:53 |
|
oil_boi joined #minetest-dev |
| 01:54 |
|
oil_boi joined #minetest-dev |
| 03:04 |
|
tuedel joined #minetest-dev |
| 03:15 |
|
nerzhul joined #minetest-dev |
| 04:00 |
|
Miner_48er joined #minetest-dev |
| 05:00 |
|
kaeza joined #minetest-dev |
| 05:07 |
|
T4im joined #minetest-dev |
| 06:01 |
|
nerzhul joined #minetest-dev |
| 06:02 |
|
JTE joined #minetest-dev |
| 06:09 |
|
Cornelia joined #minetest-dev |
| 06:35 |
|
pyrollo joined #minetest-dev |
| 06:36 |
|
pyrollo_ joined #minetest-dev |
| 06:50 |
|
kaeza joined #minetest-dev |
| 06:59 |
|
kaeza joined #minetest-dev |
| 07:19 |
|
Lunatrius joined #minetest-dev |
| 07:27 |
|
Beton joined #minetest-dev |
| 07:59 |
|
ensonic joined #minetest-dev |
| 09:44 |
|
proller joined #minetest-dev |
| 10:23 |
rubenwardy |
#8383 |
| 10:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/8383 -- Add formspec styling using a style[] tag by rubenwardy |
| 10:52 |
|
proller joined #minetest-dev |
| 11:15 |
|
proller joined #minetest-dev |
| 11:39 |
|
calcul0n_ joined #minetest-dev |
| 11:48 |
|
Fixer joined #minetest-dev |
| 11:52 |
|
Fixer_ joined #minetest-dev |
| 12:46 |
|
nerzhul joined #minetest-dev |
| 12:49 |
|
Wuzzy joined #minetest-dev |
| 13:01 |
|
Jewson_ joined #minetest-dev |
| 14:30 |
|
proller joined #minetest-dev |
| 15:11 |
|
Darcidride joined #minetest-dev |
| 15:38 |
|
pyrollo joined #minetest-dev |
| 15:41 |
|
Unioll joined #minetest-dev |
| 15:44 |
|
pyrollo_ joined #minetest-dev |
| 16:08 |
|
nerzhul joined #minetest-dev |
| 16:23 |
|
proller joined #minetest-dev |
| 17:03 |
|
proller joined #minetest-dev |
| 17:24 |
|
fwhcat joined #minetest-dev |
| 17:27 |
|
proller joined #minetest-dev |
| 17:34 |
|
nerzhul joined #minetest-dev |
| 18:57 |
|
ensonic joined #minetest-dev |
| 19:02 |
sofar |
for mp3/opus/ogg: the reason to add mp3 support is that for long sound tracks and music, mp3 offers the lowest size at lossy quality levels (~128kbits) and thus may offer significant download size benefits |
| 19:03 |
sofar |
if you want quality, ogg is best |
| 19:03 |
sofar |
but servers that want music tracks pay a heavy penalty now, and one that could be much less |
| 19:09 |
p_gimeno |
um, can't ogg compress at the same bit rates as mp3? |
| 19:09 |
VanessaE |
we need streaming :) |
| 19:09 |
VanessaE |
server should jhust tell the client "go to this URL, stream this sound" |
| 19:09 |
VanessaE |
-h |
| 19:12 |
p_gimeno |
comparing the quality of ogg and mp3 only makes sense for the same bitrates, and at low bitrates, ogg quality is superior |
| 19:13 |
VanessaE |
actually a better idea would cached steaming -- tell the client "go to this URL, stream this sound, and save the file for later re-use" |
| 19:13 |
VanessaE |
that would be the best of both worlds imhop |
| 19:13 |
VanessaE |
-p |
| 19:14 |
VanessaE |
the total bandwidth use at the server would be comparable, but there'd be basically zero extra client download time |
| 19:16 |
VanessaE |
and if the sound has to be cut off, either stop the sound and let the download finish in the background, or just finish the download next time the sound is needed |
| 19:16 |
VanessaE |
(cut off early i.e. the user has moved on to something else not needing the sound) |
| 19:17 |
VanessaE |
said URL could of course just be a public media server like yours or mine |
| 19:18 |
VanessaE |
hell even a URL could be avoided if the sound can be sourced from the media server the client is already about to download other stuff from |
| 19:18 |
VanessaE |
just so long as the download/playback happens in realtime. |
| 19:21 |
VanessaE |
one flag added to SimpleSoundSpec, and something to tell the server at connect time what files to avoid immediately downloading |
| 19:23 |
VanessaE |
s:server:server/client: s/downloading/transferring/ |
| 19:23 |
JTE |
Currently I've been using the engine's sounds folder (the one used for main menu music for some reason) to play music. If the client has no appropriately named sounds installed there, they hear nothing (the server doesn't have any of the files so it doesn't pack them in with resources for download at all), but if the client has files it plays them when the server tells it to. That way, the server only needs to say "play snow village |
| 19:23 |
JTE |
music" and the client themselves can customize their OST to contain whatever eleven "music_village_snow.ogg", "music_village_snow.0.ogg", "music_village_snow.1.ogg", etc. files they want to hear for that event. |
| 19:23 |
VanessaE |
JTE: that's how technic's music player works, too. |
| 19:23 |
JTE |
The only downside is that the server can't provide a default fallback soundtrack, so everyone joining the server from the server list hears nothing and doesn't even know music is supposed to be there. (No error messages or anything.) |
| 19:24 |
VanessaE |
and is what my stream-to-cache idea is meant to address |
| 19:24 |
VanessaE |
I just wish I could code it. |
| 19:24 |
sofar |
p_gimeno: ogg is superior at high bitrates, and lossless, not low+lossy bitrates |
| 19:25 |
sofar |
at least from the data sources I've found |
| 19:25 |
p_gimeno |
sofar: lossless ogg? I haven't read of that. This comparison disagrees, anyway: this comparison disagrees: http://nigelcoldwell.co.uk/audio/ |
| 19:25 |
JTE |
ogg vorbis is medium to high bitrate only, yes. but there is also ogg opus. |
| 19:25 |
p_gimeno |
oops |
| 19:27 |
p_gimeno |
well, when I say ogg I mean vorbis, of course - from what I read, ogg can encapsulate vorbis, opus and flac |
| 19:27 |
sofar |
streaming wouldn't be an option for music embedded in local games you want to play offline |
| 19:28 |
sofar |
so download size would still matter |
| 19:28 |
sofar |
but, not as important |
| 19:28 |
VanessaE |
sofar: well no, it wouldn't help singleplayer but in that case, who cares about download size? |
| 19:28 |
JTE |
I'd love for the server to be able to dictate some resources (sounds AND models) as being "download as necessary and not entirely before connecting" but that would be kind of a big deal. @@; |
| 19:28 |
sofar |
the player would when they download the game... :) |
| 19:29 |
VanessaE |
heh maybe |
| 19:29 |
VanessaE |
but with stream-to-cache, you could have gigs of audio on the server, and the clients wouldn't even have an extra second of download time at connect :) |
| 19:30 |
sofar |
which would definitely make things less enjoyable for players that have limited BW |
| 19:30 |
VanessaE |
why? |
| 19:30 |
sofar |
downloading while playing == lag |
| 19:30 |
VanessaE |
stream in realtime would take less bandwidth than a full download. |
| 19:31 |
sofar |
sure, cache-streaming, I can see that help |
| 19:31 |
VanessaE |
that's the idea |
| 19:31 |
sofar |
I wonder if the remote media server could indeed serve that up |
| 19:31 |
VanessaE |
download at like 20 kB/sec to get the audio in at realtime speed instead of 200 kB/sec |
| 19:32 |
VanessaE |
should be zero lag potential if it's done right :) |
| 19:32 |
VanessaE |
well, I don't see why not |
| 19:32 |
VanessaE |
it's not like the media server has to know what's being done with the file. |
| 19:32 |
VanessaE |
just so long as it's capable of resuming a partial download |
| 19:32 |
sofar |
the client will need to seek and read partial content |
| 19:32 |
VanessaE |
yeah |
| 19:33 |
sofar |
so libcurl needs to support seeks |
| 19:33 |
sofar |
well, it can already |
| 19:33 |
sofar |
hmm |
| 19:33 |
VanessaE |
client begins playback of the cached file, curl begins resuming the download, by the time he client gets to the resume point, there's already way more audio left, etc. |
| 19:33 |
sofar |
can't do checksum verification on it though |
| 19:33 |
sofar |
so you lose that, which is bad |
| 19:33 |
VanessaE |
meh, that can be worked around I'm sure |
| 19:34 |
VanessaE |
some kind of hash of the original path+filename maybe |
| 19:34 |
VanessaE |
or server+path+file etc. |
| 19:35 |
VanessaE |
or are you talking about verifying that the download isn't corrupt? |
| 19:35 |
sofar |
verifying that the remote media server is sending you the file you expect and not one that exploits your game |
| 19:35 |
VanessaE |
right |
| 19:35 |
VanessaE |
that's fair enough |
| 19:36 |
VanessaE |
but at that point, you're really just protecting against MitM right? |
| 19:36 |
sofar |
media server is a potential adversarial point |
| 19:37 |
sofar |
e.g. I run the PRMS |
| 19:37 |
VanessaE |
ohh |
| 19:37 |
VanessaE |
hm |
| 19:37 |
sofar |
many servers use the PRMS |
| 19:37 |
sofar |
I could inject false data, but right now clients would reject it entirely |
| 19:37 |
VanessaE |
that could pose a problem sure |
| 19:38 |
VanessaE |
how about handle it like is done now, but when the download completes, hash it then, in the background, and invalidate the file if it's bad? |
| 19:38 |
JTE |
make a bajillion mini-checksums for every 32 kb of a streaming file? heh... |
| 19:38 |
sofar |
JTE: yeah, that would break the compression :) |
| 19:38 |
VanessaE |
but then again, we don't do that now anyways do we? |
| 19:38 |
JTE |
oggs are already compressed |
| 19:38 |
sofar |
lazy loading is still possible |
| 19:39 |
sofar |
and I kinda like that idea |
| 19:39 |
sofar |
I thnk roblox does that |
| 19:39 |
VanessaE |
so it's not like there's any real verification once the file transfer is underway, it's not like the client hashes the file and compares it |
| 19:39 |
sofar |
once you have all the meshes, you can play even if you lack textures |
| 19:40 |
VanessaE |
sounds like something MT ought to do, then, though clearly of limited use on smaller files. |
| 19:40 |
VanessaE |
plus: |
| 19:40 |
VanessaE |
it would allow us to resolve one pain in the ass issue |
| 19:40 |
VanessaE |
adding new files during runtime :) |
| 19:41 |
VanessaE |
if a player wants a new skin, it would be really nice to let them have it then and there, instead of requiring server reboot+reconnect |
| 19:41 |
sofar |
that problem remains unsolved |
| 19:41 |
VanessaE |
I know. |
| 19:42 |
sofar |
because, you still need to tell the server there is new data, so it needs to reiniitialize lol |
| 19:42 |
VanessaE |
but with lazy loading, it would be easier to solve eventuall. |
| 19:42 |
VanessaE |
anyway that's secondary |
| 19:42 |
VanessaE |
just something that came to mind when you mentioned it |
| 19:47 |
sofar |
well we all want per player skin textures |
| 19:48 |
sofar |
maybe focus on that somehow |
| 19:48 |
VanessaE |
player_textures mod, homedecor_wardrobe, simple_skins, skinsdb.... |
| 19:48 |
VanessaE |
it's a solved problem, but each has its idiosyncrasies. |
| 19:48 |
sofar |
no, not what I mean |
| 19:49 |
sofar |
what I mean is players setting a skin in their client, then logging into a game and the game uses their skin |
| 19:49 |
sofar |
(possibly with some validation of allowed skins of course) |
| 19:49 |
VanessaE |
oh yeah |
| 19:50 |
VanessaE |
problem is R/X-rated skins. |
| 19:50 |
VanessaE |
or malicious imagery in general |
| 19:50 |
sofar |
easy enough to make an API that allows the server owner to allow/disallow skins |
| 19:50 |
VanessaE |
how? by filename? |
| 19:50 |
sofar |
just call some lua event on unknown hash |
| 19:50 |
VanessaE |
hm |
| 19:50 |
sofar |
and process the return value |
| 19:50 |
VanessaE |
so a whitelist |
| 19:51 |
sofar |
and only then send to other clients |
| 19:51 |
VanessaE |
I could see that working, but who creates the list of allowed skins? |
| 19:51 |
sofar |
the server admin |
| 19:51 |
VanessaE |
I mean, there must be hundreds of thousands out there |
| 19:52 |
sofar |
write a mod that server admins can use to categorize and classify skins |
| 19:52 |
sofar |
and one that allows specific levels only |
| 19:52 |
sofar |
use the httpapi to get data about the skins and share it online |
| 19:52 |
sofar |
I could write that part trivially |
| 19:53 |
VanessaE |
I could see that working I guess.. client sends a skin, whitelist isn't triggered, so it creates an "email" of sorts (like in Homedecor's mail mod) that must be approved or rejected |
| 19:53 |
sofar |
yep, and just falls back to a default skin defined on the server |
| 19:53 |
VanessaE |
that could work. |
| 19:53 |
sofar |
you could even allow `rp medieval` skins only that way |
| 19:53 |
sofar |
someone makes a new skin? upload, get pre-approval |
| 19:54 |
VanessaE |
all I know for now is skins are a bit of a pain in the ass right now (no 1.9 format support so they have to be cropped to 2:1 aspect, specific filenames needed, reboot needed...) |
| 19:55 |
sofar |
yep |
| 19:55 |
VanessaE |
enplus1 said he's willing to rewrite homedecor wardrobe to use simple_skins as the backend, and maybe I can talk him into adding 1.9 support, so at least some of that can be fixed. |
| 19:55 |
VanessaE |
tenplus1* |
| 20:59 |
|
nerzhul joined #minetest-dev |
| 22:04 |
|
Player-2 joined #minetest-dev |
| 23:04 |
|
Ruslan1 joined #minetest-dev |
