00:00 < bridge_> insane tech, only cost is that it lags the server xd 00:00 < bridge_> quick skip every map with ninja and shotgun 00:00 < bridge_> yea 00:00 < bridge_> quick, skip every map with ninja and shotgun 00:00 < bridge_> sadly its kinda useless on most maps lol? xd 00:00 < bridge_> yeah 00:01 < bridge_> so its not really a gamebreaking bug xd 00:01 < bridge_> it just lags a bit 00:01 < bridge_> L physics implementation 00:02 < bridge_> wanna see it in action? :justatest: 00:02 < bridge_> wdym? 00:02 < bridge_> 45.141.57.22:8340 00:02 < bridge_> i mean its just a bug xd 00:02 < bridge_> is there a real skip 00:02 < bridge_> what is there to show 00:02 < bridge_> how bad it is 00:03 < bridge_> @teero777 how would you fix this? applying ramp before ninja is a big physics change right? 00:03 < bridge_> yes it is. 00:04 < bridge_> actually 00:04 < bridge_> just clamp the velX to max speed after ninja move 00:04 < bridge_> lol 00:04 < bridge_> hmm 00:04 < bridge_> but doesn't ninja go above max speed sometimes 00:04 < bridge_> uh idk 00:05 < bridge_> maybe not 00:05 < bridge_> only if you get the velocity in the same tick you use ninja? 00:05 < bridge_> wdym "after" don't you do it before? 00:05 < bridge_> otherwise it still does huge movebox 00:07 < bridge_> @teero777 but ramp only caps X speed, why doesn't doing shotgun bug normally not cause this lag if it was because of movebox? 00:08 < bridge_> not sure what actually causes the lag here 00:08 < bridge_> @teero777 but ramp only caps X speed, why does doing shotgun bug normally not cause this lag if it was because of movebox? 00:10 < bridge_> is the map geometry logic not priori? it would not lag if it was 00:10 < bridge_> it'd have to be 00:10 < bridge_> what 00:11 < bridge_> priori vs posteriori in the context of collision detection defines when collisions are detected 00:11 < bridge_> movebox handles the geometry logic 00:14 < bridge_> @teero777 the issue says it happens on sunny side up, so it can't be related to ramp 00:14 < bridge_> huh? 00:14 < bridge_> or X vel 00:14 < bridge_> ? 00:15 < bridge_> well it must be something related to the velocity xd 00:15 < bridge_> but only with ninja 00:15 < bridge_> but I don't see anything other than movebox that changes in cost based on distance 00:15 < bridge_> but I don't see anything other than movebox in ninja code that changes in cost based on distance 00:16 < bridge_> static const mvec2 StackedLaserShotgunBugSpeed = CTVEC2(-2147483648.0f, -2147483648.0f); 00:16 < bridge_> that is our velocity. then we ninja 00:16 < bridge_> yes 00:16 < bridge_> but there's only 1 loop over distance which is movebox afaik 00:16 < bridge_> Ahh 00:17 < bridge_> i think i might know xDD 00:17 < bridge_> unless there's something like making ninja effects 00:17 < bridge_> hmm maybe not 00:17 < bridge_> well we move 1.41x more distance than normal sg bug 00:17 < bridge_> not on sunnyside up 00:17 < bridge_> wdym? 00:17 < bridge_> not on sunny side up 00:17 < bridge_> it doesnt matter 00:17 < bridge_> there's walls 00:17 < bridge_> ok? 00:17 < bridge_> so you hit them in movebox 00:18 < bridge_> and velocity is the same again 00:18 < bridge_> ok? it will still loop until it fully stops 00:18 < bridge_> yeah 00:18 < bridge_> but you don't need X vel, so it's just 1.0x sg bug speed 00:18 < bridge_> hmm 00:18 < bridge_> yea 00:19 < bridge_> the only other logic there is is the player to player collision 00:20 < bridge_> but that logic is free 00:20 < bridge_> does making a sound at sg speed distance outside of the map cause lag? xd 00:20 < bridge_> nah 00:20 < bridge_> cause the tee dies there too 00:21 < bridge_> lemme check if it also lags with my physics 00:21 < bridge_> that eliminates a lot 00:21 < bridge_> your physics don't even work outside the map 00:22 < bridge_> it it's not nearly the same 00:22 < bridge_> it would just crash 00:22 < bridge_> or movebox don't try to go there 00:22 < bridge_> or movebox wont try to go there 00:23 < bridge_> I g2g, this would be easy to find with debugger when I get home if you haven't figured it out by then. 00:25 < bridge_> yea its easy 00:42 < bridge_> @totar xd in my physics it checks if the position you are trying to go to is oob first and just kills you without doing movebox xD 00:42 < bridge_> i guess my physics won't have sg bug? 00:42 < bridge_> its a bug anyway 03:51 < bridge_> most ppl gate such bug fixes at compile time 03:51 < bridge_> if they care about preserving it 03:51 < bridge_> your physics will not be 1:1 without sg bug though 03:52 < bridge_> I think maps that exploit bugs are not allowed on ddnet so if that's the boundary you're probably ok 04:19 < bridge_> I'm already not caring about compatibility 04:21 < bridge_> there's your answer 04:26 < bridge_> did you? 04:26 < bridge_> no 04:27 < bridge_> did you do anything else? 04:27 < bridge_> wdym 04:27 < bridge_> idk, breathing, eating, driving etc. 04:27 < bridge_> I did all those things 04:27 < bridge_> woah nice, how was it? 04:28 < bridge_> do you have any grapes rn? 05:53 < bridge_> just did, it is movebox 05:54 < bridge_> we were right lol 05:54 < bridge_> woah 05:54 < bridge_> but it's not the ninja movebox 05:54 < bridge_> huh? 05:56 < bridge_> lol 05:56 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1427505280429723670/image.png?ex=68ef1b64&is=68edc9e4&hm=8fbf2f41cf9476333abe1a57ba3c2d6dc235057bba23564452df29e543ed462e& 05:56 < bridge_> small loop 05:56 < bridge_> light work 05:57 < bridge_> "1 billion MoveBox loops challenge" 05:57 < bridge_> 06:01 < bridge_> 500 cigarettes 06:07 < bridge_> ok this is rather complicated bug actually 07:03 < bridge_> this is so crazy 08:01 < bridge_> I only get more confused the more I look at this 08:02 < bridge_> I think I understand it now but my previous idea was not the whole picture so I have to rewrite the explanation 08:16 < bridge_> this is also a prediction desync lol 08:47 < bridge_> I was just wrong 08:51 < bridge_> ok I can explain it now 08:54 < bridge_> Why not just clamp the player velocity into a "sane" limit ? For example 100 tiles per second equals 2 tiles per tick, that equals about 64 game world units... 08:54 < bridge_> it does do that 08:54 < bridge_> I'll post explanation when I'm done typing 09:52 < bridge_> must be a long ass explanation 10:05 < bridge_> ## Bug reproduciton steps: 10:05 < bridge_> 10:05 < bridge_> -The shotgun tee must have a lower client id than the ninja tee 10:05 < bridge_> -the ninja tee and shotgun tee must be stacked 10:05 < bridge_> -the ninja tee must look down 10:05 < bridge_> -they both fire on the same tick 10:05 < bridge_> 10:05 < bridge_> ## Background information: 10:05 < bridge_> 10:05 < bridge_> ``length(vec2)`` can be negative if you assign it to an int: 10:05 < bridge_> 10:05 < bridge_> ``CCharacter::PreTick()`` is called in 2 different ways 10:05 < bridge_> If NoWeakHookAndBounce, then it will get called for each entity in ``CGameWorld::Tick()`` before it calls ``Tick()`` and ``TickDeferred()`` for each entity 10:05 < bridge_> But this is off by default, so we don't call ``PreTick()`` from ``CGameWorld::Tick()`` 10:05 < bridge_> 10:06 < bridge_> Instead it gets called from this code: 10:06 < bridge_> ```cpp 10:06 < bridge_> void CCharacter::Tick() 10:06 < bridge_> { 10:06 < bridge_> if(m_pGameWorld->m_WorldConfig.m_NoWeakHookAndBounce) 10:06 < bridge_> { 10:06 < bridge_> m_Core.TickDeferred(); 10:06 < bridge_> } 10:06 < bridge_> else 10:06 < bridge_> { 10:06 < bridge_> PreTick(); 10:06 < bridge_> } 10:06 < bridge_> /* ... */ 10:06 < bridge_> } 10:06 < bridge_> ``` 10:06 < bridge_> This is important because ``PreTick()`` is different depending on if we are using NoWeakHookAndBounce or not 10:06 < bridge_> ## The bug 10:06 < bridge_> 10:06 < bridge_> The shotgun tee has a lower client id, so it will process FireWeapon() via DirectInput first 10:06 < bridge_> 10:06 < bridge_> ```cpp 10:06 < bridge_> CServer::Run() 10:06 < bridge_> 10:06 < bridge_> for(each client) 10:06 < bridge_> After the Gameworld ticks all entities, it will do TickDeferred 10:06 < bridge_> 10:06 < bridge_> ```cpp 10:06 < bridge_> NinjaTee.TickDeferred() 10:06 < bridge_> { 10:06 < bridge_> m_Core.Move() 10:07 < bridge> -The shotgun tee must have a lower client id than the ninja tee 10:07 < bridge> -the ninja tee and shotgun tee must be stacked 10:07 < bridge> -the ninja tee must look down 10:07 < bridge> -they both fire on the same tick 10:07 < bridge> 10:08 < bridge> ## Background information: 10:08 < bridge> 10:08 < bridge> if the value of ``length(vec2)`` overflows when you cast it to int it will be negative : 10:08 < bridge> 10:08 < bridge> ``CCharacter::PreTick()`` is called in 2 different ways 10:08 < bridge> If NoWeakHookAndBounce, then it will get called for each entity in ``CGameWorld::Tick()`` before it calls ``Tick()`` and ``TickDeferred()`` for each entity 10:08 < bridge> But this is off by default, so we don't call ``PreTick()`` from ``CGameWorld::Tick()`` 10:08 < bridge> 10:08 < bridge> Instead it gets called from this code: 10:08 < bridge> ```cpp 10:08 < bridge> void CCharacter::Tick() 10:08 < bridge> { 10:08 < bridge> if(m_pGameWorld->m_WorldConfig.m_NoWeakHookAndBounce) 10:08 < bridge> { 10:08 < bridge> m_Core.TickDeferred(); 10:08 < bridge> } 10:08 < bridge> else 10:08 < bridge> { 10:08 < bridge> PreTick(); 10:08 < bridge> } 10:08 < bridge> /* ... */ 10:08 < bridge> } 10:08 < bridge> ``` 10:08 < bridge> This is important because ``PreTick()`` is different depending on if we are using NoWeakHookAndBounce or not 10:08 < bridge> no 10:08 < bridge> I wrote it all by hand 10:08 < bridge> GPT5 couldn't even understand the bug when I gave it all the files 10:09 < bridge> looking back I see informal punctuation but otherwise you could've fooled me 10:09 < bridge> we can't have headers anymore 10:13 < bridge> Minimal fix: 10:13 < bridge> ```cpp 10:13 < bridge> case WEAPON_NINJA: 10:13 < bridge> { 10:13 < bridge> // reset Hit objects 10:13 < bridge> m_NumObjectsHit = 0; 10:13 < bridge> 10:13 < bridge> m_Core.m_Ninja.m_ActivationDir = Direction; 10:13 < bridge> m_Core.m_Ninja.m_CurrentMoveTime = g_pData->m_Weapons.m_Ninja.m_Movetime * Server()->TickSpeed() / 1000; 10:13 < bridge> 10:13 < bridge> +++ if (length(m_Core.m_Vel) > 6000.0f) 10:13 < bridge> +++ m_Core.m_Vel = normalize(m_Core.m_Vel) * 6000.0f; 10:13 < bridge> 10:13 < bridge> m_Core.m_Ninja.m_OldVelAmount = length(m_Core.m_Vel); 10:13 < bridge> 10:13 < bridge> GameServer()->CreateSound(m_Pos, SOUND_NINJA_FIRE, TeamMask()); // NOLINT(clang-analyzer-unix.Malloc) 10:13 < bridge> } 10:13 < bridge> ``` 10:23 < bridge> is AI the end of Markdown? 10:23 < bridge> is it killing markdown? 10:26 < bridge> ?xd 10:26 < bridge> Isnt ai the no.1 customer of markdown 10:31 < bridge> Very useful explained... I would lower the general speed limit to 1000.f (that equals 31 tiles per tick more or less) that is still and impressive not playable speed 10:32 < bridge> Very useful explained... I would lower the general speed limit everywhere to 1000.f (that equals 31 tiles per tick more or less) that is still and impressive not playable speed 10:33 < bridge> Very useful explained... I would lower the general speed limit everywhere to 1000.f (that equals 31 tiles per tick more or less) that is still an impressive not playable speed... So less headache for the cpu 10:38 < bridge> Holy spam 10:40 < bridge> > if the value of length(vec2) overflows when you cast it to int it will be negative : https://godbolt.org/z/e6hq9KGh9 10:40 < bridge> 10:40 < bridge> oh no, nobody could have ever seen coming that 😮 I am so suprised that this can overflow 10:40 < bridge> > if the value of length(vec2) overflows when you cast it to int it will be negative : 10:40 < bridge> 10:40 < bridge> oh no, nobody could have ever seen coming that 😮 I am so suprised that this can overflow 10:40 < bridge> (fck off discord i am citing) 10:42 < bridge> it only barely overflows, and it's the reason that you need to look down to reproduce the bug, so I thought it was important to note 10:43 < bridge> Eventually, times ago I saw on YouTube "one line coder" designing a collisions algorithm that iterates each step where it intersects the tiles grid, instead of every single game world unit 10:43 < bridge> teero has it in his code 10:43 < bridge> yes, would be neat if teeworlds would have used that 16 years ago 10:43 < bridge> there's a nice comment 10:44 < bridge> also there was a name for this algorithm, was it bresenham? 10:44 < bridge> ```cpp 10:44 < bridge> // TODO: rewrite this smarter! 10:44 < bridge> int CCollision::IntersectLine(vec2 Pos0, vec2 Pos1, vec2 *pOutCollision, vec2 *pOutBeforeCollision) const 10:44 < bridge> ``` 10:44 < bridge> DDA 10:44 < bridge> Eventually, times ago I saw on YouTube "one lone coder" designing a collisions algorithm that iterates each step where it intersects the tiles grid, instead of every single game world unit 10:44 < bridge> wait 10:45 < bridge> nvm it is DDA 10:45 < bridge> Bresenham doesn't hit every cell 10:47 < bridge> yeah it's DDA, if I'd create a game I'd use Xiaolin Wu's and make the sensistiive checks with the sourroundings with it 10:48 < bridge> you'd even know how _hard_ a tile would be hit or how much 10:50 < bridge> Who plays his modification? Or how to try it? 10:50 < bridge> https://github.com/Teero888/ddnet_physics_c 10:50 < bridge> it's just a library, not a mod 10:52 < bridge> Hey, don't read it! 10:52 < bridge> 😳 10:52 < bridge> you gon make teeto look like :angy: 10:55 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1427580640878137344/RDT_20251014_0324151290754756230135584.jpg?ex=68ef6193&is=68ee1013&hm=920ac53ce28499af2b3aa9175d10df0ec7016229bd4aeb1657d7b45f46d2b22c& 10:57 < bridge> @totar good thing I don't have to reproduce that square root you evil mf 10:57 < bridge> why am I evil 10:58 < bridge> I would have yet another sqrt in my code if I was ddnet compatible xd 10:58 < bridge> oh lol 10:58 < bridge> you could just do squared distance 10:58 < bridge> yea. But floating point accuracy at high values like 6000*6000 is shit you know xd 10:58 < bridge> squared length 10:59 < bridge> ig 10:59 < bridge> Well it's not the same xd 10:59 < bridge> it doesn't actually matter because the direction is set to your mouse 11:00 < bridge> ig this can be simpler 11:01 < bridge> idk we will see if reviewer cares or not 11:01 < bridge> @totar I would love to show you a photo of the grill function I'm using rn to cook the baguette because we were talking about it recently but I would leak myself in the reflection 11:01 < bridge> lol 11:02 < bridge> Yea can't you just fmaxf(ninja speed, 6000) when you multiply the direction change? 11:02 < bridge> Lazy typing on phone 11:02 < bridge> You know what I mean 11:02 < bridge> Ah no you can't 11:02 < bridge> mb 11:02 < ws-client1> **** wait wot when did you release this https://github.com/Teero888/ddnet_physics_c @Teero ? 11:02 < bridge> Few weeks ago 11:02 < ws-client1> **** omg 11:02 < bridge> But don't read or use 11:02 < bridge> It's wip 11:03 < ws-client1> **** i will write new production server with it 11:03 < bridge> fminf 11:03 < bridge> you can ig, the API won't change much anymore 11:03 < ws-client1> **** pog 11:03 < ws-client1> **** but catto lib doesnt even have snaps yet ._. 11:03 < bridge> lol 11:03 < bridge> when snaps teero 11:04 < ws-client1> **** its net not physics 11:04 < bridge> @totar we need some docs for the global state of the tee accelerator. Ah maybe not. It's only relevant for multi threading 11:04 < bridge> Do you know where, in the source code, it checks if a tee is too much inside a solid tile? 11:04 < bridge> I am playing around modding physics, and when this anomaly happens the tee dies 11:04 < bridge> "don't multithread this code" 11:04 < bridge> gg 11:04 < bridge> xdd 11:05 < bridge> yea chiller don't multi thread that code until I write docd 11:05 < bridge> yea chiller don't multi thread that code until I write docs 11:05 < bridge> docs 11:05 < bridge> the docs in the docs directory are outdated 11:07 < ws-client1> **** ye dw i wont do it any time soon 11:07 < ws-client1> **** i try to implement snaps in pyson since a few days and i am hard stuck 11:08 < ws-client1> **** not sure when the net lib will get snaps 11:08 < ws-client1> **** but then i would actually like to build a server written in C 11:09 < bridge> epuc 11:09 < bridge> epic 11:10 < bridge> make better protocol while you are at it 11:17 < bridge> <0xdeen> Thank you @heinrich5991 ! ^ 11:26 < bridge> ## The bug 11:26 < bridge> 11:26 < bridge> The shotgun tee has a lower client id, so it will process FireWeapon() via DirectInput first 11:26 < bridge> 11:26 < bridge> ```cpp 11:26 < bridge> CServer::Run() 11:26 < bridge> 11:26 < bridge> for(each client) 11:26 < bridge> { 11:26 < bridge> 11:26 < bridge> // Shotgun Tee 11:26 < bridge> CGameContext::OnClientPredictedEarlyInput() 11:26 < bridge> CPlayer::OnPredictedEarlyInput() 11:26 < bridge> CCharacter::OnDirectInput() 11:26 < bridge> CCharacter::FireWeapon() 11:26 < bridge> case WEAPON_SHOTGUN: 11:26 < bridge> new CLaser(...) 11:26 < bridge> // Inside the CLaser constructor (Important!) 11:26 < bridge> CLaser::DoBounce() 11:26 < bridge> CLaser::HitCharacter() 11:27 < bridge> // The Ninja Tee gets shotgun bug velocity 11:27 < bridge> NinjaTee->SetRawVelocity(vec2(-2147483648.0f, -2147483648.0f)); 11:27 < bridge> // Ninja tee m_Core.m_Vel becomes vec2(-2147483648.0f, -2147483648.0f) 11:27 < bridge> 11:27 < bridge> // Ninja Tee 11:27 < bridge> CGameContext::OnClientPredictedEarlyInput() 11:27 < bridge> CPlayer::OnPredictedEarlyInput() 11:27 < bridge> CCharacter::OnDirectInput() 11:27 < bridge> CCharacter::FireWeapon() 11:27 < bridge> case WEAPON_NINJA: 11:27 < bridge> { 11:28 < bridge> pog 11:28 < bridge> ## The bug 11:28 < bridge> 11:28 < bridge> The shotgun tee has a lower client id, so it will process FireWeapon() via DirectInput first 11:28 < bridge> 11:28 < bridge> ```cpp 11:28 < bridge> CServer::Run() 11:28 < bridge> 11:28 < bridge> for(each client) 11:28 < bridge> { 11:28 < bridge> 11:28 < bridge> // Shotgun Tee 11:28 < bridge> CGameContext::OnClientPredictedEarlyInput() 11:28 < bridge> CPlayer::OnPredictedEarlyInput() 11:28 < bridge> CCharacter::OnDirectInput() 11:28 < bridge> CCharacter::FireWeapon() 11:29 < bridge> case WEAPON_SHOTGUN: 11:29 < bridge> new CLaser(...) 11:29 < bridge> // Inside the CLaser constructor (Important!) 11:29 < bridge> CLaser::DoBounce() 11:29 < bridge> CLaser::HitCharacter() 11:29 < bridge> // The Ninja Tee gets shotgun bug velocity 11:29 < bridge> NinjaTee->SetRawVelocity(vec2(-2147483648.0f, -2147483648.0f)); 11:29 < bridge> // Ninja tee m_Core.m_Vel becomes vec2(-2147483648.0f, -2147483648.0f) 11:29 < bridge> 11:29 < bridge> // Ninja Tee 11:29 < bridge> CGameContext::OnClientPredictedEarlyInput() 11:29 < bridge> CPlayer::OnPredictedEarlyInput() 11:29 < bridge> CCharacter::OnDirectInput() 11:29 < bridge> CCharacter::FireWeapon() 11:29 < bridge> case WEAPON_NINJA: 11:29 < bridge> { 12:24 < bridge> Classics hein RICH donation 12:25 < bridge> No it will be compatible ofc 12:25 < bridge> No chiller 12:25 < bridge> We both know rich ppl don't do that 12:25 < bridge> Let's take you as an example 12:25 < bridge> Donate? 12:25 < bridge> I am not rich 12:25 < bridge> Also I did donate 12:27 < bridge> Ok, then I am just very very ppor 12:27 < bridge> Ok, then I am just very very poor 12:27 < bridge> .\_. 12:27 < bridge> I am Munich middle class 12:28 < bridge> 110% of my income goes straight to rent 12:28 < bridge> Ok ok 12:28 < bridge> but you own the flat 12:28 < bridge> lol 12:29 < bridge> If you own a flat in Munich you are rich I guess 12:29 < bridge> ig xd 12:32 < bridge> chiller when do we play if city against each other 12:32 < bridge> if city irl 12:37 < ws-client1> **** if city irl 12:37 < ws-client1> **** wtf 12:37 < ws-client1> **** i donated 0.039 BTC to ddnet btw 12:42 < bridge> After the Gameworld ticks all entities, it will do TickDeferred 12:42 < bridge> 12:42 < bridge> ```cpp 12:42 < bridge> NinjaTee.TickDeferred() 12:42 < bridge> { 12:42 < bridge>