00:02 < bridge> I guess I do the fix before the prediction ... 00:13 < bridge> 🐝ing 00:13 < bridge> 🛏️ ing 01:08 < bridge> why is this mix, I can't sleep, because there is a third bug in this piece of code 06:43 < bridge> 11:33 < ws-client> **** wtf gif xd 11:36 < bridge> i overslept by 6h how is this possible 11:46 < bridge> database desynced .... now it's finally working, didn't notice yesterday 11:46 < bridge> idk how ddnet handles this 11:46 < bridge> I hope not like we do ;_; 12:00 < bridge> I hope my explanation on the PR was good enough so @totar doesn't melt :owo: 12:01 < bridge> I'm already writing another explanation it's ok 12:09 < bridge> that's intended behavior 12:10 < bridge> for some reason 12:10 < bridge> if you don't allow it to drift it causes stutter when I tried 12:10 < bridge> if you don't allow it to drift it causes stutters when I tried 12:11 < bridge> you can compenstate for it in the same way the game does 12:12 < bridge> the intra game tick? 12:12 < bridge> yes 12:13 < bridge> only intrapred tick is 0->1 12:13 < bridge> yes it should be allowed to drift, but it's still off 12:13 < bridge> like very off, it should be around 0 -> 2 12:14 < bridge> I almost want to put a stochastical analyzer on it in order to calculate average and mean and then correct it 12:15 < bridge> the server is allowed to send snapshots at any rate it wants 12:15 < bridge> the compensation is done with intratick 12:15 < bridge> oh really - then it's still off at this rate 😄 12:16 < bridge> ? 12:16 < bridge> like I measure the snap rate as well, and it was never not 2 12:16 < bridge> so why isn't the compensation fixing itself properly 12:17 < bridge> intratick *is* the compensation 12:17 < bridge> it doesn't do what it says 12:17 < bridge> you have to do more math to get the real intratick 12:17 < bridge> yes, that's what I mean 12:17 < bridge> exactly, this is what this issue is about 12:19 < bridge> > IntraTick = GameClient()->m_SmoothIntraTick[g_Config.m_ClDummy]; 12:19 < bridge> :kek: 12:20 < bridge> you added an extra, this doesn't exist in the client, does it? 12:20 < bridge> that's for tclient prediction feature, I fucked shit up extra 12:21 < bridge> so I had to extra unfuck it 12:21 < bridge> m_TcRemoveAnti 12:22 < bridge> btw, I have an idea how to "fix" it 12:22 < bridge> it dynamically adjusts your prediction margin when based on your freeze timer to make it easier to react 12:22 < bridge> it dynamically adjusts your prediction margin based on your freeze timer to make it easier to react 12:30 < bridge> it's also not mixed correctly in the envelopes, like sb assumed the intra tick would be 0->1 and mixing returnts values between 0->4 then 12:54 < bridge> @totar this works butter smooth: 12:54 < bridge> 12:54 < bridge> ```C++ 12:54 < bridge> // correct for janky intra tick values 12:54 < bridge> float IntraTick = Client()->IntraGameTick(g_Config.m_ClDummy); 12:54 < bridge> 12:54 < bridge> // collect the biggest and smallest measured intratick from the last tick 12:54 < bridge> if(m_LastTick != EnvelopeTick) 12:54 < bridge> { 12:54 < bridge> m_LastIntraTickMax = (3 * m_LastIntraTickMax + m_LastIntraTick) / 4.0f; 12:54 < bridge> m_LastIntraTickMin = (3 * m_LastIntraTickMin + IntraTick) / 4.0f; 12:54 < bridge> } 12:54 < bridge> 12:54 < bridge> TickRatio = std::clamp((IntraTick - m_LastIntraTickMin) / (0.5 * (m_LastIntraTickMax - m_LastIntraTickMin)), 0.0, 2.0); 12:54 < bridge> 12:54 < bridge> m_LastIntraTick = IntraTick; 12:54 < bridge> m_LastTick = EnvelopeTick; 12:54 < bridge> ``` 12:54 < bridge> 12:54 < bridge> TickRatio is the new intra tick between 0->2 12:55 < bridge> ``` 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1414, IntraTick 1.294588, Ratio 1.720020 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1414, IntraTick 1.302272, Ratio 1.735519 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1414, IntraTick 1.310502, Ratio 1.752119 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1416, IntraTick 0.317741, Ratio 0.000000 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1416, IntraTick 0.325533, Ratio 0.000000 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1416, IntraTick 0.334814, Ratio 0.000000 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1416, IntraTick 0.342098, Ratio 0.000000 12:55 < bridge> 2025-12-04 12:53:24 I dbg: GameTick 1416, IntraTick 0.349143, Ratio 0.000000 12:55 < bridge> ``` 12:55 < bridge> 12:55 < bridge> Still not flawless, but better than before 12:55 < bridge> I need to un-hardcode the 2 12:57 < bridge> does adding state that can potentially be wrong not fill you with a deep sense of dread? 12:57 < bridge> all of this animation code fills me with dread 12:57 < bridge> also the states update themselfes 12:58 < bridge> yes but there's so many bugs this could introduce 12:58 < bridge> in the animation? like? 12:58 < bridge> the server can and does decide to change the snapshot rate willy nilly 12:59 < bridge> @totar this works butter smooth: 12:59 < bridge> 12:59 < bridge> ```C++ 12:59 < bridge> // correct for janky intra tick values 12:59 < bridge> float IntraTick = Client()->IntraGameTick(g_Config.m_ClDummy); 12:59 < bridge> 12:59 < bridge> // collect the biggest and smallest measured intratick from the last tick 12:59 < bridge> if(m_LastTick != EnvelopeTick) 12:59 < bridge> { 12:59 < bridge> m_LastIntraTickMax = (3 * m_LastIntraTickMax + m_LastIntraTick) / 4.0f; 12:59 < bridge> m_LastIntraTickMin = (3 * m_LastIntraTickMin + IntraTick) / 4.0f; 12:59 < bridge> } 12:59 < bridge> 12:59 < bridge> double TickDifference = EnvelopeTick - PrevGameTick; 12:59 < bridge> 12:59 < bridge> TickRatio = std::clamp(TickDifference * (IntraTick - m_LastIntraTickMin) / (m_LastIntraTickMax - m_LastIntraTickMin), 0.0, TickDifference); 12:59 < bridge> 12:59 < bridge> m_LastIntraTick = IntraTick; 12:59 < bridge> m_LastTick = EnvelopeTick; 12:59 < bridge> ``` 12:59 < bridge> 12:59 < bridge> TickRatio is the new intra tick between 0->2 12:59 < bridge> I can imagine now the report of "once every 30 minutes my camera moves all the way across the map" 12:59 < bridge> and someone spends 10 hours debugging this 12:59 < bridge> @totar this works butter smooth: 12:59 < bridge> 12:59 < bridge> ```C++ 12:59 < bridge> // correct for janky intra tick values 12:59 < bridge> float IntraTick = Client()->IntraGameTick(g_Config.m_ClDummy); 12:59 < bridge> 13:00 < bridge> // collect the biggest and smallest measured intratick from the last tick 13:00 < bridge> if(m_LastTick != EnvelopeTick) 13:00 < bridge> { 13:00 < bridge> m_LastIntraTickMax = (3 * m_LastIntraTickMax + m_LastIntraTick) / 4.0f; 13:00 < bridge> m_LastIntraTickMin = (3 * m_LastIntraTickMin + IntraTick) / 4.0f; 13:00 < bridge> } 13:00 < bridge> 13:00 < bridge> double TickDifference = EnvelopeTick - PrevGameTick; 13:00 < bridge> 13:00 < bridge> TickRatio = std::clamp(TickDifference * (IntraTick - m_LastIntraTickMin) / (m_LastIntraTickMax - m_LastIntraTickMin), 0.0, TickDifference); 13:00 < bridge> 13:00 < bridge> m_LastIntraTick = IntraTick; 13:00 < bridge> m_LastTick = EnvelopeTick; 13:00 < bridge> ``` 13:00 < bridge> 13:00 < bridge> TickRatio is the new intra tick between 0->2 13:00 < bridge> we are talking about envelope animations here 13:00 < bridge> not enough fear in your heart 13:00 < bridge> maybe that's fine then 13:00 < bridge> I could just slap the prediction tick on it and call it a day 13:00 < bridge> but the bug can still exist 13:00 < bridge> then the rate adjusts to it pretty fast? 13:01 < bridge> I even clamp between 0.0 and TickDifference 13:01 < bridge> idk everything about this makes me feel bad, the game *does* know the true intratick, you've just decided to insulate yourself from it and add some fragile code that relies on behavior that you don't know the full extent of 13:02 < bridge> lmao 13:02 < bridge> it probably does work fine 13:02 < bridge> I just hate it 13:03 < bridge> I hate that the game doesn't provide me of an accurate enough intra game tick 13:03 < bridge> maybe fix that problem then? 13:03 < bridge> 1.4 ticks and then jumping to 0.4 ticks is equally bad 13:03 < bridge> you can make a new variable that is the thing you want 13:03 < bridge> issue is open 🤷‍♂️ I wouldn't open an issue if I knew how to fix it 13:06 < bridge> btw for me this looks like a bigger bug 13:06 < bridge> btw for me this looks like a bigger bug somewhere 13:19 < bridge> yo btw https://github.com/ddnet/ddnet/blob/master/scripts/compile_libs/gen_libs.sh here on the lines where it calls the other files it should be bash instead of ./ 13:19 < bridge> atleast it failed for me with a ./ even though the files had execution rights. 13:19 < bridge> ll. 85, 108, 120 13:24 < bridge> the only real solution is just to predict it. 13:24 < bridge> hiiiiiii 13:25 < bridge> Prediction destroyed mods. :3 13:26 < bridge> bald statement, probably some thruth to it, overly generalized. Do you want me to vote for you in the next selection? 13:26 < bridge> bald statement, probably some thruth to it, overly generalized. Do you want me to vote for you in the next election? 13:26 < bridge> bold statement, probably some thruth to it, overly generalized. Do you want me to vote for you in the next election? 13:26 < bridge> What's the vote? 13:27 < bridge> :thonk: 13:27 < bridge> bold statement, probably some truth to it, overly generalized. Do you want me to vote for you in the next election? 13:28 < bridge> my point is this is not fully true, we still have mods and some even updated to ddnet netcode 13:29 < bridge> and there was more to it, why 0.7 failed 13:29 < bridge> but who looks at facts nowadays if you can instead have an unprecise headline 13:30 < bridge> Yeah 13:30 < bridge> @essigautomat do you use soundcloud? 13:30 < bridge> Great modder always find ways to break the limitation. 13:31 < bridge> Great modder always finds ways to break the limitation. 13:31 < bridge> we have per player tune zones now which should allow you to un-break a lot of stuff 13:31 < bridge> the tune zone override 13:33 < bridge> However, DDNet keeps some tiles for its self. 13:33 < bridge> It's hard to use them if they have other behaviors in your mods. 13:33 < bridge> I am still working on the tune-lock-tile map, but I am honestly overwhelmed by the possibilities 13:34 < bridge> no 13:35 < bridge> yeah you could avoid sending them to the client, but then you'd need to rely on design. 14:55 < bridge> >projectile teleportation: owner ID, game tick. 14:55 < bridge> tee teleporation: ID, game tick. 14:55 < bridge> 14:55 < bridge> This would cause projectiles by the owner to be teleported to the same exit teleporter if they teleport in the same tick. 14:55 < bridge> 14:55 < bridge> @totar for projectiles you also mix starttick and mapindex 14:56 < bridge> so its not just based on tick they enter the tele so it wont happen? 14:56 < bridge> + owner id so 2 people shooting at the same time wont have same result 14:58 < bridge> it also mixes in the game tick, I didn't explicitly write that 14:58 < bridge> so it's like maximum distropy 14:59 < bridge> yea i dont see how 2 projectiles could "collide" 15:00 < bridge> yes, this is what we are trying to explain to heinrich 15:00 < bridge> but heinrich is correct, we should mix in the projectile type as well 15:00 < bridge> I missunderstood that before 15:02 < bridge> why? 15:02 < bridge> isnt all of the above enough?> 15:02 < bridge> well techncially it should, assuming you can't create two projectiles of different types with the same start tick 15:02 < bridge> well technicially it should, assuming you can't create two projectiles of different types with the same start tick 15:03 < bridge> well technically it should, assuming you can't create two projectiles of different types with the same start tick 15:04 < bridge> bcs of physics, different type of projectile wont have same start tick and time they enter tele 15:05 < bridge> maybe shotgun, laser only 15:06 < bridge> I'd still mesh it in, because it doesn't hurt and makes the code more robust for the worst case 15:06 < bridge> i guess 15:34 < ws-client> **** this has to be the most cursed code i ever wrote https://paste.zillyhuhn.com/HF never thought i will end up there in my life 18:09 < bridge> Why does every compiler/compiler backend use S-expression like syntax for their instruction selection DSL`s, it is unreadable https://github.com/gcc-mirror/gcc/blob/31ec203247413f150d5244198efd586fc6d2ef5e/gcc/config/i386/i386.md#L1343-L1351 :pepeW: 18:29 < bridge> <0xdeen> > Mostly by William Schelter. 18:29 < bridge> <0xdeen> https://en.wikipedia.org/wiki/Bill_Schelter 18:29 < bridge> <0xdeen> > Schelter is credited with the development of the GNU Common Lisp (GCL) implementation of Common Lisp 18:31 < bridge> cranelift ISLE also uses such syntax https://github.com/bytecodealliance/wasmtime/blob/058a9bc16bc204fec05993ce6a0b013cc3db55e6/cranelift/codegen/src/isa/x64/inst.isle 19:23 < bridge> @kebscs can you explain to me what does? I don't see any difference between preinput enabled and disabled 19:25 < bridge> there is some jank 19:25 < bridge> where timeout protection activates 19:25 < bridge> m_PredictedDummyId wont be updated 19:25 < bridge> so every time u move the preinputs will be randomly applied 19:26 < bridge> hmm I finished a solo race map and the dummy was perfectly behind me with 0.3 seconds delay doing a replay attack 🙂 19:26 < bridge> so I guess this issue is fixed? 19:26 < bridge> idk how to reproduce consistently, but it has to do smth with timeout protection and dummy copyu 19:26 < bridge> idk how to reproduce consistently, but it has to do smth with timeout protection and dummy copy 19:26 < bridge> the new code looks better to me anyways 19:26 < bridge> i dont see merge 19:27 < bridge> the point of asking you is to understand the PR better in order to boost up merge speed 19:27 < bridge> bug a timeout for you is also fine 🙂 19:27 < bridge> bug a timeout for you is also fine 🙂 :kek: 19:29 < bridge> bad bot 19:29 < bridge> :C 19:29 < bridge> i misunderstood you 19:29 < bridge> idk if it fixes your issue 20:42 < bridge> hmhmhmhm scoreboard locking is yet even harder, because the scoreboard changes depending on player num, this also needs to be prevented 20:44 < bridge> Teams also need to be handled properly 🙈 but this looks good so far 20:44 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1446225710770426070/screenshot_2025-12-04_20-43-59.png?ex=69333627&is=6931e4a7&hm=decc1365d919e9e55dcf270e0e1daeb806566aea3b2a6d60c8bb7012a4938567& 20:45 < bridge> I wanted to show the x_ninja skin for a disconnected player, do you like the idea? But this seems not to work: 20:45 < bridge> `str_copy(m_DisconnectedClientData.m_aSkinName, "x_ninja");` 21:00 < bridge> can sb explain to me, why the player info and the client data contains a team? 21:09 < bridge> I'd show them without skin or show an icon representing "disconnected" in place of the skin. I don't think the ninja fits very well. 21:09 < bridge> You shouldn't need a copy of the entire client data; that doesn't work because it needs to be managed correctly by the gameclient, which ensures that skins are loaded and unloaded depending on usage 21:10 < bridge> I am not using a copy of client data, I hold my own player-disconnected-data-object 21:10 < bridge> You could keep a copy of the player name and clan though 21:10 < bridge> I am not using a copy of client data, I hold my own player-disconnected-data-object, which I reuse for every disconnected player 21:11 < bridge> You could keep a copy of the player name, clan and country though 21:11 < bridge> this is how I had it before and you wanted the player to show as disconnected :pepeW: 21:12 < bridge> but we could expand on it and make it like this now easily 21:12 < bridge> Greyed out like this seems good for disconnected players, but still having the name seems more useful 21:13 < bridge> In general, to render a tee/skin you need a `std::shared_ptr` 21:13 < bridge> ah I didn't set this, so makes sense nothing renders 21:14 < bridge> Using `CTeeRenderInfo` directly also works, but then you need to fetch the skin every frame that it's rendered 21:20 < bridge> doing that now, removing the x_ninja 21:37 < bridge> hey check out this pr 21:57 < bridge> @kebscs after predict teleports and predicting sounds playing solo maps on high ping will feel normal right ? 21:57 < bridge> or is something else not predicted 21:58 < bridge> yes 21:59 < bridge> with dummy too 21:59 < bridge> @robyt3 , also @kebscs I moved the highlighting behind the elements, because this is how the server browser does it as well 21:59 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1446244634215845970/screenshot_2025-12-04_21-58-53.png?ex=693347c6&is=6931f646&hm=0a43b0cb66f85e641863ba0efae781f7681b19c8cb6a3587d089d0e829cafee0& 21:59 < bridge> feels better tbh 22:01 < bridge> feels like a team now 22:10 < bridge> you put it in the middle of rendering, so parts where behind and parts were infront 22:25 < bridge> @0xdeen can you host the BLOCKER maps on maps.ddnet.org ? 22:26 < bridge> in the compliations 22:26 < bridge> section 22:26 < bridge> make a blocker.zip or something maybe 22:58 < bridge> <0xdeen> no 23:28 < bridge> nein 23:29 < bridge> @chillerdragon why https://cheater-api.zillyhuhn.com is not found that you gave in https://github.com/ddnet-insta/common-configs/blob/master/base/protection.cfg