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-11 00:00:00Z and 2019-10-12 00:00:00Z

in fact, since ClientInGame() returns false for dummies, I guess some tests could be simplified

http://www.dunecase.com/index.html

an econ python api would be cool.

Why is it even needed to check for existing player/isdummy when sending a message? afaik while sending it checks for the client state aswell as if its a dummy. (at least for dummies on my server, i have my own). Maybe you remember the thing where my console got spammed because i didnt check whether m_applayers[i] exists before sending a kill message. I thought it would return anyways if the client state is invalid

checking m_apPlayers usually prevents from dereferencing a nullptr :D

yea

15:00

Well, my kill messages work a bit different, I dont send them to everyone (-1), i send them to each player individually because players from other minigames are not supposed to get them. Before I added the check whether player exists, it sent the message also to the invalid clients, and that spammed the console because it told me thats not possble

15:00

sonething invalid was the message, trying the send message blabla

15:00

But as i said, i thought it would return anyways if the client state is not ingame

I'd love to send sounds individually :'(

you can

15:02

I made a SoundGlobal() function, like the old one in 0.6 (hack ofc, they removed it from server) and an individual sound function

all I saw yesterday was that sound events are being created in the world, and haven't looked further into it.

https://github.com/teeworlds/teeworlds/blob/3fbe40e16cab948a974b02366d81355c1122c7df/src/game/server/gamecontext.cpp#L177

teeworlds/teeworlds

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

15:05

this is the normal CreateSound()

maybe add some target id to the events

15:05

with a default value of -1

void CGameContext::CreateSound(int Sound, int ClientID){	CreateSound(m_apPlayers[ClientID]->m_ViewPos, Sound, CmaskOne(ClientID));}

15:05

this is it

15:05

With this, you can send the sound to one player only

15:06

We use m_apPlayers->viewpos, because character one wouldnt work for spectators

15:06

CmaskOne gets the mask of only that single client

15:06

So other wont hear it

thanks, will maybe later look into it. Even tho I kinda don't want to tinker mich with vanilla logic, will kind of need this for projectiles, will I just need to prevent the event creation with this function? Kinda swap the creation of e.g. an explosion with this?

You can send explosions only to a single player with CmaskOns aswell

15:11

Or what is yout plan?

15:11

you cant split explosions from their sound

my plan is to send projectile/lasers with their sounds etc only to one target, the one shooting them and for everyone else not to see those effects and or sounds.

But can they interact with it?

no.

15:14

those other players should not be affected by the projectiles sent from the, let's call him "punished" player

15:15

it's kinda hacky, atm that the shokting player actually sees the projectiles, but doesn't hear the sounds

Whats your progress?

15:16

Like what do you have already?

15:18

(Github, maybe?)

the snap part is kinda done, the explosions are disabled, but would be nice to have them sent to the punished player as well and the sounds should be sent to the player as well.

15:19

it's on the zcatch github

Yeah, both are basically the same. You need to send explosion and sounds only to CmaskOne(id). Therefore, just add another parameter to the CreateExplosion and CreateSound function (int Mask = -1). You have to add that Mask parameter after sizeof(CNetEvent_whatever). Just seperated by a comma. And for the explosion, you have to make sure that you pass the client id of the punished tee, to check while dealing damage, that really only that one tee is getting through, all others just continue

the method SendXXX used in CCharacter::Die is a low level function, so it does assume you know what you are doing with it. That's why you have to check the presence of client. There may be another solution

Ahh

15:23

Thanks

15:25

I forgot, you also need to modify eventhandler

15:25

Just need to add a Mask parameter to eventhandler::Create() too

15:26

m_aClientMasks[m_NumEvents] = Mask in that case

15:26

I can help if you want

15:30

I will make a PR :p

@jxsl13 cant build with cmake?

I only build woth cmake

16:32

thanks for the pr @fokkonaut

np

16:33

@jxsl13 I couldnt get it to create the cache

16:34

at least not first try, as i said, dont have time, will go soon, that means no pc :p

16:34

even if the pr doesnt work, you should get the idea of how it works now

yeah, I will fix any build issues myself thanks.

^^

except for windows

16:35

xD

oh, well thats the problem then

16:35

I am on windows

well, ok xD

xd

any opinions on changing spectate_next a bit? I was thinking about only wasting one key for spectate binds and do bind x "+spectate;spectate_next but it doesnt work too smoth for now. spectate_next has some weird delay and it keeps switching when it gets hold.

leave it like it is pls

16:56

xd

the delay is server side

17:32

btw

then dont resend it on hold

u

Exported 68 message(s)