Replies: 18 comments 1 reply
-
Hello @bundabrg, @Wolf2323 and me looked over the suggestions and this is what we came up with:
|
Beta Was this translation helpful? Give feedback.
-
Remember that the database also needs to be updated so that items inside the backpack are stored as deserialized Item Stacks. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the comments and suggestions. DB is something I forgot about but it makes sense it should support the most generic format as @joblo2213 has mentioned. That'll need to be performed in the ConfigUpdater. For backwards compatibility I still think having a simple provider is easy enough for not much work, with the idea being that it is likely to be less used by default if its not as useful especially if no-one updates the provider. Perhaps a (assuming separate file per itemstack so no need for itemname) item_stack:
==: org.bukkit.inventory.ItemStack
v: <data version> # determines item data conversions; TODO: documentation of the available versions?
type: <item type name>
...
ignore-while-matching:
- meta.lore
- amount
- meta.attribute-modifiers.uuid
otherlocalkey: blah I do agree that having serialized itemstacks as default is a good idea as it doesn't really break backwards compatiblity and will encourage its use. Per-file items sounds like a good idea (MUCH easier to search) for serialized itemstacks as well. The nice thing about being able to use multiple item providers is that any ideas can of course be written into a new provider or extend an existing one should it be useful as well and each provider can be concentrated on independently of the others to add features. I also anticipate some additional compatibility item providers. For example there is a lot of data hidden in long hex strings in the serialized stacks that are used by some plugins. I believe Magic with wands uses NMS data which gets hidden here and having it in a simpler format for users to use would be useful (or even provided by the plugins itself entirely without reinventing the wheel) API-wise I suspect this will be a breaking change since QuestItem is pretty integral to many API's and is inherited by lots of stuff. This will require poring over QuestItem to see how breaking it could be though its possible much of this can be hidden without needing to change the API itself. |
Beta Was this translation helpful? Give feedback.
-
Ok guys @Wolf2323 and me have reached a critical point while discussion where we have multiple options regarding security and identification methods. Are you up to a live discussion via discord? |
Beta Was this translation helpful? Give feedback.
-
If you can please paste any discussions here once done (if its text based) just so it can be tracked in the issue as well that would be great. |
Beta Was this translation helpful? Give feedback.
-
How about a flag to block possible "interaction" with a questitem OR to force it into the Quest Inventory all the time. I think you get what I mean. |
Beta Was this translation helpful? Give feedback.
-
Hello guys, @Wolf2323 and I had a long discussion again where we came up with a somewhat final / complete system. This system has almost no similarities with the old one. Please forget what the former "Quest Item" is: We will refer to server owners as "creators". This explanation is a first version of a to-be-created wiki page "Items": Quest items are predefined items that can be given to players with events. They can fulfill numerous use cases such as:
Safe an Item
How to use 3th party item providersItem providers allow BetonQuest to obtain items from a 3th party source. An example of that would be a RPG item plugin where player specific values might be included in the NBT data of the item. To prevent saving these together with all the other item information you can specify 3th party providers in the /q item save command. Example: The vanilla argument:When you add the argument "vanilla" to the /q item create command the item wont have a UUID or a timestamp (check the corresponding sections to understand these systems). This means that these items can be stacked with vanilla items again and have no flags and so on of BQ. Variables in itemsYou can use variables in every part of the serialized item. This allows for translation Item Flags
More item flags could be possible, at the moment we think this these are enough. It is also possible to make a seperate plugin that adds much more flags to the items. Configuring FlagsTo manage these group flags there is a new global config called "flags.yml" that looks something like this:
Notice that a group flag can also contain another group flag. That's why we call all the content in a group-flag child-flags. Applying FlagsIf we now want to apply a flag or a group-flag onto an item we use this command: If we wanted to add special behaviours onto an already existing quest item called "GoldenRing" we would run the command "/q item flag add LotR.GoldenRing quest-item". This will add our special behaviour and some additional information in the items lore.
If you wanted to also display that this specific item cant be dropped but you dont want to change the group flag because you have applied it elsewhere you can override that shown=false setting (its actually not given in that config above which means it must be hidden) by adding show=true in the items flag option like this:
You can also override all other flag options using this. //Concept Updating Items
To properly update each item BQ has to check the players inventory for items that contain a UUID upon joining. This also happens when opening the backpack, taking an item out of a chest, trapped chest, enderchest, chest minecraft, furnace minecart, hopper minecraft, hopper dropper, dispenser, picking a book up from a lecture. As long as the UNIX timestamp in the config is not updated the corresponding item will never be updated. Please don't change the timestamp yourself, use the command! Removing items that are already in players handsIt is possible to remove an item that is already in the game by setting the item to air. When you run the update command afterwards all versions of that item that exist in your server will be replaced with air (which is an empty inventory slot). Deleting an item
@Wolf2323 and @SaltyAimbOtter would like to implement this in the plugin because we spend tons of time writing this specification (it was rewritten multiple times). We also have wrapped our heads around a lot of very special cases and problems this system has. There are more aspects that we thought of that are not in this specification because it would be too huge. We might add them after this is done in a separate PR. Refferences to other isues:
|
Beta Was this translation helpful? Give feedback.
-
Maybe add some "flag groups" that represent common flags like the current "quest item". In order to group common flags in one command. (specially for newbies) Either as flag or just probably better: a "flag" that just exists as command, which adds the common flags. |
Beta Was this translation helpful? Give feedback.
-
A read through looks pretty good so far. Main question is how to implement the flags on the created items since I assume they will need to exist on the item itself either as part of its description using special flags or stored as NMS tags? Or would BQ be tracking the items itself? Edit: Man I must be tired. I see you already cover that by tagging the description. |
Beta Was this translation helpful? Give feedback.
-
@KingJulian13 If you want a flag that add flaggs, then simply crate a new group flag in the config and add the group flag with the command above. @bundabrg |
Beta Was this translation helpful? Give feedback.
-
I think the concept is ready for the implementation. But i also think it would be easier to wait, until the Config rework is done, because it contains new features, that would allow to easier load folders that contains the items.yml's. So Depending on: #995 |
Beta Was this translation helpful? Give feedback.
-
This rework should remove the |
Beta Was this translation helpful? Give feedback.
-
It would be nice if items could be grouped together using config sections. This would then randomly pick one item from the list. |
Beta Was this translation helpful? Give feedback.
-
Changing some item values with event (durabilty, lore, title) could be really usefull. |
Beta Was this translation helpful? Give feedback.
-
Multiple Item Providers: Vanilla ProviderE.g. Simple ProviderE.g. Serialized ProviderE.g. |
Beta Was this translation helpful? Give feedback.
-
Giving a Quest Item goes directly to Backpack (flag and/or config option) Current Problem: |
Beta Was this translation helpful? Give feedback.
-
There is a new usecase |
Beta Was this translation helpful? Give feedback.
-
Overview
This is a catch-all issue to address items in BQ 1.12+. I'll go through an link older issues to this one to help track. Please do comment if you have any thoughts/ideas or if this is a horrible idea as this is planning and feasibility stage.
Currently items are defined in
items.yml
and are fairly simple to setup either manually or by using the/bq item
command.The main issues are:
items.yml
is used both for defining fully an item (for example thegive
event) as well as for matching an item (for example in theitem
condition) which may contain an incomplete definition or even wildcardsIt would be handy to some format that provides the most generic way possible of handling Items whilst still allowing plugins to use more short-hand techniques to make it easier. This way you get the best of all worlds by being able to define items in a simpler fashion for plugins (IE, MMOItems could read a mmoitem.yml file that has fields specific to it in an easier format, or bossshop could provide items from its own plugin definitions) whilst still being able to save or generate items that are not internally supported.
This means that BQ should have an Item Provider plugin system that provides the ability to lookup an item in the same manner as currently, but behind the scenes those providers may use differing methods to define an item (it could be from a database, from a yml file, by querying another plugin etc). The Item Provider will allow both a 'match' as well as being able to provide a full definition for an item.
An ItemProvider can also be extended by 3rd parties in the same way ConversationIO, Events, Conditions etc can.
Example
For example, lets say we have the following event:
When executed BQ will attempt to look up the item in the 'mypackage' package called 'cash'.
BQ could have 2 default ItemProviders called
simple
andserialized
. It would ask each one in turn for the 'cash' item in the package and return a result from the first successful one.Sample Item Providers
Simple
The
simple
provider will work the same was as current. It will lookup the item in anitems.yml
file in the package folder. This will also provide backwards compatibility.Serialized
The
serialized
provider will make use of the Spigot item serializer which provides items in a much more verbose format as follows:This could be in a file
items-serialized.yml
in the package folder.Changes
/bq item
would need to be updated to define which provider you wish to save the item with, with the default beingsimple
if not specified.What an ItemProvider needs to provider
save
- Given a real item, generate a definition (used by /bq item for example)create
- Create a real itemmatch
- Given a real item, try to match a definitionBeta Was this translation helpful? Give feedback.
All reactions