Unofficial Kaillera Server based on original binary

[TRAC_]

Summary of Commands Available to Game Lobby Creators/Hosts in Unofficial Kaillera Server (as of 0.917)

Note: most commands announce the effect of their usage to all users in the game.

/limit # - version added: 0.913 - usage: /limit 4
Sets user limit for game lobby. User limit defaults to 8, and can not be changed to a number less than the number of users currently in the game, nor can it be changed to a number greater than the user limit of the server, or 32, whichever is less. User limits are enforced.

/swap #### - version added: 0.915 - usage: /swap 01 usage: /swap 20663
Remaps user inputs on the fly, while game is playing. User inputs are reset on game start. Only the first 8 user inputs can be remapped, or used for remapping. Duplicates are allowed. The numbers supplied are the original player numbers, and are not affected by previous '/swap' commands. Using a '0' for a player's input means 'don't change from previous mapping'. The first example '/swap 01' does not change the input currently used for player 1, but uses player 1's input for player 2. The second example '/swap 20663' uses player 2's input for player 1, player 6's input for 3 and 4, and player 3's input for 5.

/swapreset - version added: 0.916 - usage: /swapreset
This command resets all input mappings in the game to the state they would be in if no '/swap' commands had ever been issued.

/ban # - version added: 0.916 - usage: /ban 5
This command kicks and bans the specified user number from the game, permanently. Games have no bans when they are first created. The example would kick and ban user 5 (the 5th least recent to join, or 5th in the standard client's game user list, from the bottom).

/banreset - version added: 0.916 - usage: /banreset
This command clears all bans in the game, whether automatic or requested.

/start - version added: 0.917 - usage: /start
This command starts the game, the same as the start button in the default client. This is necessary so that game hosts who have 'inherited' their power from a previous host leaving the game can still start the game, despite their client not otherwise having an interface for it.

/kick # - version added: 0.917 - usage: /kick 5
This command kicks the the specified user number from the game, the same as the kick button in the default client. This is necessary so that game hosts who have 'inherited' their power from a previous host leaving the game can still kick users from the game, despite their client not otherwise having an interface for it. The example would kick user 5 (the 5th least recent to join, or 5th in the standard client's game user list, from the bottom).

[TRAC_]

Version 0.918 of the Unofficial Kaillera Server is now available at the usual location (http://www.emuunlim.com/sneese/).

The only change is a fix for a bug which prevented connect types other than good from working properly (or even being properly acknowledged on login).

[Athelstone]

Excellent job. I just really wish we could get the word out on this (or get it added to the main kaillera page. Looks like that's not going to happen though until Christopher pays attention to kaillera again).

[danpyung]

I have test it, it works great...thx at your effort..TRAC_

but, when I join server, my connection type "good " is viewed as
"low" in web access..(http access..)

and if I joined with "Lan", then it is stated as "good"...

would u fix it?

[TRAC_]

Thanks a lot for pointing that problem out. I just got it fixed in my work tree, and will be fixed in the upcoming 0.919 release.

The next release also changes how the input remapping handles when a user drops from the game (users set to specific inputs keep their inputs when a lower user number leaves - if inputs are set to 134 and user 2 drops, inputs set to 3+ bump down and you get 123). I'm tempted to extend that to cases where input remapping is not in use, but so far I've decided not to, in the interest of compatibility with the current interface and user familiarity.

Another change that is likely to be included is a new '/lagstat' command, which reports a few measurements of total user lag (measured by excessive delay in response times) since the last time the current game was started. However, in the interest of reducing conflict between users based on this feature, I am wanting to get it more thoroughly tested before release.

[combo666]

well I tested and work fine

any plans to add some admin comands in future?

Very nice work trac!

[Kuroi]

Hello TRAC,

there is one problem I got with servers running unofficial kaillera server releases (let's say gametronik running 0.918, am being european) :

when I connect to a server running the enhanced version of kaillera server and with about 25 people or more already connected to it, I obtain the user listing screen with the games currently running but I can't do anything : no chat messages or even my own join message (the screen remains blank), my nick doesn't appear on the list, can't see users when i join games, etc..

It works fine when there is less than 25 people connected.

I believe it's caused by a personnal configuration (adsl modem or else), but it isn't doing that with servers running the original kaillera server. One thing I can think of, is that the server sends user list and game list as one packet, and when it's too big, the information doesn't arrive correctly and the client is not connected properly (say for example that my modem crops all packets that are bigger than a certain size).

Is it possible to change the way user list and game list are sent ? For example go back to the same method used by the original kaillera server, cause I think i'm not the only one having this problem (let's say we're at least 2 )

Thanks, and good continuation on your initiative to improve kaillera netplay !

[Night]

Hi all, hi TRAC,

I've got exactly the same problem as Kuroi, and i don't know why
I was able to connect to gametronik when it was the old kaillera, and now it's no more possible with this version.
Please help us , we want to enjoy gaming on your sweet kaillera version too.
Is it possible that our problem come from the configuration of the Connect_AveragePings ?

Or is it because i'm behind a router? (but i've configurated it and normally it would work)

Thanks.

[TRAC_]

when I connect to a server running the enhanced version of kaillera server and with about 25 people or more already connected to it, I obtain the user listing screen with the games currently running but I can't do anything : no chat messages or even my own join message (the screen remains blank), my nick doesn't appear on the list, can't see users when i join games, etc..

It works fine when there is less than 25 people connected.

I've received the same problem on servers that do not run UOKS, so I do not think it is a problem in the server software, at least not the server software alone.

I believe it's caused by a personnal configuration (adsl modem or else), but it isn't doing that with servers running the original kaillera server. One thing I can think of, is that the server sends user list and game list as one packet, and when it's too big, the information doesn't arrive correctly and the client is not connected properly (say for example that my modem crops all packets that are bigger than a certain size).

That is an interesting theory, though at the moment I can't do anything to prove or disprove it.

Is it possible to change the way user list and game list are sent ? For example go back to the same method used by the original kaillera server, cause I think i'm not the only one having this problem (let's say we're at least 2 )

I hate to have to inform you of this, but UOKS should use the exact same method for transmission of said lists as the original server, as it was obtained via decompilation of the original server. As for changing the way they are sent, the client would also need to be changed so that it could know how to receive them. Until the client is decompiled, that is not a practical option.

Is it possible that our problem come from the configuration of the Connect_AveragePings ?

Not likely, since that option is not enabled by default.

[Kuroi]

Hi and thanks for your answer,

well so the cause of the problem may not be what I pointed to if you're using the exact same method as the old server, but there is one thing for sure, this problem wasn't occuring with the old one (at least for me).

We could probably assume that this is a problem at the connection time, so what have we got that differs from the original server-client communication is the question ? Is the UOKS requesting and sending the exact same information to the client as the OKS ? Things like game listing now probably differs a bit since you can have more than 2 as the maximum # of players, and maybe some other things. And since the problem is only occuring when there is a certain number of players already connected, probably something get to oversized compared to the old communication process.

Sorry I really would like to help but it's hard with no source code nor testing possibilities, so i'm just guessing and proposing things.. Well hope you will be able to figure this out !!

[Night]

Hi, thank you to be aware about our problem.

i remember one thing, it's that i had the problem on some servers that runs OKS. But it happens only when the MOTD contains too many lines.

Please take a look on these screenshots.

- It's what happens on Gametronik (it runs UOKS)
http://membres.lycos.fr/adriensc/autres/kaillera/kaillera.jpg

- And here what happens on ArcadeHits (it runs OKS)
Some times the MOTD doesn't appear.
http://membres.lycos.fr/adriensc/autres/kaillera/kai1.jpg

Or appears partially.
http://membres.lycos.fr/adriensc/autres/kaillera/kai2.jpg

And after many tries, all the MOTD appears and i'm connected.
http://membres.lycos.fr/adriensc/autres/kaillera/kai3.jpg

So, is it possible it is the same problem on UOKS ? But i've never had the MOTD even partially on Gametronik.

Thank you again.

[Kuroi]

Oh it never happened to me with servers running OKS, so the problem was always there as said TRAC.

Then it could be the way motd is sent by the server, the message is sent and "sometimes" (when ?) not received correctly. Plus this could have to do with routers as I have a modem that functions as a router too.

What bothers me is the fact that it seems to appear randomly in the case of Night. Could that come from the rate the lines are sent ? Maybe adding a delay would help ? or the motd is maybe messing with the ping requests ? (was for example the Connect_PingCount always defaulted to 4 ?)

[Moosehead]

Look at my other thread on this subject:

viewtopic.php?t=4494

[TRAC_]

I have found a minor issue in the UOKS server (flaw from decompile, likely) which could cause it to take slightly longer to assemble the server status 'message' for a user that is logging in than it should; however, the form and contents of the packet is the same, and I doubt that the time difference is significant. Still, it will be fixed in the upcoming 0.919 release.

[Note - A 'message' is the portion of the Kaillera packets that contain individual data/command blocks. It appears both I and Moosehead use this nomenclature, hopefully this will minimize related confusion.]

The connection process itself should be the same as that of the official server (though with a little more tolerance to lost pings); however, the extra 'messages' sent by the server to inform the client of user limits in games (which the client SHOULD be able to derive from the initial server status message, but doesn't) likely cause problems in login if the packets containing that message are lost.

This can also happen on non-UOKS servers, but perhaps is less likely due to less of an initial packet flood on connect. I do not know if a busy server or one with lots of MotD lines (as both would equate to the same conditions) is more prone to it.

The MotD is sent AFTER all initial ping/pong messages have been negotiated and user login has been accepted, so it can't interfere with that.

As far as the theory about the server status message being excessively large, this probably is a valid concern. I would estimate that on average, each user adds around 24 bytes to the status packet, and each game around 88. For 20 users and 8 games, this is around 1.1k; 40 users and 16 games, this is 2.3k. One could easily blame this on inefficiencies in the Kaillera protocol, but blame doesn't solve the problem.

One could reduce the size of the server status message, however basic attempts to do so would worsen the problem of the packet flood.


Overall, for best results while we have no new client software, ALL Kaillera servers, regardless of server software, should limit themselves to an absolute max of 40 users, with 20-32 being more reasonable.

[isamu]

O.K. I'm going to try this now. I have two quick questions though....

1)I have not started my own kaillera server in ages and literally forgot how to do it. Can anyone tell me step by step how to start my own server? I'm running Windows XP and a Pentium 4 3.6Ghz machine and posting from a Internet WiFi hotspot.

2)I noticed within the download there are two exe files...kaillerasrv-ppro.exe and kaillerasrv.exe. What is the difference between the two and which one should I be using?