Submissions are to be posted in the Pending Submissions sub-forum [NYI], where they are peer-reviewed. Peer review opens up a submission to criticism from members of the community, a process intended to improve resources to a standard of quality. Approval of a submission as a resource is performed by a moderator (see below).
If the submission does not contain all of the requirements, it will not be accepted and will remain in the Pending Submission sub-forum.
All files should be attached to the submission post, or otherwise explicitly linked to on-site files. Do not link to off-site images unless the file is larger than the site maximum.
A submission must be created by the submitting user, or contain explicit permission from the creator.
Do not make submissions only to receive feedback on them; to receive feedback, post in the relevant sub-forum. The Pending Submission sub-forum is for completed work and any feedback received should be for corrections. Do not submit works-in-progress.
Moderators are responsible for approving submissions, moving them from Pending Submissions to the relevant Resources sub-forum.
If a submission is not approved, a moderator will explain why; comply with the moderator’s instructions or the submission will remain in the Pending Submissions.
In the absence of multiple moderators, a moderator cannot approve its own submission until it has at least been thoroughly peer-reviewed. Otherwise, it must be reviewed and approved by another qualified moderator.
After a period of time extending no more than one (1) month after a moderator requests changes, unaltered submissions will be moved from Pending Submissions to the relevant Development sub-forum, or will be deleted at the request of the submitting user.
Submission Format Requirements
A submission post should be formatted in such a way that it is easily read and navigated, in plain language with minimal and appropriate use of stylized text, and must contain each of the following in the order provided.
Name
May include a one-line description.
May include a link to an Asset page, if one exists.
Description
Must include a plain language description of the purpose of the submission, such as what problem it solves.
May include an additional technical description of the problem, or how the submission works.
May include a list of features.
May include an update log / update history.
Installation
Must include a detailed, non-technical set of instructions for installing the submission, if installation is any more complicated than copy-pasting or adding a dependency.
Download
Must include either the necessary files attached to the post, or links to the files on-site.
Preview
Strongly encouraged to include a map for demonstration purposes.
Strongly encouraged to include screenshots for demonstration purposes.
May include a video demonstration.
Package Requirements
Script
A script is a body of galaxy script code that can be implemented into maps and mods to achieve a specific purpose via copy-paste installation. Scripts are required to either be posted in Code markup tags or attached as a file (though providing both is strongly encouraged), and are encouraged (but not required) to include test cases and a demonstration map, preferably containing GUI wrappers to provide GUI users access to the functionality. Script submission thread titles should be prefixed with [Script].
Library
A library is a container for (usually) large batches of GUI or script content with data interdependencies that can be implemented in other maps/mods or added as a dependency. Libraries are encouraged (but not required) to include a demonstration map. Library submission thread titles should be prefixed with [Library].
In-lining and Dependencies
The inclusion of any non-Script resources not created by the submitting user in a submission must have the resource creator's explicit permission to redistribute it and must give credit in a visible place. If the submission requires mod dependencies not published on Battle.net, links must be posted to the required libraries in the submission and no permission is needed from the creator to use them.
Content Requirements
Efficiency
A submission must utilize memory, threads, and operations efficiently. Use of parameters over that of global variables, appropriate management of the data table, and the avoidance of allocating huge chunks of memory with enormous arrays are ways in which memory may be used efficiently. Reducing 6 triggers with the same Any Unit Dies event to 1 trigger with branching or stacks of actions is a way in which threads may be used efficiently. Finding a single action solution to what was previously handled with a loop is a way in which operations may be used efficiently.
Scalability
A submission must scale well; it should be able to handle any arbitrary number of instances (or otherwise allow a user to define a limit), and similarly should work for any number of units, players, et cetera.
Readability
A submission must be readable. Use clear, explicit identifiers in GUI and script, and refrain from frivolous abbreviation. Do not submit obfuscated scripts. Do not submit scripts that use obnoxious notation conventions (such as the prefixes appended to identifiers in GUI-generated script).
Utility
A submission must be obviously useful, and it must work. If its utility is not readily apparent, it will be debated as part of the review process. If a submission shares utility with an approved resource, it must exceed the quality of that resource to replace it or demonstrate its value as an alternative to be approved.
Modularity
A submission should be modular. It should solve a specific problem, address a distinct need, and do no more than the one thing it states it does. Related submissions can be linked, but should not be submitted together in same post, and must not be interdependent.
Notes
Until the Pending Submissions sub-forum is implemented, submission topics will remain here.
This is an example of a description, in an example of a submission template. It provides users with an easily-implemented formatting guide, to reduce the hassle of formatting and promote a standard of readability. No one should be made to read disorganized and hideously formatted text to make use of a good resource. If your submission is in-lining someone else's assets, this is a place to mention it.
Includes a simple, copy-paste-able format.
Provides headers and text that show where your content should go.
Great taste, low calories.
Some other feature.
Demonstration (optional)
This is where you might demonstrate script code, test cases, or explain the submission's API. It is entirely optional, but very much encouraged.
Installation
This is where you would explain the installation process of your submission. For example, to install this template, simply quote it or copy-paste the text at the bottom, inside the code tags. If the submission has on-site dependencies, this is a good place to provide links to them.
Download
This is where you would list the files attached to the post or link to other on-site files, and explain what they are. Attached to this post is a text file containing the text in this post.
Preview (optional)
This is where you might attach screenshots or embed videos, demonstrating the effects of your submission.
== Submission Template : Name ==
=== [[http://www.sc2mapster.com/assets/|Clever one-line description with a link to an Asset page (if applicable).]] ===
=== Description ===
This is an example of a description, in an example of a submission template. It provides users with an easily-implemented formatting guide, to reduce the hassle of formatting and promote a standard of readability. No one should be made to read disorganized and hideously formatted text to make use of a good resource. If your submission is in-lining someone else's assets, this is a place to mention it.
* Includes a simple, copy-paste-able format.
* Provides headers and text that show where your content should go.
* Great taste, low calories.
* Some other feature.
=== Demonstration (optional) ===
This is where you might demonstrate script code, test cases, or explain the submission's API. It is entirely optional, but very much encouraged.
=== Installation ===
This is where you would explain the installation process of your submission. For example, to install this template, simply quote it or copy-paste the text at the bottom, inside the code tags. If the submission has on-site dependencies, this is a good place to provide links to them.
=== Download ===
This is where you would list the files attached to the post or link to other on-site files, and explain what they are. Attached to this post is a text file containing the text in this post.
=== Preview (optional) ===
This is where you might attach screenshots or embed videos, demonstrating the effects of your submission.
The following script contains functions for calculating and making use of cubic Bézier curves, which provide a convenient means for modeling smooth curves. These curves can be used to make smooth, non-linear gradients and transitions, for use in simple physics systems or just to make visual interface elements look prettier.
point BezierCurvePoint (fixed t, point p0, point p1, point p2, point p3) returns a point positioned at t% along the Bézier curve defined by 4 input points.
point BezierFactorPoint (fixed t, point p1, point p2) returns a point positioned at t% along the Bézier curve defined by 2 input points between [0,0] and [1,1].
fixed BezierFactor (fixed t, point p1, point p2) returns a fixed value corresponding to t% along the Bézier curve defined by 2 input points between [0,0] and [1,1].
Installation
Simply copy-paste the code from this post to a Custom Script section in the trigger editor or a galaxy script file, or copy the code from the demonstration map.
Download
Cubic Bézier Curve Demo: map file containing a demonstration of the functions described above, used to draw the ease-in-ease-out curve screenshots attached below.
Submission Guidelines
Submission Process
Submission Format Requirements
A submission post should be formatted in such a way that it is easily read and navigated, in plain language with minimal and appropriate use of stylized text, and must contain each of the following in the order provided.
Name
Description
Installation
Download
Preview
Package Requirements
Script
A script is a body of galaxy script code that can be implemented into maps and mods to achieve a specific purpose via copy-paste installation. Scripts are required to either be posted in Code markup tags or attached as a file (though providing both is strongly encouraged), and are encouraged (but not required) to include test cases and a demonstration map, preferably containing GUI wrappers to provide GUI users access to the functionality. Script submission thread titles should be prefixed with [Script].
Library
A library is a container for (usually) large batches of GUI or script content with data interdependencies that can be implemented in other maps/mods or added as a dependency. Libraries are encouraged (but not required) to include a demonstration map. Library submission thread titles should be prefixed with [Library].
In-lining and Dependencies
The inclusion of any non-Script resources not created by the submitting user in a submission must have the resource creator's explicit permission to redistribute it and must give credit in a visible place. If the submission requires mod dependencies not published on Battle.net, links must be posted to the required libraries in the submission and no permission is needed from the creator to use them.
Content Requirements
Efficiency
A submission must utilize memory, threads, and operations efficiently. Use of parameters over that of global variables, appropriate management of the data table, and the avoidance of allocating huge chunks of memory with enormous arrays are ways in which memory may be used efficiently. Reducing 6 triggers with the same Any Unit Dies event to 1 trigger with branching or stacks of actions is a way in which threads may be used efficiently. Finding a single action solution to what was previously handled with a loop is a way in which operations may be used efficiently.
Scalability
A submission must scale well; it should be able to handle any arbitrary number of instances (or otherwise allow a user to define a limit), and similarly should work for any number of units, players, et cetera.
Readability
A submission must be readable. Use clear, explicit identifiers in GUI and script, and refrain from frivolous abbreviation. Do not submit obfuscated scripts. Do not submit scripts that use obnoxious notation conventions (such as the prefixes appended to identifiers in GUI-generated script).
Utility
A submission must be obviously useful, and it must work. If its utility is not readily apparent, it will be debated as part of the review process. If a submission shares utility with an approved resource, it must exceed the quality of that resource to replace it or demonstrate its value as an alternative to be approved.
Modularity
A submission should be modular. It should solve a specific problem, address a distinct need, and do no more than the one thing it states it does. Related submissions can be linked, but should not be submitted together in same post, and must not be interdependent.
Notes
Submission Template : Name
Clever one-line description with a link to an Asset page (if applicable).
Description
This is an example of a description, in an example of a submission template. It provides users with an easily-implemented formatting guide, to reduce the hassle of formatting and promote a standard of readability. No one should be made to read disorganized and hideously formatted text to make use of a good resource. If your submission is in-lining someone else's assets, this is a place to mention it.
Demonstration (optional)
This is where you might demonstrate script code, test cases, or explain the submission's API. It is entirely optional, but very much encouraged.
Installation
This is where you would explain the installation process of your submission. For example, to install this template, simply quote it or copy-paste the text at the bottom, inside the code tags. If the submission has on-site dependencies, this is a good place to provide links to them.
Download
This is where you would list the files attached to the post or link to other on-site files, and explain what they are. Attached to this post is a text file containing the text in this post.
Preview (optional)
This is where you might attach screenshots or embed videos, demonstrating the effects of your submission.
Cubic Bézier Curve script
A complete submission example.
Description
The following script contains functions for calculating and making use of cubic Bézier curves, which provide a convenient means for modeling smooth curves. These curves can be used to make smooth, non-linear gradients and transitions, for use in simple physics systems or just to make visual interface elements look prettier.
Demonstration
Installation
Simply copy-paste the code from this post to a Custom Script section in the trigger editor or a galaxy script file, or copy the code from the demonstration map.
Download