# How to publish a resource

How to publish a resource

If you've written your very own script or resource, you want to publish it somewhere online so that others can use it in their projects and enrich their game and users' experience.

Submitting Tutorials & Resources

We have our very own Resource Manager where you can upload all your own resources, tutorials and assets, which can be found at https://reliccastle.com/resources/, or by going back up the index from where you're viewing this tutorial.

Upon creating a resource here, you'll be asked to choose which category your resource belongs to. These categories are as follows:
• Tutorials
• Game Development and Design
• Pokémon Essentials
• Miscellaneous
• Resources
• Audio
• Graphics
• Scripts
• Miscellaneous
Use your own judgment to determine what category is best suited for your resource. Once you've selected a category, there will be various fields for you to fill out. These are described below.

• Title: Write a descriptive and direct title. If it's a resource or collection of resources with it's own "brand name" (e.g. "Elite Battle System"), that's alright too.
• Version String: The forum's system allows for updates without having to create a new duplicate resource. If left blank, this will become the date the resource was posted.
• Tag Line: A brief summary of what the resource is about. (e.g. "A tutorial on how to do this, this and that")
• Pokémon Essentials Version: When relevant to the category, this field will be shown. Select the version of Pokémon Essentials to which the resource or tutorial was made for. It's important to know if the resource is not compatible with a newer version of Pokémon Essentials.
• Description: This is the main body of your resource or tutorial. You should be very thorough when explaining what the resource is, how does it work, or any sort of instructions. The clearer you are, the less problems users will encounter.
• Tags: These tags will allow your resource to be found more easily, but do not use irrelevant tags either. For example, if I were to upload some Pokémon Essentials windowskins, I would just write "windowskin" as a tag. Maybe "text box" as well.
• Credits: Provide a list of credits that the user should provide when using your resource, which will appear in a Credits tab. If credit is not required, please state so. When listing credits, please add "Credit if used:" or some variant before listing names for clarity sake. If you notice your content is being used against your wishes or you're being uncredited, please contact an administrator. We'll work with you and the offending project to make sure proper credit is given or the project is removed from Relic Castle.

When posting a resource...
Provide an in-depth installation guide. If it includes code, make smart use of BBCode formatting, and use a text hosting site such as Pastebin when the script is too long. Be sure to give the Plugin Manager section below a read too, to make sure you use Pokémon Essentials to its fullest potential.

When posting a tutorial...
Be as descriptive as possible when explaining the steps to follow and make sure it works before submitting it (so test it yourself!). Tutorials with just steps to follow are good, but it's also important to explain the reason behind each step, so that the user may also learn from it instead of copy-pasting to their project.

When rating a resource...
You'll always be asked for a review while rating a resource. Do not give a resource a bad rating because you did not get it working. Instead, refer to the resource's thread (generated automatically) or reach the author first. For resources with a download link, you'll be required to use the download link provided. Ratings will be moderated for fairness.

Plugin Manager

If you're using Pokémon Essentials v18, there's a brand new Plugin Manager that you should use in all your new (and updated) scripts. The purpose of this Plugin Manager is to streamline dependency control by warning you if you're missing dependencies, if they're not the right version, if you've got duplicate installations, or if you have two incompatible plugins installed.
Furthermore, the Plugin Manager keeps a list of credits that are automatically inserted into the Credit scene, provided you don't remove the keyword in there that inserts them. This just saves a bit of time when crediting, and will make sure the creators are credited regardless of what happens.

So without further ado, I've got a simple example how you register a plugin below.
Ruby:
PluginManager.register({
:name => "Basic Plugin",
:version => "1.0"
})

This is the simplest way to register your plugin. You will not have your name inserted into the credits however, and if another plugin requires a newer version of this plugin, there will not be a link where to update. So let's add it! Let's pretend that the creators of this plugin are Foo and Bar, and that the link to the plugin is https://reliccastle.com/resources/1. Be sure to choose a unique name too, because you cannot have two plugins with the same name. If you know your type of plugin is common, such as "Footprints", be sure to add a unique identifier, such as your name + the resource name.
Ruby:
PluginManager.register({
:name => "My New Plugin",
:version => "1.0",
:credits => ["Foo", "Bar"],
})

The version of the program can be anything you want; a number or a string, following semantic versioning, using a-z, or anything else you come up with. However, it's important that you apply the versioning consistently in updates, or the version comparison will fail. For instance, the Plugin Manager doesn't know how to compare version 2.1 with 2.a, but it does know how to compare 2.1 with 2.1 or 2a with 2b. Similarly, if a version point is added, like 1.0 and 1.0.1, it will be compared properly.

Now let's say we have a plugin that we want to call Super Plugin, but it requires Basic Plugin. In that case, we specify the dependency field. Furthermore, you can omit the array in the credits field if it's just one name, just like with dependencies.
Ruby:
PluginManager.register({
:name => "Super Plugin",
:version => "1.0",
:credits => "Foo",
:dependencies => "Basic Plugin"
})

Now if we don't have Basic Plugin installed above Super Plugin, you will get an error asking for the Basic Plugin.

We can also specify which version of the dependency we want to check for by making the name an array of the name and version, and while we're at it, we can add another dependency.
Ruby:
PluginManager.register({
:name => "Mega Plugin DX",
:version => "1.0",
:credits => "Bar",
:dependencies => [
["Basic Plugin", "1.1"],
"Super Plugin"
]
})

Here we require Basic Plugin to be installed at at version 1.1 (or higher), and we generally require any version of Super Plugin to be installed. You can also check for one specific version using an :exact flag. Besides that flag, there's also :optional. This optional exact flag will ignore the plugin if it's not installed, but if it is, test it against the version specified. There's also :optional_exact, which is a combination of the two.
Ruby:
PluginManager.register({
:name => "Better Plugin",
:version => 427,
:credits => "Baz",
:dependencies => [
[:exact, "Basic Plugin", "1.1"],
[:optional, "Super Plugin", "1.0"]
]
})

In this example code we require Basic Plugin to be exactly version 1.1, no newer or older, and, if Super Plugin has been installed, it must be version 1.0.

What's more, we can also specify that one plugin is not compatible with another through the incompatibilities field. This is useful if you have two plugins that have the same purpose and/or override each other, or plugins that generally break if both used at once. For instance, the DP Pause Menu resource and the Modular Pause Menu resource.
Ruby:
PluginManager.register({
:version => "1A",
:credits => ["Fubar", "Foobar"],
})
Credits
Non-applicable
Author
Marin
Views
581
First release
Last update
Rating
0 ratings