https://wiki.thedarkmod.com/api.php?action=feedcontributions&feedformat=atom&user=TaaakiThe DarkMod Wiki - User contributions [en]2026-04-29T16:32:25ZUser contributionsMediaWiki 1.45.3https://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics&diff=25985TDM Release Mechanics2019-11-20T17:45:52Z<p>Taaaki: </p>
<hr />
<div>This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.<br />
<br />
The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:<br />
<br />
= Development = <br />
Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.<br />
<br />
= Libraries and License =<br />
<br />
A few weeks before release, it is a good idea to revise the set of third-party libraries used.<br />
Starting from TDM 2.08, it should be easy to check it thanks to the new conventions on third-party stuff (see also [[Libraries and Dependencies]]).<br />
<br />
It is necessary to update the <tt>LICENSE.txt</tt> file in SVN repositories if something is not up-to-date.<br />
Note that you should commit the same updated file into '''both''' source code and assets repos.<br />
<br />
= Branching off =<br />
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN. <br />
<br />
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right|350px]]<br />
* Update your darkmod working copy.<br />
* Update the darkmod_src repository too.<br />
* Right-click the darkmod folder to create the branch<br />
** Select SVN > Branch/Tag...<br />
** A new dialog appears asking for a URL. Enter a URL like this: [https://server/svn/darkmod/branches/release1.xx https://<darkmod_server_here>/svn/darkmod/branches/release1.xx] where xx is replaced by whatever version the next release will be. <br />
** You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.<br />
** Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).<br />
* The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme [https://server/svn/darkmod_src/branches/release1.xx https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx]<br />
<br />
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch. <br />
<br />
'''Important:''' Commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.<br />
<br />
= Compile Game Binaries =<br />
Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile .exe and .dll files for you, or you can bite the bullet and follow the [[TDM Compilation Guide]] to compile them yourself. As Windows user, I recommend setting up an Ubuntu 16.04 64-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC. <br />
<br />
Make sure you compile a '''release build''' (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild Solution''<br />
* Linux: <tt>scons -c && scons BUILD="release" TARGET_ARCH="x86"</tt> (or <tt>"x64"</tt>)<br />
Note that you have to compile both 32-bit and 64-bit build for every platform (Windows and Linux).<br />
<br />
Once compiled, move freshly created thedarkmod.x86 and thedarkmod.x64 files from darkmod_src (where they are created by scons) to darkmod directory.<br />
Then commit the following files ''to the branch'' (all of them must be treated as "modified" by SVN client):<br />
* ExtLibs.dll<br />
* ExtLibsx64.dll<br />
* thedarkmod.x86<br />
* thedarkmod.x64<br />
* TheDarkMod.exe<br />
* TheDarkModx64.exe<br />
<br />
= Compile tdm_update =<br />
tdm_update must be built separately for both Windows and Linux.<br />
<br />
Make sure you compile a '''release build''', and recompile everything from scratch:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild tdm_update_mfc''<br />
* Linux: descend into the tdm_update directory and then do <tt>scons -c && scons BUILD="release"</tt><br />
<br />
Once compiled, copy the results into the darkmod folder:<br />
<br />
* Windows/VC++: bin/GuiUpdater/tdm_update.exe -> darkmod/tdm_update.exe<br />
* Linux: tdm_update.linux -> darkmod/tdm_update.linux<br />
<br />
Commit these ''to the branch''.<br />
<br />
<br />
'''TODO for 2.07''': now we also have 64-bit Linux version of tdm_update (built if you add <tt>TARGET_ARCH="x64"</tt> at the end of scons command line).<br />
It should be renamed to something like tdm_update.linux64 and also committed to the branch.<br />
<br />
= The Manifest =<br />
The "manifest" is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list. The manifest text file is located in the SVN repository: '''devel/manifests/darkmod.txt'''<br />
<br />
== Building the Manifest ==<br />
<br />
Note: This section is more or less for your understanding, '''you don't need to manually generate the manifest anymore''' as this step is part of the automated process running on the TDM server itself.<br />
<br />
The manifest file is generated by the tdm_package application. (The tdm_package sources are in the darkmod_src repository, in a subfolder called tdm_update. There is a VC++ 2013 solution and a sconscript for Linux and Mac builds available. You don't need to compile it if you're in Windows, there is a pre-compiled version in the darkmod repo as well, in the devel/packager folder.) <br />
<br />
After the generation step the file '''devel/manifests/darkmod.txt''' will have been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.<br />
<br />
== What is included in the Manifest ==<br />
The package application is using the file <tt>devel/manifests/darkmod_maps.txt</tt> to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:<br />
<br />
# Include all these files (but without parsing them like maps), each<br />
# statement will include files (from SVN) in that folder:<br />
INCLUDE def/<br />
INCLUDE dds/<br />
...<br />
INCLUDE video/<br />
INCLUDE xdata/<br />
As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.<br />
<br />
As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:<br />
EXCLUDE dds/darkmod/test<br />
In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:<br />
EXCLUDE models/md5/chars/undead/revenant/.*.md5anim<br />
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant<br />
The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant '''and''' the ones in '''dds/'''models/md5/chars/undead/revenant (the dds/ part is marked to be optional). <br />
<br />
In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.<br />
<br />
= Distribute files into PK4s =<br />
Each of the roughly 15000 files in the manifest needs to be sorted into the correct PK4. This is done by defining a rules in the file <tt>devel/manifests/darkmod_pk4s.txt</tt>. Each of the lines there defines a PK4 and which files go into it:<br />
# Miscellaneous stuff (GL Progs, Script, Language Files, Rope Arrow)<br />
tdm_base01.pk4: ^glprogs, ^script, ^strings, sound\.wav, _emptyname\.wav, ^models/md5/environments, ^dds/models/md5/environments, ...<br />
Again, lines starting with the sharp # character denote comments.<br />
<br />
Leftmost is the PK4 filename, followed by a colon character. To the right of the colon a list comma-separated patterns is defined, whereas each pattern is interpreted as regular expression. As with the <tt>darkmod_maps.txt</tt> you don't need to know very much about regular expressions to define those rules, it's usually enough to write the folder names and use wildcards like <tt>.*.md5anim</tt><br />
<br />
= Build the Package =<br />
The package is built right on the TDM server - there is a full darkmod repository checked out on the server's filesystem, and it will be processed through some scripts that are listening to your commands.<br />
<br />
Once triggered, the process goes roughly like this, I'll comment on these steps below:<br />
<br />
* The working copy is reverted, such that it is clean.<br />
* The working copy is switched to the release branch of the version you're about to release (it must exist at this point).<br />
* The working copy is implicitly updated by the switch operation.<br />
* The manifest is generated.<br />
* The full set of PK4 files is generated (it takes a while, the server CPU is not very powerful).<br />
* The differential package is generated.<br />
* The files are copied to a public folder reachable through HTTP such that it can be tested by the team. The team will test it by storing a manipulated tdm_mirrors.txt file next to their tdm_update application.<br />
<br />
== Prepare the packaging process ==<br />
A few steps need to be done before kicking off the process on the server.<br />
<br />
* The release branch must be created, with a specific naming convention: https://darkmod_server_here/svn/darkmod/branches/releaseY.XX where Y is the major version and XX is the two-digit minor version, e.g. "release1.08".<br />
* The inclusion statements in the <tt>darkmod_maps.txt</tt> file need to be up to date, make sure everything is committed to the branch.<br />
* The <tt>tdm_version.txt</tt> file should be containing the correct version number, it's located in <tt>devel/release/tdm_version.txt</tt>. Commit that change to the release branch, needless to say.<br />
<br />
== Kicking off the packaging process ==<br />
There is a special admin page on the server which can be used to kick off the process. The URL has been [http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/ posted on the forums before], greebo or grayman know the URL. It's password protected, so you'll be asked to enter credentials. Once there, you can enter the two version numbers, the one you're building, and the previous one (the latest released one). E.g.: 1.08 and 1.07. It's sufficient to enter the currently released one, e.g. 1.07, into the second field and the website will automatically fill in the next version number in the first field - you can override it if really necessary.<br />
<br />
Once you start the process you'll be presented a text window with some progress information, and you can watch the messages emitted by the svn client and the tdm_package application running on the server. It takes a while, about half an hour, until the package is built.<br />
<br />
= Prepare the internal package test =<br />
The team needs to have access to the package as created above for internal testing, so tell them to download a specially prepared tdm_mirrors.txt. You can find one attached to the first post here: http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/<br />
<br />
The linked post above already contains a few instructions you can copy from. Basically, instruct the team to use the <tt>--keep-mirrors</tt> switch when starting the tdm_update application, and to copy the tdm_mirrors.txt file into their test folder before running it. If the <tt>--keep-mirrors</tt> option is omitted the updater will connect to the regular TDM update mirrors, which is not the point.<br />
<br />
= The Test & Bugfix cycle =<br />
Once the testers post their bug reports, the dev team needs to get moving to fix them. It's recommended that all fixes will be committed to the trunk (both for darkmod and darkmod_src repos), and the release manager should merge the changes into the release branch.<br />
<br />
== Merge Fixes into the Release Branch ==<br />
Let's assume there is a fix that got committed to darkmod SVN in order to fix an issue discovered in the test package. Proceed like this to merge it to the release branch. <br />
* Make sure your local working copy is switched to the release branch. <br />
* Now right-click the darkmod folder and choose SVN > Merge<br />
* Select ''Merge a range of revisions''<br />
* As ''URL to merge from'' use the address of the trunk: [https://server/svn/darkmod/trunk https://<darkmod_server>/svn/darkmod/trunk]<br />
* In the field revision range to merge you need to specify which exact change you intend to merge. It's easier if you click the "Show Log" button right next to the entry field to view the SVN Log of the trunk. You can either select a single commit, or you can select a range of commits. Perhaps double-check the changes of that checkin.<br />
* Hit ''Next'', then ''Merge''.<br />
* Important: the changes will be incorporated into your ''working copy''. If you want these changes to actually be stored in the release branch, you need to perform the ''commit''.<br />
<br />
Special note for code changes: once these are committed to darkmod_src trunk, you need to merge them just like described above. Then you're going to recompile the game binaries (I recommend from scratch) and commit the tdm_game01.pk4 / tdm_game02.pk4 files to the darkmod release branch too.<br />
<br />
== Update the Test Package ==<br />
Re-package the TDM package, as described above. Just make sure everything is committed to the release branch and kick off another build process.<br />
<br />
== Test again ==<br />
Inform your testers about the update and which things got changed since the last test. Instruct them to update their test installation (don't forget to mention --keep-mirrors) and enter the next round of testing.<br />
<br />
= Release Time: Upload & Cleanup =<br />
Once the day has come to release the next version, connect to the TDM server using a secure shell (SSH) client, like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY].<br />
<br />
Follow these steps, there are some things that need to be done afterwards, they are necessary for the ''next'' release to function properly:<br />
<br />
* Rebuild binaries from scratch, place in darkmod folder, and commit the darkmod folder.<br />
* 7-zip the Windows files: TheDarkMod.pdb, TheDarkModx64.pdb, ExtLibs.pdb, ExtLibsx64.pdb, and place them into the trunk darkmod/devel/release/debugging/2.0x folder. Add that folder to SVN and commit it.<br />
* Update the darkmod 2.0x branch tree and merge the just-placed debugging files to that branch. Commit the 2.0x branch.<br />
* Create the final package remotely as described above (through the website). <br />
* The above step will generate a new crc_info.txt and a tdm_version_info.txt file on the server.<br />
* The packaging script will take care of checking these two files into SVN for "Release" packages.<br />
* Check in the newly generated manifest, it should still be in the folder where the packaging script left it. Note: The packaging script will check this file in automatically for "Release" packages.<br />
* Create a tag for the darkmod and darkmod_src repositories (/tags/2.0x) - copy it from the latest revision in the corresponding release branch.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy package from /usr/local/www/update.thedarkmod.com/ to /usr/local/tdm_releases/2.0x/ for archiving. The next package process will need it there.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy /usr/local/tdm_releases/1.05/index.html to /usr/local/tdm_releases/2.0x<br />
** The packaging script will perform this task for "Release" packages.<br />
* Move all differential packages back to /usr/local/www/update.thedarkmod.com/<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy the one differential update package updating to the new 2.0x version back to /usr/local/tdm_releases/2.0x. In the following line, (y = x-1).<br />
** The packaging script will perform this task for "Release" packages.<br />
* At this point, the /usr/local/tdm_releases/2.0x folder contains a valid TDM 2.0x release, the one that will be pushed to all the mirrors. Examine it for double safety.<br />
* Examine the upload_to_all_mirrors.sh shell script, to see if it fits your needs.<br />
* Start uploading to all mirrors.<br />
** <tt>./upload_to_all_mirrors.sh 2.0x</tt><br />
** Update the rsyncd config on update.thedarkmod.com to point to the new release folder (taaaki will need to do this).<br />
* Update tdm_mirrors.txt and tdm_version.xml on thedarkmod.com/update: ask taaaki to do that. The tdm_mirrors.txt file is probably fine, but the tdm_version.xml needs to be updated.<br />
<br />
== Update the Wiki ==<br />
<br />
The wiki contains one page for each release. You can find them all in the [[:Category:What's New]] category. <br />
<br />
First update the current release page:<br />
<br />
* Change the "roadmap" link on the current release to a "changelog" link by swapping ''"roadmap_page.php?version_id=XX"'' with ''"changelog_page.php?version=XX"''.<br />
* Add the ''<nowiki>{{released|2.01|2014-01-30}}</nowiki>'' Template on top of the current release page with the correct date.<br />
<br />
Then add a new page for the next release. To do this, add a link to it in this template: [[Template:Whatsnew]] by editing it. After saving the template, a link to the new release version page appears in the list and in the category. Edit this page and insert some text into it (you can copy it from an older release page).<br />
<br />
Also insert a link to the current roadmap on the bugtracker, you can find out the version_id by looking at [http://bugs.thedarkmod.com/roadmap_page.php the roadmap page].<br />
<br />
== Update the Website ==<br />
<br />
Be sure to update the following pages on the website to reflect the latest release version:<br />
* [http://www.thedarkmod.com/downloads/ http://www.thedarkmod.com/downloads/]<br />
* [http://www.thedarkmod.com/download-the-mod/ http://www.thedarkmod.com/download-the-mod/]<br />
* [http://www.thedarkmod.com/download-sourcecode/ http://www.thedarkmod.com/download-sourcecode/]<br />
<br />
To generate the latest source code package for the page above:<br />
* Check out the code from the release tag. E.g. svn checkout https://svn.thedarkmod.com/svn/darkmod_src/tags/x.yy<br />
* Remove (or exclude) the .svn from the working copy folder<br />
* Create a 7zip archive with the following naming convention: thedarkmod.x.yy.src.7z<br />
** 7z a -r ../thedarkmod.x.yy.src.7z ./* <br />
* Upload the source code archive to http://www.thedarkmod.com/sources (ask taaaki for assistance with this or use the ftp upload user)<br />
<br />
== Hotfixes ==<br />
In the event of game-breaking bugs making it into the release, it is possible to rebuild the release with the same version number. This should only be done when absolutely necessary. The process is essentially as follows:<br />
* Merge the bug fixes into the current release branch (include the recompiled binaries).<br />
* Re-run the "Testing" package build and test the updated release from http://update.thedarkmod.com/testing/<br />
* If all is in order, proceed to generate the "Release" package as above and deploy the updated release to the mirrors.<br />
** Note: it may be necessary to tweak the create_package.sh file to exclude the creation of the release tag - be sure to revert back to the original after the hotfix process has been completed (TODO: an additional option should be added to the release management screen to handle with automatically).<br />
** Manually create a new release tag for darkmod/ and darkmod_src/ (E.g. darkmod/tags/2.05hotfix and darkmod_src/tags/2.05hotfix repectively).<br />
** Update the source code package and re-upload to the website if necessary.<br />
<br />
= Glossary =<br />
* Release Fileset: the PK4 files forming the actual release. <br />
* SVN: an acronym for Subversion, a version control system<br />
* Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.<br />
* Mirrors: The servers where the PK4 files are stored for download by the updater.<br />
* updater: The TDM Updater executable, used for downloading and updating TDM.<br />
* binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).<br />
* darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.<br />
* branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.<br />
* trunk: The main branch where all the ongoing development is happening.<br />
<br />
{{todo}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=Cutscenes_Part_1:_Cameras&diff=19370Cutscenes Part 1: Cameras2017-07-04T20:13:43Z<p>Taaaki: /* The Scene */</p>
<hr />
<div>==The Scene==<br />
<br />
In the scene we'll be creating, a City Watch guard is meeting an informant to hear about an upcoming bank heist. The script is simple: the two actors walk onstage, talk, and depart. The map is called ''Snitch''.<br />
<br />
FM authors use two different work setups: ''Project'', and ''Non-Project''. For an overview, see [[Startpack Mappers' Guide#Project versus Non-Project?]]. The files in this tutorial are available in Project form. Those who prefer the Non-Project form can place the files in the appropriate directories.<br />
<br />
Download [http://ftp.thedarkmod.com/tutorials/Cutscenes%20by%20grayman/snitch.zip snitch.zip] and extract it into your ''Doom 3'' folder. What you're getting is a set of maps with a dressed set, two actors, a player start near some handy buttons, and a script to run the scene. Each article in this series comes with its own starting map for you to work with, and a "finished" map to check against.<br />
<br />
==Camera Creation==<br />
[[Image:Camera1.jpg|200px|thumb|right|Camera1]]<br />
<br />
Open the map ''snitch1.map'' in Dark Radiant. In this map, center stage is the bulletin board on the north wall (+Y direction) of the courtyard. The two actors wait offstage, the guard at the end of a hallway to the NE, the informant on a porch to the West.<br />
<br />
Let's add the first of four cameras. Create a camera entity (''darkmod/func/func_cameraview'') and move it so its origin is 32 units over the top of the bush in the SE corner. Give it the following Property/Value pairs:<br />
<br />
* "name" "Camera1"<br />
* "trigger" "1" (this camera will work when triggered)<br />
<br />
When setting up any scene, you should first present an ''Establishing Shot'' to give the player a sense of where the scene is taking place. Is it in a dining room, in an alley, on the roof of a Builder cathedral? Camera1 will give us our Establishing Shot, pulled back enough to present the courtyard and show where the scene is taking place.<br />
{{clear}}<br />
==Point the Camera==<br />
[[Image:target_null_1.jpg|200px|thumb|right|target_null_1]]<br />
<br />
Camera1 needs to be told where to look. To give it a focal point, create a target entity (''base/target_null'') and place it near the center of the bulletin board. Give it the following Property/Value pair:<br />
<br />
* "name" "target_null_1"<br />
<br />
It's a good idea to use matching numbers in your camera/target pairs if you'll be using multiple cameras in a scene. There'll be less confusion as you develop your scene.<br />
<br />
To point the camera at its target, give Camera1 the following Property/Value pair:<br />
<br />
* "target" "target_null_1"<br />
<br />
For a stationary shot, this is all you need to do.<br />
{{clear}}<br />
<br />
==Camera Control==<br />
<br />
Camera control is done through scripting. If you're new to scripting, you can read [[A Beginner's Guide to Scripting]] to gain an understanding of the power of scripts.<br />
<br />
Let's look at the script that controls Camera1. Open ''snitch1.script'', which sits alongside ''snitch1.map'' in the ''snitch'' folder.<br />
<br />
If you haven't worked with scripts before, here's an overview of the file:<br />
<br />
<pre><br />
#ifndef __SNITCH_SCRIPT__<br />
#define __SNITCH_SCRIPT__<br />
<br />
void Roll1()<br />
{<br />
...<br />
}<br />
<br />
void Roll2()<br />
{<br />
...<br />
}<br />
<br />
...<br />
<br />
void main()<br />
{<br />
}<br />
<br />
#endif /* __SNITCH_SCRIPT__ */<br />
</pre><br />
Script parts:<br />
<br />
* The ''#ifndef, #define,'' and ''#endif'' directives prevent this script from being included more than once.<br />
<br />
* ''main()'' is a function (program, routine) executed once at the start of your map. Use it to initialize script-based activities.<br />
<br />
* Each ''RollN()'' is a function to be executed at some point as the player plays your map.<br />
<br />
Let's look at the function Roll1():<br />
<br />
<pre><br />
void Roll1()<br />
{<br />
sys.println("Roll1 running"); // debug<br />
<br />
$Camera1.activate($player1); // Switch view<br />
sys.wait(13); // duration of view<br />
<br />
$Camera1.activate($player1); // Return control to player<br />
}<br />
</pre><br />
<br />
What does each line do?<br />
<br />
* ''sys.println()'' prints a text line to the console. This is useful when you're unsure whether a particular function is executing or not.<br />
<br />
* ''$Camera1.activate($player1)'' triggers Camera1. ''$Camera1'' is the name of the entity, ''activate'' is what you want it to do (in this case, trigger), and ''$player1'' is the name of the entity triggering it. Triggering a camera removes control from the player and paints the screen with whatever the camera is looking at.<br />
<br />
* ''sys.wait(13)'' says to wait 13 seconds. So our shot is 13 seconds long.<br />
<br />
* The second ''$Camera1.activate($player1)'' deactivates the camera and returns control to the player.<br />
<br />
[[Image:target_callscriptfunction.jpg|200px|thumb|right|Roll1]]<br />
Now, how do we run this function? Find the ''info_player_start'' in the SW corner of the map. Next to it you'll see three buttons with three yellow cubes above them. Each cube is a ''darkmod/targets/atdm:target_callscriptfunction'' entity. Each button is targeted to activate one of these entities, which, in turn, calls a function in the script file.<br />
<br />
The leftmost ''target_callscriptfunction'' has these Property/Value pairs:<br />
<br />
* "name" "Roll1"<br />
<br />
* "call" "Roll1"<br />
<br />
So when you push the leftmost button, it triggers Roll1, which calls the function Roll1(). When you design your own scenes, you don't have to use buttons to get the cameras started. You can use any type of trigger targeted at a ''target_callscriptfunction'', or even a call from another script function, to get things moving.<br />
{{clear}}<br />
<br />
==Roll Camera 1==<br />
[[Image:Master Shot.jpg|200px|thumb|right|Establishing Shot]]<br />
Let's run what we have so far.<br />
<br />
* Save the map, build it, and run it.<br />
<br />
When the map starts, both actors will begin walking toward the bulletin board. (Don't worry about them attacking you; they're both on Team 0.) Once they've reached it, press the leftmost button on the wall to your right. Camera1 takes over and paints your Establishing Shot on the screen for 13 seconds. When it's finished, control returns to you.<br />
{{clear}}<br />
==Add a Second Camera==<br />
[[Image:Camera2.jpg|200px|thumb|right|Camera2]]<br />
<br />
There are two ''path_corners'' in front of the bulletin board. Create another ''func_cameraview'' and place it between the bulletin board and the top of the leftmost ''path_corner''. Give it the following Property/Value pairs:<br />
<br />
* "name" "Camera2"<br />
* "trigger" "1"<br />
<br />
Create another ''target_null'' and place it near the top of the rightmost ''path_corner''. Give it the following Property/Value pair:<br />
<br />
* "name" "target_null_2"<br />
<br />
Now point Camera2 at its target by giving it the following Property/Value pair:<br />
<br />
* "target" "target_null_2"<br />
<br />
Camera2 will give us a medium shot of the guard.<br />
<br />
Take a look at the middle button near the player start. It targets the middle ''target_callscriptfunction'', which calls the Roll2() script function:<br />
<br />
<pre><br />
void Roll2()<br />
{<br />
sys.println("Roll2 running"); // debug<br />
<br />
$Camera1.activate($player1); // Switch view<br />
sys.wait(5); // duration of view<br />
<br />
$Camera2.activate($player1); // Switch view<br />
sys.wait(5); // duration of view<br />
<br />
$Camera2.activate($player1); // Return control to player<br />
}<br />
</pre><br />
<br />
Roll2() rolls Camera1 for 5 seconds, rolls Camera2 for 5 seconds, then returns control to the player. <br />
{{clear}}<br />
==Roll Cameras 1 and 2==<br />
[[Image:Guard.jpg|200px|thumb|right|Medium Shot of Guard]]<br />
<br />
Save, build, and run the map. Once the actors are in place, press the middle button. A 5-second Establishing Shot will be followed by a 5-second medium shot of the guard. Note that the guard is backlit, so his face is dark. We'll take care of that later when we talk about lighting.<br />
{{clear}}<br />
<br />
==Add the Third and Fourth Cameras==<br />
[[Image:Camera3.jpg|200px|thumb|right|Camera3]]<br />
[[Image:Camera4.jpg|200px|thumb|right|Camera4]]<br />
<br />
Let's add a medium shot of the informant by placing Camera3 just behind the guard's shoulder and target_null_3 near the top of the leftmost path_corner.<br />
<br />
* Place a final camera, Camera4, near the western porch and place its target_null_4 near the player start. Remember to set the ''target'' property on each camera.<br />
<br />
The third ''target_callscriptfunction'' near the player start calls Roll3() in the script file. Looking at Roll3(), we see that it rolls Camera1 for 3 seconds, Camera2 for 7 seconds, Camera3 for 4 seconds, and Camera4 for 5 seconds.<br />
<br />
What's the purpose of Camera4? When Camera4's view comes on the screen, you'll see that the player is invisible. You know you're on that porch, because you just pushed the button. This invisibility allows the mapper to place the player anywhere in the scene. We'll see why this is important when we discuss sound later.<br />
<br />
* Save, build, run, and press button 3.<br />
{{clear}}<br />
==Wrapup==<br />
<br />
In Part 1, we've taken a look at placing stationary cameras in a scene, pointing them, passing control to them, and switching cameras.<br />
<br />
Alongside ''snitch1.map'' and ''snitch1.script'', which we've been using above, you'll find ''snitch1a.map'' and ''snitch1a.script'', which include the cameras and targets we've discussed. You can build and run ''snitch1a.map'' and compare it to your own work.<br />
<br />
Of course, you can go on and add more cameras to your map. Don't forget to change the ''*.script'' file!<br />
<br />
In Part 2, we'll investigate splines and how they're used for camera movement.<br />
<br />
<br />
{{Template: Cutscenes}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=Cutscenes&diff=19369Cutscenes2017-07-04T19:48:36Z<p>Taaaki: </p>
<hr />
<div>''Contributed by Grayman. Leave comments and questions [http://forums.thedarkmod.com/topic/11690-cutscene-wiki-page/ here].''<br />
<br />
This article discusses the use of cameras and conversations to create map cutscenes.<br />
<br />
Though information on these topics already exists, there isn't a single place that shows you how to create a scene using these features.<br />
<br />
Hopefully, the following will fill in that gap.<br />
<br />
Before you begin, you should have a basic understanding of how to edit with Dark Radiant, and how to build and run maps.<br />
<br />
'''Part 1: Cameras'''<br />
<br />
'''Part 2: Splines and Camera Movement'''<br />
<br />
'''Part 3: Lighting, Placing the Player, and Conversations'''<br />
<br />
'''Part 4: Extras'''<br />
<br />
'''Part 5: "Somewhere Above the City"'''<br />
<br />
{{Template: Cutscenes}}<br />
<br />
{{tutorial-editing|sort=Cutscenes}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics&diff=19122TDM Release Mechanics2017-03-12T12:58:15Z<p>Taaaki: /* Hotfixes */</p>
<hr />
<div>This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.<br />
<br />
The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:<br />
<br />
= Development = <br />
Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.<br />
<br />
= Branching off =<br />
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN. <br />
<br />
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right|350px]]<br />
* Update your darkmod working copy.<br />
* Update the darkmod_src repository too.<br />
* Right-click the darkmod folder to create the branch<br />
** Select SVN > Branch/Tag...<br />
** A new dialog appears asking for a URL. Enter a URL like this: [https://server/svn/darkmod/branches/release1.xx https://<darkmod_server_here>/svn/darkmod/branches/release1.xx] where xx is replaced by whatever version the next release will be. <br />
** You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.<br />
** Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).<br />
* The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme [https://server/svn/darkmod_src/branches/release1.xx https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx]<br />
<br />
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch. <br />
<br />
'''Important:''' commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.<br />
<br />
= Compile Game Binaries =<br />
Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile the tdm_gameNN.pk4 for you, or you can bite the bullet and follow the [[TDM Compilation Guide]] to compile it yourself. As Windows user, I recommend setting up an Ubuntu 10.04 32-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC. <br />
<br />
Make sure you compile a '''release build''' (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild Solution''<br />
* Linux: <tt>scons -c && scons BUILD="release" BUILD_GAMEPAK="1"</tt> <br />
<br />
Once compiled, make sure that the tdm_game01.pk4 is updated with the newly compiled DLL and the tdm_game02.pk4 is copied over from darkmod_src (where it is created after compilation) to darkmod and commit these two files ''to the branch''.<br />
<br />
Also commit TheDarkMod.exe and thedarkmod.x86 ''to the branch''.<br />
<br />
= Compile tdm_update =<br />
tdm_update must be built separately for both Windows and Linux.<br />
<br />
Make sure you compile a '''release build''', and recompile everything from scratch:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild tdm_update_mfc''<br />
* Linux: descend into the tdm_update directory and then do <tt>scons -c && scons BUILD="release"</tt><br />
<br />
Once compiled, copy the results into the darkmod folder:<br />
<br />
* Windows/VC++: bin/GuiUpdater/tdm_update.exe -> darkmod/tdm_update.exe<br />
* Linux: tdm_update.linux -> darkmod/tdm_update.linux<br />
<br />
Commit these ''to the branch''.<br />
<br />
= The Manifest =<br />
The "manifest" is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list. The manifest text file is located in the SVN repository: '''devel/manifests/darkmod.txt'''<br />
<br />
== Building the Manifest ==<br />
<br />
Note: This section is more or less for your understanding, '''you don't need to manually generate the manifest anymore''' as this step is part of the automated process running on the TDM server itself.<br />
<br />
The manifest file is generated by the tdm_package application. (The tdm_package sources are in the darkmod_src repository, in a subfolder called tdm_update. There is a VC++ 2010 solution and a sconscript for Linux and Mac builds available. You don't need to compile it if you're in Windows, there is a pre-compiled version in the darkmod repo as well, in the devel/packager folder.) <br />
<br />
After the generation step the file '''devel/manifests/darkmod.txt''' will have been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.<br />
<br />
== What is included in the Manifest ==<br />
The package application is using the file <tt>devel/manifests/darkmod_maps.txt</tt> to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:<br />
<br />
# Include all these files (but without parsing them like maps), each<br />
# statement will include files (from SVN) in that folder:<br />
INCLUDE def/<br />
INCLUDE dds/<br />
...<br />
INCLUDE video/<br />
INCLUDE xdata/<br />
As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.<br />
<br />
As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:<br />
EXCLUDE dds/darkmod/test<br />
In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:<br />
EXCLUDE models/md5/chars/undead/revenant/.*.md5anim<br />
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant<br />
The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant '''and''' the ones in '''dds/'''models/md5/chars/undead/revenant (the dds/ part is marked to be optional). <br />
<br />
In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.<br />
<br />
= Distribute files into PK4s =<br />
Each of the roughly 15000 files in the manifest needs to be sorted into the correct PK4. This is done by defining a rules in the file <tt>devel/manifests/darkmod_pk4s.txt</tt>. Each of the lines there defines a PK4 and which files go into it:<br />
# Miscellaneous stuff (GL Progs, Script, Language Files, Rope Arrow)<br />
tdm_base01.pk4: ^glprogs, ^script, ^strings, sound\.wav, _emptyname\.wav, ^models/md5/environments, ^dds/models/md5/environments, ...<br />
Again, lines starting with the sharp # character denote comments.<br />
<br />
Leftmost is the PK4 filename, followed by a colon character. To the right of the colon a list comma-separated patterns is defined, whereas each pattern is interpreted as regular expression. As with the <tt>darkmod_maps.txt</tt> you don't need to know very much about regular expressions to define those rules, it's usually enough to write the folder names and use wildcards like <tt>.*.md5anim</tt><br />
<br />
= Build the Package =<br />
The package is built right on the TDM server - there is a full darkmod repository checked out on the server's filesystem, and it will be processed through some scripts that are listening to your commands.<br />
<br />
Once triggered, the process goes roughly like this, I'll comment on these steps below:<br />
<br />
* The working copy is reverted, such that it is clean.<br />
* The working copy is switched to the release branch of the version you're about to release (it must exist at this point).<br />
* The working copy is implicitly updated by the switch operation.<br />
* The manifest is generated.<br />
* The full set of PK4 files is generated (it takes a while, the server CPU is not very powerful).<br />
* The differential package is generated.<br />
* The files are copied to a public folder reachable through HTTP such that it can be tested by the team. The team will test it by storing a manipulated tdm_mirrors.txt file next to their tdm_update application.<br />
<br />
== Prepare the packaging process ==<br />
A few steps need to be done before kicking off the process on the server.<br />
<br />
* The release branch must be created, with a specific naming convention: https://darkmod_server_here/svn/darkmod/branches/releaseY.XX where Y is the major version and XX is the two-digit minor version, e.g. "release1.08".<br />
* The inclusion statements in the <tt>darkmod_maps.txt</tt> file need to be up to date, make sure everything is committed to the branch.<br />
* The <tt>tdm_version.txt</tt> file should be containing the correct version number, it's located in <tt>devel/release/tdm_version.txt</tt>. Commit that change to the release branch, needless to say.<br />
<br />
== Kicking off the packaging process ==<br />
There is a special admin page on the server which can be used to kick off the process. The URL has been [http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/ posted on the forums before], greebo or grayman know the URL. It's password protected, so you'll be asked to enter credentials. Once there, you can enter the two version numbers, the one you're building, and the previous one (the latest released one). E.g.: 1.08 and 1.07. It's sufficient to enter the currently released one, e.g. 1.07, into the second field and the website will automatically fill in the next version number in the first field - you can override it if really necessary.<br />
<br />
Once you start the process you'll be presented a text window with some progress information, and you can watch the messages emitted by the svn client and the tdm_package application running on the server. It takes a while, about half an hour, until the package is built.<br />
<br />
= Prepare the internal package test =<br />
The team needs to have access to the package as created above for internal testing, so tell them to download a specially prepared tdm_mirrors.txt. You can find one attached to the first post here: http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/<br />
<br />
The linked post above already contains a few instructions you can copy from. Basically, instruct the team to use the <tt>--keep-mirrors</tt> switch when starting the tdm_update application, and to copy the tdm_mirrors.txt file into their test folder before running it. If the <tt>--keep-mirrors</tt> option is omitted the updater will connect to the regular TDM update mirrors, which is not the point.<br />
<br />
= The Test & Bugfix cycle =<br />
Once the testers post their bug reports, the dev team needs to get moving to fix them. It's recommended that all fixes will be committed to the trunk (both for darkmod and darkmod_src repos), and the release manager should merge the changes into the release branch.<br />
<br />
== Merge Fixes into the Release Branch ==<br />
Let's assume there is a fix that got committed to darkmod SVN in order to fix an issue discovered in the test package. Proceed like this to merge it to the release branch. <br />
* Make sure your local working copy is switched to the release branch. <br />
* Now right-click the darkmod folder and choose SVN > Merge<br />
* Select ''Merge a range of revisions''<br />
* As ''URL to merge from'' use the address of the trunk: [https://server/svn/darkmod/trunk https://<darkmod_server>/svn/darkmod/trunk]<br />
* In the field revision range to merge you need to specify which exact change you intend to merge. It's easier if you click the "Show Log" button right next to the entry field to view the SVN Log of the trunk. You can either select a single commit, or you can select a range of commits. Perhaps double-check the changes of that checkin.<br />
* Hit ''Next'', then ''Merge''.<br />
* Important: the changes will be incorporated into your ''working copy''. If you want these changes to actually be stored in the release branch, you need to perform the ''commit''.<br />
<br />
Special note for code changes: once these are committed to darkmod_src trunk, you need to merge them just like described above. Then you're going to recompile the game binaries (I recommend from scratch) and commit the tdm_game01.pk4 / tdm_game02.pk4 files to the darkmod release branch too.<br />
<br />
== Update the Test Package ==<br />
Re-package the TDM package, as described above. Just make sure everything is committed to the release branch and kick off another build process.<br />
<br />
== Test again ==<br />
Inform your testers about the update and which things got changed since the last test. Instruct them to update their test installation (don't forget to mention --keep-mirrors) and enter the next round of testing.<br />
<br />
= Release Time: Upload & Cleanup =<br />
Once the day has come to release the next version, connect to the TDM server using a secure shell (SSH) client, like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY].<br />
<br />
Follow these steps, there are some things that need to be done afterwards, they are necessary for the ''next'' release to function properly:<br />
<br />
* Rebuild binaries from scratch, place in darkmod folder, and commit the darkmod folder.<br />
* 7-zip the Windows gamex86.pdb and TheDarkMod.pdb files and place them in the trunk darkmod/devel/release/debugging/2.0x folder. Add that folder to SVN and commit it.<br />
* Update the darkmod 2.0x branch tree and merge the just-placed debugging files to that branch. Commit the 2.0x branch.<br />
* Create the final package remotely as described above (through the website). <br />
* The above step will generate a new crc_info.txt and a tdm_version_info.txt file on the server.<br />
* The packaging script will take care of checking these two files into SVN for "Release" packages.<br />
* Check in the newly generated manifest, it should still be in the folder where the packaging script left it. Note: The packaging script will check this file in automatically for "Release" packages.<br />
* Create a tag for the darkmod and darkmod_src repositories (/tags/2.0x) - copy it from the latest revision in the corresponding release branch.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy package from /usr/local/www/update.thedarkmod.com/ to /usr/local/tdm_releases/2.0x/ for archiving. The next package process will need it there.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy /usr/local/tdm_releases/1.05/index.html to /usr/local/tdm_releases/2.0x<br />
** The packaging script will perform this task for "Release" packages.<br />
* Move all differential packages back to /usr/local/www/update.thedarkmod.com/<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy the one differential update package updating to the new 2.0x version back to /usr/local/tdm_releases/2.0x. In the following line, (y = x-1).<br />
** The packaging script will perform this task for "Release" packages.<br />
* At this point, the /usr/local/tdm_releases/2.0x folder contains a valid TDM 2.0x release, the one that will be pushed to all the mirrors. Examine it for double safety.<br />
* Examine the upload_to_all_mirrors.sh shell script, to see if it fits your needs.<br />
* Start uploading to all mirrors.<br />
** <tt>./upload_to_all_mirrors.sh 2.0x</tt><br />
** Update the rsyncd config on update.thedarkmod.com to point to the new release folder (taaaki will need to do this).<br />
* Update tdm_mirrors.txt and tdm_version.xml on thedarkmod.com/update: ask taaaki to do that. The tdm_mirrors.txt file is probably fine, but the tdm_version.xml needs to be updated.<br />
<br />
== Update the Wiki ==<br />
<br />
The wiki contains one page for each release. You can find them all in the [[:Category:What's New]] category. <br />
<br />
First update the current release page:<br />
<br />
* Change the "roadmap" link on the current release to a "changelog" link by swapping ''"roadmap_page.php?version_id=XX"'' with ''"changelog_page.php?version=XX"''.<br />
* Add the ''<nowiki>{{released|2.01|2014-01-30}}</nowiki>'' Template on top of the current release page with the correct date.<br />
<br />
Then add a new page for the next release. To do this, add a link to it in this template: [[Template:Whatsnew]] by editing it. After saving the template, a link to the new release version page appears in the list and in the category. Edit this page and insert some text into it (you can copy it from an older release page).<br />
<br />
Also insert a link to the current roadmap on the bugtracker, you can find out the version_id by looking at [http://bugs.thedarkmod.com/roadmap_page.php the roadmap page].<br />
<br />
== Update the Website ==<br />
<br />
Be sure to update the following pages on the website to reflect the latest release version:<br />
* [http://www.thedarkmod.com/downloads/ http://www.thedarkmod.com/downloads/]<br />
* [http://www.thedarkmod.com/download-the-mod/ http://www.thedarkmod.com/download-the-mod/]<br />
* [http://www.thedarkmod.com/download-sourcecode/ http://www.thedarkmod.com/download-sourcecode/]<br />
<br />
To generate the latest source code package for the page above:<br />
* Check out the code from the release tag. E.g. svn checkout https://svn.thedarkmod.com/svn/darkmod_src/tags/x.yy<br />
* Remove (or exclude) the .svn from the working copy folder<br />
* Create a 7zip archive with the following naming convention: thedarkmod.x.yy.src.7z<br />
** 7z a -r ../thedarkmod.x.yy.src.7z ./* <br />
* Upload the source code archive to http://www.thedarkmod.com/sources (ask taaaki for assistance with this or use the ftp upload user)<br />
<br />
== Hotfixes ==<br />
In the event of game-breaking bugs making it into the release, it is possible to rebuild the release with the same version number. This should only be done when absolutely necessary. The process is essentially as follows:<br />
* Merge the bug fixes into the current release branch (include the recompiled binaries).<br />
* Re-run the "Testing" package build and test the updated release from http://update.thedarkmod.com/testing/<br />
* If all is in order, proceed to generate the "Release" package as above and deploy the updated release to the mirrors.<br />
** Note: it may be necessary to tweak the create_package.sh file to exclude the creation of the release tag - be sure to revert back to the original after the hotfix process has been completed (TODO: an additional option should be added to the release management screen to handle with automatically).<br />
** Manually create a new release tag for darkmod/ and darkmod_src/ (E.g. darkmod/tags/2.05hotfix and darkmod_src/tags/2.05hotfix repectively).<br />
** Update the source code package and re-upload to the website if necessary.<br />
<br />
= Glossary =<br />
* Release Fileset: the PK4 files forming the actual release. <br />
* SVN: an acronym for Subversion, a version control system<br />
* Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.<br />
* Mirrors: The servers where the PK4 files are stored for download by the updater.<br />
* updater: The TDM Updater executable, used for downloading and updating TDM.<br />
* binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).<br />
* darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.<br />
* branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.<br />
* trunk: The main branch where all the ongoing development is happening.<br />
<br />
{{todo}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics&diff=19121TDM Release Mechanics2017-03-12T12:57:13Z<p>Taaaki: /* Update the Website */</p>
<hr />
<div>This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.<br />
<br />
The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:<br />
<br />
= Development = <br />
Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.<br />
<br />
= Branching off =<br />
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN. <br />
<br />
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right|350px]]<br />
* Update your darkmod working copy.<br />
* Update the darkmod_src repository too.<br />
* Right-click the darkmod folder to create the branch<br />
** Select SVN > Branch/Tag...<br />
** A new dialog appears asking for a URL. Enter a URL like this: [https://server/svn/darkmod/branches/release1.xx https://<darkmod_server_here>/svn/darkmod/branches/release1.xx] where xx is replaced by whatever version the next release will be. <br />
** You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.<br />
** Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).<br />
* The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme [https://server/svn/darkmod_src/branches/release1.xx https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx]<br />
<br />
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch. <br />
<br />
'''Important:''' commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.<br />
<br />
= Compile Game Binaries =<br />
Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile the tdm_gameNN.pk4 for you, or you can bite the bullet and follow the [[TDM Compilation Guide]] to compile it yourself. As Windows user, I recommend setting up an Ubuntu 10.04 32-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC. <br />
<br />
Make sure you compile a '''release build''' (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild Solution''<br />
* Linux: <tt>scons -c && scons BUILD="release" BUILD_GAMEPAK="1"</tt> <br />
<br />
Once compiled, make sure that the tdm_game01.pk4 is updated with the newly compiled DLL and the tdm_game02.pk4 is copied over from darkmod_src (where it is created after compilation) to darkmod and commit these two files ''to the branch''.<br />
<br />
Also commit TheDarkMod.exe and thedarkmod.x86 ''to the branch''.<br />
<br />
= Compile tdm_update =<br />
tdm_update must be built separately for both Windows and Linux.<br />
<br />
Make sure you compile a '''release build''', and recompile everything from scratch:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild tdm_update_mfc''<br />
* Linux: descend into the tdm_update directory and then do <tt>scons -c && scons BUILD="release"</tt><br />
<br />
Once compiled, copy the results into the darkmod folder:<br />
<br />
* Windows/VC++: bin/GuiUpdater/tdm_update.exe -> darkmod/tdm_update.exe<br />
* Linux: tdm_update.linux -> darkmod/tdm_update.linux<br />
<br />
Commit these ''to the branch''.<br />
<br />
= The Manifest =<br />
The "manifest" is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list. The manifest text file is located in the SVN repository: '''devel/manifests/darkmod.txt'''<br />
<br />
== Building the Manifest ==<br />
<br />
Note: This section is more or less for your understanding, '''you don't need to manually generate the manifest anymore''' as this step is part of the automated process running on the TDM server itself.<br />
<br />
The manifest file is generated by the tdm_package application. (The tdm_package sources are in the darkmod_src repository, in a subfolder called tdm_update. There is a VC++ 2010 solution and a sconscript for Linux and Mac builds available. You don't need to compile it if you're in Windows, there is a pre-compiled version in the darkmod repo as well, in the devel/packager folder.) <br />
<br />
After the generation step the file '''devel/manifests/darkmod.txt''' will have been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.<br />
<br />
== What is included in the Manifest ==<br />
The package application is using the file <tt>devel/manifests/darkmod_maps.txt</tt> to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:<br />
<br />
# Include all these files (but without parsing them like maps), each<br />
# statement will include files (from SVN) in that folder:<br />
INCLUDE def/<br />
INCLUDE dds/<br />
...<br />
INCLUDE video/<br />
INCLUDE xdata/<br />
As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.<br />
<br />
As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:<br />
EXCLUDE dds/darkmod/test<br />
In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:<br />
EXCLUDE models/md5/chars/undead/revenant/.*.md5anim<br />
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant<br />
The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant '''and''' the ones in '''dds/'''models/md5/chars/undead/revenant (the dds/ part is marked to be optional). <br />
<br />
In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.<br />
<br />
= Distribute files into PK4s =<br />
Each of the roughly 15000 files in the manifest needs to be sorted into the correct PK4. This is done by defining a rules in the file <tt>devel/manifests/darkmod_pk4s.txt</tt>. Each of the lines there defines a PK4 and which files go into it:<br />
# Miscellaneous stuff (GL Progs, Script, Language Files, Rope Arrow)<br />
tdm_base01.pk4: ^glprogs, ^script, ^strings, sound\.wav, _emptyname\.wav, ^models/md5/environments, ^dds/models/md5/environments, ...<br />
Again, lines starting with the sharp # character denote comments.<br />
<br />
Leftmost is the PK4 filename, followed by a colon character. To the right of the colon a list comma-separated patterns is defined, whereas each pattern is interpreted as regular expression. As with the <tt>darkmod_maps.txt</tt> you don't need to know very much about regular expressions to define those rules, it's usually enough to write the folder names and use wildcards like <tt>.*.md5anim</tt><br />
<br />
= Build the Package =<br />
The package is built right on the TDM server - there is a full darkmod repository checked out on the server's filesystem, and it will be processed through some scripts that are listening to your commands.<br />
<br />
Once triggered, the process goes roughly like this, I'll comment on these steps below:<br />
<br />
* The working copy is reverted, such that it is clean.<br />
* The working copy is switched to the release branch of the version you're about to release (it must exist at this point).<br />
* The working copy is implicitly updated by the switch operation.<br />
* The manifest is generated.<br />
* The full set of PK4 files is generated (it takes a while, the server CPU is not very powerful).<br />
* The differential package is generated.<br />
* The files are copied to a public folder reachable through HTTP such that it can be tested by the team. The team will test it by storing a manipulated tdm_mirrors.txt file next to their tdm_update application.<br />
<br />
== Prepare the packaging process ==<br />
A few steps need to be done before kicking off the process on the server.<br />
<br />
* The release branch must be created, with a specific naming convention: https://darkmod_server_here/svn/darkmod/branches/releaseY.XX where Y is the major version and XX is the two-digit minor version, e.g. "release1.08".<br />
* The inclusion statements in the <tt>darkmod_maps.txt</tt> file need to be up to date, make sure everything is committed to the branch.<br />
* The <tt>tdm_version.txt</tt> file should be containing the correct version number, it's located in <tt>devel/release/tdm_version.txt</tt>. Commit that change to the release branch, needless to say.<br />
<br />
== Kicking off the packaging process ==<br />
There is a special admin page on the server which can be used to kick off the process. The URL has been [http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/ posted on the forums before], greebo or grayman know the URL. It's password protected, so you'll be asked to enter credentials. Once there, you can enter the two version numbers, the one you're building, and the previous one (the latest released one). E.g.: 1.08 and 1.07. It's sufficient to enter the currently released one, e.g. 1.07, into the second field and the website will automatically fill in the next version number in the first field - you can override it if really necessary.<br />
<br />
Once you start the process you'll be presented a text window with some progress information, and you can watch the messages emitted by the svn client and the tdm_package application running on the server. It takes a while, about half an hour, until the package is built.<br />
<br />
= Prepare the internal package test =<br />
The team needs to have access to the package as created above for internal testing, so tell them to download a specially prepared tdm_mirrors.txt. You can find one attached to the first post here: http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/<br />
<br />
The linked post above already contains a few instructions you can copy from. Basically, instruct the team to use the <tt>--keep-mirrors</tt> switch when starting the tdm_update application, and to copy the tdm_mirrors.txt file into their test folder before running it. If the <tt>--keep-mirrors</tt> option is omitted the updater will connect to the regular TDM update mirrors, which is not the point.<br />
<br />
= The Test & Bugfix cycle =<br />
Once the testers post their bug reports, the dev team needs to get moving to fix them. It's recommended that all fixes will be committed to the trunk (both for darkmod and darkmod_src repos), and the release manager should merge the changes into the release branch.<br />
<br />
== Merge Fixes into the Release Branch ==<br />
Let's assume there is a fix that got committed to darkmod SVN in order to fix an issue discovered in the test package. Proceed like this to merge it to the release branch. <br />
* Make sure your local working copy is switched to the release branch. <br />
* Now right-click the darkmod folder and choose SVN > Merge<br />
* Select ''Merge a range of revisions''<br />
* As ''URL to merge from'' use the address of the trunk: [https://server/svn/darkmod/trunk https://<darkmod_server>/svn/darkmod/trunk]<br />
* In the field revision range to merge you need to specify which exact change you intend to merge. It's easier if you click the "Show Log" button right next to the entry field to view the SVN Log of the trunk. You can either select a single commit, or you can select a range of commits. Perhaps double-check the changes of that checkin.<br />
* Hit ''Next'', then ''Merge''.<br />
* Important: the changes will be incorporated into your ''working copy''. If you want these changes to actually be stored in the release branch, you need to perform the ''commit''.<br />
<br />
Special note for code changes: once these are committed to darkmod_src trunk, you need to merge them just like described above. Then you're going to recompile the game binaries (I recommend from scratch) and commit the tdm_game01.pk4 / tdm_game02.pk4 files to the darkmod release branch too.<br />
<br />
== Update the Test Package ==<br />
Re-package the TDM package, as described above. Just make sure everything is committed to the release branch and kick off another build process.<br />
<br />
== Test again ==<br />
Inform your testers about the update and which things got changed since the last test. Instruct them to update their test installation (don't forget to mention --keep-mirrors) and enter the next round of testing.<br />
<br />
= Release Time: Upload & Cleanup =<br />
Once the day has come to release the next version, connect to the TDM server using a secure shell (SSH) client, like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY].<br />
<br />
Follow these steps, there are some things that need to be done afterwards, they are necessary for the ''next'' release to function properly:<br />
<br />
* Rebuild binaries from scratch, place in darkmod folder, and commit the darkmod folder.<br />
* 7-zip the Windows gamex86.pdb and TheDarkMod.pdb files and place them in the trunk darkmod/devel/release/debugging/2.0x folder. Add that folder to SVN and commit it.<br />
* Update the darkmod 2.0x branch tree and merge the just-placed debugging files to that branch. Commit the 2.0x branch.<br />
* Create the final package remotely as described above (through the website). <br />
* The above step will generate a new crc_info.txt and a tdm_version_info.txt file on the server.<br />
* The packaging script will take care of checking these two files into SVN for "Release" packages.<br />
* Check in the newly generated manifest, it should still be in the folder where the packaging script left it. Note: The packaging script will check this file in automatically for "Release" packages.<br />
* Create a tag for the darkmod and darkmod_src repositories (/tags/2.0x) - copy it from the latest revision in the corresponding release branch.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy package from /usr/local/www/update.thedarkmod.com/ to /usr/local/tdm_releases/2.0x/ for archiving. The next package process will need it there.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy /usr/local/tdm_releases/1.05/index.html to /usr/local/tdm_releases/2.0x<br />
** The packaging script will perform this task for "Release" packages.<br />
* Move all differential packages back to /usr/local/www/update.thedarkmod.com/<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy the one differential update package updating to the new 2.0x version back to /usr/local/tdm_releases/2.0x. In the following line, (y = x-1).<br />
** The packaging script will perform this task for "Release" packages.<br />
* At this point, the /usr/local/tdm_releases/2.0x folder contains a valid TDM 2.0x release, the one that will be pushed to all the mirrors. Examine it for double safety.<br />
* Examine the upload_to_all_mirrors.sh shell script, to see if it fits your needs.<br />
* Start uploading to all mirrors.<br />
** <tt>./upload_to_all_mirrors.sh 2.0x</tt><br />
** Update the rsyncd config on update.thedarkmod.com to point to the new release folder (taaaki will need to do this).<br />
* Update tdm_mirrors.txt and tdm_version.xml on thedarkmod.com/update: ask taaaki to do that. The tdm_mirrors.txt file is probably fine, but the tdm_version.xml needs to be updated.<br />
<br />
== Update the Wiki ==<br />
<br />
The wiki contains one page for each release. You can find them all in the [[:Category:What's New]] category. <br />
<br />
First update the current release page:<br />
<br />
* Change the "roadmap" link on the current release to a "changelog" link by swapping ''"roadmap_page.php?version_id=XX"'' with ''"changelog_page.php?version=XX"''.<br />
* Add the ''<nowiki>{{released|2.01|2014-01-30}}</nowiki>'' Template on top of the current release page with the correct date.<br />
<br />
Then add a new page for the next release. To do this, add a link to it in this template: [[Template:Whatsnew]] by editing it. After saving the template, a link to the new release version page appears in the list and in the category. Edit this page and insert some text into it (you can copy it from an older release page).<br />
<br />
Also insert a link to the current roadmap on the bugtracker, you can find out the version_id by looking at [http://bugs.thedarkmod.com/roadmap_page.php the roadmap page].<br />
<br />
== Update the Website ==<br />
<br />
Be sure to update the following pages on the website to reflect the latest release version:<br />
* [http://www.thedarkmod.com/downloads/ http://www.thedarkmod.com/downloads/]<br />
* [http://www.thedarkmod.com/download-the-mod/ http://www.thedarkmod.com/download-the-mod/]<br />
* [http://www.thedarkmod.com/download-sourcecode/ http://www.thedarkmod.com/download-sourcecode/]<br />
<br />
To generate the latest source code package for the page above:<br />
* Check out the code from the release tag. E.g. svn checkout https://svn.thedarkmod.com/svn/darkmod_src/tags/x.yy<br />
* Remove (or exclude) the .svn from the working copy folder<br />
* Create a 7zip archive with the following naming convention: thedarkmod.x.yy.src.7z<br />
** 7z a -r ../thedarkmod.x.yy.src.7z ./* <br />
* Upload the source code archive to http://www.thedarkmod.com/sources (ask taaaki for assistance with this or use the ftp upload user)<br />
<br />
== Hotfixes ==<br />
In the event of game-breaking bugs making it into the release, it is possible to rebuild the release with the same version number. This should only be done when absolutely necessary. The process is essentially as follows:<br />
* Merge the bug fixes into the current release branch (include the recompiled binaries).<br />
* Re-run the "Testing" package build and test the updated release from http://update.thedarkmod.com/testing/<br />
* If all is in order, proceed to generate the "Release" package as above and deploy the updated release to the mirrors.<br />
** Note: it may be necessary to tweak the create_package.sh file to exclude the creation of the release tag (TODO: an additional option should be added to the release management screen to handle with automatically).<br />
** Manually create a new release tag for darkmod/ and darkmod_src/ (E.g. darkmod/tags/2.05hotfix and darkmod_src/tags/2.05hotfix repectively).<br />
** Update the source code package and re-upload to the website if necessary.<br />
<br />
= Glossary =<br />
* Release Fileset: the PK4 files forming the actual release. <br />
* SVN: an acronym for Subversion, a version control system<br />
* Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.<br />
* Mirrors: The servers where the PK4 files are stored for download by the updater.<br />
* updater: The TDM Updater executable, used for downloading and updating TDM.<br />
* binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).<br />
* darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.<br />
* branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.<br />
* trunk: The main branch where all the ongoing development is happening.<br />
<br />
{{todo}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics&diff=19120TDM Release Mechanics2017-03-12T12:55:37Z<p>Taaaki: </p>
<hr />
<div>This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.<br />
<br />
The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:<br />
<br />
= Development = <br />
Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.<br />
<br />
= Branching off =<br />
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN. <br />
<br />
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right|350px]]<br />
* Update your darkmod working copy.<br />
* Update the darkmod_src repository too.<br />
* Right-click the darkmod folder to create the branch<br />
** Select SVN > Branch/Tag...<br />
** A new dialog appears asking for a URL. Enter a URL like this: [https://server/svn/darkmod/branches/release1.xx https://<darkmod_server_here>/svn/darkmod/branches/release1.xx] where xx is replaced by whatever version the next release will be. <br />
** You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.<br />
** Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).<br />
* The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme [https://server/svn/darkmod_src/branches/release1.xx https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx]<br />
<br />
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch. <br />
<br />
'''Important:''' commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.<br />
<br />
= Compile Game Binaries =<br />
Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile the tdm_gameNN.pk4 for you, or you can bite the bullet and follow the [[TDM Compilation Guide]] to compile it yourself. As Windows user, I recommend setting up an Ubuntu 10.04 32-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC. <br />
<br />
Make sure you compile a '''release build''' (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild Solution''<br />
* Linux: <tt>scons -c && scons BUILD="release" BUILD_GAMEPAK="1"</tt> <br />
<br />
Once compiled, make sure that the tdm_game01.pk4 is updated with the newly compiled DLL and the tdm_game02.pk4 is copied over from darkmod_src (where it is created after compilation) to darkmod and commit these two files ''to the branch''.<br />
<br />
Also commit TheDarkMod.exe and thedarkmod.x86 ''to the branch''.<br />
<br />
= Compile tdm_update =<br />
tdm_update must be built separately for both Windows and Linux.<br />
<br />
Make sure you compile a '''release build''', and recompile everything from scratch:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild tdm_update_mfc''<br />
* Linux: descend into the tdm_update directory and then do <tt>scons -c && scons BUILD="release"</tt><br />
<br />
Once compiled, copy the results into the darkmod folder:<br />
<br />
* Windows/VC++: bin/GuiUpdater/tdm_update.exe -> darkmod/tdm_update.exe<br />
* Linux: tdm_update.linux -> darkmod/tdm_update.linux<br />
<br />
Commit these ''to the branch''.<br />
<br />
= The Manifest =<br />
The "manifest" is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list. The manifest text file is located in the SVN repository: '''devel/manifests/darkmod.txt'''<br />
<br />
== Building the Manifest ==<br />
<br />
Note: This section is more or less for your understanding, '''you don't need to manually generate the manifest anymore''' as this step is part of the automated process running on the TDM server itself.<br />
<br />
The manifest file is generated by the tdm_package application. (The tdm_package sources are in the darkmod_src repository, in a subfolder called tdm_update. There is a VC++ 2010 solution and a sconscript for Linux and Mac builds available. You don't need to compile it if you're in Windows, there is a pre-compiled version in the darkmod repo as well, in the devel/packager folder.) <br />
<br />
After the generation step the file '''devel/manifests/darkmod.txt''' will have been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.<br />
<br />
== What is included in the Manifest ==<br />
The package application is using the file <tt>devel/manifests/darkmod_maps.txt</tt> to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:<br />
<br />
# Include all these files (but without parsing them like maps), each<br />
# statement will include files (from SVN) in that folder:<br />
INCLUDE def/<br />
INCLUDE dds/<br />
...<br />
INCLUDE video/<br />
INCLUDE xdata/<br />
As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.<br />
<br />
As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:<br />
EXCLUDE dds/darkmod/test<br />
In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:<br />
EXCLUDE models/md5/chars/undead/revenant/.*.md5anim<br />
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant<br />
The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant '''and''' the ones in '''dds/'''models/md5/chars/undead/revenant (the dds/ part is marked to be optional). <br />
<br />
In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.<br />
<br />
= Distribute files into PK4s =<br />
Each of the roughly 15000 files in the manifest needs to be sorted into the correct PK4. This is done by defining a rules in the file <tt>devel/manifests/darkmod_pk4s.txt</tt>. Each of the lines there defines a PK4 and which files go into it:<br />
# Miscellaneous stuff (GL Progs, Script, Language Files, Rope Arrow)<br />
tdm_base01.pk4: ^glprogs, ^script, ^strings, sound\.wav, _emptyname\.wav, ^models/md5/environments, ^dds/models/md5/environments, ...<br />
Again, lines starting with the sharp # character denote comments.<br />
<br />
Leftmost is the PK4 filename, followed by a colon character. To the right of the colon a list comma-separated patterns is defined, whereas each pattern is interpreted as regular expression. As with the <tt>darkmod_maps.txt</tt> you don't need to know very much about regular expressions to define those rules, it's usually enough to write the folder names and use wildcards like <tt>.*.md5anim</tt><br />
<br />
= Build the Package =<br />
The package is built right on the TDM server - there is a full darkmod repository checked out on the server's filesystem, and it will be processed through some scripts that are listening to your commands.<br />
<br />
Once triggered, the process goes roughly like this, I'll comment on these steps below:<br />
<br />
* The working copy is reverted, such that it is clean.<br />
* The working copy is switched to the release branch of the version you're about to release (it must exist at this point).<br />
* The working copy is implicitly updated by the switch operation.<br />
* The manifest is generated.<br />
* The full set of PK4 files is generated (it takes a while, the server CPU is not very powerful).<br />
* The differential package is generated.<br />
* The files are copied to a public folder reachable through HTTP such that it can be tested by the team. The team will test it by storing a manipulated tdm_mirrors.txt file next to their tdm_update application.<br />
<br />
== Prepare the packaging process ==<br />
A few steps need to be done before kicking off the process on the server.<br />
<br />
* The release branch must be created, with a specific naming convention: https://darkmod_server_here/svn/darkmod/branches/releaseY.XX where Y is the major version and XX is the two-digit minor version, e.g. "release1.08".<br />
* The inclusion statements in the <tt>darkmod_maps.txt</tt> file need to be up to date, make sure everything is committed to the branch.<br />
* The <tt>tdm_version.txt</tt> file should be containing the correct version number, it's located in <tt>devel/release/tdm_version.txt</tt>. Commit that change to the release branch, needless to say.<br />
<br />
== Kicking off the packaging process ==<br />
There is a special admin page on the server which can be used to kick off the process. The URL has been [http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/ posted on the forums before], greebo or grayman know the URL. It's password protected, so you'll be asked to enter credentials. Once there, you can enter the two version numbers, the one you're building, and the previous one (the latest released one). E.g.: 1.08 and 1.07. It's sufficient to enter the currently released one, e.g. 1.07, into the second field and the website will automatically fill in the next version number in the first field - you can override it if really necessary.<br />
<br />
Once you start the process you'll be presented a text window with some progress information, and you can watch the messages emitted by the svn client and the tdm_package application running on the server. It takes a while, about half an hour, until the package is built.<br />
<br />
= Prepare the internal package test =<br />
The team needs to have access to the package as created above for internal testing, so tell them to download a specially prepared tdm_mirrors.txt. You can find one attached to the first post here: http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/<br />
<br />
The linked post above already contains a few instructions you can copy from. Basically, instruct the team to use the <tt>--keep-mirrors</tt> switch when starting the tdm_update application, and to copy the tdm_mirrors.txt file into their test folder before running it. If the <tt>--keep-mirrors</tt> option is omitted the updater will connect to the regular TDM update mirrors, which is not the point.<br />
<br />
= The Test & Bugfix cycle =<br />
Once the testers post their bug reports, the dev team needs to get moving to fix them. It's recommended that all fixes will be committed to the trunk (both for darkmod and darkmod_src repos), and the release manager should merge the changes into the release branch.<br />
<br />
== Merge Fixes into the Release Branch ==<br />
Let's assume there is a fix that got committed to darkmod SVN in order to fix an issue discovered in the test package. Proceed like this to merge it to the release branch. <br />
* Make sure your local working copy is switched to the release branch. <br />
* Now right-click the darkmod folder and choose SVN > Merge<br />
* Select ''Merge a range of revisions''<br />
* As ''URL to merge from'' use the address of the trunk: [https://server/svn/darkmod/trunk https://<darkmod_server>/svn/darkmod/trunk]<br />
* In the field revision range to merge you need to specify which exact change you intend to merge. It's easier if you click the "Show Log" button right next to the entry field to view the SVN Log of the trunk. You can either select a single commit, or you can select a range of commits. Perhaps double-check the changes of that checkin.<br />
* Hit ''Next'', then ''Merge''.<br />
* Important: the changes will be incorporated into your ''working copy''. If you want these changes to actually be stored in the release branch, you need to perform the ''commit''.<br />
<br />
Special note for code changes: once these are committed to darkmod_src trunk, you need to merge them just like described above. Then you're going to recompile the game binaries (I recommend from scratch) and commit the tdm_game01.pk4 / tdm_game02.pk4 files to the darkmod release branch too.<br />
<br />
== Update the Test Package ==<br />
Re-package the TDM package, as described above. Just make sure everything is committed to the release branch and kick off another build process.<br />
<br />
== Test again ==<br />
Inform your testers about the update and which things got changed since the last test. Instruct them to update their test installation (don't forget to mention --keep-mirrors) and enter the next round of testing.<br />
<br />
= Release Time: Upload & Cleanup =<br />
Once the day has come to release the next version, connect to the TDM server using a secure shell (SSH) client, like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY].<br />
<br />
Follow these steps, there are some things that need to be done afterwards, they are necessary for the ''next'' release to function properly:<br />
<br />
* Rebuild binaries from scratch, place in darkmod folder, and commit the darkmod folder.<br />
* 7-zip the Windows gamex86.pdb and TheDarkMod.pdb files and place them in the trunk darkmod/devel/release/debugging/2.0x folder. Add that folder to SVN and commit it.<br />
* Update the darkmod 2.0x branch tree and merge the just-placed debugging files to that branch. Commit the 2.0x branch.<br />
* Create the final package remotely as described above (through the website). <br />
* The above step will generate a new crc_info.txt and a tdm_version_info.txt file on the server.<br />
* The packaging script will take care of checking these two files into SVN for "Release" packages.<br />
* Check in the newly generated manifest, it should still be in the folder where the packaging script left it. Note: The packaging script will check this file in automatically for "Release" packages.<br />
* Create a tag for the darkmod and darkmod_src repositories (/tags/2.0x) - copy it from the latest revision in the corresponding release branch.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy package from /usr/local/www/update.thedarkmod.com/ to /usr/local/tdm_releases/2.0x/ for archiving. The next package process will need it there.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy /usr/local/tdm_releases/1.05/index.html to /usr/local/tdm_releases/2.0x<br />
** The packaging script will perform this task for "Release" packages.<br />
* Move all differential packages back to /usr/local/www/update.thedarkmod.com/<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy the one differential update package updating to the new 2.0x version back to /usr/local/tdm_releases/2.0x. In the following line, (y = x-1).<br />
** The packaging script will perform this task for "Release" packages.<br />
* At this point, the /usr/local/tdm_releases/2.0x folder contains a valid TDM 2.0x release, the one that will be pushed to all the mirrors. Examine it for double safety.<br />
* Examine the upload_to_all_mirrors.sh shell script, to see if it fits your needs.<br />
* Start uploading to all mirrors.<br />
** <tt>./upload_to_all_mirrors.sh 2.0x</tt><br />
** Update the rsyncd config on update.thedarkmod.com to point to the new release folder (taaaki will need to do this).<br />
* Update tdm_mirrors.txt and tdm_version.xml on thedarkmod.com/update: ask taaaki to do that. The tdm_mirrors.txt file is probably fine, but the tdm_version.xml needs to be updated.<br />
<br />
== Update the Wiki ==<br />
<br />
The wiki contains one page for each release. You can find them all in the [[:Category:What's New]] category. <br />
<br />
First update the current release page:<br />
<br />
* Change the "roadmap" link on the current release to a "changelog" link by swapping ''"roadmap_page.php?version_id=XX"'' with ''"changelog_page.php?version=XX"''.<br />
* Add the ''<nowiki>{{released|2.01|2014-01-30}}</nowiki>'' Template on top of the current release page with the correct date.<br />
<br />
Then add a new page for the next release. To do this, add a link to it in this template: [[Template:Whatsnew]] by editing it. After saving the template, a link to the new release version page appears in the list and in the category. Edit this page and insert some text into it (you can copy it from an older release page).<br />
<br />
Also insert a link to the current roadmap on the bugtracker, you can find out the version_id by looking at [http://bugs.thedarkmod.com/roadmap_page.php the roadmap page].<br />
<br />
== Update the Website ==<br />
<br />
Be sure to update the following pages on the website to reflect the latest release version:<br />
* [http://www.thedarkmod.com/downloads/]<br />
* [http://www.thedarkmod.com/download-the-mod/]<br />
* [http://www.thedarkmod.com/download-sourcecode/]<br />
<br />
To generate the latest source code package for the page above:<br />
* Check out the code from the release tag. E.g. svn checkout https://svn.thedarkmod.com/svn/darkmod_src/tags/x.yy<br />
* Remove (or exclude) the .svn from the working copy folder<br />
* Create a 7zip archive with the following naming convention: thedarkmod.x.yy.src.7z<br />
** 7z a -r ../thedarkmod.x.yy.src.7z ./* <br />
* Upload the source code archive to http://www.thedarkmod.com/sources (ask taaaki for assistance with this or use the ftp upload user)<br />
<br />
== Hotfixes ==<br />
In the event of game-breaking bugs making it into the release, it is possible to rebuild the release with the same version number. This should only be done when absolutely necessary. The process is essentially as follows:<br />
* Merge the bug fixes into the current release branch (include the recompiled binaries).<br />
* Re-run the "Testing" package build and test the updated release from http://update.thedarkmod.com/testing/<br />
* If all is in order, proceed to generate the "Release" package as above and deploy the updated release to the mirrors.<br />
** Note: it may be necessary to tweak the create_package.sh file to exclude the creation of the release tag (TODO: an additional option should be added to the release management screen to handle with automatically).<br />
** Manually create a new release tag for darkmod/ and darkmod_src/ (E.g. darkmod/tags/2.05hotfix and darkmod_src/tags/2.05hotfix repectively).<br />
** Update the source code package and re-upload to the website if necessary.<br />
<br />
= Glossary =<br />
* Release Fileset: the PK4 files forming the actual release. <br />
* SVN: an acronym for Subversion, a version control system<br />
* Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.<br />
* Mirrors: The servers where the PK4 files are stored for download by the updater.<br />
* updater: The TDM Updater executable, used for downloading and updating TDM.<br />
* binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).<br />
* darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.<br />
* branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.<br />
* trunk: The main branch where all the ongoing development is happening.<br />
<br />
{{todo}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics&diff=19118TDM Release Mechanics2017-03-10T21:58:26Z<p>Taaaki: /* Release Time: Upload & Cleanup */</p>
<hr />
<div>This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.<br />
<br />
The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:<br />
<br />
= Development = <br />
Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.<br />
<br />
= Branching off =<br />
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN. <br />
<br />
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right|350px]]<br />
* Update your darkmod working copy.<br />
* Update the darkmod_src repository too.<br />
* Right-click the darkmod folder to create the branch<br />
** Select SVN > Branch/Tag...<br />
** A new dialog appears asking for a URL. Enter a URL like this: [https://server/svn/darkmod/branches/release1.xx https://<darkmod_server_here>/svn/darkmod/branches/release1.xx] where xx is replaced by whatever version the next release will be. <br />
** You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.<br />
** Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).<br />
* The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme [https://server/svn/darkmod_src/branches/release1.xx https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx]<br />
<br />
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch. <br />
<br />
'''Important:''' commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.<br />
<br />
= Compile Game Binaries =<br />
Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile the tdm_gameNN.pk4 for you, or you can bite the bullet and follow the [[TDM Compilation Guide]] to compile it yourself. As Windows user, I recommend setting up an Ubuntu 10.04 32-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC. <br />
<br />
Make sure you compile a '''release build''' (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild Solution''<br />
* Linux: <tt>scons -c && scons BUILD="release" BUILD_GAMEPAK="1"</tt> <br />
<br />
Once compiled, make sure that the tdm_game01.pk4 is updated with the newly compiled DLL and the tdm_game02.pk4 is copied over from darkmod_src (where it is created after compilation) to darkmod and commit these two files ''to the branch''.<br />
<br />
Also commit TheDarkMod.exe and thedarkmod.x86 ''to the branch''.<br />
<br />
= Compile tdm_update =<br />
tdm_update must be built separately for both Windows and Linux.<br />
<br />
Make sure you compile a '''release build''', and recompile everything from scratch:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild tdm_update_mfc''<br />
* Linux: descend into the tdm_update directory and then do <tt>scons -c && scons BUILD="release"</tt><br />
<br />
Once compiled, copy the results into the darkmod folder:<br />
<br />
* Windows/VC++: bin/GuiUpdater/tdm_update.exe -> darkmod/tdm_update.exe<br />
* Linux: tdm_update.linux -> darkmod/tdm_update.linux<br />
<br />
Commit these ''to the branch''.<br />
<br />
= The Manifest =<br />
The "manifest" is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list. The manifest text file is located in the SVN repository: '''devel/manifests/darkmod.txt'''<br />
<br />
== Building the Manifest ==<br />
<br />
Note: This section is more or less for your understanding, '''you don't need to manually generate the manifest anymore''' as this step is part of the automated process running on the TDM server itself.<br />
<br />
The manifest file is generated by the tdm_package application. (The tdm_package sources are in the darkmod_src repository, in a subfolder called tdm_update. There is a VC++ 2010 solution and a sconscript for Linux and Mac builds available. You don't need to compile it if you're in Windows, there is a pre-compiled version in the darkmod repo as well, in the devel/packager folder.) <br />
<br />
After the generation step the file '''devel/manifests/darkmod.txt''' will have been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.<br />
<br />
== What is included in the Manifest ==<br />
The package application is using the file <tt>devel/manifests/darkmod_maps.txt</tt> to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:<br />
<br />
# Include all these files (but without parsing them like maps), each<br />
# statement will include files (from SVN) in that folder:<br />
INCLUDE def/<br />
INCLUDE dds/<br />
...<br />
INCLUDE video/<br />
INCLUDE xdata/<br />
As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.<br />
<br />
As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:<br />
EXCLUDE dds/darkmod/test<br />
In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:<br />
EXCLUDE models/md5/chars/undead/revenant/.*.md5anim<br />
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant<br />
The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant '''and''' the ones in '''dds/'''models/md5/chars/undead/revenant (the dds/ part is marked to be optional). <br />
<br />
In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.<br />
<br />
= Distribute files into PK4s =<br />
Each of the roughly 15000 files in the manifest needs to be sorted into the correct PK4. This is done by defining a rules in the file <tt>devel/manifests/darkmod_pk4s.txt</tt>. Each of the lines there defines a PK4 and which files go into it:<br />
# Miscellaneous stuff (GL Progs, Script, Language Files, Rope Arrow)<br />
tdm_base01.pk4: ^glprogs, ^script, ^strings, sound\.wav, _emptyname\.wav, ^models/md5/environments, ^dds/models/md5/environments, ...<br />
Again, lines starting with the sharp # character denote comments.<br />
<br />
Leftmost is the PK4 filename, followed by a colon character. To the right of the colon a list comma-separated patterns is defined, whereas each pattern is interpreted as regular expression. As with the <tt>darkmod_maps.txt</tt> you don't need to know very much about regular expressions to define those rules, it's usually enough to write the folder names and use wildcards like <tt>.*.md5anim</tt><br />
<br />
= Build the Package =<br />
The package is built right on the TDM server - there is a full darkmod repository checked out on the server's filesystem, and it will be processed through some scripts that are listening to your commands.<br />
<br />
Once triggered, the process goes roughly like this, I'll comment on these steps below:<br />
<br />
* The working copy is reverted, such that it is clean.<br />
* The working copy is switched to the release branch of the version you're about to release (it must exist at this point).<br />
* The working copy is implicitly updated by the switch operation.<br />
* The manifest is generated.<br />
* The full set of PK4 files is generated (it takes a while, the server CPU is not very powerful).<br />
* The differential package is generated.<br />
* The files are copied to a public folder reachable through HTTP such that it can be tested by the team. The team will test it by storing a manipulated tdm_mirrors.txt file next to their tdm_update application.<br />
<br />
== Prepare the packaging process ==<br />
A few steps need to be done before kicking off the process on the server.<br />
<br />
* The release branch must be created, with a specific naming convention: https://darkmod_server_here/svn/darkmod/branches/releaseY.XX where Y is the major version and XX is the two-digit minor version, e.g. "release1.08".<br />
* The inclusion statements in the <tt>darkmod_maps.txt</tt> file need to be up to date, make sure everything is committed to the branch.<br />
* The <tt>tdm_version.txt</tt> file should be containing the correct version number, it's located in <tt>devel/release/tdm_version.txt</tt>. Commit that change to the release branch, needless to say.<br />
<br />
== Kicking off the packaging process ==<br />
There is a special admin page on the server which can be used to kick off the process. The URL has been [http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/ posted on the forums before], greebo or grayman know the URL. It's password protected, so you'll be asked to enter credentials. Once there, you can enter the two version numbers, the one you're building, and the previous one (the latest released one). E.g.: 1.08 and 1.07. It's sufficient to enter the currently released one, e.g. 1.07, into the second field and the website will automatically fill in the next version number in the first field - you can override it if really necessary.<br />
<br />
Once you start the process you'll be presented a text window with some progress information, and you can watch the messages emitted by the svn client and the tdm_package application running on the server. It takes a while, about half an hour, until the package is built.<br />
<br />
= Prepare the internal package test =<br />
The team needs to have access to the package as created above for internal testing, so tell them to download a specially prepared tdm_mirrors.txt. You can find one attached to the first post here: http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/<br />
<br />
The linked post above already contains a few instructions you can copy from. Basically, instruct the team to use the <tt>--keep-mirrors</tt> switch when starting the tdm_update application, and to copy the tdm_mirrors.txt file into their test folder before running it. If the <tt>--keep-mirrors</tt> option is omitted the updater will connect to the regular TDM update mirrors, which is not the point.<br />
<br />
= The Test & Bugfix cycle =<br />
Once the testers post their bug reports, the dev team needs to get moving to fix them. It's recommended that all fixes will be committed to the trunk (both for darkmod and darkmod_src repos), and the release manager should merge the changes into the release branch.<br />
<br />
== Merge Fixes into the Release Branch ==<br />
Let's assume there is a fix that got committed to darkmod SVN in order to fix an issue discovered in the test package. Proceed like this to merge it to the release branch. <br />
* Make sure your local working copy is switched to the release branch. <br />
* Now right-click the darkmod folder and choose SVN > Merge<br />
* Select ''Merge a range of revisions''<br />
* As ''URL to merge from'' use the address of the trunk: [https://server/svn/darkmod/trunk https://<darkmod_server>/svn/darkmod/trunk]<br />
* In the field revision range to merge you need to specify which exact change you intend to merge. It's easier if you click the "Show Log" button right next to the entry field to view the SVN Log of the trunk. You can either select a single commit, or you can select a range of commits. Perhaps double-check the changes of that checkin.<br />
* Hit ''Next'', then ''Merge''.<br />
* Important: the changes will be incorporated into your ''working copy''. If you want these changes to actually be stored in the release branch, you need to perform the ''commit''.<br />
<br />
Special note for code changes: once these are committed to darkmod_src trunk, you need to merge them just like described above. Then you're going to recompile the game binaries (I recommend from scratch) and commit the tdm_game01.pk4 / tdm_game02.pk4 files to the darkmod release branch too.<br />
<br />
== Update the Test Package ==<br />
Re-package the TDM package, as described above. Just make sure everything is committed to the release branch and kick off another build process.<br />
<br />
== Test again ==<br />
Inform your testers about the update and which things got changed since the last test. Instruct them to update their test installation (don't forget to mention --keep-mirrors) and enter the next round of testing.<br />
<br />
= Release Time: Upload & Cleanup =<br />
Once the day has come to release the next version, connect to the TDM server using a secure shell (SSH) client, like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY].<br />
<br />
Follow these steps, there are some things that need to be done afterwards, they are necessary for the ''next'' release to function properly:<br />
<br />
* Rebuild binaries from scratch, place in darkmod folder, and commit the darkmod folder.<br />
* 7-zip the Windows gamex86.pdb and TheDarkMod.pdb files and place them in the trunk darkmod/devel/release/debugging/2.0x folder. Add that folder to SVN and commit it.<br />
* Update the darkmod 2.0x branch tree and merge the just-placed debugging files to that branch. Commit the 2.0x branch.<br />
* Create the final package remotely as described above (through the website). <br />
* The above step will generate a new crc_info.txt and a tdm_version_info.txt file on the server.<br />
* The packaging script will take care of checking these two files into SVN for "Release" packages.<br />
* Check in the newly generated manifest, it should still be in the folder where the packaging script left it. Note: The packaging script will check this file in automatically for "Release" packages.<br />
* Create a tag for the darkmod and darkmod_src repositories (/tags/2.0x) - copy it from the latest revision in the corresponding release branch.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy package from /usr/local/www/update.thedarkmod.com/ to /usr/local/tdm_releases/2.0x/ for archiving. The next package process will need it there.<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy /usr/local/tdm_releases/1.05/index.html to /usr/local/tdm_releases/2.0x<br />
** The packaging script will perform this task for "Release" packages.<br />
* Move all differential packages back to /usr/local/www/update.thedarkmod.com/<br />
** The packaging script will perform this task for "Release" packages.<br />
* Copy the one differential update package updating to the new 2.0x version back to /usr/local/tdm_releases/2.0x. In the following line, (y = x-1).<br />
** The packaging script will perform this task for "Release" packages.<br />
* At this point, the /usr/local/tdm_releases/2.0x folder contains a valid TDM 2.0x release, the one that will be pushed to all the mirrors. Examine it for double safety.<br />
* Examine the upload_to_all_mirrors.sh shell script, to see if it fits your needs.<br />
* Start uploading to all mirrors.<br />
** <tt>./upload_to_all_mirrors.sh 2.0x</tt><br />
** Update the rsyncd config on update.thedarkmod.com to point to the new release folder (taaaki will need to do this).<br />
* Update tdm_mirrors.txt and tdm_version.xml on thedarkmod.com/update: ask taaaki to do that. The tdm_mirrors.txt file is probably fine, but the tdm_version.xml needs to be updated.<br />
<br />
== Update the Wiki ==<br />
<br />
The wiki contains one page for each release. You can find them all in the [[:Category:What's New]] category. <br />
<br />
First update the current release page:<br />
<br />
* Change the "roadmap" link on the current release to a "changelog" link by swapping ''"roadmap_page.php?version_id=XX"'' with ''"changelog_page.php?version=XX"''.<br />
* Add the ''<nowiki>{{released|2.01|2014-01-30}}</nowiki>'' Template on top of the current release page with the correct date.<br />
<br />
Then add a new page for the next release. To do this, add a link to it in this template: [[Template:Whatsnew]] by editing it. After saving the template, a link to the new release version page appears in the list and in the category. Edit this page and insert some text into it (you can copy it from an older release page).<br />
<br />
Also insert a link to the current roadmap on the bugtracker, you can find out the version_id by looking at [http://bugs.thedarkmod.com/roadmap_page.php the roadmap page].<br />
<br />
= Glossary =<br />
* Release Fileset: the PK4 files forming the actual release. <br />
* SVN: an acronym for Subversion, a version control system<br />
* Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.<br />
* Mirrors: The servers where the PK4 files are stored for download by the updater.<br />
* updater: The TDM Updater executable, used for downloading and updating TDM.<br />
* binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).<br />
* darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.<br />
* branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.<br />
* trunk: The main branch where all the ongoing development is happening.<br />
<br />
{{todo}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=Main_Page&diff=18451Main Page2016-07-26T16:17:26Z<p>Taaaki: </p>
<hr />
<div>[[Image:Welcome to the dark wiki.gif|center]]<br />
<br />
<table align="center" width="95%" cellspacing="10"><tr><br />
<td style="width:50%; vertical-align:top; padding:2em; border:1px solid #e1e1e1; background-color:#f9f9f9"><br />
<br />
<div align="center"><br/> [[Image:Tdm_wiki_logo.png|link=http://www.thedarkmod.com/downloads/]]<br /><br />
<div style="padding: 10px;font-family: Verdana, Helvetica, sans-serif;font-size:2em; letter-spacing: 20;font-weight:bold">[[http://www.thedarkmod.com/downloads/ Download here]]</div><br />
<div style="letter-spacing: 1px">The Dark Mod 2.04 Released: '''2016-07-12'''</div><br />
<div style="letter-spacing: 1px;font-size:small">See the [http://wiki.thedarkmod.com/index.php?title=What%27s_new Changelog]</div><br />
<br />
<br />
To see (or add to) a list of all available missions, click below.<br />
<div style="padding: 10px;font-family: Verdana, Helvetica, sans-serif;font-size:1.6em; letter-spacing: 20;font-weight:bold"><br />
[[Fan Missions for The Dark Mod]]</div><br />
<br />Having problems? Check out the <br /><div style="padding: 10px;font-family: Verdana, Helvetica, sans-serif;font-size:2em; letter-spacing: 20;font-weight:bold">'''[[FAQ|Frequently Asked Questions]]'''</div><br />
</div><br />
<br />
<br />
<br />
<br />
<br />
</td><td style="vertical-align:top; padding:2em; border:1px solid #e1e1e1; background-color:#f9f9f9"><br />
<br />
<p style="font-size:130%">'''Topics:'''</p><br />
<br />
; [[Installation]] / [[FAQ]] : Information how to get The Dark Mod running.<br />
; [[Bindings and User Settings]] : Key binding and interface documentation.<br />
; [[The Dark Mod Gameplay]] : The instruction manual for how to play TDM missions.<br />
; [[Universe]] : Information about The Dark Mod universe and setting<br />
; [[:Category:Tutorial|Tutorials]] : Complete tutorials about setting up certain characteristics<br />
; [[:Category:Editing|Editing]] : Information about level design and the tools<br />
; [[DarkRadiant]] : Documents concerning the Dark Mod's own level editor ([[:Category:DarkRadiant|article index]]).<br />
; [[Textures]] : Explanation of material shaders and image files<br />
; [[Modeling]] : Modeling and file format information<br />
; [[Animation]] : General tips, and software tutorials<br />
; [[Sound]] : Soundeffects, ambients and how to get them ingame<br />
; [[Coding]] : Source code modification, level and GUI scripting<br />
; [[Release]] : How to pack a mission, and get it tested and released!<br />
<br />
</td></tr></table></div>Taaakihttps://wiki.thedarkmod.com/index.php?title=What%27s_new_in_TDM_2.04&diff=18435What's new in TDM 2.042016-07-13T18:14:12Z<p>Taaaki: </p>
<hr />
<div><!-- keywords whats new --><br />
See the [http://bugs.thedarkmod.com/changelog_page.php?version_id=71 changelog] on our bugtracker.<br />
{{released|2.04|2016-07-12}}<br />
<br />
== AI ==<br />
* grayman enhanced AI searching to allow for wider, more realistic searches.<br />
* grayman fixed some issues with AI relighting lights.<br />
* grayman fixed the infamous "barmaid gets stuck while peeing" problem in "Inn Business".<br />
* grayman allowed AI to see weapons dropped by other AI.<br />
* grayman fixed the "AI get stuck in sit-down & get up" cycle. This was causing them to scoot themselves out of the map.<br />
<br />
== Coding ==<br />
<br />
* Demagogue has created a new override that allows mappers to simply override location ambients with another sound<br />
* SteveL has fixed a glitch that resulted in occasional sound popping<br />
* SteveL has adjusted the grabber so that it is easier to lift up objects without banging into things<br />
* SteveL has fixed breakable glass behavior<br />
* SteveL has fixed collision behavior on skin swapping<br />
* SteveL has fixed distant decals rendering over the top of objects they should be behind<br />
* SteveL has optimized particle bounds calculations to reduce map load times<br />
* SteveL has created a new "ai_see" argument for lights so mappers can create decorative lighting without illuminating the player accidentally<br />
* SteveL has fixed a bug where lod_bias objects leave collision models behind on map start when set to be removed<br />
* SteveL has improved Dmap (map compiling) performance dramatically by removing logspam and decoupling vsync<br />
* SteveL has created an new quicksave system that alternates between files to prevent corruption caused by poor OS file handling.<br />
* SteveL has fixed the shadow bobbing that happens when a player holds a lantern in water<br />
* Rebb has fixed Ambient shading on rotated models<br />
* grayman has repaired the savegame crash caused by card players.<br />
* Agent Jones has fixed a few stability issues with the Mission Downloader<br />
<br />
== Assets ==<br />
<br />
* No significant asset changes. A massive set of new assets will appear in 2.05.<br />
<br />
== GUIs ==<br />
<br />
* grayman expanded the space allotted to the current mission name to accommodate longer names.<br />
* SteveL has added Durandall's Inventory GUI system which allows for mouse based inventory management<br />
<br />
== Scripting ==<br />
<br />
* Obstortte has created a new combination lock<br />
<br />
<br />
{{whatsnew|sort=204}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics&diff=18428TDM Release Mechanics2016-07-09T15:50:12Z<p>Taaaki: </p>
<hr />
<div>This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.<br />
<br />
The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:<br />
<br />
= Development = <br />
Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.<br />
<br />
= Branching off =<br />
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN. <br />
<br />
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right|350px]]<br />
* Update your darkmod working copy.<br />
* Update the darkmod_src repository too.<br />
* Right-click the darkmod folder to create the branch<br />
** Select SVN > Branch/Tag...<br />
** A new dialog appears asking for a URL. Enter a URL like this: [https://server/svn/darkmod/branches/release1.xx https://<darkmod_server_here>/svn/darkmod/branches/release1.xx] where xx is replaced by whatever version the next release will be. <br />
** You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.<br />
** Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).<br />
* The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme [https://server/svn/darkmod_src/branches/release1.xx https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx]<br />
<br />
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch. <br />
<br />
'''Important:''' commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.<br />
<br />
= Compile Game Binaries =<br />
Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile the tdm_gameNN.pk4 for you, or you can bite the bullet and follow the [[TDM Compilation Guide]] to compile it yourself. As Windows user, I recommend setting up an Ubuntu 10.04 32-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC. <br />
<br />
Make sure you compile a '''release build''' (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild Solution''<br />
* Linux: <tt>scons -c && scons BUILD="release" BUILD_GAMEPAK="1"</tt> <br />
<br />
Once compiled, make sure that the tdm_game01.pk4 is updated with the newly compiled DLL and the tdm_game02.pk4 is copied over from darkmod_src (where it is created after compilation) to darkmod and commit these two files ''to the branch''.<br />
<br />
Also commit TheDarkMod.exe and thedarkmod.x86 ''to the branch''.<br />
<br />
= Compile tdm_update =<br />
tdm_update must be built separately for both Windows and Linux.<br />
<br />
Make sure you compile a '''release build''', and recompile everything from scratch:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild tdm_update_mfc''<br />
* Linux: descend into the tdm_update directory and then do <tt>scons -c && scons BUILD="release"</tt><br />
<br />
Once compiled, copy the results into the darkmod folder:<br />
<br />
* Windows/VC++: bin/GuiUpdater/tdm_update.exe -> darkmod/tdm_update.exe<br />
* Linux: tdm_update.linux -> darkmod/tdm_update.linux<br />
<br />
Commit these ''to the branch''.<br />
<br />
= The Manifest =<br />
The "manifest" is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list. The manifest text file is located in the SVN repository: '''devel/manifests/darkmod.txt'''<br />
<br />
== Building the Manifest ==<br />
<br />
Note: This section is more or less for your understanding, '''you don't need to manually generate the manifest anymore''' as this step is part of the automated process running on the TDM server itself.<br />
<br />
The manifest file is generated by the tdm_package application. (The tdm_package sources are in the darkmod_src repository, in a subfolder called tdm_update. There is a VC++ 2010 solution and a sconscript for Linux and Mac builds available. You don't need to compile it if you're in Windows, there is a pre-compiled version in the darkmod repo as well, in the devel/packager folder.) <br />
<br />
After the generation step the file '''devel/manifests/darkmod.txt''' will have been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.<br />
<br />
== What is included in the Manifest ==<br />
The package application is using the file <tt>devel/manifests/darkmod_maps.txt</tt> to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:<br />
<br />
# Include all these files (but without parsing them like maps), each<br />
# statement will include files (from SVN) in that folder:<br />
INCLUDE def/<br />
INCLUDE dds/<br />
...<br />
INCLUDE video/<br />
INCLUDE xdata/<br />
As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.<br />
<br />
As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:<br />
EXCLUDE dds/darkmod/test<br />
In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:<br />
EXCLUDE models/md5/chars/undead/revenant/.*.md5anim<br />
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant<br />
The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant '''and''' the ones in '''dds/'''models/md5/chars/undead/revenant (the dds/ part is marked to be optional). <br />
<br />
In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.<br />
<br />
= Distribute files into PK4s =<br />
Each of the roughly 15000 files in the manifest needs to be sorted into the correct PK4. This is done by defining a rules in the file <tt>devel/manifests/darkmod_pk4s.txt</tt>. Each of the lines there defines a PK4 and which files go into it:<br />
# Miscellaneous stuff (GL Progs, Script, Language Files, Rope Arrow)<br />
tdm_base01.pk4: ^glprogs, ^script, ^strings, sound\.wav, _emptyname\.wav, ^models/md5/environments, ^dds/models/md5/environments, ...<br />
Again, lines starting with the sharp # character denote comments.<br />
<br />
Leftmost is the PK4 filename, followed by a colon character. To the right of the colon a list comma-separated patterns is defined, whereas each pattern is interpreted as regular expression. As with the <tt>darkmod_maps.txt</tt> you don't need to know very much about regular expressions to define those rules, it's usually enough to write the folder names and use wildcards like <tt>.*.md5anim</tt><br />
<br />
= Build the Package =<br />
The package is built right on the TDM server - there is a full darkmod repository checked out on the server's filesystem, and it will be processed through some scripts that are listening to your commands.<br />
<br />
Once triggered, the process goes roughly like this, I'll comment on these steps below:<br />
<br />
* The working copy is reverted, such that it is clean.<br />
* The working copy is switched to the release branch of the version you're about to release (it must exist at this point).<br />
* The working copy is implicitly updated by the switch operation.<br />
* The manifest is generated.<br />
* The full set of PK4 files is generated (it takes a while, the server CPU is not very powerful).<br />
* The differential package is generated.<br />
* The files are copied to a public folder reachable through HTTP such that it can be tested by the team. The team will test it by storing a manipulated tdm_mirrors.txt file next to their tdm_update application.<br />
<br />
== Prepare the packaging process ==<br />
A few steps need to be done before kicking off the process on the server.<br />
<br />
* The release branch must be created, with a specific naming convention: https://darkmod_server_here/svn/darkmod/branches/releaseY.XX where Y is the major version and XX is the two-digit minor version, e.g. "release1.08".<br />
* The inclusion statements in the <tt>darkmod_maps.txt</tt> file need to be up to date, make sure everything is committed to the branch.<br />
* The <tt>tdm_version.txt</tt> file should be containing the correct version number, it's located in <tt>devel/release/tdm_version.txt</tt>. Commit that change to the release branch, needless to say.<br />
<br />
== Kicking off the packaging process ==<br />
There is a special admin page on the server which can be used to kick off the process. The URL has been [http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/ posted on the forums before], greebo or grayman know the URL. It's password protected, so you'll be asked to enter credentials. Once there, you can enter the two version numbers, the one you're building, and the previous one (the latest released one). E.g.: 1.08 and 1.07. It's sufficient to enter the currently released one, e.g. 1.07, into the second field and the website will automatically fill in the next version number in the first field - you can override it if really necessary.<br />
<br />
Once you start the process you'll be presented a text window with some progress information, and you can watch the messages emitted by the svn client and the tdm_package application running on the server. It takes a while, about half an hour, until the package is built.<br />
<br />
= Prepare the internal package test =<br />
The team needs to have access to the package as created above for internal testing, so tell them to download a specially prepared tdm_mirrors.txt. You can find one attached to the first post here: http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/<br />
<br />
The linked post above already contains a few instructions you can copy from. Basically, instruct the team to use the <tt>--keep-mirrors</tt> switch when starting the tdm_update application, and to copy the tdm_mirrors.txt file into their test folder before running it. If the <tt>--keep-mirrors</tt> option is omitted the updater will connect to the regular TDM update mirrors, which is not the point.<br />
<br />
= The Test & Bugfix cycle =<br />
Once the testers post their bug reports, the dev team needs to get moving to fix them. It's recommended that all fixes will be committed to the trunk (both for darkmod and darkmod_src repos), and the release manager should merge the changes into the release branch.<br />
<br />
== Merge Fixes into the Release Branch ==<br />
Let's assume there is a fix that got committed to darkmod SVN in order to fix an issue discovered in the test package. Proceed like this to merge it to the release branch. <br />
* Make sure your local working copy is switched to the release branch. <br />
* Now right-click the darkmod folder and choose SVN > Merge<br />
* Select ''Merge a range of revisions''<br />
* As ''URL to merge from'' use the address of the trunk: [https://server/svn/darkmod/trunk https://<darkmod_server>/svn/darkmod/trunk]<br />
* In the field revision range to merge you need to specify which exact change you intend to merge. It's easier if you click the "Show Log" button right next to the entry field to view the SVN Log of the trunk. You can either select a single commit, or you can select a range of commits. Perhaps double-check the changes of that checkin.<br />
* Hit ''Next'', then ''Merge''.<br />
* Important: the changes will be incorporated into your ''working copy''. If you want these changes to actually be stored in the release branch, you need to perform the ''commit''.<br />
<br />
Special note for code changes: once these are committed to darkmod_src trunk, you need to merge them just like described above. Then you're going to recompile the game binaries (I recommend from scratch) and commit the tdm_game01.pk4 / tdm_game02.pk4 files to the darkmod release branch too.<br />
<br />
== Update the Test Package ==<br />
Re-package the TDM package, as described above. Just make sure everything is committed to the release branch and kick off another build process.<br />
<br />
== Test again ==<br />
Inform your testers about the update and which things got changed since the last test. Instruct them to update their test installation (don't forget to mention --keep-mirrors) and enter the next round of testing.<br />
<br />
= Release Time: Upload & Cleanup =<br />
Once the day has come to release the next version, connect to the TDM server using a secure shell (SSH) client, like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY].<br />
<br />
Follow these steps, there are some things that need to be done afterwards, they are necessary for the ''next'' release to function properly:<br />
<br />
* Rebuild binaries from scratch, place in darkmod folder, and commit the darkmod folder.<br />
* 7-zip the Windows gamex86.pdb and TheDarkMod.pdb files and place them in the trunk darkmod/devel/release/debugging/2.0x folder. Add that folder to SVN and commit it.<br />
* Update the darkmod 2.0x branch tree and merge the just-placed debugging files to that branch. Commit the 2.0x branch.<br />
* Create the final package remotely as described above (through the website). <br />
* The above step will generate a new crc_info.txt and a tdm_version_info.txt file on the server.<br />
* Copy this crc_info.txt and tdm_version_info.txt to the folder packaging/darkmod/devel/release/version_info/2.0x and commit:<br />
** <tt>cd /usr/local/tdm_releases/packaging/darkmod/devel/release/version_info</tt> <br />
** <tt>mkdir 2.0x (replace the x)</tt> <br />
** <tt>cd 2.0x</tt> <br />
** <tt>cp /usr/local/www/update.thedarkmod.com/crc_info.txt .</tt> <br />
** <tt>cp /usr/local/www/update.thedarkmod.com/tdm_version_info.txt .</tt> <br />
** <tt>cd ..</tt><br />
** <tt>svn add 2.0x</tt><br />
** <tt>svn ci --username=<YOUR_SVN_USER> -m "<YOUR COMMIT MESSAGE>"</tt><br />
* Check in the newly generated manifest, it should still be in the folder where the packaging script left it:<br />
** <tt>cd /usr/local/tdm_releases/packaging/darkmod/devel/manifests</tt><br />
** <tt>svn ci --username=<YOUR_SVN_USER> -m "<YOUR COMMIT MESSAGE>"</tt><br />
* Create a tag for the darkmod and darkmod_src repositories (/tags/2.0x) - copy it from the latest revision in the corresponding release branch.<br />
** Switch your darkmod working copy to the 2.0x release branch<br />
** Choose SVN > Branch/Tag and fill in the dialog fields with the following:<br />
*** From WC/URL: https://svn.thedarkmod.com/svn/darkmod/branches/release2.0x<br />
*** To Path: /tags/2.0x<br />
*** Log message: Tag for 2.0x release<br />
*** Create a copy in the repository from: HEAD revision in the repository<br />
** Same goes for the darkmod_src repository, just replace /darkmod/ with /darkmod_src/ above.<br />
* Copy package from /usr/local/www/update.thedarkmod.com/ to /usr/local/tdm_releases/2.0x/ for archiving. The next package process will need it there.<br />
** cd /usr/local/tdm_releases<br />
** mkdir 2.0x<br />
** cp -r /usr/local/www/update.thedarkmod.com/* 2.0x<br />
* Copy /usr/local/tdm_releases/1.05/index.html to /usr/local/tdm_releases/2.0x<br />
* Move all differential packages back to /usr/local/www/update.thedarkmod.com/<br />
** <tt>mv /usr/local/tdm_releases/2.0x/tdm_update_1.0*.zip /usr/local/www/update.thedarkmod.com/</tt><br />
** <tt>mv /usr/local/tdm_releases/2.0x/tdm_update_2.0*.zip /usr/local/www/update.thedarkmod.com/</tt><br />
* Copy the one differential update package updating to the new 2.0x version back to /usr/local/tdm_releases/2.0x<br />
** <tt>cp /usr/local/www/update.thedarkmod.com/tdm_update_2.0y_to_2.0x.zip to /usr/local/tdm_releases/2.0x</tt> (y = x-1)<br />
* At this point, the /usr/local/tdm_releases/2.0x folder contains a valid TDM 2.0x release, the one that will be pushed to all the mirrors. Examine it for double safety.<br />
* Examine the upload_to_all_mirrors.sh shell script, to see if it fits your needs.<br />
* Start uploading to all mirrors.<br />
** <tt>./upload_to_all_mirrors.sh 2.0x</tt><br />
* Update tdm_mirrors.txt and tdm_version.xml on thedarkmod.com/update: ask taaaki to do that. The tdm_mirrors.txt file is probably fine, but the tdm_version.xml needs to be updated.<br />
<br />
== Update the Wiki ==<br />
<br />
The wiki contains one page for each release. You can find them all in the [[:Category:What's New]] category. <br />
<br />
First update the current release page:<br />
<br />
* Change the "roadmap" link on the current release to a "changelog" link by swapping ''"roadmap_page.php?version_id=XX"'' with ''"changelog_page.php?version=XX"''.<br />
* Add the ''<nowiki>{{released|2.01|2014-01-30}}</nowiki>'' Template on top of the current release page with the correct date.<br />
<br />
Then add a new page for the next release. To do this, add a link to it in this template: [[Template:Whatsnew]] by editing it. After saving the template, a link to the new release version page appears in the list and in the category. Edit this page and insert some text into it (you can copy it from an older release page).<br />
<br />
Also insert a link to the current roadmap on the bugtracker, you can find out the version_id by looking at [http://bugs.thedarkmod.com/roadmap_page.php the roadmap page].<br />
<br />
= Glossary =<br />
* Release Fileset: the PK4 files forming the actual release. <br />
* SVN: an acronym for Subversion, a version control system<br />
* Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.<br />
* Mirrors: The servers where the PK4 files are stored for download by the updater.<br />
* updater: The TDM Updater executable, used for downloading and updating TDM.<br />
* binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).<br />
* darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.<br />
* branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.<br />
* trunk: The main branch where all the ongoing development is happening.<br />
<br />
{{todo}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=TDM_Release_Mechanics&diff=18427TDM Release Mechanics2016-07-09T15:45:32Z<p>Taaaki: </p>
<hr />
<div>This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.<br />
<br />
The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:<br />
<br />
= Development = <br />
Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.<br />
<br />
= Branching off =<br />
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN. <br />
<br />
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right|350px]]<br />
* Update your darkmod working copy.<br />
* Update the darkmod_src repository too.<br />
* Right-click the darkmod folder to create the branch<br />
** Select SVN > Branch/Tag...<br />
** A new dialog appears asking for a URL. Enter a URL like this: [https://server/svn/darkmod/branches/release1.xx https://<darkmod_server_here>/svn/darkmod/branches/release1.xx] where xx is replaced by whatever version the next release will be. <br />
** You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.<br />
** Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).<br />
* The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme [https://server/svn/darkmod_src/branches/release1.xx https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx]<br />
<br />
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch. <br />
<br />
'''Important:''' commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.<br />
<br />
= Compile Game Binaries =<br />
Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile the tdm_gameNN.pk4 for you, or you can bite the bullet and follow the [[TDM Compilation Guide]] to compile it yourself. As Windows user, I recommend setting up an Ubuntu 10.04 32-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC. <br />
<br />
Make sure you compile a '''release build''' (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild Solution''<br />
* Linux: <tt>scons -c && scons BUILD="release" BUILD_GAMEPAK="1"</tt> <br />
<br />
Once compiled, make sure that the tdm_game01.pk4 is updated with the newly compiled DLL and the tdm_game02.pk4 is copied over from darkmod_src (where it is created after compilation) to darkmod and commit these two files ''to the branch''.<br />
<br />
Also commit TheDarkMod.exe and thedarkmod.x86 ''to the branch''.<br />
<br />
= Compile tdm_update =<br />
tdm_update must be built separately for both Windows and Linux.<br />
<br />
Make sure you compile a '''release build''', and recompile everything from scratch:<br />
* Windows/VC++: Menu ''Build'' > ''Rebuild tdm_update_mfc''<br />
* Linux: descend into the tdm_update directory and then do <tt>scons -c && scons BUILD="release"</tt><br />
<br />
Once compiled, copy the results into the darkmod folder:<br />
<br />
* Windows/VC++: bin/GuiUpdater/tdm_update.exe -> darkmod/tdm_update.exe<br />
* Linux: tdm_update.linux -> darkmod/tdm_update.linux<br />
<br />
Commit these ''to the branch''.<br />
<br />
= The Manifest =<br />
The "manifest" is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list. The manifest text file is located in the SVN repository: '''devel/manifests/darkmod.txt'''<br />
<br />
== Building the Manifest ==<br />
<br />
Note: This section is more or less for your understanding, '''you don't need to manually generate the manifest anymore''' as this step is part of the automated process running on the TDM server itself.<br />
<br />
The manifest file is generated by the tdm_package application. (The tdm_package sources are in the darkmod_src repository, in a subfolder called tdm_update. There is a VC++ 2010 solution and a sconscript for Linux and Mac builds available. You don't need to compile it if you're in Windows, there is a pre-compiled version in the darkmod repo as well, in the devel/packager folder.) <br />
<br />
After the generation step the file '''devel/manifests/darkmod.txt''' will have been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.<br />
<br />
== What is included in the Manifest ==<br />
The package application is using the file <tt>devel/manifests/darkmod_maps.txt</tt> to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:<br />
<br />
# Include all these files (but without parsing them like maps), each<br />
# statement will include files (from SVN) in that folder:<br />
INCLUDE def/<br />
INCLUDE dds/<br />
...<br />
INCLUDE video/<br />
INCLUDE xdata/<br />
As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.<br />
<br />
As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:<br />
EXCLUDE dds/darkmod/test<br />
In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:<br />
EXCLUDE models/md5/chars/undead/revenant/.*.md5anim<br />
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant<br />
The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant '''and''' the ones in '''dds/'''models/md5/chars/undead/revenant (the dds/ part is marked to be optional). <br />
<br />
In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.<br />
<br />
= Distribute files into PK4s =<br />
Each of the roughly 15000 files in the manifest needs to be sorted into the correct PK4. This is done by defining a rules in the file <tt>devel/manifests/darkmod_pk4s.txt</tt>. Each of the lines there defines a PK4 and which files go into it:<br />
# Miscellaneous stuff (GL Progs, Script, Language Files, Rope Arrow)<br />
tdm_base01.pk4: ^glprogs, ^script, ^strings, sound\.wav, _emptyname\.wav, ^models/md5/environments, ^dds/models/md5/environments, ...<br />
Again, lines starting with the sharp # character denote comments.<br />
<br />
Leftmost is the PK4 filename, followed by a colon character. To the right of the colon a list comma-separated patterns is defined, whereas each pattern is interpreted as regular expression. As with the <tt>darkmod_maps.txt</tt> you don't need to know very much about regular expressions to define those rules, it's usually enough to write the folder names and use wildcards like <tt>.*.md5anim</tt><br />
<br />
= Build the Package =<br />
The package is built right on the TDM server - there is a full darkmod repository checked out on the server's filesystem, and it will be processed through some scripts that are listening to your commands.<br />
<br />
Once triggered, the process goes roughly like this, I'll comment on these steps below:<br />
<br />
* The working copy is reverted, such that it is clean.<br />
* The working copy is switched to the release branch of the version you're about to release (it must exist at this point).<br />
* The working copy is implicitly updated by the switch operation.<br />
* The manifest is generated.<br />
* The full set of PK4 files is generated (it takes a while, the server CPU is not very powerful).<br />
* The differential package is generated.<br />
* The files are copied to a public folder reachable through HTTP such that it can be tested by the team. The team will test it by storing a manipulated tdm_mirrors.txt file next to their tdm_update application.<br />
<br />
== Prepare the packaging process ==<br />
A few steps need to be done before kicking off the process on the server.<br />
<br />
* The release branch must be created, with a specific naming convention: https://darkmod_server_here/svn/darkmod/branches/releaseY.XX where Y is the major version and XX is the two-digit minor version, e.g. "release1.08".<br />
* The inclusion statements in the <tt>darkmod_maps.txt</tt> file need to be up to date, make sure everything is committed to the branch.<br />
* The <tt>tdm_version.txt</tt> file should be containing the correct version number, it's located in <tt>devel/release/tdm_version.txt</tt>. Commit that change to the release branch, needless to say.<br />
<br />
== Kicking off the packaging process ==<br />
There is a special admin page on the server which can be used to kick off the process. The URL has been [http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/ posted on the forums before], greebo or grayman know the URL. It's password protected, so you'll be asked to enter credentials. Once there, you can enter the two version numbers, the one you're building, and the previous one (the latest released one). E.g.: 1.08 and 1.07. It's sufficient to enter the currently released one, e.g. 1.07, into the second field and the website will automatically fill in the next version number in the first field - you can override it if really necessary.<br />
<br />
Once you start the process you'll be presented a text window with some progress information, and you can watch the messages emitted by the svn client and the tdm_package application running on the server. It takes a while, about half an hour, until the package is built.<br />
<br />
= Prepare the internal package test =<br />
The team needs to have access to the package as created above for internal testing, so tell them to download a specially prepared tdm_mirrors.txt. You can find one attached to the first post here: http://forums.thedarkmod.com/topic/13179-packaging-and-testing-107/<br />
<br />
The linked post above already contains a few instructions you can copy from. Basically, instruct the team to use the <tt>--keep-mirrors</tt> switch when starting the tdm_update application, and to copy the tdm_mirrors.txt file into their test folder before running it. If the <tt>--keep-mirrors</tt> option is omitted the updater will connect to the regular TDM update mirrors, which is not the point.<br />
<br />
= The Test & Bugfix cycle =<br />
Once the testers post their bug reports, the dev team needs to get moving to fix them. It's recommended that all fixes will be committed to the trunk (both for darkmod and darkmod_src repos), and the release manager should merge the changes into the release branch.<br />
<br />
== Merge Fixes into the Release Branch ==<br />
Let's assume there is a fix that got committed to darkmod SVN in order to fix an issue discovered in the test package. Proceed like this to merge it to the release branch. <br />
* Make sure your local working copy is switched to the release branch. <br />
* Now right-click the darkmod folder and choose SVN > Merge<br />
* Select ''Merge a range of revisions''<br />
* As ''URL to merge from'' use the address of the trunk: [https://server/svn/darkmod/trunk https://<darkmod_server>/svn/darkmod/trunk]<br />
* In the field revision range to merge you need to specify which exact change you intend to merge. It's easier if you click the "Show Log" button right next to the entry field to view the SVN Log of the trunk. You can either select a single commit, or you can select a range of commits. Perhaps double-check the changes of that checkin.<br />
* Hit ''Next'', then ''Merge''.<br />
* Important: the changes will be incorporated into your ''working copy''. If you want these changes to actually be stored in the release branch, you need to perform the ''commit''.<br />
<br />
Special note for code changes: once these are committed to darkmod_src turnk, you need to merge them just like described above. Then you're going to recompile the game binaries (I recommend from scratch) and commit the tdm_game01.pk4 / tdm_game02.pk4 files to the darkmod release branch too.<br />
<br />
== Update the Test Package ==<br />
Re-package the TDM package, as described above. Just make sure everything is committed to the release branch and kick off another build process.<br />
<br />
== Test again ==<br />
Inform your testers about the update and which things got changed since the last test. Instruct them to update their test installation (don't forget to mention --keep-mirrors) and enter the next round of testing.<br />
<br />
= Release Time: Upload & Cleanup =<br />
Once the day has come to release the next version, connect to the TDM server using a secure shell (SSH) client, like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY].<br />
<br />
Follow these steps, there are some things that need to be done afterwards, they are necessary for the ''next'' release to function properly:<br />
<br />
* Rebuild binaries from scratch, place in darkmod folder, and commit the darkmod folder.<br />
* 7-zip the Windows gamex86.pdb and TheDarkMod.pdb files and place them in the trunk darkmod/devel/release/debugging/2.0x folder. Add that folder to SVN and commit it.<br />
* Update the darkmod 2.0x branch tree and merge the just-placed debugging files to that branch. Commit the 2.0x branch.<br />
* Create the final package remotely as described above (through the website). <br />
* The above step will generate a new crc_info.txt and a tdm_version_info.txt file on the server.<br />
* Copy this crc_info.txt and tdm_version_info.txt to the folder packaging/darkmod/devel/release/version_info/2.0x and commit:<br />
** <tt>cd /usr/local/tdm_releases/packaging/darkmod/devel/release/version_info</tt> <br />
** <tt>mkdir 2.0x (replace the x)</tt> <br />
** <tt>cd 2.0x</tt> <br />
** <tt>cp /usr/local/www/update.thedarkmod.com/crc_info.txt .</tt> <br />
** <tt>cp /usr/local/www/update.thedarkmod.com/tdm_version_info.txt .</tt> <br />
** <tt>cd ..</tt><br />
** <tt>svn add 2.0x</tt><br />
** <tt>svn ci --username=<YOUR_SVN_USER> -m "<YOUR COMMIT MESSAGE>"</tt><br />
* Check in the newly generated manifest, it should still be in the folder where the packaging script left it:<br />
** <tt>cd /usr/local/tdm_releases/packaging/darkmod/devel/manifests</tt><br />
** <tt>svn ci --username=<YOUR_SVN_USER> -m "<YOUR COMMIT MESSAGE>"</tt><br />
* Create a tag for the darkmod and darkmod_src repositories (/tags/2.0x) - copy it from the latest revision in the corresponding release branch.<br />
** Switch your darkmod working copy to the 2.0x release branch<br />
** Choose SVN > Branch/Tag and fill in the dialog fields with the following:<br />
*** From WC/URL: https://svn.thedarkmod.com/svn/darkmod/branches/release2.0x<br />
*** To Path: /tags/2.0x<br />
*** Log message: Tag for 2.0x release<br />
*** Create a copy in the repository from: HEAD revision in the repository<br />
** Same goes for the darkmod_src repository, just replace /darkmod/ with /darkmod_src/ above.<br />
* Copy package from /usr/local/www/update.thedarkmod.com/ to /usr/local/tdm_releases/2.0x/ for archiving. The next package process will need it there.<br />
** cd /usr/local/tdm_releases<br />
** mkdir 2.0x<br />
** cp -r /usr/local/www/update.thedarkmod.com/* 2.0x<br />
* Copy /usr/local/tdm_releases/1.05/index.html to /usr/local/tdm_releases/2.0x<br />
* Move all differential packages back to /usr/local/www/update.thedarkmod.com/<br />
** <tt>mv /usr/local/tdm_releases/2.0x/tdm_update_1.0*.zip /usr/local/www/update.thedarkmod.com/</tt><br />
** <tt>mv /usr/local/tdm_releases/2.0x/tdm_update_2.0*.zip /usr/local/www/update.thedarkmod.com/</tt><br />
* Copy the one differential update package updating to the new 2.0x version back to /usr/local/tdm_releases/2.0x<br />
** <tt>cp /usr/local/www/update.thedarkmod.com/tdm_update_2.0y_to_2.0x.zip to /usr/local/tdm_releases/2.0x</tt> (y = x-1)<br />
* At this point, the /usr/local/tdm_releases/2.0x folder contains a valid TDM 2.0x release, the one that will be pushed to all the mirrors. Examine it for double safety.<br />
* Examine the upload_to_all_mirrors.sh shell script, to see if it fits your needs.<br />
* Start uploading to all mirrors.<br />
** <tt>./upload_to_all_mirrors.sh 2.0x</tt><br />
* Update tdm_mirrors.txt and tdm_version.xml on thedarkmod.com/update: ask taaaki to do that. The tdm_mirrors.txt file is probably fine, but the tdm_version.xml needs to be updated.<br />
<br />
== Update the Wiki ==<br />
<br />
The wiki contains one page for each release. You can find them all in the [[:Category:What's New]] category. <br />
<br />
First update the current release page:<br />
<br />
* Change the "roadmap" link on the current release to a "changelog" link by swapping ''"roadmap_page.php?version_id=XX"'' with ''"changelog_page.php?version=XX"''.<br />
* Add the ''<nowiki>{{released|2.01|2014-01-30}}</nowiki>'' Template on top of the current release page with the correct date.<br />
<br />
Then add a new page for the next release. To do this, add a link to it in this template: [[Template:Whatsnew]] by editing it. After saving the template, a link to the new release version page appears in the list and in the category. Edit this page and insert some text into it (you can copy it from an older release page).<br />
<br />
Also insert a link to the current roadmap on the bugtracker, you can find out the version_id by looking at [http://bugs.thedarkmod.com/roadmap_page.php the roadmap page].<br />
<br />
= Glossary =<br />
* Release Fileset: the PK4 files forming the actual release. <br />
* SVN: an acronym for Subversion, a version control system<br />
* Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.<br />
* Mirrors: The servers where the PK4 files are stored for download by the updater.<br />
* updater: The TDM Updater executable, used for downloading and updating TDM.<br />
* binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).<br />
* darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.<br />
* branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.<br />
* trunk: The main branch where all the ongoing development is happening.<br />
<br />
{{todo}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=Template:Whatsnew&diff=18094Template:Whatsnew2015-02-08T21:06:09Z<p>Taaaki: </p>
<hr />
<div><noinclude><br />
This template displays a "See also" section with links to other changelogs. Also:{{template-help|name=whatsnew|sort=Whatsnew}}<br />
<br />
Here is a preview:<br />
-----<br />
== See also ==<br />
<br />
* '''[[What's new in TDM 2.03]]''' (Older releases: [[What's new in TDM 2.02|v2.02]], [[What's new in TDM 2.01|v2.01]], [[What's new in TDM 2.00|v2.00]], [[What's new in TDM 1.08|v1.08]], [[What's new in TDM 1.07|v1.07]], [[What's new in TDM 1.06|v1.06]], [[What's new in TDM 1.05|v1.05]], [[What's new in TDM 1.04|v1.04]], [[What's new in TDM 1.03|v1.03]], [[What's new in TDM 1.02|v1.02]], [[What's new in TDM 1.01|v1.01]])<br />
<br />
</noinclude><br />
<includeonly><br />
== See also ==<br />
<br />
* '''[[What's new in TDM 2.03]]''' (Older releases: [[What's new in TDM 2.02|v2.02]], [[What's new in TDM 2.01|v2.01]], [[What's new in TDM 2.00|v2.00]], [[What's new in TDM 1.08|v1.08]], [[What's new in TDM 1.07|v1.07]], [[What's new in TDM 1.06|v1.06]], [[What's new in TDM 1.05|v1.05]], [[What's new in TDM 1.04|v1.04]], [[What's new in TDM 1.03|v1.03]], [[What's new in TDM 1.02|v1.02]], [[What's new in TDM 1.01|v1.01]])<br />
* [http://thedarkmod.com/downloads.php Download TDM]<br />
<br />
[[Category:What's New|{{{sort|{{PAGENAME}}}}}]]<br />
</includeonly></div>Taaakihttps://wiki.thedarkmod.com/index.php?title=Template:Whatsnew&diff=18093Template:Whatsnew2015-02-08T21:05:13Z<p>Taaaki: </p>
<hr />
<div><noinclude><br />
This template displays a "See also" section with links to other changelogs. Also:{{template-help|name=whatsnew|sort=Whatsnew}}<br />
<br />
Here is a preview:<br />
-----<br />
== See also ==<br />
<br />
* '''[[What's new in TDM 2.02]]''' (Older releases: [[What's new in TDM 2.01|v2.01]], [[What's new in TDM 2.00|v2.00]], [[What's new in TDM 1.08|v1.08]], [[What's new in TDM 1.07|v1.07]], [[What's new in TDM 1.06|v1.06]], [[What's new in TDM 1.05|v1.05]], [[What's new in TDM 1.04|v1.04]], [[What's new in TDM 1.03|v1.03]], [[What's new in TDM 1.02|v1.02]], [[What's new in TDM 1.01|v1.01]])<br />
<br />
</noinclude><br />
<includeonly><br />
== See also ==<br />
<br />
* '''[[What's new in TDM 2.03]]''' (Older releases: [[What's new in TDM 2.02|v2.02]], [[What's new in TDM 2.01|v2.01]], [[What's new in TDM 2.00|v2.00]], [[What's new in TDM 1.08|v1.08]], [[What's new in TDM 1.07|v1.07]], [[What's new in TDM 1.06|v1.06]], [[What's new in TDM 1.05|v1.05]], [[What's new in TDM 1.04|v1.04]], [[What's new in TDM 1.03|v1.03]], [[What's new in TDM 1.02|v1.02]], [[What's new in TDM 1.01|v1.01]])<br />
* [http://thedarkmod.com/downloads.php Download TDM]<br />
<br />
[[Category:What's New|{{{sort|{{PAGENAME}}}}}]]<br />
</includeonly></div>Taaakihttps://wiki.thedarkmod.com/index.php?title=What%27s_new_in_TDM_2.04&diff=18092What's new in TDM 2.042015-02-08T21:04:10Z<p>Taaaki: Created page with "<!-- keywords whats new --> See the [http://bugs.thedarkmod.com/roadmap_page.php?version_id=71 roadmap] on our bugtracker. <!--See also the [http://bugs.thedarkmod.com/changel..."</p>
<hr />
<div><!-- keywords whats new --><br />
See the [http://bugs.thedarkmod.com/roadmap_page.php?version_id=71 roadmap] on our bugtracker.<br />
<!--See also the [http://bugs.thedarkmod.com/changelog_page.php?version_id=71 changelog] on our bugtracker.--><br />
{{notreleasedyet|2.04}}<br />
<!--{{released|2.04|2015-xx-xx}}--><br />
<br />
== AI ==<br />
* <br />
<br />
<br />
== Coding ==<br />
<br />
* <br />
<br />
<br />
== Assets ==<br />
<br />
* <br />
<br />
<br />
== GUIs ==<br />
<br />
* <br />
<br />
<br />
== Scripting ==<br />
<br />
* <br />
<br />
<br />
{{whatsnew|sort=204}}</div>Taaakihttps://wiki.thedarkmod.com/index.php?title=What%27s_new_in_TDM_2.03&diff=18091What's new in TDM 2.032015-02-08T20:52:08Z<p>Taaaki: </p>
<hr />
<div><!-- keywords whats new --><br />
<!--See the [http://bugs.thedarkmod.com/roadmap_page.php?version_id=66 roadmap] on our bugtracker.--><br />
See also the [http://bugs.thedarkmod.com/changelog_page.php?version_id=66 changelog] on our bugtracker.<br />
<!--{{notreleasedyet|2.03}}--><br />
{{released|2.03|2015-02-08}}<br />
== AI ==<br />
<br />
* AI will react if they are hit by an opening door (grayman)<br />
* Regular helmets no longer protect sleeping AI from KOs (grayman)<br />
* AI now coordinate their searches when many AI are involved in the same search--some AI will run to guard choke points (grayman)<br />
* New AI barks for AI searching together; new searching animations (Springheel)<br />
* new animation for AI noticing they have been pickpocketed (Arcturus)<br />
* The Lanternbot's whistle will now properly alert nearby AI<br />
* AI are far less likely to see directly behind themselves when turning their head<br />
* Running AI handle doors better<br />
<br />
<br />
== Coding ==<br />
<br />
<br />
* the LOD system has been extended to cover AI and animated objects (SteveL)<br />
* Soft Particles: particle effects will no longer show harsh edges when intersecting geometry (SteveL)<br />
* Water distortion no longer distorts things in front of the water (SteveL) <br />
* The Stats screen now tracks the number of game saves, and mappers can limit number of saves (Obsttorte)<br />
* The skybox used to flash grey when the player clipped into geometry while mantling. This is fixed. (SteveL)<br />
<br />
<br />
== Assets ==<br />
<br />
* numerous new models and skins have been added to the mod (Springheel)<br />
* several new light entities have been added (Springheel)<br />
* A number of entities are now using the LOD system by default, allowing for higher poly models close up (Springheel)<br />
* loot textures have been given more shine to make them a bit easier to pick out (Springheel)<br />
* Many AI use LOD stages to allow for better performance. (Springheel)<br />
* Several AI have had their meshes and textures upgraded (Springheel)<br />
* A new "maiden" vocal set has been added (script: Springheel, vocals: Amber)<br />
* A new female townsfolk AI has been added (Springheel)<br />
* movable candles will now cast a soft shadow when carried (Springheel)<br />
* The spyglass will be properly round regardless of screen resolution (AluminumHaste)<br />
<br />
<br />
== GUIs ==<br />
<br />
* Main menu now lists the currently installed mission (grayman)<br />
* The loading bar now accurate reflects the amount of time it takes a mission to load (grayman)<br />
<br />
== Scripting ==<br />
<br />
* Various script events for string manipulation have been added. (Tels)<br />
<br />
<!--<br />
== Internationalization (I18N) ==<br />
<br />
* Updated the German translation. (Tels)<br />
* Swedish can now be selected in the menu (the translation is still missing). (Tels)<br />
--><br />
<br />
{{whatsnew|sort=203}}</div>Taaaki