Page 1 of 3

Bug Reports: Dedicated Server

Posted: 08 Jan 2012, 01:04
by nocturne
This is not a support thread. Any problems with the normal configuration or operation of a dedicated server should be stated in a separate thread.

Note: I figured it was time we started a Bug Report thread for the dedicated server... I'll pre-populate this list with whatever bugs I spot with a quick glance through this forum, but be sure to point out anything I've missed (along with a link to the original complaint/report if possible).

Please report any general bugs/inconsistencies regarding the Dedicated Server software here. Be sure to include as much relevant info as possible: ie. version of the dedicated server (should always be the latest, currently 2011-10-12), operating system (Windows, Debian, RHEL), steps taken to reproduce the bug, and any relevant logs and configs (with any logins, pw's, or other personal info removed of course).

Note: All confirmed bug reports will be forwarded (by me, personally) to the following Nadeo employees: XBX, Gouxim, Legor, Farfa, and Hylis.

Color Coding:
  • Red: Major problem, affecting the overall usability of the server
  • Black: Normal problem, affecting performance/stability without affecting normal operation
  • Grey: Minor problem, affecting neither performance nor normal operation -- basic minor annoyance
Existing Bugs:
  • Improper P2P cache file handling (ie, permissions, read-only files, no error handling, no size management). (not well documented, but we all know this problem) pre-TM2/MP
  • Excessive Memory Consumption of *nix Dedicated Server. < link , link > 2011-10-12
  • No method to limit/disable track-included mods. < link > pre-TM2/MP
  • Different handling of ScoreTables CustomUI than in TMF. < link , link > 2011-10-13
  • Mixed languages in RPC methods. < link > too old to put a date on..
  • Absolutely no documentation on how to run a Server.. no readme, no instructions, absolutely nothing for any that are new to TM. Not a bug... but seriously, guys.. get it together already!!
Fixed Bugs:
  • XMLRPC connection closed when sending data larger than 512kb. < link > 2011-11-03
    -- Fixed with Jan 17 2012 update, limit raised to 1024kb.
  • /noautoquit Command Line Parameter nonfunctional. < link > 2011-12-22
    -- Fixed with Jan 17 2012 update.

In addition, there have been a plethora of reports of the dedicated server locking up completely upon sync after a new map has been loaded (with or without mods), as well as many other general performance issues that clearly state the existence of some bugs; but the problems seem too intermittent to be able to reproduce on demand.

Note: Problems/Bugs relating to the game client should be posted in this thread (link), as well as taking the necessary effort to notify any relevant Nadeo employees (link).

Re: Bug Reports: Dedicated Server

Posted: 08 Jan 2012, 03:48
by fastforza
Old callbacks still exist.
Regardless of what the new API documentation says, the old callbacks still exist. This really confused me until I started logging each callback only to realise that the TrackMania prefixed callbacks were being fired. :?

To get the gist of what I mean, here's an example:
ManiaPlanet.BeginMatch is still/actually TrackMania.BeginRace.

To conclude:
- There is no new protocol version that I'm currently aware of. E.g. "GBXRemote 3".
- The problem may derive from the extremely old .NET XML-RPC library Flo developed in 2006. I have analysed the code and it's pretty much a bog-standard XML-RPC library. Much like the PHP IXR library used in popular PHP controllers.

Re: Bug Reports: Dedicated Server

Posted: 08 Jan 2012, 09:06
by nocturne
fastforza wrote:Old callbacks still exist.
Is that a bug report, or an observation..? In either case, I have to respond with the old adage: "that's not a bug, it's a feature!" :D

Though, both callback formats certainly shouldn't be fired, but.. In a previous discussion where I had complained that Nadeo seemed to change the callbacks/methods just for the hell of changing them, Xymph was kind enough to notify me that the original callback/method formatting was still indeed supported, though it's support was specifically defined by the method SetAPIVersion (or something along those lines.. I'm too lazy to dig through my downloads bin to dig up the current ListMethods.html file (provided Nadeo ever bothered updating it) and it seems Xymph has been a bit lazy in listing the updated version on his TM2 portal page (my usual go-to source)).

I imagine that this xml-rpc method specifically defines which callback/method formatting to use, and lacking any preferred format being defined, the dedicated server will just throw both versions' callback formattings (as well as respond to methods in either format).

I wouldn't exactly call it a bug.. you wouldn't get to any place where the callback formatting would be of any concern, unless you had a hand in developing a server controller -- in which case you would seem to have all the tools available to you to avoid such wasteful multiple callbacks.

Edit: I guess I should note.. you don't need to color code your bug listing.. When a bug is annoying enough, it'd be rated in deep red ink regardless of from where you are standing; so I'll be personally rating each bug report (provided it's a bug), using my best attempt at objective consideration.

Re: Bug Reports: Dedicated Server

Posted: 08 Jan 2012, 09:23
by fastforza
I see. Thanks for the explanation! :thumbsup:
Edit: I guess I should note.. you don't need to color code your bug listing.
It seemed appropriate. :P

Re: Bug Reports: Dedicated Server

Posted: 08 Jan 2012, 10:30
by Xymph
nocturne wrote:
fastforza wrote:Old callbacks still exist.
Is that a bug report, or an observation..? In either case, I have to respond with the old adage: "that's not a bug, it's a feature!" :D

Though, both callback formats certainly shouldn't be fired, but.. In a previous discussion where I had complained that Nadeo seemed to change the callbacks/methods just for the hell of changing them, Xymph was kind enough to notify me that the original callback/method formatting was still indeed supported, though it's support was specifically defined by the method SetAPIVersion
http://forum.maniaplanet.com/viewtopic. ... ion#p81018
What's said about methods there indeed also applies to the callback names, so if fastforza didn't change the API version he'll indeed get the old callbacks.
nocturne wrote:(or something along those lines.. I'm too lazy to dig through my downloads bin to dig up the current ListMethods.html file (provided Nadeo ever bothered updating it) and it seems Xymph has been a bit lazy in listing the updated version on his TM2 portal page (my usual go-to source)).
Me, lazy? Never! Overworked and perennially short on spare time? Sure. ;)
In reality, I've been migrating most detailed info from my hub pages to XAseco.org, leaving only pointers on the hubs.
For the callbacks I went through the extra effort :P of listing both sets: http://server.xaseco.org/callbacks2.php
nocturne wrote:I imagine that this xml-rpc method specifically defines which callback/method formatting to use, and lacking any preferred format being defined, the dedicated server will just throw both versions' callback formattings (as well as respond to methods in either format).
Nah, with no API version defined, the default original callback/method names are issued/accepted, not both.

Re: Bug Reports: Dedicated Server

Posted: 08 Jan 2012, 10:52
by nocturne
Just in time.. hehe :clap:

Thanks for the clarification.. I am indeed admittedly (and rather proudly, hehe) lazy, though, and hadn't really noticed the site transition. :thumbsup:

Re: Bug Reports: Dedicated Server

Posted: 08 Jan 2012, 12:22
by w1lla
After doing some tests with my linux server i came to the following conclusion:

Code: Select all

1516:   ./ManiaPlanetServer /internet /login= /password= /game_settings=MatchSettings/CanyonA.txt /dedicated_cfg=dedicated_cfg.txt /title=TMCanyon
Address   Kbytes Mode  Offset           Device    Mapping
08048000   17840 r-x-- 0000000000000000 0fd:00000 ManiaPlanetServer
091b4000     440 rw--- 000000000116c000 0fd:00000 ManiaPlanetServer
09222000     364 rw--- 0000000009222000 000:00000   [ anon ]
0a9f6000  187908 rw--- 000000000a9f6000 000:00000   [ anon ]
b1e7f000    2352 rw--- 00000000b1e7f000 000:00000   [ anon ]
b20cb000   97024 r---- 0000000000000000 0fd:00000 dedicated.pak
b7f8b000     168 r---- 0000000000000000 0fd:00000 resource.pak
b7fb5000     300 rw--- 00000000b7fb5000 000:00000   [ anon ]
bf9d8000      84 rw--- 00007ffffffe9000 000:00000   [ stack ]
mapped: 306480K    writeable/private: 191448K    shared: 0K
to see it on your own servers:

go to console: be a root user and type first ps aux to find the PID of maniaplanet server.
Use The pid in the following command:
pmap -d PID
It will print out a same code as above with the full commandline aswell as the kilobytes used aswell as library.

In Fact the memory used is 191488K which is 191 MB :P

The main thing that uses memory is a [anon] which is simply a Threading thing as explained here

Documentation used:

http://virtualthreads.blogspot.com/2006 ... linux.html


_________________________________________________________________________________________________

Another Issue:

- Add on hitting CP's not the OLD trackmania 1 and trackmania united/forever times of 0.18.84, but do the following:

- 0.18.84x in that way players can see what difference they really made. Adjust this also to the player Score on the ScoreRankings board aswell as the Custom_UI for Checkpoints aswell.

- Total points recieved during RoundsMode should be properly aligned.
http://tmrankings.com/mlepp/roundsposit ... eboard.JPG
http://forum.maniaplanet.com/viewtopic. ... ode#p43171

- A bug in Ranking during Rounds is not completely correct: Its still in after B2.

Some don't have access to beta forum so i qouted the following message from the following url
ohei2 wrote:Today I was playing in rounds mode for the first time and stumbled about an oddity (bug?) in the ranking information. We were just three, thus it was easy to compare what the game said to what really happened.

The little text when you cross the finish line often had the ranking wrong. When I was first it said I am second and when I was second it said I am first.

Image

Image

Both images are from the same race. In the first you see I am "2nd)" though I am first as you can see in the little window to the right in the second image.

This happened often, but not always, thus I really have no clue under which condition(s) this might occur.
- Give a general Warning if a SuperAdmin connects to the server with Basic.php or any other ServerController and tell them that the Cache is almost full or make a callback for it.
Sometimes a server locksup and then everybody is kicked due to a full cache of the server and a message of Corrupted login occurs.




A General Note for us Server Nerds (http://wiki.maniaplanet.com/en/Community_articles)

Re: Bug Reports: Dedicated Server

Posted: 11 Jan 2012, 14:51
by 4lturbo
There is a bug in lap mode, if you are first during the race, you never know the gap between others players and you (bottom right) and if you are not first you only see players in front of you, never see the players behind you.

Re: Bug Reports: Dedicated Server

Posted: 15 Jan 2012, 14:50
by fastforza
Methods documentation sates that GetPlayerInfo returns the same struct as GetPlayerList, but it clearly doesn't. :? I bet Xymph will know! :P

Code: Select all

struct GetPlayerInfo
{
    Login
    NickName
    PlayerId
    TeamId
    SpectatorStatus
    LadderRanking
    Flags
}

Code: Select all

struct GetPlayerList[]
{
    Login
    NickName
    PlayerId
    TeamId
    IsSpectator
    IsInOfficialMode
    LadderRanking
}
Using the latest API version.

Re: Bug Reports: Dedicated Server

Posted: 15 Jan 2012, 22:35
by Xymph
fastforza wrote:Methods documentation sates that GetPlayerInfo returns the same struct as GetPlayerList, but it clearly doesn't.
Ok, I'll bite. :) You need to use the same compatibility parameter in both method calls, then the structs are the same.