xREL.v3

G  A  M  E   I  S  O



R E L E A S E  R U L E S

| After approximately 20 years without new, written rules for the PC games
| section the leading Game ISO groups assembled to collaborate on a long
| overdue modernization.
| The following chapters and paragraphs describe the methods used to release
| ISO games. 0day Game Rips are not regulated by this document.

| This 2021 ruleset supersedes all previous rules regarding ISO games.

| I. RELEASE PACKAGING

|  1.1 All unmodified, original game files have to be packed into an archive
using any format and compression level the group prefers. This archive  |
is accompanied by an installer that extracts the files to a location
chosen by the user.

|  1.2 In case a game is being offered with different filesets for 32-bit and  |
64-bit systems, only the 64-bit fileset is mandatory to be included.
The 32-bit fileset may be included in the same release if the group so  |
chooses or it may be pred as a separate release, even by another group. |

|  1.3 Optionally the archive may also contain an extra folder with
redistributables that are necessary for the game to run.

|  1.4 In case the game is being distributed in a packaged form it is at the
group's discretion to either use the files as-is or to repackage the
game files with a custom installer following the rules outlined above.  |

|  1.5 The crack files have to be placed outside the installation archive
into a separate folder that is labeled with the group's name or
"Crack".

|  1.6 The archive, installer and crack folder have to be authored into an
ISO file complying with either the ISO 9660 standard (including any
extensions needed to store the contained files correctly) or the UDF
standard (any revision).
The ISO file's label field has to contain the game's name as closely
to the original name as possible given the format's character set and
field size restrictions.
The ISO file's extension must be ".iso".

|  1.7 The ISO file has to be packed into a RAR archive using the RAR4 or the  |
RAR5 format and the old style volume naming scheme.
e.g. grp-gamename.rar, grp-gamename.r00, grp-gamename.r01,

|  1.8 No additional unrelated or useless data may be added to the
installation archive, the ISO file or the RAR archive.

|  1.9 Releases that do not function as full, standalone games have to
contain only the files necessary to fullfill that release's task.
The files must not be authored into an ISO file, but put into the
RAR archive directly.

| 1.10 Allowed RAR archive volume sizes for standalone game releases:
(MB = megabyte = 1,000,000 bytes)

ISO file size                RAR volume size
up to      700 MB          15,000,000 bytes
700 MB,   4700 MB]         50,000,000 bytes
4700 MB,   8500 MB]        100,000,000 bytes
8500 MB,  13200 MB]        150,000,000 bytes
13200 MB,  17000 MB]        200,000,000 bytes
17000 MB, 225250 MB]        250,000,000 bytes
(225250 MB,  infinity]        500,000,000 bytes

| 1.11 Allowed RAR archive volume release sizes for all other release types:

data size                RAR volume size
up to     100 MB            5,000,000 bytes
bigger than  100 MB        same sizes as per 1.10

| 1.12 For standalone game releases the minimum combined size of all RAR
volumes is 400,000,000 bytes. Other release types do not have a
minimum size requirement.

| 1.13 Allowed compression methods for the RAR archive are fastest (m1),
fast (m2), normal (m3), good (m4) and best (m5).
Store (m0) is forbidden and must not be used.

| 1.14 Encryption or password protection is not allowed.

| 1.15 The final release directory may contain only the following items:
RAR archive volumes
NFO file (singular)
SFV file (singular)

| II. NFO

|  2.1 The NFO has to contain the following information:
Group name and/or logo
Game name
Game protection
Link to the game's store page and/or official website (optional)
Brief game description
Installation intructions
List of included DLCs (optional for initial release)
Patchlevel/installed updates (optional)
List of required previous releases (for non-standalones)
List of included languages (MULTI releases only)

| III. DIRECTORY / FILE NAMING

|  3.1 Single punctuation must be used.
Consecutive punctuation is not allowed.
Only dots and underscores are allowed as whitespace replacements.

Negative examples:
Awesome.-.Game-GRP, Another.Game.-GRP, grp--gamename.rar
Awesome_-_Game-GRP, Another_Game_-GRP, grp__gamename.rar

|  3.2 Allowed characters in directory names:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789.-_

|  3.3 If a game's name contains other characters than the ones listed above
then they can either be omitted or be replaced by lookalike characters. |
If that leads to a directory name that would not identify the game
properly then romanisation, common descriptions or official unicode
descriptions may be used.

|  3.4 Allowed characters in file names:
abcdefghijklmnopqrstuvwxyz      (only lowercase for files)
0123456789.-_

|  3.5 The file names of the RAR files and the SFV file must be prefixed with  |
the group's name or tag and have matching stems in a single release.
(stem = filename without extension)
RAR and SFV file names have to be globally unique.
e.g. grp-crysis7.rar, grp-crysis7.sfv

| IV. EXCLUSIVITY

|  Digital distribution becoming the standard for PC games has caused the
|  number of published updates and other additional content to rise
|  considerably. This has led to a lot of standalone releases containing
|  relatively little actual new data but lots of dupe data.
|  To prevent a specific class of those releases a limited time exclusivity
|  right is introduced.

|  4.1 The group that won the race for a new game or new paid content earns
the exclusive right to pre free updates/DLC and other specific new
content for that game (see lists below).

|  4.2 Each time the game receives a free update/DLC or other eligible content |
a 60 day period* begins in which only the group currently owning the
right is allowed to pre it.
plus the period between time of publication and 00:00 UTC+0)
If multiple updates etc. are published by the developer within that
period, the group does not have to match each publication with releases |
of their own but can combine consecutive updates/DLC into custom
releases as they see fit. However this does not change the end point of |
the exclusivity period started by the first publication.

|  4.3 If the group pres the content within the aforementioned period, the
exclusive right to pre future content for this game remains with that
group.
If the group fails to do so, the right is forfeited and a free-for-all  |
race for the new update/content starts.

|  4.4 Paid content is exempt from this rule and starts a new race except if
it is one or a combination of the following:
In-game cosmetic items like armor, weapons, skins and/or any other
visual only content
Non-game files such as artbooks, wallpapers, videos, music and/or
game guides and similar

|  4.5 Examples of paid content that explicitly does start a new race:
New missions, levels, tracks which actually add to the main game
experience
Remastered/enhanced game versions featuring improved/reworked
graphics and/or sound

|  4.6 The right is only valid for the specific installation type regarding
the bitness and included languages of the winning release.
If the game can also be released as MULTI then the right to that
language combination must be won in a separate race. The same is
true for foreign, single-language releases.
If languages are added to the standard English installation, those
updates are exclusive to the group who currently owns the right for
that release type.
The exclusivity right either covers both 32-bit and 64-bit together
or separately, depending on the release type chosen by the group(s).  |
For more info see rule 1.2 and rules 5.15-5.18.

|  4.7 Releases of non-final versions of a game do not grant the right.

| V. RELEASE TYPES

|  5.1 Every game and every addon/DLC that are non-free can be released.
Free addons/DLC can either be released for already existing releases
of the non-free base game or, if no such release exists yet,
integrated into the base game as a standalone release.
Free games can be released only if the release also contains non-free
addons/DLC.

|  5.2 A game is considered final, and therefore good to be released without
any non-final tags, when there are no indications inside (e.g. version  |
number) or outside the game (e.g. store page, dev communication) that
point to a non-final state (Early Access, Alpha, Beta).
If the indications are ambiguous, a group may take the risk of preing
a mistagged, non-final game that can be nuked and propered or repacked  |
in case the game files change before the true state of the game
becomes clear.

|  STANDALONE GAMES

|  5.3 <Game name>-GROUPNAME
This is meant for initial, standalone releases of games.

|  5.4 <Game name>.<DLC/update name>-GROUPNAME
<Game name>.<version info>-GROUPNAME
These are meant for subsequent full releases of games including one
or more DLCs or updates where a normal DLC or update release without  |
the base game would be unfeasible or absurd.

|  5.5 <Game name>.x86-GROUPNAME
Releases that contain only the 32-bit files for a game that is
offered in both 32-bit and 64-bit variants separately have to
include this tag in the directory name.
Allowed only if the 32-bit files have not been included in a
previous release yet and only after the 64-bit files have been
released.

|  5.6 Re-releasing a game as a standalone is also allowed if one or more of
the following conditions is met:
Combined size of needed updates is larger than 1/2 of the last
standalone release.
Number of needed updates is 4 or more.

|  5.7 Renamed games that contain changed files can be released as a new
standalone by the group that currently owns the exclusivity right for
that title (see chapter IV.).
If the renamed game does not have changed files only a simple DIRFIX
may be pred.

|  UPDATES / DLC

|  5.8 <Game name>.Update.<version>[.incl.DLC]-GROUPNAME
<Game name>.<version>.Update[.incl.DLC]-GROUPNAME
<Game name>.<DLC name>.DLC-GROUPNAME
These are meant for traditional update and DLC releases that can be
applied to an already installed base game. They may add new files
and patch/remove already present files. The crack has to be included  |
in a separate folder.
Changelogs/patchnotes are optional.

|  5.9 Updates can only be pred for valid releases (non-nuked, non-propered).  |
If a group wants to pre an update for one of their own releases that
is nuked but can be fixed, it has to be fixed first.

|  DOX

| 5.10 <Game name>.CHEAT-GROUPNAME
Instructions and/or tools to use already built-in cheats.
e.g. list of cheatcodes, tools to unlock hidden menus

| 5.11 <Game name>.UNLOCKER-GROUPNAME
Used for anything that can normally be unlocked in the game by
playing or paying.
<Game name>.DLC.UNLOCKER-GROUPNAME
Unlocker explicitly for DLCs, e.g. when only some additional crack
files and/or an entry in the crack config is needed.
Should not contain any new game files. If those are needed too,
use an update or DLC release instead.

| 5.12 <Game name>.Plus.<AMOUNT OF OPTIONS>.Trainer-GROUPNAME
There is no time limit for trainer releases.
The trainer has to work with the latest pred version of the game
title. Releasing trainers for past versions or new versions that are  |
officially available but have not yet been pred is not allowed.
New trainers have to include at least 1 previously unreleased option  |
for the same game version.

| 5.13 Anything that adds value to the original release like keygens, covers,  |
guides or language changers is allowed.

| 5.14 DOX for non-final releases (alpha, beta, early access, ...) is not
allowed.

|  FOREIGN / MULTI

| 5.15 Games that are not playable in English are considered foreign and have  |
to be tagged according to the rules below.
Language-neutral games are not considered foreign.

| 5.16 If a game is playable in English but it's not enabled by default,
the group must include appropriate tools and/or instructions on how to  |
enable it by hand.
Such games are not considered foreign and therefore do not require
language tagging.

| 5.17 <Game name>.<language>-GROUPNAME
Used for single-language non-english releases.

Examples:
Title.GERMAN-GROUPNAME
Title.FRENCH.Plus.<AMOUNT OF OPTIONS>.Trainer-GROUPNAME
Title.SPANISH.UNLOCKER-GROUPNAME
Title.POLISH.<version>.Update-GROUPNAME

| 5.18 <Game name>.MULTI<number>-GROUPNAME
Used for multi-language releases that include languages normally not  |
available in an official English installation (if the game is
distributed as loose files) or installer (if the game is distributed  |
in a packaged form).
The number after MULTI denotes the count of different languages
contained in the release.
MULTI releases must contain at least one previously unreleased
language.

Examples:
Title.MULTI3-GROUPNAME
Title.MULTI7.Update.<version>.incl.DLC-GROUPNAME

|  VIRTUAL REALITY

| 5.19 <Game name>.VR-GROUPNAME
This tag has to be used for games that can only be played with a
virtual reality headset.
If the official game name already includes this tag as a separate
word, repeating it is not required.

Examples:
Half-Life.Alyx.VR-GROUPNAME
Half-Life.Alyx.VR.Update.<version info>-GROUPNAME
WyVRn.VR-GROUPNAME (separate VR tag mandatory)
The.Kremer.Collection.VR.Museum-GROUPNAME (separate VR tag optional)

|  INTERNAL

| 5.20 <Release name>.INTERNAL-GROUPNAME
This tag can be used for a wide variety of releases like:
Internal tools, software which is not retail, titles with custom
modifications made by the group, etc.
Releases whose cracks do not fully respect chapter VII.
(stolen stuff is not allowed under any circumstances)
Releases of this type may only be nuked if they do not work as
advertised

|  ADDITIONAL TAGGING

| 5.21 Groups may use extra TAGS for their releases if they feel the release
types listed in this document do not adequately describe the content.
e.g. READ.NFO, READNFO, REAL, LANGUAGE.PACK, TEXTURE.PACK,

| 5.22 Directory names for standalone releases must not contain
"incl.<something>" tags.

| 5.23 Tags that indicate the store where the game was bought/downloaded from  |
are allowed only if they are part of the official game name.

| VI. Alternative OS releases

|  Releases intended for platforms other than Microsoft Windows generally
|  follow the same rules with the exceptions listed below.

|  6.1 Releases for other platforms have to include a platform tag.
e.g. Some.Game.Linux-GROUPNAME, Other.Game.MacOS-GROUPNAME
The legacy tag MacOSX is not allowed anymore.

|  6.2 Packing game files into an installer/archive combination is optional.

|  6.3 MacOS releases may contain an Apple Disk Image file (.dmg) instead of
an ISO file.

|  6.4 Groups can choose to skip creating the image file altogether.
In that case the final rar volumes will include:
Game.Name-GROUPNAME directory containing untouched game files
Crack/group folder containing needed crack files

| VII. CRACKS

|  7.1 Stolen cracks are strictly forbidden.

|  7.2 It is forbidden to crackfix/repack releases that contain stolen
cracks.

|  7.3 Using a similar method to an already existing crack is allowed as long  |
as no code or data in whole or in part is copied.

|  7.4 Loaders are banned. In-memory patching is allowed.
Loader = a non-game executable/script that uses a separate process to
modify the game before or while the original game code is running.

|  7.5 Parts of a demo, alpha, beta, early access version (or similar
pre-final access programs) or a completely separate game may not
be used to create a crack.

|  7.6 Cracks must support the following, fully updated operating systems,
given that the non-cracked version does:
Windows 8.1 or later
MacOS 10.11 or later
Linux : no special requirements
Supporting operating systems whose development has been discontinued
by the vendor (reached End Of Life) is optional.

|  7.7 Nuking for bad crack or stolen crack must include proof.

|  7.8 Game code that is not connected to the protection may also be altered
if this leads to an improvement of the user experience.

|  7.9 Only use cracks from other groups with permission.

| 7.10 Private tools may only be used with the author's permission.

| 7.11 It is allowed to use tools or code snippets placed under public
domain in order to create the crack.

| 7.12 Code and data related to the crack can be protected by the group
however they wish as long as it does not impair the user experience.

| 7.13 Cracks that introduce new kernel components are not allowed.
(e.g. Windows drivers, Linux kernel modules, MacOS kernel extensions)

| 7.14 Binding network sockets to anything else than the local loopback
addresses must be clearly documented in the NFO.

| VIII. PROPER / REPACK / FIXES

A release can be affected by flaws of three different types:
Type 1: Major technical flaw that allows other groups to pre a proper
release.
Type 2: Minor technical flaw that does not allow other groups to act,
but requires actions from the original group.
Type 3: Cosmetic flaw that does not impair the overall functionality of
the release.

|  8.1 List of Type 1 flaws:
The crack does not adhere to the expected quality (see chapter VII.)  |
One or more necessary files of the advertised game are missing from
the release
The release cannot be extracted/installed correctly
Completely wrong directory name
Missing or bad RAR volumes / SFV file
Release does not work offline
Packing RAR volumes with store (m0) preset

|  8.2 List of Type 2 flaws:
File names of RAR volumes or the SFV are not globally unique
Typos in release directory name
Erroneous or completely wrong NFO

|  8.3 List of Type 3 flaws:
Bad shortcut after installation
Audio/video glitches during the installation process
Bad ISO label

|  8.4 Bugs that are also present in the same, non-cracked version of the
game do not justify a proper. Correcting errors from the original
developers is outside the scope of a scene release.

|  8.5 Buttons, menu entries or any other user interactions that redirect to
or access external, online-only or network resources may not be used
as a proper reason, unless they softlock or hardlock the game.

|  8.6 When a release is nuked with grp.req then the first subsequent,
flawless release of the same game by another group does not have to
include the PROPER tag in the dirname.

|  8.7 <Release name>.PROPER-GROUPNAME
If a release suffers from a T1 flaw, another group may pre a proper
version of it and the flawed release shall be nuked.
A group must not proper itself. To correct own mistakes, repacks
and/or fixes must be used.
The proper reason must be stated in the NFO and should be
comprehensible to non-crackers if the technical situation allows it.  |
A PROPER must be released for the same game version as the flawed
release.

|  8.8 <Release name>.REPACK-GROUPNAME
If a release is affected by a T1 or T2 flaw and a fix would not
remedy the problem, the original group may pre a repack.
Additionally a group may pre a repack of any of its releases for any  |
reason except if the release in question has been propered by
another group with a technically flawless release.
If the repack is technically flawless, the original release shall be  |
nuked.
The repack reason must be stated in the NFO.

|  FIXES

|  8.9 Releasing a technically flawless fix for a flawed release entails
that the possibly nuked original release shall be unnuked.

| 8.10 <Release name>.CRACKFIX-GROUPNAME
In case the crack of a release is technically flawed, the affected
group may pre a crackfix. It contains only the new crack files.
If the game files have to be re-released too, a repack must be pred.  |
The reason for the crackfix must be stated in the NFO.
A group may only pre a CRACKFIX for its own releases.

| 8.11 <Release name>.PROPER.CRACK-GROUPNAME
In case the crack of release is technically flawed, a different
group may pre a proper crack. It contains only the new crack files.
If the proper crack is valid the original release is considered
valid too and shall be unnuked.
The reason for the proper crack must be stated in the NFO.
A group may only pre a PROPER.CRACK for releases of a different
group.

| 8.12 <Release name>.CRACK.ONLY-GROUPNAME
When a group thinks they have a better crack for an already existing  |
release by another group but the other crack is valid, they can use
this release type to show their skills.

| 8.13 <Game name>.MULTIPLAYER.CRACK-GROUPNAME
Used for special cracks that enable online multiplayer functionality. |
The method for achieving this functionality must be described
clearly in the NFO, so the user may assess associated risks.
Usage of unique credentials, either supplied by the user or
hardcoded into the crack, is not allowed.

| 8.14 <Release name>.DIRFIX-GROUPNAME
Used to correct typos in the directory name of the original release.  |
Releasing a game with a directory name of a completely unrelated
game is not considered a typo.
The fixed release must be stated in the NFO.
DIRFIX to alpha/beta/internal/early access is not allowed.

| 8.15 <Release name>.HOTFIX-GROUPNAME
Used for relatively small updates without differentiating version
information.

| 8.16 <Release name>.NFOFIX-GROUPNAME
If the NFO contains mistakes, the group may pre a corrected version.  |

| 8.17 RARFIX and SFVFIX are absolutely not allowed. A REPACK/PROPER of the
release is required.

| IX. DUPE

|  9.1 If a release contains exactly the same files as a combination of
previous releases (except store specific data) the newly pred release
is considered a dupe and shall be nuked.

|  9.2 If the chronological order is clear and consistent across presites and  |
prebots, the first release wins no matter how small the difference in
release times may be.
If it is unclear which group won a race because timing data from
presites and/or prebots is ambiguous then the pred releases that do
not exhibit any technical flaws (T1/T2) are not considered dupes and
shall not be nuked for that reason.
In situations like this the race is not considered to be over, none of  |
the groups earned the exclusivity right from chapter IV.
The race will be called by the first unambiguously decidable win of
an update/DLC related to the game in question (paid or free).

|  9.3 Non-English language standalone releases are considered dupes if a
MULTI tagged release containing the same language was already pred.

Signed (in alphabetical order)

ACTiVATED  ANOMALY  CODEX  CPY  DARKSiDERS  DINOByTES  DOGE  HOODLUM

I_KnoW  PLAZA  Razor1911  RazorDOX  RUNE  SKIDROW  TiNYiSO  VREX

Compliance with this document is mandatory as of 2021-01-01 00:00:01 UTC