Configuration file
All you need to know about the configuration file.
The plugin works as follows. When the player logs in, the plugin draws three random quests from the files. When the player logs out, the current quests are saved in a file. If the quests have been drawn for more than 24 hours, new ones replace them.
The plugin offers two modes:
Mode 1, which means that the quests will only come from the globalQuests.yml file.
Mode 2, which will give the player one quest per category file, i.e. an easy quest, a medium quest, and a hard quest.
You can select the mode you want, and change it at any time without changing the quest files.
However, if you change from one mode to another, we recommend that you delete the progress.yml file, because the next time the player logs in, it could generate errors, or the wrong quests could be loaded.
You can also change the names of the interfaces, the items to fill in the blanks, and the texts for the player menu.
For now, two storage methods are available : YAML and MySQL.
YAML : player progressions will be stored in a "progression.yml" file.
H2 : player progressions will be stored in a "database.mv.db" file.
MySQL : player progressions will be stored in a MySQL database. To configure, pleaser refer to the "database" section in the config.yml file.
The choice of storage only affects the progress of the players. Quests should always be created in the appropriate YAML files.
Please pay attention to the indentation on all YAML files. The slightest mismatch may cause errors when the plugin is loaded.
Also, you should never delete a variable, framed by percentages (%). These variables are used to display information such as quest names, rewards, number of items required...
This file supports HEX colour codes.
Anti-glitch
With the store_xx_xx options in the configuration file, you can prevent players from abusing quests, e.g. by breaking and placing the same block to make them progress.
Here is how it works:
store_placed_blocks
BREAK
All blocks that have been placed by a player will not count in the quest progression.
store_broken_blocks
PLACE
All blocks that have been broken by a player will not count in the quest progression.
store_dropped_items
PICKUP
All items that have been dropped by a player will not count in the quest progression.
Warning: the options store_broken_blocks and store_dropped_items adds an NBT tag to the item dropped by the player. This means that its signature changes, and it will no longer be possible to stack them with unaffected items of the same type. However, these items are still normally usable.
The objects used are all stored using standard Spigot API objects: PersistentDataContainer and Metadata. This means that ODailyQuests does not store anything itself, everything is managed by the server. So there shouldn't be any particular problems, except if the API changes from one version to another.
On the other hand, this kind of data is not saved after the server is restarted. But this will still limit abuse for the most part.
Custom types
Since the 2.3.0, it is possible to create custom quest types directly in the configuration file.
This kind of quest can be used with other plugins rewards or actions with the following command :
/dqa customcomplete <player> <type> <amount>
These quests can therefore only be progressed and completed via the command. This type of quest can be very useful if you need a type that doesn't already exist, linked to a plugin.
Let's take an example. You have a shop with rare items made with ShopGUI+, and one of your quests is to buy a Nether Star. In your O'DailyQuests configuration, you have the following block :
# ===========================================================
# CUSTOM QUESTS TYPES
# Here you can add custom quests types that can be complete only with command:
# /dqa customcomplete <player> <type> <amount>
# This kind of quest can be used with other plugins rewards or actions.
# ===========================================================
custom_types:
- "BUY_NETHER_STAR"Then, you can add your custom type to your quest config :
1:
name: "Nether Star"
menu_item: NETHER_STAR
description:
- "Buy a Nether Star on the shop and win 500$."
quest_type: BUY_NETHER_STAR
required_amount: 1
reward:
reward_type: MONEY
amount: 500And you should have the following item in your ShopGUI+ configuration :
1:
type: command
item:
material: NETHER_STAR
quantity: 1
commands:
- "give %PLAYER% nether_star 1"
- "dqa customcomplete %PLAYER% BUY_NETHER_STAR 1"
requireInventorySpace: true
buyPrice: 100
slot: 0And that's it! When the player buys a Nether Star, the command will be executed, and if the player has a quest of type BUY_NETHER_STAR, it will progress by 1. If the player doesn't have the quest, nothing happens, quite simply.
You can create as many types as you like, associating one per action. You can use them wherever the other plugin lets you run commands as a console: dungeons, quests, mini-games, events... You can even complete them manually during your hand-managed events.
Last updated