Teeworlds - general

@Aoki what do you want buddy (edited)

i do

@heinrich5991 I hate how 0.7 removed everything from the snaps :(

11:58

Well, I am talking about the CPlayer snap

petition to stop this madness and put player info back into the snap

13:19

in 0.8 ofc

the idea why it was moved out of the snap was because the new skin info made the player info huge

13:21

which kind of makes sense, because the whole snapshot is sent in the beginning a couple of times because the client hasn't acked any yet

13:21

the problem is that we have a mismatch between the snap world and the game message world (but we also had that before)

13:21

there are two different states, one for stuff in the snap and one for stuff in game messages

13:22

in 0.6, there was the problem that we couldn't clearly associate player IDs to chat messages or kill messages

13:22

because snaps might get lost that carry the necessary data about the player name

13:23

now we have the problem that we don't know the names of ingame tees, because snaps might arrive before the relevant game messages

13:23

I don't know a sane way out of this

13:23

if you have an idea, please enlighten me

I have one, not breaking status quo until we come up with an idea

that's obviously not a solution to the problem I stated

that's obviously not a solution to anything

it is, to not breaking things e.g.

it's a superset, it's the default solution one should take for any issue that comes up

I don't see it to be a big deal that we don't know the names of tees

13:25

Well, some components would need to be adapted

@Dune do you know how we handle missing tees? I bet it's handled really implicitly

13:25

like no one really thought about it

What do you mean by missing?

13:26

I can't think of a situation where we have missing tees atm?

snapshot comes in with an ID we don't know

13:26

tee is right next to us (edited)

a snap that arrives before game messages can cause a tee not to exist

But that doesn't happen atm, right

why not?

13:26

please read the description I gave above @Dune

there is nothing in the code that provides synchronisation

I tried to state the problem above

13:27

(the code in 0.6 had the same problem, just in different places)

@heinrich5991 I'm not sure if forcing synchronisation is a good idea though, it might require us to wait for either a game message or a snap, which is not desirable performance/fluidity wise

waiting is not the solution

13:30

I thought that not reusing player IDs might help

13:30

i.e. only ever increase them

13:30

that would help the client detect such a situation and let it handle an unknown player

that doesn't solve the broader issue of synchronisation between the game messages and snaps, it only solves this specific instance of it

it seems to me that the problem of synchronization is mostly that of player IDs

13:31

what else is there?

13:31

hm. map changes

well I haven't really thought of any other problem, but I never really thought about the issue in general

13:32

How about something like "vital" snaps with associated serial numbers? We can send the serial in game messages and only increase the serial when the gameworld significantly changes?

13:33

The client would know that it missed a snap if a game message with a serial in the future arrives

ah, you mean tracking of generations of snaps, basically?

any issues we can think about, we could increase the serial number for

13:34

y ^^

so. how does the client react to a snapshot that it doesn't have the game messages for?

the client wouldn't know if there are game messages for a given snap in this scheme

hm. then we still have the "missing player" problem

well missing player wouldn't be an issue, you'd get a game message with a serial in the future, thus we'd know if the id in this message refers to someone that doesn't exist

13:38

but with a bigger connection issue you'd get a "substituted player" issue instead

IDs get reused

13:39

yes

that we can't detect

13:39

well we could just hold game messages that we can hold on to until the snap we need arrives?

yes

13:41

hm. I think the player names/clans are better suited as messages

13:41

that way we always know which IDs to associated with chat messages, etc.

13:41

if they were in snaps, we might entirely miss players

well, right now startinfo is already a part of messages not snaps

yes

13:42

so the snaps only need another integer that says which generation of game information it applies to

13:43

hm, no, that's not sufficient

13:43

we'd still need a way to find out if a player rejoined or not

13:43

so we'd still need never-reused player IDs

[4:43 PM] heinrich5991: we'd still need a way to find out if a player rejoined or not what for?

for not displaying wrong kill messages, etc.

13:44

ah no

13:44

for not displaying wrong nameplates

If we don't have current enough game info, we hold on to the game message

13:44

hm, nameplates are indeed an issue

13:45

tbh, with this scheme, as soon as you get a game message in the future, you really shouldn't be displaying any information that we are keeping track of with generations

13:45

but that's not really desirable

we can display an unknown player

13:46

if the player names etc. remain in the game messages and we only have the problem in snaps

13:46

we can use non-reused client IDs for tracking players

13:47

then we always know whether we know the player name

13:47

and if not, we just display (unknown player)

I guess we could just do non-reused client ids, we didn't come up with any other issues anyway

map change

I was trying to avoid the rather large rework required by the non-reused client ids

we can still make sure that client_id % 64 remains unique (edited)

you'd either need an ugly translation layer or actually rework every array that has MAX_CLIENTS elements to a sparse array

13:50

Both making sure that's unique and the rework would be rather ugly, no?

why?

13:50

that allows us to keep using the MAX_CLIENT arrays

13:50

without a translation layer

while(m_aSomeArray[cid % 64]) cid++; to assign a client id

yes, can keep a free list if you want performance

to make sure we never re use one we'd have to always start from the last client id we assigned

13:51

cid might grow faster then expected with 64p servers

max 64 per player in the worst case

if player 64 keeps leaving and rejoining, cid would keep getting +64 basically

yes

I guess with a long it'd take quite some time before overflow ever becomes an issue

13:54

and we could keep track of the oldest id we've used for a given client and as people leave, open up the earlier parts of the id space

we get 33 million joins in the worst case

13:54

with 31 bit integers

13:54

recycle those after a map change and it's fine

hm, how did you come up with 33m?

2**31 // 2**6 // 1000 // 1000 in python (edited)

why divide by 1000?

to get the number of millions

ah

13:58

hm, I think += 64 is really the worst case

13:58

I couldn't come up with a worse one

me neither

before the player snap info is saved, the client checks if the slot is active actually that does not seem to be the case for characters

14:23

so there should not be any wrong entries in the scoreboard but there might be tees without name

14:25

in general the snapshots need some more validation. for example sending a character with a far future tick value isn't a good idea

Is there a tool to convert 0.7 maps to 0.6?

no, only the other way around, afaik

:/

0.6 doesn't have all the tilsets 0.7 has anyway, so it wouldn't be possible in the general case

tilesets doesn't matter

(you could just embed them)

the format changed

17:01

yes

tile layer format specifically i believe

@ChillerDragon create a playlist with teeprogramming videos

Hi ! after upgrading ubuntu to 20.04, I have this error and I can't play anymore, cas someone help ?

[2020-04-24 19:28:29][client]: starting...
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  96
  Current serial number in output stream:  97

@Rimso try rebooting if you haven't already

ah it was so simple, thanks

;d

the prediction dies on 0.7 with throughhook tiles

20:22

not that I am mad that a hack looks hacky

?

even the demo lags <.ö<