- MySQL optimization.
- Added a new setting SAVE_INTERVAL that allows you to enable additional periods when the XP is saved, rather than it happening only when the player disconnects. Now you can do it when the player dies, in the end of the round or every time when the XP amount is modified. The goal of this setting is to prevent XP loss in servers that have a tendency to crash.
- Added 2 new XP Rewards: team_win and team_lose that are called when you win a round and lose a round, respectively.
In order to update from the previous version, you need to update the .sma file and add the following lines in the [Settings] section of the configuration file:
PHP Code:
# When to save the XP?
# It's best to leave this setting on 0 if your server isn't experiencing any problems (crashes) that prevent it from saving XP.
# 0 = on disconnect (best for servers that never crash)
# 1 = on disconnect + on death (good for servers that crash occasionally and you want to save the XP for at least the current life)
# 2 = on disconnect + on round end (good for servers that crash occasionally and you want to save the XP for at least the current round)
# 3 = every time the player's XP is changed (guarantees that XP will never be lost, but may be laggy if players receive XP very often)
SAVE_INTERVAL = 0
Quote:
|
Originally Posted by OciXCrom
@HamletEagle - I'll do the changes + the ones from your PM later today or tomorrow.
|
Tomorrow has finally come.
Quote:
|
Originally Posted by HamletEagle
g_aLevels seems to be an array for integers. Then cellsize should be 1, not 16.
|
Done.
Quote:
|
Originally Posted by HamletEagle
As I said before, your code can leak connections if a query fails. If you prematurely return from a function before a handle is freed you should also add SQL_FreeHandle before returning.
For example, at line 239: assume the if check passes because the query failed. You will print the error message and jump after SQL_FreeHandle(iSqlConnection) with a goto. This will cause a leak.
|
I think it should be fine now.
Quote:
|
Originally Posted by HamletEagle
In client_infochanged you should refactor to have the SAVE_TYPE check be first or right after is_user_connected check. There is no point in retrieving new/old name or doing anything for that matter if the saving method is not "name".
|
You missed this line:
PHP Code:
set_task(DELAY_ON_CHANGE, "update_vip_status", id)
If the name changes, his flags can change as well and this is independent of the
SAVE_TYPE setting. This is yet another reason why we need
client_flags_updated forward.
Quote:
|
Originally Posted by HamletEagle
Why do you wait 0.1 seconds in the mysql case instead of immediately calling save_or_load for loading.
|
Usually the name updates ~0.1 seconds after
client_infochanged, but not sure why I didn't use
szNewName right away. I changed it now.
Quote:
|
Originally Posted by HamletEagle
Also, do you think you could add a setting to control what happens on a name change? It can be right now, where you simply load whatever was saved on the new name or you could actually transfer the data from the old name to the new name and remove the old one from the vault/database.
I think this could be useful if a player gets sick of his old name, wants to play under a new one, but doesn't want to start from 0.
|
It's a possibility, yes. I'll leave it for a future update though, as I don't have much options for testing at the moment, plus this will need to be checked on player connect as well and compare the IP/SteamID data with the previous nickname, which is not possible at the moment, because only the IP/SteamID is saved when
SAVE_TYPE is not
ST_NICKNAME.
Quote:
|
Originally Posted by HamletEagle
It's probably time to remove Cmd_UpdateMySQL.
|
Yup.
Quote:
|
Originally Posted by HamletEagle
In sort_players_by_xp, you can just return g_ePlayerData[id2][XP] - g_ePlayerData[id1][XP]. This is common practice for short sorting functions.
|
So I assume "-1" and "1" are not the only valid return values as stated in the API and it actually checks if the value is positive or negative. Cool, I didn't know that.
Quote:
|
Originally Posted by HamletEagle
I know I pointed this out before, but I'll say again, just in case: inside save_or_load, in SL_SAVE_DATA you should free iSqlConnection or use SQL_FreeHandle inside SQL_QuoteString.
|
Yup. I made sure every variable tagged with
Handle is freed at the end of its usage.
Quote:
|
Originally Posted by HamletEagle
In SL_LOAD_DATA case: I don't really like you make a connection, close it and then reopen immediately inside prepare_player. Keep the connection open and do both task with one connection, the information is already there.
|
Done.
__________________