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-05-10 00:00:00Z and 2020-05-11 00:00:00Z

The algorithm already tries to keep the player list stable, your really shouldnt be getting this many connect disconnects tbh

06:21

@heinrich5991 it is possible that the handling for the snaps is more efficient then handling the packets, even chunks bunched together will have to go through some unpacking of the headers

06:22

Vital packets mean that there will be resends

@fokkonaut why don't you give it a try to clear the weapon drops up a bit. The whole map is flooded with weapons that collide and can be collected etc sounds to me like a half tee. Imo its worth a try to decrease the amount.

How many packets per second does the server send, how high is the cpu load? Are the clients experiencing packet loss or even disconnects? The resend mechanism in tw is really simple. It might just not be sufficient for sending packets periodically. When a resend is necessary the server needs to resend all packets. This amount of data might lead to packet loss again, so the queue builds up...

cpu load is at 80% avg redix

11:33

no disconnects

Problem with the size of the player data is not only that the server needs additional bandwidth. The size of the snapshots is limited (64k as far as I remember). With 64 players the player data requires about 15k in the snap. There is still enough space but it's just waisting a huge amount of the snap size.

11:37

Hmm okay. Regular resending might still lead to lags due to high packet output =\

@Learath2 the map has teleporters and the spawn is pretty far away from the rest of the map, also /pause of course, those lead to many connects and disconnects

yeah, snapshot size is 64k

12:05

putting the player data in the snap would in the worst case take about 32k

12:05

just for that

hey Oy

12:17

not sure what you mean with filling with whitespaces

12:17

shouldn't we just use a aBuf[4] ?

Dune: if the word has to be at least 3 chars in lengh, fill the missing one with a space

minimum size is not a problem, maximum is

12:20

it's okay if they translate by "NE", not by "NETT"

ah, then i misread it :)

(would overflow)

yeah, then just clamp it

alright

though wouldn't use a buf[4]

12:21

keep utf8 in mind

ah

cut it after 3 chars

buf4 -> buffour -> buffer lol

with str_format size param?

12:21

i think this is in bytes too

yeah

12:22

ptobably have to write sth

okay

https://github.com/teeworlds/teeworlds/blob/master/src/base/system.c#L2421

teeworlds/teeworlds

A retro multiplayer shooter. Contribute to teeworlds/teeworlds development by creating an account on GitHub.

12:24

for loop

12:25

maybe add a function in base/system.c for it?

it's a bit of a hacky solution anyway

12:25

character width not a constant etc

12:26

Uploaded file: https://uploads.kiwiirc.com/files/ff8efb6a4a84a5b085fd9cd3adb6d6e2/image.png

Embedded image

12:27

Transifex lets us set a hard character limit

@fokkonaut by default the client only sends snapshots in every second tick. Try to send the connect/disconnect stuff in a tick where no snap is sent. Are you flushing the connection? When you are only sending the players that actually changed I think the whole thing should work somehow. When you are sending more than that, there are probably too many packets

of course it works somehow, but it is just too laggy sometimes

Yeah, maybe because of too many packets at once

when joining 176.9.114.238:9303 my client keeps crashing

13:04

(0.7)

ddnet lol

oh yeah its a ddnet server

Map seems broken. The client is stuck in a loop because of a broken envelope item.

nice, new method for client crasher

corrupt maps tend to crash the client

shouldn't the client be more stable concerning this?

shoulds are many, dos are rarer

I think this is the one time where a try-catch clause is a good use

ew

13:17

that wouldn't solve out of bound accesses etc.

Does teeworlds has any kind of error logs?

the console

I mean some kind of post client crash logging, with an unhandled exception handler

no

Crashing the client is really easy. There is hardly any validation when loading maps and even the snapshot code still has some issues

I always thought you want the client to be as stable as possible ^^ but okay

13:29

^I should clarify this

13:30

I thought you want the client fully stable, so every error case is handled

that would be good, yes

Yeah that would definitely be good, but nobody really looked into this so far

please no exceptions in teeworlds

13:47

A lot of the datafile code needs checks though, if someone cba to go through it

yeah

in case someone wants to fix the map: NUT_hardcore_best (on the ddner server @Assa mentioned) has a CMapItemEnvelope with m_Channels = 8. The value should be clamped to 1-3. DDNet does not really use it when loading a map but 0.7 gets stuck in this loop due to a buffer overflow: https://github.com/teeworlds/teeworlds/blob/60bfb5615e26d07afa294e8af1e44808a036068d/src/game/client/components/maplayers.cpp#L257-L264

there is an issue with the asynchronous rendering in macOS and this time I don't know how to fix it

14:57

The main dispatch queue is running in our initial thread, when we call swap it causes a dispatch in sdl, however right after that we waitforidle

14:57

thus the dispatch queue never runs again

14:57

thus the dispatch from sdl never goes through, thus the graphics thread is stuck

15:03

on macOS we can't afford to not SDL_PollEvent for a while

hm, I guess they could be doing an async dispatch instead

Well I’ll commit it and hope icculus doesn’t be an ass

15:17

That doesn’t sound right

should we maybe remove custom colors setting? its not a custom color anymore since it is turned on for default colors too (edited)

what colors are you talking about?

@Learath2 should only perform worse on packet loss

@Dune tee's ofc

22:31

there should be no more custom colors option, the picker should be active always

22:31

because as i said its not custom anymore, since default skins also use "custom colors on", it doesnt make sense anymore, it only did before

Exported 83 message(s)