Contributing
Summary
Why Follow Guidelines?
What Can I Contribute?
Programming
Translation
Everything Else
What Can I Not Do?
Guidelines
Our Mission
How to Contribute
Production Enviroment
Npm Run
Charts
Development Environment

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 the documentation of this project, make your fork from the documentation branch. If you are contributing to the code/programming of this project, make your fork from the code branch. 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 up-to-date changes.

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 call Overlay() as well.
• Low quality code will be rejected.
• You can find documentation for Blue Marble here.
• Don't fork the main branch! Fork either code or documentation.
• If you are adding a new feature, and it is feasable to stick your feature inside a function, then use a function. This will make your code conflict less with other people's code. Make your code modular.

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 when 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:

1. The template image is generated and the tile information is retrieved.
2. The color filter function is passed in the template image and the tile information. The color filter overrides the template image with the filtered colors, and outputs that as the template image.
3. The pixel counter function is passed in the modified template image and the tile information, and outputs the pixel count.
4. 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

• 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.

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

1. Read all of the contributing guidelines.
2. If you would like to contribute, submit a request here.
3. If you have received authorization to start working on your contribution, set up the development environment on your device.
4. Fork the project.
5. Download your fork to the development environment.
6. 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 Overlay popup window works.
7. Make your contribution.
8. Commit to your fork.
9. 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.

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

Browser

Operating System