gaoesa

The g_dbUserMaxAge setting could cause problems. But then it would also delete all admin levels. Also according to the log, while it did do file cleanup, the record amounts did look good. The problem with setting the g_dbUserMaxAge the way you try is that it is execed too late. For security reasons, the value can be changed only during server start. However, if this value would cause problems, they would exist on every map change. I suggest you set the value only in the cfg chain that is executed on server start. This did show, however, that you have some delayed cfg executing. Is the xp save settings set directly at the server startup cfgs, or with similar method. If the g_xpsave flag 4 is not set during the very first init, it could lead to full xp reset. Of course, once it is set the first time, it will remain in settings and there would not be any more full resets.

That is the first log output from the database after server restart? The 7 records are not XP but some optional informations which are rarely used. I.e. shrubbot related information. Based on the log output, it loads XP for 202 players, if they have some. I interpreted your question mark meaning this. However, since the shrubbot levels remain after server restart, there shouldn't be problems with the database files. Also it means that the files are not pruned (cleaned from unused data). Nevertheless, could you post the log output regarding the database from the first database closing after the server start. The XP loading is 2 part process. First the database is cached. This seems to work fine. Second part is when the player connects. At this point the age of the XP is checked and if it is too old, it will not be given to the player. The new XP values are then saved to the database at the next level end and that way the players new XP becomes his persistent XP. This is the only way XP resets if the g_XPSave flag 4 is set. If the g_XPSaveflag 4 is not set, all player XP is resetted when map starts. The cases when the XP is resetted from all the players are: * It is the first map of the campaign. * The map count value for XP reset is reached when using map voting game types. * It is last man standing gametype and the first round. * With all other gametypes unconditionally.

No problem. I'm glad you got it solved.

What do you mean with again?

The private message code is the original from ETPub 0.9.1. It is limited to the maximum command length from server to client. Also, other mods that I know of limit it the same way. This includes the major mods.

Yes.

As Dragon posted. The file is not used to store admins but it is used to add admins to the databse if they haven't been on the server yet. Using the !readadmins command. The block is correct one for the use. You can use either one of the GUID fields to insert admins. You should know, however, that if you use the silEnT GUID then the admins PB GUID will not be inserted to the database later even if he would have one. You don't need to delete any lines from the block, you can just leave the value empty.

About the shrubbot trouble. Please check the shrubbot.cfg file and specifically bans. There is a bug that sometimes results temp ban system to create invalid bans and breaking the cfg file. If that is the case, the log will have bunch of parse error prints in it during map starts. Disabling temp ban system will prevent the error until the next version is out.

Do you possibly have some cleanup scripts included with the server restart script? How often do you restart? This problem is puzzling from the mods view because server restart is not different from map change. So it should have the files correctly in use. Especially if you have checked the log entrys concerning the database. Could you check what the first database open and database close logs after the server startup. It would reveal if it is creating new database for some reason or other issues. The g_XPSaveMaxAge should be set, but by default it is 30 days if I remember correctly so it probably isn't the problem in this case.

Private messages not sent to self in next version. It appeared that the messages were sent to self to maintain etadmin mod compatibility. I'm not familiar with the mod and I hope this won't break it in important areas. The private message sizes are limited to maximum command size that can be networked. Increasing the size is not possible without fragmenting the messages to several commands sent to clients.

[banner] message = ^2Visit our website at http://www.himalia.fi/ wait = 45 position = chat [banner] message = ^2Problems with ET ^7crashing^2? Update to to 2.60b! wait = 45 position = bp These are the two banners I'm using on my server. Wiki document: http://mygamingtalk.com/wiki/index.php/Silent_Banners From the document, "position" can have the values chat, cpm (popup), cp (center), bp (banner) or print (console). The cvar is of course g_banners since 0.4.0 even though the document says g_settings which was used before.

1. g_userAxisRespawnTime & g_userAlliedRespawnTime 2. What do you mean? Take a look at the banners.cfg if this is what you mean. 3. No there is no way to change them. Only damage and radius settings.

silEnT mod has a crash handler which usually does print at least something into the log/console, are you sure there is nothing in there? Also we know that omnibot 0.81 crashes sometimes but very rarely. If you're using it you might want to test 0.82 omnibot library.

Resetting charge bar has a buggy nature. Why should class work get fresh start after death. Stamina bar is of course different, but class work is not individual. If there are several cvars to nerf specific effects of this bug, there most likely are even more that are not even addressed. Furthermore, I don't like the idea to do lots of little settings to fix symptomps if one can fix it in the source. The rifle grenade is not a primary weapon and it consumes the engineer charge instead of overheating. Panzerfaust is primary weapon, but should it be possible to blast away without any penalties just because it is a primary weapon. It's not a bug and therefore there is no fix. But this is a feature request and it is not closed. However, doing change that has so much effects to gameplay individual players don't necessarily even notice is not a small thing to do. Foremost, it effects how random players find the games when they play silEnT mod. Not the short term individual frustration when it happens but the game overall.

On the other hand, the charge bar that does not reset for each respawn works pretty well. Also enforcing players to give more thought on how they use the charge and naturally limiting certain events. With charge bar not resetting fops would not get combination of airstrike and artillery for "free" if he/she would die lyckily too close to the spawn time. Similar example with panzerfaust and there are many other cases where it makes an impact. If there is an issue only sometimes, changing the whole behaviour has a far bigger impact then what it is fixing.

You mean that when the recipient name is also part of the senders name?

g_chargeType is ETPub cvar and not included in the silEnT mod. For the issue with the engineers, you could also change the g_engineerChargeTime cvar. The request sounds like the ETPro b_stickycharge cvar which allows getting full charge if the player was killed by the enemy. Which doesn't limit only to /kill. If the issue is limited only to engineers, maybe adjusting the engineer charge time is enough. The charge time can be adjusted also in the map configs.

I'm glad you got it working. I will delete the post in the bug tracker.The bug is not related to this issue. Good luck with your server.

Have you checked the vote_allow_ values using rcon on a live server? Votes that are not allowed do not display in the menu.

I haven't had any problems with PB on Windows 7. Difference in my setup is that I don't have XP compatibility set. Only running as administrator.

set g_dbUserMaxAge "30" This sets the max age to 30 seconds. It's a fault in the default config. Please note that changing this value requires full server restart.

set g_doWarmup 1 I suspect this is the reason. There is a bug that the warmup text is not shown to players before the countdown and this cvar requires players to be ready (press f3 usually) before the countdown for the map starts. This is fixed in the next version. Sorry for the trouble.

It is normal. The length may vary and usually I don't even notice it but it is always expected.

What does PC crashing mean? Windows stops responding? To be clear, is it the client side Windows that is crashing when connecting to a server with PB enabled? What is your antivirus software? Maybe that will say something to someone.

It doesn't happen on it's own. It was running but then suddenly they can't get it up again. The choice of the mod is your own, but at this point if they really officially claim the servers installations just break on their own, you would do better with another hoster.