QuickShop-Hikari

Artist: Ghost_chu - Server group photo

Another regular update for QuickShop-Hikari! In this update we've made a special update to privacy protection, increasing user control over data collection and sending. In addition to this, we have fixed several bugs, optimized performance, and brought some extended feature updates.

The Minecraft 1.20.2 is coming soon, and we'll be adapting the new version as soon as it's released, so we'll see you again in 1.20.2! (If there are no new bugs that need to be fixed urgently ;))

New Features

• Privacy Controller
  • We've always taken our users' privacy seriously, and in 5.1.0.0 we've added a brand new privacy management tool.
  • The privacy controller and reviews all privacy related requests, like paste, bStats, rollbar error tracker.
  • This tool provides an efficient switch for data processing within QuickShop-Hikari, allowing the management of data processing for the entire assortment or for individual modules.
  • You can review the audit log in /quickshop paste report.
  • The goal of this tool is not GDPR compliance, but we also don't deal with non-anonymized processing; the data transferred to bStats, Rollbar etc. is all anonymized; the tool primarily allows users to opt-out of some outgoing data. This provides an option other than disabling the entire bStats or error handler.
  • Our goal is to plug as many modules that will execute external data transfer into this controller as possible and provide a command that allows you to quickly disable, enable them, these missing pieces will be added gradually in future versions.
• [COMPACT] AngelChest Compatibility Module.
  • This module can disallow users create shop on a AngenChest and prevent AngelChest being deleted when executing Protection Checking.
• [COMPACT] ChestProtect Compatibility Module.
  • This module can disallow users create shop on a container that proteced by ChestProtect, and prevent protect removing by executing Protection Checking.

Reworks

• Rewrited shop cache system
  • The new Shop Lookup Cache module improves code maintainability so that we can apply it to more places in future releases.
  • After the rewrite, the cache hit statistics for this module now reflect the real data.
  • Reduced cache size, too large a size reduces cache lookup performance and leads to wasted memory usage.

Optimizes

• Improved performance of out-of-cache shop lookups, and chunk loading is now no longer performed in non-necessary cases.

Changes

• Added and default enabled option that cancel the fake Protection Checking Event (BlockBreakEvent) before pass to MONITOR listeners.
  • This can alleviate conflicts or error logging with some plugins.
• Updated TNE-API to TNE-Recode (0.1.2.2-Pre-1), this should fix an incompatibility issue that arose with newer versions of TNE. (contributed by @creatorfromhell )
• [ADDON] Improved BlueMap addon. (contributed by @ItsJuls )

Bug Fixes

• Fixed shop.blacklist-lores setting doesn't work at all.
  • The code implementation of this feature was accidentally removed in an earlier updates.
  • We rewrote the code for the relevant functions and the new check will ignore color and style symbols in lores.
• Fixed minor CSS issue in generated paste.
• [ADDON] Fixed DiscordSRV json message template parsing issue, now load the JSON message template from the language file with the correct mapping name.

API Changes

• Added ShopManager#getShopsViaCache and ShopManager#getShopsIncludeAttachedViaCache interfaces.
• Deleted ShopCache class cause it was replaced by new ShopCaching system.

Privacy Changes

• We've added a new bStats data collection (similar to QuickShop-Reremake) Here's a list of all the new collection items, you can opt out of them at any time using the new PrivacyController.
• In order to comply with our privacy transparency requirements, we explain the uses of the metrics we collect in more detail below.
  • Collecting the all QuickShop-Hikari's addons/compactibility module's name that installed on your server.
    • We use this metric to understand the popularity of extensions among the user community and consider merging popular expansions into the core. We also use this metric to discover new third-party modules.
  • Collecting the QuickShop-Hikari's feature status of allow-stacks
    • We use this metric to understand the popularity of this feature and decide if we should put it default enabled in default configuration.
  • Collecting the QuickShop-Hikari's feature status of protection-checker-listener-blacklist
    • We use this metric to understand most popular blacklist settings across our users, this allows us to work with its authors to improve compatibility.
  • Collecting the QuickShop-Hikari's command alias.
    • We use this metric to understand most popular/most disabled command alias of quickshop, then we will consider put them into/remove them from default alias list.
  • Collecting the QuickShop-Hikari's database type you're using.
    • We use this metric to understand most popular database type, and targeted to improve its query, insert and modify performance.
  • Collecting the QuickShop-Hikari's database version.
    • We use this metric as a reference so that we don't drop support for older but popular database versions.
  • Collecting the QuickShop-Hikari's database vendor.
    • We use this metric to know the name of the specific database vendor that the user is using so that we can use an optimized JDBC driver for the specific database vendor, such as MariaDB or OceanBase.
  • Collecting the QuickShop-Hikari's economy bridge type that user using.
    • We use this metric to understand the types of economic bridging plugins used by our users so that we can improve the corresponding economic bridging plugin transaction processing and transactional performance, and optimize performance using asynchrony and callbacks where supported.
  • Collecting QuickShop-Hikari's item matcher type that user using.
    • We use this metric to check the popularity between different ItemMatchers in order to improve them. It also helps us understand the popularity of some of the ItemMatcher implementations that are known to be problematic in order to decide if we should write mitigations.
  • Collecting QuickShop-Hikari's display type that user using.
    • We use this metric to check the popularity of different DisplayImpl's across servers so that we can decide whether to optimize them or maintain the status quo. It also helps us to see if the popularity of the faster VirtualDisplayItem has suffered due to the demand for ProtocolLib.
  • Collecting QuickShop-Hikari's total shops amount on your server.
    • This metric ends up on bStats as a total of all stores on all servers. This metric helps us average the size of the number of server stores in order to decide whether to optimize lookup or cache performance, or whether we should not over-optimize. When this value rises for a period of time, we may initiate a performance optimization topic update program within Discord so that we can look for potential operational performance issues.
  • Collecting QuickShop-Hikari's background debug logger switch status.
    • We use this metric as a reference to get a rough idea of whether a large number of users are being affected by the unknown performance degradation of DebugLogger and to improve its performance if needed, which seems to be good, at least for now.
  • Other metrics collected by bStats it self.
    • Just like other plugins and your server software, here is some basic metrics data collected by bStats and we can't control them. To out-put from them, go to /plugins/bStats/config.yml to disable bStats.