gaoesa

The gib, lol, pip and pop no longer do it to everyone. The target must be specified. !giba works as before.

You read the numbers from that line like this:
client number,
rounds in session, (for stopwatch games)
weaponmask, (this is a bitmask of the weapons that are presented in the string)
n * [hits, attempts, kills, deaths, headshots], (the n is defined in the weapon mask and the weapons are in the smallest set bit to the highest set bit order)
damage given,
damage received,
team damage given,
team damage received,
skillpointmask, (this is a bitmask of the skills that are presented in the string)
n * skillpoints
 
The weapon mask values, I've put the hexadecimal bitmask for single weapon as a comment:

WS_KNIFE, // 0x01 WS_LUGER, // 0x02 WS_COLT, // 0x04 WS_MP40, // 0x08 WS_THOMPSON, // 0x10 WS_STEN, // 0x20 WS_FG42, // 0x40 -- Also includes WS_BAR (allies version of fg42) WS_PANZERFAUST, // 0x80 WS_FLAMETHROWER, // 0x100 WS_GRENADE, // 0x200 -- Includes axis and allies grenade types WS_MORTAR, // 0x400 WS_DYNAMITE, // 0x800 WS_AIRSTRIKE, // 0x1000 -- Lt. smoke grenade attack WS_ARTILLERY, // 0x2000 -- Lt. binocular attack WS_SYRINGE, // 0x4000 -- Medic syringe uses/successes WS_SMOKE, // 0x8000 WS_SATCHEL, // 0x10000 WS_GRENADELAUNCHER, // 0x20000 WS_LANDMINE, // 0x40000 WS_MG42, // 0x80000 WS_GARAND, // 0x100000 // Gordon: (carbine and garand) WS_K43, // 0x200000 // Gordon: (kar98 and k43) WS_PPSH, // 0x400000 WS_TRIPMINE, // 0x800000
 
The above is read so that the if the value is for example 12 , then there is weapon statistics for colt and mp40. First colt, then mp40.
 
The skill bit mask values are:

SK_BATTLE_SENSE, // 0x01 SK_EXPLOSIVES_AND_CONSTRUCTION, // 0x02 SK_FIRST_AID, // 0x04 SK_SIGNALS, // 0x08 SK_LIGHT_WEAPONS, // 0x10 SK_HEAVY_WEAPONS, // 0x20 SK_MILITARY_INTELLIGENCE_AND_SCOPED_WEAPONS, // 0x40
 
This works exactly the same way as the weapon mask.

I don't understand how an empty/only bots server can have a huge popularity at the same time. So this sounds like a contradiction. However, I have seen this discussion before and I hope it will not be started here. At least not at the silEnT subforum. Like Dragon said, there is nothing we can do to the fake information in the masterlist. Putting large numbers of bots to the spectators is of course something we can address. Sorry, no news of this yet. This is not among the highest priority tasks because there are so many other ways for adding the fake information to the list.

Stabbing under water is realistic. So no backing up.
 
It is irrelevant how many admins you have pissed. But I'm sure it is a skill.
 
Throwing knives or grenades from under water to above surface is the big issue. Beginners typically can't understand the physics engine would allow this and have hard time finding the opponent. There is no skill involved in there. It is just a bug to exploit. There is no distinction between throwing under water and above water in the physics engine. That is a problem and underwater throws will not be enabled at all since they can't be constrained to under water. Even if they would be fun in an arcade way.
 
And the issue is about realism and preventing exploiting weird behaviour. There is no contradiction here.

Optional aliases database is implemented in the next version with new commands !aliases, !aliassearch and option for !userinfo to show also the aliases. New server cvar g_dbMaxAliases.
 
Alias information holds: first time seen, last time seen, the time the alias has been in actual use.

The mute information is shown in the !finger output in the next version.

Optional aliases database is implemented in the next version with new commands !aliases, !aliassearch and option for !userinfo to show also the aliases. New server cvar g_dbMaxAliases.
 
Alias information holds: first time seen, last time seen, the time the alias has been in actual use.

Changing the weapon definitions freely would create very random game experiences. Especially the grenade time is something that should never be changed because no one would know how to use it with random ticks. There would be a huge load of bug reports to our tracker It is not changeable in any mod and it is unlikely that it will ever be.
 
http://mygamingtalk.com/forums/topic/58-feature-request/

Changing the weapon definitions freely would create very random game experiences. Especially the grenade time is something that should never be changed because no one would know how to use it with random ticks. There would be a huge load of bug reports to our tracker It is not changeable in any mod and it is unlikely that it will ever be.
 
http://mygamingtalk.com/forums/topic/58-feature-request/

That scenario can be handled by maxbots command and also editing the omni bot scripts so that after a certain threshold, the rest of the bots get removed. I mean specifically allowing more bots to play when the server is emptier but reducing the maxbots value based on the amount of players on the server.

The admin level structure: http://mygamingtalk....ot#shrubbot.cfg
 
Adding a map tto the objective cycle.
 
Objective cycle looks usually something like this:

set d1 "set g_gametype 2 ; map oasis ; set nextmap vstr d2" set d2 "set g_gametype 2 ; map battery ; set nextmap vstr d3" set d3 "set g_gametype 2 ; map goldrush ; set nextmap vstr d4" set d4 "set g_gametype 2 ; map radar ; set nextmap vstr d5" set d5 "set g_gametype 2 ; map railgun ; set nextmap vstr d6" set d6 "set g_gametype 2 ; map fueldump ; set nextmap vstr d1" vstr d1
 
To add for example adlernest, add line

set d7 "set g_gametype 2 ; map adlernest; set nextmap vstr d1"
 
Also, on the line

set d6 "set g_gametype 2 ; map fueldump ; set nextmap vstr d1"
Change it to this

set d6 "set g_gametype 2 ; map fueldump ; set nextmap vstr d7"
 
The change is the last vstr d1 to vstr d7. Which means that instead of nextmap being set to the first line, it is set to the value of d7. The d6 and d7 are both custom cvars. vstr is a command that executes the value in the cvar parameter. So, set nextmap, sets the value of the inbuilt nextmap cvar to "vstr d7". "vstr d7" will expand to

set g_gametype 2 ; map adlernest; set nextmap vstr d1
which sets the gametype to 2, executes the map command with the map adlernest and finally sets the value of the nextmap to do vstr of the next cvar to be executed after map ends.
 
The final result would be

set d1 "set g_gametype 2 ; map oasis ; set nextmap vstr d2" set d2 "set g_gametype 2 ; map battery ; set nextmap vstr d3" set d3 "set g_gametype 2 ; map goldrush ; set nextmap vstr d4" set d4 "set g_gametype 2 ; map radar ; set nextmap vstr d5" set d5 "set g_gametype 2 ; map railgun ; set nextmap vstr d6" set d6 "set g_gametype 2 ; map fueldump ; set nextmap vstr d7" set d7 "set g_gametype 2 ; map adlernest ; set nextmap vstr d1" vstr d1
 
About not being able to connect, have you tried to ping your server? I suspect you are hosting the server yourself so be sure to check firewalls and all such things as well. One thing that makes me curious is, how can you put the commands in the console if you can't connect to the server. Did you mean the server console?

* First, be sure that the getstatus exploit is properly removed from the threats.
 
* Take a look at the cpu and memory consumption with top command.
 
If the problem is recent, i.e. there wasn't problems before with same player amounts and same settings, the issue may be external. E.g. the getstatus exploiting, the ET300 which I suspect you are using.
 
3 MB user.db is not a really big yet and should not cause problems.
 
It is too early to make promises but the networking has been investigated again and it is possible that improvements will be made to the next version.

Do you have VPS or dedicated. One of the problems with VPS can be that the network buffering might not be sufficient with really high packet amounts.

* First, be sure that the getstatus exploit is properly removed from the threats.
 
* Take a look at the cpu and memory consumption with top command.
 
If the problem is recent, i.e. there wasn't problems before with same player amounts and same settings, the issue may be external. E.g. the getstatus exploiting, the ET300 which I suspect you are using.
 
3 MB user.db is not a really big yet and should not cause problems.
 
It is too early to make promises but the networking has been investigated again and it is possible that improvements will be made to the next version.

If the binary update fixed this, then it was just a matter of luck that it happened on the shuffle. I'm glad it is now fixed.

Entity overflow can happen because of players dropping too many medkits/ammopacks after death for example. But it is not related to gamestate chars.

One player takes up to about 150 bytes if I remember correctly. So you can estimate the value a little. Also, if on your server you are used to having 40 players, you can also test by removing just the map that was playing when it happened. Certain maps are more prone to it then others. Also, you can see the config string usage with csinfo rcon command.
 
EDIT:
It's actually closer to max 130 bytes/player.

Large amount of pk3 files in the etmain and in the silent folders. Try reducing them a little if you can.

1. Changin this was necessary because the knife throwing behaviour was changed. It is not possible to hold the knife armed using weapalt.The attack2 is used in Jaymod, NoQuarter and in Nitmod also.
 
2. We always try to look for ways to improve performance.
 
3. I have no idea why ETPub team sees it as experimental. Nevertheless, that decision was made by them and we kept it like that. Furthermore, we haven't even looked at it's implementation which is all the more reason to maintain the ETPub teams recommendations.

Indeed. The weapon number was changed in cooperation with crapshoot and that is why the old file does not work. Try changing the line

WEAPON.PPSH = 101;
To

WEAPON.PPSH = 50;
inside the file weapon_silEnT_ppsh.gm.

Or you can install ET outside of the Program Files folder. No need for the administrator privileges and connecting to the AxE server then

I'm writing this post to bring attention since the documentation is not well written around the subject.
 
Since GUIDs are not trustable at all. Not PB GUIDs or silEnT GUIDs. We included admin level protection system into the 0.5.0 version of the mod. This system effectively limits all benefits from GUID spoofing into gaining XP of the spoofed players. Even private messages are not possible without proper authentication with the server.
 
The system uses 2 cvars:
 
g_adminProtection : bitmask
1 Log succesfull authentications to the cheat log
2 Log admin spoofing attempts to the cheat log
4 Report admins waiting for confirmation on their level to the admin chat
 
g_protectMinLevel : integer
The minimum level of the protected admins.
 
To use the system, set the g_adminProtection to 7. This will enable all logging so you can see who authenticates to what level and if the authentication is succesfull or not. Set the g_protectMinLevel to the lowest level you want to protect. Don't set this to too low because it causes little overhead and also the credentials need to be given using online commands on the server.
 
When the silEnT notices there is an admin connecting to the server who has protected admin level but no credentials, it will report this admin to the admin chat. When this happens, the admin needs to be confirmed with !confirm command by someone who is able to identify the player identity. This only needs to done once for each admin. In the following connections, the silEnT is able to handle the authentications silently itself.
 
From now on, if someone spoofs the GUID of an admin, he will face the authentication procedure. The silEnT will inform into the admin chat that the player has lost his authentication and !setlevel is required. Do not do the !setlevel unless you know this one is genuinly the correct admin. Also, the !confirm command cannot be used anymore for the reason that the !confirm command can be given to less high admins without risks. If the player spoofing the GUID attempts to spoof the credentials, again the admin chat and cheat log is reported with the spoof attempt.
 
Important thing to know is that the !confirm command and !setlevel commands do not give credentials during the warmup period. Also, authentication does not operate during warmup but player needs to wait until the end of warmup before he gains access to his admin level. If you do !confrim or !setlevel during the warmup and the player is later on reported to not have yet been confirmed, just do the !confirm again.
 
I hope this information helps and brings some light to the subject. Feel free to ask questions in this thread and I we will answer those.

This line in the server.cfg seems to be the problem. The campaign cycle does start the mod because it has the map command inside. The watchdog command is probably irrelevant but I recommend removing that one too. It is enough when these are in the silent.cfg.
 
EDIT:
The issue is that the server.cfg is executed first and the silent.cfg after. It is better to have only one cfg in the command line to avoid problems.

oleczek7, add me on my xfire: znemo
 
 
I will help you out trought it. thanks!

Please check the file type using command prompt and the dir command. There really is no bug with opening Lua files by the mod.