Simple Item Durability System v1.1 [GUI]

[Moderator]

07:42, 17th Aug 2012
Magtheridon96:

Approved.

You should add a disclaimer.
Users should not give durability to items with charges. (Nevermind)
Actually, you can make the charges optional with a configurable boolean.

Old crap

-

Code

• Custom script: set bj_wantDestroyGroup = true
• Unit Group - Pick every unit in (Units in (Playable map area) matching (((Matching unit) is A Hero) Equal to True)) and do (Actions)
  • Loop - Actions
    • Unit Group - Add (Picked unit) to ID_Group
    • Trigger - Add to ID Takes Damage <gen> the event (Unit - (Picked unit) Takes damage)

Since you're using Bribe's DamageEngine, this is totally not needed
Just get rid of that code, and everything'll run fine.

Old Rant

Okay, this is a really nice system, and the configuration is excellent.

The only thing I don't like is the fact that it uses it's own form of damage detection :/
The problem is, units are going to enter the map very often in a real game and die.
And what happens to the event registered for those units on the damage trigger? Nothing, they leak, and make everything slower.
Damage detection systems solve this by recycling the trigger every time a certain number of units is deindexed. (15 is the most commonly used value, but Nestharus uses 80.)

Really, the best solution is to use Bribe's DamageEngine here, because if you're going to make so many Stand-alone systems, than you're going to end up with a slow map since every system would have it's own damage detection code, it's onIndex/onDeindex code, etc...

You can treat Bribe's Damage Engine as a standard library.
No one would mind if you would use it or not, because they're likely already using it in their maps, and importing it is something you'd have to do only once.
Bribe's UnitIndexer is also very standard as well.

Using Bribe's DamageEngine would also increase the usability of this system.

The majority of people move forward.
They move from using no damage detection system, to using a damage detection system.
They do not move from using a damage detection system, to using no damage detection system.

So, your resource is actually becoming less usable as time progresses.

The /sane/ people who use damage detection systems would not use this because it uses it's own form of damage detection, and if they /do/ use it, they're going to have to modify the triggers quite a lot.

The people who don't use damage detection systems will use this.
But, they will likely use other systems too, possibly systems that use a standard Damage detection library. At that point, if they are /sane/ enough, they would start taking advantage of damage detectors, and they will end up having to modify your system to use whichever standard library you're using.

Requirements are not a bad thing.
They are a good thing.
They only need to be installed once per map, and the benefits are immense.

I really need people to stop having this ideology that requirements are something terrible that we should all try to avoid as much as possible, it just kills modularity, speed, and because of the increased code length, readability, so it's not a Win-Win, it's a Win-lose-lose-lose :/

Thank you for taking the time to read this lengthy piece of text.
Actually, I don't even know how long it is because this Moderator Review is pretty small, lol.

 

[defskull]

Reserved.

 

[Kingz]

This should probably interface with another damage detection engine rather than making one again.

Mainly this one in order to reduce the redundant code and improve effectiveness.

You shouldn't use item charges for the detection, as for example:
I have a sword that casts sleep up to 10 times, but doesn't dissapear after using all 10. If i were to use your system my charges would drop even without me casting the item ability.
Use a saved integer inside a hashtable instead.

 

[defskull]

This should probably interface with another damage detection engine rather than making one again.

Mainly this one in order to reduce the redundant code and improve effectiveness.

I'm trying to create a system that is stand-alone, I don't want any other system to be one of requirements to use in my system.
Still effective enough I see, you won't get registered twice or more because I put a Condition of Unit Group, so there won't be Event leak (register Unit Takes Damage Event twice or more).
Once again, I'd like my system to support on its own, I don't want to add extra condition to user if they want to use my system, they gotta install that Damage Detection System.
And that system is related with another system, Unit Indexer.
So there's now 3 systems needs to be implemented if they wanna use this system which is not my aim from the start.
Also, it is working as intended, so I'm not so worry about efficiency as long my system does not has bugs, it's good enough, but there will always be a room for improvements, except that this one I won't "improve" because I want a stand-alone system.

You shouldn't use item charges for the detection, as for example:
I have a sword that casts sleep up to 10 times, but doesn't dissapear after using all 10. If i were to use your system my charges would drop even without me casting the item ability.
Use a saved integer inside a hashtable instead.

I hope you read the "INTRODUCTIONS" hidden tag, right ?
There's a note message there, you should read it.

Also, there's a reason why I used Item Charges.

It is because I want to show how many durability left for that item.
Face it, if you wanna use my system, you should not register items with Charged.
If you wanna have an item that is Charged, you should not use my system.

I can use Integer as the Item Durability BUT, there's no durability counter shown on the item over at the Inventory, which will make the user confused how many durability does each item left.

I could use Multiboards to show current durability, but hey, if you have 3 Heroes in that map, would you expect me to create 3 Multiboards for each Hero per player ?

That's the only reason why I used Item Charges as its durability, to acknowledge Players how much durability does each item has.

Next Features:
- Will add "Repair" option to the item.

 

[Kingz]

It should then be a configurable:

if SHOW_DURABILITY is set to true use charges of the item to show durability, else use a integer saved via hashtable and don't show the number.

It should support both cases and the modification isn't hard to make.

Edit:

It is because I want to show how many durability left for that item.
Face it, if you wanna use my system, you should not register items with Charged.
If you wanna have an item that is Charged, you should not use my system

It's not about what you want, it's what the users find useful.
Crippling the possibility of the system for users who want to have charged items is against the very idea of a public resource. You make the resource for the public not yourself, ergo it should support charged items as they are quite common (both potions and otherwise).

I could use Multiboards to show current durability, but hey, if you have 3 Heroes in that map, would you expect me to create 3 Multiboards for each Hero per player ?

Don't, multiboards are used for different things and they are quite messy, keep it light.

Edit:

As said by magtheridon, those 2 systems you mentioned you "don't want" are really useful and should be present in most maps by now.

Also, it is working as intended, so I'm not so worry about efficiency as long my system does not has bugs, it's good enough, but there will always be a room for improvements, except that this one I won't "improve" because I want a stand-alone system.

You won't get far making systems if you think like this. We have a lot of really effective scripts/systems around that make our work easier and reinventing the wheel is frowned upon anyway, especially when you invent a "square" wheel.

 

[defskull]

t should then be a configurable:

if SHOW_DURABILITY is set to true use charges of the item to show durability, else use a integer saved via hashtable and don't show the number.

It should support both cases and the modification isn't hard to make.

What if the user wants both ?
To have item durability AND have potions that has charges ?
It's pretty funny to see Potions have durability too, right ?
Therefore, don't register potions or any other item that uses charges to the system, simple as that.
Hey, a system has its limitations too you know, you can't always follow user but you can receive feedback on what to improve and how.
Therefore, I'm sticking to my method.

I will add new feature that will not reduce the item counter even when the item is used.

For example, you have an item ability, that when activate, it will damage all enemy units around the user.

Currently, whenever you use an item that has charges, it will reduce its counter automatically.

In the next version, I would make the item to use ability from it without reducing the counter.

However, for the Unit Indexer + DDS, I'll implement them in the next version.

 

[Kingz]

It's pretty funny to see Potions have durability too, right ?

Or you know... filter them out with their classification of "Consumeable".
Edit:
Not to mention you have to manually add items to your system meaning the user should know not to register potions anyway.

 

[defskull]

Or you know... filter them out with their classification of "Consumeable".

I should not filter them out if the item is not registered to the system in the first place, right ?
Ah yea, currently my system will loop through all 6 inventories and will reduce the item charge.
But, if I load the value which has a null value from that item (returns 0), therefore the item has 0% chance to be reduce its item charges, right ?
Therefore, it is impossible for the Potions to be reduced its item charges upon taking damage.

 

[Kingz]

You should read the 2nd part of my post, the edited one, i said the exact same thing you did.

 

[defskull]

Magtheridon96: Okay, this is a really nice system, and the configuration is excellent.

The only thing I don't like is the fact that it uses it's own form of damage detection :/
The problem is, units are going to enter the map very often in a real game and die.
And what happens to the event registered for those units on the damage trigger? Nothing, they leak, and make everything slower.
Damage detection systems solve this by recycling the trigger every time a certain number of units is deindexed. (15 is the most commonly used value, but Nestharus uses 80.)

Really, the best solution is to use Bribe's DamageEngine here, because if you're going to make so many Stand-alone systems, than you're going to end up with a slow map since every system would have it's own damage detection code, it's onIndex/onDeindex code, etc...

You can treat Bribe's Damage Engine as a standard library.
No one would mind if you would use it or not, because they're likely already using it in their maps, and importing it is something you'd have to do only once.
Bribe's UnitIndexer is also very standard as well.

Using Bribe's DamageEngine would also increase the usability of this system.

The majority of people move forward.
They move from using no damage detection system, to using a damage detection system.
They do not move from using a damage detection system, to using no damage detection system.

So, your resource is actually becoming less usable as time progresses.

The /sane/ people who use damage detection systems would not use this because it uses it's own form of damage detection, and if they /do/ use it, they're going to have to modify the triggers quite a lot.

The people who don't use damage detection systems will use this.
But, they will likely use other systems too, possibly systems that use a standard Damage detection library. At that point, if they are /sane/ enough, they would start taking advantage of damage detectors, and they will end up having to modify your system to use whichever standard library you're using.

Requirements are not a bad thing.
They are a good thing.
They only need to be installed once per map, and the benefits are immense.

I really need people to stop having this ideology that requirements are something terrible that we should all try to avoid as much as possible, it just kills modularity, speed, and because of the increased code length, readability, so it's not a Win-Win, it's a Win-lose-lose-lose :/

Thank you for taking the time to read this lengthy piece of text.
Actually, I don't even know how long it is because this Moderator Review is pretty small, lol.

You just want me to change to Indexing, is that it for this long comments :/
Sadly hashtable has been forgotten, okay.

EDIT:
Updated to v1.0f

 

[Adiktuz]

Hmmm... I go with Kingz, I prefer the capability to register charged items... but yeah, it could be a bit hard or maybe really hard or inefficient...

anyway, this would be really useful for those who needs it...

 

[Magtheridon96]

All I wanted you to do was use a standard Damage detection system :/
It's much better to have users use one damage detection system for everything, hence the standard ones, than to have one damage detection system per spell/system.

Using standard ones is the best way to go because then you can assure that users will be using only one or zero damage detection systems in their map.

 

[defskull]

All I wanted you to do was use a standard Damage detection system :/

What is the "standard ones" ?
Whaaaat...

 

[Adiktuz]

Bribe's GUI Damage engine...

 

[defskull]

I already updated it ????????

 

[Adiktuz]

maybe you should put in the description that it uses the GUIDE, and also put proper credits and link to GUIDE

 

[defskull]

The what GUIDE ?
Or a system ?

Lol I forgot to mention it in the CREDITS section.

 

[Adiktuz]

GUI Damage Engine... I just thought up of shortening it to an acronym and it turned out to be GUIDE when I posted...

 

[Magtheridon96]

GUIDE
What an epic coincidence!

 

[defskull]

Okay updated it, removed old script (lol).

 

[Virus-X]

What the hell is this, good thing i just copy a clone map or my map cannot edit anymore, anyone how to fix this, i'm using Warcraft 3 World Editor New Version
Edit:

I just test another blank map, but still error