00:33 <+bridge> [ddnet] @n000b wait what? how? 00:42 <+bridge> [ddnet] @Soreu replay 00:55 <+bridge> [ddnet] :thonk: @Jupstar ✪ what texture size is safe to use in general, if i have to use a fixed size texture for text. 00:56 <+bridge> [ddnet] I mean GPU supports wise. 00:56 <+bridge> [ddnet] 2048 is safe 00:56 <+bridge> [ddnet] i don't care about keeping all glyphs 00:56 <+bridge> [ddnet] only the windows software renderer cant handle it 00:56 <+bridge> [ddnet] so is 1024 pretty much good on everything? 00:56 <+bridge> [ddnet] 1024 is safest 00:56 <+bridge> [ddnet] ok thanks 00:57 <+bridge> [ddnet] but 2048 is also safe 00:57 <+bridge> [ddnet] https://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_SIZE 00:57 <+bridge> [ddnet] GetIntegerv(GL_MAX_TEXTURE_SIZE,) ? 00:57 <+bridge> [ddnet] xd 00:57 <+bridge> [ddnet] only 200 GPU dont have it and if u click it 00:58 <+bridge> [ddnet] I'm currently using 1024, and it is pretty enough for my use case. dropping 1/4 of the 1024 texture isn't causing too much trouble for now. 00:58 <+bridge> [ddnet] u'll see some very early mesa and windows software renderer 00:58 <+bridge> [ddnet] and that report is 5years old too 00:59 <+bridge> [ddnet] maybe i can add a config 01:00 <+bridge> [ddnet] @Jupstar ✪ how does the font renderer work? do u save all glyphs in a atlas? do u pack them the easy way or do u use some kind of algorithm 01:00 <+bridge> [ddnet] > https://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_SIZE 01:00 <+bridge> [ddnet] yeah, looks like 1024 is the safest, although idk if software render can really play teeworlds well anyway. 01:00 <+bridge> [ddnet] they are packed with buttom left skyline algorithm 01:00 <+bridge> [ddnet] its not directly an atlas 01:00 <+bridge> [ddnet] we packed the glyphs on the spot 01:01 <+bridge> [ddnet] if one shows up it get packed 01:01 <+bridge> [ddnet] https://github.com/edg-l/SimpleGame/blob/master/src/engine/graphics/renderer.c#L105 01:01 <+bridge> [ddnet] this is how i did it, i dont know shit tho xd 01:02 <+bridge> [ddnet] i'd say 2048 is safe too 01:02 <+bridge> [ddnet] i would use 2048 01:02 <+bridge> [ddnet] okay 01:02 <+bridge> [ddnet] we use 1024 01:02 <+bridge> [ddnet] but his approach is different 01:02 <+bridge> [ddnet] but you guys can resize the texture i suppose 01:02 <+bridge> [ddnet] yeah 01:03 <+bridge> [ddnet] it probs goes to 2048 on a chinese server quickly 01:03 <+bridge> [ddnet] what r u working on? 01:04 <+bridge> [ddnet] with 512 is page dropping city even when you just looking at the settings.:doggo_lol: 01:07 <+bridge> [ddnet] hes working on the text in vanilla 01:08 <+bridge> [ddnet] oh is he asking me 01:08 <+bridge> [ddnet] sorry didn't notice 01:08 <+bridge> [ddnet] :EeveeShy: yes. i'm working on text in vanilla 01:45 <+bridge> [ddnet] <Андрей Рудой> How ddnet servers fixed the following problem: when you are frozen on zcatch for example and hold hook it's rapidly flickering in and out with sounds. Same with movement keys, your tee gets in some direction a bit and then returns. 01:45 <+bridge> [ddnet] <Андрей Рудой> Test 01:47 <+bridge> [ddnet] you can send tunning setting to clients to shorten their hook, so the client prediction can't try to kick in 01:51 <+bridge> [ddnet] <Андрей Рудой> But fng mode still shows very short hook flickering (better than zcatch) but DDrace does not at all! 01:54 <+bridge> [ddnet] i'm guessing fng is not completely 0'd it's hook length? 01:55 <+bridge> [ddnet] or can you not make 0 length hook, i can't remember 01:57 <+bridge> [ddnet] cl_predict_freeze 01:57 <+bridge> [ddnet] <Андрей Рудой> That's interesting because even movement on ddnet does not 01:57 <+bridge> [ddnet] the client knows 01:57 <+bridge> [ddnet] <Андрей Рудой> Oof 01:58 <+bridge> [ddnet] <Андрей Рудой> So just set it to 0 and everything will look fine? 01:58 <+bridge> [ddnet] no everything looks shit on ddnet xd 01:58 <+bridge> [ddnet] with it on it looks fine 01:58 <+bridge> [ddnet] <Андрей Рудой> Ddnet client on ddnet server does not show flickering things tho 01:58 <+bridge> [ddnet] yes 01:59 <+bridge> [ddnet] cl_predict_freeze 0 = no prediction = laggy 01:59 <+bridge> [ddnet] <Андрей Рудой> Why didn't fng creators set this variable? 01:59 <+bridge> [ddnet] but fng has no "freeze" like ddrace 01:59 <+bridge> [ddnet] u can add it 01:59 <+bridge> [ddnet] <Андрей Рудой> Wuur 01:59 <+bridge> [ddnet] <Андрей Рудой> Wuut 01:59 <+bridge> [ddnet] fng uses a different approach that also supports vanilla clients 01:59 <+bridge> [ddnet] also i guess server can't set config for clients? 01:59 <+bridge> [ddnet] <Андрей Рудой> DDrace does not? 01:59 <+bridge> [ddnet] no 01:59 <+bridge> [ddnet] its just the client that knows about ddrace 02:00 <+bridge> [ddnet] so hardcoded magic 02:00 <+bridge> [ddnet] <Андрей Рудой> So I can't connect to ddnet server using default tw? 02:01 <+bridge> [ddnet] you can 02:01 <+bridge> [ddnet] it still hooks on vanilla 02:01 <+bridge> [ddnet] but no prediction 02:01 <+bridge> [ddnet] <Андрей Рудой> No prediction? I thought it's only ddnet client feature 02:02 <+bridge> [ddnet] yes 02:02 <+bridge> [ddnet] <Андрей Рудой> Now I'm completely confused 02:02 <+bridge> [ddnet] no prediction = it does not predict freeze 02:02 <+bridge> [ddnet] prediction = see into the future xD 02:02 <+bridge> [ddnet] <Андрей Рудой> > but no prediction 02:02 <+bridge> [ddnet] <Андрей Рудой> @Jupstar ✪ maybe you meant here "but with prediction"? 02:02 <+bridge> [ddnet] u asked for default tw 02:03 <+bridge> [ddnet] it has no prediction 02:03 <+bridge> [ddnet] <Андрей Рудой> Yep 02:03 <+bridge> [ddnet] default tw has prediction tho.. 02:03 <+bridge> [ddnet] ddnet don't glitch because it disabled prediction for hook 02:03 <+bridge> [ddnet] wording is hard.. 02:03 <+bridge> [ddnet] <Андрей Рудой> But it does glitch 02:03 <+bridge> [ddnet] <Андрей Рудой> On fng 02:03 <+bridge> [ddnet] but fng is something different 02:03 <+bridge> [ddnet] its a different mod 02:03 <+bridge> [ddnet] u can add support for it in ddnet code 02:03 <+bridge> [ddnet] they will add it and it wont glitch 02:04 <+bridge> [ddnet] sounds like ddnet clients has hardcoded check to disable prediction for ddnet servers 02:04 <+bridge> [ddnet] <Андрей Рудой> Hmmmm 02:04 <+bridge> [ddnet] so you can't fix it in server, is what he's saying. 02:04 <+bridge> [ddnet] ddnet is in first place made for ddrace... during the time other modders added mod support too 02:05 <+bridge> [ddnet] <Андрей Рудой> Okay I'll look for it in sources 02:05 <+bridge> [ddnet] use the fng method, you can prevent glitch for a certain distance on all clients i think. 02:05 <+bridge> [ddnet] <Андрей Рудой> It would be not that easy. I've seen folder predictions, what does code inside do? 02:05 <+bridge> [ddnet] if you only want to make server mods 04:38 <+bridge> [ddnet] two things i think would be pretty cool to implement: 04:38 <+bridge> [ddnet] 1. being able to start a lan server inside the client without having to open an external window + program 04:38 <+bridge> [ddnet] 2. "texture pack files" where you can just have one folder with game, particles, entities, etc. files so you can hotswap different game, particles, emotes, and other visuals without having to rename each individual one (and have texture packs available to change + select inside the client) 04:39 <+bridge> [ddnet] ofc it would take some time but these are just two things that would be cool 04:51 <+bridge> [ddnet] @louis isnt 1. in the newest client 04:51 <+bridge> [ddnet] oh is it 04:51 <+bridge> [ddnet] version 15 04:52 <+bridge> [ddnet] is it a beta build 04:52 <+bridge> [ddnet] it will be released in the next days 04:52 <+bridge> [ddnet] oh neat 04:52 <+bridge> [ddnet] if you have github 04:52 <+bridge> [ddnet] https://github.com/ddnet/ddnet/runs/1119831512 04:52 <+bridge> [ddnet] you can download artifacts top right 04:58 <+bridge> [ddnet] neat it works nicely 07:47 <+bridge> [ddnet] @Soreu it is useful when something epic happens but u weren't recording you can still use replays (if u have them enabled) to save a replay of that epic moment 07:48 <+bridge> [ddnet] save_replay 30 saves the last 30 seconds of ur game 09:07 <+bridge> [ddnet] No no no no 10:51 <+bridge> [ddnet] <Андрей Рудой> @Jupstar ✪ do github actions eat any money? Did you even meet any limitations with it? 10:52 <+bridge> [ddnet] No limitations for public repos 10:53 <+bridge> [ddnet] I'm certain they will talk to you if you go over some limit, same as with repository size 10:58 <+bridge> [ddnet] There is a limit to the builds you can run per month 11:00 <+bridge> [ddnet] @Learath2 @heinrich5991 btw, I just checked and xz was about same speed for compression and smaller file sizes than zstd for teehistorian files for me (tested with lowest and highest compression levels). Was just wondering if I could easily save some space by recompressing 11:02 <+bridge> [ddnet] I'm wondering what the proper approach would be to get a teehistorian replayer for creating proper demo files 11:02 <+bridge> [ddnet] I guess I need to reimplement teehistorian format reader in C++, run a modified server that just uses the inputs at the correct ticks? 11:03 <+bridge> [ddnet] Yes I think that about covers it 11:03 <+bridge> [ddnet] You might also want to run the server at a higher tickspeed so it doesnt take hours 11:04 <+bridge> [ddnet] And then ideally we throw a DDNet client to watch at it and make it record the video to a stream that gets proxied to the user watching the teehistorian? 11:04 <+bridge> [ddnet] well, or implement a demo viewer in teewebs javascript client 11:05 <+bridge> [ddnet] @Learath2 I thought we could remove the waits between ticks totally and just run through the ticks instantly 11:05 <+bridge> [ddnet] One problem I can think of is the rather massive teehistorian files 11:05 <+bridge> [ddnet] These are sometimes like 20 hours of server uptime, all in one file 11:06 <+bridge> [ddnet] There are teehistorian files with > 100 hours I think 11:06 <+bridge> [ddnet] So when a tee requests a demo, you need to chop the massive demo up 11:06 <+bridge> [ddnet] and nearly full server for much of the time, so they are easily multi-GB 11:06 <+bridge> [ddnet] well, can't find out where to cut it 11:07 <+bridge> [ddnet] If only we were saving race starts 11:08 <+bridge> [ddnet] I was thinking of skipping until the race start, then running it backwards until I have enough for a full snap and starting there 11:11 <+bridge> [ddnet] Well, we have the finish time 11:12 <+bridge> [ddnet] we could go back from that and try to find when the players that finished started 11:12 <+bridge> [ddnet] but it's a bit hacky 11:12 <+bridge> [ddnet] But it's not very easy to figure out when you have enough for a full snap 11:13 <+bridge> [ddnet] I wonder if we can just run it through in the server, if that's cheap enough, no need to bother with hacking around teehistorian files 14:54 <+ChillerDragon> @Ryozuki im such a github influencer i wonder if i can get sponsored and make some github ads xd https://zillyhuhn.com/cs/.1600260808.png 14:55 <+ChillerDragon> btw join #olive on freenode 15:11 <+bridge> [ddnet] ChillerDragon i found it curious cuz i was searching for a video wditor 15:36 <+bridge> [ddnet] @heinrich5991 can you give me a hand with some rust? 15:36 <+bridge> [ddnet] just a handful of lines 15:55 <+bridge> [ddnet] or @Ryozuki ^^ 16:01 <+bridge> [ddnet] if its not *too* complicated i could try my best @Learath2 :) 16:02 <+bridge> [ddnet] It's trivial, I have a program that takes a filename as an argument, I need it to be able to get the file from stdin too 16:02 <+bridge> [ddnet] https://paste.pr0.tips/xV 16:03 <+bridge> [ddnet] ah, ive never actually worked with stdin, only ever used the command arguments 16:04 <+bridge> [ddnet] Meh 😦 16:04 <+bridge> [ddnet] shouldnt be that complicated tho, no? 16:04 <+bridge> [ddnet] have you tried https://doc.rust-lang.org/std/io/struct.Stdin.html? 16:05 <+bridge> [ddnet] process takes a Path though, hm 16:05 <+bridge> [ddnet] I can break it and rewire it to just work with stdin 😄 16:06 <+bridge> [ddnet] wait so your problem is that you want to allow either filename as argument or via stdin? 16:06 <+bridge> [ddnet] Smth with pathbuf irc 16:06 <+bridge> [ddnet] Not home rn 16:07 <+bridge> [ddnet] I was thinking of wiring it like cat, treat `-` filename as stdin 16:08 <+bridge> [ddnet] What the problem ezactly 16:08 <+bridge> [ddnet] Taking arguments from stdin 16:08 <+bridge> [ddnet] Or converting it to a path? 16:08 <+bridge> [ddnet] https://doc.rust-lang.org/std/path/struct.PathBuf.html 16:09 <+bridge> [ddnet] stdin isn't a path 16:09 <+bridge> [ddnet] but process takes a path 16:09 <+bridge> [ddnet] I think I should move the opening of the file out of process, so I can just pass a teehistorian reader to process 16:13 <+bridge> [ddnet] Whats process here? 16:14 <+bridge> [ddnet] Oh u sent a paste 16:14 <+bridge> [ddnet] Didnt see 16:18 <+bridge> [ddnet] I think u should create the path with pathbuf the diference is that pathbuf is owned 16:18 <+bridge> [ddnet] Also u dont need extern crate 16:18 <+bridge> [ddnet] Pathbuf::from() 16:51 <+bridge> [ddnet] @Learath2 make sure to use a BufReader 16:51 <+bridge> [ddnet] Read isnt buffered 16:51 <+bridge> [ddnet] std::io::Read 16:51 <+bridge> [ddnet] https://doc.rust-lang.org/std/io/struct.BufReader.html 16:56 <+bridge> [ddnet] @Learath2 cna't think of something simple except pass `/dev/stdin` to the process 16:56 <+bridge> [ddnet] I decided against doing everything generically in the teehistorian crate, so the only thing I accept is a `File` (or a `Path`) that will be opened 17:22 <+bridge> [ddnet] @heinrich5991 why would you tie parsing to the opening? 17:23 <+bridge> [ddnet] I tie it to a `File` 17:23 <+bridge> [ddnet] i.e. I can't read from arbitrary streams 17:25 <+bridge> [ddnet] the core library doesn't do that (teehistorian/src/raw.rs), but I didn't expose that in the public API 17:25 <+bridge> [ddnet] I guess I'll pass /dev/stdin 21:28 <+bridge> [ddnet] can `mastersrv` and `twping` executable be renamed to something similar, but not the same? 21:28 <+bridge> [ddnet] can `mastersrv` and `twping` executables be renamed to something similar, but not the same? 21:29 <+bridge> [ddnet] git ignores /mastersrv and /twping, github actions can't compile `everything` 21:29 <+bridge> [ddnet] what does that have to do with each other? 21:31 <+bridge> [ddnet] it not very comfortable to make mod under ddnet base on fork with `modname` branch, it needs to be reuploaded on new repo 21:31 <+bridge> [ddnet] its not very comfortable to make mod under ddnet base on fork with `modname` branch, it needs to be reuploaded on new repo 21:33 <+bridge> [ddnet] and when im starting, always `tools` or `various targets` they are showing up 21:33 <+bridge> [ddnet] and when im starting, always `tools` or `various targets` are showing up 21:33 <+bridge> [ddnet] tools or various targets are showing up? 21:33 <+bridge> [ddnet] where? 21:34 <+bridge> [ddnet] I'm not quite following 21:34 <+bridge> [ddnet] the mastersrv and twping folders are in gitignore 21:34 <+bridge> [ddnet] if you create a mod and upload your initial base, then these folders dont show up 21:34 <+bridge> [ddnet] compiler can't find /mastersrv and /twping, because `mastersrv` and `twping` are written in `.gitignore` 21:34 <+bridge> [ddnet] in the repo 21:34 <+bridge> [ddnet] ah 21:35 <+bridge> [ddnet] we can fix the gitignore 21:35 <+bridge> [ddnet] (but you should not use create a new git repository for your mod, you can keep the history anyway, even with a different github repo) 21:35 <+bridge> [ddnet] ye 21:37 <+bridge> [ddnet] oh, need to learn about it more 22:16 <+bridge> [ddnet] It's coming together 22:16 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/755884927186108446/Screenshot_2020-09-16_at_23.16.30.png 22:23 <+bridge> [ddnet] wdyd? 22:24 <+bridge> [ddnet] Making a dissector 22:24 <+bridge> [ddnet] building on any prior work? 22:24 <+bridge> [ddnet] Nope 22:25 <+bridge> [ddnet] There is no prior work except the libtw2 dissector 22:25 <+bridge> [ddnet] I didn't feel like plunging into depression because of the rust compiler 22:25 <+bridge> [ddnet] and fstd's dissector 22:26 <+bridge> [ddnet] Ah, he has one too? 22:26 <+bridge> [ddnet] Anyway I'm using conversations to dissect 0.6 0.6.5 and 0.7 all in one 22:26 <+bridge> [ddnet] nice! 22:28 <+bridge> [ddnet] With connless flag set, numchunks doesn't mean anything, does it? 22:29 <+bridge> [ddnet] numchunks is 0xff for num_chunks I think 22:29 <+bridge> [ddnet] for connless packets* 22:30 <+bridge> [ddnet] Seems the client doesn't set it to anything 22:31 <+bridge> [ddnet] I found one with 0x56 one with 0x4f and it seems to vary between runs so, I'm guessing uninitialized memory 22:35 <+bridge> [ddnet] @Learath2 there's also some part that is used as part of the extended serverinfo protocol 22:35 <+bridge> [ddnet] maybe you saw that 22:35 <+bridge> [ddnet] ? 22:35 <+bridge> [ddnet] normal (non-extended) should have it at 0xff 22:35 <+bridge> [ddnet] Oh is that where we packed the extended bit? 22:36 <+bridge> [ddnet] we made the first two bytes of the packet 22:36 <+bridge> [ddnet] xe 22:36 <+bridge> [ddnet] and then 4 bytes for free use IIRC 22:36 <+bridge> [ddnet] But the first two bytes of the packet are after numchunks, no? 22:37 <+bridge> [ddnet] no, first two bytes in the header 22:37 <+bridge> [ddnet] it happened that 'xe' contains the connless flag ^^ 22:37 <+bridge> [ddnet] Oh wow 22:37 <+bridge> [ddnet] (we didn't have much space to work with, forgive us) 22:37 <+bridge> [ddnet] But that only destroys flags and ack 22:38 <+bridge> [ddnet] I guess after its detected as extended the rest is just the packet? 22:38 <+bridge> [ddnet] ye, and then next four bytes are for free use. I don't know which, but we use two of them as the token for the serverinfo 22:38 <+bridge> [ddnet] we have serverinfo tokens? 22:39 <+bridge> [ddnet] Not the handshake kind, only for one way verification iirc 22:39 <+bridge> [ddnet] In 0.6 22:39 <+bridge> [ddnet] ? 22:39 <+bridge> [ddnet] ah ye 22:39 <+bridge> [ddnet] i remember 22:40 <+bridge> [ddnet] I see 22:42 <+bridge> [ddnet] I guess I'll need to keep track of ddnet too, to dissect TKEN properly 22:43 <+bridge> [ddnet] can also be detected by having exactly four bytes remaining after decoding four chunks 22:43 <+bridge> [ddnet] *all 22:44 <+bridge> [ddnet] I already keep state for the connection. Might aswell keep this there too 22:45 <+bridge> [ddnet] fair 22:48 <+bridge> [ddnet] Wireshark has a rather meh plugin system 22:48 <+bridge> [ddnet] please do publish your even unfinished end result 😉 22:48 <+bridge> [ddnet] it'll be interesting to look at 22:49 <+bridge> [ddnet] Idk how best to publish it tbh, you are supposed to develop plugins in tree 22:49 <+bridge> [ddnet] I guess I could have an entire fork of wireshark 22:50 <+bridge> [ddnet] fstd did that IIRC 22:50 <+bridge> [ddnet] Ah I'll host the teeworlds folder 22:50 <+bridge> [ddnet] Add the folder as a submodule 22:51 <+bridge> [ddnet] 👍 22:51 <+bridge> [ddnet] I like how well plugins integrate though, when you dissect in a plugin it looks exactly like a native dissector 22:52 <+bridge> [ddnet] You have access to exactly the same features as a built in dissector too 22:52 <+bridge> [ddnet] ye 22:56 <+fstd> Learath2: you're going to lua that? 23:04 <+bridge> [ddnet] @Learath2 nice on the dissector 23:09 <+bridge> [ddnet] fstd: nah sticking to C 23:12 <+fstd> probably for the better, it makes the decompression and deserialization copypastable 23:12 <+fstd> would suck to reimplement that in lua I suppose 23:25 <+bridge> [ddnet] <Андрей Рудой> Why there is no moving platforms or dynamically changing blocks on maps? 23:25 <+bridge> [ddnet] <Андрей Рудой> I'm sure this idea already was in some minds 23:25 <+bridge> [ddnet] The only implementation of it was on kog and it wasnt clean enough to add to ddnet iirc 23:26 <+bridge> [ddnet] <Андрей Рудой> So maybe ddnet should be initiator of this change? Not static maps would be great to see 23:29 <+bridge> [ddnet] Let me take a look at kogs implementation again 23:29 <+bridge> [ddnet] @qshar can I take a look pls?