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 2019-10-15 00:00:00Z and 2019-10-16 00:00:00Z

Can we shot the flag cap time in the logs again? In 0.6 it was possible to look at the logs and see who capped the flag in what time through the chat message. But now only flag_capture player='0:ChillerDragon' team=0 is left :/

09:44

So the only way of getting stats about fastest tees is building a own tracking system that keep state of grab and capture.

you mean the time that pops up for each capture? or a permanent leaderboard?

12:00

the latter is pointless because ctf isnt a racemap

he means the first part. he wants to parse the logs(econ) in order to create statistics.

just maintain flag states

0.6 used to display the server messages as chat messages so it was possible in the logs to see how fast a flag capture was if it was faster than 1 minute. Was a nice feature to then build own ladderboards and statics. Because ctf maps are actually fastcap maps and people like to speedrun them.

14:56

rand: what do you mean by maintaining state? I tried to calculate the flag time based on the diff between the timestamp of grab and cap but timestamps accuracy only goes down to seconds :/

oh, right

15:33

then, adding a field in this message could be good, like the number of millisecond, or second with 2 decimals

yea that would be great. I think seconds with 2 decimals like in the chat message would be consitent. Im currently working on a pr but im too stoopid xd any1 knows how to get the game tick speed on the server side? because Server()->TickSpeed() seems to be something different

15:44

Image attachment

15:44

oh well xd

tickspeed is the number of tick in 1 second iirc

The thing is the client does this: float Time = aParaI[2] / (float)Client()->GameTickSpeed(); where aPara[2] is Server()->Tick()-F->GetGrabTick() But on the serverside this does give me times 10 times to big: float Time = Server()->Tick()-F->GetGrabTick() / (float)Server()->TickSpeed();

15:54

yea rand thats what i thought but following the functions both boil down to SERVER_TICK_SPEED which is fix to 50

did use parentheses in your code ?

16:00

(in your message, only the grab tick is divided by the speed)

i used the code i sent and also tried variations with parentesis castings and so on

16:00

yea that does not really make send to only devide the grab tick

16:00

thats not a time diff as far as i understand

16:02

But how i understand it the server just sends the grab tick here https://github.com/teeworlds/teeworlds/blob/master/src/game/server/gamemodes/ctf.cpp#L191 and then the client just divides the grab tick by the gametick and then uses this as the time? I miss a subtraction of the current tick. https://github.com/teeworlds/teeworlds/blob/master/src/game/client/gameclient.cpp#L655

teeworlds/teeworlds

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

teeworlds/teeworlds

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

[teeworlds] <ChillerDragon> where aPara[2] is Server()->Tick()-F->GetGrabTick()

16:03

I see a substraction here

where is the sub?

the - before the F

omg im blind haha

16:04

i read it as one llong pointer. Thanks!

16:05

can we put spaces between vars pls :/

that would be a huge PR x)

im sure im not the only blind person who mixes up subtraction with pointers more easily without spaces

no hard rules about that - see: https://teeworlds.com/?page=docs&wiki=nomenclature

the editor may color the - differently

well my editor sucks i guess

16:08

Dune: then lets add a hard spacing rule :p

but one can argue that it is better with spaces anyway

more chacracters tho xd

16:09

longer lines

16:09

so ill use spaces in my pr

just describe a format for clang-format and use it to ensures formating as pre-commit hook

I agree but @ChillerDragon imo don't make a huge diff on teeworlds just for the sake of changing nomenclature, it breaks forks that want to update etc. I've seen much worse nomenclatures, gotta adapt

Hmm should i also show no time at all in the logs when it was over 60 secs?

print it anyway

print it clamped to 60?

no issue -> no accepted pr, beware

my preference at least

16:13

nah

because the chat messages show no time when its longer than 60

i should be able to give an example

ok i would enjoy times over 60 in logs as well

from chiller's PRs and mine

@jxsl13 no, simply if what you code for is a controversial feature/change, you might prefer to discuss it in an issue first :)

any opinion on the 60 sec limit @Dune ?

hmm

we will see :D

i guess its not displayed to clients to avoid weird messages like "flag was captured in 1923.23 seconds"

be consistent

clamp it to 86400s :p

agree with rand

16:15

clamp it to INT_MAX :p

but to be fully consistent with i would fully remove the time= in logs if its over 60

consistent with what?

should be reasonable

with the chat

clamp to one day makes sense

oh, chat doesn't print those? didn't know :)

Image attachment

16:15

yea sadly :/

eh well it makes sense from the chat perspective

thats why a million tees in my db have a cap time of exactly 60 secs xd

16:16

yea

you dont need to be exactly consistant with chat

but in logs you don't want to be so human-readable, better not split in two cases

perfect

be friendly with stuff that parses the log

see join/leave, pickups etc

flag_capture player='0:foo' team=0 time=123143.23

16:16

lgtm

yes

one day :0

16:17

bigger

dont rush the the capper at least he did it

wonder if millisecond is better or worse

xD

nah id stay consitent with chat on that rand

is every flag loss case being documented in the log?

pretty sure

16:18

or my 0.6 server would have probably crashed

my point of view is that having as little case scenarios for log parsing is more important than consistency with chat

agree

do flags despawn after some time if they are not being found or would they stay forever in a different place if the flag carrier has been killed and nobody gets the flag

they respawn to the base

16:20

pretty fast

16:20

flag_return if im not mistaken

16:21

Image attachment

hm

15s ?

more like 30 i think

16:22

if(Server()->Tick() > m_DropTick + Server()->TickSpeed()*30)

nice guess

did any1 ever tested if the timers still work exactly the same since they were moved to client?

which timers ?

for flags

16:24

if you do exactly the same run in 0.6 and 0.7 will it be the same time?

about capture ?

y

the calculus is the same

yea i guess. But maybe it is calculated after/before some other calculations and thus ofsetted. Probably too few difference to be seen in the last two decimals

16:26

i was just wondering if any1 ever tested it. I like testing instead of using brain haha

the part you show that the calculus uses the exact same values

yea but i mean if it position in code changes where the time calc happens it doesnt matter if it is the same. a = time.now() b = time.now() foo() // diff will change when u call bar here instead diff = b - a

16:30

rip irc

the only thing the client does is dividing the value sent by the server by SPEEDTICK

well nvm i cant explain what i mean but it probably is not having any effect anyways

it does not care of its tick

16:33

and only the server knows/decides who captures and when

16:33

so it controls the truth

16:33

the server is everything

16:33

praise the server

16:33

...

16:35

ChillerDragon, if I do : a = time.now(); b = time.now(); stuff(); diff = b-a, whatever the duration of stuff(), diff will hold the same value

ah ye thats true xd

16:37

move stuff() between a and b

travis ci rip

16:46

github actions > rest

ChillerDragon: and this case does not happens for capture timer, since the server send the diff :)

this is getting weird.. sorry for everyone who gets spammed with this useless conversation but rand seems interested xd https://github.com/teeworlds/teeworlds/commit/6c530b2926b256342ffa63e03a3e399722410d0d#diff-084568a27829d83965cba5518d9178abL193

made ingame notifications for players simple game messages and let...

…e client handle/localise them

16:53

but the diff used to be in a float init now it is in the 3rd parameter of a function call so it is in a different position in code so i was thinking if this could affect the diff being different but the offset is so little it most likley has no effect at all

16:54

diff = a -b foo(x, y, a - b) // different than foo(x, y, diff)

16:55

but lets end this useless conversation now xd i am 99% sure that the change has no effect at all on the time.

16:57

i just tested it and all worked fine. It probably doesnt even make a difference at the 100st decimal

16:57

(sorry)

17:00

oh travis seems to be broken?

ChillerDragon: Server()->Tick() is a integer constant between two tick

17:16

so, it does not matter, it is not changed before the every thing is resolved (like tee/projectile movements, pickups etc)

oh true

btw, prefer int as the type of "diff" (since it holds an integer) (imo)

oh good catch

but now u understood my concerns right?

17:19

yea that the tick doesnt change during one tick makes sense xxxd i could have thought about that

why do we now have NETMSG_RCON_AUTH_ON and _OFF instead of just _STATUS?

17:35

oh, ofc you also removed the name from NETMSG_RCON_AUTH, not like anyone was using it...

rude Learath2

oh cmon, I've stated my displeasure in quite a benign way, it's not rude at all

i feel like heinrich xd but you sound lill agressive. Not very motivating to help you. (im just tryiin to spread some love here)

Learath2: git blame says last modif is oy 2012-07-21 20:00:01

17:52

try git show 9ae4479dad48d09b38dfd142d9a40fc14a3dd335

17:52

looks like a very old cleanup

Just wanted to ask whether there was a reason for the extra message

yeah, my point is that it's unlikely you find an answer 7 years later from anyone but Oy :/

Image attachment

17:59

wtf ci hates me today

oh just noticed oy merged my list maps thing

18:08

after 6 years :D

18:09

\o/

nice one (Y) keep up the great work.

there was an effort to adapt PRs and merge what was desirable to clear the backlog after 0.7.2. see also https://github.com/teeworlds/teeworlds/pull/1989

Implement SushiTee's shell sort, rewrite it to match pseudocode; d...

Implements @SushiTee's algorithms from #1169 Deprecate heap, quick, merge sorts. Carefully rewrite the shell sort to match 1:1 the pseudocode in https://en.wikipedia.org/wiki/Shellsort (wi...

wait, what.. oy used a c++ stl function?

18:37

aren't those stl functions like the nemesis of the teeworlds code base?

:D

quickly looks into the code base tonsee, if it's thill there

18:39

still

18:41

holy moly look at this.. my eyes xD https://github.com/teeworlds/teeworlds/blob/master/src/base/tl/algorithm.h

teeworlds/teeworlds

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

18:42

std everywhere :0000

My personal opinion is that STL is a shithole of overly abstract tools and poorly optimized stuff

18:42

But sometimes it does the job

"poorly optimized" :D

Some people get wet over using the maximum level of abstractions, template and c++17 stuff, definitely not me

18:43

Modern =/= good

Some of the STL is quite decent to use

18:44

e.g. sorts look nice with lambdas

my problem with the tw code base is, that it should slowly transition to using some tested ages old (not modern) containers like vector and not implement containers everywhere yourself.

Learath2: problems with lamdas to me is that the syntax is dreadfully unreadable in c++. Would be nice in a proper functional language

one could use auto selfexplainingvariablename = lambda; and then put the labda comparator into those sorts.

Huh, syntax is definitely subjective, but I find [](){]

18:47

[](){} fits quite well to C++

instead of having infinitly long nested lambda expressions.

I don't know, def subjective

to make it more readable

When I read Haskell or caml lambdas i know what it does, not c++

"why don't we rewrite teeworlds in my favorite language™"

python?

18:53

agreed

18:53

xD

18:54

hm, rust?

Heinrich did that already

nah, just a poc server

18:57

gotta port that to 0.7 someday

please port fstd's wireshark dissector to 0.7 first :/

18:59

fstd: yo here? send help xd

i think before porting it to 0.7 you'd have to port it to 0.6 ;)

urgh, freenode

and wireshark itself changed a ton too

0.6 works fine

oh really

i ported it to newest wireshark base

i must ahve forgotten

19:00

great

compiled and works ok enough

19:00

i messed ur code up a bit tho xd

heh

i have no clue how wireshark works :/ in 0.7 it crashes

19:01

any chance youll work on a 0.7 version? <3

today is literally my last day off, so i'm not sure i find the time

19:02

but if so i'll have a look

well in case my crap helps here it is... https://github.com/ChillerDragon/wireshark

ChillerDragon/wireshark

wireshark dissector for the teeworlds protocol. Contribute to ChillerDragon/wireshark development by creating an account on GitHub.

aight

what are you using that dissector for?

is this why you hi'ed me the other day in PM?

depends on when im usually lost using your old awesome projects might be pstd related as well

19:03

my quakenet is broken so i can't pm you :c

19:03

join freenode hehe

is it intentional, that skins cannot be completely black, just some kinda light grey or is that a bug?

sup

19:06

bbl playing some dead by daylight tho

@jxsl13 intentional

19:07

we had black tees running around in 0.5, that looked unaesthetical

wowo

19:07

xD

19:07

thin ice

xd

is it client side or server side?

19:08

or bith=

19:08

both?

both

19:08

in 0.5 it was only clientside

19:08

^^

i remember a yt video for black skin tut in 0.5 o.O

should be server side only :'/

19:09

so ppl can decide themselves if they want black tees

19:09

in their mods*

haha true server dev

gib modifications power pls!

yes

agree tho. Put as much as possible in server.

hm

19:10

I think the check might only be in the client for setting your own skin color

19:10

not sure, try it out

is the hue to rgb calculation altered or i the range of the hue values altered Oo

19:11

is

19:11

so might it be possible to manipulate the settings files to bypass the checks in the color picker

https://github.com/ddnet/ddnet/blob/master/src/base/color.h ^^

DDraceNetwork, a cooperative racing mod of Teeworlds - ddnet/ddnet

19:12

All vanilla teeworlds colors go through ColorHSLA::Lighten

ok, so a calculation, no real check

haha Learath2 the color pro

hm, negative hue xD?

I don't think in vanilla it's possible to bypass

19:13

As vanilla doesn't even know how to read non altered colors :P

19:13

Whatever it reads, it clamps the L

rip :'/

19:13

gib server the powers!

gib xd

19:14

beerlang detected

well, the vanilla code looks more cryptic in that regard :c

19:17

float v2 = HSL.l < 0.5f ? HSL.l * (1.0f + HSL.s) : (HSL.l+HSL.s) - (HSL.s*HSL.l);

jxsl13 took me a couple days to clean all of that up

19:18

and keep the old colors the same, it'd be easier to break but all the players would behead me

so basically that 0.5 check seems only to exust in hsl to rgb

19:19

and looking for that function name only results in me getting a menu source file to show that it's being used there

19:20

damn, skins

19:20

skins.cpp as well ..

19:22

DARKEST_COLOR_LGT=61,

19:22

make this 0 xD

Then people will set black color client side and think it works

this whole color stuff seems to be completely handled by the clients

Server too

so for oneself one could set this to 0

19:25

where does the server check and apply those lightening operations :o?

19:25

the server seems only to pass the color to the clients and the clients force the lighening stuff on the received colors?

19:25

src/game/client/components/menus_settings.cpp

19:26

src/game/client/components/skins.h

hm, I don't see any server side checks..

@Dune you online?

19:43

@heinrich5991 online?

19:43

forum pls

Heinrich busy 0.0

:O?

Ddnet Client release struggle

fixed forum

Hm?

ddnet still alive Oo

19:49

ty for killing off the tw forum activity :'/

<jxsl13> holy moly look at this.. my eyes xD https://github.com/teeworlds/teeworlds/blob/master/src/base/tl/algorithm.h ← huh, concepts in 2009

teeworlds/teeworlds

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

the file is that old?

@jxsl13 the lighten happens clientside

huh, that's blasphemy

20:06

@ minus

did a blame, says 11 years ago

cpp consortium noobs

20:07

xD

20:08

must have not looked properly, but including the whole algo header for one sort algorithm Oo

20:08

were the pros and cons weighted against each other there

20:10

hm, the range.h looks interesting

20:10

cool stuff

20:11

compile time checks

20:13

I wonder if those checks are being optimized away, as the code is being never entered

It's called dymamically dead code

20:17

Compilers are not that bad

I heard compilers are rather amazing at optimizing code

20:18

it's not like imma disassemble the binaries to check what's gotten optimized away ._.

20:19

was just wondering and you hd the answer

20:19

had

jxsl3 the server sends the color data as it receives it from the client, however when rendering the color is converted to rgb, during which it gets lit up

21:14

heinrich5991 broke the ddnet client and went into hiding :P

yeah, client lightens ip in receiving and on sending

21:21

it

21:21

up

21:21

why not make this server handled

what benefits would that bring?

the server regulating coloration?

22:08

would be a small benefit, maybe not worth the effort

ChillerDragon, I lost myself with wireshark and dissector in lua -> https://0x0.st/zxtD.lua

22:31

https://pb.died.re/uploads/Sids.png https://pb.died.re/uploads/8NQc.png

Embedded image

Embedded image

Exported 312 message(s)