• 欢迎来到Minecraft插件百科!
  • 对百科编辑一脸懵逼?帮助:快速入门带您快速熟悉百科编辑!
  • 因近日遭受攻击,百科现已限制编辑,有意编辑请加入插件百科企鹅群:223812289

GuillaumeVDN的插件文档/迁移

来自Minecraft插件百科
Qsefthuopq讨论 | 贡献2020年10月25日 (日) 16:50的版本
跳转至: 导航搜索
GuillaumeVDN的插件文档
页面

GuillaumeVDN的插件文档 · 迁移

所有插件都有的常见内容

配置 · 杂项 · 关联

QuestCreator

基础内容 · 示例 · 详细特性 · 高级内容 · 关联

迁移至GCore v8和QuestCreator v6

QuestCreator的v6版本需要v8版本的GCore作为前置。我彻底重制了这一版本的插件,新版本的插件可以实现之前所无法实现的功能。

最重要的是,它可以让插件维护更加高效。而且让我不会在面对几年前写的破代码时痛不欲生。之前版本的代码质量虽然可读性强,但到了要修复bug或更新时,我几乎不知所措。这是因为这些代码是我在几年前刚学编程时写的。现在我的编程技术已炉火纯青,几个月前我就有了重制插件这一想法。正是因此你才会看到这份文档和我重制的插件。

我很感谢所有在过去几个月里耐心等待修复漏洞和更新插件的人。虽然有些人只因为他们买了我的产品就似乎认为我属于他们,认为我就应该快点更新插件,但很多人都表示支持[和/或]耐心等待重制插件,即便在重制期间我很少更新插件和修复漏洞。虽然这听起来很傻,但Minecraft目前是我生活的重要组成部分,我非常感谢你们的支持。

我的其它插件

我专注于开发QuestCreator,因为我收到来自这款插件的询问最多。我计划重制我的全部插件,但这需要点时间。我计划在2020-2021年期间完成,只要我有时间,就会去做这件事。

目前只有QuestCreator v6兼容GCore v8。如果你同时使用QuestCreator和我的其它插件,那么你需要同时下载旧版的Gcore 。对此造成的不便我深感抱歉。

警告

这个版本的插件并不稳定,请在投入到正在运行的服务器之前进行充分测试。我会在Discord服务器上发布早期测试版来修复大多数重大漏洞。现在我所公开发布的版本是为了加速调试插件,也为 了不让你们等待太久。

请在Discord服务器汇报任何你遇到的重大问题,如果不是那么严重的问题,你可以在GitLab上汇报。

我会分批处理漏洞,频繁发布新的build,可能每3-4天发布一次。我也会在Discord上发布新的build,以避免无谓的等待时间(对已验证用户而言)。

备份你的服务器

为了避免必须手动调整所有的变更配置,GCore v8和QuestCreator v6内置了一个自动转换配置和数据文件的系统。我用一堆不同的文件测试过该系统。但是某些东西可能会出乎意料地被破坏。

我不管一些人怎样看待我的插件,但无论如何我是不会特意在我的插件中加入漏洞的 ^_^ 。我会尽我所能地修复它们,但我无法预料所有情况,这也是为何插件会存在漏洞。

So, to avoid data loss, I want you to make a complete backup before migrating on your production server. Not only my plugins files, but the entire server, including maps, player data states, and data from other plugins. Although QuestCreator never directly alters that, there are more than likely commands/economy rewards, item manipulation, etc, in your quests, and new bugs might trigger them unexpectedly.

I won’t bear responsability for data loss or any irreversible change due to you not backing up before an update. But it’s something I unfortunately hear too often, so please, just back up !

除了备份之外, there’s no particular instruction for migration. Back up, and replace old .jar files by the new ones, and migration will begin automatically on start.


主要变更和新增内容

The structure of many things is mostly the same (quests, activators, …), there are new features, config standardization, nomenclature standardization and small changes. And there’s a brand new damn documentation !

I have to admit I didn’t note every single thing that changed, because there are just too many. Here’s a list of most important changes that come to my mind. If you have any doubt about something changing, I advise you to check the relevant part of this documentation. I also just advise you to read through it once, at least the generic and basic sections.

优化和数据

The first thing that comes to my mind about this update is optimization. That’s not something that’s actually visible to you, but the code is way clearier, more optimized, more consistent, and all of that cool stuff. This will allow better maintenance. I also standardized many libraries, which means things like “that bug you fixed here happened there as well” will no longer happen.

Data boards now are handled much more consistently, with proper async/callback management. I won’t get into details here but it means data saving is much more consistent, and some random problems you might have sometimes (duplicated quests, data files not removing, …), won’t happen anymore.

配置、物品和变体

I have rewritten a YAML parser, instead of using the default bukkit one. The most major improvement to me is that it keeps comments and config organization whenever re-writing the file. Find out more info about it on that page.

Many configuration sections weren’t consistent from one place to another. The main example I can think of are items : it wasn’t always the same settings from one place to another. Sometimes you could have some settings, but sometimes not ; and most of the time, settings such as ‘exact_match’ or ‘remove_after_action’ were included in the items configuration, but weren’t accepted everywhere. Now, everything is consistent : items have their own sections and specific settings are located outside. Most of those generic configuration sections are documented here

Items are now handled much better and have a much more consistent behavior. You can configure most of the specific item meta, and also NBT tags more clearly (instead of an unreadable base64 encoded text).

Read more details about variants (materials/sounds/particles) here. This doesn’t change much as I used the same old names most of the time, but this allows more freedom and clarity (mainly for me, but you’re also free to edit it and you always have an up-to-date list of available materials/sounds/particles for your server).

文本

Texts are to me the main downside of this update, and something I have to apologize about : I couldn’t find a way to smoothly convert existing lang files. Because of many reasons (many texts were added, removed or modified, the meaning of some texts changed, placeholders aren’t the same, etc).

Doing an automatic conversion for texts would just give a messy, incoherent, not good-looking result, and also would take too much time (and I’m running out of time for this summer). So you will have to retranslate your texts in your own language. I’m sorry about that to all the translators, I know translating texts can be really boring and take a long time.

On the brighter side, texts now have their own folders for each plugin, instead of just one messy texts.yml file with all the languages in. So translating will be less annoying and clearier.

指令

With every major update seem to come improvements to my commands library. I guess most of you will be happy with the main change : no more -argument:value format.

Where you previously needed to write /qc start -q:farm_quest -p:player, you can just write /qc start farm_quest player, like a regular, normal, not annoying command system.

Arguments musn’t follow a particular order : /qc start farm_quest GuillaumeVDN, /qc start GuillaumeVDN farm_quest will have the same effect.

Argument detection was improved, you don’t have to write the entierty of arguments, and there’s also a better autocompletion system. If the plugin stops suggesting values for an argument, it means it found a single fitting value. For instance, typing ‘Guillaume’ will result in ‘GuillaumeVDN’ for a player argument, or even just ‘g’ if there are no other players whose name start with the letter G.

So all of those commands will have the same effect : /qc start GuillaumeVDN farm_quest, /qc start Guillaume farm, /qc start g farm, /qc start g fa. This makes commands less annoying to type, but beware to not shorten the things too much, as you might accidentally start another quest starting with fa, or for another player starting with g.

Most commands with a target player argument will be performed for the sender if none is specified.

It’s also a cool thing to note that the reload commands now completely unloads all config and data and reloads a fresh instance of everything.

文件结构

File structure didn’t change a lot for GCore, but it did for QuestCreator.

Here’s a summary of the new hierarchy. New features and changes are explained further below.

  • /plugins/QuestCreator/ :
    • data_v6/ : player/server data files (there are some local files even if you’re using MySQL) for QuestCreator *(previously all data files were centralized in GCore
    • quest_models/ (same as before)
    • quest_models_functional/ (new)
    • quest_activators/ (previously all activators were in the same config file)
    • quest_groups/ (previously all groups were in the same config file)
    • quest_pools/ (previously all pools were in the same config file)
    • quest_states/ (new)
    • guis/ (same as before)
    • global_branches/ (new)
    • global_conditions/ (previously all global conditions were in the same config file)
    • global_gui_items/ (new)
    • global_objects/ (new)
    • global_time_frames/ (new)
    • global_variables.yml (same as before)
    • server_variables.yml (new)
    • default_variables.yml (previously in config.yml)
    • points_categories.yml (previously in config.yml)
    • config.yml (same as before)

GUI

GUI handling was recoded as well and comes with some improvements. Everything is handled to try to avoid lag as much as possible, especially when loading big multi-page GUIs, or ranking GUIs with many player skins to fetch and stuff like that.

If you have ProtocolLib installed, a client-side packets implementation of GUIs will be used. This avoids extra event processing by Spigot and should result in slightly better performance if you have many plugins interacting with inventories.

Some config improvements and freedom were brought as well, such as page configuration and clicks overrides. More information on this page.

激活器和注册

Some useless activator types have been removed, such as ENABLED, DISABLED, and stuff like that. A quest now don’t need an activator anymore. If it has no activator, it can still be started using the GUI or command, as long as they have the permission to do so. Some activator types also were adapted/removed.

The registration file is also gone. You don’t need to register your quest models in order for them to be started. Activators can be configured directly in the quest model file. Groups now have their quests configured inside their own configuration.

任务目标和条件

Most quest objects and conditions were converted (with nomenclature standardization for names and settings) or deleted/replaced by alternatives. A few useful things were added, such as special objects CONDITIONS_SWITCH, LOGIC_SWITCH and DIVERGE_GUI. See the new list of objects for reference.

多目标任务目标(方块/实体/物品)

A feature that has been requested for a long time now is multiple goals within the same objects. That is now possible for most blocks, entities and items player objects.

For existing blocks/items/entities quests, that currently only have one possible objective, the plugin will create an objective in the multiple objectives list. This objective will have the id a. For instance :

# Old configuration
my_object:
  type: PLAYER_BLOCK_BREAK
  block_type: [DIRT,GRASS_BLOCK]
  amount: 50

# New, converted configuration
my_object:
  type: PLAYER_BLOCKS_BREAK
  blocks:
    a:
      types: [DIRT,GRASS_BLOCK]
      goal: 50.0

Is is crucial that you leave this id to a. If you change it, progression for objects currently active for players will be reset to 0.

物品目标和关联条件

Some integrations had their own item conditions and objects. For instance, PLAYER_QUANTUMRPG_ITEM_PICKUP or MMOITEMS_ITEM.

Those objects have been removed (except some very specific ones) because of the new easy NBT configuration. It was kind of painful to maintain all of those, instead of having one, consistent item condition/object type.

For those specific conditions and objects, you might have to import them again. Some testing will be required, don’t hesitate to contact me about that.

逻辑目标和条件

Most conditions that previously required a certain number to be validated, such as ‘having X money’ or ‘having a certain value for a variable’, have been refactored into logic strings. This requires basic knowledge of logic conditions, explained here.

For instance :

# Old configuration
my_condition:
  type: HEROES_SKILL_LEVEL
  skill_name: my_skill
  operation: AT_LEAST
  value: 10
# New configuration
my_condition:
  type: HEROES_SKILL_LEVEL
  skill: my_skill
  logic: '{skill_level} >= 10'

The same thing goes for objects : the ones that previously affected a certain value, such as ‘modifying money’ or ‘modifying veriable’, have been refactored into math expressions strings.

For instance :

# Old configuration
my_object:
  type: SERVER_MONEY_CHANGE
  operation: ADD
  value: 100.0
# New configuration
my_object:
  type: SERVER_LOGIC_MONEY
  value_formula: '{value} + 10'  # taking the current money and adding 10 to  
特例:CONDITIONS条件目标

CONDITIONS目标在新版中被移除了,现根据用法现已被分为了多个其它目标。

a) If it had a fail goto (used as a junction between two objects) :

# Old configuration
my_object:
  type: CONDITIONS
  conditions:
    # ... conditions settings
    goto_if_not_valid: QUEST_FAIL
  goto: OBJECT continue

# New, converted configuration
my_object:
  type: CONDITIONS_SWITCH
  cases:
    a:
      conditions:
        # ... conditions settings
      goto: continue
    # ... there can be other cases
  goto: QUEST_FAIL  # default goto

b) If it had no fail goto (just waiting for the conditions to be valid to continue) :

# Old configuration
my_object:
  type: CONDITIONS
  conditions:
    # ... conditions settings
  goto: OBJECT continue

# New, converted configuration
my_object:
  type: NONE
  progress_conditions:
    # ... conditions settings
  goto: continue

更多设置

Many settings were added and standardized for a bunch of elements. For most quest objects were added cool things like “items_needed” and “position_stay”. For quest pools were added more control settings for each quest and also groups configuration. A clearier actor restriction management. And many settings specific to each element, read more about it on relevant pages.

全局元素

To avoid repetition through configuration, I introduced ‘global variables’ and ‘global conditions’ a bunch of updates ago. I have extended this principle to objects, branches, gui items and time frames. It’s useful if you spend a lot of time copy/pasting the same config parts from one quest to another. Read more about it on this page.

还有更多内容!

There are a bunch of configuration improvements, and also new features I didn’t list above, that are detailed in the documentation.

Including, but not limited to :