611 lines
47 KiB
HTML
611 lines
47 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<title>2021_GAMEiSO.nfo</title>
|
|
<style type="text/css">
|
|
@font-face {
|
|
font-family: nfo;
|
|
font-style: normal;
|
|
font-weight: normal;
|
|
src: url(nfo.eot);
|
|
}
|
|
.nfo {
|
|
padding: 12px;
|
|
font-family: nfo, courier new;
|
|
font-size: 11px;
|
|
line-height: 1em;
|
|
}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<pre class="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 |
|
|
+------------------------------------------------------------------------------+
|
|
</pre>
|
|
</body>
|
|
</html>
|