__ __
+------------------------\/-- G A M E I S O --\/------------------------+
| |
: ________:__ _._______ _ ______.__ _ _________:_ _\/______. :
. / ./\ / + /\+/ ://+____:_/ _./\ ___/X_ //____ .
/ _____/ //_____/ 7// / // _______z/ / / \ __/__ /_
___/. /\___/_/_\____/ // / / __ / / / /_/ / // /____ / /\
\+// / /_ \ _ /+ / / \+/ / /\_\/ / / \/ //_ //\
\/ /_+_/ /\ // /X/ /_____/ / ___/_/_____ /___/ /// / /
/ . / / /________/ /\____/ . / \ __/_\___\ ____ /____/ /
/____/\______/ /\______/ . / / /________\ \ . \/ /\----\____\/\___\/
<<\___\/\_____\/_______/_____/ /____\___/____________\ /\/ /< << ----+\/---- >
- ---------------------\_____\/---------\_____________\/ /\/- ---------------- -
. \/ .
| __ __ |
+--------------------\/-- 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 |
+------------------------------------------------------------------------------+