Tags
Creators
Details
Licensed MIT
Published 4 years ago
Updated last week
All versions
5.1.0
Release
CrazyVouchers 5.1.0last year 100
Uploaded by
Compatibility
Minecraft: Java Edition
1.21.10
1.21.8
Platforms
Folia
Paper
Purpur
Changes
Changes
- Added a new configuration option
has-argumentto vouchers/codes which was a result of fixing{arg}not being replaced in commands. - Added a new configuration option to the
config.ymlthat allows you to choose whether to allow off-hand usage or not. - Added a new permission
crazyvouchers.bypass.2fawhich lets you bypass 2fa when right-clicking. - Added a new configuration option
override-anti-dupeto vouchers which lets you override the anti dupe option in the config.yml- It defaults to false, which is the default behavior out of the box.
- Added a new configuration option
allow-vouchers-in-item-framesto vouchers, which lets your players place vouchers in item frames if set to true. chance-commandsandrandom-commandshave been combined, They were not working properly anyway. We opted for a weight based system when picking random commands, The lower the number. The less likely the command(s) will be run.- You can specify one command in the list, or multiple. It's up to you!
- If there is no weight option present, It will be considered how
random-commandsfunctioned before, which is run separately and has no relation to the weight based options. - You will need to run
/crazyvouchers migrate -mt VouchersDeprecatedfor the changes to take effect, You will see console nagging regarding outdated configurations until you do.
random-commands:
"1":
# The chance for these to run
weight: 45.0
# The commands to run
commands:
- "eco give {player} 100"
"2":
# The chance for these to run
weight: 25.0
# The commands to run
commands:
- "eco give {player} 1000"
# No chance is provided, thus we will pick random commands.
"6":
# The commands to run
commands:
- "give {player} diamond 5"
Technical Changes
- Cleaned up internals when creating a voucher, or a code.
- This allows us to add newer features easier as it's more readable, and less prone to human error.
{random}:1-10000has been improved, and has better logging when a problem happens i.e. due to invalid numbers being used.- Updated the interaction internals to account for off-hand usage by using PlayerInventory & EquipmentSlots
Bugs Fixed
- Voucher Codes when broken were being put in the wrong list which could lead to confusion when viewing what broke.
{arg}was not being replaced when a command was being run.- We no longer check the name/lore if
{arg}is present which in hindsight was a bad idea. - Please read the Changes for further information on how this works now.
- You can manually add this to your existing configurations that do use the
{arg}variable.
- We no longer check the name/lore if
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:EMORKQjj:HcqfTkzU"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:EMORKQjj:HcqfTkzU"
}

