00:35 < bridge> <zhn> lmfao
00:36 < bridge> <zhn> because it's json kekeke
00:37 < bridge> <reitw> yes but that's useless asf
00:37 < bridge> <reitw> http standards has headers for that
00:37 < bridge> <reitw> like Accept
00:37 < bridge> <reitw> Accept: application/json
00:47 < bridge> <meloƞ> nerdge
00:47 < bridge> <Jupstar ✪> I guess if he wants to add yaml
00:47 < bridge> <Jupstar ✪>
00:47 < bridge> <Jupstar ✪> then he can simply add /yaml and still have /json
00:47 < bridge> <Jupstar ✪> Can't hurt xd
00:48 < bridge> <Jupstar ✪> Using headers is probs more complicated
02:10 < bridge> <zhn> not really, their main route is https://ddstats.tw/player
02:10 < bridge> <zhn> thats actual web page so
02:11 < bridge> <zhn> a better option would be something like https://api.ddstats.tw/player but doesnt matter idk
06:42 < bridge> <matodor> last or most used?
07:33 < bridge> <zhn> last rn
07:40 < bridge> <matodor> rn no :justatest: I'll add this feature to my API in a few days
09:07 < bridge> <meloƞ> @scrumplex :poggers2: :poggers2: :poggers2: :poggers2:
09:07 < bridge> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1292745174845227018/Screenshot_20241007-090715.png?ex=6704da43&is=670388c3&hm=7f1fa9b9c7329cd19482541f16fcde61a6fe54ba314e4248942f1a3c5e288472&
09:08 < bridge> <meloƞ> Prolly one of the best picks
09:15 < bridge> <ryozuki> what is this?
09:16 < bridge> <meloƞ> Scrumplex is nominated to be part of the nix steering committee!!!
09:16 < bridge> <meloƞ> https://github.com/NixOS/SC-election-2024
09:16 < bridge> <01000111g> gl hf
09:18 < bridge> <reitw> https://blog.cloudflare.com/how-cloudflare-auto-mitigated-world-record-3-8-tbps-ddos-attack/
09:18 < bridge> <reitw> :justatest:
09:18 < bridge> <meloƞ> :pepeW:
09:20 < bridge> <ryozuki> im pro gentoo
09:27 < bridge> <egyt> im anti gentoo
11:06 < bridge> <ryozuki> @jupeyy_keks
11:06 < bridge> <ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1292775089221402658/image.png?ex=6704f61f&is=6703a49f&hm=2a5544fd8ca2415e81fa2cbcb0a40de01eb625032668c70745de446940428e15&
11:08 < bridge> <ryozuki> https://query.rs/
11:14 < bridge> <Jupstar ✪> Looks fair
11:24 < bridge> <meloƞ> Are we able to specify a path to the autoexec_server.cfg file ?
11:24 < bridge> <meloƞ> Or any config file in general
11:24 < bridge> <egyt> Serbia when Rust became popular: 🤑
11:26 < bridge> <heinrich5991> 1. that's by design, I think
11:26 < bridge> <heinrich5991> 2. not sure how it's redundant, but it's also not used anymore, so whatever
11:26 < bridge> <heinrich5991> 3. because the engine deals with input timing etc
11:26 < bridge> <heinrich5991> 4. I don't understand what you mean by self-replicating
11:26 < bridge> <heinrich5991> 5. probably to make sure that we get map data for the correct map
11:26 < bridge> <heinrich5991> "break the protocol" isn't a goal, it can be a means to achieve a goal
11:27 < bridge> <heinrich5991> what you posted looks more like a couple of questions about the current protocol though. I'd be worried if we decided to break the protocol because someone had questions on it
11:28 < bridge> <heinrich5991> can you write up your vision for a map format?
11:31 < bridge> <meloƞ> Or let me reword that, can the .cfg file handle absolute paths ? (eg exec ~/.config/ddnetserver/myconfig.cfg)
11:32 < bridge> <ryozuki> its rewind time
11:33 < bridge> <heinrich5991> no. link? 🙂
11:37 < bridge> <learath2> https://www.phoronix.com/news/Mesa-frog-fifo-v1-MR
11:37 < bridge> <learath2>
11:37 < bridge> <learath2> https://www.supergoodcode.com/My-Wayland-Your-Wayland-Our-Wayland/
11:38 < bridge> <learath2> Mike's blogpost is about how they'd fix the governance issue. And the first link is about the temporary solution they came up with to get things moving
11:39 < bridge> <scrumplex> :3
11:40 < bridge> <scrumplex> make sure to vote if you are eligible ^^
11:52 < bridge> <meloƞ> 👍❤️
14:02 < bridge> <zhn> first of all it was a small review of 0.6 protocol and i don't try to force anyone to break the protocol, it's more about the time when protocol breaking will be a thing (i doubt current protocol messages will migrate like this though), but if i'll elaborate anyway:
14:02 < bridge> <zhn> 1. but they have same layout with same information
14:02 < bridge> <zhn> 2. that's why it's redundant :D, it's literally unused
14:02 < bridge> <zhn> 3. i guess, it's fair, i didn't really dive into teeworlds engine part
14:02 < bridge> <zhn> 4. situation like clstartinfo and clchangeinfo, they have same layout and the only difference that one's being sent by server and other by client, why they can't use the same message to indicate it
14:02 < bridge> <zhn> 5. but in 0.7 protocol they send crc32 and sha256 only once, because it's useless to send them on every chunk, i guess ( i don't really know, maybe, im missing something)
14:05 < bridge> <heinrich5991> clstartinfo and clchangeinfo are both sent by the client AFAIK (they also both have the cl prefix). one is used as part of the login sequence. I don't think this has something to do with "backward compatibility"
14:05 < bridge> <zhn> if you are about 4 then conready and ready is just message id, with no information at all
14:05 < bridge> <zhn> i don't really know why they should be divided in two identical messages
14:06 < bridge> <heinrich5991> yes, I saw that the 0.7 protocol makes a different choice for the map data. they also make some other weird choices, like map data messages not being self-contained — you need to have outside knowledge to know the length of the contained data
14:06 < bridge> <zhn> yeah serverinfo is kinda meh
14:06 < bridge> <heinrich5991> I think conready and ready signal different readiness levels of client/server
14:06 < bridge> <heinrich5991> i.e. different stages of the loading process
14:07 < bridge> <zhn> wait, but conready is sent right after server receives ready from client
14:08 < bridge> <zhn> but anyway, is there any reason to keep the same crc (of whole map i mean, it's not crc chunk or anything else afaik) on every chunk packet
14:09 < bridge> <heinrich5991> it makes the protocol a little bit more robust against stray map download packets
14:10 < bridge> <heinrich5991> but I guess it's kinda random
14:32 < bridge> <animepdf> ./ddnet_server -f file.cfg
14:33 < bridge> <animepdf> yes
14:35 < bridge> <animepdf> :okSanya:
14:35 < bridge> <animepdf> https://cdn.discordapp.com/attachments/293493549758939136/1292827660585533532/image.png?ex=67052715&is=6703d595&hm=2ad15fb8ccbeb5d8e2e3dc4898818a1b4773fb7d304e6cdf6f3a625bdc40f8ac&
14:39 < bridge> <animepdf> @heinrich5991 hi, can you review 2 of my prs :catrose:, i mean finish reviewing AB one and check new one
14:46 < bridge> <meloƞ> Thanks darling
14:47 < bridge> <matodor> with "-f file.cfg" data/autoexec_server.cfg it will be executed anyway
14:47 < bridge> <matodor> https://cdn.discordapp.com/attachments/293493549758939136/1292830565887643699/image.png?ex=670529ca&is=6703d84a&hm=57aae2e4b502f49225ab6bcffe8d4a628460bd58b8c5bece828ab408007a1841&
14:48 < bridge> <heinrich5991> no promises
14:49 < bridge> <animepdf> that's fine, just don't forget about me
14:49 < bridge> <animepdf> https://tenor.com/view/itsover-wojack-gif-4367840179675491690
14:52 < bridge> <animepdf> delete it
14:55 < bridge> <matodor> It is better not to execute these files if a specific config is specified via launch parameters
14:55 < bridge> <matodor>
14:55 < bridge> <matodor> `exec data/autoexec_server.cfg` if you need it
14:56 < bridge> <matodor> I didn't know about this, I recently launched a public server and was very surprised when players started voting for "Shutdown server"
14:56 < bridge> <Jupstar ✪> https://github.com/rust-lang/rust/pull/129086
14:56 < bridge> <Jupstar ✪>
14:56 < bridge> <Jupstar ✪> omg finally
14:56 < bridge> <Jupstar ✪> in 10 days
14:57 < bridge> <Jupstar ✪> i can rerwite my code :lol:
14:57 < bridge> <Jupstar ✪> i hated that so much
14:57 < bridge> <animepdf> you don't need autoexec cfg in most cases, just start a lot of servers with script specifying per-server config with -f that will set individual server settings + execute common.cfg that will have settings common for all servers
14:57 < bridge> <animepdf> thats how ddnet and most servers work
14:59 < bridge> <heinrich5991> you can implement stuff like this by yourself, just needing an `use util::IsNoneOr as _;` at the top of each file where you use it
14:59 < bridge> <heinrich5991> no need to wait for official stabilization
15:00 < bridge> <Jupstar ✪> i can do a lot of stuff if i dont wait for other things. but manually writing an include is defs less attractive than just having it 😄
15:00 < bridge> <heinrich5991> there's even a crate that implements it apparently: https://docs.rs/is_none_or/0.1.0/is_none_or/
15:00 < bridge> <heinrich5991> can your IDE also automatically include a `use` when you use a trait method? I know rustrover can do that
15:01 < bridge> <Jupstar ✪> yes it can
15:01 < bridge> <heinrich5991> so no need to manually write the `use` there
15:01 < bridge> <Jupstar ✪> but i'd still need to link the crate everytime i use it
15:01 < bridge> <heinrich5991> yes
15:01 < bridge> <Jupstar ✪> that is smth my ide cant do
15:01 < bridge> <heinrich5991> but it's one of the cool features of rust. you can extend standard library types without waiting for the standard library to do it
15:01 < bridge> <heinrich5991> I'm missing that when I write C++
15:02 < bridge> <Jupstar ✪> @milkeeycat THATS IT
15:02 < bridge> <Jupstar ✪>
15:02 < bridge> <Jupstar ✪> your language needs to automatically add dependencies xDD
15:02 < bridge> <Jupstar ✪>
15:02 < bridge> <Jupstar ✪> just type in vk:: and bam dep added
15:02 < bridge> <Jupstar ✪> i agree with that yeah
15:02 < bridge> <milkeeycat> i wrote ~350 loc in it and it didn't segfault even a single time
15:03 < bridge> <Jupstar ✪> 😮 nice
15:03 < bridge> <milkeeycat> it already sends connect packet to server, and recieves data back
15:03 < bridge> <milkeeycat> now im trying to decode all dis stuff
15:04 < bridge> <roma226k9> hello my god friends
15:05 < bridge> <matodor> yes, that's why I say the server should not automatically execute autoexecs files if a specific config was specified
15:06 < bridge> <Jupstar ✪> hello, what do you want from us gods?
15:09 < bridge> <animepdf> fire, obviously
15:09 < bridge> <animepdf> now we gotta figure who's prometheus
15:12 < bridge> <learath2> Don't need to decode much of anything if you just want to get a tee ingame
15:13 < bridge> <milkeeycat> i need a token
15:13 < bridge> <milkeeycat> no?
15:13 < bridge> <learath2> Oh actually you do, I forgot it's 2024 and we have tokens
15:14 < bridge> <learath2> Look at the logs I have to go off of to fix an error at work today:
15:15 < bridge> <learath2> `3:09PM ERR Activity error. ActivityType=ListInventoryLevels Attempt=4 Error="Unknown Error"`
15:15 < bridge> <learath2> idk what part of the stack is throwing that very informative "Unknown Error" all the way to the top, but thank
15:23 < bridge> <Jupstar ✪> next rust stable is a pretty huge deal:
15:23 < bridge> <Jupstar ✪> https://github.com/rust-lang/rust/pull/122792
15:25 < bridge> <heinrich5991> huh, nice 🙂
15:26 < bridge> <heinrich5991> although I'd say it's only a QoL change, not a dealbreaker, since you could achieve the same with more code before
15:38 < bridge> <jxsl13> temporal (probably) in sight
15:39 < bridge> <learath2> It was `goshopify` 🙃
15:39 < bridge> <jxsl13> urgh :0
16:04 < bridge> <ryozuki> the map format should be more extensible,
16:04 < bridge> <ryozuki> - Like with images, it should also bundle the game/front tile graphics (and editor tiles if they differ) if they arent included in the base client (external), this allows us to not need to bundle all the new mods game tiles, etc
16:04 < bridge> <ryozuki> - Revise any compression algorithm if it can be improved
16:04 < bridge> <ryozuki> - Revise any data format if it can be improved, i think it should be improved with the following prioritis if needs be: extendability > compression > load speed, just for the map format case, since its mostly static data that needs to be stored and loaded.
16:04 < bridge> <ryozuki> - Also maybe a external optional file describing the tiles, like we do for the current game tiles iirc, but for other mods.
16:09 < bridge> <learath2> If I were doing it today, I'd probably offload everything to zip
16:12 < bridge> <learath2> A metadata json, an assets folder for all embedded assets, and the layers directly as uncompressed binary files. Deflate should take relatively good care of it
16:14 < bridge> <learath2> Also layer types as uuids, `tele-v1@maplayer.ddnet.org`
16:18 < bridge> <Jupstar ✪> the first is defs interesting, but ppl like to mod the entities, but as a base image sounds cool
16:18 < bridge> <Jupstar ✪>
16:18 < bridge> <Jupstar ✪> > extensibility > compression > load speed
16:18 < bridge> <Jupstar ✪> Interestingly I'd go the exact opposite, extensibility can be done on a higher level 😄
16:18 < bridge> <Jupstar ✪>
16:18 < bridge> <Jupstar ✪> > Also maybe a external optional file describing the tiles, like we do for the current game tiles iirc, but for other mods.
16:18 < bridge> <Jupstar ✪> Could be part of the physics module, which the editor could load. Thought about doing that, but isn't high prio enough for me
16:44 < bridge> <jxsl13> due to #7777 being closed with the reasoning stated there, moddability r.i.p.
16:44 < bridge> <DDNet> https://github.com/ddnet/ddnet/issues/7777
16:46 < bridge> <jxsl13> such maps are probably also "out of scope".
16:48 < bridge> <Jupstar ✪> The problem is some ppl don't want a mod, they want a different game
16:48 < bridge> <Jupstar ✪> So they gotta wait for dd-pg, just another 20 years, like always
16:57 < bridge> <ryozuki> :gigachad:
17:07 < bridge> <zhn> meeee :3
17:07 < bridge> <zhn> teeworlds looks like a good start point, it has everything and nothing at the same moment
18:17 < bridge> <Kaffeine> It supports only 16 players which is nonsense nowadays. Plugging the 64 players support means a lot of work. Then a mod needs the new ddnet registration to be listed. Then it needs NetEx uuid-based system (and various CNetObj\_GameInfoEx, CNetObj\_DDNetCharacter, etc). 100+ hours to get the ground.
18:23 < bridge> <zhn> im not about well-prepared mod developers though, im about programming newbies that have literally no experience in both programming and gamedev
18:23 < bridge> <zhn> you have assets, sounds, prepared net and bunch of things to start with
18:23 < bridge> <zhn> teeworlds itself as a game engine sucks ofc
18:24 < bridge> <milkeeycat> there was no segfault but it was writing to wrong memory location :lol:
18:31 < bridge> <jxsl13> https://cdn.discordapp.com/attachments/293493549758939136/1292887058620088380/image0.gif?ex=67055e67&is=67040ce7&hm=b81c0ec49ca5a0e9d6b4d122f5768621afc9d26b5c8a9d508ac0216444f42ef4&
18:43 < bridge> <heinrich5991> - I think I'd actually like to debundle images etc. to be downloaded separately from the server
18:43 < bridge> <heinrich5991> - agree that another compression algorithm might be nice
18:43 < bridge> <heinrich5991> - too vague IMO. I'd probably do it the way @learath2 proposed, dump most stuff into JSON inside a zip
18:43 < bridge> <heinrich5991> - I don't understand the last point about describing tiles, do you mean the game tile descriptions? I really don't think that should be part of actual maps, it'd get out of sync with the mods instantly. perhaps we could get mod packs for the editor that include game tiles plus their descriptions instead
18:44 < bridge> <heinrich5991> wdym with more extensible btw, what are you missing?
19:36 < bridge> <zhn> but what if players want to share map, they should archive their map with images every time?
19:37 < bridge> <Jupstar ✪> that is what ddnet is kinda doin rn
19:40 < bridge> <zhn> i mean ddnet bundles images, heinrich proposes to debundle them
19:41 < bridge> <Jupstar ✪> he wants to zip everything i think
19:41 < bridge> <Jupstar ✪> but generally i think at least the server should debundle them
19:41 < bridge> <Jupstar ✪> and distribute them individually
19:41 < bridge> <Jupstar ✪> but i defs understand that this is less intuitive for a normal user
19:41 < bridge> <zhn> then i can't process "debundle" and "zip archives with map info" in one message
19:42 < bridge> <Jupstar ✪> well all file formats individually
19:42 < bridge> <Jupstar ✪> into a zip
19:43 < bridge> <zhn> eh
19:43 < bridge> <Kaffeine> That's complicated. Unfortunately a detailed discussion on this topic was wiped (or hidden from users) when DDNet Season 2 (or what season it was) was removed from server channels list. One of the options is to implement a sparse map download. In that case the client downloads the map without bundled assets, and then ask the (game or https) server for missing parts, and then bake it into a complete `.map` in downloads/.
19:44 < bridge> <Jupstar ✪> mh and then?
19:45 < bridge> <Jupstar ✪> then u can also download the whole container at once
19:45 < bridge> <Jupstar ✪> if they are unbundled on the filesystem it saves space
19:49 < bridge> <Kaffeine> In that case users can share maps as-is, and the assets are still debundled e.g. not downloaded if the client already have them. I don't remember the detailed plan right now but the map should reference the assets by names or by UUID or by sha256, and then (depending on what we want) an asset can be updated (uuid) or be carved in stone forever (sha).
19:49 < bridge> <Kaffeine> Like: the client has `downloaded assets/<uuid>`, download missing stuff and inserts it into the map file if/when necessary.
19:49 < bridge> <Jupstar ✪> but in any way, the map format has other problems than distribution or size problems
19:49 < bridge> <Kaffeine> Are we really struggle to save players disk space?
19:50 < bridge> <Jupstar ✪> are we struggling to save a bit network traffic? xd
19:52 < bridge> <Kaffeine> Sure. The download time is a real problem for some players/mods, and it would be nice to have assets update.
19:52 < bridge> <Jupstar ✪> is that a network limitation, or simply our way to download files
19:53 < bridge> <Jupstar ✪> the more interesting format is actually demo anyway.
19:53 < bridge> <Jupstar ✪>
19:53 < bridge> <Jupstar ✪> - it needs to store the map
19:53 < bridge> <Jupstar ✪> - in future anything mod related
19:53 < bridge> <Jupstar ✪> - server settings
19:53 < bridge> <Jupstar ✪>
19:54 < bridge> <Jupstar ✪> etc.
19:54 < bridge> <heinrich5991> it'd be nice if a map could be updated and only the changed layer could be downloaded
19:54 < bridge> <Jupstar ✪> that sounds like quite a bit of complexity added tho
19:54 < bridge> <Jupstar ✪> to save 500KB download size?
19:54 < bridge> <heinrich5991> i.e. even if the mod has 20 MiB of assets, it'd be nice if all of the images and sounds don't need to be redownloaded
19:54 < bridge> <Kaffeine> Our way to download files. IIUC it is the same limitation which makes us using 'rates' instead of sending all commands list on rcon client authenticated. See e.g. https://github.com/ddnet/ddnet/pull/7650
19:54 < bridge> <heinrich5991> if the map changes
19:54 < bridge> <Ewan> i agree
19:54 < bridge> <Ewan> hi heinrich
19:55 < bridge> <heinrich5991> you probably want to download maps via HTTPS anyway — that's doable for everyone today
19:55 < bridge> <Jupstar ✪> but you cannot have x without changing y.
19:55 < bridge> <Jupstar ✪>
19:55 < bridge> <Jupstar ✪> how do you want to store your map related assets on disk then?
19:56 < bridge> <Ewan> u dont have to send the whole file to reload map
19:56 < bridge> <Ewan> just some payload indicating what changed
19:56 < bridge> <Jupstar ✪> compared to what
19:56 < bridge> <heinrich5991> either bundled or unbundled, but that's a separate decision. what's x and y?
19:56 < bridge> <Ewan> map filename and/or hash of current map (which should have been sent when the client connected)
19:57 < bridge> <heinrich5991> live updates sound more complicated though
19:57 < bridge> <Jupstar ✪> if it's bundled, u will have either 2 files or delete one
19:57 < bridge> <Jupstar ✪>
19:57 < bridge> <Jupstar ✪> if u have 2, you increase disk space by 20MiB (assuming your assets)
19:57 < bridge> <Jupstar ✪>
19:57 < bridge> <Jupstar ✪> if u unbundle them, then you could say it's user unfriendlier again
19:57 < bridge> <Ewan> they both just keep a working in-memory copy already
19:57 < bridge> <Ewan> keeping it in sync just sounds like the potential issue
19:57 < bridge> <heinrich5991> yup, those are the tradeoffs of bundled vs unbundled on disk
19:57 < bridge> <Ewan> u dont have to send any more than the original map file
19:58 < bridge> <Ewan> assuming u know what
19:58 < bridge> <Ewan> is changing
19:58 < bridge> <Jupstar ✪> generally from a programmer perspective i'd go with unbundled.
19:58 < bridge> <Jupstar ✪>
19:58 < bridge> <Jupstar ✪> but i also can understand that sharing the files sucks then
19:58 < bridge> <Jupstar ✪> yes
19:59 < bridge> <Jupstar ✪> rn on dd-pg i tried to go with unbundled for pretty much everything
19:59 < bridge> <Jupstar ✪> and later think how much it really sucks
20:00 < bridge> <Jupstar ✪> (and ofc also split assets from map then)
20:00 < bridge> <animepdf> Can it be that selfbuilt will use other versions of libs, than official release?
20:00 < bridge> <animepdf> https://cdn.discordapp.com/attachments/293493549758939136/1292909543961001984/image.png?ex=67057358&is=670421d8&hm=d0140ba8b6bb63950465a07471958097fa32403b8dd1c45662da77a25f08b6c9&
20:01 < bridge> <Jupstar ✪> > I think I'd actually like to debundle images etc. to be downloaded separately from the server
20:01 < bridge> <Jupstar ✪> E.g. this is also what i want. server side assets can then do lot of things
20:01 < bridge> <Jupstar ✪> y<es
20:01 < bridge> <Jupstar ✪> for shared libs that are not shipped with the client that is the case
20:02 < bridge> <animepdf> that is unfortunate
20:03 < bridge> <Kaffeine> Makes sense but it is complicated in some cases. E.g. infclass generates client maps on demand — depending on the current server settings, and e.g. it adds map assets on the fly.
20:03 < bridge> <Kaffeine> Still, can you please recommend an https server (software)? `python -m http.server`? nginx? Apache? Maybe it is possible to generate some client maps set for usual server settings at least.
20:03 < bridge> <learath2> Why debundle anyway? What feature do you want to support with that?
20:05 < bridge> <Ewan> i like flask, it's very easy. axum is also very good for making a high performance web server without a lot of headache
20:05 < bridge> <Jupstar ✪> Think of the demo format, and lets additionally assume u have wasm files, lua scripts what do i know.
20:05 < bridge> <Jupstar ✪> + server side assets that are REQUIRED (so cannot miss)
20:05 < bridge> <Jupstar ✪> u end up with pretty annoying huge files
20:06 < bridge> <heinrich5991> I'd suggest nginx or caddy, but any https capable server works
20:06 < bridge> <Kaffeine> Thanks
20:06 < bridge> <heinrich5991> caddy has automatic https built in
20:06 < bridge> <learath2> Ah you are thinking of stuff like that. Yeah a map bundle can not contain everything needed for a server that can send wasm/lua at runtime
20:08 < bridge> <heinrich5991> can you make the infclass server output the map file into a directory? Kaffeine
20:08 < bridge> <heinrich5991> a HTTPS server could then directly serve this file
20:08 < bridge> <jxsl13> sounds like docker images
20:08 < bridge> <learath2> I would keep it bundled, let the server send patches to the map for runtime stuff. Said patches would be saved in the demo as messages which would keep it reproducible
20:09 < bridge> <heinrich5991> how would you handle skipping?
20:10 < bridge> <learath2> (either pre or post) I would scan through the demo to get a list of ticks where patches are applied
20:10 < bridge> <heinrich5991> and add file offsets somewhere
20:10 < bridge> <learath2> This could also be generated while saving the demo removing the cost from demo load
20:10 < bridge> <heinrich5991> sounds sane
20:11 < bridge> <Ewan> how can this be known
20:11 < bridge> <Ewan> actually what even is the goal
20:11 < bridge> <Ewan> why demo file
20:11 < bridge> <Ewan> i missed all that
20:13 < bridge> <Kaffeine> heinrich5991, yes, the generated client maps are saved to files. It means the host 'd have to run own https server but yeah, it can work 👍. In other case I could upload maps to github pages, and skip https cert acquiring.
20:15 < bridge> <heinrich5991> if you don't like the https cert acquiring process, I'd suggest using caddy
20:15 < bridge> <heinrich5991> you just start it and it deals with acquiring the certificate automatically
20:16 < bridge> <Ewan> that does sound very handy
20:16 < bridge> <jxsl13> caddy is pretty easy to use
20:17 < bridge> <Ewan> cert management never sounds like a problem until ur on a distro that doesn't have the nginx letsencrypt plugin or whatever
20:19 < bridge> <Ewan> historically i have used cloudflare to proxy my http traffic at the endpoint and then you literally don't need to think about SSL certs
20:19 < bridge> <Ewan> but then ofc there's a whole section of your pipeline where the traffic is not encrypted
20:24 < bridge> <jxsl13> an example config:
20:24 < bridge> <jxsl13> /etc/caddy/Caddyfile
20:24 < bridge> <jxsl13> ```Caddyfile
20:24 < bridge> <jxsl13> zcat.ch {
20:24 < bridge> <jxsl13> root * /var/www/html/zcatch/public
20:24 < bridge> <jxsl13> file_server
20:24 < bridge> <jxsl13> log {
20:24 < bridge> <jxsl13> output file /var/log/caddy/zcat.ch.access.log {
20:24 < bridge> <jxsl13> roll_size 2mb
20:24 < bridge> <jxsl13> roll_keep 5
20:24 < bridge> <jxsl13> }
20:24 < bridge> <jxsl13> }
20:24 < bridge> <jxsl13> }
20:25 < bridge> <jxsl13>
20:25 < bridge> <jxsl13> pic.zcat.ch {
20:25 < bridge> <jxsl13> redir https://discord.gg/38aDRSfVKt
20:25 < bridge> <jxsl13> log {
20:25 < bridge> <jxsl13> output file /var/log/caddy/pic.zcat.ch.access.log {
20:25 < bridge> <jxsl13> roll_size 2mb
20:25 < bridge> <jxsl13> roll_keep 5
20:25 < bridge> <jxsl13> }
20:25 < bridge> <jxsl13> }
20:25 < bridge> <jxsl13> }
20:25 < bridge> <jxsl13> ```
20:25 < bridge> <Ewan> lol
20:25 < bridge> <Ewan> nice
20:26 < bridge> <jxsl13> an example config:
20:26 < bridge> <jxsl13> /etc/caddy/Caddyfile
20:26 < bridge> <jxsl13> ```Caddyfile
20:26 < bridge> <jxsl13> zcat.ch {
20:26 < bridge> <jxsl13> root * /var/www/html/zcatch/public
20:26 < bridge> <jxsl13> file_server
20:26 < bridge> <jxsl13> log {
20:26 < bridge> <jxsl13> output file /var/log/caddy/zcat.ch.access.log {
20:26 < bridge> <jxsl13> roll_size 2mb
20:26 < bridge> <jxsl13> roll_keep 5
20:26 < bridge> <jxsl13> }
20:26 < bridge> <jxsl13> }
20:26 < bridge> <jxsl13> }
20:26 < bridge> <jxsl13>
20:26 < bridge> <jxsl13> pic.zcat.ch {
20:26 < bridge> <jxsl13> redir https://discord.TLD/38aDRSfVKt
20:26 < bridge> <jxsl13> log {
20:26 < bridge> <jxsl13> output file /var/log/caddy/pic.zcat.ch.access.log {
20:26 < bridge> <jxsl13> roll_size 2mb
20:26 < bridge> <jxsl13> roll_keep 5
20:26 < bridge> <jxsl13> }
20:26 < bridge> <jxsl13> }
20:26 < bridge> <jxsl13> }
20:26 < bridge> <jxsl13> ```
20:26 < bridge> <jxsl13> can't remove discord embeddings from code blocks, lol
20:28 < bridge> <jxsl13> caddy v2 can be configured at runtime, using json http calls iirc
20:28 < bridge> <jxsl13> if anyone needs that
20:51 < bridge> <Jupstar ✪> what is caddy? certbot alternative?
20:52 < bridge> <Jupstar ✪> ah ok
20:52 < bridge> <Jupstar ✪> sounds interesting
21:07 < bridge> <Jupstar ✪> @robyt3 check if that also happens with 0.7
21:07 < bridge> <Jupstar ✪> THEN WE CAN REMOVE IT AGAIN HEEEHEHE
21:08 < bridge> <Jupstar ✪> but only on sender side?
21:08 < bridge> <Jupstar ✪> not recv?
21:08 < bridge> <robyt3> Only sender. I think it already happened before 0.7 was merged, I noticed it again because of testing for #9097
21:09 < bridge> <DDNet> https://github.com/ddnet/ddnet/pull/9097
21:41 < bridge> <Jupstar ✪> furo: do you use a database for ddstats.tw?
21:41 < bridge> <Jupstar ✪>
21:41 < bridge> <Jupstar ✪> Could you lookup how many player entries there are in total in your db?
21:42 < furo> I do, what do you mean by player entry?
21:42 < bridge> <Jupstar ✪> how many unique players there are in total basically
21:53 < furo> 9,67 million unique player names seen since 2021-05-18
21:53 < bridge> <Jupstar ✪> oh wow wtf, i send you a pm in matrix, to tell you what my idea was xD
21:53 < bridge> <Jupstar ✪> didnt expect more than 1 million entries 😄
22:42 < bridge> <ryozuki> https://tweedegolf.nl/en/blog/137/rust-is-rolling-off-the-volvo-assembly-line
22:42 < bridge> <ryozuki> volvo casually using rust in production
22:42 < bridge> <ryozuki> Embassy + defmt
22:42 < bridge> <ryozuki> embassy is like a tokio for embedded
22:44 < bridge> <kollpotato> 🦀
22:47 < bridge> <Ewan> sweet
22:57 < bridge> <zhn> :poggers2:
23:50 < bridge> <jxsl13> *applied*
23:50 < bridge> <jxsl13> for the job
23:51 < bridge> <meloƞ> :poggers2:
23:52 < bridge> <Ewan> nice
23:53 < bridge> <jxsl13> imagine, no rust knowledge, getting the job
23:53 < bridge> <jxsl13> that's :poggers:
23:54 < bridge> <meloƞ> Fake it till you make it 💥