• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

JASS Submission Rules

Status
Not open for further replies.

Bribe

Code Moderator
Level 50
Joined
Sep 26, 2009
Messages
9,456


JASS Submissions Forum

Description
The Submissions forum is a great place to share your custom script for WarCraft III. Any submitted script must be written in either plain JASS, vJass, Zinc, Lua or Wurst resources that you would like to share with the community.
Where to Submit
Spells or systems which require a demo map or would make the most sense to have a demo map should be submitted to the Spells section. If the code is simple or straightforward enough to be more or less copy & paste, you should submit it here.

If your resource is unfinished or you are unsure whether or not it even works, has bugs or may have already been done before (ie. a Timer system), you should submit it to The Lab for feedback before making your official submission.

Rules
  • All threads should contain the script's code in the original post itself, unless more text space is needed and each script-inclusive reply is linked to in the original post.

  • An already approved resource may be deprecated if a replacement is obviously superior in many aspects.

  • Submissions must be as free of memory leaks as possible.

  • JassHelper resources must adhere to the correct encapsulation syntax introduced by JassHelper.


    • All submissions here should be included in a library, not a scope.
    • Contents of a library should be prefixed with “private” when not intended to be used by the user. For structs, there is also the “readonly” keyword which allows a variable to be read publicly but not written to publicly. Use that at your own discretion.
    • To make something “internal” (can be accessed anywhere in the library, but would otherwise need to be listed as “public” in order to compile), use “keyword” (documented in the JassHelper manual).

    Vanilla JASS resources are not able to apply any of those keywords. They must, however, include unique prefixes for “private” variables/functions and, optionally (for readability), be "quarantined” with documentation stating that such code block is only for use with the system and not by the user.

  • New threads represent new submissions. Do not make a post here unless it is a submission. 1 thread must contain 1 submission. No more, no less. 2 submissions can only be in the same thread if the purpose of one is to add an extra field to the other without making any radical changes to the core. (Add-ons)

  • Proper documentation must be included with all scripts. This includes, but is not limited to:

    • Library requirements. (This includes but is not limited to the name of the library, the author, and a link to the library's thread.)
    • A listing of the public API. (This includes functions, structs, modules, globals, struct members, function interfaces, and so on.)
    • Instructions on how to import the script into a map should it not be simply copy and paste.
    • A clear description on how the script should be used and, if possible, explain why the resource is useful.

    Scripts that are not properly documented will not be approved until such documentation is added. Spend a few minutes listing the API and what each function/variable can do for the user. An undocumented script has no potential if no one is able to take advantage of your hard work.

  • Any submitted script must be written in either plain JASS, vJass, Zinc, LUA or Wurst. cJass is invalid as it has too many bugs to be acceptable.

  • Resources’ public API should strive to follow the JASS convention set by JPAG. If you would like to do something different if you think your change improves readability or clarity, feel free to inquire about it with a moderator or collaborate with other users. The important thing is that we are all on the same page, so we know what to expect when we are working with public API.

  • A good resource is a resource that has a clear purpose, performs it efficiently and does not require an extensive learning curve. The less it does, the easier it is to debug, improve, learn and implement.

  • If your resource was moved to the Graveyard, check if the resource followed the above rules. If you would like to update it, feel free to resubmit it or PM a moderator about the situation if you feel that the graveyarding is no longer needed.

  • If you do not yet have JNGP installed, you can acquire it here.
    JNGP does not work with newest patch! WEX is an alternative.
 
Last edited by a moderator:
Status
Not open for further replies.
Top