Im having a problem with Essentials kits. I have made many kits that have many enchants. The problem is... essentials is adding its own enchants. example: - 278 1 efficiency:5 unbreaking:5 fortune:5 name:&9{USERNAME}&9's_God_Pickaxe lore:{DATE} . THis works fine but when i receive the kit it has sweeping edge... and so do all my kit items for that matter.

god:
    delay: 2678400
    items:
      - 310 1 protection:5 unbreaking:5 protection_fire:5 name:&9{USERNAME}&9's_God_Helmet lore:{DATE}
      - 311 1 protection:5 unbreaking:5 protection_fire:5 name:&9{USERNAME}&9's_God_Chestplate lore:{DATE}
      - 312 1 protection:5 unbreaking:5 protection_fire:5 name:&9{USERNAME}&9's_God_Leggings lore:{DATE}
      - 313 1 protection:5 unbreaking:5 protection_fire:5 name:&9{USERNAME}&9's_God_Boots lore:{DATE}
      - 276 1 sharpness:5 unbreaking:5 fire_aspect:2 knockback:5 looting:5 name:&9{USERNAME}&9's_God_Sword lore:{DATE}
      - 278 1 efficiency:5 unbreaking:5 fortune:5 name:&9{USERNAME}&9's_God_Pickaxe lore:{DATE}
      - 277 1 efficiency:5 unbreaking:5 fortune:5 name:&9{USERNAME}&9's_God_Shovel lore:{DATE}
      - 279 1 sharpness:5 unbreaking:5 fire_aspect:2 name:&9{USERNAME}&9's_God_Axe lore:{DATE}
      - 56 32
      - 60 1
      - 322:1 16

so i figured out that {WORLDDATE} is the server date. and when {DATE} is applied it adds sweeping edge... plz help

Confirming:
{DATE} is definitely the problem; I believe it has something to do with today being the 22nd. Sweeping Edge's enchantment ID is 22. It seems like the lore doesn't group the replacement of the variable up to where it can be parsed as an entire String. Seems like there needs to special cases for placeholder Strings like that.
Essentials b547
MC/Spigot 1.12.2

any suggestions? cause i agree this may be the problem. the enchant does change depending on the day
ah sorry

https://gist.github.com/Stoniasawsome/4b2b1b87f7cd34a87e9da804c4ff917a

This is awesome! Will report back soon with a fix.

@Stoniasawsome I'm pretty sure that this issue will have to be fixed in the code, as it's a formatting/reading issue that has to do with the format of the {DATE} tag.

Weirdly enough, I'm unable to reproduce this issue. Can you https://gist.github.com your entire config.yml please?

EDIT: Do you know what your server locale is? If not, which part of Earth is the server running?

i did, did i do it wrong?

https://gist.github.com/Stoniasawsome/4b2b1b87f7cd34a87e9da804c4ff917a

sorry the server is based from ashburn nc
and i dont know what my server locale is, i hve seen it tho i think

This has been fixed in 5fa2ce7. You can grab the fix from build 554 on the CI server.

The Problem

It would seem the OP and others are using locale en_US, which formats datestamps in US format.

In brief: {DATE} was being transformed into Dec 22 2017

EssentialsX is set to parse individual tokens. These tokens are like words, separated by whitespaces. In the case of
- 310 1 protection:5 unbreaking:5 protection_fire:5 name:&9{USERNAME}&9's_God_Helmet lore:{DATE}

It was being passed to the item parser (MetaItemStack) as
- 310 1 protection:5 unbreaking:5 protection_fire:5 name:&9{USERNAME}&9's_God_Helmet lore:Dec 22 2017

The lore becomes Dec, then the parser reads the numbers 22 and 2017. In this case it consumes 22 and tries all possibilities coming down to a search for enchantment by numeric id, which SWEEPING_EDGE's id is 22. When no level is specified it defaults to the maximum enchantment level.

Finally 2017 reaches enchantment parser lastly which doesn't do anything since it can't find an enchantment with numeric id 2017.

The fix

All text after lore will now be parsed as the lore itself. To prevent this from happening, ensure any item data is placed before the lore definition.

All though it is a breaking change, I believe it to be common practice for most admins to have the lore at the end of the item definition anyways.

Cool!

im sorry im really slow, like really slow, how do i get the fix? :D

As per the first line of my response. You download the jar from the CI server here https://ci.ender.zone/job/EssentialsX/

EDIT: Oops, Fixed CI link.

It seems @SupaHam is being forgetful today, the CI server is https://ci.ender.zone/job/EssentialsX/

thank you sir!

Removed debug message, please download build 555.

10/10 would ThupaHam again

• What server version are you running? /version
• What EssentialsX version are you running? /essentials
• Please paste your config on Gist.

i have found my problem, i am using 1.12.1 RO-1 server with essentialsx 2.0.1-b531. Through process of elimination i found The problem is the {DATE} placeholder. I switched it to {WORLDDATE} and it solved my problem. i think {DATE} may need a fix.

wouldn't this problem then occur if someone were to use {Date} in another field such as "name" with us-EN on?

@L3thalBunny Correct. Will need to consider that case soon.

@SupaHam I reckon that it'd be better to just enclose fields in quotation marks and replace double apostrophes ('') with double quotes? I haven't looked at how it's handled, but it seems like it'd work?