Tutorial: Adding a new field to account information (persistent settings)
How successful would Las Venturas Playground be if players had to start over from zero whenever they re-joined the server? Clearly, not successful at all. Storing user information has become critical in the user experience, and starting with LVP 4.0 we have a brand new account system that follows a different philosophy than we previously did. It is asynchronous, split up in multiple tables and has a more complicated design, as it no longer is contained within a single file.
Adding a new data field, which means "wanting to store new information in a player's account", needs work on both the database as the script sides. This tutorial mostly focuses on the gamemode side, as not all developers will have access to the database, and those who do generally know what they're doing. As usual, if you have any questions, please feel free to comment.
First step: getting permission
For privacy reasons, we cannot store anything we want. Furthermore, adding new information needs database modifications on both the game as webserver, synchronization might be impacted, and the website may need changes as well. For these reasons, you have to get permission before you are going to add a new field to account data.
The following people are able to accept requests:
1. Determining what category your data belongs to
Account data has been split up in several categories, both for clarity in the database and in the gamemode itself. These have separate classes, although loading and saving of data is being done in a single location. If your field needs a new category, these steps must be done by a lead developer. The reason for this is that adding a new data category involves modifying the queries itself and will impact server load, so this will be done with more care.
The following categories are available:
In this tutorial, we are going to add the ability to store ponies as part of a player's financial data. The database field is called pony_count.
2. Adding your getter and setter to the AccountData class.
After a Lead Developer helped you to determine the name for your data type, it's time to add it to the storage category's class. There are three main things which we have to do here: write a getter, write a setter and make sure it resets when we have to do so. Since we're adding ponies to the player's financial data, we will modify "Features/Account/AccountFinancialData.pwn".
First, we add the field itself with a brief description.
![[Image: owned_ponies.jpg]](http://crew.sa-mp.nl/russell/owned_ponies.jpg)
Of course, we don't want players to get the ponies of the player who used to have the Id, so make sure we reset it:
![[Image: reset_my_pony.jpg]](http://crew.sa-mp.nl/russell/reset_my_pony.jpg)
Then we have to add the getter and setter. In the code, the setter comes before the getter. Be sure to have a brief description of what the methods do, their parameter type and return type.
![[Image: get_my_ponies.jpg]](http://crew.sa-mp.nl/russell/get_my_ponies.jpg)
Starting right now, you'd be able to use the data as it's saved in the database. However, please read a later section on what you should and shouldn't do in terms of using the AccountData classes directly!
3. Loading your ponies, saving them, but only if they're dirty!
Great! All that remains now is to actually load and save the ponies in the database.
Using the data in the gamemode
In general, it's better to not use the AccountData classes directly. The reason for this is that we may not have to update every kind of data when an account's data is being saved again, which significantly decreases the number of queries we have to execute. This step will be done in the AccountData::isDirty() method, which will return a boolean that indicates whether something has changed. Some categories of data will always return true here, which is the case when code does use the storage directly.
How successful would Las Venturas Playground be if players had to start over from zero whenever they re-joined the server? Clearly, not successful at all. Storing user information has become critical in the user experience, and starting with LVP 4.0 we have a brand new account system that follows a different philosophy than we previously did. It is asynchronous, split up in multiple tables and has a more complicated design, as it no longer is contained within a single file.
Adding a new data field, which means "wanting to store new information in a player's account", needs work on both the database as the script sides. This tutorial mostly focuses on the gamemode side, as not all developers will have access to the database, and those who do generally know what they're doing. As usual, if you have any questions, please feel free to comment.
First step: getting permission
For privacy reasons, we cannot store anything we want. Furthermore, adding new information needs database modifications on both the game as webserver, synchronization might be impacted, and the website may need changes as well. For these reasons, you have to get permission before you are going to add a new field to account data.
The following people are able to accept requests:
- Russell
- MrBondt
1. Determining what category your data belongs to
Account data has been split up in several categories, both for clarity in the database and in the gamemode itself. These have separate classes, although loading and saving of data is being done in a single location. If your field needs a new category, these steps must be done by a lead developer. The reason for this is that adding a new data category involves modifying the queries itself and will impact server load, so this will be done with more care.
The following categories are available:
- General data (AccountData, used for general data such as online time)
- Financial data (AccountFinancialData, used for financial data such as bank account type)
In this tutorial, we are going to add the ability to store ponies as part of a player's financial data. The database field is called pony_count.
2. Adding your getter and setter to the AccountData class.
After a Lead Developer helped you to determine the name for your data type, it's time to add it to the storage category's class. There are three main things which we have to do here: write a getter, write a setter and make sure it resets when we have to do so. Since we're adding ponies to the player's financial data, we will modify "Features/Account/AccountFinancialData.pwn".
First, we add the field itself with a brief description.
Of course, we don't want players to get the ponies of the player who used to have the Id, so make sure we reset it:
Then we have to add the getter and setter. In the code, the setter comes before the getter. Be sure to have a brief description of what the methods do, their parameter type and return type.
Starting right now, you'd be able to use the data as it's saved in the database. However, please read a later section on what you should and shouldn't do in terms of using the AccountData classes directly!
3. Loading your ponies, saving them, but only if they're dirty!
Great! All that remains now is to actually load and save the ponies in the database.
Using the data in the gamemode
In general, it's better to not use the AccountData classes directly. The reason for this is that we may not have to update every kind of data when an account's data is being saved again, which significantly decreases the number of queries we have to execute. This step will be done in the AccountData::isDirty() method, which will return a boolean that indicates whether something has changed. Some categories of data will always return true here, which is the case when code does use the storage directly.