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 15 15:10
    TAXSET commented #375
  • Aug 09 14:28
    CheeseTastisch commented #373
  • 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
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?
Those also work on regular Client objects
Also, creating a new Timer object for a single task is pretty cringe
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter

Oh ok...

Its been a long time for me since I programmed my last TS3 Bot and I haven't generally programmed for a while now because I wasn't home

Just trying to get back in starting with a Bot for a friend's server

Roger Baumgartner
@rogermb
I'm actually not sure what's causing the invalid client type error. You might just want to single-step through your code with a debugger and see what statement triggers that exception
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
Ok
Roger Baumgartner
@rogermb
In essence - calls on Client, ClientInfo, Channel, etc. objects are cheap
But calls on TS3Api objects (and TS3ApyAsync when used in conjunction with get) are expensive
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
So - always try to get the Client etc?
Roger Baumgartner
@rogermb
So instead of calling api.getClientInfo(e.getClientId()) multiple times, just assign it to a variable
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
Ok
The thing which is confusing me the most is this "CommandFuture"
Roger Baumgartner
@rogermb
Also, just as a general coding advice: try not to build pyramids if it's not necessary
image.png
image.png
Cha0s_B0y • Cha0sDev
@Cha0s_B0yYT_twitter
Ok :)
Roger Baumgartner
@rogermb
Especially if you have guard conditions like if (e.getInvokerId() != whoAmI), just flip it around:
if (e.getInvokerId() == whoAmI) return;

The thing which is confusing me the most is this "CommandFuture"

You probably shouldn't use the async API if you're not familiar with asynchronous programming

Just use the regular TS3Api