01:41 < bridge> [teeworlds] https://www.teeworlds.com/?page=docs&wiki=compiling_everything_windows 01:41 < bridge> [teeworlds] guide says: install visual studio 2017 01:41 < bridge> [teeworlds] bam: You need Microsoft Visual Studio 8, 9, 10, 11, 12, 13 or 15 installed 01:42 < bridge> [teeworlds] nevermind, there is a note underneath <.< 01:50 < bridge> [teeworlds] bam compiled 01:50 < bridge> [teeworlds] now: 01:50 < bridge> [teeworlds] configure.lua:367: no c/c++ compiler found 01:51 < bridge> [teeworlds] do you have gcc or cl in path? 02:02 < bridge> [teeworlds] yes, but how it looks only in the native command prompt, thank you for the hint 02:06 < bridge> [teeworlds] I don't need to recompile bam, do I? 02:07 < bridge> [teeworlds] no 02:07 < bridge> [teeworlds] `bam config` should show you no compiler found 02:10 < bridge> [teeworlds] instead of adding blub\bin to the path, i needed to add blub\bin\x64_86\x64 to the path ... 02:10 < bridge> [teeworlds] windows doesn't stop to amaze me 02:19 < bridge> [teeworlds] 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 ... 02:50 < bridge> [teeworlds] in which system variable does bam look for the headers? 02:50 < bridge> [teeworlds] the headers? 03:16 < bridge> [teeworlds] okay, how do i tell bam to use a specific compiler? 03:18 < bridge> [teeworlds] `bam config compiler=gcc` worked 03:22 < bridge> [teeworlds] i switched to `mingw` since it was easier 03:34 < bridge> [teeworlds] good news: everything compiles, bad news: i reached the command limit xD 04:45 < bridge> [teeworlds] I need some help: clang throws (only with cmake) `-Winconsistent-missing-override` and i have no idea how to disable it 04:47 < bridge> [teeworlds] I like how bam is using gcc and cmake is using clang in the gh-actions-workflow 04:49 < bridge> [freenode] hmm, what to do about dickhead server that bans me immediately /for nothing/ no warning? can I blacklist off these servers/players? 04:50 < bridge> [freenode] "oh never need to bother looking for a fair game with these dickheads" 04:58 < bridge> [teeworlds] `-Wno-inconsistent-missing-override` i learned something today 🙂 10:35 < bridge> [teeworlds] JewZeus: I guess they want to play with their friends 11:43 < bridge> [teeworlds] play on servers with the ip 149.202.127.134 if you want to avoid getting banned 🙂 12:08 < bridge> [teeworlds] 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. 13:01 < bridge> [teeworlds] 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 14:56 < bridge> [teeworlds] this post is from today 6 o'clock, Dune is always up to date 😮 14:58 < bridge> [teeworlds] @Dune i get "low fps" when opening the commands screen? 15:02 < bridge> [teeworlds] no idea 15:10 < bridge> [teeworlds] issued 15:10 < bridge> [teeworlds] i think low tier systems my have problems there 16:35 < bridge> [teeworlds] nice `build/x86_64/release/objs/engine/client/backend_sdl.o:backend_sdl.cpp:(.text+0xea): undefined reference to `SDL_MinimizeWindow' 16:35 < bridge> [teeworlds] ` 16:36 < bridge> [teeworlds] I can't compile the client, because the linker doesn't find sdl and freetype 17:01 < Oy> yeah, text rendering should be improved :) 17:12 < bridge> [teeworlds] The text is rendered several times over to estimate its width 17:34 < bridge> [teeworlds] vulkan > sdl 17:34 < bridge> [teeworlds] xD 17:35 < bridge> [teeworlds] can you help me compiling the client? I have linker issues 17:35 < bridge> [teeworlds] server works <.< 17:36 < bridge> [teeworlds] @jxsl13 i wait for Vulcan PR 17:36 < bridge> [teeworlds] well, vulkan is super much code for super nothing at the end 17:37 < bridge> [teeworlds] does vulcan work on all machines? 17:37 < bridge> [teeworlds] most, I suppose 17:38 < bridge> [teeworlds] i checked and yes 18:39 < bridge> [teeworlds] Older gpus don't support vulkan. The Intel igpus before broadwell don't support it for example 18:41 < bridge> [teeworlds] For the text rendering vertex buffers would be good for caching. They are supported in opengl 2 18:43 < bridge> [teeworlds] Vulkan is overkill for tw. Even most opengl 3 features are not really necessary here 😅 19:48 < bridge> [teeworlds] Hello, can anyone recommand me a max. value for `NET_CONN_BUFFERSIZE` that is still sane enough? Default is at` 1024*32` 19:48 < bridge> [teeworlds] Hello, can anyone recommand me a max. value for `NET_CONN_BUFFERSIZE` that is still sane enough? Default is at `1024*32` 20:06 < bridge> [teeworlds] 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 20:06 < bridge> [teeworlds] times 2until something weird happens 😄 20:07 < bridge> [teeworlds] When you send a rather huge amount once* 20:07 < bridge> [teeworlds] 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 20:07 < bridge> [teeworlds] what do you send that exceeds that buffer? 20:08 < bridge> [teeworlds] and if there are 64p it will cause overloads 20:08 < bridge> [teeworlds] if everyone joins a different minigame at basically the same time 20:08 < bridge> [teeworlds] i already improved it so that it doesnt resend teamchanges if they didnt actually change 20:08 < bridge> [teeworlds] but i think that still isnt enough 20:09 < bridge> [teeworlds] times 4 ._. 20:09 < bridge> [teeworlds] As long as you are not doing it each tick it's fine I think 20:09 < bridge> [teeworlds] i dont xD 20:09 < bridge> [teeworlds] its currently working without problems with the default size, but yea just wanna be sure 20:11 < bridge> [teeworlds] 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? 20:11 < bridge> [teeworlds] imagine 64players having rainbow, that would in theory mean 64*64 skin changes pertick xD 20:11 < bridge> [teeworlds] 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 20:11 < bridge> [teeworlds] any idea what would be a good workaround here? 20:12 < bridge> [teeworlds] Aww man i wish all that stuff would still be in the snap xd 20:15 < bridge> [teeworlds] 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 😮 20:15 < bridge> [teeworlds] @jxsl13 you mean 1024*128? 20:15 < bridge> [teeworlds] @redix in 0.6 skins, names, clans, all that was in the snap and worked fine 20:15 < bridge> [teeworlds] in 0.5 too 20:15 < bridge> [teeworlds] in every version before 0.7 iirc 20:16 < bridge> [teeworlds] 0.7 has more skinparts and each part has a name field. The packets are way bigger than in 0.6 20:16 < bridge> [teeworlds] True 20:17 < bridge> [teeworlds] 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 20:19 < bridge> [teeworlds] Hmm... Strange that there are already problems with one player 😕 20:19 < bridge> [teeworlds] well, it sends a skinchange to 10 people every tick 20:19 < bridge> [teeworlds] thats quite a lot 20:19 < bridge> [teeworlds] But each connection has a buffer 20:20 < bridge> [teeworlds] So it should be just one per tick 20:20 < bridge> [teeworlds] mhh 20:20 < bridge> [teeworlds] well, i dont know why that happens 20:22 < bridge> [teeworlds] don't change skins on every tick 20:22 < bridge> [teeworlds] > @jxsl13 you mean 1024*128? 20:22 < bridge> [teeworlds] For the start: only send it every second tick. By default snapshots are also only sent every second tick 20:22 < bridge> [teeworlds] yeah 20:22 < bridge> [teeworlds] that's 25 changes per second 20:23 < bridge> [teeworlds] why 25? 20:23 < bridge> [teeworlds] ah ye 20:23 < bridge> [teeworlds] ofc xd 20:23 < bridge> [teeworlds] sorry 20:23 < bridge> [teeworlds] well, 25*64 is still a lot xd will cause overloads 20:23 < bridge> [teeworlds] like every 10 ticks 20:23 < bridge> [teeworlds] imo 20:24 < bridge> [teeworlds] 5 changes per second 20:24 < bridge> [teeworlds] isnt that very slow then? 20:24 < bridge> [teeworlds] for my eyes 10 changes per second is too fast Oo 20:24 < bridge> [teeworlds] like 10's the limit 20:24 < bridge> [teeworlds] the rainbow speed even increases with increasing server runtime 20:24 < bridge> [teeworlds] idk why 20:25 < bridge> [teeworlds] maybe you are blocking the main theread for too long, whick might cause your per tick time to get disturbed 20:25 < bridge> [teeworlds] thread 20:25 < bridge> [teeworlds] which 20:25 < bridge> [teeworlds] like getting above 20ms 20:25 < bridge> [teeworlds] How can that happen? 20:25 < bridge> [teeworlds] wth time intensive operations 20:26 < bridge> [teeworlds] mh 20:26 < bridge> [teeworlds] walking over every tile in the map seems inefficient 😄 20:26 < bridge> [teeworlds] i know it is 20:26 < bridge> [teeworlds] i dont do that xd 20:28 < bridge> [teeworlds] that causes the server to lag very hard 20:28 < bridge> [teeworlds] did you just walk over every map tile ? 20:28 < bridge> [teeworlds] :O? 20:29 < bridge> [teeworlds] no, i tried it some months ago 20:29 < bridge> [teeworlds] hm k 20:29 < bridge> [teeworlds] Btw... The buffer does not only contain the raw packet data... Each packet also has additional data 😕 20:29 < bridge> [teeworlds] so wait, maybe increasing the buffer *4 and sending rainbow every 5th tick fixes it already? 20:30 < bridge> [teeworlds] Thing is... When there are disconnects for one player already I don't think the protocol can handle 64 at all 20:31 < bridge> [teeworlds] mh 20:32 < bridge> [teeworlds] let me try something 20:32 < bridge> [teeworlds] i will tell the result soon 20:33 < bridge> [teeworlds] oh btw, it doenst disconnect for out of buffer, it disconnect for Error sending data 20:40 < bridge> [teeworlds] nah, hm test didnt work as expected nvm 20:44 < bridge> [teeworlds] 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 20:44 < bridge> [teeworlds] %5 = 0, = 1, = 2, = 3 20:45 < bridge> [teeworlds] `if (tick % 5 == 1)` means every 5+1 tick? 20:45 < bridge> [teeworlds] yeah 20:46 < bridge> [teeworlds] 6 % 5 = 1 20:46 < bridge> [teeworlds] oh yea 20:47 < bridge> [teeworlds] but couldnt i do it every tick then? 20:47 < bridge> [teeworlds] 16 in the first, 16 in the 2nd, 16 in the 3rd, 16 in the 4th? 20:47 < bridge> [teeworlds] that would be %4 20:47 < bridge> [teeworlds] %4 = 0, 1, 2, 3 20:48 < bridge> [teeworlds] why 20:48 < bridge> [teeworlds] 64 / 16 = 4 -> 4 ticks 20:48 < bridge> [teeworlds] per tick one 20:48 < bridge> [teeworlds] part 20:48 < bridge> [teeworlds] or one batch of 16 20:49 < bridge> [teeworlds] 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? 20:49 < bridge> [teeworlds] I think based on ID 20:49 < bridge> [teeworlds] or rather 20:49 < bridge> [teeworlds] ok 20:50 < bridge> [teeworlds] not id % 4, but if id is < 16 20:50 < bridge> [teeworlds] yy ofc 20:50 < bridge> [teeworlds] Error sending data in the server console means out of buffer for the client. Error handling is sometimes a bit minimalistic in tw 20:51 < bridge> [teeworlds] out of buffer for the client? 20:51 < bridge> [teeworlds] the skin change function could probably profit from sending deltas 20:51 < bridge> [teeworlds] The client sees out of buffer. Server log says error sending data 20:52 < bridge> [teeworlds] oh okay 20:52 < bridge> [teeworlds] interesting 20:52 < bridge> [teeworlds] Yeah but delta is only implemented for snapshots 😅 20:57 < bridge> [teeworlds] 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. 20:58 < bridge> [teeworlds] But right now you cannot check whether the client lost a packet from outside the engine 😕 21:00 < bridge> [teeworlds] can nobody here help me with my linker problem? 21:01 < bridge> [teeworlds] i have no clue what's going wrong 21:05 < bridge> [teeworlds] `bam config` says that it's using the supplied win64 libraries 21:46 < bridge> [teeworlds] it says sdl not found ._. 21:47 < bridge> [teeworlds] and commit diff? 21:47 < bridge> [teeworlds] that might have caused it? 21:47 < bridge> [teeworlds] *might look at it on the train :o* 21:53 < bridge> [teeworlds] any* 22:00 < bridge> [teeworlds] looks like a 64/32 bit issue to me 22:13 < bridge> [teeworlds] yeah could be 22:14 < bridge> [teeworlds] I am using mingw32, is this the issue? 22:20 < bridge> [teeworlds] it was the issue 😮 22:20 < bridge> [teeworlds] and i needed to clean bam before switching the compiler, what the heck 22:23 < bridge> [teeworlds] nice my client crashs instantly without any error message or something 22:24 < bridge> [teeworlds] don't use mingw32 yeah 22:29 < bridge> [teeworlds] dont use bam hehe 22:36 < bridge> [teeworlds] dont use 22:36 < bridge> [teeworlds] hehe 22:49 < bridge> [teeworlds] mingw32 worked better 22:49 < bridge> [teeworlds] at least the server was working, now everything compiles and nothing works