Improved Item Descriptions

Lilbren2u

Member
I would have a recommendation for Item Descriptions, which would essentially permit the following to take place.

Item Name: &fCharm of &6Tarik
Lore Line 1: &e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝
Lore Line 2:
&fThis is a pendant made of a metal chain, at its
Lore Line 3:
&fend lies &6a gilded sun&f, in all of its blazing
Lore Line 4:
&fglory.
Lore Line 5: &e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝&3∞&6✵&3∞&e↜↭↝

1655850206648.png


Currently, you're only really able to colour the Item Name all nice. But aren't able to make very pretty descriptions like this short example.

I'll show a bunch of other dividers for examples. Dividers are beautiful.

1655850481798.png
 
What I don't really like though is putting stylistic dividers as text in the item description message. A description should just be readable text, coloured or not. How would you like to use to dividers? Would they always be at the top and bottom, or in arbitrary places? Plain text dividers like this run into trouble when the amount of text columns is implementation-specific, causing them to potentially wrap around onto the next line which is very ugly.
 
If i may add - simplistic/line dividers are also a thing, such as the examples I'll post.
dividers are good to.. well, divide. from description, divider, mechanics, divider, and then who made it - it depends on who's writing the item. I like using dividers in text to separate mechanics (if any) and the flavourful text.

1655887218486.png

1655887226920.png

1655887294371.png

These utilize hexcodes, as you can see by the variations in colour. Hexcodes are great :)
 
Last edited:
What I don't really like though is putting stylistic dividers as text in the item description message. A description should just be readable text, coloured or not. How would you like to use to dividers? Would they always be at the top and bottom, or in arbitrary places? Plain text dividers like this run into trouble when the amount of text columns is implementation-specific, causing them to potentially wrap around onto the next line which is very ugly.
I've worked with the dividers with the current item editing plugin, and have managed to keep the dividers on their specific lines - without the ugly wrapping.

As shown by Kale's example above, the dividers would be placed where there's breaks in the item descriptions. Peoples' styles vary greatly, however these dividers and coloured texts have really done wonders to allow for pretty item descriptions to be created.
 
I've worked with the dividers with the current item editing plugin, and have managed to keep the dividers on their specific lines - without the ugly wrapping.
The problems with this only start as soon as we want to display item descriptions in different ways. I admit it's a bit of a software developer tick, but we generally don't like to mix data with representation, hence my hesitation.
The problem is that the descriptions are already being abused in this manner. When we wish to re-use these item descriptions and present them in a different way somewhere else now, we would have to write a filter mechanism that detects and removes such dividers which may not be compatible with an alternative form of presentation. That is a big headache problem. Colours are different because they are distinct and easily filterable.
 
The problems with this only start as soon as we want to display item descriptions in different ways. I admit it's a bit of a software developer tick, but we generally don't like to mix data with representation, hence my hesitation.
The problem is that the descriptions are already being abused in this manner. When we wish to re-use these item descriptions and present them in a different way somewhere else now, we would have to write a filter mechanism that detects and removes such dividers which may not be compatible with an alternative form of presentation. That is a big headache problem. Colours are different because they are distinct and easily filterable.
Fixable - the idea is to store the data in the item somewhere, as well as extra data describing the chosen separators by constants;
The display can be generated at runtime only once when the edited item is finished being edited. The data gets stored separately.
The cost of this is slightly more space usage per each item, but the benefits may be quite flavorful.

Example storage format (excluding Display Name which can be stored as is with setDisplayName):
Code:
separator=SOME_SEPARATOR_ENUM;gradient=#aaabbb-#cccddd;rarity=UNCOMMON_ENUM;lore=Lorem ipsum dolor sit amet, consectetur adipscit elit.
Edit: see 1.18's new Metadata system for applying hidden custom data to an item without NMS.
 
Fixable - the idea is to store the data in the item somewhere, as well as extra data describing the chosen separators by constants;
The display can be generated at runtime only once when the edited item is finished being edited. The data gets stored separately.
The cost of this is slightly more space usage per each item, but the benefits may be quite flavorful.

Example storage format (excluding Display Name which can be stored as is with setDisplayName):
Code:
separator=SOME_SEPARATOR_ENUM;gradient=#aaabbb-#cccddd;rarity=UNCOMMON_ENUM;lore=Lorem ipsum dolor sit amet, consectetur adipscit elit.
Edit: see 1.18's new Metadata system for applying hidden custom data to an item without NMS.
Yes this is more less the direction I'm thinking, but the dividers will have to be defineable by the players themselves so they keep their artistic freedom. I think the challenge is doing this without making it cumbersome, because if it is cumbersome players will not use it and just paste the dividers as they are doing right now.
 
Yes this is more less the direction I'm thinking, but the dividers will have to be defineable by the players themselves so they keep their artistic freedom. I think the challenge is doing this without making it cumbersome, because if it is cumbersome players will not use it and just paste the dividers as they are doing right now.
Store the separator directly, escaped if you wish, instead of the Enum then.
The system can be intuitive.

Consider this design:
All items come with some sensible separator and color defaults. (simple line separator, and &7 lore text color)
When editing an item, the player may click on a button called "Advanced Styles", which prompts them with another menu.
This menu would contain a button for separators, which once clicked will ask in chat for a 32-long separator (ignoring color codes, otherwise max is 255), similar to editing an item's display name.
It would also contain a button for Lore Text Color, which will let the user input up to two Vanilla and/or Hex colors with the format &a, or #aaabbb, or &a-&b, or &a-#ffffff, or #aaaaaa-#bbbbbb. Single colors mean no gradient, whereas line (-) separated ones imply a gradient. If two colors are added, the system will generate a list of hex colors to be applied per line such that it approximates the gradient which the user described.

Edit: interpolation algorithm:
Code:
R = firstCol.R * p + secondCol.R * (1 - p)
 
Last edited:
Store the separator directly, escaped if you wish, instead of the Enum then.
The system can be intuitive.

Consider this design:
All items come with some sensible separator and color defaults. (simple line separator, and &7 lore text color)
When editing an item, the player may click on a button called "Advanced Styles", which prompts them with another menu.
This menu would contain a button for separators, which once clicked will ask in chat for a 32-long separator (ignoring color codes, otherwise max is 255), similar to editing an item's display name.
It would also contain a button for Lore Text Color, which will let the user input up to two Vanilla and/or Hex colors with the format &a, or #aaabbb, or &a-&b, or &a-#ffffff, or #aaaaaa-#bbbbbb. Single colors mean no gradient, whereas line (-) separated ones imply a gradient. If two colors are added, the system will generate a list of hex colors to be applied per line such that it approximates the gradient which the user described.

Edit: interpolation algorithm:
Code:
R = firstCol.R * p + secondCol.R * (1 - p)
That's pretty much what I'm thinking about yes. I think the default separator is your key point here, because it will 'force' players to use the separator mechanism, as when they would just type the separator as part of the message body, they will end up with duplicate separators and they will avoid that.
Implementation details about colour gradient algorithms are really beyond the scope of this discussion.

I do wonder whether we should just allow arbitrary styling within the message body itself instead of one colour or gradient for the whole description. Some players might like to use that to add emphasis to certain parts.
 
Back
Top