- Joined
- Jul 17, 2013
- Messages
- 544
how about giving it a name? instead just another warcraft iii map
-
Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
-
Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.
-
🏆 HD Modeling Contest #7 POLL is live! ✅ Vote for the TOP 3 MODELS! ❗️Poll closes April 28, 2025. 🎬Watch the entries on our YouTube channel! 🔗 Click here to cast your vote!
Simple Item Drop System for Percentages
- Author(s)
- CarlosCepinha
- Tags
- System, No Target, GUI / Triggers
- Size
- 38.72 KB
- Rating
- Downloads
- 272
- Created
- Apr 17, 2020
- Updated
- Apr 19, 2020
- Resources
- 1
- State
Awaiting update
This bundle is marked as awaiting update. A staff member has requested changes to it before it can be approved.
First time submitting. I hope this gets reviewed just in case I missed anything.
I've tried to make it GUI, MUI, Leakless.
Just copy the folder and make sure all variables are declared.
Drop system for GUI users where you create an Array for the items dropped and a second Array for how much chance(percentage) of each item has to drop.
After setting these, you just choose wich Arrays to use when applying the drop.
Example Percentages:
Mana Potion - 10% (writen as 1,0)
Health Potion - 5% (writen as 0,5)
Orb of Frost - 1% (writen as 0,1)
Min chance - 0,1% (writen as 0,01)
Max chance - 100,0% (writen as 10,00)
And the system will make the maths (instead of repeating them every time for each unit).
You can apply the same Arrays to many units or create new Arrays for each new unit.
There is also an extra variable in the begginning that lets you change the "dificulty" of the drop, meaning: that variable can be used to reduce all chances overall.
This was the simplest version I've been able to came up with, doesn't require use of hashtables and item ID's wich can be a bit more advanced to newer users.
I've tried to make it GUI, MUI, Leakless.
Just copy the folder and make sure all variables are declared.
Drop system for GUI users where you create an Array for the items dropped and a second Array for how much chance(percentage) of each item has to drop.
After setting these, you just choose wich Arrays to use when applying the drop.
Example Percentages:
Mana Potion - 10% (writen as 1,0)
Health Potion - 5% (writen as 0,5)
Orb of Frost - 1% (writen as 0,1)
Min chance - 0,1% (writen as 0,01)
Max chance - 100,0% (writen as 10,00)
And the system will make the maths (instead of repeating them every time for each unit).
You can apply the same Arrays to many units or create new Arrays for each new unit.
There is also an extra variable in the begginning that lets you change the "dificulty" of the drop, meaning: that variable can be used to reduce all chances overall.
This was the simplest version I've been able to came up with, doesn't require use of hashtables and item ID's wich can be a bit more advanced to newer users.
Contents
Reviews
- Joined
- Mar 1, 2020
- Messages
- 22
Is this drop item system?
Edit: Oh, so... It useful for RPG map. I like It
Edit: Oh, so... It useful for RPG map. I like It
Last edited:
- Joined
- Mar 1, 2018
- Messages
- 41
Sorry I didn't notice. Yes it's a drop system for GUI users where you create an Array for the items dropped and a second Array for how much chance(percentage) of each item has to drop.
After setting these, you just choose wich Arrays to use when applying the drop.
After setting these, you just choose wich Arrays to use when applying the drop.
- Joined
- Jul 17, 2013
- Messages
- 544
it would be intresting if there was an option to set max limit of items that can drop. just to prevent too much items.
Spell Reviewer
- Joined
- Aug 27, 2013
- Messages
- 4,214
Please follow GPAG - GUI Proper Application Guide for prefix and variable naming to ensure a much cleaner and readable triggers.
I'm not sure what's the purpose of indexing the dying units in your system as I see no reason for it. If you are afraid the system overwrites the value of dying unit, you don't have to worry, because it does not. This is proven by the fact that you can use dying unit with waits. But if you want a safer and slightly more efficient option, simply use triggering unit instead. Still no reason to index them, though.
Also, "DROPing_UnitIndex" will always start from 2 when it has reached a value greater than 70. This is due to how you place "DROPing_UnitINDEX = (DROPing_UnitINDEX + 1)", simply place it in else block instead. But you don't need to use indexing in the first place anyway because of the point I explained previously.
You don't need to null global variable. It is only necessary for locals.
Your system looks more like a template to me. I will not deny its usefulness, however, it is a bit too simple from coding perspective and not user-friendly enough to use from end-user standpoint because they still need to copy/paste the code and change some values for every new table they create. This can also get expensive if they create a lot of tables, because longer code in GUI can cause lag in the editor, I imagine it will be a nightmare to change the necessary values at that point.
A good system is a system that allows the user to not worry about how things work in the background (they don't even need to know how it works) but still allows them to change some values from the foreground aka the config trigger. Most of the things here are done manually by the user except the math, you can instead use a Hashtable to automate the process.
In summary, remove the indexing because it has no use. Use triggering unit instead of dying unit for a safer and slightly more efficient option. No need to null global variable. Follow the GPAG to ensure a much cleaner and readable triggers. Create a more in-depth documentation on how to use your system (Not everyone is a GUI user). Consider using Hashtable to automate the process so user doesn't have to copy/paste code and change the value more than they have to, this however is optional.
Resource is set to
Awaiting Update
I'm not sure what's the purpose of indexing the dying units in your system as I see no reason for it. If you are afraid the system overwrites the value of dying unit, you don't have to worry, because it does not. This is proven by the fact that you can use dying unit with waits. But if you want a safer and slightly more efficient option, simply use triggering unit instead. Still no reason to index them, though.
Also, "DROPing_UnitIndex" will always start from 2 when it has reached a value greater than 70. This is due to how you place "DROPing_UnitINDEX = (DROPing_UnitINDEX + 1)", simply place it in else block instead. But you don't need to use indexing in the first place anyway because of the point I explained previously.
You don't need to null global variable. It is only necessary for locals.
Your system looks more like a template to me. I will not deny its usefulness, however, it is a bit too simple from coding perspective and not user-friendly enough to use from end-user standpoint because they still need to copy/paste the code and change some values for every new table they create. This can also get expensive if they create a lot of tables, because longer code in GUI can cause lag in the editor, I imagine it will be a nightmare to change the necessary values at that point.
A good system is a system that allows the user to not worry about how things work in the background (they don't even need to know how it works) but still allows them to change some values from the foreground aka the config trigger. Most of the things here are done manually by the user except the math, you can instead use a Hashtable to automate the process.
In summary, remove the indexing because it has no use. Use triggering unit instead of dying unit for a safer and slightly more efficient option. No need to null global variable. Follow the GPAG to ensure a much cleaner and readable triggers. Create a more in-depth documentation on how to use your system (Not everyone is a GUI user). Consider using Hashtable to automate the process so user doesn't have to copy/paste code and change the value more than they have to, this however is optional.
Resource is set to
Awaiting Update
