Suggestions for the plugin

[WhyHaveALife]

Hi, let me explain with greater detail the ideas that I presented to you on dev Bukkit comment page.

1. Gear limit on each tier: Each tier will have an option to spawn only certain gear, such as wooden sword, leather chestplate, and so on. This way, lower tier items will not spawn diamond sword and legendary spawn wooden gears.

1.5 Set damage values for gear: Gear held by mobs should not always be perfect when given back to the players, so I hope there is a way to set damage points for these soon.

1. Drop rate per tier: For every tier that a user creates, he/ she should be able to define how often gear of that type should drop when the mob is killed. For example, I want my legendary armor to drop almost 100% because they show up less, but normal gear to drop less because about 50% will be "normal" weapon
2. Regions: Can define "difficulty" to a region defined through plugins such as WorldEdit and World Guard and spawn higher tier armor or lower tier armor depending on setting. 3.5. Region Types: Dungeon, Road, etc Dungeon could have lootable chest that will be accessible per player(different loot per player (perhaps based on armor equiped)) that will restock every X second. Road could give speed boosts to speed, Towns could make mobs weaker, and decrease chance to drop loot, etc
3. Specifying enchantments Each tier could have option for "Specified enchant" that will always show up on this tier. Swordsmaster tier could always have knockback 2 and sharpness 5 and then X amount more, etc
4. Permission Perhaps in the tier, you could have configuration per permission groups, so you could do the following for loot "chance: groupname1: 10 groupname2: 25" And you would give diablodrops.groupname1 to default players and diablodrops.groupname2 to donators and give them better chance to get loot from chests
5. Decimals in Chance Explained in previous ticket

This is all I can think of at the moment, thank you again for the great plugin

[WhyHaveALife]

I also suggest Global Suffix/ Prefix and Per-Equipment Suffix and Prefix Under a seperate file, you could define something like Helmet: headgear wingedhelmet Diamond_helmet: Shiny_blue_helm Sword: name1 name2 Wood_Sword: name4: name5:

[deathmarine]

Currently defining 6461532 (198_126_37*7) Basic item setups adding just basic unsafe enchantments on top of the names, adds 17513875027110 possible combinations 21^10+21^9+21^8+21^7+21^6+21^5+21^4+21^3+21^2+21^1. In total with randomization a possibility of 113166463931672132520 completely different items. Not including lore. More variables are being added

Honestly defining each parameter can be done, it would take time as well as ruin the randomness above.

1. was already planned on the bukkitdev page. More config.

1.5 Already planned. but not fully fleshed out. Even more config

2 Multiworld is current, but an extensive configuration for regions and worldguard hooks would take time, considering the plugin won't be able to assume what region names are for. Possibly in the future. More config.

3 See above. The idea is to allow custom generated items. I mean we can take all the generation out and allow everyone to create every individual drop via a configuration.

4 Permissions should follow the standard super-perms. Having >2-3 configurations and multiple hooks with so much stored information is going to start weighing on the server figuring everything up on every / specific kill. I really don't want to have to start hooking multiple dependencies before having everything lined out. Or were just going to spend more time bug chasing and lagging. Plugin Description/ Register perms

1. Doubles(Decimals) are possible but would require a huge rewrite and creation of a custom random generator or a span / alogarithm to figure out Integers from Doubles and preform the check based on thousands.

The goal is to be simple, random, and configurable not confusing, but we'll see what we can do. The balance between Resources/Calculation vs Randomness vs Customization/Configurable will be an on going battle.

[WhyHaveALife]

If extensive config will be an issue, could it be a possibility to create a lightweight version (current version) and a extensive version so players can decide what they want to use?

For float values being an issue, you could have a variable in config that is default at 100, and the code use this number instead of 100 as percentage. i.e. if it is changed to 1000 (for decimals such as 0.1) it will use 1000 in your randomization code, so "1" in the "chance" config will actually be 0.1% and 10 be 1%, 100 10%, etc. I haven't seen your code but that would probably be a simple change, or at least simpler than changing everything to float variable from int

[ToppleTheNun]

1. Gear limits on tiers is certainly possible, but has its own issues that will become more and more apparent as the idea is fleshed out and coded. I personally would say to not expect it within the next couple versions, as those are introducing other more pressing features as well as bug fixes. Damage values are also something that can easily be implemented, it'd just take one configuration option and one additional method call. Again, however, it may have repercussions on the rest of the code and I wouldn't expect it within the next couple versions. Drop rates per tiers would have to wait for more tier coding.
2. From my personal experience with MBR, hooking WorldGuard for that would be a huge deal because it's kinda heavy and having to add flags is a nuisance. Creating our own regions would also be impractical for this kind of thing; if we were to add regions it would have to be its own separate subplugin, I believe. We're also still in the point of coding where we're figuring out what our stable code is - we've changed the format of multiple things about five times at this point.
3. That's certainly possible. Like @deathmarine said, though, the purpose is randomness. This point could and would only follow after completing and implementing point 1.
4. I'm personally not in favor of this, as it would require one of two options: using SuperPerms, which is a major issue because we can't define the permissions in the plugin.yml as they will change constantly, and hooking Vault and adding groups support. Adding Vault support will alienate part of the userbase that doesn't use Vault as well as making the plugin more resource intensive. If I had to choose one, I'd choose the second, but I'm personally not in favor of this point unless there's another option that can be uncovered.
5. Decimals in code could be solved by simply switching from a 100 base system to a 1000 base system, a 10000 base system, or a 100000 base system. However, one of the issues that comes with that is end user friendliness. How are we going to explain this to someone who's new to plugin configuration? It'd be much easier to stick with the 100 base system and adding decimals, since that's something that everyone knows. I've got a little bit of experience with random decimals, I could certainly do a little bit of something with that, but it would take much more effort than I believe it would be worth.

In conjunction with point 5, here's an explanation of how our item generation code works. If you have the default configuration file with Legendary, Lore, Magical, Set, Rare, and Unidentified, each with their chances of 3, 7, 15, 10, 20, and 33 respectively, here's how the code actually reads that (and I'm going to translate it to English):

Okay, so we have this list here: Legendary, Lore, Magical, Set, Rare, and Unidentified. Alright, lemme take a look. First up is Legendary. If I roll this 100-sided dice and get a 3 or less, they get a Legendary. rolls dice It's bigger than three. Oh well, onto Lore. If I roll this 100-sided dice and get a 7 or less, they get a Lore. rolls dice It's bigger than seven. Oh well, onto Magical. If I roll this 100-sided dice and get a 15 or less... etc.

Using this system, it's entirely possible to end up without an item at all. If it gets to the end of the list and still has no item type to give you, it will repeat itself up to ten times. In this way, setting a tier to have a chance of one gives it an extremely small chance of being chosen, especially if you put the tier later in your list. If you want to have a tier with a 0.01% chance of being given, simply give it a Chance of 1 and put it near the end of your list. It's extremely unlikely that it will be rolled.

[ToppleTheNun]

Also within my experience, creating two different versions is a great way to mess up any standard code you may have.

EDIT: On a completely different note: @deathmarine: where did you get that number from? That's very impressive.

[ToppleTheNun]

My personal calculations (from the basic configuration):

a = 6 = basic tiers b = 198 = basic prefixes c = 126 = basic suffixes d = 21 = colors (including bold, italics, underline, and magic) e = 46 = different kinds of tools and armors f = 52 = different enchantments g = 10 = levels of enchantments that Minecraft is comfortable displaying

a_b_c_d_e = 141455160 a_b_c_d_e_f = 7519127616 a_b_c_d_e_f*g = 75191276160

That means without enchantments, we have one hundred forty-one million, four hundred fifty-five thousand, one hundred sixty (141,455,160) combinations available from the beginning.

Once you add in the different enchantments (this is assuming that each item can get EVERY enchantment), the number jumps to seven billion, five hundred nineteen million, one hundred twenty-seven thousand, six hundred sixteen (7,519,127,616) combinations available from the beginning.

Finally, once you add in the levels that Minecraft is comfortable showing (yet it can go higher than that), we arrive at seventy-five billion, one hundred ninety-one million, two hundred seventy-six thousand, one hundred sixty(75,191,276,160) combinations from the beginning. The actual number is higher than that, considering that Minecraft can handle enchantment levels higher than 10.

The numbers only increase as tiers, prefixes, and suffixes increase. Let's say that we have a ten tier system with the same amount of prefixes and suffixes. It would end up with 125,318,793,600 individual combinations.

A ten tier system with 225 prefixes and 126 suffixes has 142,407,720,000 combinations.

Suffice to say, it is extremely unlikely that you will ever receive the same item more than once.

[WhyHaveALife]

Thank you for sharing how the code works, I was very interested in knowing how it worked. I know java but I had never worked with a java project so I did not know how things were laid out, and couldn't really figure out what was going on.

So what would happen if it added up to higher than 100? I assume that it will just be like normal

One last thing, would it be possible to make chests that spawn random loot?

And thank you to both of you for your thoughts, I will perhaps make another topic once I get new ideas.

[ToppleTheNun]

If all of the chances add up to more than 100, it will make no difference in how the code runs.

There's a new feature called Ruins in the new code that makes random chests appear. It still needs some tweaking, but it should be some good fun.

[deathmarine]

Damn I forgot colors but more than one enchantment can be added to each item making 21^10 with a max of ten but yet can have less then 21 enchantments with 10 levels. Never less when we get to a major release it will be epic and configurable.

[ToppleTheNun]

I actually did more calculations with the idea that you can have more than one enchantment, and with a ten tier system with 250 prefixes and 250 suffixes, the amount of possible combinations is over 16 trillion.

[deathmarine]

Either way random is the way to go.

[ToppleTheNun]

Indeed.

[deathmarine]

1. is done. 1.5. made random with config. 1?again is done.
2. Regions are not coming any time soon. 3.5 Will be another plugin 3.Your tier config already includes each individual material. We made enchantments safe, so nah...
3. Nope.
4. Unnecessary. 1 out of a 100 normally spawned entities that spawn to a limit of about 100 per world with a default chance per item. Adding anymore randomization would be counter productive.