gaoesa

This discussion at Omni-bot forum might be related http://www.omni-bot.com/forum/showthread.php?3159-Medic-gives-medpacks-instead-of-reviving-with-needle In general, I haven't noticed this effect or know what might be causing it. EDIT: Another thread about it at Omni-bot forum http://www.omni-bot.com/forum/showthread.php?3167-0-82-Beta-Revive-Goal

Please read what the server log says. There is a printed line for every block it executes and the player count it is using. However, the last g_excludedMaps is overriding every g_excludedMaps in the previous blocks. Remember that the last one executed is the one that is used. They don't add to each others.

That is indeed intializing etmain. Finding the silent-0.6.3.pk3 is also missing from the log. That should be just above the line /usr/local/games/enemy-territory/silent The log should say this. The server silent folder must have both qagame.mp.i386.so and silent-0.6.3.pk3 for the mod to load.

It sounds like at first it didn't download the silent pk3. Second problem it downloaded it but the game couldn't extract the binaries before you did run the client as an admin. The third issue: Happens because the silent cgame is not loaded. Is this on localhost? Make sure you run both client and the server as admin. Make sure you have the qagame in the silent folder of the server. What is the command you use to start the server?

Make sure you have the correct silent-0.6.3.pk3 file in the server. Also, you have sv_pure in your config set to 0. This should be set to 1, unless you're using the server for map making or something similar.

It should be. You should confirm the value is set using rcon.

Enable flags 16 and 32 in g_classWeapons http://mygamingtalk.com/wiki/index.php/Silent_Mod_Server_Cvar#g_classWeapons to go around the bug. Ensure that these flags are set with rcon. The reason why this happens is that when the player clicks the team button in the limbo panel, the default class is soldier and if the bottom weapon in the expanding weapon box is not available for selecting, this error will close the client. Note that it happens exactly when clicking the team button.

Shoutcaster are not affected by the inactivity timer. The spec_invite allows following the team regardless of spec lock.

The next [players] will automatically close the previous open block. If there are parsing errors, those are printed into the server log.

Bots don't use limbo panel and don't use the team command either. You need to check if the player entity is a bot and exclude it if that is the case.

It doesn't work in the server cfg. It work only in the mapconfigs. Check the g_playerCounting cvar too. Maybe the map name had a typo.

I don't know if it will be possible. You can test intercepting "team" command from client and manipulating sess.shoutcaster. To make shoutcaster: sess.shoutcaster to value 1 sess.spec_invite to value 3 To remove shoutcaster: sess.shoutcaster to value 0 if the player is not referee (sess.referee is 0), sess.spec_invite to value 0 The reason why manipulating directly is so that the change would take effect before the actual client team command is handled. The team command is sent from the client only when they press ok button from the limbo panel or use it directly from the console. You probably don't need to call http://mygamingtalk.com/wiki/index.php/Silent_Lua#ClientUserinfoChanged after manipulating the status as the team command execution will do it. But otherwise this is needed.

If you mean is there possibility of getting that message erroneously. No there is not with unmodified silent client. Even if the player would intentionally spoof to cause it, he is still hacking the game. This is a very old feature existing in the mod for several versions even though the message you read is new.

Using the older example as base local timestamp = os.date("%Y-%m-%d %H:%M:%S") local logLine = timestamp.." Player "..name.." silEnT GUID "..guid.." executed command: "..command.."\n"

This is one method of doing it http://mygamingtalk.com/wiki/index.php/Silent_Mod_Server_Cvar#g_mapConfigs

Fixed. In future versions the kick length is 0 seconds and temp ban is only through shrubbot.

In shrubbot.cfg [command] command = spec exec = putteam [i] s; specplayer [i] "[1?]" desc = spec any player syntax = [name] levels = 0 1 2 3 4 5 In Lua: function et_ConsoleCommand(command) if et.trap_Argv(0) == "specplayer" then if et.trap_Argc() == 3 then local clientNum = et.trap_Argv(1) local targetClientNum = et.ClientNumberFromString(et.trap_Argv(2)) et.gentity_set(clientNum, "sess.spectatorState", 2) et.gentity_set(clientNum, "sess.spectatorClient", targetClientNum) end return 1 end return 0 end Notice that the Lua hook is now ConsoleCommand and not ClientCommand.

First, make sure your server has the proper silent-0.6.3.pk3 file. Don't change the contents of that pk3 file in any way.

Yes. You can intercept the "players" command with et_ClientCommand Lua hook. For example: function et_ClientCommand(clientNum, command) command = command:lower() if command == "players" then local name = et.gentity_get(clientNum, "pers.netname") local guid = et.gentity_get(clientNum, "sess.guid") local logLine = "Player "..name.." silEnT GUID "..guid.." executed command: "..command.."\n" -- log to the server log et.G_LogPrint(logLine) -- log to a separate file fd, len = et.trap_FS_FOpenFile("clientcommands.log", et.FS_APPEND) et.trap_FS_Write(logLine, string.len(logLine), fd) et.trap_FS_FCloseFile(fd) end return 0 end

The rcon command is not an actual client command. If you want to log them, unfortunately, it must be done in the server engine or in the firewall. Luckily, the rcon command is sent as plain text inside the packets. I don't know what kind of options current server engine modifications can offer for this type of security.

Put the pak0 back.

Implemented in the requested way by extending shrubbot flags 6 and 8 to the !mute command.

http://mygamingtalk.com/forums/topic/2586-running-silentmod-063-with-et300-and-sv-protocolcheck-0/

This is a bug. Thanks for reporting. Will be fixed in the next version. The same bug affects several other announcements too.

g_maxIgnoresPerMap added in 0.7.0. This server cvar is the maximum number of times one player can ignore another player during one map. Default value is 2.