From EncyclopAtys
(Created page with "{{Trad |DE= |EN=Patch |ES= |FR=Patch RU= }} = Patch creation = == Installation packages == ===External Tools :=== # lzma # xdelta sudo aptitude install lzma xdelta ==...") |
m |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | {{Trad | + | <noinclude>{{Trad |
|DE= | |DE= | ||
|EN=Patch | |EN=Patch | ||
|ES= | |ES= | ||
|FR=Patch | |FR=Patch | ||
− | RU= | + | |RU= |
− | }} | + | }}</noinclude> |
− | = Patch creation = | + | == Patch creation == |
− | == Installation packages == | + | === Installation packages === |
− | ===External Tools :=== | + | ====External Tools :==== |
# lzma | # lzma | ||
# xdelta | # xdelta | ||
Line 15: | Line 15: | ||
sudo aptitude install lzma xdelta | sudo aptitude install lzma xdelta | ||
− | ===Tools Nel=== | + | ====Tools Nel==== |
#make_bnp | #make_bnp | ||
#patch_gen | #patch_gen | ||
Line 23: | Line 23: | ||
[[en_make_bnp|Compilation of the .bnp]]. | [[en_make_bnp|Compilation of the .bnp]]. | ||
− | === Implementation of the data hierarchy === | + | ==== Implementation of the data hierarchy ==== |
It must first be placed in a place in which we generate patches. One of these areas will be opened by the Apache server to serve the web clients. | It must first be placed in a place in which we generate patches. One of these areas will be opened by the Apache server to serve the web clients. | ||
We will place us in the '' patch_service '' in our directory '' home '': | We will place us in the '' patch_service '' in our directory '' home '': | ||
Line 48: | Line 48: | ||
~/patch_service$ touch patch_game/Example.version | ~/patch_service$ touch patch_game/Example.version | ||
− | == Configuring the patch server == | + | === Configuring the patch server === |
You must then edit the file ''patch_service/ryzom.xml'' : | You must then edit the file ''patch_service/ryzom.xml'' : | ||
Line 80: | Line 80: | ||
The specified parameters will gradually increment the content of our .bnp, adding new files, and the file bnp after being downloaded by the client, will be unpacked in '' / user '' to be taken account last (to overwrite older versions of files such as handy for testing). | The specified parameters will gradually increment the content of our .bnp, adding new files, and the file bnp after being downloaded by the client, will be unpacked in '' / user '' to be taken account last (to overwrite older versions of files such as handy for testing). | ||
− | == Patch server activation at the database == | + | === Patch server activation at the database === |
The system based on a database, you must let him know that we activate the patch server. For this we will use commands in MySQL. | The system based on a database, you must let him know that we activate the patch server. For this we will use commands in MySQL. | ||
Line 95: | Line 95: | ||
UPDATE domain SET patch_urls='http:''my.ip.com/patch' WHERE domain_id=12; | UPDATE domain SET patch_urls='http:''my.ip.com/patch' WHERE domain_id=12; | ||
− | == Creation of the first Patch == | + | === Creation of the first Patch === |
We must now create the first patch, which will provide the bnp in its original state at client.Nous reuse the same command, but with a different statement this time: | We must now create the first patch, which will provide the bnp in its original state at client.Nous reuse the same command, but with a different statement this time: | ||
Line 111: | Line 111: | ||
The key is to get to the end: ''Generating client index: patch_game/patch/00001/ryzom.idx...'' | The key is to get to the end: ''Generating client index: patch_game/patch/00001/ryzom.idx...'' | ||
− | == Création de la Release Note == | + | === Création de la Release Note === |
You can create a file in the root '' patch '' that will serve to disseminate information on the patched data. This may be a php file, which can receive from the customer more information: | You can create a file in the root '' patch '' that will serve to disseminate information on the patched data. This may be a php file, which can receive from the customer more information: | ||
* version : the version of the patch ; | * version : the version of the patch ; | ||
Line 138: | Line 138: | ||
The content is now ready for release, remains to know the customers. | The content is now ready for release, remains to know the customers. | ||
− | = Apache server configuration = | + | == Apache server configuration == |
We are assuming that you already have a working Apache server, and that it is just to create a new VirtualHost. If the directory '' home '' of the user who manages the server is named '' gameserver '', it must have these parameters (otherwise adjust according to your settings): | We are assuming that you already have a working Apache server, and that it is just to create a new VirtualHost. If the directory '' home '' of the user who manages the server is named '' gameserver '', it must have these parameters (otherwise adjust according to your settings): | ||
Line 179: | Line 179: | ||
~/patch_service$ sudo service apache2 restart | ~/patch_service$ sudo service apache2 restart | ||
− | = Announce the availability of the patch = | + | == Announce the availability of the patch == |
It must then warn customers that this patch number 1 is ready to be distributed, we will do with a new file '' Exemple.version '' (there will be two to one previously created) in directory '' patch '' served by Apache: | It must then warn customers that this patch number 1 is ready to be distributed, we will do with a new file '' Exemple.version '' (there will be two to one previously created) in directory '' patch '' served by Apache: | ||
Line 193: | Line 193: | ||
The second number is the one that is passed to the php page for '' version '', we change simultaneously so. | The second number is the one that is passed to the php page for '' version '', we change simultaneously so. | ||
− | = Client Configuration = | + | == Client Configuration == |
For the client to access the patches, there are two cases. | For the client to access the patches, there are two cases. | ||
− | == Client DEV == | + | === Client DEV === |
It is better to indicate the parameters in its client_default.cfg. should therefore be taken to the presence of these lines: | It is better to indicate the parameters in its client_default.cfg. should therefore be taken to the presence of these lines: | ||
Line 207: | Line 207: | ||
[[#creation_de_la_release_note|Release Notes.]] | [[#creation_de_la_release_note|Release Notes.]] | ||
− | == Client FV == | + | === Client FV === |
The FV client must be compiled with the '' WITH_RYZOM_PATCH '' to access the patch server. Without any other option specified, it will automatically connect to the patch server specified by the server (noted above in the MySQL database). | The FV client must be compiled with the '' WITH_RYZOM_PATCH '' to access the patch server. Without any other option specified, it will automatically connect to the patch server specified by the server (noted above in the MySQL database). | ||
Line 223: | Line 223: | ||
RingReleaseNotePath = "http:''my.ip.com/patch/index.php"; | RingReleaseNotePath = "http:''my.ip.com/patch/index.php"; | ||
− | = Enjoy ! = | + | == Enjoy ! == |
With this configuration, be sure that your '' unpack '' is empty of any file '' .version '' or '' .idx '' for the first patch. Thereafter, the system will keep track of patches received in this directory, so be sure to keep these files (under penalty of having to re-patch your client 0). With our example, new elements will be automatically unpacked in your '' user '' at the client restart after downloading. | With this configuration, be sure that your '' unpack '' is empty of any file '' .version '' or '' .idx '' for the first patch. Thereafter, the system will keep track of patches received in this directory, so be sure to keep these files (under penalty of having to re-patch your client 0). With our example, new elements will be automatically unpacked in your '' user '' at the client restart after downloading. | ||
It'll just launch your game client and see if patch! | It'll just launch your game client and see if patch! | ||
+ | |||
+ | |||
+ | ==Notes== | ||
+ | For wiki pages about Patch, see the French page [[:fr:Conventions Patches & Updates]] (to translate in En). | ||
+ | <noinclude> | ||
{{Portal Forge}} | {{Portal Forge}} | ||
[[category:Help-support]] | [[category:Help-support]] | ||
+ | </noinclude> |
Latest revision as of 13:32, 13 February 2021
Contents
Patch creation
Installation packages
External Tools :
- lzma
- xdelta
sudo aptitude install lzma xdelta
Tools Nel
- make_bnp
- patch_gen
They were created with the compilation of the shard. For make_bnp : Compilation of the .bnp.
Implementation of the data hierarchy
It must first be placed in a place in which we generate patches. One of these areas will be opened by the Apache server to serve the web clients. We will place us in the patch_service in our directory home :
mkdir ~/patch_service cd ~/patch_service
Generate New Product :
~/patch_service$ patch_gen createNewProduct patch_game/ryzom.xml
Directory Layout:
- patch_service/
- bnp/
- patch/
- ref/
- ryzom.xml
We will then copy our bnp files in the directory assigned to them (which we assume they are stored in a directory ~ / bnp :
~/patch_service$ cp ~/bnp/*.bnp patch_game/bnp/
You must then create an empty file, which will be used for indexing patches. It consists of the name of the shard (we will Lirria as an example here, as this is the name of the shard development kaganate) followed .version, and will be placed in the patch_game :
~/patch_service$ touch patch_game/Example.version
Configuring the patch server
You must then edit the file patch_service/ryzom.xml :
~/patch_service$ nano patch_game/ryzom.xml
Detailed explanation of the syntax of this file is given in another article ( The syntax of the xml file of the patch server), and we will simply create here the establishment of the single patch_example.bnp , planned to copy in the client subdirectory '/ user' data for testing.
Our configuration file will look like this:
<xml> <_Categories> <_Category> <_Name type="STRING" value="khanat_lirria"/> <_IsOptional type="SINT32" value="0"/> <_UnpackTo type="STRING" value="./user/"/> <_IsIncremental type="SINT32" value="1"/> <_Files type="STRING" value="patch_example.bnp"/> </_Category> </_Categories> <_IndexFileName type="STRING" value="ryzom.hist"/> <_PatchDirectory type="STRING" value="patch_game/patch/"/> <_BnpDirectory type="STRING" value="patch_game/bnp/"/> <_RefDirectory type="STRING" value="patch_game/ref/"/> <_NextVersionFile type="STRING" value="patch_game/Example.version"/> <_ClientIndexFileName type="STRING" value="ryzom"/> </xml>
The specified parameters will gradually increment the content of our .bnp, adding new files, and the file bnp after being downloaded by the client, will be unpacked in / user to be taken account last (to overwrite older versions of files such as handy for testing).
Patch server activation at the database
The system based on a database, you must let him know that we activate the patch server. For this we will use commands in MySQL.
We assume that your domain number is 12, if not, change the value. First activate the patch server (by setting the value of patch_version to 1 instead of 0, default)
USE nel; UPDATE domain SET patch_version=1 WHERE domain_id=12;
Then specify the server address in the fields patch_urls :
USE nel; UPDATE domain SET patch_urls='http:my.ip.com/patch' WHERE domain_id=12;
Creation of the first Patch
We must now create the first patch, which will provide the bnp in its original state at client.Nous reuse the same command, but with a different statement this time:
~/patch_service$ patch_gen updateProduct patch_game/ryzom.xml
It is possible that you have a warning during this operation, but this seems not serious.
WRN a8ded740 patch_gen_common.cpp 59 GeneratePatch <Unknown> : 'xdelta delta patch_game/empty patch_game/bnp/patch_example.bnp patch_game/patch/00001/patch_v1_00001.patch' failed with error code 256
The key is to get to the end: Generating client index: patch_game/patch/00001/ryzom.idx...
Création de la Release Note
You can create a file in the root patch that will serve to disseminate information on the patched data. This may be a php file, which can receive from the customer more information:
- version : the version of the patch ;
- lang : the customer's language ;
- ca : the connection Shard ;
- startPage : <wrap tip>to define</wrap>
Suppose we create a simple html file.
~/patch_service$ nano patch_game/patch/index.php
<html><head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body> <h1>Saturday, october 28 2016</h1> <h2>RELEASE</h2> <p>After much work and a few years we are proud to present the first official release .</p> <br> </body></html>
The content is now ready for release, remains to know the customers.
Apache server configuration
We are assuming that you already have a working Apache server, and that it is just to create a new VirtualHost. If the directory home of the user who manages the server is named gameserver , it must have these parameters (otherwise adjust according to your settings):
Our wish is to have a single address, without port to the patch server, which will be of the form http:my.ip.com/patch .
So we must first install some modules for Apache (if not already done in advance):
~/patch_service$ sudo a2enmod proxy ~/patch_service$ sudo a2enmod proxy_http
We then add in the VirtualHost listening on port 80 the line:
ProxyPass /patch/ http:lirria.khaganat.net:43435/
Then we define our dedicated and Virtual Host:
<VirtualHost *:43435> ServerName lirria.khaganat.net DocumentRoot /home/gameserver/patch_service/patch_game/patch/ <Directory "/home/gameserver/patch_service/patch_game/patch"> Options -Indexes AllowOverride All Require all granted </Directory>
</VirtualHost>
The Option -Indexes blocks the display of default directories for security reasons.
Open the 43435 port in Apache.
Listen 43435
Once this is done, we restart the Apache service:
~/patch_service$ sudo service apache2 restart
Announce the availability of the patch
It must then warn customers that this patch number 1 is ready to be distributed, we will do with a new file Exemple.version (there will be two to one previously created) in directory patch served by Apache:
~/patch_service$ nano patch_game/patch/Lirria.version
It is enough to indicate just (1 - space 1 ):
1 1
to say that the patch number 1 is ready. In the future, it will be enough to put 2 to serve the patch 2 etc.
The second number is the one that is passed to the php page for version , we change simultaneously so.
Client Configuration
For the client to access the patches, there are two cases.
Client DEV
It is better to indicate the parameters in its client_default.cfg. should therefore be taken to the presence of these lines:
PatchWanted = 1; PatchUrl = "http:my.ip.com/patch"; RingReleaseNotePath = "http:my.ip.com/patch/index.php";
It is now well PatchUrl and not PatchServer , which is obsolete.
The last refers to the file we created for Release Notes.
Client FV
The FV client must be compiled with the WITH_RYZOM_PATCH to access the patch server. Without any other option specified, it will automatically connect to the patch server specified by the server (noted above in the MySQL database).
It will seek the release notes on these hardcodées Address:
RingReleaseNotePath = "http:" + WebIgMainDomain + "/releasenotes_ring/index.php"; ReleaseNotePath = "http:" + WebIgMainDomain + "/releasenotes/index.php";
This will require careful to ensure that the address WebIgMainDomain is correctly filled in client_defaut.cfg
IF the customer FV also received the WITH_RYZOM_CUSTOM_PATCH_SERVER , it will act as the client DEV and will be provided with the necessary lines in his client_default.cfg:
PatchWanted = 1; PatchUrl = "http:my.ip.com/patch"; RingReleaseNotePath = "http:my.ip.com/patch/index.php";
Enjoy !
With this configuration, be sure that your unpack is empty of any file .version or .idx for the first patch. Thereafter, the system will keep track of patches received in this directory, so be sure to keep these files (under penalty of having to re-patch your client 0). With our example, new elements will be automatically unpacked in your user at the client restart after downloading.
It'll just launch your game client and see if patch!
Notes
For wiki pages about Patch, see the French page fr:Conventions Patches & Updates (to translate in En).