DDraceNetwork - developer

DDraceNetwork

Development / developer

Development discussion. Logged to https://ddnet.tw/irclogs/ Connected with DDNet's IRC channel, Matrix room and GitHub repositories — IRC: #ddnet on Quakenet | Matrix: #ddnet-developer:matrix.org GitHub: https://github.com/ddnet

Between 2019-11-17 00:00:00Z and 2019-11-18 00:00:00Z

yes

15:44

in fact, only the laser target is checked

@trml 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

and it's directly on the edge

15:45

so if you have any amount of downward speed, you won't see it

if the laser reaches its maximum, yes. if a wall blocks it, of course i casn see it

15:45

but also CLaser::Snap is the same, i have no diea D:

is your laser length tunings the same?

yes, its the same

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

i did

15:47

it does return right there, 1

15:47

i added dbg messages

15:48

and of course so it only prints the msg if it is my shot, and not from any other entity

ok. does SnapNewItem in laser.cpp succeed too? because then the client should get it I think. otherwise I dont know

it returns before it gets there

15:51

it returns in NetworkClipped()

15:52

if(absolute(dx) > 1000.0f || absolute(dy) > 800.0f)
        return 1;

15:52

here

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?

my mod has the same laser.cpp as ddnet

@fokkonaut: did you check your viewpos and your checkpos?

also, this happens in ChillerDragons DDNetPP mod

:/

15:54

im innocent

15:55

@heinrich5991 also is contributor of ddnet++ i blame him xd

@Learath2 they should be the same...

should

Just check em' geez

if you're debugging a problem that you can't explain, try to figure out which of your assumptions does not hold

15:55

because obviously one doesn't

It's like everyone wants me to debug things by looking at the code today, even that guy in ##C

whats ##C ?

Learath2: you need a space after @username for hte bridge to recognize it

15:56

##C on freenode

what is it about?

15:57

C# ?

no, C

why two #announcements

15:57

#

15:57

autocomplete .-

# is the channel indicator, ## is for channels where the admin is not the author of the project

ah ty for info

16:00

does DoScrollbarH() support ranges from negativ to positive?

16:00

im not big brain enough

16:01

    g_Config.m_ClMyCfg= static_cast<int>(DoScrollbarH(&g_Config.m_ClMyCfg, &Button, g_Config.m_ClMyCfg/1200.0f-600.0f)*1200.0f+0.1f);

16:01

it goes from -600 to 600 and that did not work :/

I think it probably goes from 0.0 to 1.0 like most other things

16:02

But i'm not sure, tw does sometimes love to use non normalized values for the lulz

i dont really know what positions i should check here

16:05

i have my viewpos and the laser pos

Check what the pos's are that lead to dx or dy being huge

are u talking about the bug where it uses the laser end position to decide whether to snap the laser

16:06

vs the start position or te middle

probs

16:07

@Learath2 both are quite normal

16:07

both are almost the same

16:08

oh lol

Then dx and dy can't be that large and it can't be returning where you say it's returning

that bug is also in ddnet

16:08

@Learath2 well it is

16:08

I guess i just need to put From to the checkpos, so it checks from where the laser starts

16:09

since lasers work the other way round

16:09

the m_Pos is the little laser ball at the end, and m_From is where the tee is

If it is returning there it's undefined behaviour

then it has the opposite bug

the NetworkClipped for laser entity could use a slightly bigger range than it uses for a tee imo

when you're far away, you're not seeing the laser

16:09

probably less noticeable though, so you could call that "fixed" I guess

if (NetworkClipped(SnappingClient, m_From))

16:10

like this it is fixed

16:10

it does use the position where it starts (where the tee is) to check

16:10

not the end, that makes more sense

Heeellooooo If dx and dy are small and it's returning where he says it is, something else is verybroken

has he checked that dx and dy are small?

Heeeeelloooo then its also broken in ddnet

16:10

yea

you printed them?

no, i printed the checkpos and the viewpos

and you added a print in the condition to check whether it happens?

16:11

then print the dx

it makes sense that they are high

AH YES, THE SUPREME CRITERION FOR DIAGNOSING BUGS, IF IT HAPPENS IN DDNET IT'S FINE

lol what

16:11

it makes full sense

16:11

its not a bug

16:12

if(NetworkClipped(SnappingClient) && NetworkClipped(SnappingClient, m_From))
        return;

16:12

vanilla does it also like this

It's not just any bug, it's either UB or our math functions are broken

no

16:12

lol

16:12

it isnt a bug

being unable to see ur own lasers when u shoot in the wrong direction sounds like a bug to me

You seriously make me want to chug a glass of cyanide

boi

16:13

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.

16:13

thats why vanilla also uses m_From, the postion where the laser starts

which is also wrong, because then you don't see lasers that are far away and would end within your screen

16:14

it's just less obviously wrong

wouldnt the best solution be checking both start and end point

well, true. laser just need a bigger distance allowed

and snapping if either are in range

@noby vanilla checks both

yes, since lasers aren't so long that being in the middle is possible

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?

16:20

Or am I just going insane?

you are going insane

16:20

:D

16:22

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

the laser reaches its target instantly

well, it still fails there, because the distance gets bigger

yes

So CheckPos and ViewPos are not very similar at all...

lasers need their own NetworkClipped, and the check need to use Tuning()->m_LaserReach

16:23

No, not very similar

17:07 <+bridge_> [ddnet] <fokkonaut> @Learath2 both are quite normal

16:24

17:07 <+bridge_> [ddnet] <fokkonaut> both are almost the same

wrong analysis from me, sorry

It is fairly trivial to check whether a line intersects with the viewbox anyway, should be an easy fix

16:29

Or you can cheat and check the midpoint aswell and hope laser reach isnt > 2x viewbox diagonal

[ddnet/ddnet] Pull request opened: #1970 Save selected UI settings page

Inspired by @SushiTee's teeworlds commit: https://github.com/teeworlds/teeworlds/commit/65cc8f7fd93d6136f4d4ec570a4d22aa3490928e

[ddnet:master] 2 new commits

0f76c89 Save selected UI settings page - ChillerDragon f7b7c3a Merge #1970 - bors[bot]

18:44

[ddnet/ddnet] Pull request closed: #1970 Save selected UI settings page

Exported 123 message(s)