00:05 < bridge_> player\_name newame 00:06 < bridge_> player\_body\_skin greensward 00:06 < bridge_> Or was it player\_skin\_body idk just type skin and iterate with tab key 03:44 < bridge_> @murpi esta ahi? 08:40 < bridge_> <_voxeldoesart> the word blazingly is now associated with the rust community good job 08:45 < bridge_> I don’t think so 08:46 < bridge_> when i hear ‘blazingly fast’ i think of JS toolkits 08:49 < bridge_> <_voxeldoesart> i doubt thats true 08:50 < bridge_> you doubt that’s what I think? 09:41 < bridge_> this is what blazingly fast is nowadays ^ 09:54 < bridge_> It fills your memory blazingly fast 09:55 < bridge_> yea 12:03 < bridge_> It’s short for **W**eb **T**emplate **F**ramework and provides commonly used functions all over the WebKit codebase. 12:19 < bridge_> They knew what they were doing 16:56 < bridge_> my map textures flew off what to do? 16:58 < bridge_> Read #bugs 16:59 < bridge_> Also don't spam in multiple channels 18:55 < bridge_> @chairn https://web.archive.org/web/20100228145846/http://x264dev.multimedia.cx/?p=317 18:55 < bridge_> i remember u mentioning wavelets 18:55 < bridge_> over fourier 19:01 < bridge_> im no video compression expert, but i thought they could just use a different wavelet function to get more sharpiness 19:02 < bridge_> like the Haar wavelet which keeps edges https://en.wikipedia.org/wiki/Haar_wavelet 20:45 < bridge_> that might make very sharp edges easier but will likely have much bigger problems with anything that's *not* sharp 20:45 < bridge_> like more blurred edges, gradients, and finer textures 21:17 < bridge_> @robyt3 what ya think 21:19 < bridge_> many ppl ask why long times etc 21:19 < bridge_> solution: 21:21 < bridge_> Seems straightforward to implement, but the main question is security again. Are you only going to allow it for official servers? Having the server make the client open an arbitrary URL in a browser seems like a recipe for disaster, given that our `open_link` is also generally unsafe. 21:21 < bridge_> @robyt3 does it need to be in the browser? 21:21 < bridge_> idk how the verify happens 21:21 < bridge_> but if its just a simple request 21:21 < bridge_> curl can do 21:21 < bridge_> and it doesnt execute js 21:21 < bridge_> so we can just timeout 21:21 < bridge_> on 2seconds 21:21 < bridge_> or so 21:22 < bridge_> true, although that would still leak the IP at the very least 21:22 < bridge_> but its still a action the user takes 21:22 < bridge_> like connecting 21:22 < bridge_> not automated 21:26 < bridge_> I don't know how the verification works, but it doesn't seem like any JS is involved right now. 21:31 < bridge_> Is making the client do an empty GET request to an arbitrary url a security issue. That's I guess the question we are looking to answer 21:32 < bridge_> Not more risk than having the server with that IP in the server list to begin with I'd say 21:34 < bridge_> Maybe we should only allow a port so people don't make requests to any other url? Though that might be unnecessarily restrictive I guess 21:38 < bridge_> maybe we are being overly cautios 21:38 < bridge_> the IP leak from master was a big thing 21:38 < bridge_> because simply loading the game leaked it to all the server list 21:38 < bridge_> here its a action the user takes willingly 21:38 < bridge_> like connecting 21:47 < bridge_> Which results in a connection to an ip that isn't shown anywhere that might not be related at all though 21:47 < bridge_> the internet isnt safe 21:47 < bridge_> u visit random webs 21:48 < bridge_> all day 21:48 < bridge_> idk 21:53 < bridge_> The only thing I'd be really concerned about is something like `"verify_url": "vodafone.station/reset_config_and_blow_up_router"` 22:59 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1125893746697981972/fpjzzu5bjz9b1.webp 23:04 < bridge_> I think this can also be caused by a simple `` 23:04 < bridge_> True, I guess it's fine then 23:12 < bridge_> wait for template error in c++ 😄