PretendoNetwork/.profile
Watch
1
0
Fork
You've already forked .profile
 0
Code Issues Projects Releases Packages Wiki Activity

Merge pull request #64 from PretendoNetwork/templates

Browse source
This commit is contained in:
Jonathan Barrow 2024-05-31 10:54:27 -04:00 • committed by GitHub
commit acab5470a2
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
12 changed files with 996 additions and 495 deletions
Download patch file Download diff file Expand all files Collapse all files

0
CODE_OF_CONDUCT.md → .github/CODE_OF_CONDUCT.md vendored
View file

120
.github/CONTRIBUTING.md vendored Normal file
View file

@ -0,0 +1,120 @@
# How to contribute
Thank you for showing interest in contributing to Pretendo Network! As an open source project, Pretendo Network welcomes contributions from developers outside of our core team. We are a large project, made up of over 100 different repositories spanning various languages and scopes. For the sake of consistency and maintainability, we have created these guidelines to outline project goals, standards, and best practices. This document will cover both code contributions as well as going over how to report any bugs or issues with a service or documentation. By adhering to these guidelines, contributors can ensure that their contributions align with the project's vision and meet the quality standards expected by the community.
### Contents
- [Prerequisites](#prerequisites)
- [Questions and Contact](#questions-and-contact)
- [Finding Work](#finding-work)
- [Making Issues](#making-issues)
- [Code Changes](#code-changes)
- [Consistency](#consistency)
- [Quality and Substance](#quality-and-substance)
- [Commits](#commits)
- [Scale and Scope](#scale-and-scope)
- [Messages](#messages)
- [Pull Requests](#pull-requests)
- [Tests](#tests)
- [Licensing](#licensing)
# Prerequisites
Before diving into the contribution process, we recommend familiarizing yourself with our project's existing repositories. By studying our existing codebases, issues, and pull requests you will get a better sense of direction of how we operate. Additionally, please review our [Code of Conduct](CODE_OF_CONDUCT.md) to ensure a respectful and inclusive environment for all participants.
Given that our project's main goal is to emulate Nintendo Network, it is also highly recommended that you familiarize yourself with how these services operate. Information on these topics, and our libraries, can be found both on our [wiki](https://nintendo-wiki.pretendo.network/docs/) and our (in progress) [developer documentation](https://developer.pretendo.network/home).
> [!NOTE]
> Developer documentation is highly work in progress. Do not expect to find everything there at this time. Please refer to the wiki first and foremost.
# Questions and Contact
If you have questions about a specific topic or wish to contact the core development team, you have 3 main options:
1. GitHub issues (recommended for specific questions)
2. The forum (recommended for broader/more general questions and discussion)
3. The Discord server (not recommended)
If you have a specific question regarding a specific service, tool, etc. then it is preferred if you make an issue on the relevant repository using the `Question` issue template. An example would be asking a question regarding the implementation of a specific RMC method on a specific game server.
If you have a more generalized question then it is preferred if you create a thread on the [Technical Discussion forum](https://forum.pretendo.network/c/technical-discussion). An example would be asking about a topic which spans multiple services, clarifying questions about infrastructure, contacting the team regarding good first steps/issues, etc. The [Technical Discussion forum](https://forum.pretendo.network/c/technical-discussion) is also a place for contributors, both current and potential, to have general discussions with each other regarding Pretendo Network. This is arguably the best place to contact the core development team.
Finally, if none of the above are suitable you may join our [Discord server](https://invite.gg/pretendo). General support and technical help is being phased out here, however, in favor of the forum. Joining our Discord server for the purposes of technical discussions and contribution help is ***not*** recommended.
# Finding Work
To get an overview of our current and future plans, see our ["Plans" GitHub Project](https://github.com/orgs/PretendoNetwork/projects/34). The information here differs from that found on our website progress page. The website progress page gives a brief, general, overview of feature support in select games. The information on this GitHub project shows all of our wider plans for Pretendo Network as a whole.
Most tasks will be linked to an issue on the relevant repository. If there is no repository for a task which you would like to work on, feel free to reach out to ask for one to be made. If there is something you would like to work on and is not listed as an existing task, create a feature request issue on the relevant repository.
# Making Issues
Before contributing any code, you should understand how we use issues and how to make them in a way which ensures you will get the response you want.
Issues are used by all repositories for most interactions. Issues are used for reporting actual issues with the codebase, as well as making feature requests and asking general questions. When making an issue, please use one of the provided issue templates. Using the provided templates keeps things consistent, as well as makes it easier for any of our 3rd party tools to interact with issues. If a template does not exist for what you wish to do, create a feature request for one. Not using an issue template may result in your issue being closed without completion.
When making code changes, an issue for the changes must be made and marked as approved before making the relevant changes. This ensures that your time is not wasted on changes we are not interested in making.
When making issues we ask that you be as detailed as possible. Do not make issues with titles like "I had an issue", "Found a bug", etc. The issue title should be an adequate summary of the information found within the issue's contents. When writing the issue body, provide as much detail as possible. Make the issue as long as it needs to be in order to adequately get the information across. We welcome the use of images, videos, etc. as well when applicable. Provide error codes, error messages, timestamps, the actions leading up errors, etc. Relevant links and even code snippets are also asked for when applicable. The more details we have from the start, the less time we spend asking clarifying questions resulting in faster resolutions. If you do not have much information, that is alright as well. We simply ask that you provide us with as much as you can from the start, and have patience as we work things out.
# Code Changes
As stated in [Making Issues](#making-issues), before making any code changes there must be an open, approved, issue for them. If you can not find an approved issue for the changes you wish to make, please make one before continuing.
There are 2 main goals when making code contributions:
1. [Consistency](#consistency)
2. [Quality/Substance](#quality-and-substance)
## Consistency
Arguably the most important thing about contributions is keeping them consistent with the rest of the codebase/project. With very few exceptions, contributions should be consistent with the existing codebases style, implementations/patterns, tech stack, etc. Doing so will ensure that anyone can jump into any repository and easily navigate about it. If you would like to make changes which go against any current consistency guidelines or implementations (such as changing linter rules, or swapping to a different tool in the stack), we ask that you make an issue specifically for these ideas first so they can be discussed by the core team.
See each repository for it's style and linting rules, however some higher level guidelines are:
- NEX (game) servers are written in Go.
- Game servers which require databases use Postgres.
- All other servers (with few exceptions) are written in TypeScript with the intention of being run on Node. If a server is not written in TypeScript, it needs to be migrated to it. Runtimes besides Node (Bun, Deno, etc.) are not accounted for. If compatibility for another runtime can be added without introducing regressions when running under Node, and without significant refactoring, then support may be added via a pull request.
- Package managers besides npm are not accounted for. If compatibility for another package manager can be added without introducing regressions when running under npm, and without significant refactoring, then support may be added via a pull request.
- TypeScript servers which require databases use MongoDB.
- APIs designed by us (not emulated APIs for game consoles) are implemented using gRPC. The protobuf files for these are found [here](https://github.com/PretendoNetwork/grpc-protobufs).
- Given that our stacks are mostly Go and TypeScript, our tools and libraries are also written in Go and TypeScript depending on where they will be used. For desktop applications we typically prefer [Electron](https://electronjs.org/), as it allows us to reuse our existing libraries.
## Quality and Substance
We do not accept changes for the sake of changes. Changes should solve real problems, not change things for your personal preferences. This does not mean changes need to be *large*, however. A spelling error is a "real problem" and is worth changing, despite being a small change. However changes such as "Changed from `for...of` to `forEach`" will likely be rejected unless some additional problem is being solved with the change.
This does not mean we do not value the opinions of others, however. If you feel that a change should be made, but does not solve a specific problem (such as a refactoring change), we welcome opening a feature request for these changes. We do not claim to be infallible, and we are open to making stylistic changes to our codebases when they make sense. However changes like these must still be approved, and justified. If the changes do not provide any true substance, they will likely be rejected.
Requiring changes to be approved and having substance is essential to not wasting the time of both contributors (who may spend time making changes we are not interested in) and our developers (who will have to spend time reviewing changes which ultimately get rejected).
# Commits
Besides the changes themselves, commits are the most important part of contributions. There are 2 major things to keep in mind for commits:
1. [Scale/Scope](#scale-and-scope)
2. [Messages](#messages)
## Scale and Scope
The scale and scope of a commit should be reasonable. Do not commit for every line when making multiple changes, for example. However you should not include many unrelated changes in a single commit. By limiting the scope of the commit we can ensure that if any regressions or new bugs are introduced we can easily revert those changes without the need for major refactors or reimplementations. Limiting the scale of commits also makes review of the changes easier and faster.
## Messages
Commit messages should adequately explain the changes in the commit. Messages like "Updated file.md" and "spelling error" should not be used. Nonsense messages such as "oops" or "fixed" are especially not allowed. Commit messages should, at minimum, be in the format `type: message` where `type` represents the type or scope of the changes (`feat`, `chore`, `docs`, `fix`, etc.) and `message` is the actual changes. Unless the word is from the codebase and starts with a capital letter (such as an exported Go struct), the `message` should be lowercase. We also recommend using both "subject" and "body" commits. This can be achieved through the git CLI by using multiple `-m`/`--message` flags. For example `git commit -m "short subject" -m "longer description of the changes"`.
The following are examples of good commit messages:
- `chore: renamed nnid service to nnas`
- `fix: fixed hang in MutexMap.Has`
Please refer to [Conventional Commits](https://conventionalcommits.org/) for a detailed guide on how to structure commit messages. Writing good, detailed, commit messages helps ensure that we can refer back to the git history and quickly find where specific changes occurred in the event that they need further review, reverting, etc.
# Pull Requests
As stated in [Making Issues](#making-issues), before making a pull request there must be an open, approved, issue for the changes being made. If you can not find an approved issue for the changes you wish to make, please make one before continuing.
Before making a pull request ensure you have tested all changes and that no regressions have been introduced.
Pull requests should never be made against the default (`main`/`master`) branch of a repository. The default branch contains the most recent, stable, version of the codebase. All work on the codebase should take place in other branches. Unless otherwise specified, your target branch should typically be the `dev` branch. You may target other feature branches, however, if need be. If a `dev` branch does not exist for the repository you are working on, please submit a feature request for one to be added before continuing.
A pull request does not necessarily need to *close* an issue. A pull request may be made which implements only a subset of the requirements to close an issue, but does not fully complete the task itself. A pull request should never be *unfinished* code, however. All code must be tested and shippable. A pull request must at minimum bring an issue closer to closing without introducing any new regressions.
Like everything else, pull requests should be as detailed as possible. Your title should adequately summarize the changes being made, and the body of the pull request should fully explain your changes. We ask that, if applicable, the rationale behind your changes also be noted. For example rather than simply "Changed from `for...of` to `forEach`", if the change was made for a performance reason you should say "Changed from `for...of` to `forEach` due to `forEach` being X times faster in this case" and provide some benchmarks. Adding images, videos, etc. is also welcomed in order to illustrate changes. If the changes being made are directly tied to some form of visual (such as a change to the website, a tools GUI, etc.) then images or videos is ***REQUIRED***. If none are provided, then we may delay review until they are given. Providing visual examples of these changes allow us to quickly assess whether or not we wish to proceed with the changes being made.
If a pull request requires any database migrations, describe them in detail and leave any migration queries inside of a code block within a `<details>` tag. This should happen either at the very beginning of the pull request message, or at the very end, but not somewhere in between. Doing so makes it clear at a glance that there are migrations required and makes it easy to find the related queries.
We ask that you have patience with us as we review your pull request. Pretendo Network only has a single full time developer, all other work is done by volunteers on their own time. Due to the sheer number of issues and pull requests, alongside our other general work and research, it may take us some time to fully review and decide on whether or not to merge your changes.
# Tests
We do not require 100% code coverage in any tests. We do not currently have strict rules regarding tests, however we may ask that tests be provided for large or complex changes.
# Licensing
Unless otherwise specified all code is licensed under [GNU AGPLv3](https://choosealicense.com/licenses/agpl-3.0), including that of outside contributions. This license allows users many freedoms to use our code in their own applications, including private and commercial use, while ensuring that all derivatives remain under this same license and keeps the source available, even when used over a network. A repository's license may not be changed by outside contributors unless that change is done with good reason, has been approved by the core development team, and is done with the consent of all relevant contributors.

47
.github/ISSUE_TEMPLATE/bug.yaml vendored Normal file
View file

@ -0,0 +1,47 @@
name: Bug Report
description: File a bug report
title: "[Bug]: "
labels: ["bug", "awaiting-approval"]
assignees: []
body:
- type: checkboxes
attributes:
label: Checked Existing
description: Ensure you have checked the existing issues, both open and closed, for duplicate issues.
options:
- label: I have checked the repository for duplicate issues.
required: true
- type: markdown
attributes:
value: "We're sorry to hear you had an issue. Please fill out this form to the best of your ability to help us get to the bottom of things."
- type: textarea
id: what-happened
attributes:
label: What happened?
description: Describe the bug in as much detail as possible.
validations:
required: true
- type: textarea
id: expected-result
attributes:
label: What did you expect to happen?
validations:
required: true
- type: textarea
id: reproduce
attributes:
label: Steps to reproduce?
description: What steps have you taken to see the bug? (OPTIONAL)
placeholder: 1. ...
validations:
required: false
- type: textarea
id: other-info
attributes:
label: Other relevant information. (OPTIONAL)
description: |
Feel free to give us any more information that doesn't fit the above text boxes.
Tip: You can attach files by clicking this textbox and dragging in files.
validations:
required: false

5
.github/ISSUE_TEMPLATE/config.yml vendored Normal file
View file

@ -0,0 +1,5 @@
blank_issues_enabled: false
contact_links:
- name: Technical Discussion
url: https://forum.pretendo.network/c/technical-discussion
about: Please use our forum for general technical discussions.

25
.github/ISSUE_TEMPLATE/enhancement.yaml vendored Normal file
View file

@ -0,0 +1,25 @@
name: Enhancement
description: Request an update to an existing feature
title: "[Enhancement]: "
labels: ["enhancement", "awaiting-approval"]
assignees: []
body:
- type: checkboxes
attributes:
label: Checked Existing
description: Ensure you have checked the existing issues, both open and closed, for duplicate issues.
options:
- label: I have checked the repository for duplicate issues.
required: true
- type: textarea
id: enhancement
attributes:
label: What enhancement would you like to see?
validations:
required: true
- type: textarea
id: other-details
attributes:
label: Any other details to share? (OPTIONAL)
validations:
required: false

32
.github/ISSUE_TEMPLATE/feature.yaml vendored Normal file
View file

@ -0,0 +1,32 @@
name: Feature Request
description: Suggest a new feature
title: "[Feature]: "
labels: ["feature", "awaiting-approval"]
assignees: []
body:
- type: checkboxes
attributes:
label: Checked Existing
description: Ensure you have checked the existing issues, both open and closed, for duplicate issues.
options:
- label: I have checked the repository for duplicate issues.
required: true
- type: textarea
id: what-feature
attributes:
label: What feature do you want to see added?
validations:
required: true
- type: textarea
id: why-feature
attributes:
label: Why do you want to have this feature?
placeholder: A new button!
validations:
required: true
- type: textarea
id: other-details
attributes:
label: Any other details to share? (OPTIONAL)
validations:
required: false

19
.github/ISSUE_TEMPLATE/question.yaml vendored Normal file
View file

@ -0,0 +1,19 @@
name: Question
description: Ask a general question
title: "[Question]: "
labels: ["question"]
assignees: []
body:
- type: checkboxes
attributes:
label: Checked Existing
description: Ensure you have checked the existing issues, both open and closed, for duplicate issues.
options:
- label: I have checked the repository for duplicate issues.
required: true
- type: textarea
id: question
attributes:
label: What would you like to know?
validations:
required: true

46
.github/ISSUE_TEMPLATE/regression.yaml vendored Normal file
View file

@ -0,0 +1,46 @@
name: Regression
description: Report a feature regression
title: "[Regression]: "
labels: ["regression", "awaiting-approval"]
assignees: []
body:
- type: checkboxes
attributes:
label: Checked Existing
description: Ensure you have checked the existing issues, both open and closed, for duplicate issues.
options:
- label: I have checked the repository for duplicate issues.
required: true
- type: markdown
attributes:
value: "We're sorry to hear something broke. Please fill out this form to the best of your ability to help us get to the bottom of things."
- type: textarea
id: what-happened
attributes:
label: What happened?
description: Describe the regression in as much detail as possible.
validations:
required: true
- type: textarea
id: expected-result
attributes:
label: What was the previous functionality?
validations:
required: true
- type: textarea
id: when
attributes:
label: When did this occur?
description: If known, please link to the commit or pull request which introduced this regression. (OPTIONAL)
validations:
required: false
- type: textarea
id: other-info
attributes:
label: Other relevant information. (OPTIONAL)
description: |
Feel free to give us any more information that doesn't fit the above text boxes.
Tip: You can attach files by clicking this textbox and dragging in files.
validations:
required: false

28
.github/PULL_REQUEST_TEMPLATE.md vendored Normal file
View file

@ -0,0 +1,28 @@
<!--
* Before making a pull request, ensure the changes are for an approved issue.
* If your changes are not for an approved issue, your pull request can and will be rejected.
*
* CHECK https://github.com/PretendoNetwork/REPO_NAME/issues?q=is%3Aopen+is%3Aissue+label%3Aapproved
* FOR APPROVED ISSUES!
-->
Resolves #XXX
### Changes:
<!--
* Describe your changes in as much detail as possible. Make sure to list your changes, as well as the rationale behind them.
* If applicable, include code snippets, images, videos, etc.
*
* If your changes require any database migrations, describe them in detail and leave any migration queries inside of a code
* block within a <details> tag.
-->
- [ ] I have read and agreed to the [Code of Conduct](https://github.com/PretendoNetwork/Pretendo/blob/master/.github/CODE_OF_CONDUCT.md).
- [ ] I have read and complied with the [contributing guidelines](https://github.com/PretendoNetwork/Pretendo/blob/master/.github/CONTRIBUTING.md).
- [ ] What I'm implementing was an [approved issue](../issues?q=is%3Aopen+is%3Aissue+label%3Aapproved).
- [ ] I have tested all of my changes.

13
.github/SECURITY.md vendored Normal file
View file

@ -0,0 +1,13 @@
# Security Policy
## Supported Versions
All versions of our software are supported by this policy. However only the most recent version is supported for vulnerability reporting on its repository and is eligible for fixes and new releases. If a vulnerability is found in older versions of the software, a vulnerability report should instead be made on *dependant* software, so that an update may be issued.
## Reporting a Vulnerability
If a security vulnerability is discovered, we ask for a non-public disclosure. ***The repository "Issues" tracker is fully public.*** Security vulnerabilities can be privately disclosed on the repository's "Security" page (https://github.com/PretendoNetwork/NAME/security/advisories/new). Maintainers will be automatically notified and any non-notified, relevant, contributors will be made aware internally.
## Expectations and Communication
We understand the desire to publicly disclose security vulnerabilities following a non-public disclosure. We ask that you give us ample time to research the vulnerabilities, issue fixes, and update relevant software before this. Pretendo Network is maintained almost entirely on volunteer time, with a single full time developer. Thus communication may be slow, and we may need more than the typical amount of time to provide fixes.

122
CONTRIBUTING.md
View file

@ -1,122 +0,0 @@
# Contributing Guide
The following is a guide designed to help new developers get a feel for how best to contribute to Pretendo. It is important that all who want to help contribute read these guidelines.
#### Table Of Contents
[Code of Conduct](#code-of-conduct)
[Prerequisites](#prerequisites)
* [Different areas](#different-areas)
* [Prerequisites for PRUDP](#prerequisites-for-prudp)
* [Prerequisites for NEX](#prerequisites-for-nex)
* [Prerequisites for Services](#prerequisites-for-services)
* [Prerequisites for PUS](#prerequisites-for-pus)
* [Prerequisites for Misc](#prerequisites-for-misc)
[Contributing](#contributing)
* [Getting started](#getting-started)
* [Contributing to PRUDP, NEX, or services](#contributing-to-prudp-nex-or-services)
* [Localization](#localization)
## Code of Conduct
This project and everyone participating in it is governed by the [Pretendo Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.
## Prerequisites
### Different areas
Before you can contribute it is important to know what area you would like to contribute to. Due to the scale and complexity of the network, the Pretendo Network project is split into several different areas of development which cover specific sections of the network. Each of these sections require slightly different prerequisites and background knowledge.
### Prerequisites for PRUDP
PRUDP(S) is the protocol layer ontop of all network requests made by the Nintendo WiiU/3DS family of consoles. It is a simple protocol spec sitting on top of UDP. It aims to make UDP reliable and secure, and was originally developed by [Quazal](https://en.wikipedia.org/wiki/List_of_Ubisoft_subsidiaries#Quazal), with a custom version made for Nintendo.
For more information about PRUDP, see [this Wiki](https://github.com/Kinnay/NintendoClients/wiki/PRUDP-Protocol)
### Prerequisites for NEX
NEX is the server middleware/framework used to handle the PRUDP connections. It handles the authentication, done through Kerberos, and connections to the secure server. In Pretendo both the PRUDP and NEX implementations are written in [Golang](http://golang.org). All non-(PR)UDP services are written in [NodeJS](https://nodejs.org).
For more information about NEX, see [this Wiki](https://github.com/Kinnay/NintendoClients/wiki/Game-Server-Overview)
### Prerequisites for Services
Services are servers which implement NEX in a functional way. These can be game servers such as the Super Mario Maker server or Mario Kart 8 match making server, or service servers such as the Friends service, ect.
### Prerequisites for PUS
PUS stands for Pretendo Update Server and, as the name suggests, is the Pretendo implementation of NUS (Nintendo Update Server). This server handles things such as FW updates, serving titles to the eShop, ect. It utilizes SOAP rather than REST. NUS has not been properly reverse engineered, we are simply mimicking what we have seen the official servers send during network dumps.
### Prerequisites for Misc
There are several other, smaller, areas of development. These range from the account server, to the frontend website, the Discord bot, the OTP/SEEPROM/account.dat generation (for [Cemu](http://cemu.info/) users), ect. These serve various purposes and use various languages/technologies.
## Contributing
### Getting started
Before you can contribute you need a few things first. First of all, you need to decided which area you are contributing to. If you are contributing to the development of NEX/PRUDP, or any services using them, you must first install [Golang](http://golang.org) and read the [Prerequisites for PRUDP](#prerequisites-for-prudp) and/or [Prerequisites for NEX](#prerequisites-for-nex) sections.
If you wish to contribute to PUS, or any other parts of the network, you must install [NodeJS](https://nodejs.org) and then read the correct prerequisites section.
### Contributing to PRUDP, NEX, or services
To contribute to PRUDP, NEX, or services decide which console you will be using to test (WiiU or 3DS). Alternatively, if you lack a console you can use [Cemu](http://cemu.info/) to emulate a WiiU, which supports network connections, as well as using this [Python library](https://github.com/Kinnay/NintendoClients) to build custom clients to test with.
If using a physical console or Cemu, you must download and run a local copy of the [account server](https://github.com/PretendoNetwork/account) to direct the client to the local NEX server.
If using the NintendoClients Python library you simply have to point the client to your local NEX server.
If using a physical console, install [Fiddler Proxy](https://www.telerik.com/fiddler) and then follow this setup guide to setup a WiiU (we currently do not have a setup guide for the 3DS):
1. In Fiddler, open `Tools > Options`
2. In the `HTTPS` tab turn on HTTPS Connects
3. Enable HTTPS decrypting
4. Ignore server certificate errors
5. In the `Connections` tab tick `Allow remote computers to connect`
6. Turn off `Act as system proxy on startup`
7. Back in the `HTTPS` tab click `Actions > Export Root Certificate to Desktop`
8. Rename `FiddlerRoot.cer` to `CACERT_NINTENDO_CA_G3.der` wherever you exported it to. Make sure the file extension`.der` NOT `.cer`. If its the wrong format you risk a brick
9. Install FTPiiU_Everywhere (not regular FTPiiU)
10. Launch in to Mocha (redNAND or sysNAND, doesn't matter. Do which ever you want)
11. Launch the Homebrew Launcher and startup FTPiiU_Everywhere
12. Connect to the FTP server on your computer using any FTP client (FileZilla/WinSCP on Windows or Finder on MacOS for example)
13. Navigate to `/storage_mlc/sys/title/0005001b/10054000/content`
14. Dump the `ccerts` folder to your PC (Will be used later. The file you will be using is common to ALL WiiU consoles, so you can download this file online if you want)
15. Enter `scerts` and replace the `CACERT_NINTENDO_CA_G3.der` file there with the `CACERT_NINTENDO_CA_G3.der` file you just made earlier from the `FiddlerRoot.cer` (make sure to backup the original. replacing this cert makes you unable to connect to the official servers without the proxy, you must change it back if you want to disable the proxy and still go online)
16. Close the FTP connection on your computer and exit FTPiiU_Everywhere (press Home button)
17. Reboot your console (Do not force-reboot (holding power button for 4 seconds), reboot normally (only hold for 2 seconds), to prevent cache issues)
18. Go to the connection settings for your WiFi connection on your WiiU and turn on proxy connections
19. Set the proxy server to your PC's IP, and the port to `8888` (unless you changed the Fiddler port)
20. On your PC go to where you dumped `ccerts` and copy `WIIU_COMMON_1_CERT.der` (again, this file is common to all consoles. You can find it online if you want)
21. Paste the cert in `%USERPROFILE%\My Documents\Fiddler2\` and rename it to `ClientCertificate.cer`
22. Open the `FiddlerScript` tab and find the `OnBeforeRequest` method
23. At the end of the method, add:
```JavaScript
// Change "account.nintendo.net" to whatever official Nintendo server you are replacing
if (oSession.HostnameIs("account.nintendo.net"))
{
if (oSession.HTTPMethodIs("CONNECT"))
{
oSession["x-replywithtunnel"] = "PretendoTunnel";
return;
}
oSession.fullUrl = "address.of.account.server" + oSession.PathAndQuery;
}
```
24. Restart Fiddler to save changes
If using Cemu, follow the [Cemu online play guide](http://compat.cemu.info/wiki/Tutorial:Online_Play) to get Cemu online. Then modify the above steps to work with Cemu (untested).
## Localization
To help with localizing Pretendo Network to your language, head over to our [Weblate](https://hosted.weblate.org/projects/pretendonetwork/)!
* * *
## Attribution
This contributing guideline is adapted from the [Atom contributing guideline](https://github.com/atom/atom/blob/master/CONTRIBUTING.md).

1034
LICENSE
View file

File diff suppressed because it is too large Load diff