Teeworlds - bridge

https://www.teeworlds.com/?page=docs&wiki=compiling_everything_windows

00:41

guide says: install visual studio 2017

00:41

bam: You need Microsoft Visual Studio 8, 9, 10, 11, 12, 13 or 15 installed

00:42

nevermind, there is a note underneath <.<

bam compiled

00:50

now:

00:50

configure.lua:367: no c/c++ compiler found

do you have gcc or cl in path?

yes, but how it looks only in the native command prompt, thank you for the hint

01:06

I don't need to recompile bam, do I?

no

01:07

bam config should show you no compiler found

instead of adding blub\bin to the path, i needed to add blub\bin\x64_86\x64 to the path ...

01:10

windows doesn't stop to amaze me

so i had to set my PC to developer mode, so it installs the developer package, so it can find the C++ files iam missing when compiling ...

in which system variable does bam look for the headers?

the headers?

okay, how do i tell bam to use a specific compiler?

02:18

bam config compiler=gcc worked

02:22

i switched to mingw since it was easier

good news: everything compiles, bad news: i reached the command limit xD

I need some help: clang throws (only with cmake) -Winconsistent-missing-override and i have no idea how to disable it

03:47

I like how bam is using gcc and cmake is using clang in the gh-actions-workflow

hmm, what to do about dickhead server that bans me immediately /for nothing/ no warning? can I blacklist off these servers/players?

03:49

"oh never need to bother looking for a fair game with these dickheads"

-Wno-inconsistent-missing-override i learned something today

JewZeus: I guess they want to play with their friends

play on servers with the ip 149.202.127.134 if you want to avoid getting banned

it's a problem of players thinking they own the servers, that are actually open for everyone to play on. Some servers have a contact info in their server info, where you might get help if someone abuses votes. If you are banned, you might find other servers with similar naming and read the server info there.

I think it's fine that people want to play on a server with friends. Ideally, the server should have votes like Assa showed there: https://www.teeworlds.com/forum/viewtopic.php?pid=123908#p123908

this post is from today 6 o'clock, Dune is always up to date

13:58

@Dune i get "low fps" when opening the commands screen?

no idea

issued

14:10

i think low tier systems my have problems there

nice build/x86_64/release/objs/engine/client/backend_sdl.o:backend_sdl.cpp:(.text+0xea): undefined reference to SDL_MinimizeWindow' `

15:36

I can't compile the client, because the linker doesn't find sdl and freetype

yeah, text rendering should be improved :)

The text is rendered several times over to estimate its width

vulkan > sdl

16:34

xD

can you help me compiling the client? I have linker issues

16:35

server works <.<

16:36

@jxsl13 i wait for Vulcan PR

well, vulkan is super much code for super nothing at the end

does vulcan work on all machines?

most, I suppose

i checked and yes

Older gpus don't support vulkan. The Intel igpus before broadwell don't support it for example

17:41

For the text rendering vertex buffers would be good for caching. They are supported in opengl 2

17:43

Vulkan is overkill for tw. Even most opengl 3 features are not really necessary here

Hello, can anyone recommand me a max. value for NET_CONN_BUFFERSIZE that is still sane enough? Default is at 1024*32 (edited)

Using 64K or 128K should be okay. But what are you actually doing? When you only send a rather huge amount of data it might be okay (many votes for example). When you are constantly sending lots of packets, clients with a bad connection will probably still get disconnected after some time

times 2until something weird happens

When you send a rather huge amount once*

Well, I hide some other from scoreboard players based on in which minigame they are, therefore i need to loop through every tee and send some Sv_TeamChange msgs

what do you send that exceeds that buffer?

and if there are 64p it will cause overloads

19:08

if everyone joins a different minigame at basically the same time

19:08

i already improved it so that it doesnt resend teamchanges if they didnt actually change

19:08

but i think that still isnt enough

times 4 ._.

As long as you are not doing it each tick it's fine I think

i dont xD

19:09

its currently working without problems with the default size, but yea just wanna be sure

19:11

But also i wanna get my rainbow working without overload disconnects xd, therefore i would need it aswell. i will try sending it not each tick to every player, but do you have any ideas how i should handle it?

19:11

imagine 64players having rainbow, that would in theory mean 64*64 skin changes pertick xD

19:11

so i need to do something, for example send one half in the next tick, so that each player only gets updates every 2 ticks or something

19:11

any idea what would be a good workaround here?

19:12

Aww man i wish all that stuff would still be in the snap xd

The skin change packets are rather big (in comparison to the other packets). When you put them into the snap they would eat up quite a lot of memory

@jxsl13 you mean 1024*128?

19:15

@redix in 0.6 skins, names, clans, all that was in the snap and worked fine

19:15

in 0.5 too

19:15

in every version before 0.7 iirc

0.7 has more skinparts and each part has a name field. The packets are way bigger than in 0.6

True

19:17

So, any ideas for rainbow here (64player at the same time?) xd with the normal buffer it already starts disconnecting players due to buffer overload when one player has rainbow and there are like 10 players only, but i did send every tick tho

Hmm... Strange that there are already problems with one player

well, it sends a skinchange to 10 people every tick

19:19

thats quite a lot

But each connection has a buffer

19:20

So it should be just one per tick

mhh

19:20

well, i dont know why that happens

don't change skins on every tick

@jxsl13 you mean 1024*128?

For the start: only send it every second tick. By default snapshots are also only sent every second tick

yeah

19:22

that's 25 changes per second

why 25?

19:23

ah ye

19:23

ofc xd

19:23

sorry

19:23

well, 25*64 is still a lot xd will cause overloads

like every 10 ticks

19:23

imo

19:24

5 changes per second

isnt that very slow then?

for my eyes 10 changes per second is too fast Oo

19:24

like 10's the limit

the rainbow speed even increases with increasing server runtime

19:24

idk why

maybe you are blocking the main theread for too long, whick might cause your per tick time to get disturbed

19:25

thread

19:25

which

19:25

like getting above 20ms

How can that happen?

wth time intensive operations

mh

walking over every tile in the map seems inefficient

i know it is

19:26

i dont do that xd

19:28

that causes the server to lag very hard

did you just walk over every map tile ?

19:28

:O?

no, i tried it some months ago

hm k

Btw... The buffer does not only contain the raw packet data... Each packet also has additional data

so wait, maybe increasing the buffer *4 and sending rainbow every 5th tick fixes it already?

Thing is... When there are disconnects for one player already I don't think the protocol can handle 64 at all

mh

19:32

let me try something

19:32

i will tell the result soon

19:33

oh btw, it doenst disconnect for out of buffer, it disconnect for Error sending data

nah, hm test didnt work as expected nvm

might make sense to cycle the rainbow updates, like sending 16 updates to the first players every 5 ticks, of the next 16 every 5 + 1 ticks, 16 every 5 +2 , 16 every 5 + 3

19:44

%5 = 0, = 1, = 2, = 3

if (tick % 5 == 1) means every 5+1 tick?

yeah

19:46

6 % 5 = 1

oh yea

19:47

but couldnt i do it every tick then?

19:47

16 in the first, 16 in the 2nd, 16 in the 3rd, 16 in the 4th?

that would be %4

19:47

%4 = 0, 1, 2, 3

why

64 / 16 = 4 -> 4 ticks

19:48

per tick one

19:48

part

19:48

or one batch of 16

should i cycle based on clientid or based on how many players are on, so if there are 16 players, i would cycle through 16 at once or 4 seperated to 4 ticks?

I think based on ID

19:49

or rather

ok

not id % 4, but if id is < 16

yy ofc

Error sending data in the server console means out of buffer for the client. Error handling is sometimes a bit minimalistic in tw

out of buffer for the client?

the skin change function could probably profit from sending deltas

The client sees out of buffer. Server log says error sending data

oh okay

19:52

interesting

Yeah but delta is only implemented for snapshots

19:57

Problem might also be that you keep sending more data even when a client lost a packet. The server needs to resend all packets and it's even getting more and more.

19:58

But right now you cannot check whether the client lost a packet from outside the engine

can nobody here help me with my linker problem?

20:01

i have no clue what's going wrong

20:05

bam config says that it's using the supplied win64 libraries

it says sdl not found ._.

20:47

and commit diff?

20:47

that might have caused it?

20:47

might look at it on the train :o

20:53

any*

looks like a 64/32 bit issue to me

yeah could be

I am using mingw32, is this the issue?

21:20

it was the issue

21:20

and i needed to clean bam before switching the compiler, what the heck

21:23

nice my client crashs instantly without any error message or something

don't use mingw32 yeah

dont use bam hehe

dont use

21:36

hehe

mingw32 worked better

21:49

at least the server was working, now everything compiles and nothing works