gaoesa

That is the line which tells the problem. Please make sure you have the file named autopromotion.lua in your silent folder.

Does the log say anything about the Lua script when the map starts? Also, do remember to set the lua_allowedModules to empty unless you have the correct checksums for the script.

The immediate help in your case would be to make g_warmup longer so the players already playing would have time to connect before the warmup ends. Though I must say I'm a little surprised the sil_guid is not in the engine stored userinfo after map change. I would actualy still like to see more log entrys for the map changes where the existing players don't fully connect before the warmup ends. EDIT: I remember when doing the cg_ident one of the problems was that the server remembered the old cg_ident from the player even without the client being reconnected. Are you sure I have not misunderstood what you were saying about the bug? This does happen to players who have already played on the previous map? EDIT2: Sorry, I indeed misunderstood this. Yes. This bug is known and it of course needs to be resolved somehow. However, it does not concerns players already playing on the server but only those unfortunate ones that happen to connect just when the warmup is ending and they don't have enough time to send their userinfo before the ClientBegin is forced on them. After quick testing the earlier proposition I made about the engine side fix, it is not that simple. It seems to generate a new type of bug where player never enters the world in the same conditions of connecting just at the end of the warmup. Nevertheless, there is a bug in this matter.

I have found the information I was looking for from the logs. This problem is very problematic because it is important the mod doesn't allow players without proper silEnT GUID to play. However, the SV_MapRestart_f in the engine side does force the ClientBegin in the mod side to execute for everyone after the warmup ends. This falsely sets the players to the fully connected state on the server. I would rather look at: // connect and begin all the clients for ( i = 0 ; i < sv_maxclients->integer ; i++ ) { client = &svs.clients[i]; // send the new gamestate to all connected clients if ( client->state < CS_CONNECTED ) { continue; } if ( client->netchan.remoteAddress.type == NA_BOT ) { if ( SV_GameIsSinglePlayer() || SV_GameIsCoop() ) { continue; // dont carry across bots in single player } isBot = qtrue; } else { isBot = qfalse; } // add the map_restart command SV_AddServerCommand( client, "map_restart\n" ); // connect the client again, without the firstTime flag denied = VM_ExplicitArgPtr( gvm, VM_Call( gvm, GAME_CLIENT_CONNECT, i, qfalse, isBot ) ); if ( denied ) { // this generally shouldn't happen, because the client // was connected before the level change SV_DropClient( client, denied ); if ( ( !SV_GameIsSinglePlayer() ) || ( !isBot ) ) { Com_Printf( "SV_MapRestart_f(%d): dropped client %i - denied!\n", delay, i ); // bk010125 } continue; } client->state = CS_ACTIVE; SV_ClientEnterWorld( client, &client->lastUsercmd ); } To check if the player was CS_ACTIVE before the new GAME_CLIENT_CONNECT and only in that case make the SV_ClientEnterWorld call. This is some thoughts for the case if there are engine programmers out there who can test and possibly apply this kind of change. I do think this might have something to do with the shuffle bug as well. The bug when connecting client gets shuffled and for some reason some teammate uniforms can get mixed with the enemy uniforms for him.

Could you pm me part of a log file for map change to warmup end and some player(s) getting dropped.

That is because it is not binary hack. EDIT: This feature is not an Anti Cheat. I do recommend using only the report part.

When the players silent guid changes it means that he has his old PB GUID but the silent GUID changed. The player was rebound to the old record using the PB GUID and the silent guid was updated.

I think I have found the reason for this. The engine is calling the mod side ClientBegin after warmup even to the players who have not yet been properly reconnected. I don't have the means to reproduce this because even on my network test server I connect before the warmup ends. Even when setting g_warmup to 0. There seems to be no way to completely prevent the warmup or I didn't find it.

It usually happens when players are connect to the server just when the server restarts after warmup. How long is the warmup period on your server? EDIT: Or did you mean only new players connecting to the server gets kicked? Because I checked and couldn't see a reason for this to happen for old players. This is unfortunate but, it happens because the mod ensures all the players have a silEnT GUID before they enter the game and if they don't have, they get kicked. In the 0.5.1 it was not checked. IT seemed that it happens only for the exact moment when the warmup ends. If clients connect to the game(spectators) before the warmup ends, they have no problems.

That is not possible in current version. We can consider it to the next versions.

I think what you are referring is a service from TrackBase http://forum.trackba...w-rating-method . You can get it if you have private slot on your server that is reserved for the trackbase bot called TSP. You need to request it at the trackbase forums. Sorry I couldn't find the info from the FAQ page or from the tutorials on that site for direct linking. Also, Paul from TrackBase has authored an ET server engine version called ET 300 which has some features inbuilt for tracking players and their statistics. EDIT: PS. Forgot to answer that silEnT mod doesn't itself do anything for these ratings at the tracbase website and there are no specific settings for this.

Execing default.cfg mapconfig for 21 players. * Execing commands for player amount between 20 - 64. * Execed total of 22 commands from the config file. Execing supply_pro.cfg mapconfig for 21 players. * Config file "mapconfigs/supply_pro.cfg" was not found. This is the type of log entrys to look for. I searched for parse error messages and I didn't find those. It seemed in the log that there were very few times when the 20 players were exceeded. As for the error of having always the same g_excludedMaps it might suggest you have another set g_excludedMaps somewhere after the blocks. If that is the case, it will overrule the g_excludedMaps inside the blocks.

Even if you can hack the level.db in Jaymod, it is undocumented and I didn't know this or bothered looking when I had the Jaymod server. This resulted that I had to use lot of cursing for the Jaymod system while expanding the levels in the middle. As I said, we can add some commands that help making quick fixes or checks while playing on the server, but we will not move to the system Jaymod uses because of it's harder usability. Do note that expanding the levels in silEnT only takes one copy paste block with edits, changing the level numbers of the higher levels, looking up few privilege flags and doing !readconfig or waiting for the map to change. All this while the server is running. This takes only fraction of the time it takes to use Jaymod style level editing commands. Also, the initial setup is faster to do this way. I personally don't believe anyone configures their first install of any mod within 30 minutes to the fully usable state and debates of whether it takes or should take 1 or 2 hours are pointless. There are many advantages we get from the database system we have now.

Check from logs what it says when it is execing the config files. This will ensure the block you want is executed or if not, you will see what is the player amount it is using. About the goldrush, make sure you don't have some custom version on the votable list and that there are no typos in the map names. Just tomakesure, you did add these blocks into the default.cfg in the g_mapConfigs directory?

Certainly if the client binary is not recognized it does not mean the player would be cheating. For example ET Legacy nightly builds would be the case of that. However, it does make it harder for someone to make completely different build with whatever features they want into the game. Afterall, the multiplayer game should be played with features that are considered equal with what other players have. With that said, for example our server doesn't enforce the binaries. But they are reported to the g_cheatLog and also to the admin chat. There are those players sometimes, not too often though. What I would suggest if you are unsure, to enable just the reporting and see the situation first hand. Furthermore, if some player is dropped because of the binary, it is logged into the g_cheatLog regardless of other settings.

I think I have found the error. You tried to set the level higher then 32, which resulted the error. This is indeed a bug because the levels are not required to go from 0 to 32.

Did you have the level you tried to set loaded from the shrubbot.cfg? Can you give more details so we can try to reproduce the error please.

I personally really disliked the online commands to edit user levels. When my server had Jaymod. Also, the flags are easy and a nice way to group the commands for the level. This is of course subjective. But for me it is far easier to edit config file then using online commands with at least 4 parameters. For each command and privilege for each userlevel. I had to expand the levels few times and that was a pain to do. Maybe there can be some type of commads to help setting up specific commands to a userlevel or check them. But moving completely from config file to online commands is not a possibility because of it's lesser usability and transferability between servers. The rcon problem you had may have been a bug perhaps or maybe I didn't understand what you said. Rcon is never restricted.

The teams wont get locked. But you can also put only one of them to 0 if you will.

You can check thestored values from the server.dat in the silent folder. It has 4 rows and the last 2 rows are the stored player counts. Also, check the log, it does verbosely explain which blocks it execs or parse errors from the block markups.

If you set g_teamForceBalance or g_unevenTeamDiff to 0 it will not be displayed anymore.

There shouldn't be anything in the cvars that require specific attention when updating. Just remember to backup data first. Also, remember to upload the qagame .so or .dll aswell.

Forcing the clients allow downloads might not work. The forced cvars are supposed to last only for the map. Apart from the latched cvars which may cause some problems after disconnecting. However, you can test it of course.

Please ask all questions at the support part of the silEnT forum.

Oops. I was late with editing, please look at my previous post I edited an example there.