Merge branch 'main' into credit-doc

Author: suspect15

docs/.vitepress/config/en.ts

@@ -80,7 +80,7 @@ function sidebarGeneral(): DefaultTheme.SidebarItem[] {
           link: "/general/how-ra-works",
         },
         {
-          text: "Ways to Contribute",
+          text: "How to contribute if you're not a developer",
           link: "/general/ways-to-contribute",
         },
         {

docs/.vitepress/config/es.ts

@@ -88,7 +88,7 @@ function sidebarGeneral(): DefaultTheme.SidebarItem[] {
           link: "/es/general/how-ra-works",
         },
         {
-          text: "Maneras de contribuir",
+          text: "Cómo contribuir si no eres desarrollador",
           link: "/es/general/ways-to-contribute",
         },
         {

docs/developer-docs/console-specific-tips.md

@@ -143,8 +143,29 @@ Checks if the 8-bit value at 0x18BAB5 is equal to 0x20. This means 0x18BAB5 cont
 
 ## GameCube
 
-- Serial is located at **0x00000000** as a string of ASCII characters. Revision Number seems to typically be stored at **0x00000007**. You can use these to determine the specific disc loaded.
+- Identification of the game/disc:
+   - Serial is located at **0x00000000** as a string of ASCII characters.
+   - Disc Number (for multidisk games) is stored at **0x80000006**. (0 = Disc 1)
+   - Revision Number is stored at **0x00000007**.
+   - You can use these to determine the specific disc loaded.
 - GameCube uses a PowerPC chipset with big-endian data. Filter using `16-Bit BE`, `32-Bit BE`, `Float BE`, and `Double32 BE` for data types wider than 1 byte (8-bits). Data is typically aligned on Gamecube, so 16-Bit data is always at an even address and 32-bit data addresses at a multiple of 4, etc.
+- Gamecube has one bank of RAM, 24MB, located at `0x80000000-0x817FFFFF`, which is mapped at `0x00000000-0x017FFFFF` in the RA toolkit.
+   - Therefore, pointers found will start with 0x8, and to use them, you can mask them using `0x1fffffff` to convert to RA addressing.
+   - `Add Address 32-Bit BE Pointer & 0x1fffffff`
+   - Uncached mirror of the RAM exists as well at `0xC0000000`. If you happen to find pointers that begin with 0xC, the same masking scheme will work to convert them to the RA addressing.
+
+## Wii
+
+- Identification of the game/disc:
+   - Serial is located at **0x00000000** as a string of ASCII characters.
+   - Disc Number (for multidisk games) is stored at **0x80000006**. (0 = Disc 1)
+   - Revision Number is stored at **0x00000007**.
+   - You can use these to determine the specific disc loaded.
+- Wii uses a PowerPC chipset with big-endian data. Filter using `16-Bit BE`, `32-Bit BE`, `Float BE`, and `Double32 BE` for data types wider than 1 byte (8-bits). Data is typically aligned on Wii, so 16-Bit data is always at an even address and 32-bit data addresses at a multiple of 4, etc.
+- Wii has two banks of RAM, 24MB called "MEM1" located at `0x80000000-0x817FFFFF`, which is mapped at `0x00000000-0x017FFFFF` in the RA toolkit, and 64MB called "MEM2" located at `0x90000000-0x93FFFFFF`, which is mapped at `0x10000000-0x13FFFFFF` in the RA toolkit.
+   - Therefore, pointers found will start with 0x8 or 0x9, and to use them, you can mask them using `0x1fffffff` to convert to RA addressing.
+   - `Add Address 32-Bit BE Pointer & 0x1fffffff`
+   - Uncached mirrors of MEM1 and MEM2 exist as well at `0xC0000000` and `0xD0000000`, respectively. If you happen to find pointers that begin with 0xC or 0xD, the same masking scheme will work to convert them to the RA addressing.
 
 ## Neo Geo
 

docs/developer-docs/devquests.md

@@ -37,6 +37,7 @@ DevQuests are achievement development-related quests that Developers can take pa
 2. The following do not count toward the total: Network issues, tickets for achievements you developed, tickets you opened, tickets closed on behalf of Junior Developers, and tickets closed as a result of ticket spamming.
 3. May not overlap with DevQuest 002 or with any completion requirements for DevQuest 013.
 4. Tickets for users banned from development count for double credit.
+5. Up to 10 "unsupported core/emulator" tickets may be used across DQ1 and its sequels. If you have closed 10 in this fashion, no more of this type shall count. The DQ Team shall highlight these tickets using purple on the tracking sheet.
 
 ### 002 [Retro Renovator](https://retroachievements.org/game/15957)
 
@@ -430,6 +431,8 @@ You must have made sets for at least 15 subgenres before opt-in. To opt-in, make
    - [No Dynamic RP](https://retroachievements.org/game/3083)
    - [Player-Input RP](https://retroachievements.org/game/28506)
    - [Single Save Support](https://retroachievements.org/game/28449)
+   - [Outdated Version](https://retroachievements.org/hub/29482)
+      - If you identify a set you believe should qualify for a task like this, simply request approval from the team. Providing support to an updated version of a hack, homebrew or language patch will yield 1 point regardless of if it was tagged as outdated, provided the update required actual logic updates and/or adding achievements to cover added content.
 4. No collaboration allowed.
 5. This quest does not stack with other revision DevQuests. If a set would also be eligible to DQ2 or DQ13 those quests will take priority.
 6. Sets are subject to DevQuest team approval, along with a small plan on what the dust-off will be about. Sets already in the approved DQ22 list do not require approval, only notification.
@@ -453,6 +456,28 @@ You must have made sets for at least 15 subgenres before opt-in. To opt-in, make
    - You can see this list on the `Quest23: Elligible Games Lists` sheet within the DevQuest Sheets document.
 6. You may swap lists with other participants. All participants must confirm the swap before it is performed. Muti-way swaps (three or more developers) are allowed. Swapping will reset your three-month respin timer.
 
+### 024 [She's Got This!](https://retroachievements.org/event/186-devquest-024-shes-got-this)
+
+![DQ024](https://media.retroachievements.org/Images/118081.png)
+
+**Type**: Set Creation  
+**Goal**: Publish two new sets featuring a female character as the primary protagonist!  
+**Repeatable**: No
+
+1. Sets intended for this quest must be complete and encompass all notable content specific to the game.
+2. Hacks are allowed, but the original game must **not** have a female character as the primary protagonist.
+   - Sets for small hacks will be scored as a half point.
+3. Homebrew is allowed
+   - Sets for small homebrew games will be scored as a half point.
+   - Up to one point can be from homebrew.
+4. Collaborations are allowed. A set done as a collaboration will be scored as a half point for any collaborator receiving credit towards this quest.
+5. The primary protagonist must be clearly identified as a female character somewhere in the game.
+   - Games without a clear singular protagonist are allowed as long as a clear majority of the protagonists, i.e.: About 2/3 of the protagonists driving the story, plot, or game action should be clearly identified as female characters.
+   - Any characters falling into such protagonist roles should be player-controllable.
+   - Games where the player creates an avatar do not count the avatar as a female protagonist unless the avatar is required to be female.
+   - When in doubt, please reach out to the DevQuest team.
+6. Each point of credit (equivalent to one set) must have a different female character as the protagonist (or different ensemble of female characters)
+
 ## Wheel Spin DevQuest Rules
 
 1. You may respin 3 months after you spin. This requires and consumes your respin token for that quest

docs/developer-docs/jr-dev-rules.md

@@ -15,7 +15,8 @@ The purpose of the Junior Developer Program is to assist interested people with
 
 To join the Junior Developer Program, the following requirements must be met:
 
-- RetroAchievements account must not be banned or suspended from achievement development or involuntarily untracked from competitive leaderboards
+- Must be familiar with how RetroAchievements sets are structured: this means having an account that is at least 3 months old and have at least 3,000 points. As sets must be designed with hardcore in mind, hardcore points are preferred but not obligatory
+- Cannot be banned or suspended from achievement development or involuntarily untracked from competitive leaderboards
 - Have a Discord account verified on the [RetroAchievements Discord server](https://discord.gg/dq2E4hE)
 - Request the Junior Developer role in #role-request channel in the General section of the RA Discord server
   - Include your RA profile link
@@ -36,7 +37,7 @@ Note: New Junior Developers who had a set plan approved when requesting to join
 
 If a Junior Developer needs to extend their claim beyond 3 months, they need to make a progress report on the official forum for the game in accordance with [Claims System rules for extending a claim](/guidelines/developers/claims-system.html#extending-a-claim).
 
-Prior to a second extension (at the six-month mark) as well as further extensions, a detailed progress report must be sent to the [Code Review Team](https://retroachievements.org/messages/create?to=CodeReviewTeam) for approval before the extension is made. The team may deny the extension in cases where progress is insufficient. 
+Prior to a second extension (at the six-month mark) as well as further extensions, a detailed progress report must be sent to the [Code Review Team](https://retroachievements.org/messages/create?to=CodeReviewTeam) for approval before the extension is made. The team may deny the extension in cases where progress is insufficient.
 
 When a junior set is marked as In Review, the claim will be renewed automatically when it would normally expire. While progress reports on forums are not necessary for such extensions, potential players usually appreciate the update.
 
@@ -62,6 +63,7 @@ The following rules apply to all Junior Developers:
   - Must make a subset request in ⁠#jr-devs-requests which includes a set plan. If approved, the subset is subject to [Subset Rules](/guidelines/content/subsets)
     - May request to create a subset in addition to a primary claim if both are for the same game
 - May make a maximum of 1 set for a hack during the program
+- Developers of hacks and homebrews may not work on their own games during the program
 
 ### Ticket Handling
 
@@ -89,10 +91,15 @@ Junior Developers are required to ensure sets they submit for Code Review are of
 
 Participation in the Junior Developer Program is not an entitlement or right. Junior Developers are expected to take the program seriously, put forth significant effort, seek assistance when unable to figure something out, strive to make the highest quality set possible and maturely accept and apply Code Reviewer feedback. Junior developers may be temporarily or permanently removed from the program for the following reasons:
 
-- Violations of the RA Developer Code of Conduct or the rules set forth within this document
+- Violations of the [RA Developer Code of Conduct](/guidelines/developers/code-of-conduct) or the rules set forth within this document
 - 1 month of [inactivity](/guidelines/developers/code-of-conduct#inactivity) in either active development or RA in general
+  - This does not apply if your set is in the review backlog or under current review
   - First time inactivity removals may request immediate restoration of Junior Developer role
-  - Subsequent inactivity removals will be subject to a 30-day cool down, beginning upon demotion action. After cool down, must submit a full rejoin request per [Entry Requirements](#entry-requirements)
+  - Subsequent inactivity removals may, at Code Reviewer discretion, be subject to a 30-day cooldown (beginning upon demotion action) prior to being able to rejoin the program
+- Holding a claim for 1 month without progress
+  - This does not apply if your set is in the review backlog or under current review
+  - You must push code notes, assets, or game page updates to the website in order for this timer to reset. Simply opening the game will not count
+  - If you are removed on this basis and wish to rejoin the program, you will be required to provide a progress report and either push any local work to the website or provide your `GameID-User.txt` file upon role request
 
 ### Graduation Consideration
 

docs/developer-docs/rollouts.md

@@ -27,20 +27,24 @@ It's worth noting that these are general guidelines that apply to all rollouts.
 
 - Since the overall goal of a rollout is to provide sets to launch with a console's support, developers who go inactive or otherwise end up not working on the chosen sets will have their claim lapsed. In other words, claiming a set just to sit on it will not fly and will result in a lapse.
 
+- If a primary rollout claim is dropped during the rollout, this claim becomes temporarily unavailable. The rollout team will bring this claim up with all rollout participants, and developers interested will be put in a lottery. Of course, your current priority claim must still be finished before you are able to take this one on. Like regular claims, if there is suspicion of claim hogging with the intention to have a friend claim it, you will be removed from participating in the rollout and will be met with a penalty for the next rollout.
+
+- If one of your rollout claims is a collab, where one of the participating developers has the intention to work on one or multiple subsets while the other developer has no interest, the claim will be freed up for them once the core set has been signed off. Of course, the developer intending to work on subsets must still prioritize finishing the core set to prevent other developers from being unable to develop other games. If this is not the case, the collab partner can reach out to the rollout team.
+
 - If problematic behavior occurs during a rollout, such as refusing cooperation with the involved teams or causing issues for fellow developers, the Rollout Team may implement remediation measures. These may include lowering priority for claim selection in future rollouts, or removing claims during the current rollout.
 
 ## Rollout Process
 
 - **Step 1: Proposal for New Integrations** - The admin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted.
 - **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can take months or even years.
 - **Step 3: Integration Testing** - The Rollout Team tests the new support for any issues and provides feedback to the integration developers. A public test may also occur during this step to solicit feedback from all achievement developers.
-- **Step 4: Rollout Selection** - Once the Rollout team and RAdmin are satisfied with the integration, developers are contacted privately by the Rollout Team about their interest in joining. Developers will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows:
+- **Step 4: Rollout Selection** - Once the Rollout team and RAdmin are satisfied with the integration, developers are contacted privately by the Rollout Team about their interest in joining. Developers will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery draft and selected by priority, which goes as follows:
   - 1: Developers who have participated in the previous rollout and released their set(s) on time, and (new) developers who have never participated in any rollout prior.
   - 2: Developers who did not participate in the previous rollout, but were involved with other rollouts.
   - 3: Developers who, in the last rollout they participated in, received a large number of tickets or potential set demotion, or released their rollout set long beyond the rollout's end date. This priority level will be judged on a case-by-case basis.
   - 4: Developers who have at least one open ticket with no work done on it for over a month.
 - **Step 5: Selection Planning** - The Rollout Team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are limited to one priority claim (either solo or collaborative), but may join another developer's primary claim if they are looking for collaboration partners, one at a time.
-- **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. RAdmin will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The Rollout Team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be the **actual release date** of the new system's/emulator's support, but if unexpected issues arise, this release date may be extended. If this happens, developers will be informed well in advance.
+- **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. RAdmin will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The Rollout Team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be the **actual release date** of the new system's/emulator's support, but one month before the release date, the developers will be polled to discuss if they agree that the rollout meets technical expectations. If this is not the case, the date can potentially be pushed back.
 - **Step 7: Set Development** - Developers start working on their claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the Rollout Team. If a priority pick was not provided to the Rollout Team during Step 4, developers may now reach out to the Rollout Team to request a set to work on.
 - **Step 8: Sign-Off** - Developers submit their finished claims for review by pinging the Writing Team for an initial check to make the set compliant with the [Writing Policy](/guidelines/content/writing-policy). A member of the Writing Team will discuss any necessary changes with you privately, so be sure to allow them this space, such as private messaging through Discord. Once their check has finished, they will then ping the Rollout Team who will check for the [Achievement Set Requirements](/guidelines/content/achievement-set-requirements). Note: collabs can be signed off only after every collaborator has finished their part.
 - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time.

docs/es/general/about-us.md

@@ -7,7 +7,7 @@ description: Explora la historia y los roles dentro de la comunidad de RetroAchi
 
 ## Equipo RA
 
-El proyecto RetroAchievements comenzó como un proyecto personal de [Scott Breen](http://scottbreen.info/) y en los primeros días el proyecto solo tenía administradores, creadores de logros y usuarios regulares (y todavía es así en el sitio web). En ese momento, los administradores eran responsables de hacer cosas como:
+El proyecto RetroAchievements comenzó como un proyecto personal de [Scott Breen](http://scottbreen.info/) y en los primeros días el proyecto solo tenía administradores, creadores de logros y usuarios regulares. En ese momento, los administradores eran responsables de hacer cosas como:
 
 - Echarle un ojo en la calidad de los logros.
 - Echarle un ojo si alguien está cambiando los logros de otras personas (accidental o intencionalmente).