Teeworlds - bridge

Teeworlds

IRC / bridge

One-way IRC channel bridge. If you want to be able to send messages to IRC, contact @Dune or @heinrich5991. https://www.teeworlds.com/?page=docs&wiki=rules/irc_rules

Between 2020-03-26 00:00:00Z and 2020-03-27 00:00:00Z

@LordSk 🦋 what do you need for #2503?

Learath2: have you wrangled with openssl before?

14:34

do you know how to get the error message for a connection?

very little

on the network I see that the client says "Unknown CA", but I was unable to even get that message locally

14:34

I'm trying to find out why this application (writtten in python with twisted which uses pyopenssl) tells me that my certificate is invalid

14:35

but all I get is "invalid certificate"

14:35

(certificate works for nginx&firefox) (edited)

SSL_get_error

ty, will check

call it after the call that fails

14:37

does the certificate include all the intermediaries?

except root, I think so

14:37

can't get openssl verify to work on it, but I don't know if it's unrelated

14:37

(firefox accepts it behind an nginx)

Learath2: there is a section #if 0'd out that needs fixing

14:38

Also testing old map formats

@LordSk 🦋 why are you using a sparse array?

So IDs are not a pain to deal with

okay we can save maps now

wow that was quick

15:34

I'll look at both the PRs as soon as I can

Learath2 what do you think about sending the server list in msgpack format instead of json

15:36

https://github.com/Ryozuki/teeworlds-master-server

Ryozuki/teeworlds-master-server

HTTPS Teeworlds master server implemented in Go. Contribute to Ryozuki/teeworlds-master-server development by creating an account on GitHub.

15:36

wip

I'd say: do json first and later add msgpack as an optimization if needed

15:37

json is ubiquitous, msgpack is not

well, i currently save the cached list on memcached with msgpack and i respont to http with json

15:38

but i like msgpack :p

^^

I vote json too, it's verypopular :)

msgpack is more efficient tho

15:43

"It's like JSON but fast and small."

Yes, but do we need the efficiency and is it a worthwhile tradeoff (for other applications querying the masters json is easier to handle)

msgpack is widely adopted

15:46

nodejs has a lib for it

15:46

c has a lib for it

I thought you were all for the fancy newfangled userfriendly stuff

any major lang has it

15:46

im all for new stuff

15:46

if its userfriendly or not its another thing

15:46

but i dont think its that unfriendly

15:46

its just not visible in the plain eye

we already have one serialization library in the tw code and js clients wouldn't even need a library to read json

well its fine http responses will be in json

Well it's up to you, you are the one implementing it but I highly doubt anyone else would agree with the decision

ye thats why im not doing it

15:47

and why i ask here

15:48

altho i doubt it will be adopted even if its good

15:48

i still have little faith in tw progress

well we'd definitely adopt it for ddnet

:)

15:49

Learath2 can you explain me how the token stuff works

15:49

i currently only require the server to send a heartbeat

15:49

every x seconds

15:50

but i dont allow it to be send too early tho

15:50

to prevent spam

there were already efforts for HTTP masters by heinrich5991, but he stopped working on that afaik

let me check how I implemented it

i want to know, why is a token needed

token where? tw connect?

im talking about master server and server relationship

ah

15:52

I can see two places for tokens: forward check and ipv4/v6 registration

15:52

ipv4 and ipv6 of a server should be associated with the same server entry

15:52

and the server could send a token to show that it's the same server

oh I never pushed that half of the code

forward check: the master server tries to send a token to the game server

heinrich5991 why they need to show they are the same server tho?

15:53

clients still want the 2 entries

15:53

ipv4 and ipv6

no, client wants one entry

learath told me another thing

and connect to whichever is available

what if both are available

then take any, probably preferring ipv6?

what if the client doesnt have ipv6 support

you just said that both are availabel

One "serverlist entry" has an ipv4 and an ipv6 field

the client chooses the one they can access (edited)

the client decides what to use

ok

I think the tokens I implemented with the fwcheck

15:55

The server registers without a token, waits for the fwcheck, the master provides the token while doing the fwcheck, after that you have to use the token on every packet

heinrich5991 why the master server should send anything to the server?

15:56

shouldnt the server be the one interested in a heartbeat

15:56

u can just timeout servers

15:56

after x time

to check that port forwarding works correctly

15:56

to check that clients can connect

15:56

otherwise people will get serverlist entries where they can't connect

i see

15:57

the request is udp then i guess

15:57

to the game server

I don't remember what was my contingency plan if the fwcheck never gets there though

whats fwcheck?

it's the message the master sends to the server to check connectivity

ok

15:58

https://github.com/Ryozuki/teeworlds-master-server#todo

Ryozuki/teeworlds-master-server

HTTPS Teeworlds master server implemented in Go. Contribute to Ryozuki/teeworlds-master-server development by creating an account on GitHub.

15:58

so this is the checklist i guess

15:58

anything else to add?

clients shouldn't request which ip they want, clients should get both, just let them figure out what to do with it

ok

btw I love how everyone keeps starting this project again when I have a fully working prototype we could all try cleaning up :P

tbf I already had a couple of prototypes

i think golang is perfect for this

16:02

it has rly good concurrency support

well I guess none that you liked enough to share :)

yes

16:02

@ Learath2

the only issue with go is that you are the only one that knows it

my master was a flask app

Learath2 reading someone else code is always a hasle :p

16:03

but you did it in python right?

mine was in flask too

eh, it's not much trouble to reimplement it in some other language if you suddenly disappear or stop contributing :P

what about the python GIL

16:04

u can never achieve real threading in python

Well depends on how long you hold the GIL, a long operation happening would definitely be trouble

Learath2 u should learn go :p its one of those langs thats its rly easy to pick up

I think twisted also avoids the gil issue by holding the lock in very short intervals and doing it's processing while not holding it

okay, I think I have one more in me, anyone need anything fixed?

@LordSk 🦋 :p

17:27

I guess you had enough with the UI Learath2 :D

Well better when I'm warmed up with the UI code then later :P

https://github.com/teeworlds/teeworlds/issues/1631 would be very nice to fix

Make the "stressing network" automatic ban less trigger-happy · Iss...

I experience getting banned regularly when restarting the client for a setting to take effect. Would it be possible to make this condition more gentle?

17:29

I wanted to finish 2242 before 074 but it had bugs

17:30

(a simple version, # prefix means option is not votable, and displays different background and indent level)

huh, that seems quite trivial to implement

17:46

I mean the way you mentioned, you can ofc go veryoverboard with it

17:47

I don't quite like the way votes are implemented to begin with though, why are we sending the entire thing when the id of the vote would be enough?

Yes those are simple issues, still need to be done ^^

https://github.com/fokkonaut/F-DDrace/commit/a9e04b993c8472c64473c76d79703c775631827a#diff-a60948952f625787eb8b3cf54f82d047

17:48

What about this? Patch I applied in my mod, originally introduced in ddnet in 0.6

What does it do?

Fixes the stressing network thing

17:48

I mean, solves it in a better way

17:49

you can try it live on my server, just enter multiple times

The issue is about a client side fix

17:49

But server side is nice too

I wouldnt do a client fix, that can always be abused by modders

Huh?

@Dune you care about backwards compatibility right?

Just don't reenter servers too fast

17:50

Yes Learath2

it happens often by accident @Dune

But displaying a # for server titles is something people already do

17:51

@fokkonaut hence the client side fix

?

@Dune would you mind if I keep the old vote system in, code a new one and make the server translate the old messages to new ones if it receives it

17:52

we can drop the old message god knows when though

That sounds overkill to me though

17:53

What would the benefits of this new system be?

It really bugs me that I can't clean this up :D

17:53

less data over the wire?

I'm not sure, is that significant?

This mess of string comparisons is really easy to break tbh

I try to be careful with refactors, should poke Oy about that separate issue

17:54

ensures unicity of votes by design too

Yeah, I'll go ahead and do it with #s for now, there is no way I get Oy to accept a vote refactor that comes with a lot of compatibility code

what point is there for vote uniqueness?

18:51

people formatted their votes in a certain way, with sections etc.

18:51

vanilla purposefully broke that, only leading to people working around it

18:51

(thankfully, I haven't seen any recent willful breakage)

okay, I got it functional but I'm no ui magician

18:53

@Dune how would you like the subheaders to be rendered?

The way you like it best :) Im not good at UI design

Yeah that's what I was scared of :P

eh, it kinda looks ugly on older clients

some servers currently use that convention though? like

19:11

# Scorelimits

19:11

20

19:11

50

You'll see what I mean when I create the pr

@Dune do you think #2518 is a satisfactory fix or do you still clientside foolproofing aswell?

20:32

s/still/still want/

I'll look in a while

@learath2, i would also add the netlimit

when opening chat and pressing uparrow i really expect it to even repeate last chat commands :/

@ChillerDragon I opened a PR for it

22:02

trying to fix a stupid SDL bug and I'm disassembling AppKit again, why must they obsecure everything?

ah awesome thanks Learath

amazing, switching to fullscreen completely fails so SDL returns that it succeeded, because even though the transition to fullscreen never ends the application is convinced it's in fullscreen

22:50

if you slow it down enough through a debugger though it does work

22:51

completely breaks the mouse clicks though

hm :/

Exported 187 message(s)