16:44 <+bridge_> [ddnet] yes 16:44 <+bridge_> [ddnet] in fact, only the laser target is checked 16:45 <+bridge_> [ddnet] @nuborn it returns here `if(absolute(dx) > 1000.0f || absolute(dy) > 800.0f)` in NetworkClipped(), but it is the same as in DDNet, no idea why. Also absolute() is the same function, so it wont throw different results. The laser is invisible for myself if i fall and shoot up, or if i shoot down and jump 16:45 <+bridge_> [ddnet] and it's directly on the edge 16:45 <+bridge_> [ddnet] so if you have any amount of downward speed, you won't see it 16:45 <+bridge_> [ddnet] if the laser reaches its maximum, yes. if a wall blocks it, of course i casn see it 16:45 <+bridge_> [ddnet] but also CLaser::Snap is the same, i have no diea 16:45 <+bridge_> [ddnet] D: 16:46 <+bridge_> [ddnet] is your laser length tunings the same? 16:46 <+bridge_> [ddnet] yes, its the same 16:47 <+bridge_> [ddnet] did you see if it enters that function? and returns successful? maybe do a debug print only for lasers. otherwise it has to be something else, like too many entities 16:47 <+bridge_> [ddnet] i did 16:47 <+bridge_> [ddnet] it does return right there, 1 16:47 <+bridge_> [ddnet] i added dbg messages 16:48 <+bridge_> [ddnet] and of course so it only prints the msg if it is my shot, and not from any other entity 16:50 <+bridge_> [ddnet] ok. does SnapNewItem in laser.cpp succeed too? because then the client should get it I think. otherwise I dont know 16:51 <+bridge_> [ddnet] it returns before it gets there 16:51 <+bridge_> [ddnet] it returns in NetworkClipped() 16:52 <+bridge_> [ddnet] ```if(absolute(dx) > 1000.0f || absolute(dy) > 800.0f) 16:52 <+bridge_> [ddnet] return 1;``` 16:52 <+bridge_> [ddnet] here 16:53 <+bridge_> [ddnet] oh. did you check what the values are? and compare them with the player position? maybe your mod does something differently when it creates the lasers, like creating them further away from the player? 16:54 <+bridge_> [ddnet] my mod has the same laser.cpp as ddnet 16:54 <+Learath2> @fokkonaut: did you check your viewpos and your checkpos? 16:54 <+bridge_> [ddnet] also, this happens in ChillerDragons DDNetPP mod 16:54 <+bridge_> [ddnet] :/ 16:54 <+bridge_> [ddnet] im innocent 16:55 <+bridge_> [ddnet] @heinrich5991 also is contributor of ddnet++ i blame him xd 16:55 <+bridge_> [ddnet] @Learath2 they should be the same... 16:55 <+bridge_> [ddnet] *should* 16:55 <+Learath2> Just check em' geez 16:55 <+bridge_> [ddnet] if you're debugging a problem that you can't explain, try to figure out which of your assumptions does not hold 16:55 <+bridge_> [ddnet] because obviously one doesn't 16:55 <+Learath2> It's like everyone wants me to debug things by looking at the code today, even that guy in ##C 16:56 <+bridge_> [ddnet] whats ##C ? 16:56 <+bridge_> [ddnet] Learath2: you need a space after @username for hte bridge to recognize it 16:56 <+bridge_> [ddnet] ##C on freenode 16:57 <+bridge_> [ddnet] what is it about? 16:57 <+bridge_> [ddnet] C# ? 16:57 <+bridge_> [ddnet] no, C 16:57 <+bridge_> [ddnet] why two #announcements 16:57 <+bridge_> [ddnet] # 16:57 <+bridge_> [ddnet] autocomplete .- 16:57 <+bridge_> [ddnet] # is the channel indicator, ## is for channels where the admin is not the author of the project 16:58 <+bridge_> [ddnet] ah ty for info 17:00 <+bridge_> [ddnet] does ``DoScrollbarH()`` support ranges from negativ to positive? 17:00 <+bridge_> [ddnet] im not big brain enough 17:01 <+bridge_> [ddnet] ``` 17:01 <+bridge_> [ddnet] g_Config.m_ClMyCfg= static_cast(DoScrollbarH(&g_Config.m_ClMyCfg, &Button, g_Config.m_ClMyCfg/1200.0f-600.0f)*1200.0f+0.1f); 17:01 <+bridge_> [ddnet] ``` 17:01 <+bridge_> [ddnet] it goes from -600 to 600 and that did not work :/ 17:01 <+Learath2> I think it probably goes from 0.0 to 1.0 like most other things 17:02 <+Learath2> But i'm not sure, tw does sometimes love to use non normalized values for the lulz 17:05 <+bridge_> [ddnet] i dont really know what positions i should check here 17:05 <+bridge_> [ddnet] i have my viewpos and the laser pos 17:06 <+Learath2> Check what the pos's are that lead to dx or dy being huge 17:06 <+bridge_> [ddnet] are u talking about the bug where it uses the laser end position to decide whether to snap the laser 17:06 <+bridge_> [ddnet] vs the start position or te middle 17:06 <+bridge_> [ddnet] probs 17:07 <+bridge_> [ddnet] @Learath2 both are quite normal 17:07 <+bridge_> [ddnet] both are almost the same 17:08 <+Learath2> Then dx and dy can't be that large and it can't be returning where you say it's returning 17:08 <+bridge_> [ddnet] oh lol 17:08 <+bridge_> [ddnet] that bug is also in ddnet 17:08 <+bridge_> [ddnet] @Learath2 well it is 17:08 <+bridge_> [ddnet] I guess i just need to put From to the checkpos, so it checks from where the laser starts 17:09 <+bridge_> [ddnet] since lasers work the other way round 17:09 <+bridge_> [ddnet] the m_Pos is the little laser ball at the end, and m_From is where the tee is 17:09 <+Learath2> If it is returning there it's undefined behaviour 17:09 <+bridge_> [ddnet] then it has the opposite bug 17:09 <+bridge_> [ddnet] the NetworkClipped for laser entity could use a slightly bigger range than it uses for a tee imo 17:09 <+bridge_> [ddnet] when you're far away, you're not seeing the laser 17:09 <+bridge_> [ddnet] probably less noticeable though, so you could call that "fixed" I guess 17:10 <+bridge_> [ddnet] `if (NetworkClipped(SnappingClient, m_From))` 17:10 <+bridge_> [ddnet] like this it is fixed 17:10 <+bridge_> [ddnet] it does use the position where it starts (where the tee is) to check 17:10 <+bridge_> [ddnet] not the end, that makes more sense 17:10 <+Learath2> Heeellooooo If dx and dy are small and it's returning where he says it is, something else is verybroken 17:10 <+bridge_> [ddnet] has he checked that dx and dy are small? 17:10 <+bridge_> [ddnet] Heeeeelloooo then its also broken in ddnet 17:10 <+bridge_> [ddnet] yea 17:11 <+bridge_> [ddnet] you printed them? 17:11 <+bridge_> [ddnet] no, i printed the checkpos and the viewpos 17:11 <+bridge_> [ddnet] and you added a print in the condition to check whether it happens? 17:11 <+bridge_> [ddnet] then print the dx 17:11 <+bridge_> [ddnet] it makes sense that they are high 17:11 <+Learath2> AH YES, THE SUPREME CRITERION FOR DIAGNOSING BUGS, IF IT HAPPENS IN DDNET IT'S FINE 17:11 <+bridge_> [ddnet] lol what 17:11 <+bridge_> [ddnet] it makes full sense 17:11 <+bridge_> [ddnet] its not a bug 17:12 <+bridge_> [ddnet] `if(NetworkClipped(SnappingClient) && NetworkClipped(SnappingClient, m_From)) 17:12 <+bridge_> [ddnet] return;` 17:12 <+bridge_> [ddnet] vanilla does it also like this 17:12 <+Learath2> It's not just any bug, it's either UB or our math functions are broken 17:12 <+bridge_> [ddnet] no 17:12 <+bridge_> [ddnet] lol 17:12 <+bridge_> [ddnet] it isnt a bug 17:12 <+bridge_> [ddnet] being unable to see ur own lasers when u shoot in the wrong direction sounds like a bug to me 17:12 <+Learath2> You seriously make me want to chug a glass of cyanide 17:12 <+bridge_> [ddnet] boi 17:13 <+bridge_> [ddnet] shooting up or down, while falling, makes the distance bigger, and to the top and bottom it checks for a slightly smaller distance to return. 17:13 <+bridge_> [ddnet] thats why vanilla also uses m_From, the postion where the laser starts 17:14 <+bridge_> [ddnet] which is also wrong, because then you don't see lasers that are far away and would end within your screen 17:14 <+bridge_> [ddnet] it's just less obviously wrong 17:15 <+bridge_> [ddnet] wouldnt the best solution be checking both start and end point 17:15 <+bridge_> [ddnet] well, true. laser just need a bigger distance allowed 17:15 <+bridge_> [ddnet] and snapping if either are in range 17:15 <+bridge_> [ddnet] @onby vanilla checks both 17:15 <+bridge_> [ddnet] yes, since lasers aren't so long that being in the middle is possible 17:20 <+Learath2> I don't get how you are all fine with the fact that CheckPos and ViewPos are very similar and yet it still fails a distance theck. I was so confused by this that I even read the entire chat log again to make sure @fokkonaut didn't correct himself. Let me get this straight. It concerns you more that the laser isn't rendered in some cases then that there is possibly a much larger problem with the code? 17:20 <+Learath2> Or am I just going insane? 17:20 <+bridge_> [ddnet] you are going insane 17:20 <+bridge_> [ddnet] :D 17:22 <+bridge_> [ddnet] So, the laser's m_Pos is the position, where it ends, not where it starts. Therefore, if you shoot straight up, without any blocks that stop the laser, the laser is out of the screen. It takes a little for the laser to reach its ending position, and if you fall while shooting up, the distance is just slightly too big for the check in NetworkClipped 17:22 <+bridge_> [ddnet] the laser reaches its target instantly 17:22 <+bridge_> [ddnet] well, it still fails there, because the distance gets bigger 17:22 <+bridge_> [ddnet] yes 17:23 <+Learath2> So CheckPos and ViewPos are not very similar at all... 17:23 <+bridge_> [ddnet] lasers need their own NetworkClipped, and the check need to use Tuning()->m_LaserReach 17:23 <+bridge_> [ddnet] No, not very similar 17:24 <+Learath2> 17:07 <+bridge_> [ddnet] @Learath2 both are quite normal 17:24 <+Learath2> 17:07 <+bridge_> [ddnet] both are almost the same 17:24 <+bridge_> [ddnet] wrong analysis from me, sorry 17:27 <+Learath2> It is fairly trivial to check whether a line intersects with the viewbox anyway, should be an easy fix 17:29 <+Learath2> Or you can cheat and check the midpoint aswell and hope laser reach isnt > 2x viewbox diagonal