Teeworlds - bridge

I'm making a web gui for Teeworlds, what do you think? https://lounge.bittemple.org/uploads/75e1e24576e897fa/image.png

looks good

18:16

how do you interface with the server?

Econ prolly

yeah econ

hm how it works?

18:28

that web gui will be only for hostings?

18:29

or it works as api

18:30

im stupid sorry then dont answer me

18:30

i understood all

it's a node.js app that connects to a teeworlds server via econ. it monitors game state and forwards game events to the web browser.

18:32

I have the node <-> econ part of it on github already but the gui part isn't published yet

doing this econ based is really prone to breaking as the log format isn't really stable :/

yea i noticed :P

but it looks great, gj

thx!

I decided to remove 128 players now again from my server. The reason why is because it is just too laggy to always send those connect/disconnect packets :/ otherwise it was working very well, also with the players with same IP having the same IDs (for dummy hammerfly and correct pings in chat). Whispers were also working. There was nothing bad about excpet the laggs coming from the (i guess) connect/disconnect packets. When I did 256 in 0.6 it wasnt laggy at all, no packets. On LAN server 0.7 with 128 it is also okay, since the packets only go to 1 player (me, not the dummies). It's sad, but I removed it now, its way too laggy sometimes. Server was mostly at about 70-90 players, maximum was 94 :(

23:28

@Dune could we move the playerinfo back to snaps for 0.8?

move it to another branch

The player info is fat because of skin names, @fokkonaut

people might wanna use it as reference

@jxsl13 why would they, it doesnt matter anyways

23:29

It is just too laggy

as reference that can be improved with threads

I asked @Learath2, it seems this cant be threaded in an easy way+

23:29

its a function that gets called every tick

23:30

or basically every 5th, in ddnet

23:30

for me every 50th, due to the packets :/

23:32

Also, @jxsl13 what would a thread do better? The packets still need to go out

23:32

Its not just the algorithm, that should still be fine for 128 players

23:33

@Dune is the playerinfo soo much bigger that we cant handle it anymore?

Well, it would take a significant amount of bandwidth

snaps are deltashots so they only send new stuff, dont they?

At least that was the reasoning behind this change as far as I know (and according to @heinrich5991 )

I'm not sayi g I have a solution, but saying to leave your hours of work for someone that might have one. dumping that rather big project into tue trash bin is just a waste.

the first three or so aren't deltashots

I would love to give those 20-30 extra players per day the chance to play, but with these laggs it is just not possible

23:35

Also its a damn nice feeling if you know your server got 94 players at once, for 0.7 and 0.6

well it's not like they can't play. two 64p servers sounds reasonable to me

But the map is so big that it is just awesome to have that many players at one server, not spread apart

I understand, it sounds like there is a difficult compromise and I don't have the technical knowledge of the Teeworlds network stuff to weight benefits and inconvenients

hm

23:49

I don't know how exactly the player messages work

23:49

you say it's join/leave

23:50

that should cause less traffic than changing snapshots

definitely not, it sends a whole packet of the tee: name, clan, skinparts, country

23:50

also the cid of course, whether its local

that would also be in the snapshot, at least if we'd do it as you propose

23:51

and it would cause more traffic than the join/leave packets

why?

because when you move that information into the snapshot (like it was before), then it would have to be sent multiple times if the client has a ping >40ms

23:52

the server sends the difference to the last acked snapshot

23:52

so if the client can't ack within 40ms (time difference between two snaps), then you're going to send the player changes twice

so is there a good solution to this?

you say that the players are far away from each other?

23:55

perhaps you could send less player changes

i already send them each 50 ticks

23:55

ddnet does it each 5th tick

well, maybe one could get away with not sending them at all unless one needs a change

23:56

i.e. only send them if a player comes into view that the client doesn't currently have

mh