Configuration file

All you need to know about the configuration file.

Summary

Storage Mode

Three storage modes are available : SQLite, MySQL and YAML.

YAML : player progressions will be stored in a progression.yml file.
SQLite: player progressions will be stored in a database.mv.db file. This is the recommended storage mode.
MySQL : player progressions will be stored in a MySQL or MariaDB database. To configure, pleaser refer to the database section in the config.yml file.

Quests per category

This section of the configuration file is used to define the number of daily quests assigned to the player for each category. Only the categories listed here will be loaded, ensuring precise control over which quest categories are active. You can add as many categories as you want.

Category Listing and Order: The listed categories dictate the order in which quests are assigned. The order is crucial as it affects the prioritization of quest assignments.
Category Naming: Each category name must match the respective filename containing the quests. For example, the category "global" corresponds to quests found in global.yml. Additional categories can be added as needed.

Example Configuration:

quests_per_category:
  easy: 1   # Assigns 1 quest from the "easy.yml" file.
  medium: 1 # Assigns 1 quest from the "medium.yml" file.
  hard: 1   # Assigns 1 quest from the "hard.yml" file.

⚠️Changing this configuration when quests are already assigned to players can cause problems and require their quests to be reset. Also, make sure you have enough quests in the categories, otherwise the plugin will not start!

To know how to properly create a category, please look at this page.

Timestamp Mode Configuration

The timestamp_mode setting in the configuration file determines how and when quests are reloaded for players. Setting the correct mode is crucial for aligning quest resets with your intended gameplay experience and server operation. Here are the available modes:

Mode 1: Quests are reloaded at a defined renew time for all players simultaneously. This approach ensures that all players receive new quests at the same server-wide refresh time.
Mode 2: Quests are reloaded based on the player’s activity. If a player's active quests are older than the duration specified in the temporality mode, they will receive new quests upon logging in. This provides a personalized experience, as each player may receive new quests at different times based on their individual login activity.

Important Considerations:

If you're using the first mode, ensure your server's machine is set to the correct time zone, as the timestamp function depends on it.
In the second mode, quests are renewed the first time they are progressed or consulted, after the time limit has passed. This means that if the player takes no action on the quests for, say, two hours after the renewal time, they will not be renewed until then.
If you switch between modes, player progressions may require a reset to reflect the changes.

By configuring the timestamp_mode appropriately, you can tailor quest availability to suit your server environment and player preferences.

Renew Time

The renew_time setting allows you to define the specific time at which quests will be reloaded. This configuration ensures that players receive new quests in a timely manner based on the server's clock settings.

Accepted Formats

You can specify the renew_time using the following formats:

"3AM": Represents 03:00 in 12-hour format with AM/PM.
"3:15AM": Represents 03:15 in 12-hour format including minutes.
"15": Represents 15:00 in 24-hour format without minutes.
"15:30": Represents 15:30 in 24-hour format with minutes.

By default, the renew_time is set to "00:00", which reloads quests at midnight. Adjust this time according to server requirements and player activity patterns to optimize the quest experience.

Renew Time Zone

Depending on your server configuration, you may wish to change the time zone used for the renew_time parameter. By default, the system time zone is used (SystemDefault). However, you will find all the time zones that can be used on this page.

Renew Interval

The renew_interval setting allows you to specify the frequency at which quests will be reloaded automatically. This interval ensures consistent engagement by refreshing quests at regular intervals, improving the overall player experience.

Accepted Formats

You can configure the renew_interval using the following formats:

"1d": Reloads quests every 1 day.
"2h": Reloads quests every 2 hours.
"30m": Reloads quests every 30 minutes.
"1h30m": Reloads quests every 1 hour and 30 minutes.

By default, the renew_interval is set to "1d", resulting in a daily reload of the quests. Adjust the interval according to your server's dynamics and quest demands to maintain optimal player engagement.

Temporality Initials

The temporality_initials configuration allows you to customize the initials that are displayed between the time values in quest schedules. This can be helpful in providing a clear and understandable format for players.

Configuration options:

days: Default initial is "d" for days.
hours: Default initial is "h" for hours.
minutes: Default initial is "m" for minutes.
few_seconds: Displays as "Few seconds" when the time is less than a minute.

Example usage:

Format: 6d9h24m would be interpreted as 6 days, 9 hours, and 24 minutes.

Global Reward

The global_reward configuration is used to define rewards given to players upon completing all their daily quests. This can serve as an additional incentive for players to fully engage in quest activities each day. Configuration options:

enabled:
- Type: boolean
- Description: Enables or disables the global reward. Set to true to activate.
reward_type:
- Type: string
- Description: Determines the type of reward. All types can be viewed here.
commands:
- Type: list of strings
- Description: Commands to be executed as rewards for the player. Use %player% to reference the player receiving the rewards.
Example
```
global_reward:
  enabled: true
  reward_type: COMMAND
  commands:
    - "eco give %player% 5000"
    - "give %player% diamond_block 32"
```
In this configuration example, a player completing all daily quests will receive 5000 currency units and 32 diamond blocks. Make sure your server supports the used commands and placeholders for correct execution.

Categories Rewards

The categories_rewards configuration grants rewards to players who complete all daily quests within a specific category. The syntax aligns with that of quest rewards and the global reward. This feature will be disabled by default if the quests mode is set to 1. Ensure that the name of the category matches exactly with the name in the quests_per_category section.

Example Configuration

categories_rewards:
  global:
    enabled: true
    reward_type: COMMAND
    commands:
      - "eco give %player% 1000"
      - "give %player% gold_block 1"

In this example, players completing all quests in the "global" category receive 1000 currency units and 1 gold block. Adjust rewards and categories according to game design needs.

To know how to properly create a category, please look at this page.

Title

The title section allows you to set a custom title that appears on the player's screen upon completing a quest. Two placeholders are available: %player% and %questName%.

Configuration Options

enabled: Set to true to display the title upon quest completion.
fadeIn: Determines the number of ticks for the title to completely appear on the screen.
stay: Sets how long the title remains visible.
fadeOut: Configures the number of ticks for the title to completely disappear.
text: The primary message displayed as the title.
subtitle: An optional secondary message. You can leave this blank if no subtitle is desired.

Example

title:
  enabled: true
  fadeIn: 10
  stay: 70
  fadeOut: 20
  text: "&aWell done, %player%"
  subtitle: "&aYou have completed the quest %questName% &a!"

Adjust these settings to customize the quest completion experience to fit your game design.

Toast Notification

Show a native Minecraft "advancement-style" toast when a player completes a quest. This is a lightweight, non-intrusive way to celebrate progress without opening a GUI or spamming chat.

Placeholders supported: %player%, %questName% Line breaks: Use \n inside text to add a new line.

Configuration options

enabled (boolean) : Turn the toast on/off.
frame (string) : Visual style of the toast border and sound. One of:
- TASK (simple)
- GOAL (golden rim)
- CHALLENGE (purple rim, more “epic” feel)
icon (string) : Item shown in the toast. Use a valid Bukkit Material name (e.g., DIAMOND, PAPER, NETHERITE_INGOT). If you use a resource pack, pick the base item your model targets.
custom_model_data (integer, optional) : Custom Model Data to display a resource-pack model for the chosen icon.
text (string) : The message shown in the toast. Supports color codes (&a, &b, …) and \n for a second line.

# Display a toast notification when a player completes a quest.
# Available placeholders : %player% , %questName%
toast:
  enabled: false
  frame: TASK          # Frame type: TASK / GOAL / CHALLENGE
  icon: DIAMOND        # Icon displayed in the toast (Bukkit Material)
  # custom_model_data: 123   # Optional: resource-pack model for the icon
  text: "&b&lQuest completed!\n%questName%"  # Use \n for a new line

Note: Toast animations/timings are handled by the Minecraft client and are not configurable. Also, keep messages short; the toast has limited space. A two-line format (title + subtitle) reads best.

Progression Message

The progression_message section allows you to configure a message displayed to the player as they progress through a quest. It supports various visual formats and includes several placeholders for dynamic content.

Available placeholders: %player%, %questName%, %progressBar%, %progress%, %required%

Available types: ACTIONBAR, BOSSBAR, CHAT

Note: The CHAT type is not recommended as it may lead to chat spam.

Configuration Example:

progression_message:
  enabled: true
  text: "%progressBar% &7(&b%progress%&a/&b%required% &7- &e%questName%&7)"
  type: BOSSBAR
  bossbar: # applicable only if type is BOSSBAR
    color: PURPLE # Refer to BarColor options
    style: SEGMENTED_6 # Refer to BarStyle options

BarColor options can be viewed here. BarStyle options can be viewed here.

Customize these settings to tailor the visual feedback provided during quest progression. Adjust type to specify the display format and configure additional settings if using the BOSSBAR type, such as color and style.

Actionbar

The actionbar section lets you set a custom message in the actionbar when a player completes a quest. Similar to the title feature, this provides immediate feedback to enhance the player's gaming experience.

Available placeholders: %player%, %questName%

Configuration Options

enabled: Set to true to display the message in the actionbar upon quest completion.
text: The message shown in the actionbar. Customize using available placeholders for dynamic content.

Example Configuration

actionbar:
  enabled: true
  text: "&eYou have completed the quest %questName%&e!"

Progress Bar

The progress bar allows players to visually track their quest advancement. Customize it by defining various parameters that control its appearance and functionality.

Configuration Options

symbol: The character used to visually represent each unit of progress within the bar.
amount_of_symbols: Defines the total length of the progress bar by specifying how many symbols will fill the bar.
completed_color: Sets the color code for the symbols that represent completed progress.
remaining_color: Sets the color code for the symbols that represent uncompleted progress.

Example Usage

progress_bar:
  symbol: "|"
  amount_of_symbols: 20
  completed_color: "&a"
  remaining_color: "&7"

In this configuration, a progress bar 20 symbols long will be displayed using the | symbol. Completed segments will appear in green (&a), while remaining segments will appear in gray (&7). Adjust these parameters to seamlessly match your game's visual style and provide clear feedback to players.

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:

Config. option

Involved quest type

Description

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 option store_broken_blocks 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 Items Support

When integrating custom items into your quest system, it's crucial to configure the plugin to recognize the specific tools or items being used. Below are the configuration options available for different custom item plugins:

use_itemsadder
use_oraxen
use_nexo

If you're using one of these plugin items somewhere in your ODailyQuests config, you must set to true the corresponding one.

⚠️ Activating this parameter without having the relevant plugin installed will cause quests to not load.

use_custom_furnace_results

If plugins modify furnace results with custom model data, set it to true. This setting ensures compatibility with custom item data from furnaces. It is enabled by default when using one of the previous settings.

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: 500

And 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: 0

And 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.

Interfaces

In this section, you can configure the display settings for each quest category interface within the game. This includes setting a custom name for the inventory interface and selecting an item type to fill the empty slots in the interface's display grid.

next_item_name: The label for the item allowing players to navigate to the next page.
previous_item_name: The label for the item allowing players to go back to the previous page.

For each quest category, specify the following:

inventory_name: The name of the inventory interface shown to players.
empty_item: The item type that fills the empty slots in the interface.

Examples of category configurations:

interfaces:
  next_item_name: "&a&lNext Page"
  previous_item_name: "&e&lPrevious Page"
  global: # Ensure it aligns with the category name listed in the quests_per_category.
    inventory_name: "Quests - Global"
    empty_item: BLACK_STAINED_GLASS_PANE

Here, the global category displays as "Quests - Global" with empty slots filled by black stained glass panes.

To know how to properly create a category, please look at this page.

Disabled Worlds

In this section, you can configure which worlds should have quest progression disabled. To specify a world to be excluded from quest progression, list the world name under the disabled_worlds section. This name generally corresponds to the world directory name.

You have three options here:

Specify World Names: List the exact world names.
Wildcard Usage: Use the "?" character as a wildcard to disable multiple worlds with common prefixes or suffixes. For example, "?_survival" will apply to any world names ending in "_survival".
Keep All Worlds Active: If quest progression should not be disabled in any world, use hooks: disabled_worlds: [].

Example Configuration:

disabled_worlds:
  - "world_nether"
  - "world_the_end"

This configuration will prevent quests from progressing in the nether and the end worlds. For more granular control, worlds can also be disabled per individual quest, as detailed in the documentation.

NPCs

The NPCs implementation section allows you to define NPC names corresponding to each quest category. Players must engage with these NPCs to open the quest interface. Each category of quests has a specific NPC name as configured in the npcs section. Ensure the NPC names match exactly with the categories listed under quests_per_category for a seamless experience.

Here's some examples of how to configure NPC names:

player: This NPC opens the interface for player-specific quests.
```
player: "&7Player Quests"
```
global: The NPC if we have a category named global.
```
global: "&4Global Quests"
```

This functionnality is currently compatible with Citizens and FancyNpcs. For both integrations, you must specify the display name, i.e., the name shown to the player. This also includes color codes!

Other Configuration Items

Parameter

Type

Description

debug

Boolean

Useful if the plugin doesn't work as expected. To be activated on developer's request to facilitate support. Generates a debug.yml file containing technical information. Not to be activated, as it consumes additional resources.

check_for_update

Check if the plugin is up to date and send a message to the console if it is not.

disable_logs

Boolean

If you're annoyed by the save and load player quests messages on login and logout, you can enable this option to remove them.

safety_mode

Boolean

This option ensures that all players have the required number of quests. If disabled, it allows only quests requiring permission in the file, but players without the permissions may not have any quests.

player_data_load_delay

Numeric

Delay in seconds before player quest data is loaded after login. Useful when using the same database across multiple servers to avoid sync issues.

join_message_delay

Numeric

Adds a delay before quest messages are displayed when the player logs in.

synchronised_progression

Boolean

If a player has two quests of the same type and with the same item/entity, choose if they should progress simultaneously, or if the first should be completed before the second progresses.

disable_spawners_progression

Boolean

Disables the progression of quests where you have to kill an entity if it comes from a Spawner. This setting does not apply to players with the odailyquests.bypass.spawner permission.

complete_on_click

Boolean

Quests are not completed automatically when reaching the required amount. If enabled, this behaves like a GET quest and the message appears in the interface once the required progress has been achieved.

take_items_for_get_quests

Boolean

Determines if the player loses required items when completing a GET quest.

reroll_only_if_not_achieved

Boolean

Determines if the quest can be rerolled even if it has already been completed, when using the reroll command.

shared_mobs

Boolean

If you are using MythicMobs, you can set this parameter to "true" to share the mobs between players. It means that if someone kill a mob, the quest progression will be updated for all players that were involved in the fight and that have the quest.

use_wildstacker

Boolean

If you use WildStacker on your server to group mobs, set this parameter to "true". Otherwise, quests of type KILL may not progress.

use_rosestacker

Boolean

If you use RoseStacker on your server to group mobs, set this parameter to "true". Otherwise, quests of type KILL may not progress.

Default Configuration File

config.yml

# if the plugin doesn't work as expected, set debug to true and send the log file to the developer.
debug: false

# check if the plugin is up to date and send a message to the console if it is not
check_for_update: true

# never touch these lines, used for the plugin auto update system
version: 3.0.0
database_version: 2

# prefix that will be displayed before every message from messages.yml
prefix: '&3[&bO''DailyQuests&3] '

# disable the logs when player quests are loaded or saved
disable_logs: false

# storage mode for quests & progression
# AVAILABLE MODES: YAML, MySQL, SQLite
# RECOMMENDED: SQLite
storage_mode: "SQLite"

# MySQL Database Connection
database:
  name: "MyDatabase"   # Database name
  host: "127.0.0.1"    # Database host
  user: "admin"        # Database user
  password: "1234"     # Database password
  port: 3306           # Database port

# Delay in seconds before player quest data is loaded after login.
# Useful when using the same database across multiple servers to avoid sync issues.
# Do not change this value unless you are sure of what you are doing.
player_data_load_delay: 0.5

# When enabled (default), the plugin will stop loading if a category does not have enough quests without permissions
# to give every player the required amount of daily quests.
#
# Disable this if you want categories where all quests require permissions.
# /!\ Players without permissions may then end up with no quests at all!
safety_mode: true

# Define the number of daily quests assigned to the player for each category.
# Categories that are not listed here will not be loaded.
#
# The order in which categories are listed matters! Quests will be assigned in this order.
#
# The category name must exactly match the filename containing the quests (e.g., "easy" refers to "easy.yml").
# You can create and configure as many categories as you want.
#
# More information here: https:////////////
quests_per_category:
  #examples: 9
  easy: 3  # The player will receive 3 quests from the "easy.yml" file
  medium: 3
  hard: 3

# Select the mode of timestamp.
# ============================================================================
# 1 : quests will be reloaded at the defined renew time for all players.
# ============================================================================
# 2 : player quests will be reloaded if active quests are older
# than the duration selected temporality mode.
# This means that each player will have new quests at a different login time.
# ============================================================================
# The timestamp depends on the machine on which your server is installed.
# Set the right time zone!
# ============================================================================
# You need to reset progressions if you change this mode.
timestamp_mode: 1

# Select the time at which the quests will be reloaded.
# Accepted formats are:
# - "3AM"         → 03:00 (12-hour format with AM/PM)
# - "3:15AM"      → 03:15 (12-hour format with minutes)
# - "15"          → 15:00 (24-hour format without minutes)
# - "15:30"       → 15:30 (24-hour format with minutes)
# Default is "00:00" (midnight).
# Remember to surround the value with double quotes, otherwise it will not work!
renew_time: "00:00"

# Set the time zone for the renew_time. (e.g., "UTC", "Europe/Paris", "America/New_York")
# You can find the list of time zones here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
# If you want to use the server time zone, set it to "SystemDefault".
renew_time_zone: "SystemDefault"

# Select the interval at which the quests will be reloaded.
# Accepted formats are:
# - "1d"    → 1 day
# - "2h"    → 2 hours
# - "30m"   → 30 minutes
# - "1h30m" → 1 hour and 30 minutes
# Default is "1d" (1 day).
# Remember to surround the value with double quotes, otherwise it will not work!
renew_interval: "1d"

# Delay in seconds before the status message is displayed when a player joins the server.
# Corresponds to quests_in_progress and all_quests_achieved_connect messages.
join_message_delay: 1.0

# Initials that will be displayed
# between the values on the placeholders.
# ex: 6d9h24m
temporality_initials:
  days: "d"
  hours: "h"
  minutes: "m"
  few_seconds: "Few seconds"

# Global Reward
# Will be given when the player has completed all his daily quests.
# The syntax is the same as for quest rewards.
global_reward:
  enabled: true
  reward_type: COMMAND
  commands:
    - "eco give %player% 2000"
    - "give %player% iron_ingot 16"

# Categories Rewards
# Will be given when the player has completed all his daily quests of a precise category.
# The syntax is the same as for quest rewards, and the global reward.
# Will be by default disabled if the quests mode is set to 1.
# The name of the category must match the name of the category in the quests_per_category section.
categories_rewards:
  easy:
    enabled: true
    reward_type: COMMAND
    commands:
      - "eco give %player% 750"
      - "give %player% diamond 1"
  medium:
    enabled: true
    reward_type: COMMAND
    commands:
      - "eco give %player% 1000"
      - "give %player% diamond 2"
  hard:
    enabled: true
    reward_type: COMMAND
    commands:
      - "eco give %player% 1500"
      - "give %player% diamond 3"

# Set a title that will be displayed when a player completes a quest.
# Reminder: 20 ticks is equal to one second.
# Available placeholders : %player% , %questName%
title:
  enabled: true
  fadeIn: 10 # The default number of ticks for the title to fade in.
  stay: 70 # The default number of ticks for the title to stay.
  fadeOut: 20 # The default number of ticks for the title to fade out.
  text: "&aWell done, %player%"
  subtitle: "&aYou have completed the quest %questName%&a!" # Leave this field blank if you do not want a subtitle

# Display a toast notification when a player completes a quest.
# Available placeholders : %player% , %questName%
toast:
  enabled: false
  frame: TASK # Frame type: TASK / GOAL / CHALLENGE
  icon: DIAMOND # Icon displayed in the toast
  # custom_model_data: 123 # Optional: custom model data for resource-pack icons
  text: "&b&lQuest completed!\n%questName%" # Supports \n for new line

# Set a message that will be displayed in the actionbar when a player completes a quest.
# Available placeholders : %player% , %questName%
actionbar:
  enabled: true
  text: "&eYou have completed the quest %questName%&e!"

# Set a message that will be displayed to the player when he progresses in a quest.
# Available placeholders : %player% , %questName% , %progressBar% , %progress% , %required%
# Available types : ACTIONBAR, BOSSBAR, CHAT
# /!\ The CHAT type is not recommended, it can cause chat spam.
progression_message:
  enabled: true
  text: "%progressBar% &7(&b%progress%&a/&b%required% &7- &e%questName%&7)"
  type: BOSSBAR
  bossbar: # only apply if type is set to BOSSBAR
    color: PURPLE # https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/boss/BarColor.html
    style: SEGMENTED_6 # https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/boss/BarStyle.html

# Here you can customize the progress bar that can be used with the %progressBar% placeholder.
# symbol: the symbol that will be used to fill the progress bar.
# amount_of_symbols: the number of symbols that will be used.
# completed_color: the color of the symbols for the progress made.
# remaining_color: the color of the symbols for the progress to be achieved.
progress_bar:
  symbol: "|"
  amount_of_symbols: 20
  completed_color: "&a"
  remaining_color: "&7"

# ===========================================================
# ANTI-GLITCH PART
# Here you can prevent some abuse from players, by storing the items they have used.
# ===========================================================

# All blocks that have been placed by a player will not count towards the progress of a BREAK quest.
store_placed_blocks: false

# All items dropped by a player will not count towards the progress of a PICKUP quest.
store_dropped_items: false

# All blocks that have been broken by a player will not count towards the progress of a PLACE quest.
#
# Warning: this option adds an NBT tag to the item(s) dropped by the block.
# 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.
store_broken_blocks: false

# ===========================================================
# CUSTOM ITEMS SUPPORT
# ===========================================================

# Enable this if you are using IA items for quest menu or required items.
# NEVER enable this if you are NOT using ItemsAdder. The quests will not load.
use_itemsadder: false

# Enable this if you are using Oraxen items for quest menu or required items.
# NEVER enable this if you are NOT using Oraxen. The quests will not load.
use_oraxen: false

# Enable this if you are using Nexo items for quest menu or required items.
# NEVER enable this if you are NOT using Nexo. The quests will not load.
use_nexo: false

# Enable this if some plugins are modifying the furnace results.
# You should enable it if the furnace results can have a custom model data (e.g. with Oraxen).
# Enabled by default if you are using ItemsAdder.
use_custom_furnace_results: false

# ===========================================================
# 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.
# More information on the Wiki.
# ===========================================================
custom_types:
  - "COMPLETE_DUNGEON"
  - "KILL_BOSS"
  - "BUY_VIP"

# ===========================================================

# Here you can define the name of the interfaces for each quests category.
# You can also define which item will be displayed to fill the empty slots.
# The name of the category must match the name of the category in the quests_per_category section.
interfaces:
  next_item_name: "&a&lNext Page"
  previous_item_name: "&e&lPrevious Page"
  examples:
    inventory_name: "Quests - Examples"
    empty_item: BLACK_STAINED_GLASS_PANE
  easy:
    inventory_name: "Quests - Easy"
    empty_item: LIME_STAINED_GLASS_PANE
  medium:
    inventory_name: "Quests - Medium"
    empty_item: ORANGE_STAINED_GLASS_PANE
  hard:
    inventory_name: "Quests - Hard"
    empty_item: RED_STAINED_GLASS_PANE

# You can disable quest progression in certain worlds.
# You must put here the name of the world (in theory the name of its directory).
# If you don't want to disable worlds, just put hooks. (disabled_worlds: []).
# In addition, you can disable some worlds for each quest. Please refer to the Wiki.
#
# You can also use prefixes/suffixes to disable multiple worlds at once with the "?" character.
# For example, "?_survival" will disable all worlds ending with "_survival".
disabled_worlds: []
  # - "world_nether"
  # - "world_the_end"

# ===========================================================
# INTEGRATIONS - Functionalities related to other plugins
# ===========================================================

# Citizens Implementation
# Here you can select NPCs names for each category.
# The player have to interact with the NPC to open an interface.
# 'player' is the name of the NPC that will open the player quests interface.
# For categories, the name must match the name of the category in the quests_per_category section.
npcs:
  player: "&7Player Quests"
  examples: "&eExample Quests"
  easy: "&a&lEasy Quests"
  medium: "&6&lMedium Quests"
  hard: "&c&lHard Quests"

# If a player has two quests of the same type and with the same item/entity,
# choose if they should progress simultaneously
# or if the first should be completed before the second progresses.
synchronised_progression: false

# Disables the progression of quests where you have to kill an entity if it comes from a Spawner.
disable_spawners_progression: false

# Determines if the player loses required items when completing a GET quest.
take_items_for_get_quests: false

# When enabled, quests that reach their required progression must be completed via the menu to grant rewards.
complete_only_on_click: false

# Determines if the quest can be rerolled even if it has already been completed, when using the reroll command.
reroll_only_if_not_achieved: false

# If you are using MythicMobs, you can set this parameter to "true" to share the mobs between players.
#
# It means that if someone kill a mob, the quest progression will be updated for all players
# that were involved in the fight and that have the quest.
shared_mobs: false

# If you use WildStacker on your server to group mobs, set this parameter to "true".
# Otherwise, quests of type KILL may not progress.
use_wildstacker: false

# If you use RoseStacker on your server to group mobs, set this parameter to "true".
# Otherwise, quests of type KILL may not progress.
use_rosestacker: false

# You can define aliases for the player command (/dailyquests) here.
#
# Important:
# - These aliases apply only to the player command (/dailyquests), not to the admin command.
# - Before adding an alias, make sure it's not already used by another plugin.
# - Also check that the alias is not already listed here:
#   https://ordwenplugins.gitbook.io/odailyquests/commands/player-commands#aliases
#
# Format: a list of strings. Example:
# command_aliases:
#   - daily
#   - challenges
#
# For pratical reasons, editing this option need a server restart to take effect.
command_aliases: []

# You can define aliases for player subcommands (/dailyquests ...) here.
#
# Important:
# - These aliases apply only to the player command (/dailyquests), not to admin commands.
# - Subcommand aliases allow players to use alternative names like:
#     /dailyquests list   -> /dailyquests show
#     /dailyquests refresh     -> /dailyquests reroll
# - Before adding an alias, make sure it’s not already used by another subcommand or plugin.
#
# Format: map where keys are the original subcommands, and values are lists of aliases.
# Example:
# subcommand_aliases:
#   show:
#     - list
#     - view
#   reroll:
#     - re
#     - refresh
#
# For practical reasons, editing this option need a server restart to take effect.
subcommand_aliases:
  me: []
  show: []
  reroll: []

# If you want to keep only the aliases in the tab completion of the subcommands.
# The original command will not be displayed in the tab completion, BUT the player will still be able to use it.
keep_only_aliases_in_completion: false

Previous2.3.0 -> 3.0.0 NextMessages file

Last updated 6 days ago