00:04 < bridge> <robyt3> I don't think so. Images for tile layers should have width and height divisible by 16, so the images need to be at least 16x16
00:04 < bridge> <blade67> Yeah I just noticed that image data items have a width and height
00:05 < bridge> <robyt3> You can observe this when creating a pixelart with the tool in the editor, that should create very small embedded images for the pixel colors
00:05 < bridge> <blade67> Trying to figure out how to get the right size for the name tho
00:09 < bridge> <catseyenebulous> A multiple of 64 if I got it right.
00:09 < bridge> <catseyenebulous> https://forum.ddnet.org/viewtopic.php?f=16&t=4940
00:10 < bridge> <catseyenebulous> Are you trying to make a tileset?
00:13 < bridge> <robyt3> For detailed tilesets, yes, but if you only need colored blocks then each tile can be 1x1 pixel. The images always need to contain 16x16 tiles.
00:15 < bridge> <catseyenebulous> So 16 is the minimum, I see. :)
00:23 < bridge> <blade67> Sorry for the late reply, no I'm trying to render out an image embedded in a map file
00:24 < bridge> <catseyenebulous> So you are trying to get an immage from a map?
00:24 < bridge> <blade67> Yes, more specifically tilesets
00:34 < bridge> <catseyenebulous> Can you get the name of the tileset and then search it up?
00:36 < bridge> <blade67> I see what the issue here is. Sorry for the confusion. I'm a programmer, I'm implementing the teeworlds map format in the Godot engine. Hence why I'm talking in the #developer channel. All my questions etc. are programming related
00:46 < bridge> <catseyenebulous> Oh my bad. ^^ If you just needed the size then Robyt answered it already I guess.
00:47 < bridge> <blade67> Well, technically he did, although I asked my question in such a stupid way that he didn't answer my questio (absolutely my fault!)
00:47 < bridge> <blade67> But I did it!
00:47 < bridge> <blade67> https://cdn.discordapp.com/attachments/293493549758939136/1167957917610287165/image.png?ex=65500493&is=653d8f93&hm=5964687f8fa49f77692073b0936a2fb20d7146b127675737718a5a108f37c663&
00:48 < bridge> <catseyenebulous> Haha okay, good job!
01:32 < bridge> <Ewan> good morning
01:32 < bridge> <Ewan> somehow i went to bed at the same time and woke up at 4;00 pm instead of 7:00 am
02:14 < ChillerDragon> xd
02:14 < ChillerDragon> u ok ewan?
03:18 < bridge> <Ewan> Lol
03:18 < bridge> <Ewan> <https://github.com/Squirrel/Squirrel.Windows/issues/1002>
07:56 < bridge> <stnwtr> There is a thing called teewebs.net - no matter if it works atm, how is it built? Using WebRTC for an UDP connection? Or WebSockets - but using a proxy or smth?
08:16 < bridge> <Jupstar ✪> It uses web sockets
08:16 < bridge> <Jupstar ✪> And the server must support it too
08:17 < bridge> <Jupstar ✪> Also there is no udp in the web
08:17 < bridge> <Jupstar ✪> At least no raw udp
08:17 < bridge> <reitw> Quic is udp :issou:
08:23 < bridge> <stnwtr> yeah i thought maybe it uses webrtc to establish an "udp" connection to not have the tcp drawbacks
08:23 < bridge> <stnwtr> just was curious, thanks
10:59 < bridge> <robyt3> Missing image name and broken rendering in Purple Panic 2 is fixed now
11:01 < bridge> <Jupstar ✪> what was it in the end?
11:02 < bridge> <robyt3> I didn't check what was wrong with the string itself, but because it was not getting loaded, the ingame image was also not getting loaded
11:02 < bridge> <robyt3> We don't really need the name for embedded images, but I guess it's good that it was caught like this
11:02 < bridge> <Jupstar ✪> it's just interesting that this probably broken since years but apparently never caused issues ^^
11:02 < bridge> <Jupstar ✪> 
11:02 < bridge> <Jupstar ✪> lucky
11:02 < bridge> <robyt3> Yeah, we just ignored missing/broken name for embedded images
11:03 < bridge> <robyt3> If the embedded images failed to load, it might have printed garbage UTF-8 to the console
11:03 < bridge> <robyt3> Nothing more
11:03 < bridge> <Jupstar ✪> but what prevented it from load crrectly
11:03 < bridge> <Jupstar ✪> in our current version
11:03 < bridge> <robyt3> Harder validation
11:03 < bridge> <robyt3> If name not loaded -> fail to load entire image
11:03 < bridge> <Jupstar ✪> i c
11:04 < bridge> <Jupstar ✪> and do you know why patigas tool failed to detect it?
11:04 < bridge> <Jupstar ✪> i didnt follow ur convo
11:04 < bridge> <robyt3> Maybe it didn't check for broken UTF-8 yet
11:04 < bridge> <robyt3> I can investigate in what way the string was broken
11:05 < bridge> <Jupstar ✪> would maybe be useful if some editor version generated these invalid strings
11:05 < bridge> <Jupstar ✪> if patiga converts the string to a rust string it must have been checked i guess
11:05 < bridge> <robyt3> I think we are going to discover a bunch of strange maps that are generated by other editors and tools once we add more map validation
11:06 < bridge> <Jupstar ✪> yeah
11:06 < bridge> <Jupstar ✪> still i'd have thought that's what patigas tool is for xd
11:07 < bridge> <robyt3> Not sure if it checks everything, like map item versions. For example every map version item should have version 1, but there were maps that didn't have this item.
11:08 < bridge> <robyt3> The map info item also should always have version 1, but maybe another client added version 2
11:11 < bridge> <patiga> its because invalid utf-8 is wayyy too common, so I just used https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8_lossy
11:12 < bridge> <patiga> while I do try to be strict with loading, I do also want compatibility to a degree ^^
11:12 < bridge> <Jupstar ✪> wtf, why is it so common tho
11:12 < bridge> <Jupstar ✪> aren't most maps simply using english names
11:13 < bridge> <patiga> I believe there was some broken input in the past, maybe it was utf-16 or something, or local input with other symbol maps
11:14 < bridge> <patiga> and the thing is, these things get propagated further by mappers basing their maps on other maps (or appending them) to use their envelopes
11:14 < bridge> <Jupstar ✪> well but if ddnet will fail in future
11:14 < bridge> <Jupstar ✪> we should make a decision
11:15 < bridge> <patiga> we could decide to forbid saving maps with invalid utf-8
11:15 < bridge> <patiga> and maybe fix the utf-8 during loading as well as possible
11:15 < bridge> <patiga> there are a few other bugs which the twmap parser intentionally ignores
11:16 < bridge> <patiga> but the invalid-utf8 was so big that it doesn't even throw a log warning I think
11:17 < bridge> <Jupstar ✪> problem is: in my eyes a failed image means a failed map
11:17 < bridge> <Jupstar ✪> if there is invalid parts in maps we should not at all allow to continue
11:17 < bridge> <Jupstar ✪> this is always a mess to deal with
11:18 < bridge> <Jupstar ✪> currently an image fails with broken utf8
11:18 < bridge> <Jupstar ✪> the renderer is simply not built to deal with it
11:18 < bridge> <Jupstar ✪> it's not its problem
11:19 < bridge> <Jupstar ✪> if we ignore it for stirngs, we should also ignore it in ddnet again
11:19 < bridge> <Jupstar ✪> (which afai understand is not the case rn)
11:19 < bridge> <patiga> wdym here?
11:20 < bridge> <Jupstar ✪> well u kinda ignore invalid utf8
11:21 < bridge> <Jupstar ✪> but ddnet does not _anymore_
11:22 < bridge> <robyt3> Silently ignoring errors is usually a big no in code review, so validation is as strict as possible
11:22 < bridge> <patiga> what about fixing the utf-8?
11:22 < bridge> <patiga> or throwing away the string
11:22 < bridge> <robyt3> Do unicode replacement characters cause problems elsewhere though?
11:22 < bridge> <Jupstar ✪> i also prefer to catch all errors at IO time. then not all other code has to deal with it
11:22 < bridge> <Jupstar ✪> i just don't like a semi broken map
11:23 < bridge> <Jupstar ✪> either completely not load, or load
11:23 < bridge> <Jupstar ✪> as said, i don't like that the renderer has to deal with this (in theory)
11:23 < bridge> <robyt3> btw, the filename in question was `DDmaxFreezeAlpha3 weiß versuch 1` (encoded as correct ANSI, but therefore incorrect utf-8)
11:24 < bridge> <patiga> slightly, the strings get longer (because its 4 bytes long) and they breach the size limit of the string. twmap slices the string after to keep the max
11:25 < bridge> <robyt3> Always returning the checked string from the datafile directly is nice because no additional malloc/free is necessary
11:25 < bridge> <robyt3> I'll also add `GetDataStringArray` in the future, which would return `std::optional<std::vector<const char *>>`
11:26 < bridge> <patiga> note that I don't think performance considerations are necessary. my benchmarks always showed that the zlib decompression is responsible for ~95% of the cpu time
11:26 < bridge> <patiga> allocations won't make any difference I think
11:26 < bridge> <Jupstar ✪> true
11:27 < bridge> <Jupstar ✪> zlib decompression and png decompression is most time for me too
11:27 < bridge> <robyt3> Yeah, there should be a validation phase after loading the map file, where all map items that are known to the game are validated. But checking all the data at this stage would mean we load everything into memory immediately, which heinrich was also against.
11:27 < bridge> <Jupstar ✪> but additionally the mapformat sadly saves 0-tiles  (air tiles)
11:27 < bridge> <Jupstar ✪> 
11:27 < bridge> <Jupstar ✪> so gotta iterate over all tiles
11:27 < bridge> <Jupstar ✪> that sucks too xd
11:28 < bridge> <Jupstar ✪> ok but he is against anything lmao
11:28 < bridge> <robyt3> I mostly meant that the frees are annoying from API usability point of view
11:28 < bridge> <Jupstar ✪> make a parameter list of stuff that we "want" to load
11:28 < bridge> <Jupstar ✪> and only load these things
11:28 < bridge> <Jupstar ✪> ofc. we don't need the credits or smth
11:29 < bridge> <robyt3> But you also need to load the image/sound from the data immediately
11:29 < bridge> <patiga> does that actually affect performance that bad? twmpa always iterates over all tiles on map loads with checks and its still 95% decompression
11:29 < bridge> <robyt3> You wouldn't want image loading to fail later when it finds that the RGBA data was invalid
11:29 < bridge> <Jupstar ✪> yep is that a problem?
11:29 < bridge> <Jupstar ✪> i mean not like the images aren't used anyway
11:29 < bridge> <Jupstar ✪> they are loaded anyway later btw
11:29 < bridge> <Jupstar ✪> all at once
11:29 < bridge> <robyt3> Hmmm, basically you want a giant wrapper around the entire map
11:30 < bridge> <Jupstar ✪> i do that in dd-pg
11:30 < bridge> <Jupstar ✪> it still loads faster than ddnet-cpp
11:30 < bridge> <Jupstar ✪> the only thing it does additionally is having a bool list of stuff u want to load
11:30 < bridge> <Jupstar ✪> e.g. server doesn't need to load design tiles
11:30 < bridge> <Jupstar ✪> saves RAM etc.
11:31 < bridge> <robyt3> That would be checked by the map item validation
11:31 < bridge> <patiga> don't we have newer c++ versions in ddnet now? couldn't we just use some smart pointer?
11:31 < bridge> <robyt3> Each data index needs to validated as well, at which point you load the respective data
11:31 < bridge> <Jupstar ✪> why cant the validator do it on per item base?
11:31 < bridge> <robyt3> Then it's not a pure validator anymore
11:31 < bridge> <Jupstar ✪> but it validates anything we use
11:31 < bridge> <Jupstar ✪> anything else is task of the editor
11:32 < bridge> <robyt3> If it also allocates another data structure that represents the validated map, but I guess that makes the most sense
11:32 < bridge> <Jupstar ✪> we don't need a pure validator. with that argument u'd need to check all maps u'll ever download xd
11:32 < bridge> <Jupstar ✪> even if not loaded
11:33 < bridge> <robyt3> Why?
11:33 < bridge> <Jupstar ✪> ah yes
11:33 < bridge> <robyt3> As long as it's not loaded it doesn't have to be validated
11:33 < bridge> <Jupstar ✪> we should introduce a cleaner data structure anyway
11:33 < bridge> <Jupstar ✪> working with the map data directly is kinda unclean imo
11:33 < bridge> <Jupstar ✪> yes
11:33 < bridge> <Jupstar ✪> that's my argument too
11:33 < bridge> <Jupstar ✪> it sounded like u want a validator that checks the whole map
11:33 < bridge> <robyt3> yeah, it's like we have to add validation everywhere separately where the items are used. much better to have a validated wrapper class
11:34 < bridge> <Jupstar ✪> i just wanted to say:
11:34 < bridge> <Jupstar ✪> - load everything that is requested(by a bool list)
11:34 < bridge> <Jupstar ✪> - check all these things
11:34 < bridge> <Jupstar ✪> 
11:34 < bridge> <Jupstar ✪>  => we can use it safely
11:34 < bridge> <Jupstar ✪> yep i agree
11:34 < bridge> <patiga> I could offer twmap bindings :happy:
11:34 < bridge> <patiga> tho there are multiple reasons why it could be a bad fit
11:38 < bridge> <Jupstar ✪> my dd-pg is still unclean and doesn't support sound but:
11:38 < bridge> <Jupstar ✪> it basically writes everything(that is possible) into a struct
11:38 < bridge> <Jupstar ✪> 
11:38 < bridge> <Jupstar ✪> https://github.com/Jupeyy/dd-pg/blob/test5/game/shared-base/src/datafile.rs#L214-L237
11:38 < bridge> <Jupstar ✪> 
11:38 < bridge> <Jupstar ✪> then another wrapper loads all stuff it needs from above strruct:
11:38 < bridge> <Jupstar ✪> https://github.com/Jupeyy/dd-pg/blob/test5/game/client-map/src/client_map.rs#L42-L45
11:38 < bridge> <Jupstar ✪> 
11:38 < bridge> <Jupstar ✪> `render` & `upload_data` = all buffered stuff, images etc.
11:38 < bridge> <Jupstar ✪> `collision` = game layers
11:38 < bridge> <Jupstar ✪> `raw` should be private at some point probably
11:38 < bridge> <Jupstar ✪> 
11:38 < bridge> <Jupstar ✪> so it should in theory never have to deal with the original raw file
11:39 < bridge> <Jupstar ✪> i think envelops are still handled from the raw data rn ^^
11:40 < bridge> <robyt3> Are you checking `Header.m_Size` and `Header.m_Swaplen` already?
11:40 < bridge> <patiga> yea, but with compatibility with that weird error in the past
11:40 < bridge> <robyt3> ah so you already know about https://github.com/teeworlds/teeworlds/commit/3dd1ea0d8f6cb442ac41bd223279f41d1ed1b2bb ?
11:41 < bridge> <patiga> yes
11:41 < bridge> <patiga> https://gitlab.com/Patiga/twmap/-/blob/bbee11a442b891270513c3f71cb3e79fb9d41778/twmap/src/datafile/parse.rs#L164
11:41 < bridge> <robyt3> good good, that also confused me when I first added some validation for teeworlds maps
11:42 < bridge> <robyt3> https://github.com/teeworlds/teeworlds/pull/2931/files#diff-84e820ca19b13c6f72bc344f3f5018944ff97293cf394806e7781d1ddeddb0c5R187-R194
11:42 < bridge> <robyt3> Never finished testing all of this, and the chance of merging were already less than 1% before oy went perma-afk
11:42 < bridge> <patiga> what surprised me a lot was that in heinrich's map collection, many many maps fail in my parser because the zlib compression fails :thonk: 
11:42 < bridge> <patiga> not sure whats going on with those maps
11:43 < bridge> <Jupstar ✪> can u name a map?
11:43 < bridge> <patiga> lemme check
11:44 < bridge> <Jupstar ✪> and maybe also send it xd
11:44 < bridge> <Jupstar ✪> i'd really wish we could break the map format. it's so wrong xd
11:45 < bridge> <Jupstar ✪> well i'll do it anyway xd
11:46 < bridge> <patiga> I still want to revert that parallax-zoom-values-per-group change
11:46 < bridge> <Jupstar ✪> why do we even need an addon for that at all?
11:46 < bridge> <patiga> you mean why we need custom values?
11:46 < bridge> <Jupstar ✪> yes
11:46 < bridge> <patiga> I don't know actually
11:46 < bridge> <patiga> Ravie says it breaks maps
11:47 < bridge> <patiga> I have yet to see a proper example
11:47 < bridge> <Jupstar ✪> in the background?
11:47 < bridge> <patiga> I was shown a map where it would've broken visuals **if** a certain element would've had transparency
11:47 < bridge> <patiga> but the fix would've been easy
11:47 < bridge> <patiga> yes
11:47 < bridge> <Jupstar ✪> mh ok
11:48 < bridge> <patiga> Ravie's other argument was that it makes it harder to map, because you have to verify that the map looks good with and without parallax-zoom
11:48 < bridge> <Jupstar ✪> i'd argue that zoom is generally the hard part here
11:48 < bridge> <patiga> my argument there was, that we retroactively activated it on **all** maps, and it only caused a non-issue on a single map
11:49 < bridge> <patiga> https://github.com/ddnet/ddnet/issues/6196
11:53 < bridge> <Jupstar ✪> mhhhhhhhhhh
11:55 < bridge> <Jupstar ✪> i have to say i am rather confused what the current behavior of ddnet is then. it seems to only scale the first layer of the background?
11:55 < bridge> <Jupstar ✪> to me this sounds like an issue with our background zoom feature
11:55 < bridge> <Jupstar ✪> in general
11:55 < bridge> <Jupstar ✪> but i haven't thought about this enough yet
11:57 < bridge> <Jupstar ✪> maybe background is already a bad word:
11:57 < bridge> <Jupstar ✪> 
11:57 < bridge> <Jupstar ✪> we have FAR away background
11:57 < bridge> <Jupstar ✪> 
11:57 < bridge> <Jupstar ✪> and we have a "near" background
11:57 < bridge> <patiga> here are three:
11:57 < bridge> <patiga> https://heinrich5991.de/teeworlds/maps/maps/HeyYa_c17a348632a881f415ff126525cc219bd1d47d630e4b842610ce3af30cb2615c.map
11:57 < bridge> <patiga> https://heinrich5991.de/teeworlds/maps/maps/Hope_4d354ebb30623192441c370558afb99163c5ac415b6be0bc23e5f6937a571bf5.map
11:57 < bridge> <patiga> https://heinrich5991.de/teeworlds/maps/maps/Icy%20Morning_4c1030fc3b04d38fd967caedb00d7de734cae47c7f606c7019720366919d0991.map
11:57 < bridge> <Jupstar ✪> the FAR background must scale all elements
11:57 < bridge> <Jupstar ✪> ty
11:58 < bridge> <patiga> no, Fireball made a nice video to show the difference https://www.youtube.com/watch?v=W7eXQN0gRFI
11:59 < bridge> <robyt3> All of them lead to the same crash dump because the image data seems to be truncated
12:00 < bridge> <Jupstar ✪> my point is maybe a different one
12:00 < bridge> <Jupstar ✪> parallex kinda emulates depth
12:00 < bridge> <patiga> its about scaling all groups differently depending on their parallax value, to create a 'logical' zoom
12:00 < bridge> <patiga> before, only parallax x == 0 + parallax y == 0 was a special case so that it doesn't get resized on zoom, but with the new parallax-zoom, its no longer a special case but simply integrated into the general case
12:00 < bridge> <Jupstar ✪> in the background parallex 0 would basically mean scale the background to fit
12:01 < bridge> <Jupstar ✪> a completely static background would not scale at all
12:01 < bridge> <patiga> interesting. my checker only throws: `Io: corrupt deflate stream`
12:01 < bridge> <patiga> exatly, it is infinitely far away, so moving the camera back and fourth doesn't change its size
12:02 < bridge> <Jupstar ✪> and you cannot calculate that mathematically?
12:02 < bridge> <Jupstar ✪> without an extra item?
12:02 < bridge> <patiga> yes, thats also how its done
12:02 < bridge> <patiga> if the value is not changed, its simply `max(parallax.x, parallax.y)`
12:03 < bridge> <patiga> and those are also the values the editor writes on new maps
12:03 < bridge> <patiga> but the values are editable for some reason
12:03 < bridge> <robyt3> The client also prints `datafile: uncompress error. result=-3 wanted=4194304 got=4173556` because zlib fails, but we don't check in other places if the image data was loaded and has the correct size
12:03 < bridge> <Jupstar ✪> yeah that's weird.
12:03 < bridge> <Jupstar ✪> 
12:03 < bridge> <Jupstar ✪> But generally, we isn't this simply default behavior for all maps?
12:03 < bridge> <patiga> it is the default behavior
12:03 < bridge> <Jupstar ✪> why a new map item
12:04 < bridge> <patiga> ah, yes
12:04 < bridge> <patiga> thats also my question
12:04 < bridge> <patiga> I want that reverted currently
12:04 < bridge> <patiga> (since like a year or so)
12:04 < bridge> <Jupstar ✪> yes
12:04 < bridge> <Jupstar ✪> what happens if the map item misses?
12:04 < bridge> <Jupstar ✪> does it not do any logical scale?
12:04 < bridge> <patiga> ah its actually `clamp(max(parallax.x, parallax.y), 0, 100)`
12:05 < bridge> <patiga> it simply calculates the value normally
12:05 < bridge> <Jupstar ✪> mh ok
12:05 < bridge> <patiga> which I think is the correct behavior
12:05 < bridge> <Jupstar ✪> i get the same err xd
12:05 < bridge> <patiga> just calculate the value
12:06 < bridge> <Jupstar ✪> wait ok, but if it's not missing and u didn't explicitly change it in the editor, it's the same value basically?
12:06 < bridge> <patiga> are you also using the system zlib?
12:06 < bridge> <patiga> yes
12:06 < bridge> <Jupstar ✪> i use deflate crate
12:07 < bridge> <Jupstar ✪> yeah then i guess it makes sense to not have it, except that guy that implemented it shows clear evidence that the math is wrong
12:07 < bridge> <patiga> where? please show an example where its wrong. was the timeshop map actually changed?
12:07 < bridge> <Jupstar ✪> well that is my question too
12:08 < bridge> <Jupstar ✪> your issue is rather long
12:08 < bridge> <Jupstar ✪> did he reply with anything?=
12:08 < bridge> <patiga> yes
12:08 < bridge> <Jupstar ✪> anything useful i mean xd
12:08 < bridge> <patiga> https://github.com/ddnet/ddnet/issues/6196#issuecomment-1407683058
12:08 < bridge> <patiga> not sure what you consider useful ^^
12:09 < bridge> <patiga> I'd say at this point that I'll quickly check with python which map has parallax zoom on non-default values
12:09 < bridge> <patiga> but twmap doesn't parse that :d
12:10 < bridge> <patiga> (see `Why the value is complicated to handle right now` in my discussion issue)
12:10 < bridge> <Jupstar ✪> he claims timeshop uses non default?
12:12 < bridge> <patiga> the timeshop map up on ddnet servers does not use custom values, no
12:12 < bridge> <Jupstar ✪> interesting xd
12:12 < bridge> <patiga> (cool map btw)
12:12 < bridge> <patiga> maybe Fireball confused some stuff from early testing
12:13 < bridge> <Jupstar ✪> well anyway, i don't even remember why we got to this feature, but yeah, best is good default behavior xd
12:14 < bridge> <patiga> if you want you could give a +1 on that issue or smth, I don't think I can really push it harder with just my own opinion
12:20 < bridge> <patiga> @robyt3 do you have an opinion on parallax zoom?
12:21 < bridge> <robyt3> Haven't looked at it in detail. I suppose you could push harder by opening a PR with your proposed changes
12:21 < bridge> <Jupstar ✪> @patiga did u already try out egui xd
12:21 < bridge> <patiga> no ^^
12:21 < bridge> <patiga> fair point
12:28 < bridge> <Jupstar ✪> @patiga what would be the biggest thing for you to change in the map format?
12:30 < bridge> <patiga> hmm, I always liked your idea of adding shaders
12:30 < bridge> <patiga> otherwise: switch the compression method with a much quicker one?
12:30 < bridge> <patiga> I haven't given it much thought tbh
12:30 < bridge> <patiga> add quad scaling to envelopes
12:30 < bridge> <Jupstar ✪> that was voxels idea xd
12:30 < bridge> <patiga> @_voxeldoesart gud idea
12:31 < bridge> <Jupstar ✪> shaders would be cool, but uncontrolled code execution
12:31 < bridge> <Jupstar ✪> uncontrolled by us at least
12:31 < bridge> <patiga> hm yea
12:32 < bridge> <patiga> lets invent a new shading language :brownbear:
12:32 < bridge> <Jupstar ✪> yeah compression 100% agree
12:32 < bridge> <Jupstar ✪> and don't compress image data directly into the map format
12:32 < bridge> <Jupstar ✪> xd
12:32 < bridge> <patiga> at least save it as png or smth, not weird zlib
12:32 < bridge> <Jupstar ✪> yep
12:32 < bridge> <Jupstar ✪> and i'd love to have the ability to set the clamp mode for quads
12:33 < bridge> <Jupstar ✪> i really dislike that mappers have to use an offset for the texture coordinates
12:33 < bridge> <ryozuki> ```rust
12:33 < bridge> <ryozuki>                 fn R (t:f32, mut x:
12:33 < bridge> <ryozuki>             f32,mut y:f32)->(f32,f32,){
12:33 < bridge> <ryozuki>          let mut f=x;x-=t*y;y+=t*f;f=(3.-x
12:33 < bridge> <ryozuki>        *x-y*y)/2.;(x*f,y*f)}fn main() {let(
12:33 < bridge> <ryozuki>      mut x,mut y,mut o,mut N); let mut z:[f32;
12:33 < bridge> <ryozuki>     1760];let mut a:f32=0.;let mut e:f32=1.;let
12:33 < bridge> <ryozuki>   mut c:f32=1.;let mut d:f32=0.;let (mut g,mut h,
12:33 < bridge> <ryozuki>   mut G,mut H,mut A,mut t,mut D);let(mut b):[char
12:33 < bridge> <ryozuki>  ;1760];loop{(z)=[0.;         1760];(g,h)=(0.,1.);
12:33 < bridge> <ryozuki> b=[' ';1760];for TJ             in 0..90{(G,H)=(0.,
12:33 < bridge> <ryozuki> 1.0);for M in 0..                 314{A=h+2.0;D=1./
12:33 < bridge> <ryozuki> (G*A*a+g*e+5.);t=                 (G*A*e)-(g*a);x=(
12:33 < bridge> <ryozuki> 40.0+(30.0*D*(H*A                 *d-t*c)))as i32;y
12:33 < bridge> <ryozuki> =(12.0+(15.*D*(H*                 A*c+t*d)))as i32;
12:33 < bridge> <ryozuki> o=x+(80*y);N=(8.*                 (((g*a-G*h*e)*d)-
12:33 < bridge> <ryozuki> G*h*a-g*e-H*h*c))as             i32;if 0<y&&y<22&&0
12:33 < bridge> <ryozuki>  <x&& x<80&& D>z[o as         usize]{z[o as usize]
12:33 < bridge> <ryozuki>   =D;b[o as usize]=b".,-~:;=!*#$@"[if N >0{N as//
12:33 < bridge> <ryozuki>   usize}else{0}]as char}(H,G)=R(0.02,H,G);}(h,g)=
12:34 < bridge> <ryozuki>     R(0.07,h,g);}for k in 0..=1760{print!("{}",
12:34 < bridge> <ryozuki>      if k%80!=0{b[k]}else{'\n' as char})}(e,a)
12:34 < bridge> <ryozuki>        =R(0.04,e,a);(d,c)=R(0.020,d,c);std::
12:34 < bridge> <ryozuki>          thread::sleep(std::time::Duration
12:34 < bridge> <ryozuki>             ::from_millis(015));print!(
12:34 < bridge> <ryozuki>                 "\x1b[23A");}}//TJ!
12:34 < bridge> <ryozuki> ```
12:34 < bridge> <ryozuki> valid rust
12:34 < bridge> <patiga> hm, couldn't the editor be improved to somewhat fix that? noone would notice a 1-pixel offset
12:34 < bridge> <Jupstar ✪> the problem is, that this is still not really fixable, considering that different mipmaps have different texture sizes
12:34 < bridge> <Jupstar ✪> a 10x10 texture would require a 1/10 offset
12:34 < bridge> <patiga> we could also save the tilemap layers as png :feelsamazingman:
12:34 < bridge> <patiga> (except for speedup)
12:34 < bridge> <Jupstar ✪> xd
12:34 < bridge> <patiga> well who needs a differently sampled 10x10 texture, honestly :p
12:34 < bridge> <Jupstar ✪> what does it calculate @ryozuki
12:35 < bridge> <ryozuki> https://www.reddit.com/r/rust/comments/17io61g/donutc_now_in_rust/
12:35 < bridge> <ryozuki> https://github.com/EvanZhouDev/TheDonutProject
12:35 < bridge> <ryozuki> > This all started with donut.c, the classic C code that looks like, and generates a 3D spinning donut when run. Out of sheer curiosity, I searched up this code in different languages, and noticed that many people have created 3D spinning donuts in those languages... but their code mostly didn't look like a donut.
12:35 < bridge> <Jupstar ✪> my point is rather that the mipmap would leak other texels
12:36 < bridge> <Jupstar ✪> e.g. u have a 1000x1000 image in the editor
12:36 < bridge> <Jupstar ✪> 
12:36 < bridge> <Jupstar ✪> so the editor adds 1/1000 as offset
12:36 < bridge> <Jupstar ✪> 
12:36 < bridge> <Jupstar ✪> when zooming out tho, it would not work bcs the mipmap might be 10x10
12:36 < bridge> <Jupstar ✪> 1/1000 on a 10x10 would bleed
12:36 < bridge> <patiga> if you haven't yet you could try out if https://crates.io/crates/cloudflare-zlib improves your map loading :D
12:36 < bridge> <Jupstar ✪> is it rust only?
12:37 < bridge> <patiga> doesn't look like it, C
12:37 < bridge> <heinrich5991> does adding shaders bind us to a certain standard like opengl or vulkan, unable to change away from that? or is it even worse?
12:37 < bridge> <patiga> but SIMD-accelerated, must be good :p
12:37 < bridge> <Jupstar ✪> yeah ^^
12:37 < bridge> <Jupstar ✪> but i guess my map loading is ok now
12:37 < bridge> <Jupstar ✪> <1s for biggest ddnet map
12:37 < bridge> <patiga> yup, you'd need to select a shading language
12:38 < bridge> <patiga> there are transpilers
12:38 < bridge> <patiga> but yea, that makes it difficult
12:39 < bridge> <patiga> https://crates.io/crates/naga appears to be a good tool for shader translation
12:39 < bridge> <Jupstar ✪> mhh
12:39 < bridge> <Jupstar ✪> i used it xd
12:39 < bridge> <Jupstar ✪> it's very unfinished still sadly
12:39 < bridge> <patiga> ow :c
12:39 < bridge> <patiga> how so?
12:39 < bridge> <Jupstar ✪> i tried GLSL to spir-v
12:39 < bridge> <heinrich5991> is there some subset shader language that is supported by all graphic APIs?
12:40 < bridge> <patiga> ah, naga and not that cloudflare thingy
12:40 < bridge> <heinrich5991> (and would thus likely be supported in the future as well)
12:40 < bridge> <Jupstar ✪> it has missing features like push-constants
12:40 < bridge> <Jupstar ✪> and generally seems to use a syntax that is closer to HLSL than GLSL xd
12:40 < bridge> <patiga> that is what wgsl tries to be
12:40 < bridge> <Jupstar ✪> vulkan only supports spir-v
12:40 < bridge> <patiga> which is made for webgpu
12:40 < bridge> <Jupstar ✪> nothing else
12:40 < bridge> <patiga> (but can be translated to from wgsl for example)
12:40 < bridge> <heinrich5991> maybe you can compile wgsl to spir-v?
12:40 < bridge> <heinrich5991> ah
12:41 < bridge> <heinrich5991> wgsl seems quite new though, 2021
12:41 < bridge> <heinrich5991> will it still be around in ten years?
12:41 < bridge> <patiga> I don't know
12:41 < bridge> <Jupstar ✪> i guess it's the opposite
12:41 < bridge> <Jupstar ✪> it will be around in 10years XD
12:42 < bridge> <Jupstar ✪> when browsers finally support it to 100%
12:42 < bridge> <patiga> https://en.wikipedia.org/wiki/WebGPU @heinrich5991 the big players seem to be onboard
12:43 < bridge> <heinrich5991> > WebGPU is the working name for a potential web standard and JavaScript API for accelerated graphics and compute, aiming to provide "modern 3D graphics and computation capabilities".
12:43 < bridge> <heinrich5991> sounds good indeed. it might be better to wait until it's a standard so it doesn't change anymore
12:44 < bridge> <Jupstar ✪> the biggest problem is that it still relies on safe drivers to a certain extend
12:45 < bridge> <heinrich5991> ah, it's a security vulnerability? ^^
12:45 < bridge> <heinrich5991> probably a lot more than loading a png
12:45 < bridge> <Jupstar ✪> well i wouldn't say it is
12:45 < bridge> <heinrich5991> if we're executing code
12:45 < bridge> <Jupstar ✪> yes
12:45 < bridge> <Jupstar ✪> https://www.khronos.org/webgl/security/
12:45 < bridge> <Jupstar ✪> 
12:45 < bridge> <Jupstar ✪> e.g. they specify what webgl has to check
12:45 < bridge> <patiga> Jupstar when you don't have 20,000 fps: :cammostripes:
12:45 < bridge> <Jupstar ✪> so the browser might do all this
12:45 < bridge> <Jupstar ✪> but still doesn't mean the driver itself isn't exploitable
12:46 < bridge> <Jupstar ✪> that's not even my point here ^^
12:46 < bridge> <patiga> ah xd
12:46 < bridge> <Jupstar ✪> i managed to crash my PC with webgl2
12:46 < bridge> <Jupstar ✪> that doesn't directly mean it's unsafe
12:46 < bridge> <Jupstar ✪> but at least concerning xD
12:46 < bridge> <heinrich5991> well, DoS by making the machine crash is also a security vulnerability ^^
12:47 < bridge> <heinrich5991> but yea, wgsl seems like the thing we'd need in order to enable shaders for maps
12:48 < bridge> <Jupstar ✪> https://security.stackexchange.com/a/13840
12:48 < bridge> <Jupstar ✪> random stackoverflow answer
12:48 < bridge> <heinrich5991> spir is an abbreviation just like llvm 😄
12:49 < bridge> <Jupstar ✪> note also webgpu is MUCH more powerful than webgl
12:49 < bridge> <Jupstar ✪> i only quote webgl here xd
12:49 < bridge> <Jupstar ✪> "Browsers have responded to this with a variety of defenses: they have blacklisted video cards with known security problems; they have tried to fix the known memory safety problems; and they have restricted use of WebGL per the same-origin policy, to prevent a malicious web site from using WebGL to spy on users' use of other web sites."
12:50 < bridge> <Jupstar ✪> this alone sounds like a hard to manage thing
12:50 < bridge> <heinrich5991> yea
12:50 < bridge> <heinrich5991> sounds like the code would need to be approved before being run in the client
12:51 < bridge> <heinrich5991> 2013 microsoft: https://web.archive.org/web/20130602040650/https://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx?Redirected=true
12:51 < bridge> <heinrich5991> (from the so answer)
12:58 < bridge> <Jupstar ✪> i guess wgsl with a limited subset of features could work out
12:58 < bridge> <Jupstar ✪> 
12:58 < bridge> <Jupstar ✪> but in the end there is always a risk, even if u just write a endless loop or stuff like that, which is not in our control anymore (or the wgls converter)
13:00 < bridge> <patiga> what happens if a shader runs into an endless loop btw?
13:01 < bridge> <Jupstar ✪> i dunno
13:01 < bridge> <Jupstar ✪> 
13:01 < bridge> <Jupstar ✪> i can just say that i managed to crash my PC, by spamming many draw instances XD
13:02 < bridge> <heinrich5991> do shaders allow for loops?
13:02 < bridge> <Jupstar ✪> yeah
13:02 < bridge> <Jupstar ✪> shaders are kinda just mini programs
13:02 < bridge> <Jupstar ✪> without direct memory allocation access etc.
13:03 < bridge> <Jupstar ✪> i mean always depends on the graphics library, but spir-v is also used for the compute shaders
13:18 < bridge> <learath2> Interesting that they aren’t limited to provably finite loops like eBPF
13:19 < bridge> <Jupstar ✪> i mean if u do a 
13:19 < bridge> <Jupstar ✪> for i in 0..u64::MAX
13:19 < bridge> <Jupstar ✪> would u say this is a finite loop?
13:19 < bridge> <Jupstar ✪> strictly speaking yes
13:20 < bridge> <heinrich5991> matricks wanted to create a scripting language that provably terminates (in reasonable time)
13:21 < bridge> <heinrich5991> loops would have been forbidden, you'd be allowed to iterate only over certain arrays
13:21 < bridge> <heinrich5991> IIRC
13:21 < bridge> <Jupstar ✪> but can u iterate over arrays of arrays xd
13:21 < bridge> <Jupstar ✪> or the same array twice
13:21 < bridge> <Jupstar ✪> nested
13:22 < bridge> <learath2> Yeah, but iirc eBPF also limits the amount of times you can loop, it’s a very rough time limit
13:22 < bridge> <Jupstar ✪> anyway shaders are not really limited at all and that's not really their idea. the limits they have are simply to fit the idea of a graphics pipeline and high parallelism
13:22 < bridge> <heinrich5991> probably not, or only twice deep
13:22 < bridge> <heinrich5991> or something like that
13:27 < bridge> <Jupstar ✪> anyway, before it sounds like i want to prevent that feature. i just want to make clear there are certain things i'd find concerning.
13:27 < bridge> <Jupstar ✪> 
13:28 < bridge> <Jupstar ✪> If we disable loops etc. at some point u can also not use shaders but parameters to alter the rendering xd
13:28 < bridge> <Jupstar ✪> or human proof the shaders, before maps are released or smth
13:30 < bridge> <_voxeldoesart> :brownbear:
13:31 < bridge> <patiga> yea a growing set of 'official' shaders with configurable parameters also sounds nice
13:31 < bridge> <_voxeldoesart> what type of shaders r u thinking
13:32 < bridge> <patiga> well any, I guess ^^
13:32 < bridge> <patiga> textures, materials, post-processing
13:32 < bridge> <patiga> get particles into it somehow
13:32 < bridge> <patiga> dunno which ones ares the most important
13:33 < bridge> <_voxeldoesart> ooh yea ive always wanted a particles system
13:34 < bridge> <_voxeldoesart> https://cdn.discordapp.com/attachments/1009728757512278116/1039792177456353321/image.png?ex=654b2ded&is=6538b8ed&hm=932010431f257f4b22e47e6f6042e44d735ef9a887b032836f8a0144d693dde2&
13:34 < bridge> <_voxeldoesart> old partocle generator idea
13:34 < bridge> <_voxeldoesart> old particle generator idea
13:35 < bridge> <_voxeldoesart> what u could see and place in a map
13:35 < bridge> <_voxeldoesart> link it to an image n stuff
13:36 < bridge> <_voxeldoesart> smoke type goes up and is interactive
13:36 < bridge> <_voxeldoesart> spew type acts like a lil cannon
13:37 < bridge> <Jupstar ✪> is that even a shader xd
13:37 < bridge> <Jupstar ✪> sounds like u want custom physics
13:39 < bridge> <_voxeldoesart> oh
13:39 < bridge> <_voxeldoesart> tbh anything works at this point
13:39 < bridge> <_voxeldoesart> ddnet maps Need something new like this
13:40 < bridge> <robyt3> Particle system already exists, it's just disabled. Would be cool to enabled it again and add particle emitters as map tiles
13:40 < bridge> <robyt3> Particle flow system already exists, it's just disabled. Would be cool to enabled it again and add particle emitters as map tiles
13:42 < bridge> <Jupstar ✪> i wish i could show some stuff, but i am not far enough yet
13:42 < bridge> <Jupstar ✪> 
13:42 < bridge> <Jupstar ✪> but generally i'd allow with the WASM runtime to even change client side graphics on a per server basis. so there wouldn't be any limiations on what you can change.
13:42 < bridge> <Jupstar ✪> 
13:42 < bridge> <Jupstar ✪> but similar to shaders i'd only allow this if human prooved
13:44 < bridge> <Jupstar ✪> it also wouldn't be required to be added to the code base, so no bloating xd
13:45 < bridge> <_voxeldoesart> u know what would also be cool? envelope logic
13:46 < bridge> <_voxeldoesart> like, have envelopes that loop or just play once
13:46 < bridge> <_voxeldoesart> add tunes that start, stop and play certain envelopes
13:46 < bridge> <patiga> the only sad thing about such envelopes is that spectating multiple teams wouldn't really work with them, or solo parts
13:46 < bridge> <Ewan> good morning
13:46 < bridge> <patiga> just like switches also don't interact well with solo parts
13:49 < bridge> <patiga> loop/play once is interesting, I guess you can do play once already, by placing an env point at like 1 day or smth
13:49 < bridge> <patiga> (and loop is the default)
13:50 < bridge> <_voxeldoesart> yeah
13:52 < bridge> <_voxeldoesart> another spitball idea: different sounds for different textures
13:52 < bridge> <Jupstar ✪> materials
13:52 < bridge> <_voxeldoesart> grass hook noises, alongside stone, metal, stuff like that
13:52 < bridge> <_voxeldoesart> yea
13:52 < bridge> <Jupstar ✪> good
13:53 < bridge> <Jupstar ✪> learn rust and join robyte & me team or patiga & zwelf's team
13:56 < bridge> <_voxeldoesart> whats rust gotta do with that
13:58 < bridge> <Ewan> sounds like they are using rust 😃
13:58 < bridge> <Jupstar ✪> smone gotta code these features
13:58 < bridge> <Ewan> jupstar carry me in gores
13:58 < bridge> <cyberFighter> diep.io
13:58 < bridge> <Jupstar ✪> k
13:58 < bridge> <_voxeldoesart> well i dont know how to code low level
13:59 < bridge> <_voxeldoesart> i can provide concept art n stuff tho
13:59 < bridge> <_voxeldoesart> yea
13:59 < bridge> <Jupstar ✪> k
14:00 < bridge> <Ewan> i like this map very aesthetic
14:00 < bridge> <Ewan> https://cdn.discordapp.com/attachments/293493549758939136/1168172410051248229/image.png?ex=6550cc56&is=653e5756&hm=ca6b226166fd7cf5445e5b8a8a2647c929f6519b5c778d4881b3348e1698d507&
14:00 < bridge> <Jupstar ✪> @patiga what r u workn on rn
14:00 < bridge> <Jupstar ✪> how can i find u ingame
14:00 < bridge> <Ewan> Ewan
14:00 < bridge> <Ewan> 😃
14:00 < bridge> <Jupstar ✪> i dont have account
14:00 < bridge> <Jupstar ✪> xd
14:00 < bridge> <Ewan> o u wanna play ddrace
14:01 < bridge> <Jupstar ✪> no
14:01 < bridge> <Jupstar ✪> just have no kog acc yet
14:01 < bridge> <patiga> @jupeyy_keks this
14:01 < bridge> <Ewan> :nouis:
14:01 < bridge> <Jupstar ✪> work on ddnet-next instead xds
14:01 < bridge> <Jupstar ✪> work on ddnet-next instead xd
14:01 < bridge> <patiga> :p
14:01 < bridge> <Ewan> all ger servers are account servers :justatest:
14:02 < bridge> <Jupstar ✪> 74.91.114.169:8303
14:02 < bridge> <DDNet> 74.91.114.169:8303 appears to be a KoG server. DDNet and KoG aren't affiliated. 
14:02 < bridge> <DDNet> Join their discord and ask for help there instead. <https://discord.kog.tw/>
14:02 < bridge> <Ewan> ok sec
14:07 < bridge> <_voxeldoesart> cant wait for mirror materials in ddnet
14:07 < bridge> <_voxeldoesart> so u can walk past one n stuff
14:09 < bridge> <_voxeldoesart> i imagine they'd be like, tiles so that its easier to manage
14:10 < bridge> <_voxeldoesart> if u want custom shapes u can overlay graphics over them
14:53 < bridge> <_ilovesuicide_> i tried suicide 3 times and nothing
15:42 < ChillerDragon> i can open demos in my downloads folder via file manager gui "open with" is there a cli alternative for that?
15:42 < bridge> <Jupstar ✪> ./DDNet name.demo
15:43 < ChillerDragon> i tried
15:43 < bridge> <Jupstar ✪> but
15:43 < ChillerDragon> it just open ddnet
15:43 < bridge> <Jupstar ✪> mhh
15:43 < bridge> <Jupstar ✪> surprising
15:43 < ChillerDragon> yea i thought stuff like that works in modern 2023 ddnet
15:43 < ChillerDragon> maybe im doing something wrong
15:43 < bridge> <learath2> It does, your computer broken
15:43 < ChillerDragon> ok
15:43 < ChillerDragon> i go buy new
15:43 < bridge> <learath2> Install windings, is much better
15:43 < ChillerDragon> wat windings
15:44 < bridge> <Jupstar ✪> windoof
15:44 < bridge> <Jupstar ✪> hööhhö
15:44 < ChillerDragon> a
15:44 < ChillerDragon> wait does it work for you guys?
15:44 < bridge> <learath2> I can even drag demos onto my ddnet shortcut, superior os
15:44 < ChillerDragon> i can probably too? maybe
15:44 < bridge> <Jupstar ✪> i think i've opened demos like that
15:44 < bridge> <Jupstar ✪> in fact our benchmark does that
15:45 < ChillerDragon> axaxax works in chilerbot
15:45 < bridge> <robyt3> if you drag the demo onto the file it passes the absolute path, which should work
15:46 < bridge> <robyt3> if you drag the demo onto ddnet it passes the absolute path, which should work
15:46 < ChillerDragon> idk wat cracklord version my DDNet in path is 
15:46 < ChillerDragon> a nvm
15:46 < ChillerDragon> it was the demo name
15:46 < ChillerDragon> seems like it cant do spaces
15:46 < bridge> <robyt3> if you use a relative path then it has to be in your storage, also it has to include the `demos` folder
15:46 < bridge> <robyt3> you need "" to escape paths with spaces
15:46 < ChillerDragon> always these windows users and their spaces in filenames
15:46 < ChillerDragon> i know how to use bash -.-
15:46 < ChillerDragon> it didnt eat it
15:47 < ChillerDragon> does it work for u?
15:47 < ChillerDragon> wait now it does
15:47 < ChillerDragon> im confused af
15:47 < bridge> <robyt3> which command line are you using?
15:48 < ChillerDragon> bash
15:48 < ChillerDragon> wait i can reproduce again i restored old filename
15:48 < bridge> <robyt3> and the command you are running including the argument?
15:49 < ChillerDragon> ``DDNet team\ bug.demo``
15:49 < bridge> <robyt3> Does it work with escaping the space?
15:49 < ChillerDragon> yes
15:49 < ChillerDragon> its same as ``DDNet 'team bug.demo'`` if it makes you nervouse
15:50 < ChillerDragon> neither work
15:50 < ChillerDragon> idk im stupid rn
15:50 < ChillerDragon> i managed to play "a a.demo"
15:50 < ChillerDragon> lemme try and error for a sec
15:50 < ChillerDragon> ah maybe because it starts with "team 
15:50 < ChillerDragon> and thats a ddnet command
15:51 < ChillerDragon> yea pretty sure thats it
15:51 < ChillerDragon> i still blame the windows user that sent me a demo containing a space for that :p 
15:51 < ChillerDragon> but the ddnet client could also not troll in that case
15:52 < bridge> <robyt3> In git bash it works with `./ddnet "C:\absolute\path\test 123.demo"`
15:52 < ChillerDragon> not test 123.demo
15:52 < ChillerDragon> do "team 123.demo"
15:53 < bridge> <robyt3> Also works, why would that make a difference?
15:53 < ChillerDragon> the file exists check should probably be before the is a command check
15:53 < ChillerDragon> i assume it runs the command ``team`` with "123.demo" as arg and calls it a day
15:53 < bridge> <robyt3> You are not passing an absolute path, are you?
15:53 < ChillerDragon> no
15:53 < ChillerDragon> relative
15:53 < bridge> <robyt3> Well
15:53 < bridge> <robyt3> How should the game find your file then?
15:54 < ChillerDragon> it works well for me
15:54 < bridge> <robyt3> Relative path works if the file is in a storage location
15:54 < ChillerDragon> idk how ddnet does it i assume it also checks relative
15:54 < ChillerDragon> yea $currentdir
15:54 < ChillerDragon> should be there in a vanilla storage.cfg
15:54 < ChillerDragon> works wonderfully for me
15:55 < ChillerDragon> unless it starts with a valid ddnet command
15:55 < ChillerDragon> u get what im saying right?
15:55 < bridge> <robyt3> Interesting, I can reproduce it
15:56 < ChillerDragon> this quits my client ``DDNet "quit game.demo"`` and this plays a demo ``DDNet "game quit.demo"`` 
15:56 < bridge> <robyt3> Workaround: use play command instead
15:56 < bridge> <robyt3> I'm not sure it's solveable easily
15:57 < ChillerDragon> play command is pain to quote its almost slower than opening ui
15:57 < bridge> <robyt3> The way it works is that we register an "unknown command handler" for the console temporarily, but because `team 123.demo` is not an unknown command it doesn't reach it
15:57 < ChillerDragon> yea if its pain to fix it dont its an edge case
15:57 < ChillerDragon> i just insult the user who sent me the demo and call it a day
15:58 < bridge> <robyt3> We previously tried to check if the command line argument and in `.demo` but that breaks on other edge cases
15:58 < bridge> <robyt3> We previously tried to check if the command line argument end in `.demo` but that breaks on other edge cases
15:58 < ChillerDragon> yea thats not better
15:59 < ChillerDragon> it should check if the file exist if it does then check the ending if its map use it as map if its demo use it as demo. And otherwise fallback to interpreting it as commands.
15:59 < ChillerDragon> seems doable
16:00 < ChillerDragon> just run that check in the very beginning before any command handler. Only if argc is 1
16:00 < bridge> <robyt3> Could get a bit weird. If you open the client with `./DDNet "play my.demo"` should it execute `play my.demo` or open the demo `play my.demo`
16:01 < bridge> <robyt3> Assuming both demos exist
16:01 < ChillerDragon> also TIL that the commands are case insenstive. I assumed ``Team`` to not match the ``team`` command
16:01 < ChillerDragon> oh yea you are right
16:02 < ChillerDragon> i guess my gui open with expands the path and thats why it worked on the demo
16:03 < bridge> <robyt3> yeah, GUIs should pass the absolute path, so it should only be an issue for edge cases in the CLI
16:04 < ChillerDragon> yea cli users will manage (he said after asking for help in #developer and being confused for 10minutes xd)
16:04 < ChillerDragon> but in general i can see demos matching that pattern quite often since there are so many one word commands and all the windows users love spaces and it even matches case insensitive
16:05 < bridge> <robyt3> `DDNet.exe ./team\ 123.demo` with `./` also works
16:06 < ChillerDragon> well neither my bash nor my zsh tab completion expands the ./ so i would have to manually type ./ :c 
16:06 < ChillerDragon> but yea much better workaround than using the play command :)
16:06 < bridge> <robyt3> That's where remappable keyboard key come into play :justatest:
16:07 < ChillerDragon> lmao
16:07 < ChillerDragon> i rather fork bash before i remap my keyboard
16:07 < ChillerDragon> or fork readline i guess its not even bash who handles that is it?
16:08 < ChillerDragon> there is probably hooks for it
16:08 < ChillerDragon> windows does that if i remember correctly
16:08 < ChillerDragon> you do foo<tab> and it gives your the .\foo.ps1
16:09 < bridge> <robyt3> yeah, seems like it works that way in PowerShell but not in Bash
16:09 < ChillerDragon> omg my windows knowledge is top tier
16:10 < bridge> <Ewan> Q
16:13 < ChillerDragon> uhm can you turn off teams in the autoexec.cfg?
16:13 < ChillerDragon> i never bothered to figure out and always edited the default in the code or added it to map settings
16:13 < bridge> <nouaa> Ye
16:13 < ChillerDragon> how?
16:13 < bridge> <nouaa> sv_team
16:13 < bridge> <nouaa> or sv_teams
16:13 < bridge> <nouaa> sv_team 0
16:13 < bridge> <nouaa> BUT
16:14 < ChillerDragon> in the autoexec.cfg without config reload?
16:14 < bridge> <nouaa> It forces it to 0 in the src code somewhere
16:14 < ChillerDragon> 0 is what i want xd
16:14 < ChillerDragon> i cant get it off
16:14 < bridge> <nouaa> Ah, 1*
16:15 < ChillerDragon> yea so adding ``sv_team 0`` does not work that much i know
16:15 < ChillerDragon> but what is the clean way to set it then?
16:15 < ChillerDragon> editing the map is not an option
16:15 < bridge> <nouaa> you need to do smth in gamecontext.cpp afaik
16:16 < bridge> <nouaa> It's called ddrace options or sum
16:16 < ChillerDragon> in the code? fr
16:16 < bridge> <nouaa> Y
16:16 < ChillerDragon> cant i set it in my config somehow -.-
16:17 < bridge> <heinrich5991> you can set it in the reset file or in the map config
16:17 < bridge> <heinrich5991> if I read the source code correctly
16:18 < bridge> <nouaa> Can you send the part where it does that?
16:19 < ChillerDragon> ok lemme try putting it in reset.cfg
16:19 < bridge> <heinrich5991> https://github.com/ddnet/ddnet/blob/110247f08f87392c883cc2c266125f11cab96de0/src/game/server/gamecontext.cpp#L3573-L3582
16:25 < bridge> <ryozuki> https://udoprog.github.io/rust/2023-10-28/stop-worrying.html
16:26 < ChillerDragon> works thanks for reading the code when im too lazy to do it @heinrich5991 i hoped someone would know already
18:14 < bridge> <blade67> Since when does DDRace have moving freeze tiles?
18:14 < bridge> <teero777> how do i convert uint to hsla :pepeW:
18:15 < bridge> <blade67> uint *what*?
18:15 < bridge> <teero777> it doesnt. its kog specific
18:15 < bridge> <blade67> Ah! Gotcha
18:15 < bridge> <teero777> unsigned int 32 to HSLA color format
18:15 < bridge> <teero777> im sure there is some function for that in ddnet code but i cant find it
18:15 < bridge> <blade67> 1 byte per value
18:16 < bridge> <robyt3> Either the color constructors or `UnpackAlphaLast`
18:16 < bridge> <blade67> Didn't dive directly into the code in a long while so unsure if there already is
18:16 < bridge> <blade67> Roby here to save the day!
18:16 < bridge> <robyt3> `UnpackAlphaLast` is for HSLA/RGBA, the constructors use AHSL, ARGB
18:18 < bridge> <blade67> I assume this is used for the skin colors? Since images are RGB/RGBA
18:19 < bridge> <robyt3> Skins colors are saved in AHSL format, editor saves colors in RGBA
18:19 < bridge> <blade67> Weird inconsistency
18:20 < bridge> <blade67> I mean it does kind of make sense given that skin colors are modulated and not set
18:20 < bridge> <robyt3> Skins are also weird because they don't use the full L-value for HSL
18:21 < bridge> <blade67> Is that only a limit set by the game's slider or is that actually limited in the code?
18:21 < bridge> <robyt3> Should be limited in code when the colors are received by clients, otherwise we would have more players with completely black skins running around
18:22 < bridge> <blade67> I do remember that being a think way back in the day
18:22 < bridge> <blade67> Like, 0.5 time
18:22 < bridge> <blade67> Rainbow skins too, although I assume these are still around
18:24 < bridge> <teero777> sadly not bcs of info change delay on servers
18:24 < bridge> <blade67> Oh, oh well, it is what it is
19:15 < bridge> <teero777> im so confused.
19:15 < bridge> <teero777> ```cpp
19:15 < bridge> <teero777>         RenderInfo.m_ColorBody = color_cast<ColorRGBA>(ColorHSLA(g_Config.m_ClPlayerColorBody));
19:15 < bridge> <teero777>         dbg_msg("Players.cpp", "%d == %f,%f,%f,%f", g_Config.m_ClPlayerColorBody, RenderInfo.m_ColorBody.r, RenderInfo.m_ColorBody.g, RenderInfo.m_ColorBody.b, RenderInfo.m_ColorBody.a);
19:15 < bridge> <teero777> ```
19:15 < bridge> <teero777> why would the rgb values always be 0 no matter that the body color is?
19:35 < bridge> <burnyllama> When I try to compile DDNet I get this error (main/master branch):
19:35 < bridge> <burnyllama> ```
19:35 < bridge> <burnyllama> -- Building vulkan shaders
19:35 < bridge> <burnyllama> /home/USER/Development/ddnet/data/shader/vulkan/quad.vert
19:35 < bridge> <burnyllama> error: line 1: Capability cannot appear before the memory model instruction
19:35 < bridge> <burnyllama>   OpCapability Shader
19:35 < bridge> <burnyllama> ```
19:36 < bridge> <teero777> i just had to do .UnclampLighting()
20:31 < bridge> <teero777> to me rainbow visuals are still the coolest.
20:31 < bridge> <teero777> https://cdn.discordapp.com/attachments/293493549758939136/1168270885015277578/Whispering_2023-10-29_20-29-34_replay.mp4?ex=6551280c&is=653eb30c&hm=a12f96d38fdf68f7f3ad5e8eeb0dd29bf12d6437c4deb97db67adbf68b513f7f&
20:33 < bridge> <blade67> Yeah, why not
20:55 < bridge> <_voxeldoesart> now program in bloom :monkalaugh:
21:00 < bridge> <v4ox3r> does anyone know how to put a points system on the ddrace server?
21:16 < bridge> <catseyenebulous> There is a point system?
21:23 < bridge> <nouaa> You mean in the scoreboard?
21:23 < bridge> <nouaa> You can choose between time format and points
21:23 < bridge> <nouaa> Or smth else
21:24 < bridge> <kekomonter> Create in database table with points, table with points for finishing map and code system for it xd
21:52 < bridge> <blaiszephyr> For what ?
22:05 < bridge> <ryozuki> https://twitter.com/cmzw_/status/1718634235664445866
22:05 < bridge> <ryozuki> https://vxtwitter.com/cmzw_/status/1718634235664445866
22:59 < bridge> <ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1168308182137970879/60s4oc1jy5xb1.webp?ex=65514ac8&is=653ed5c8&hm=e545e0f73987b6ea22db090ac1f3d67ace945b43800d66bee4a78435eee18d83&
23:00 < bridge> <teero777> uuuhmmm
23:01 < bridge> <teero777> dis supposed to be a joke or something to demonstrate something?
23:04 < bridge> <ryozuki> its a joke
23:04 < bridge> <ryozuki> i guess u dont know js and c#
23:04 < bridge> <ryozuki> i mean java
23:04 < bridge> <teero777> Well I do but I'm kinda xonfused
23:04 < bridge> <ryozuki> xd
23:04 < bridge> <ryozuki> its just imitating js and java in c++
23:05 < bridge> <teero777> you can do python in C xd
23:05 < bridge> <ryozuki> u made the joke boring now
23:05 < bridge> <ryozuki> :c
23:05 < bridge> <teero777> sry :<
23:06 < bridge> <teero777> https://cdn.discordapp.com/attachments/293493549758939136/1168309804754813029/RDT_20231016_2224002171473661244753011.jpg?ex=65514c4b&is=653ed74b&hm=a29fcf8cb07623bd4eb98fe508147cca6c1413699b88bf09b02f9a0994e28fd2&
23:06 < bridge> <teero777> hope this fixes it :>
23:11 < bridge> <teero777> I also have a duck 🦆 if that helps :c
23:11 < bridge> <ryozuki> :ferrisBorrowCheck: