by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 04 11:18
    CheeseTastisch opened #375
  • Aug 04 01:05
    C00ckieHunter edited #374
  • Aug 04 01:04
    C00ckieHunter opened #374
  • Jul 30 23:04
    Mav1st opened #373
  • Jul 30 19:38
    CheeseTastisch closed #372
  • Jul 29 15:32
    rogermb labeled #372
  • Jul 29 15:32
    rogermb commented #372
  • Jul 29 08:25
    TAXSET commented #372
  • Jul 29 07:58
    CheeseTastisch commented #372
  • Jul 29 07:43
    CheeseTastisch commented #372
  • Jul 29 07:42
    TAXSET commented #372
  • Jul 29 07:41
    TAXSET commented #372
  • Jul 29 07:31
    TAXSET commented #372
  • Jul 28 20:12
    CheeseTastisch opened #372
  • Jul 28 20:11
    CheeseTastisch closed #371
  • Jul 23 23:56
    rogermb commented #371
  • Jul 22 21:08
    CheeseTastisch closed #363
  • Jul 22 21:07
    CheeseTastisch opened #371
  • Jul 22 00:08
    rogermb closed #370
  • Jul 22 00:08
    rogermb commented #370
Roger Baumgartner
@rogermb
The only way you can guarantee the freshness of that data would be to send clientlist commands every X minutes
Yup, the server query interface doesn't
I'm not sure if the client query interface does, though, but we're not using that here
WolverinDEV
@WolverinDEV
Well thats a big uff there.
I already knew some drawbacks of the query and actually pusht it a bit.
CQI is some different stuff (kind of)
Roger Baumgartner
@rogermb
And that's just one part where I think the event system is sorely lacking. What also really bothers me is how they can't even use the same identifiers for the same kind of data
WolverinDEV
@WolverinDEV

can't even use the same identifiers for the same kind of data

you're thinking of the cluid and client_unique_id thing right?

Roger Baumgartner
@rogermb
For example, but not only that. The main thing I was thinking about was the data sent in client join events and the responses to clientlist and clientinfo
I'll see if I can find some examples in our code...
Actually, scrap that, they seem to be using the same identifiers there, so no complaints here.
WolverinDEV
@WolverinDEV
HAHA Yes, we're both using the same keys there since the information are stored by thus keys as well
Roger Baumgartner
@rogermb
But another thing that's really quite annoying to work with is how the client join event, clientlist and clientinfo; as well as channelinfo vs channellist send different parts of the available client / channel information that is not a subset of each other
Like, just look at this mess: https://yat.qa/ressourcen/variablen-parameter/ :joy:
Sorry for the German link
WolverinDEV
@WolverinDEV
I'm German all right :D
Yes Redeemer has done some search :D
Roger Baumgartner
@rogermb
But basically, this kind of mess makes designing an object-oriented API around the server query extremely difficult
If you just do a JavaScript, pass around dictionaries of strings to strings and all that, that doesn't really matter, but if you try to actually build a type-safe API, it's extremely annoying
WolverinDEV
@WolverinDEV
But I could actually understand why (I agree it's a mess):
With channellist or clientlist you could receive the minimum amount of data to properly render the channel tree or a client list (at least what the we're thinking would be the minimum required data).
With clientinfoyou're actually able to receive extra data which could be displayed in some kind of "Info" Window or in the TS3 client's case on the right side.
But more pain the the ass is the thing that responses come without any return code so they're sometimes hard to assign
Roger Baumgartner
@rogermb
Or that the TS3 server offers no way to perform any kind of "transactional" commands. If you get disconnected, you have no clue which commands you sent got executed and which didn't
I shouldn't call it transactional, that's a step above what would be required (of course, transactions would be really nice :smile:). What would be required is some kind of journalling
So that if you get disconnected, you could request that the server re-sends the last N responses sent to the client (e.g. the server could limit that to 3 commands)
Then you would have some way to pick back up where you left off, which currently just isn't possible
WolverinDEV
@WolverinDEV
I don't actually see a point in there if the TS3 server fits this requirement (TeaSpeak does):
  • Send a response code for the last processed command
  • Disconnects the client without any further command processing
Roger Baumgartner
@rogermb
Imagine this scenario: you're a client and you send out 5 commands to the TS3 server.
You see from your end that these 5 commands have been sent.
The server starts executing these commands, and you receive 1 command response, but then you get disconnected
How many commands got lost on the way to the server, and never even got executed? How many got lost on the way back, that is, the commands were executed, but we just couldn't receive the response
WolverinDEV
@WolverinDEV

How many commands got lost on the way to the server, and never even got executed? How many got lost on the way back, that is, the commands were executed, but we just couldn't receive the response

Ahh you're more talking of some network issues rather than the server disconnects you.
I see the thing there. But imagine the server side which not only has to keep track of active sessions it would have to track disconnected/inactive as well

I also don't know any other API which does this as well
Roger Baumgartner
@rogermb
Yes, it would have to keep track of the last N command responses for some time, which in my opinion is a manageable overhead, considering that there is only a finite amount of server query accounts on the TS3 server (you obviously wouldn't do that for unauthenticated queries)
But keep in mind that the server query interface is already a stateful protocol; the TS3 server has to keep track of state not only while the TS3 query is online, but also across sessions in the client database
WolverinDEV
@WolverinDEV

Yes I see that point.
It's interesting but I'm actually not seeing a that huge use case tbh.

We could talk back later (started CS match :D)

Roger Baumgartner
@rogermb
Sure! gl & hf!
WolverinDEV
@WolverinDEV
HAHA won :D
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
Hey :)
I am working on a new Bot which manages the Support but it is only working once after that it just spits out random blue numbers into my client... does anyone know what I could be doing wrong?
Roger Baumgartner
@rogermb
That sounds really strange
To the point where I don't think it's a TS3 API issue
Could you show me that "random blue numbers" output? Also, what's your code?
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
I am getting (in blue) 0
And after that in Red
Invalid client type
Roger Baumgartner
@rogermb
Code?
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
Am I somehow able to make a pic in here? Because I am on my Phone
Roger Baumgartner
@rogermb
Uh, pretty sure you can upload pictures, yeah
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
How?
Roger Baumgartner
@rogermb
No clue
I don't use Gitter on my phone
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
Roger Baumgartner
@rogermb
Why do you keep sending getClientInfo commands to call isInServerGroup on them?