► NFO
__ __ +------------------------\/-- 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 | +------------------------------------------------------------------------------+
► NFO Render
► SFV
Code: Select all
gameiso-official.game.iso.ruleset.2021.rar f410e3a1