QuickShop-Hikari

New Features

• New option shop.async-owner-name-fetch has been added into configuration.

  #[BETA] Should we async fetch the owner name?
  #If you enable this option, the calls for ContainerShop#ownerName will return the cached result.
  #If the request out of cache, QuickShop-Hikari will allow up to 20 ms for sync fetch username.
  #Then it will turn to background and return "N/A" this time.
  #This may cause some display problems (e.g. the info sign will show that the shop owner is N/A)
  #But once the cache is completed for fetching in the background, the next request will return the correct username
  #This is very useful for large servers, because sometimes players may accidentally load a large number of long ago shops, resulting in a large number of main route IO requests for username queries and causing a spike in lagging
  async-owner-name-fetch: false

Optimize

• Improved parallel player username <-> uuid query workflow, reduced unnecessary Bukkit OfflinePlayer API requests (which it really slow)
• Pre-fill username lookup cache with server's usercache.json to boost initialization cache for improve the cache hit rate
• Added EssentialsX data sources, now QuickShop will also use EssentialsX's data for mapping query (still, in parallel)
• Move /qs staff uuidquery tasks from server thread to standalone async thread to avoid tps loss
• Move /qs unlimited uuid query tasks from server thread to standalone async thread to avoid tps loss
• Move /qs benefit uuid query tasks from server thread to standalone async thread to avoid tps loss
• Move /qs staff uuid query tasks from server thread to standalone async thread to avoid tps loss
• Move /qs transfer uuid query tasks from server thread to standalone async thread to avoid tps loss
• Move /qs permission uuid query tasks from server thread to standalone async thread to avoid tps loss
• Move MsgUtil msg sending functions username query tasks from server thread to standalone async thread to avoid tps loss