18 KiB
Contributing
Thank you for wanting to contribute to the userscript "Blue Marble"! It means a lot to me that someone likes my project enough to want to help it grow. If you haven't already done so, consider joining our Discord. You can ask questions about the userscript there and receive feedback. You can also visit the official Blue Marble website for more information.
Note: If you are using AI, and you want to tell the AI how the codebase files are related to each-other, go to the Class diagram of relationships for Blue Marble diagram in the chart section of this file. Copy the chart, and give it to the AI.
Note: If you are contributing to this project, make your fork from the latest release branch. The latest release branch number should be one MINOR version higher than the current. E.g. if the latest release is 1.2.3, you should fork release/v1.3.0. If you fork main, and make a PR from main -> main your PR might be rejected. This is because main is not up-to-date, and your changes might conflict with the bleeding-edge.
Summary
- I don't want to waste your time, so double check with me before starting a big change like adding a new feature. For example, imagine you spend 50 hours making a bot that automatically places pixels, then your pull request was rejected because a bot that automatically places pixles does not align with the "Mission" of Blue Marble. That would be sad :(
- Follow the style of the project. E.g., if all overlays are made by calling
Overlay(), and you want to make a new overlay, you should probably callOverlay()as well. - Low quality code will be rejected. If I can't maintain the code, it will be rejected.
- Low quality Pull Requests will be rejected. Communicate with the reviewers, make changes to your Pull Request when asked, and take responsibility for the code until the PR is merged. If you make a PR and abandon the PR, it will be rejected.
- You can find documentation for Blue Marble here.
- Make your code modular. If you are adding a new feature, and it is feasable to stick your feature inside a new function, then use a new function. This will make your code conflict less with other people's code. Ideally, most features should be their own function.
Why Follow Guidelines?
Following the guidelines on this page helps everyone. Writing code that follows the guidelines:
- Helps me implement (and continue support for) your feature.
- You get your feature implemented.
- Everyone else gets a new supported feature.
What Can I Contribute?
Programming
Most of the work to be done in this userscript is related to programming. It is helpful to have a background in programming, but not required. If you are looking to learn JavaScript and its syntax, check out this roadmap for learning JavaScript. We strongly recommend that you understand functions, methods, classes, and Object-Oriented-Programming if you plan to implement a brand new feature. More technical knowledge like method chaining and lambda expressions are useful but not required. You can find the documentation for Blue Marble here. Make your code modular whenever possible. In other words, you should "blackbox" your code by putting it in a function when possible. For example, if you are adding a color filter to remove colors from being displayed on the template, the function should pass in the template information and tile information, and output the filtered template/tile information. This way, other people's code can't interfere with the color filter. For example:
- The template image is generated and the tile information is retrieved.
- The template image and the tile information is passed into the color filter function. The color filter overrides the template image with the filtered colors, and outputs that as the template image.
- The modified template image and the tile information is passed into the pixel counter function, and it outputs the pixel count.
- The modified template image and the tile information is used to render the template.
Translation
While typically overlooked, translating is a powerful way to contribute to a project. If you can write, there is something you can contribute! From minor grammar mistakes, to translating an entire language, all help is appreciated.
Everything Else
Although userscripts are oriented around coding, there are many ways to contribute! From improving the README file, to making tutorials, you can contribute in many ways that don't require programming skills. For example, if you have an idea for a feature, but you don't have the skills to implement it, submit a feature request! Someone might see it, think it is cool, and implement it.
What Can I Not Do?
Please do not use GitHub Issues for asking support questions (e.g. "How do I install this?" or "What does cssMangler do?"). We use the GitHub issue tracker for bug reports and feature requests. If you are having trouble and need help, ask on our Discord. However, you should make a feature request on our issue tracker before starting work on your contribution. Nothing sucks more than working hard on a high-quality contribution just for it to be rejected because it does not align with the mission of the mod. Ask first!
Please contribute in good faith. We will reject pull requests with bad code, comments, or pull requests that damage the mod.
Guidelines
- The project owner has the final say over all decisions. The current project owner is:
SwingTheVine. - Always submit a feature request and receive authorization to work on your contribution before you start working on your contribution. This will save you time if we end up rejecting the contribution. Small contributions (like fixing spelling errors) don't need a feature request.
- Follow the Code of Conduct. This includes both your contributions and the way you interact with this community.
- Always write a clear message that explains the changes. "Added some things" does not explain what was changed.
- Different feature, different pull request. If you submit a pull request for templates and localization (i18n) together, and we want to reject the localization, your template code is rejected along with the localization since they are the same pull request. They should be separate pull requests since they are separate features.
- The file structure must be maintained (unless you were authorized to change it). For example, all code should go in `src/` and all code affecting the overlay should go in the Overlay class file.
- The naming structure must be maintained (unless you were authorized to change it). For example, the template image variable could be called "templateDataImage." Most things are named to be grouped based on what they share in common first. In the previous example, the variable is first related to a "template," then "data" which is an "image." This is because the variable stores an image that comes from the data of a template. The main reason for naming things this way is to aid you when you try to find the name of something. "I need the image of a template, so the variable probably starts with 'template'".
- Your code must be commented, explaining what everything does. We may reject the pull request if we can't understand what the code does.
- Your code should follow SwingTheVine's code style. It is not required, but it helps things progress faster.
Our Mission
Our "mission" makes up the essence of this userscipt. Without it, this project would not exist.
The mission of this userscript is to provide a well-documented, high-quality, open-source template overlay.
- We recognize that most pixel canvas overlays do not have high-quality open-source code. Either the overlay is high-quality & close-sourced, or the overlay is low-quality & open-sourced. This userscript strives to fix that.
- We recognize that most pixel canvas overlay userscripts are obfuscated. While it is possible to modify them, it is unnecessarily challenging. This userscript hopes to change the precedence by being unobfuscated.
- We recognize that most pixel canvas overlay userscripts do not have enough documentation to allow their community to modify (or understand) the inner workings of the overlay. This userscript strives to be as beginner-friendly as possible.
How To Contribute
- Read all of the contributing guidelines.
- If you would like to contribute, submit a request here.
- If you have received authorization to start working on your contribution, set up the development environment on your device.
- Fork the project.
- Download your fork to the development environment.
- If applicable, it might be useful to learn how a (already in the userscript) feature similar to your contribution works. For example, if you want to add a new popup window, it might be benifical to learn how the
Overlaypopup window works. - Make your contribution.
- Commit to your fork.
- Submit a pull request between your fork and this project.
Production Enviroment
Here lies information that may be of interest to those who wish to modify Blue Marble.
Npm Run
Running npm run build will compile Blue Marble. The compiled files can be found in the dist/ directory. Running npm run patch will increment the patch version, and compile Blue Marble.
Charts
Use the arrow and zoom buttons to navigate the charts. Use the ↔️ button to go fullscreen. Use the 🔄 button to reset. All buttons can be found on the chart. Use the "two squares" icon to copy the chart. If you need assistance reading the chart, copy the chart into an AI using the "two squares" button on the chart.
Class diagram of relationships for Blue Marble: (last updated 0.74.0)
---
config:
class:
hideEmptyMembersBox: true
---
classDiagram
class main {
name : string
version : string
+inject()
+observeBlack()
+buildOverlayMain()
}
class utils {
+escapeHTML()
+serverTPtoDisplayTP()
+negativeSafeModulo()
+consoleLog()
+consoleError()
+consoleWarn()
+numberToEncoded()
+uint8ToBase64()
+base64ToUint8()
}
class apiManager {
coordsTilePixel : number[4]
+spontaneousResponseListener()
}
class templateManager {
userID : number
templatesShouldBeDrawn : boolean
+createJSON()
+createTemplate()
-storeTemplates()
+disableTemplate()
+drawTemplateOnTile()
+importJSON()
+parseBlueMarble()
+setTemplatesShouldBeDrawn()
}
class Template {
+createTemplateTiles()
}
class Overlay {
+setApiManager()
-createElement()
+add...()
+buildElement()
+buildOverlay()
+updateInnerHTML()
+handleDrag()
+handleDisplayStatus()
+handleDisplayError()
}
main o-- apiManager : creates
main o-- utils : creates
main o-- Overlay : creates main, tabTemplate
main o-- templateManager : creates
apiManager ..> templateManager : calls drawTemplateOnTiles(), sets userID
apiManager ..> utils : calls escapeHTML(), numberToEncoded(), serverTPtoDisplayTP()
Overlay ..> apiManager : uses coordsTilePixel
Overlay ..> templateManager : calls setTemplatesShouldBeDrawn()
templateManager *-- Template : manages
templateManager ..> utils : calls base64ToUint8(), numberToEncoded()
Template ..> utils : calls uint8ToBase64()
Class diagram of relationships for Blue Marble's compiler/builder: (last updated 0.74.0)
---
config:
class:
hideEmptyMembersBox: true
---
classDiagram
namespace npm_run_patch {
class `patch.js` {
}
class `docs/README.md` {
}
}
namespace npm_run_build {
class `build.js` {
mapCSS : JSON Object
}
class `cssMangler.js` {
importMap : JSON Object
returnMap : JSON Object
+mangleSelectors()
+escapeRegex()
+numberToEncoded()
}
class `update-version.js` {
}
class `utils.js` {
+consoleStyle()
}
class esbuild {
+build()
}
class terser {
+minify()
}
class `dist/BlueMarble.user.js` {
}
class `dist/BlueMarble.user.css` {
}
class `dist/BlueMarble.user.css.map.json` {
}
class `src/BlueMarble.meta.js` {
}
class `src/main.js` {
}
class `package.json` {
}
}
note for `patch.js` "calls npm_run_build"
`build.js` ..> terser : requires
`build.js` ..> `utils.js` : calls consoleStyle()
`build.js` ..> `update-version.js` : executes
`build.js` ..> `src/BlueMarble.meta.js` : reads
`build.js` ..> esbuild : calls build()
`build.js` ..> `dist/BlueMarble.user.css` : writes
esbuild ..> `src/main.js` : reads
`build.js` ..> `dist/BlueMarble.user.js` : writes
terser ..> `dist/BlueMarble.user.js` : reads & writes
`build.js` ..> `cssMangler.js` : calls manglerSelectors()
`cssMangler.js` ..> `dist/BlueMarble.user.css.map.json` : reads
`cssMangler.js` ..> `dist/BlueMarble.user.js` : reads & writes
`cssMangler.js` ..> `dist/BlueMarble.user.css` : reads & writes
`build.js` <.. `cssMangler.js` : returns mapCSS
`build.js` ..> `dist/BlueMarble.user.css.map.json` : writes mapCSS
`patch.js` ..> `docs/README.md` : reads & writes
`patch.js` ..> `utils.js` : calls consoleStyle()
`update-version.js` ..> `package.json` : reads
`update-version.js` ..> `src/BlueMarble.meta.js` : reads & writes
`update-version.js` ..> `utils.js` : calls consoleStyle()
Development Environment
This is what SwingTheVine uses to program Blue Marble. You don't have to use the exact same thing. This is provided for reference.
IDE
Visual Studio CodeVersion: 1.109.0Browser
Google ChromeVersion:
144.0.7559.133 (Official Build) (64-bit)TamperMonkey Version:
5.4.1
Operating System
Windows 11 HomeVersion:
25H2OS Build:
26200.7705Processor:
Intel Core i7-9750H CPU @ 2.60GHzRAM:
16.0 GBStorage:
932 GB SSD Samsung SSD 970 EVO Plus 1TB, 238 GB SSD HFM256GDJTNG-8310AGraphics Card:
NVIDIA GeForce GTX 1660 Ti (6 GB)System Type:
64-bit operating system