• published the article Abandoned and Inactive Projects

    Project Definitions

    What is an abandoned project?

    Really there are two types of abandoned projects. There are ones that we've marked as abandoned, and there are ones that are abandoned in practise, but not in name.

    We give projects a long time, a very long time, before we mark them as abandoned. So these types are considered essentially dead. However, if the project's license allows, it can be resurrected.

    The second category is for a project which hasn't been updated in a long time; the project leader seems to be MIA and/or the project is slowly fading due to bitrot.

    What is an inactive project?

    An inactive project is one which has not had any activity for a period of time.

    What is a mature project?

    Some projects are feature complete and essentially will not break when patches come out. These projects will not get a lot of attention from their authors simply because the attention is not needed.

    If you feel that your project will not need updates in the future, please mark it as mature. Do not mark a project as mature simply as a way to circumvent the automatic status changes; they were put into place for a reason.

    Reclaiming your abandoned or inactive project

    These project statuses are often set automatically by the system. If the status was set and you do not feel that it is correct, please do not submit a ticket or a report: You can manually change the status by going to Project management, Edit project, then changing the Development stage near the bottom of the page.

    Taking over an abandoned project

    You should attempt to contact the author directly - we will do nothing without the project owner's express permission. If you cannot receive permission to take over the project for whatever reason, and that project's license is permissive of forking, you should fork the project using a different name from the original.

    We do not allow fan updates, as most of these are fire-once-and-forget and we also want to avoid a situation of having five different versions of "Awesome AddOn X Continued" which only serves to confuse users of the original project.

    Uploading to another authors work to CurseForge

    In certain instances, the original author(s) will not want to maintain their project on CurseForge. In these cases when creating a project you must do the following:

    1. Obtain explicit permission to upload to CurseForge. This permission must be included in the project description.
    2. Link back to the original hosting location of the project.
    3. Credit the original authors in your main description.

    Required project elements when taking over a project

    When taking over a project we require that you observe the following rules:

    1. The original project author(s) are kept on the project as authors (There is now a former author role for the site, please use that if the author is no longer active.).
    2. The main description of the project identifies that you have taken over from another author and lists who previously worked on the project.
    3. Credit the original author(s) in the code (aka X-credits in a .toc)
    Posted in: Abandoned and Inactive Projects
  • published the article Documentation

    API

    Automatic Packaging

    Repository Migration

    Posted in: Documentation
  • published the article Bukkit Plugins

    All file uploads must be in JAR (Java Archive) format. In cases where one or more auxiliary files are intended to work with the main JAR file, these can be uploaded as additional (child) files from the main file's information page.


    To upload an Additional File, go to the Files page on your project, then go to the page for a specific file. Near the bottom of that page, under the Changelog section you will see this:



    Click the Upload Additional File button, then enter the appropriate information and upload the file as you would normally.


    Posted in: Bukkit Plugins
  • published the article Project Localization

    Definitions

    Locale
    A language with some extra information. For example, esES (Spanish) is distinct from esMX (Latin American Spanish), despite it being the same language, some words might be different.
    Phrase
    An entry into the Localization System. This represents the key your phrase is, what namespace it belongs to, any context attached to it. This will always have an English translation attached.
    Translation
    A single translation of a phrase into a specific language. There is only one definitive translation per-phrase per-locale.
    Translator
    A user who submits translations to a project. If the project's Localization System is set to closed, a translator must be explicitly defined by the manager of the project. Otherwise, any user of the site may enter translations.
    Developer
    A member of the project that (for our purposes) has the privilege to edit, create, and delete English translations.
    Namespace
    A namespace acts as a section for a group of phrases. All projects have a base namespace (or root namespace). This is particularly useful if you have a modular project where you want the individual modules to have a separate namespace from the core.

    Why should I localize my project?

    You may ask "Why should I localize my project?", caring only about English-speaking people and the like. It's a good idea to localize because although many foreigners speak English, a lot don't, and the ones that do might rather use your project in their native tongue. After all, we're coding addons for games, games should be fun, games shouldn't make you translate in your head constantly. Remember that World of Warcraft is released in nine different languages! Also, if you do everything through the localization app, it's mostly a fire-and-forget system, where once all your phrases are in, you don't have to worry about it, and the translators will take care of things themselves.

    Importing existing translations

    If you have localized your project without our system, you should be able to import your phrases and translations quite easily.

    Just click the Import button in the navigation bar at the top, fill in your details and copy-paste your translations into the text box. Note: you should be just copy-pasting the translations and not any AceLocale headers or such.

    You do this once per language.

    Phrases

    Creating Phrases

    If you're either starting from scratch or want to add new phrases, you'll probably want to create a new phrase through the website, since extra details can be supplied that can't be on import. In the navigation bar, you'll see "Phrases", if you hover over it, it will pop up a menu containing "Create phrase". Use this form to create a new phrase.

    There is an optional section for Context that you can supply. This can be a description of the phrase or where to find or some other indicator that will give translators proper context on how to translate the phrase properly.

    Editing Phrases

    In the event that you need to change a phrase, first find the phrase through the phrase index (Phrases button in the navigation bar), click on it, then click Edit phrase in the navigation bar.

    Namespaces

    First, realize that for the majority of projects, namespaces are unnecessary. Sticking to the base namespace is perfectly acceptable.

    Creating a Namespace

    In the navigation bar, you'll see "Namespaces", hover over it, and a menu will pop up containing "Create namespace". You can now create a namespace.

    Editing a Namespace

    Find the namespace you want through the namespace index (Namespaces button in the navigation bar), click on it, then click Edit namespace in the navigation bar.

    Exporting Translations

    Once you're satisfied with the translations in the system, you can, at any time, export your translations.

    Web Interface

    Click the Export button in the navigation bar. Fill in the details on how you want it to export, then click the Export button on the form. You'll have a text box full of your translations which you can copy-paste into your code.

    You'll have to do this once per locale.

    File Upload

    Since exporting manually can be a pain, we supply a way to have your translations automatically injected into your uploaded files. You can see the full details on the Localization Substitutions knowledge base page.

     

    Directing translators to localize your project

    You should point them to the localization index (found by clicking "Localization" in your project's navigation bar), which shows the status of all the locales. It is recommended you put a nice message in your project's description, or you can advertise on the forums of your choice. The "Localization" tab will appear to regular users whenever you have phrases in your localization system, nonetheless.

    Posted in: Project Localization
  • published the article Repository Keyword Substitutions

    When repositories are packaged, certain keyword substitutions take place on text files.

    Simple replacements

    @file-revision@
    Turns into the current revision of the file in integer form. e.g. 1234
    Note: For Git, this will use the file hash.
    @project-revision@
    Turns into the highest revision of the entire project in integer form. e.g. 1234
    Note: For Git, this will use the commit hash.
    @file-hash@
    Turns into the hash of the file in hex form. e.g. 106c634df4b3dd4691bf24e148a23e9af35165ea
    Note: No replacement will occur for Subversion.
    @project-hash@
    Turns into the hash of the entire project in hex form. e.g. 106c634df4b3dd4691bf24e148a23e9af35165ea
    Note: No replacement will occur for Subversion.
    @file-abbreviated-hash@
    Turns into the abbreviated hash of the file in hex form. e.g. 106c63 Note: No replacement will occur for Subversion.
    @project-abbreviated-hash@
    Turns into the abbreviated hash of the entire project in hex form. e.g. 106c63
    Note: No replacement will occur for Subversion.
    @file-author@
    Turns into the last author of the file.
    @project-author@
    Turns into the last author of the entire project.
    @file-date-iso@
    Turns into the last changed date (by UTC) of the file in ISO 8601. e.g. 2008-05-01T12:34:56Z
    @project-date-iso@
    Turns into the last changed date (by UTC) of the entire project in ISO 8601. e.g. 2008-05-01T12:34:56Z
    @file-date-integer@
    Turns into the last changed date (by UTC) of the file in a readable integer fashion. e.g. 20080501123456
    @project-date-integer@
    Turns into the last changed date (by UTC) of the entire project in a readable integer fashion. e.g. 2008050123456
    @file-timestamp@
    Turns into the last changed date (by UTC) of the file in POSIX timestamp. e.g. 1209663296
    @project-timestamp@
    Turns into the last changed date (by UTC) of the entire project in POSIX timestamp. e.g. 1209663296
    @project-version@
    Turns into an approximate version of the project. The tag name if on a tag, otherwise it's up to the repo.
    :SVN returns something like "r1234"
    :Git returns something like "v0.1-873fc1"
    :Mercurial returns something like "r1234".

    Debug replacements

    These occur based on filetype, as they tend to tie into the comment system for the file.

    The insides aren't removed so that line numbers stay the same, they just cause them to be commented out.

    Lua

    --@debug@ and --@end-debug@
    Turns into --[===[@debug and --@end-debug]===].
    --[===[@non-debug@ and --@end-non-debug@]===].
    Turns into --@non-debug@ and --@end-non-debug@.

    XML

    <!--@debug@--> and <!--@end-debug@-->
    Turns into <!--@debug and @end-debug@-->.
    <!--@non-debug@ and @end-non-debug@-->.
    Turns into <!--@non-debug@--> and <!--@end-non-debug@-->.

    TOC

    #@debug@ and #@end-debug@
    Turns into #@debug@ and #@end-debug@, as well as adding a # to the beginning of each line in-between.

    Exclude from packaging

    These occur based on filetype, as they tend to tie into the comment system for the file.

    --@do-not-package@ and --@end-do-not-package@ (for Lua)
    <!--@do-not-package@--> and <!--@end-do-not-package@--> (for XML)
    #@do-not-package@ and #@end-do-not-package@ (for TOC)
    Removes everything between the @do-not-package@ and @end-do-not-package@ tags including the 2 tags themselves. This may cause line numbers of subsequent lines to change. The typical usage is at the end of Lua files surrounding debugging functions and other code that end users should never see/execute.

    Because of pre-commit hooks, you will still need to comment out the @do-not-package@ and @end-do-not-package@ tags for the relevant file types.

    Alpha Replacements

    These occur based on filetype, as they tend to tie into the comment system for the file.

    The insides aren't removed so that line numbers stay the same, they just cause them to be commented out.

    These occur from packages created not from tags, i.e. alpha packages.

    This is useful to put extra debugging information that you want your alpha testers to have, but don't want to appear in release versions.

    Lua

    --@alpha@ and --@end-alpha@
    Turns into --[===[@alpha and --@end-alpha]===].
    --[===[@non-alpha@ and --@end-non-alpha@]===].
    Turns into --@non-alpha@ and --@end-non-alpha@.

    Example:

    --@alpha@
    assert(everythingIsOkay())
    --@end-alpha@
    

    This would make it so the assert takes place in dev mode and alpha zips, but doesn't bother for release and beta.

    XML

    <!--@alpha@--> and <!--@end-alpha@-->
    Turns into <!--@alpha and @end-alpha@-->.
    <!--@non-alpha@ and @end-non-alpha@-->.
    Turns into <!--@non-alpha@--> and <!--@end-non-alpha@-->.

    TOC

    #@alpha@ and #@end-alpha@
    Turns into #@alpha@ and #@end-alpha@, as well as adding a # to the beginning of each line in-between.

    No-lib Replacements

    These occur based on filetype, as they tend to tie into the comment system for the file.

    The insides aren't removed so that line numbers stay the same, they just cause them to be commented out.

    These only occur on packages marked as -nolib.

    TOC

    #@no-lib-strip@ and #@end-no-lib-strip@.
    Turn into #@no-lib-strip@ and #@end-no-lib-strip@, as well as adding a # to the beginning of each line in-between.

    XML

    <!--@no-lib-strip@--> and <!--@end-no-lib-strip@-->.
    Turn into <!--@no-lib-strip and @end-no-lib-strip@-->.
    Posted in: Repository Keyword Substitutions
  • published the article Localization Substitutions

    The Localization subsystem is designed to allow your project to be translated into different languages. If you've decided to enable this system on your project, translations will automatically be injected into your files based on the formatting outlined in this article.


    Here is an example substitution:

    @localization(locale="enUS", format="lua_table")@


    The example turns into something that looks like this:

    { ["Some key"] = "Some value" }

     

    Arguments

    Note: only locale and format are required.

     

    • locale
      • one of "enUS", "frFR", "deDE", etc. You'll see a full list of each possible locale on your project's localization page.
    • format
      • if "lua_table", then it will look like { ["Some key"] = "Some value" }
      • if "lua_additive_table", then it will look like L["Some key"] = "Some value"
    • key
      • Inserts the translation for the given phrase key. If this is used, the format argument is ignored.
    • handle-unlocalized - what to do when you have an unlocalized string.
      • if "english", then it will output the english value.
      • if "comment", then it will output the english value, but comment it out the line.
      • if "blank" (default), then it will output "", but comment out the line.
      • if "ignore", then no line will be printed out.
    • escape-non-ascii - whether to escape non-ASCII (unicode) strings as escape strings instead of raw UTF-8
      • if false (default), then you get a string like "Über"
      • if true, then you get a string like "\195\156ber"
    • prefix-values
      • This will prefix all value strings the given string. For WoW, the default is nothing. For other games, especially those which are unicode-aware, the prefix could be something along the lines of "L". e.g. "Hello" vs. L"Hello"
    • table-name - used in format="lua_additive_table" only.
      • This defines the name of the table to add to. For WoW, the default is "L". For WAR, the default is "T".
    • same-key-is-true
      • true - if the key is the same as the value, then make the value = true rather than the value itself.
      • false (default) - no special action when value == key.
    • namespace
      • "" (default) - the base namespace, all namespaces derive from this and phrases not attached to a namespace are on this base.
      • "Monkey" - the "Monkey" namespace. This varies based on your project.
      • "Monkey/Banana" - the "Monkey/Banana" subnamespace. This varies based on your project.
    • handle-subnamespaces
      • "none" (default) - don't show subnamespaces at all
      • "subtable" - show subnamespaces as a lua sub-table.
      • "concat" - concatenate the namespace with the key.
    • namespace-delimiter - used when handle-subnamespaces="concat"
      • "/" (default) - concatenate with / as the delimiter.
      • "." - use "." instead.
      • "any other string" - use "any other string" instead.

    Example usage


    Here's an example of AceLocale-3.0 usage with this new system:

    enUS.lua

    local debug = false --@debug@ debug = true --@end-debug@ local L = LibStub("AceLocale-3.0"):NewLocale("MyAddon", "enUS", true, debug) --@localization(locale="enUS", format="lua_additive_table", same-key-is-true=true, handle-subnamespaces="concat")@

    deDE.lua


    local L = LibStub("AceLocale-3.0"):NewLocale("MyAddon", "deDE") if not L then return end --@localization(locale="deDE", format="lua_additive_table", handle-subnamespaces="concat")@

    You're probably wondering about the @debug@ statement, but that's so that in development, you pass in an argument into :NewLocale that makes it so nonexistent translations don't error.

    The resultant code will look like this:


    enUS.lua

    local debug = false --[===[@debug@ debug = true --@end-debug@]===] local L = LibStub("AceLocale-3.0"):NewLocale("MyAddon", "enUS", true, debug) L["Hello, World!"] = true L["How are you today?"] = true L["AwesomeModule/Eat some pie"] = "Eat some pie"

    deDE.lua


    local L = LibStub("AceLocale-3.0"):NewLocale("MyAddon", "deDE") if not L then return end L["Hello, World!"] = "Hallo, Welt!" -- L["How are you today?"] = "" L["AwesomeModule/Eat some pie"] = "Geh Kuchen essen"
    Posted in: Localization Substitutions
  • published the article World of Warcraft

    General

    Version Control

    Posted in: World of Warcraft
  • published the article Automatic Packaging

    Automatic Packaging

    Configuring the Repository Webhook

    Generate a CurseForge API token

    First, you’ll need to generate an API token. To do this, navigate to your API tokens page. From here, give the token a descriptive name such as "Webhooks." Once the token has been generated, move to Step 2 in order to configure the webhook on GitHub or Bitbucket.

    Configuring the Repository Webhook on GitHub or Bitbucket

    First, go to “Webhooks & Services” under settings for your repository and click the “Add Webhook“ button.

    For the Payload URL, use one of the following values, based on the site where your project resides:

     

    https://wildstar.curseforge.com/api/projects/{projectID}/package?token={token}

    https://wow.curseforge.com/api/projects/{projectID}/package?token={token}

    https://www.wowace.com/api/projects/{projectID}/package?token={token}

     

    Replace {projectID} with the ID from the About This Project section of your project’s Overview page on CurseForge, and {token} with the token we just generated above.

    Example: https://wildstar.curseforge.com/api/projects/204592/package?token=21ec57a7-7bc0-454f-ae80-627fb5722df1

    Leave all other settings at their defaults.

    Automatically Marking Your Files as Alpha, Beta, or Release

    When packaging is triggered on your repository, the generated file’s release type will automatically be set based on two factors:

    1. If configured to package all commits, the latest untagged commit will be packaged and will be marked as an alpha.
    2. Otherwise, when a tagged commit is pushed, it will be flagged as either alpha, beta, or release depending on the tag itself:
      • If the tag contains the word “alpha”, for example “1.0-alpha” or “1.0.alpha7”, it will be marked as an alpha file.
      • If instead the tag contains the word “beta,” it will be marked as a beta file.

    File Packaging Configuration

    You can optionally configure the way your file is packaged by including a YAML file named either "pkgmeta.yaml" or ".pkgmeta" in the root of your repository. Each of these behaviors are optional:

    1. Specify the name of the packaged file. If omitted, the packaged file will be named after the project's URL slug.
    2. Inclusion of libraries or code from other projects.
    3. Move files and folders.
    4. Ignore files and folders.
    5. Specify dependencies on other projects, if they are available on the site.
    6. Specify tools used in the development of your project, if they are available on the site.
    7. Override compilation of repository commit messages with a manually-written change log.
    8. Inclusion of the project license in the packaged file.

    An example, with all of the options utilized:

    package-as: KillerCupcakes
    enable-nolib-creation: no
    externals: libs/LibDialog: url: https://github.com/wildstarnasa/LibDialog.git tag: latest # if this line is left out, the latest version (even if it's not a tag) is assumed libs/GeminiAddon: url: https://github.com/wildstarnasa/GeminiAddon.git tag: 1337.0.10 # This is an example. Please use an actual tag if you are targeting a specific version. move-folders: KillerCupcakes/Modules/Fire: KillerCupcakesOnFire # This moves KillerCupcakes/Modules/Fire to the same level as KillerCupcakes, as KillerCupCakesOnFire KillerCupcakes/Modules/Sky: KillerCupcakesInTheSky ignore: # Files and directories beginning with a dot (such as .git) are automatically ignored, as is the pgkmeta file itself. - Scripts - Some/File.txt required-dependencies: - 221710-dear-cupcake optional-dependencies: - 220002-junkit manual-changelog: CHANGELOG.txt license-output: LICENSE.txt tools-used: - data-tools

    Replacement Tokens

    When repositories are packaged, certain keyword substitutions take place on text files.

    Simple replacements

    @file-revision@
    @file-hash@
    The current revision/hash of the file. For example: 106c634df4b3dd4691bf24e148a23e9af35165ea
    @project-revision@
    @project-hash@
    The hash of the entire project in hex form. e.g.106c634df4b3dd4691bf24e148a23e9af35165ea
    @file-abbreviated-hash@
    The abbreviated hash of the file in hex form. e.g. 106c63
    @project-abbreviated-hash@
    The abbreviated hash of the entire project in hex form. e.g. 106c63
    @file-author@
    The name of the last author of the file.
    @project-author@
    The name of the last author of the entire project.
    @file-date-iso@
    The last changed date (by UTC) of the file in ISO 8601. e.g. 2014-05-01T12:34:56Z
    @project-date-iso@
    The last changed date (by UTC) of the entire project in ISO 8601. e.g. 2014-05-01T12:34:56Z
    @file-date-integer@
    The last changed date (by UTC) of the file in a readable integer fashion. e.g.20140501123456
    @project-date-integer@
    The last changed date (by UTC) of the entire project in a readable integer fashion. e.g.2014050123456
    @file-timestamp@
    The last changed date (by UTC) of the file in POSIX timestamp. e.g. 1209663296
    @project-timestamp@
    Turns into the last changed date (by UTC) of the entire project in POSIX timestamp. e.g.1209663296
    @project-version@
    An approximate version of the project. The tag name if on a tag, otherwise the short revision.

    Debug replacements

    These occur based on filetype, as they tend to tie into the comment system for the file.

    The insides aren't removed so that line numbers stay the same, they just cause them to be commented out.

    Lua
    --@debug@ and --@end-debug@
    Turns into --[===[@debug and --@end-debug]===].
    --[===[@non-debug@ and --@end-non-debug@]===].
    Turns into --@non-debug@ and --@end-non-debug@.
    XML
    <!--@debug@--> and <!--@end-debug@-->
    Turns into <!--@debug and @end-debug@-->.
    <!--@non-debug@ and @end-non-debug@-->.
    Turns into <!--@non-debug@--> and <!--@end-non-debug@-->.
    TOC
    #@debug@ and #@end-debug@
    Turns into #@debug@ and #@end-debug@, as well as adding a # to the beginning of each line in-between.

    Exclude from packaging

    These occur based on filetype, as they tend to tie into the comment system for the file.

    --@do-not-package@ and --@end-do-not-package@ (for Lua)
    <!--@do-not-package@--> and <!--@end-do-not-package@--> (for XML)
    #@do-not-package@ and #@end-do-not-package@ (for TOC)
    Removes everything between the @do-not-package@ and @end-do-not-package@ tags including the 2 tags themselves. This may cause line numbers of subsequent lines to change. The typical usage is at the end of Lua files surrounding debugging functions and other code that end users should never see/execute.

    You will still need to comment out the @do-not-package@ and @end-do-not-package@ tags for the relevant file types.

    Alpha replacements

    Occurs for packaged files that are Alpha release status. The transformations are filetype-based, as they tend to tie into the comment style for the file. The text between tokens isn't removed so, that line numbers stay the same; it is simply commented out.
    This is useful for inserting extra debugging information that you want your alpha testers to have, but don't want to appear in release versions.

    Lua
    --@alpha@ and --@end-alpha@
    Turns into --[===[@alpha and --@end-alpha]===].
    --[===[@non-alpha@ and --@end-non-alpha@]===].
    Turns into --@non-alpha@ and --@end-non-alpha@.

    Example:

    --@alpha@
    assert(everythingIsOkay())
    --@end-alpha@
    

    This would make the assert take place in development mode and alpha zips, but not for release and beta.

    XML
    <!--@alpha@--> and <!--@end-alpha@-->
    Turns into <!--@alpha and @end-alpha@-->.
    <!--@non-alpha@ and @end-non-alpha@-->.
    Turns into <!--@non-alpha@--> and <!--@end-non-alpha@-->.
    TOC
    #@alpha@ and #@end-alpha@
    Turns into #@alpha@ and #@end-alpha@, as well as adding a # to the beginning of each line in-between.
    Posted in: Automatic Packaging
  • published the article Automatic Packaging

    Automatic Packaging

    Configuring the Repository Webhook

    Generate a CurseForge API token

    First, you’ll need to generate an API token. To do this, navigate to your API tokens page. From here, give the token a descriptive name such as "Webhooks." Once the token has been generated, move to Step 2 in order to configure the webhook on GitHub or Bitbucket.

    Configuring the Repository Webhook on GitHub or Bitbucket

    First, go to “Webhooks & Services” under settings for your repository and click the “Add Webhook“ button.

    For the Payload URL, use the following value: https://wildstar.curseforge.com/api/projects/{projectID}/package?token={token}
    Replace {projectID} with the ID from your project’s URL on CurseForge, and {token} with the token we just generated above.

    Example: https://wildstar.curseforge.com/api/projects/204592/package?token=21ec57a7-7bc0-454f-ae80-627fb5722df1

    Leave all other settings at their defaults.

    Automatically Marking Your Files as Alpha, Beta, or Release

    When packaging is triggered on your repository, the generated file’s release type will automatically be set based on two factors:

    1. If configured to package all commits, the latest untagged commit will be packaged and will be marked as an alpha.
    2. Otherwise, when a tagged commit is pushed, it will be flagged as either alpha, beta, or release depending on the tag itself:
      • If the tag contains the word “alpha”, for example “1.0-alpha” or “1.0.alpha7”, it will be marked as an alpha file.
      • If instead the tag contains the word “beta,” it will be marked as a beta file.

    File Packaging Configuration

    You can optionally configure the way your file is packaged by including a YAML file named "pkgmeta.yaml" in the root of your repository. Each of these behaviors are optional:

    1. Specify the name of the packaged file. If omitted, the packaged file will be named after the project's URL slug.
    2. Inclusion of libraries or code from other projects.
    3. Move files and folders.
    4. Ignore files and folders.
    5. Specify dependencies on other projects, if they are available on the site.
    6. Specify tools used in the development of your project, if they are available on the site.
    7. Override compilation of repository commit messages with a manually-written change log.
    8. Inclusion of the project license in the packaged file.

    An example, with all of the options utilized:

    package-as: KillerCupcakes
    enable-nolib-creation: no
    externals: libs/LibDialog: url: https://github.com/wildstarnasa/LibDialog.git tag: latest # if this line is left out, the latest version (even if it's not a tag) is assumed libs/GeminiAddon: url: https://github.com/wildstarnasa/GeminiAddon.git tag: 1337.0.10 # This is an example. Please use an actual tag if you are targeting a specific version. move-folders: KillerCupcakes/Modules/Fire: KillerCupcakesOnFire # This moves KillerCupcakes/Modules/Fire to the same level as KillerCupcakes, as KillerCupCakesOnFire KillerCupcakes/Modules/Sky: KillerCupcakesInTheSky ignore: # Files and directories beginning with a dot (such as .git) are automatically ignored, as is the pgkmeta file itself. - Scripts - Some/File.txt required-dependencies: - 221710-dear-cupcake optional-dependencies: - 220002-junkit manual-changelog: CHANGELOG.txt license-output: LICENSE.txt tools-used: - data-tools

    Replacement Tokens

    When repositories are packaged, certain keyword substitutions take place on text files.

    Simple replacements

    @file-revision@
    @file-hash@
    The current revision/hash of the file. For example: 106c634df4b3dd4691bf24e148a23e9af35165ea
    @project-revision@
    @project-hash@
    The hash of the entire project in hex form. e.g.106c634df4b3dd4691bf24e148a23e9af35165ea
    @file-abbreviated-hash@
    The abbreviated hash of the file in hex form. e.g. 106c63
    @project-abbreviated-hash@
    The abbreviated hash of the entire project in hex form. e.g. 106c63
    @file-author@
    The name of the last author of the file.
    @project-author@
    The name of the last author of the entire project.
    @file-date-iso@
    The last changed date (by UTC) of the file in ISO 8601. e.g. 2014-05-01T12:34:56Z
    @project-date-iso@
    The last changed date (by UTC) of the entire project in ISO 8601. e.g. 2014-05-01T12:34:56Z
    @file-date-integer@
    The last changed date (by UTC) of the file in a readable integer fashion. e.g.20140501123456
    @project-date-integer@
    The last changed date (by UTC) of the entire project in a readable integer fashion. e.g.2014050123456
    @file-timestamp@
    The last changed date (by UTC) of the file in POSIX timestamp. e.g. 1209663296
    @project-timestamp@
    Turns into the last changed date (by UTC) of the entire project in POSIX timestamp. e.g.1209663296
    @project-version@
    An approximate version of the project. The tag name if on a tag, otherwise the short revision.

    Debug replacements

    These occur based on filetype, as they tend to tie into the comment system for the file.

    The insides aren't removed so that line numbers stay the same, they just cause them to be commented out.

    Lua
    --@debug@ and --@end-debug@
    Turns into --[===[@debug and --@end-debug]===].
    --[===[@non-debug@ and --@end-non-debug@]===].
    Turns into --@non-debug@ and --@end-non-debug@.
    XML
    <!--@debug@--> and <!--@end-debug@-->
    Turns into <!--@debug and @end-debug@-->.
    <!--@non-debug@ and @end-non-debug@-->.
    Turns into <!--@non-debug@--> and <!--@end-non-debug@-->.
    TOC
    #@debug@ and #@end-debug@
    Turns into #@debug@ and #@end-debug@, as well as adding a # to the beginning of each line in-between.

    Exclude from packaging

    These occur based on filetype, as they tend to tie into the comment system for the file.

    --@do-not-package@ and --@end-do-not-package@ (for Lua)
    <!--@do-not-package@--> and <!--@end-do-not-package@--> (for XML)
    #@do-not-package@ and #@end-do-not-package@ (for TOC)
    Removes everything between the @do-not-package@ and @end-do-not-package@ tags including the 2 tags themselves. This may cause line numbers of subsequent lines to change. The typical usage is at the end of Lua files surrounding debugging functions and other code that end users should never see/execute.

    You will still need to comment out the @do-not-package@ and @end-do-not-package@ tags for the relevant file types.

    Alpha replacements

    Occurs for packaged files that are Alpha release status. The transformations are filetype-based, as they tend to tie into the comment style for the file. The text between tokens isn't removed so, that line numbers stay the same; it is simply commented out.
    This is useful for inserting extra debugging information that you want your alpha testers to have, but don't want to appear in release versions.

    Lua
    --@alpha@ and --@end-alpha@
    Turns into --[===[@alpha and --@end-alpha]===].
    --[===[@non-alpha@ and --@end-non-alpha@]===].
    Turns into --@non-alpha@ and --@end-non-alpha@.

    Example:

    --@alpha@
    assert(everythingIsOkay())
    --@end-alpha@
    

    This would make the assert take place in development mode and alpha zips, but not for release and beta.

    XML
    <!--@alpha@--> and <!--@end-alpha@-->
    Turns into <!--@alpha and @end-alpha@-->.
    <!--@non-alpha@ and @end-non-alpha@-->.
    Turns into <!--@non-alpha@--> and <!--@end-non-alpha@-->.
    TOC
    #@alpha@ and #@end-alpha@
    Turns into #@alpha@ and #@end-alpha@, as well as adding a # to the beginning of each line in-between.
    Posted in: Automatic Packaging
  • published the article Rewards Program Terms of Service

    Rewards Program Terms of Service

    Terms last modified on January 11, 2019.

    PLEASE READ THIS AGREEMENT CAREFULLY; THIS IS A BINDING CONTRACT.

    Welcome to the CurseForge Author Rewards Program, operated by Curse LLC (unaffiliated with Curse Media). Curse LLC (referred herein as “CurseForge,” “we,” “our,” or “us”) provides access to the CurseForge Author Rewards Program (the “Rewards Program”) for certain authors of add-on applications (“Add-On Applications”) and/or add-on application libraries (“Add-On Libraries” and collectively with Add-On Applications, “Add-Ons”) that are distributed through curseforge.com and other websites that are the part of the CurseForge website network (collectively, the “Sites”) and certain other account holders of the Sites that participate in various programs offered by CurseForge.

    The terms and conditions contained in this Rewards Program Terms of Service (the "Rewards Program TOS") apply to each Sites account holder that elects to participate in the Rewards Program (referred herein as “Participant”, “user,” “you,” or “your”). The Rewards Program TOS is in addition to the TERMS OF SERVICE which can be found at https://www.twitch.tv/p/legal/terms-of-service/ and the PRIVACY POLICY which can be found at https://www.twitch.tv/p/legal/privacy-policy/.

    PLEASE READ THE CURSEFORGE REWARDS PROGRAM TOS, THE TERMS OF SERVICE AND THE PRIVACY POLICY CAREFULLY. YOU MUST AGREE TO THE CURSEFORGE REWARDS PROGRAM TOS, THE TERMS OF SERVICE AND THE PRIVACY POLICY BEFORE REGISTERING FOR THE CURSEFORGE REWARDS PROGRAM. IF YOU DO NOT ACCEPT AND AGREE TO ALL THE TERMS AND CONDITIONS OF THE CURSEFORGE REWARDS TOS AS WELL AS THE TERMS OF SERVICE AND THE PRIVACY POLICY, YOU MUST NOT REGISTER FOR THE CURSEFORGE REWARDS PROGRAM.

    If you have any questions about the Rewards Program, please visit our FAQ. If you don’t find the answer to your question in our FAQ, you can e-mail us at support@curseforge.com. Please include your name and username in all correspondence.

    1. Description of Rewards Program

    The Rewards Program provides certain users of the Sites the opportunity to receive CurseForge Rewards Points (“Points”) based upon certain metrics that CurseForge determines in its sole discretion, which metrics CurseForge may change from time to time in its sole discretion, with or without notice to you.

    2. Rewards Program TOS Updates

    CurseForge may revise this Rewards Program TOS as the Rewards Program evolves. You must agree to all revisions if you choose to continue participating in the Rewards Program. By using the Rewards Program after such an update, you agree to the then-current version of this Rewards Program TOS as posted on http://authors.curseforge.com/rewards-program/119-rewards-program-terms-of-service. If at any point you do not agree to any portion of the then-current version of this Rewards Program TOS, you must immediately discontinue being a member of the Rewards Program and opt-out of the Rewards Program by going to the Rewards Program Settings section of your user profile.

    3. Eligibility

    You must be an individual person at least 18 years of age to register for the Rewards Program. Minor children may participate in the Rewards Program through the use a parent or guardian’s Rewards Program account so long as the parent or guardian consents and accepts full responsibility for the conduct of the child. Any entity other than individual persons are not allowed to register for the Rewards Program. To register for the Rewards Program, you must have an active, valid user account through the Sites and “opt-in” to participate in the Rewards Program. If you are part of a team of authors that has created an Add-On, you may register for the Rewards Program on behalf of your team, however, you will be solely responsible for distributing Points earned, if any, amongst your team members. CurseForge shall have no responsibility over, nor incur any liability related to, the distribution of Points between you and the rest of the creators of your project.

    4. Earning Points

    Points may be earned in a variety of manners, including, without limitation: (1) submitting projects; (2) participating in testing new features or applications available through the Sites; (3) moderating Sites forums; or (4) engaging in other activities for which points may be earned. CurseForge determines, in its sole and absolute discretion: (a) how Points are earned; (b) the amount of Points earned for each particular Rewards Program activity; and (c) when such Points, if any, shall be distributed to you. CurseForge expressly reserves the right to establish additional means of earning Points, to delete any or all means of earning Points, to exclude specific types of activities from those that allow points to be earned, to adjust your points, or to terminate the Rewards Program at any time, for any reason, or no reason at all.

    Rewards will be earned and calculated as specified in the FAQs found at https://authors.curseforge.com/rewards-program/110-rewards-program-faq.

    YOU HEREBY ACKNOWLEDGE AND AGREE THAT YOUR PARTICIPATION IN THE REWARDS PROGRAM DOES NOT GUARANTEE THAT YOU WILL EARN ANY POINTS. CURSEFORGE MAKES NO REPRESENTATION, WARRANTY OR GUARANTEE THAT YOU WILL RECEIVE ANY POINTS THROUGH YOUR PARTICIPATION IN THE REWARDS PROGRAM.

    5. Points Redemption

    You may redeem Points through certain designated areas of the Sites in which CurseForge may offer various items with assigned Point values. When you select a particular item offered through the Sites, and provided you have enough Points to acquire that item, the Points in your account will be reduced by the Point value designated for such item after you have completed the ordering process. Physical products that you have ordered through Points redemptions will be delivered within the time period specified for the delivery method designated on the Sites. Provided you have a Paypal account and you have submitted your Paypal account information to CurseForge, you may elect to redeem Points for cash. Cash redemptions are only available for 1000 Points or more. Should you elect to redeem your Points for cash, CurseForge will make a payment to your Paypal account in the cash amount redeemed within sixty (60) days from the date of redemption. All cash redemptions will be paid in US Dollars. Information regarding the conversion value of Points for cash can be found at https://authors.curseforge.com/store. All the other terms of this Section 5 with regards to item redemption apply to cash redemptions.

    ALL REDEMPTIONS OF POINTS ARE DEEMED FINAL. YOU ACKNOWLEDGE AND AGREE THAT REDEMPTIONS OF POINTS ARE NOT REFUNDABLE, IN WHOLE OR IN PART. YOU ARE FULLY RESPONSIBLE AND LIABLE FOR ALL REDEMPTIONS OF POINTS THROUGH YOUR ACCOUNT, INCLUDING, WITHOUT LIMITATION, ANY UNAUTHORIZED REDEMPTIONS.

    You must provide your current accurate taxpayer information to CurseForge. You acknowledge and agree that you are solely liable for the payment of any and all taxes resulting from your redemption of Points, and you further acknowledge and agree that you will execute any documents and do any such other acts or deeds as requested by CURSEFORGE with regards to your payment of such taxes. If CurseForge does not have current taxpayer information for you on file for a particular year, CurseForge may refuse your redemption of Points or withhold certain amounts from your redemptions as determined by CurseForge in its sole and absolute discretion.

    Reward items may be subject to third party terms and conditions.

    6. Points Expiration

    Points will expire on the third anniversary from the end of the month in which you earn them. For example, if you earn 10 Points in February, 2013, those 10 Points will expire if you do not redeem them prior to February 28, 2016. CurseForge may, but is not obligated to, provide you an email reminder that your Points will expire to the email address you provided in creating your Rewards Program account. You are solely responsible for tracking when your Points will expire.

    7. Ownership

    As between you and CurseForge, CurseForge owns the Sites and the Points. You hereby expressly acknowledge and agree that:

    POINTS HAVE NO VALUE OUTSIDE OF THE CURSEFORGE REWARDS PROGRAM AND YOU HAVE NO CLAIM, RIGHT, TITLE, PROPRIETARY OR OWNERSHIP INTEREST IN ANY POINTS; AND

    CURSEFORGE SHALL NOT BE LIABLE IN ANY MANNER FOR THE DESTRUCTION, DELETION, MODIFICATION, IMPAIRMENT, HACKING OF OR ANY OTHER DAMAGE OR LOSS OF ANY KIND OF THE POINTS YOU HAVE RECEIVED, IF ANY, INCLUDING, BUT NOT LIMITED TO, DELETION OF POINTS UPON THE TERMINATION OR EXPIRATION OF YOUR ACCOUNT OR EXPIRATION OF POINTS PURSUANT TO SECTION 6.

    8. Prohibited Activities

    You agree that you will not buy, sell or trade, or offer to buy, sell or trade, any Points with any individual or entity other than by (1) redeeming Points with CurseForge pursuant to Section 5 above; or (2) giving Points to other CurseForge account holders through the Sites. For the avoidance of doubt, and in no way limiting the foregoing, you are prohibited from offering for sale or purchasing any Points (whether or not held by accounts registered to you) outside of the Sites, through a website, or any other medium, or exchanging Points, whether inside or outside the Sites except as set forth in Section 5 above or in this Section 8, for anything of value outside the Sites.

    CurseForge has the right to terminate your Sites account if you violate the Terms of Service or any other CurseForge policy. Additionally, CurseForge may terminate your Sites account if CurseForge determines, in its sole and absolute discretion that you have: (1) engaged in fraud or deceitful conduct relating to the Rewards Program; or (2) engaged in any illegal act or violated any law, regulation or policy relating to the Rewards Program.

    You expressly acknowledge and agree that your participation in the Rewards Program is void where prohibited or restricted by law.

    9. Disclaimer of Warranties

    YOUR PARTICIPATION IN THE REWARDS PROGRAM IS AT YOUR SOLE RISK. THE REWARDS PROGRAM IS PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS. CURSEFORGE EXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.

    CURSEFORGE MAKES NO WARRANTY THAT (I) THE REWARDS PROGRAM WILL MEET YOUR REQUIREMENTS, (II) THE REWARDS PROGRAM WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE, (III) THE RESULTS THAT MAY BE OBTAINED FROM PARTICIPATING IN THE REWARDS PROGRAM WILL BE ACCURATE OR RELIABLE, (IV) THE QUALITY OF ANY PRODUCTS, SERVICES, INFORMATION, OR OTHER MATERIAL OBTAINED BY YOU THROUGH THE REWARDS PROGRAM WILL MEET YOUR EXPECTATIONS, OR (V) ANY ERRORS IN THE SITES AND/OR REWARDS PROGRAM WILL BE CORRECTED.

    Because some states or jurisdictions do not allow the disclaimer of implied warranties, the foregoing disclaimer may not apply to you.

    10. Limitation of Liability

    TO THE MAXIMUM EXTENT PERMITTED BY LAW, CURSEFORGE, ITS AFFILIATES, LICENSORS AND BUSINESS PARTNERS (COLLECTIVELY, THE “RELATED PARTIES”) DISCLAIM ALL LIABILITY, WHETHER BASED IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, AND FURTHER DISCLAIM ALL LOSSES, INCLUDING WITHOUT LIMITATION DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, OR SPECIAL DAMAGES ARISING OUT OF OR IN ANY WAY CONNECTED WITH ACCESS TO OR USE OF THE REWARDS PROGRAM AND/OR THE SITE, EVEN IF CURSEFORGE AND/OR RELATED PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. WITHOUT LIMITING THE FOREGOING, IN NO CASE SHALL THE LIABILITY OF CURSEFORGE OR ANY OF THE RELATED PARTIES EXCEED THE AMOUNT THAT YOU RECEIVED THROUGH REDEEMING POINTS DURING THE SIX (6) MONTHS PRIOR TO THE TIME YOUR CAUSE OF ACTION AROSE.

    Because some states or jurisdictions do not allow the exclusion or the limitation of liability for consequential or incidental damages, in such states or jurisdictions, the liability of CurseForge and/or the Related Parties shall be limited to the fullest extent permitted by law.

    11. Indemnification.

    In addition to your indemnification obligations set forth in the Terms of Service, you agree to indemnify, defend and hold CurseForge and the Related Parties harmless from any claim, demand, damages or other losses, including reasonable attorneys’ fees, asserted by any third-party resulting from or arising out of any breach by you of this Rewards Program TOS.

    12. Termination

    You acknowledge that CurseForge, in its sole discretion, may terminate your username, password, account (or any part thereof) or use of the Rewards Program for a variety of reasons, including, without limitation, if CurseForge believes that you have violated or acted inconsistently with the letter or spirit of the Rewards Program TOS or any other agreement referred to in the Rewards Program TOS. You agree that any termination of your access to the Rewards Program under any provision of the Rewards Program TOS may be effected without prior notice, and acknowledge and agree that CurseForge may immediately deactivate or delete your account and/or bar any further access to the Rewards Program. If your account is terminated by CurseForge, it will not be automatically renewed and access will be terminated, without refund. If for any reason your account is terminated by either CurseForge or you, all Points in your account will be immediately forfeited. Further, you agree that CurseForge shall not be liable to you or any third-party for termination of your access to the Rewards Program.

    13. Conflicts

    In the event of any conflict between the Terms of Service and this Rewards Program TOS, the terms and provisions of this Rewards Program TOS shall control and prevail to the extent related to the CurseForge Author Rewards Program.

    14. Contact

    We may contact you via e-mail or postal mail to provide you with information about the Rewards Program or your account or to provide you with information about special offers available only to CurseForge Rewards Program participants.

    Posted in: Rewards Program Terms of Service