Quake3 Server Commander v0.2

[Gamall]

Peut-on l'utiliser même si le HUD est désactivé et donc le texte y compris? Parce que je voudrais voir le texte quand on parle mais pas le HUD.

Heu, c'est une question générale sur JKA plus qu'une question sur QCmd

Et la réponse est ... heu.... ben je sais pas en fait

Je n'ai jamais désactivé le HUD que pour prendre des screens, et là je souhaitais aussi faire disparaître le texte, que ce soient les annonces du serveur ou les dialogues des joueurs.

Je pense qu'il y a moyen de faire ça, mais je ne saurais pas te dire comment. Et là je n'ai pas JKA pour essayer.

Sinon, tu peux toujours installer un mod pour avoir un HUD plus discret, il y en a certainement un paquet. Et si tu n'en trouves pas qui te plaise, tu peux en créer un, ce n'est pas très compliqué si tu aimes tochop.

[Dakin Quelia]

D'accord!

[Gamall]

Here is the linux binary for QCmd 0.2b. (I'll make a Windows one next time I use my Windows box: edit: done and corrected minor win bug, so it's version 0.2c now ).

QCmd0.2c-bin.zip

(570.71 KiB) Downloaded 1438 times

I've been sitting on this one since last month, but didn't have time to upload it. I still don't have time to update the readme etc.

The changes in version 0.2b are mostly under the hood, but the -netport option could be used to solve problems with firewalled servers, such as Slaughter's.

Hope I didn't introduce any new bug

A more detailed changelog is here:

changelog from 0.2a to 0.2b:

Added more checks on the validity of the command line.

Changed the way the command-line is parsed so options can be passed after the +mode instruction. They could only be passed before in previous versions. This does not apply to +q mode, obviously, as everything after +q is seen as part as the query, to avoid the need to use quotes around queries with spaces.

added option -netport, which sets the local port QCmd uses.This is useful when you need to go through a proxy or firewall, and want to know which port to open.

added option -netporter (as in Netport Error Recovery), which defines the policy the program must follow when it fails to open the requested netport. The possible policies are Abort: display an error message and quit; Warn: display an error message and find another port, then continue as if nothing happened; Ignore: find another port and continue as if nothing happened, without informing the user.

added options -exsingle and -exmulti, which enforce the selected connection mode (or exchange mode) with the Quake3 server for everything but the messenger mode (which has its own sockets).

In SINGLE mode, QCmd expects only one datagram from the server in answer to its queries. This was the only mode available in previous versions. This is enough most of the time, but some queries, such as RCon Status, Dir, Quit etc, return several packets. Trouble is, there is no way to guess how many, nor which is last. Therefore, a socket timeout is inevitable. Which brings us to the MULTI mode.

In MULTI mode, QCmd reads every packet the server sends. This systematically introduces a delay, since the only way to know nothing else has been sent is to let the socket time out (I thought that strange too, but I'm not the only one to have run into that problem), but this allows multiline commands to be read correctly.

Each QCmd mode uses by default the exchange mode which is most suitable: that is: RCon mode uses MULTI, while every other mode uses SINGLE.

So basically, on linux, rcon status and such now work as expected:

Code: Select all

________________________________________________________________________________
# status
map: the_academy_v3
num score ping name            lastmsg address               qport rate
--- ----- ---- --------------- ------- --------------------- ----- -----
  0     0    0 ^3{<� ^1Bot Idi      50                   bot     0 16384
  1    13    0 ^3{<� ^1Bot B�t      50                   bot     0 16384
  8     0 CNCT  ^2# ^5QCmd MSG     3150    99.66.97.20:-29071 29506  3000
________________________________________________________________________________

***
WINDOWS USERS: The MULTI mode is buggy on Windows. So is timeout, by the way. So every mode uses SINGLE by default. You can always use these options to enforce MULTI mode, though.
***

This bug will need to be fixed before I release the source code

[slaughter]

[from Private Message: 11 Feb 2008 06:28 pm]

Hi,

My host opened the port 58789 on tcp and udp, I tested it and it's opened. This is the error I get when I send this command :
./qcmd -netport 58789 +q 63.211.110.185 27960 ****** status
Fatal error: exception Unix.Unix_error(30, "sendto", "")


The password is good, you can do watever you want on that server, I don't really mind

[Gamall]

Code: Select all

./qcmd -netport 58789 +q 63.211.110.185 27960 ****** status

The "rcon" is missing in this command


But that's not your problem. I can reproduce this behaviour on (and only on) my old shared hosting web server, so it clearly has to do with some security restrictions on those systems.

But it does not come directly from a port being blocked: version 0.2c detects that and displays an error message when it happens.

To make this short, I'm completely stumped there for now...

[Jc61990]

when i try to use rcon it hangs...

i made a batch file to automatically go to it but also even when directly typed from CMD i get a hang.

my batch looks like this

Code: Select all

@echo off
qcmd -nick JC -color 4 -timeout 3 +rcon 69.113.106.43 27080 ************     (i typed this directly to CMD also)

heres a screenshot

[Jc61990]

Just tryed on linux.... and im getting error....

ERROR: Socket timeout. No Reply received !



help please?

[Gamall]

Okay,

I've found the problem: Your server has an anti-rcon-flood: only one RCon query is answered to in a span of 0.5 seconds or so. When rcon mode fires, it requests both the game version and the gamename.

Problem is, when I wrote that, I had not yet written the code to extract cvars from status requests, so I used RCon queries instead. As a result, qcmd fires two rcon queries in a span of some milliseconds: therefore, on your server, the second one is ignored. I didn't notice it on my test servers, since they all have the rcon anti flood disabled.

So, on linux, you get an error message but it is actually alright: it just means that one query wasn't answered, but after that everything works.

Enters Windows: there is a bug on the windows version which causes any timeout to make the prog hang up indefinitely. So on windows, you never get into rcon mode, because the prog hang up before that.


FIX:

I can't easily fix the heart of the problem (the windows bug) since it is not in my own code.

But I will simply change the version and gamename queries to a getstatus and extract the info from there. This will avoid the timeout. And it's the way I should have written it in the first place.

So the next version should solve your problem.

PS:

qcmd -nick JC -color 4 -timeout 3 +rcon 69.113.106.43 27080 ************

nick and color are +msg options, not +rcon. And +msg doesn't work on JK2: it uses protocol 16 and not protocol 26 as JKA does... I'll add support for it one day...

[Gamall]

Here is version 0.2d, which seems to solve the problem:

try it and let me know

[Jc61990]

so your saying that on Jk2 i cant use the chat feature... damn, ive been looking for years now for an Rcon controller that has chat support. i know of 1 clan that has 1 when he talks thru it it says like

server: <One>: hi

and he can see what we type back

i thought maybe this was it idk ill have to do deeper research, but thanks for that update too

[Gamall]

damn, ive been looking for years now for an Rcon controller that has chat support. i know of 1 clan that has 1 when he talks thru it it says like server: <One>: hi and he can see what we type back

Well, I am sorry to say you won't find one, since this has nothing to do with RCon at all

What you describe is chatting using the server's console, which can be done either directly if you host it on your own computer, or through an interface some server hosts provide, which then feeds the queries to the process's standard input. Either way this assumes direct access to the server at some point.

edit: I could probably make a program which, once installed on a specific server, would allow that kind of things, but most server providers do not give their client enough access for this to work, so it would be kinda useless...

[Jc61990]

do u know how it can be done, and could it be done for JK2, cuz mainly i wanted it for my servers, and some other people. my servers are hosted on a dedicated box at which i have root access to

oh and i know for a fact that their server is rented. they actually get it for free so they only get FTP to it i think. the did it some how

[Gamall]

If you have root access, either direct or through SSH, it can be done. FTP access is not enough.

As for how, the idea is simple: having a program read the standard output of the server's process and transmit it to a client program on your machine. That way you would see what's happening in your server as though you were reading its console directly.

Assuming Linux and using a pipe, it is a straightforward socket programming exercice. Either find another coder willing to do it, or wait for me to have some free time for that (not until mid-summer. With luck).

[Gamall]

From a discussion on the same subject here too lengthy for filefront comments...

cool, now u just need to get it so u can see in game chat.

In game chat. That is my goal. We are working on an FTP file transfer that will allow you to download the log every few minutes. So far the idea is good, but the transfer sucks on large log files. The parsing is taking way to long. The alternative is to connect a fake client...but if I understand correctly, this has been attempted and does not work.

The alternative is to connect a fake client...but if I understand correctly, this has been attempted and does not work.

To my knowledge, it has *not* been attempted. That's the main problem. Getting a fake player in connecting state is fairly easy, but having it join the game is another story, and I gave that up when writing QCmd. But if someone had enough time on their hands to research the protocol past the 'handshake' bit, that definitely *would* work, and allow for a very elegant distant chat, which is what I originally wanted for QCmd's messenger mode.

The alternative approach I considered for that is simply sending the standard output of the server's process to the client: but that assumes running a service on the dedicated server, which most hosts do not allow.

I do not know much about the protocols between the server and the client...but is it possible to capture a game with a packet sniffer and then "read" what was sent and received?

on sniffing:

AFAIK this is possible only if you own a part of the network the packets transit on... which is fortunate, since if it was absolutely trivial to sniff packets right off the internet, we would all be in deep, deep manure. (polite version)

on the protocol:

Even supposing that you could, there would still be lots of work to do. Try sniffing on a local network (or just localhost), and you will see that all packets past the handshake bit look very ugly.

In fact, it would seem that each packet is encrypted with a key (I don't know which one, perhaps some derivative of qport, perhaps something else, which probably changes over time) and huffman compressed. (and even once decrypted and uncompressed, you'd still need to figure out what they mean...)

So basically, even if you could sniff everything, which you clearly can't, you would still have to implement a huge part of the quake3 protocol. And because of the key encryption I would wager you need to know much about a specific client to be able to decrypt their packets. So the quickest way to do that would be to connect your own client.

[Jc61990]

ok so i was in that server today, he was telling me about the program used, it was made by some 1 in that can works only on their server, said it was coded in c++ and has a Java GUI.

this is what it looks like ingame