************************************************
************************************************

Unfortunately, this site has restricted functionality as this browser does not support the HTML button formaction attribute.

Unfortunately, this site has restricted functionality as this browser has HTML web storage turned off.

32451 of 48,116 files

2020 December 31

  • Amiga Text / Community standard
4 items in the archive
  • gameiso-official.game.iso.ruleset.2021.sfv
  • official.game.iso.ruleset.2021.nfo
  • [X] - ( 0M 1F - COMPLETE ) - [X]/
  • gameiso-official.game.iso.ruleset.2021.rar
[+] Configuration Copy text
__ __ +------------------------\/-- 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 -GROUPNAME | | - This is meant for initial, standalone releases of games. | | | | 5.4 .-GROUPNAME | | .-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 .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 .Update.[.incl.DLC]-GROUPNAME | | ..Update[.incl.DLC]-GROUPNAME | | ..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 .CHEAT-GROUPNAME | | - Instructions and/or tools to use already built-in cheats. | | e.g. list of cheatcodes, tools to unlock hidden menus | | | | 5.11 .UNLOCKER-GROUPNAME | | - Used for anything that can normally be unlocked in the game by | | playing or paying. | | .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 .Plus..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 .-GROUPNAME | | - Used for single-language non-english releases. | | | | Examples: | | Title.GERMAN-GROUPNAME | | Title.FRENCH.Plus..Trainer-GROUPNAME | | Title.SPANISH.UNLOCKER-GROUPNAME | | Title.POLISH..Update-GROUPNAME | | | | 5.18 .MULTI-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..incl.DLC-GROUPNAME | | | | VIRTUAL REALITY | | | | 5.19 .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.-GROUPNAME | | WyVRn.VR-GROUPNAME (separate VR tag mandatory) | | The.Kremer.Collection.VR.Museum-GROUPNAME (separate VR tag optional) | | | | INTERNAL | | | | 5.20 .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." 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 .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 .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 .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 .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 .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 .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 .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 .HOTFIX-GROUPNAME | | - Used for relatively small updates without differentiating version | | information. | | | | 8.16 .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 | +------------------------------------------------------------------------------+
official.game.iso.ruleset.2021.nfo 80x586 Font
80