Migration
This guide explains how to migrate from BetonQuest 1.12.X or any BetonQuest 2.0.0 dev build to BetonQuest 2.0.0.
The majority of changes will be migrated automatically. However, some things must be migrated manually.
The migration will first find any 1.12 packages in the BetonQuest plugin folder and migrate them to the 2.0 package format. It will then place them inside the newly introduced QuestPackages folder. Then it updates everything inside the QuestPackages folder to the new 2.0 syntax. This way the migration works for both 1.12 and 2.0.0-DEV packages.
Warning
Before you start migrating, you should backup your server!
Changes🔗
Steps marked with are migrated automatically. Steps marked with must be done manually.
- 2.0.0-DEV-87 - Rename to
ride
- 2.0.0-DEV-98 - RPGMenu Merge
- 2.0.0-DEV-238 - Package Structure Rework
- 2.0.0-DEV-337 - Event Scheduling Rework
- 2.0.0-DEV-450 - Package section
- 2.0.0-DEV-485 - Experience changes
- 2.0.0-DEV-538 - Smelt Objective
- 2.0.0-DEV-539 - NPC Holograms
- 2.0.0-DEV-644 - Database migration for profiles
- 2.0.0-DEV-647 - EffectLib
- 2.0.0-DEV-674 - MMO Updates
- 2.0.0-DEV-749 - Static Event Rework
- 2.0.0-DEV-769 - RemoveEntity-Event
2.0.0-DEV-87 - Rename to ride
🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
To unify the naming for riding a vehicle, we renamed the condition (riding
) and the objective (vehicle
)
to ride
.
rideHorse: riding Horse
rideHorse: ride Horse
rideHorse: vehicle Horse events:teleport
rideHorse: ride Horse events:teleport
2.0.0-DEV-98 - RPGMenu Merge 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
All existing RPGMenu users must update their RPGMenu config file. Simply rename it from rpgmenu.config.yml
to
menuConfig.yml
.
2.0.0-DEV-238 - Package Structure Rework 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
- Ensure your server is running on Java 17
- Move your current Quests to the folder "BetonQuest/QuestPackages"`, as quests are now loaded from there
- Rename all "main.yml" files to "package.yml"
- Quest packages can now contain nested quest packages in sub folders. You can also have any file and folder structure with any file and folder names you want. Only the "package.yml" is reserved as indicator for a quest package.
-
Therefore, the "events.yml`, "objectives.yml", "conditions.yml", "journal.yml" and "items.yml" files must be updated to the following format: Every type that was previously a separate file with a special name is now identified by a "parent-section". It's the names of the type / the name the file previously had. Let's take a look at an example for events and conditions:
Example
events.ymlmyEvent: "teleport 1;2;3;world" myOtherEvent: "point level 1"
conditions.ymlmyCondition: "location 300;200;300;world"
events.ymlevents: myEvent: "teleport 1;2;3;world" myOtherEvent: "point level 1"
conditions.ymlThis allows you to freely name the files. Also, it is no longer necessary that events, conditions etc. are in separate files. You could also put everything in a single file or use any other file structure:conditions: myCondition: "location 300;200;300;world"
anyFileName.ymlevents: myEvent: "teleport 1;2;3;world" myOtherEvent: "point level 1" conditions: myCondition: "location 300;200;300;world"
Warning
You must do this change for all types, not just events and conditions!
-
Alongside the previous change, conversations and menus must also be updated to the following format: Add an extra prefix matching their type and the file name:
Example
lisa.ymlquester: Lisa first: option1, option2 NPC_options: option1: # ...
anyFileName.ymlconversations: lisa: #(1)! quester: Lisa first: option1, option2 NPC_options: option1: # ...
- This key is now the conversation name that you must refer to when linking NPCs to conversations.
Or alternatively:
conversations.lisa: quester: Lisa first: option1, option2 NPC_options: option1: # ...
2.0.0-DEV-337 - Event Scheduling Rework 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
-
All your static events need to be converted to the new scheduling system. The
realtime-daily
schedule makes this easy:Example
Old Syntaxstatic: '09:00': beton '11:23': some_command,command_announcement
New Syntaxschedules: betonAt09: #(1)! type: realtime-daily #(2)! time: '09:00' #(3)! events: beton #(4)! cmdAt1123: type: realtime-daily time: '11:23' events: some_command,command_announcement
-
A name for the new schedule.
Can be anything you want for organizing your schedules. -
The type schedule
realtime-daily
was created for easy updating.
It behaves just like the old static events. -
The former key is now the time value.
You still have to put it in 'quotes'. -
The former value is now the events value.
-
2.0.0-DEV-450 - Package Section 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
-
There is now a new section
package
for organizing package related settings. As a result of this theenabled
boolean was moved to this section. If you use theenabled
boolean you need to move it to thepackage
section.Example
Old Syntaxenabled: false
New Syntaxpackage: enabled: false
2.0.0-DEV-485 - Experience changes 🔗
Due to a misuse of the Spigot API, all code regarding player experience (experience
event, condition and objective) had to be changed.
It is not possible to obtain the amount of experience points a player has, only their level can be obtained.
If you used any of these elements you might have to adjust the configured values because the behaviour changed as follows:
- The
experience
objective and condition do not allow raw experience anymore. Only levels are supported from now on. - The
experience
objective, condition and event now supports decimal numbers.
For example, you can useexperience 1.5
to check for one and a half level.
You can convert raw experience points to levels, using such decimal numbers.
2.0.0-DEV-538 - Smelt Objective 🔗
The smelt
objective now requires a quest item instead of a BlockSelector.
Therefore, you now need to define the item you want to smelt in the items section.
It is recommended to use the /q item packageName.ItemName
command to save the target item from in-game. This will save the
item you currently hold in your hand to the given package with the given name.
After you did this, you need to replace the BlockSelector in the smelt
objective with the item's name.
2.0.0-DEV-539 - NPC and Non-NPC Holograms 🔗
Potentially Faulty Automatic Migration
In some cases this migration will not be run although the configuration is in the 1.12 format.
This is the case because it is not possible to reliably detect if the configuration must be migrated - it simply has not changed enough.
If the (NPC-)hologram section does NOT contain one of the following keys the migration will NOT be run:
follow
check_interval
If this is the case you need to update the configration manually. See the steps below.
Both NPC and Non-NPC Holograms were reworked. Mainly three things have to be changed:
- The
vector
is now above the head of the NPC by default. This was previously achieved with0;3;0
. Therefore, every hologram that has defined a vector is now three blocks higher than before. If it is set to0;3;0
delete the vector argument. Otherwise, subtract3
from the y-axis. - The
follow
boolean can now be set for each NPC Hologram, so you have to add it to each NPC Hologram. It's off by default. Don't add it to still-standing NPCs. This will save you a lot of performance. - The
check_interval
can now be set for each NPC Hologram as well. This allows for finer control over how much server resources are used.
npc_holograms:
check_interval: 200
follow: true
default:
lines:
- "Some text!"
conditions: "has_some_quest"
vector: 0;3;0
npcs:
- 0
- 22
npc_holograms:
default:
lines:
- "Some text!"
conditions: "has_some_quest"
vector: 0;0;0 #(1)!
check_interval: 200 #(2)!
follow: true #(3)!
npcs:
- 0
- 22
- You can delete this if you had
0;3;0
previously as the origin was changed. Subtract 3 from the y-axis for any other value. - You can delete this if you had the default value of
200
(or whatever you set in "config.yml"). - You can delete this if you had the default value of
false
.
2.0.0-DEV-644 - Database migration for profiles 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
The database migrated to a new format for profiles and every profile will have a name. You can set a initial creation name in your config.yml, so every new generated profile (through migration or joining of a new player) will get this name. If you don't set a initial name, the initial name will be "default".
Example
profiles:
initial_name: player # (1)!
- Only set this if you want to change the initial name. If you don't set this, the initial name will be "default".
2.0.0-DEV-647 - EffectLib 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
The EffectLib integration was rewritten. With this rewrite, the following things are now possible:
- NPC effects will now move with the NPC
- Effects can be assigned to locations
The following changes need to be done:
- Rename
npc_effects
toeffectlib
. - Add
pitch: -90
to preserve the old rotation to NPC effects. - Remove
check_interval
from the npc_effects section - Remove
disabled
from the npc_effects section
npc_effects:
check_interval: 50
disabled: false
farmer:
class: VortexEffect
iterations: 20
particle: crit_magic
helixes: 3
circles: 1
grow: 0.1
radius: 0.5
interval: 30
npcs:
- 1
conditions:
- '!con_tag_started'
- '!con_tag_finished'
effectlib:
farmer:
class: VortexEffect
iterations: 20
particle: crit_magic
helixes: 3
circles: 1
grow: 0.1
radius: 0.5
pitch: -60 #(4)!
yaw: 90
interval: 30 #(1)!
checkinterval: 80 #(2)!
npcs: #(3)!
- 1
locations:
- 171;72;-127;world
conditions:
- '!con_tag_started'
- '!con_tag_finished'
- This field is optional. You can delete this if you had the default value of
100
. - This field is new and optional. It replaces the old
check_interval
field. You can delete this if you had the default value of100
. - In case you never had the
npcs
field and the effect were played on every npc in the package, you now need to add thenpcs
section with every npc the effect should be played at. - In case you never had the
pitch
field, you need to use the default value of-90
.
2.0.0-DEV-674 - MMO Updates 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
A change related to the integration of the MMO suite by Phoenix Development was made.
The objectives mmocorecastskill
and mmoitemcastability
were merged into the mmoskill
objective.
The mmoskill
objective works exactly like its predecessors, but also supports defining one or more trigger types.
See the objective's documentation for more information.
castMMOCoreSkill: "mmocorecastskill DEEP_WOUND"
castMMOItemSkill: "mmoitemcastability DEEP_WOUND"
castMMOCoreSkill: "mmoskill DEEP_WOUND trigger:CAST"
castMMOItemSkill: "mmoskill DEEP_WOUND trigger:RIGHT_CLICK"
2.0.0-DEV-749 - Static Event Rework 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
Until now if you used non-static events in a schedule, they were executed for every player that was online at the time.
If you run such a schedule now you will get a warning message in the console similar to this:
Example
[15:27:10 WARN]: [BetonQuest] Cannot fire non-static event 'announcements.ringBell' without a player!
To fix this wrap the event in a runForAll
event:
events:
# Events that require a player (non-static events).
bell_sound: 'notify io:sound sound:block.bell.use'
bell_ring: 'folder bell_sound,bell_sound,bell_sound,bell_sound period:0.5'
# Player independent events (static events).
notify_goodNight: 'notifyall &6Good night, sleep well!'
schedules:
sayGoodNight:
type: realtime-daily
time: '22:00'
events: bell_ring,notify_goodNight
events:
# Events that require a player (non-static events).
bell_sound: 'notify io:sound sound:block.bell.use'
bell_ring: 'folder bell_sound,bell_sound,bell_sound,bell_sound period:0.5'
# Player independent events (static events).
notify_goodNight: 'notifyall &6Good night, sleep well!'
bell_ring_all: 'runForAll events:bell_ring' #(1)!
schedules:
sayGoodNight:
type: realtime-daily
time: '22:00'
events: bell_ring_all,notify_goodNight #(2)!
- Runs
bell_ring
for all online players. notify_goodNight
is a static event, so no need to wrap it inrunForAll
.
While this seems like more work for the same functionality it gives you more control over how events are run.
With this change we finally allow using conditions in schedules!
Just keep in mind you can only add player dependent conditions if the event is run player dependent (wrapped inside runForAll
).
Tip
To check if your event still works inside a schedule or if it must be wrapped, use the following command to run the event without a player:
/q event - <package>.<event>
-
is important, it means run independent .
2.0.0-DEV-769 - RemoveEntity-Event 🔗
Automated Migration
The migration is automated. You shouldn't have to do anything.
As you probably noticed, the ClearEntity
event and the KillMob
event did almost the same thing.
Both got merged into the RemoveEntity event,
while keeping the syntax more or less the same.
events:
clearArea: 'clear ZOMBIE,CREEPER 100;200;300;world 10 name:Monster'
killBolec: 'killmob ZOMBIE 100;200;300;world 40 name:Bolec'
events:
clearArea: 'removeentity ZOMBIE,CREEPER 100;200;300;world 10 name:Monster'
killBolec: 'removeentity ZOMBIE 100;200;300;world 40 name:Bolec kill'