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 2022-03-29 00:00:00Z and 2022-03-30 00:00:00Z

https://github.com/teeworlds/teeworlds/issues/2645iirc some of his findings got CVEs

Issues · teeworlds/teeworlds

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

h

07:35

hi

07:35

hi

07:35

hi

07:35

hi

07:35

hi

07:35

h

07:35

hi

07:35

hi

07:35

hih

07:35

ih

07:35

ih

07:35

hi

07:36

hih

07:36

ih

07:36

ih

07:36

hi

07:36

hi

07:36

hihih

07:36

ih

07:36

ih

07:36

hi

07:36

i

07:36

helo

07:36

:(

07:36

whynobody have

im fokko .sunglaseestststst

.a

.a

a.

07:37

s.d

07:37

as.

07:37

d.as.

07:37

h,

07:37

hi

07:37

hi

07:37

hi

07:37

hi

07:37

.a

.s

07:37

.d

07:37

.lol

http://i.imgur.com/3M9fQ.jpg

Can u guys stop faking me, thanks

Fans

can somebody explain to me, why this works? https://github.com/teeworlds/teeworlds/blob/26d24ec061d44e6084b2d77a9b8a0a48e354eba6/src/game/gamecore.h#L42

15:48

this looks like C++ magic to me, trying to interprete this class as a bunch of ints

15:50

and shouldn't this be devided by sizeof(CTuneParam)?!

CTuningParams is an array of char*

16:00

So I guess this assumes sizeof int is sizeof char*

16:00

Nothing C++ in this

I am pretty sure it's an array of CTuneParams which happens to story just one integer value

16:06

store*

16:13

but thanks for the reply, it made it clearer for me ^^

yeah that code looks wrong

16:56

fails to account for s_apNames and any potential padding

16:56

it's an accident waiting to happen

@Assa wanna open an issue?

17:07

ty for confirming minus

s_apNames is a static member, so I guess it's ignored? I can open an issue, but I am currently working on a better setup for tuning variables and Materials anyway

Don't change stuff if it doesn't bring concrete improvements

A new refactor PR? The backlog for oy grows :d

I wouldn't if it wouldn't ^^ Currently I need to add tuning variables for each material i am adding, while the new materials itself are just the same variables with different values

Will some of the tunes be map based?

materials are tune-based

17:27

ice is nothing else then default-ground with fancy tuning settings

I wanted to work on such system, where map could transfer some of the tunes in the map, with a few acceptable presets. This would be done in order to allow to adapt the "water" to suit their map's theme and needs

there already is a tuning-layer in ddnet if you are interested

How does it work, exactly?

the tuning layer? you have 1 block with an ID like a telelayer and envlopes, that contain the new tuning settings

oh, you're right, Assa. still isn't nice tho

And data for that block ID can be changed in their editor?

yes

Here similarly I guess :) i was planning to add a tab where one could edit various tunes (mainly for water) or just pick a preset from vanilla. (Those accepted by vanilla gametypes)

What I am also modelling is material interactions, what if you are standing on Ice (left foot) and default ground (right foot) at the same time? I don't want to hardcode each interaction, so I genealize this

This would be done to let vanilla mappers do their own thing while keeping in with the vanilla 'purity' requirements

17:34

You want to make a smooth transition between materials?

Yes, and I have already done this

17:35

well, "smooth", for friction i get the minimum, for accerlation the maximum as example

17:36

but you could do it smooth, too

CTuneParam are class that contains only a int, so CTunningParams is a list of int members

20:01

oh, CTunningParams::Num() is only used for the debug HUD

20:06

iirc, the number of tune params is not part of the network layer (assumed to be the same for server and client, so 32)

20:10

if you want to start worrying, look into how each tunning param is retrieve for this HUD : *pValue = (float)((CTuneParam *)this)[Index]; (where this is CTunningParams)

thank you ^^ I already understood the code, but it's still a bit hackish. Does Teeworlds have a map Type like std::map?

20:20

This would solve all problems there

no

how would that help here ?

a map already implements methods like size(), and also we are searching in that static names field a lot

we are looking into a small array, the Num() function is likely to compute anything but return a constant known at build time

20:30

as long this data is not dynamic, this is good enough no?

yes, as long as you don't introduce new stuff, like materials

if you add tuning stuff in tuning.h, macros should work to produce a correct CTunningParams class

20:36

(but, no client (except the one built with this setup) will like it)

exactly! But we can already do a lot with the already existing tuning variables with different values

I missed the point then. anyway, the tuning could be dynamic, carefully look into the code where it's assumed fixed. The name lookup doesn't worth a std::map tho (with respect to teeworlds codebase)

Exported 100 message(s)