00:05 < bridge> <gorp_tw> why is this like a sick beat
00:05 < bridge> <gorp_tw> it reminds me of like a druim line stop
00:36 < bridge> <kebscs> would be so nice for 20.0 if we can get this 3 prediction prs merged :D
00:36 < bridge> <kebscs> teles, sounds, dummy
00:46 < bridge> <gorp_tw> and freeze behavior tune
00:46 < bridge> <gorp_tw> :D
00:46 < bridge> <gorp_tw> (plz)
00:49 < bridge> <louis> what constitutes major vers change?
00:51 < bridge> <totar> 18.9 -> 19.0 and 16.9 -> 17.0 were just because we reached 9 minor versions, but we skipped that for 17.4 -> 18.0
00:51 < bridge> <totar> idk why
00:52 < bridge> <totar> I don't think there was anything that crazy in 18.0
00:59 < bridge> <louis> okay so its just off vibes i guess :greenthing:
02:38 < bridge> <gorp_tw> https://discord.com/channels/252358080522747904/745926398140612678/1445224685146210420 thoughts on this?
02:38 < bridge> <gorp_tw> for an issue
02:39 < bridge> <gorp_tw> i was thinking you could parameterize some prefix like `clear_lines ***`
02:39 < bridge> <gorp_tw> er, i guess that would be what would be kept
02:39 < bridge> <gorp_tw> `clear_except ***`
02:40 < bridge> <gorp_tw> im not sure there are usecases outside of `***` and getting the motd kept seems weird
02:43 < bridge> <gorp_tw> `clear_console_chat` is a more intuitive way of doing what they want, it should show all mapfile demo_recorder motd and chat/server except `: ***` starting lines
02:43 < bridge> <gorp_tw> ah wait, `chat/whisper` and `chat/all` would be removed, entirely of `chat/server` would not be affected
02:43 < bridge> <gorp_tw> ah wait, `chat/whisper` and `chat/all` would be removed, entirety of `chat/server` would not be affected
02:44 < bridge> <gorp_tw> i think this is useful for dumping logs of things happening without worrying about weird things sent in chat
02:44 < bridge> <gorp_tw> `clear_types chat/whisper chat/all` is another wayt
02:44 < bridge> <gorp_tw> `clear_types chat/whisper chat/all` is another way
03:48 < bridge> <dhsauid> @everyone Listen: Сhеck this оut… ‼️
03:49 < bridge> <dhsauid> ||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​||||​|
08:01 < bridge> <chillerdragon> What message assa?
08:02 < bridge> <chillerdragon> Oh you mean snap size
08:02 < bridge> <Assa> ye
08:02 < bridge> <chillerdragon> Yea if you can keep it out of the snap and it still works that would be great
08:03 < bridge> <chillerdragon> The maximum snap size is super low
08:03 < bridge> <chillerdragon> And everything will be worse with 128 pr
08:03 < bridge> <Assa> idk if thats possible with the translated id
08:04 < bridge> <chillerdragon> You can easily run into snap sizes already if you have a few pickups
08:04 < bridge> <chillerdragon> limits\*
08:04 < bridge> <chillerdragon> What translated Id
08:16 < bridge> <remakepower> I have to say that
08:20 < bridge> <remakepower> Since snapshots are incremental, I’ve always believed we should limit the incremental portion itself, not the size of the source data.
08:22 < bridge> <Assa> idk how to do this, I am still learning netcode
08:29 < bridge> <learath2> Wasnt 18.0 the community update?
08:30 < bridge> <Assa> the next update will be the scoreboard update 😄
08:30 < bridge> <Assa> maybe with 20 we get a new tile, if sb. finally merges my cleanup PR
08:31 < bridge> <totar> I guess yeah
08:36 < bridge> <totar> idk, I don't really feel like there's much that justifies skipping a major version cycle
08:36 < bridge> <learath2> Well it is vibes based
08:37 < bridge> <totar> android support was a minor version, but I guess you could say that doesn't affect most players
08:37 < bridge> <Assa> I'd argue that's just "yet another os", even if I know full well, that it's hard and much effort
08:38 < bridge> <Assa> did anybody ever check if were steam-deck ready?
08:38 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1445318296466489404/image.png?ex=692fe90e&is=692e978e&hm=aa1a54f77b2cd25947c4969a6ce6a178f0579828e879917bbd67229314e983d7&
08:39 < bridge> <Assa> was about to post the same image 😄
08:40 < bridge> <learath2> They should send me a steam deck so I can optimize it
08:40 < bridge> <totar> damn what happened here? we figured out how to use a fuzzer?
08:40 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1445318683441238016/image.png?ex=692fe96a&is=692e97ea&hm=80e049b7f4cb9e35e392b50f542ba662d955f9553dc1a90ae069b6d0cc2f7260&
08:40 < bridge> <Assa> was about to write the same thing 😄
08:41 < bridge> <Assa> patiga involved, maybe twmap dropped 🤔
08:41 < bridge> <learath2> I think someone with a fuzzer reported like 3 things, then we tried to clean up everything asan, ubsan and valgrind reports, just for good measure
08:44 < bridge> <totar> wait what, do we still have this
08:44 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1445319768101093447/image.png?ex=692fea6d&is=692e98ed&hm=069c21f009f93580a72e8d3e8d55e13cd1171ec6c6867b6816b4a3108ae69257&
08:46 < bridge> <totar> huh
08:46 < bridge> <totar> oh it's off by default
08:46 < bridge> <totar> does the binary ship with it?
08:47 < bridge> <totar> huh it does
08:48 < bridge> <totar> it was less optimized before??
08:49 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1445320831738707980/image.png?ex=692feb6b&is=692e99eb&hm=a5896d0fd6d51584892fad7a31cb3c9ce2ba6695d1edaf5851c2c66e3dfc5e04&
08:52 < bridge> <Assa> chiller u there?
08:53 < bridge> <totar> one person in history got their player page linked in the patch notes lol
08:53 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1445321866716647476/image.png?ex=692fec61&is=692e9ae1&hm=893fccb1eeec0aea0d64c46affe4d62e9a17716343fdfcc28a188c0ee154bbd6&
09:03 < bridge> <Assa> omg you can put yourself on your own friendlist xD
09:03 < bridge> <Assa> guess it makes sense on a string based system
09:04 < bridge> <Assa> omg we could use this for quick join after timeout protection
09:33 < bridge> <Assa> > A PRNG takes a pseudo-random state and produces another pseudo-random state
09:33 < bridge> <Assa> @totar but you are aware, that you can set a pseudo-random-state once, and just forward new random states from there and this is deterministic?
09:34 < bridge> <totar> yes I'm aware
09:34 < bridge> <Assa> I have no problem with your murmur3 impl, just saying, because it sounds like this
09:35 < bridge> <Assa> time to checkout and break kebs particle prediction
09:35 < bridge> <totar> how do you suggest using a prng for teleport prediction?
09:37 < bridge> <Assa> basically the same tbh, but combined
09:37 < bridge> <Assa> like have a prgn on both server and client side, synced to game tick
09:37 < bridge> <Assa> like have a prgn on both server and client side, synced to game tick (meaning you forward it once with the game tick)
09:38 < bridge> <Assa> and then scramble with a hashing function
09:38 < bridge> <Assa> oh look I am at your impl, but we don't need to send the seed every tick, but only once
10:13 < bridge> <Assa> @kebscs your prediction PR needs the teleport PR from @totar or your nades fully desync and are just doing bullshit xD
10:13 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1445342127960756355/screenshot_2025-12-02_10-12-32.png?ex=692fff40&is=692eadc0&hm=15d1296327443ee63084641fbaf0cbb858b2c4265b27ee19f83796dc4252e542&
10:14 < bridge> <Assa> I am shooting at a weapon teleport
10:14 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1445342249184661524/screenshot_2025-12-02_10-13-52.png?ex=692fff5d&is=692eaddd&hm=41b20e9a5768719e9000e63c347a8fdae7455345a9f282887faff1b759047747&
10:14 < bridge> <kebscs> If you stand next to the tele you'll be pushed and teleported  back
10:14 < bridge> <kebscs> This is not the particle issue
10:15 < bridge> <totar> ok, lets say I am predicting 10 ticks into the future, the prng the server sent me is now 10 ticks old. In the past 10 ticks of prediction I teleported 3 items, and myself, but without my knowledge someone else also teleported an item in those 10 ticks. How do you handle this?
10:15 < bridge> <Assa> I actually do, I also get some random explosion animation at other positions :thonk:
10:16 < bridge> <Assa> oh no I am confusing myself with multiple exits
10:18 < bridge> <Assa> the server sends you a prng seed once, when you join. you sync the prng to the tick, meaning you forward it tick times. if you are predicting 10 ticks in the future, your prediction should have forwarded the prng 10 ticks
10:18 < bridge> <b lazu wjelgook.i> Good morning fellow devs
10:18 < bridge> <Assa> what do you not understand about that
10:19 < bridge> <Assa> I am not forwarding the prng with each interaction
10:19 < bridge> <Assa> we still murmur3 the current prng value with the other values
10:19 < bridge> <kebscs> Won't this make tele predictable per tick
10:20 < bridge> <Assa> absolutely
10:20 < bridge> <kebscs> Murmur mixes clientid in it so regular player can't predict it
10:20 < bridge> <Assa> doesn't the current implementation do this too?
10:20 < bridge> <kebscs> By looking at clock
10:20 < bridge> <Assa> like I can find the seed of the current implementation
10:21 < bridge> <kebscs> But with just prn you'll always go into same tele out at same tick
10:21 < bridge> <Assa> no, because we mix the player position and id with it
10:21 < bridge> <totar> incrementing the prng every tick makes no difference if you're going to do this anyway
10:22 < bridge> <totar> the whole point of the hash is that if any of the inputs change it makes a completely random output
10:22 < bridge> <Assa> I understand that
10:22 < bridge> <Assa> my point abut the prng is that you don't need to send it every tick, but just once
10:23 < bridge> <totar> I thought you already asked this
10:23 < bridge> <Assa> heinrich asked that
10:23 < bridge> <Assa> heinrich asked that (in the PR)
10:23 < bridge> <totar> it was kebs
10:24 < bridge> <totar> if we did this for every value that didn't change every tick we would have 20 more snapshot objects
10:25 < bridge> <Assa> my only point in using a prng is, that we can reduce bandwith even more
10:25 < bridge> <Assa> it has the downside of making the seed known on client side and everything entirely predictable
10:26 < bridge> <totar> 🫠
10:26 < bridge> <totar> can I ping chatgpt
10:26 < bridge> <totar> how do I do that
10:26 < bridge> <Assa> maybe we need a vc
10:27 < bridge> <Assa> and I stream paint and we make drawings xD
10:27 < bridge> <Assa> imo your implementation is working really well and I don't care too much
10:27 < bridge> <kebscs> Read this
10:28 < bridge> <kebscs> If prng takes last value, what if they do it off screen
10:28 < bridge> <Assa> you do, you have a seed per character snap if I am not mistaken (in current impl)
10:28 < bridge> <Assa> ah
10:28 < bridge> <kebscs> The seed is static
10:28 < bridge> <kebscs> For prng it would change every time
10:32 < bridge> <Assa> no?
10:33 < bridge> <Assa> no? With my proposal the prng-value per tick is entirely deterministic for each player
10:33 < bridge> <Assa> guys, what is a seed for you? If I talk of a seed of a prng, i mean the INITIAL START VALUE, not the generated ones
10:34 < bridge> <Assa> @kebscs I can make looping grenades which misspredict every tick with some funny setup xD
10:36 < bridge> <Assa> neat setup making your prediction think you're out of the mapborder when you arent xD
10:38 < bridge> <Assa> `length(pTarget->m_Pos - ProjStartPos) > 0.0f`
10:38 < bridge> <Assa> 
10:38 < bridge> <Assa> Who wrote this
10:39 < bridge> <Assa> who do I need to lynch?
10:39 < bridge> <totar> why is this so bad
10:39 < bridge> <totar> ah hmm
10:39 < bridge> <totar> it is bad
10:39 < bridge> <totar> but 1 length is a drop in the bucket
10:40 < bridge> <kebscs> Mate i didn't add nade prediction
10:41 < bridge> <kebscs> Just for the prediction to show visual
10:41 < bridge> <kebscs> If it's broken, it was broken before, just you didn't see it
10:41 < bridge> <kebscs> Explosion pushing people was still there
10:41 < bridge> <Assa> I know, my point is that the teleport prediction just has higher priority right now, and that your PR would benefit greatly from it
10:42 < bridge> <Assa> yes I saw that
10:43 < bridge> <Assa> @kebscs do you actually not understand, why it's **mathematically** the same as `pTarget->m_Pos != ProjectPos` ?
10:43 < bridge> <kebscs> I don't want change server code
10:44 < bridge> <Assa> yes this is fine and a good explanation, that is not why I am asking 😄
10:45 < bridge> <kebscs> It's the same if you're asking, I just copied it and didn't look
10:46 < bridge> <Assa> I guess, I just keep stumbling over bad server code in the prediction, because it copies it
10:47 < bridge> <Assa> I wonder if it's actually that bad, since normalize probably uses length
10:55 < bridge> <totar> it's actually kinda important that we do it the exact same way
10:55 < bridge> <totar> it's possible that there's floating point bullshit that makes it not the same as ``pTarget->m_Pos != ProjectPos``
10:56 < bridge> <Assa> exactly 🤷‍♂️ I am also fine with it just beeing copied server code
10:58 < bridge> <totar> ok here is chatgpt reading our whole conversation
10:58 < bridge> <totar> 
10:58 < bridge> <totar> > The core problem isn’t “PRNG vs hash”, it’s “stateful RNG vs stateless RNG”.
10:58 < bridge> <totar> > We can’t use any RNG that depends on how many times rand() has been called, because the client doesn’t see every teleport / projectile / off–screen event that might consume randomness.
10:58 < bridge> <totar> > So we need teleport choice to be a pure function of stuff that both client and server know (tick, ids, etc) plus a hidden seed from the server. That’s what the hash-based approach is doing.
10:58 < bridge> <totar> > What you’re calling “PRNG synced to tick” basically collapses to the same thing: a stateless function R(tick, seed). At that point it is just a hash with a seed.
10:59 < bridge> <Assa> so chat gpt agrees with me
10:59 < bridge> <Assa> 🫠
10:59 < bridge> <totar> .-.
11:00 < bridge> <Assa> we are not calling rand() for every interaction, we have one rand() per tick, which we then use for the has
11:00 < bridge> <Assa> we are not calling rand() for every interaction, we have one rand() per tick, which we then use for the hash
11:00 < bridge> <totar> can you please state your proposed teleport procedure in sufficient depth for me to know what you're asking
11:00 < bridge> <Assa> again why do I propose that? So we only need to send a seed once
11:00 < bridge> <totar> that's already how it works
11:00 < bridge> <Assa> then why do you need to send the seed every tick?
11:01 < bridge> <Assa> or is it always the same seed, that then gets removed by snapshot delta?
11:01 < bridge> <totar> am I talking to a goldfish? what
11:01 < bridge> <totar> you gave a thumbs up to this message 5 minutes ago
11:02 < bridge> <Assa> give me a sec
11:03 < bridge> <Assa> https://github.com/ddnet/ddnet/pull/11321/files#r2580478973
11:03 < bridge> <Assa> you are setting the seed every snap
11:03 < bridge> <totar> ok??
11:04 < bridge> <Assa> why?
11:04 < bridge> <totar> the server is allowed to change it on any snap
11:04 < bridge> <totar> if a player leaves and rejoins it will get a new rng value
11:04 < bridge> <totar> or if it goes offscreen and comes back
11:04 < bridge> <totar> like what
11:04 < bridge> <Assa> but it's usually the same?
11:04 < bridge> <totar> skljdflsj
11:05 < bridge> <totar> so we can just delete all that code
11:05 < bridge> <totar> just assume it's usually the same
11:05 < bridge> <totar> why even ask the server for information
11:05 < bridge> <totar> we can just assume
11:06 < bridge> <Assa> note I linked the server code
11:06 < bridge> <Assa> wdym by that, like this point specifially?
11:07 < ws-client> **<ChillerDragon>** vps provider lost all my data and compensated me with 10 euros pog
11:07 < bridge> <Assa> wdym by that, like this point specifically?
11:08 < bridge> <totar> did you see what ``pDDNetCharacter`` is
11:08 < bridge> <totar> ```cpp
11:08 < bridge> <totar>     CNetObj_DDNetCharacter *pDDNetCharacter = Server()->SnapNewItem<CNetObj_DDNetCharacter>(Id);
11:08 < bridge> <totar> ```
11:09 < bridge> <totar> it's empty
11:09 < bridge> <totar> if we dont' set the value the client will get zeros
11:09 < bridge> <Assa> ah nevermind I understand the offscreen one now, it's for other clients ofc
11:13 < bridge> <Assa> very last question @totar, do we really need different seeds for every player instead of a single seed for everyone when we hash with the client id anyway?
11:16 < bridge> <Assa> because this would allow us to handle even offscreen players.
11:18 < bridge> <totar> technically no, but having it per player allows you to change it without breaking prediction for everyone and it's basically the same effort.
11:18 < bridge> <totar> 
11:18 < bridge> <totar> also "handle even offscreen players" is not a thing that we do. offscreen in this context players *don't exist* to the client. they aren't predicted at all
11:19 < bridge> <Assa> I see the benefits to it, but don't tell me you don't have an additional feature for this in mind 😉
11:20 < bridge> <Assa> I already approved your request ages ago, and I am 99% sure I understand it, even if you think I am a goldfish
11:25 < bridge> <totar> I simply prefer it to be per-player because as a logical separation, but it's not strictly necessary. The semi-realistic minor motivation is that it would allow a server to aggressively randomize the seed of each player like when they touch the start line or enter/exit spec to prevent TAS without making the entire server desync.
11:26 < bridge> <Assa> >  to prevent TAS without making the entire server desync.
11:26 < bridge> <Assa> Additional feature in mind 👆
11:26 < bridge> <Assa> >  to prevent TAS without making the entire server desync.
11:26 < bridge> <Assa> Additional feature in mind 👆 This is exactly what I was thinking
11:26 < bridge> <totar> that's just an example, I think doing it this way is good future proofing and more useful to servers.
11:26 < bridge> <Assa> I agree and I like it 🙂
11:27 < bridge> <totar> if someone later decides to add some physics that uses this randomness because we made it predictable then it could become more impactful later
11:28 < bridge> <totar> also we don't really have any place to put "gameworld" state, so this way is similarly simple
11:29 < bridge> <pioooooo> What do you think of this? Sounds like flooding server with their input 
11:29 < bridge> <pioooooo> https://discord.com/channels/252358080522747904/757720336274948198/1445095959762829483
11:30 < bridge> <Assa> I already pinged Robyt about that, because I experienced this myself
11:30 < bridge> <Assa> But I didn't want to make it public :lol:
11:31 < bridge> <totar> it would be useful if someone could take a traffic capture of what they're doing so it can be fixed
11:31 < bridge> <totar> they're only sending 1000 packets/tick so it should be filterable by the server, but idk what it is
11:37 < bridge> <byfox> On teefusion, I saw bad packets arriving at a length of 600* that did not pass blocking through XDP (eXpress Data Path)
11:46 < bridge> <totar> it would be nice to know *which* packet tho
12:27 < bridge> <Assa> When you need to send the support a video, because they don't understand your issue ....
12:27 < bridge> <Assa> I guess ddnet is there no different xD
15:26 < bridge> <Assa> the client doesn't allow me to set unknown server settings in mapsettings anymore ;_;
16:04 < bridge> <kebscs> Press allow unknown settings checkbox
16:24 < bridge> <Assa> doesn't work
16:26 < bridge> <Assa> do you mean this?
16:26 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1445435936354599013/screenshot_2025-12-02_16-26-09.png?ex=6930569e&is=692f051e&hm=f011db86183ac81d0d14d4010d5973a3b8091985a174c1da2f39706419bd0474&
16:40 < bridge> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1445439375809974354/image.png?ex=693059d2&is=692f0852&hm=ff49e782b6d5fe8b85b024fbdc151af8495bc05ebd326c8efd3aff0539c2c497&
16:40 < bridge> <kebscs> @essigautomat
16:41 < bridge> <0xdeen> Question mark is kind of unclear symbol here, I would have expected that it shows you some explanation
16:41 < bridge> <kebscs> yea editor ui is bad in a lot of places
16:44 < bridge> <Assa> :pepeW: thank you
17:25 < bridge> <chillerdragon> @murpi: what is migrated from where to where?
17:35 < bridge> <murpi> chillerdragon: Everything tied to ddnet.org. deen set up a new, much more powerful server for us.
17:49 < bridge> <kebscs> @essigautomat idk how it works but the proejctiles can have multiple ids
17:49 < bridge> <kebscs> so itll have duplicates
18:01 < bridge> <Assa> ?! okay wth
18:04 < bridge> <kebscs> yea the fire weapon prediction spawns the projectile with id -1
18:06 < bridge> <kebscs> and the real id comes from the snap i guess
18:07 < bridge> <kebscs> i think i can use start tick then
18:10 < bridge> <Assa> oh we have that, that'd be great ❤️
18:18 < bridge> <kebscs> hooking: 🟢 (mostly)
18:18 < bridge> <kebscs> whats not predicted? @essigautomat
18:25 < bridge> <Assa> telehooks 😄 traffic light is green, don't worry
18:27 < bridge> <Assa> can't review today anymore, have a nice evening
20:13 < bridge> <Lagar> These maps also showed as unfinished even if u finished them in website
21:23 < bridge> <alw5> @0xdeen with the new infrastructure could this make http://ddnet.org/stats/ddnet.sqlite.zip update more often instead of daily ?
21:25 < bridge> <0xdeen> why?
21:27 < bridge> <alw5> for the services that rely on the dump
21:27 < bridge> <0xdeen> which services?
21:27 < bridge> <alw5> ddstats.tw
21:28 < bridge> <alw5> and ddstats from ryo
21:28 < bridge> <alw5> if anyone wants to host it
21:29 < bridge> <teero777> we just want #records back, an unofficial clone couldn't directly report any r1s but would have to wait for a day 🥲
21:29 < bridge> <teero777> Sadly i don't think this is easily achievable
21:29 < bridge> <alw5> could also be a thing
21:45 < bridge> <Assa> you could also depay # records bay exaxtly 24h
21:45 < bridge> <Assa> you could also delay # records bay exaxtly 24h
21:45 < bridge> <Assa> you could also delay # records by exaxtly 24h
21:45 < bridge> <Assa> you could also delay # records by exactly 24h