Item Set System v.2

[Moderator]

12th Dec 2015
IcemanBo: For long time as NeedsFix. Rejected.

14:41, 18th May 2015
IcemanBo: http://www.hiveworkshop.com/forums/spells-569/item-set-system-v-2-a-263987/index2.html#post2685515

 

[Tal'Rarity]

This seems quite limiting, will check later. Good job on deciding to try on submitting it though, don't give up even if you don't succeed. =)

 

[BPower]

I never though about buffs to highlight the set bonuses.
I will add this to my ItemSet system, when I find the time
I solved your one item one set bonus problem with another type of data structure.

 

[q.b]

This seems quite limiting, will check later. Good job on deciding to try on submitting it though, don't give up even if you don't succeed. =)

Thanks. Yes, it is limited, but only because of transformations. If there aren't any, the limit doesn't apply.

I never though about buffs to highlight the set bonuses.
I will add this to my ItemSet system, when I find the time
I solved your one item one set bonus problem with another type of data structure.

What kind of data structure? Is in in vJass? Can you please share it?

 

[Tal'Rarity]

Thanks. Yes, it is limited, but only because of transformations. If there aren't any, the limit doesn't apply.

Well you do know you can make abilities permanent right? It's a JASS only function.

What kind of data structure? Is in in vJass? Can you please share it?

Yeah his is in VJass.

 

[q.b]

Well you do know you can make abilities permanent right? It's a JASS only function.

Of course, I do. I wrote it at the first part of Some Clarifications. The function 'UnitMakeAbilityPermanent' does work for spellbooks, but only for the spellbook. The abilities inside it do not become permanent even if the spellbook does, so even if the spellbook remains after transformation, it'll be empty because the abilities inside it are removed by the said transformation.

 

[Tal'Rarity]

Of course, I do. I wrote it at the first part of Some Clarifications. The function 'UnitMakeAbilityPermanent' does work for spellbooks, but only for the spellbook. The abilities inside it do not become permanent even if the spellbook does, so even if the spellbook remains after transformation, it'll be empty because the abilities inside it are removed by the said transformation.

Then track them and then identify them when this happens then re-add them.

 

[q.b]

Then track them and then identify them when this happens then re-add them.

There would be no need to use spellbooks if it was that easy to simply just track and make them permanent. Besides, I don't think there's a way to identify the abilities inside a spellbook (not that I know of).

I even tried tracking the transformation itself, but it required the recording of every transformation spell to be used in a map and their respective transformation times.

I'm considering using hashtables to try an idea I have in mind, but I don't want to use them if I can avoid it.

 

[Tal'Rarity]

There would be no need to use spellbooks if it was that easy to simply just track and make them permanent. Besides, I don't think there's a way to identify the abilities inside a spellbook (not that I know of).

I even tried tracking the transformation itself, but it required the recording of every transformation spell to be used in a map and their respective transformation times.

I'm considering using hashtables to try an idea I have in mind, but I don't want to use them if I can avoid it.

Why record custom spells when you can't have new order ID's in the first place? It's easy to track every single transformation spell, just use their orders instead of abilities. New/custom abilities still can't escape this, only channel can and it doesn't transform.

Also there really is no need to use spell-books.

 

[q.b]

Why record custom spells when you can't have new order ID's in the first place? It's easy to track every single transformation spell, just use their orders instead of abilities. New/custom abilities still can't escape this, only channel can and it doesn't transform.

Also there really is no need to use spell-books.

Detecting a transformation order/cast/end/effect didn't work. I just tried them all, actually. Abilities inside a permanent spellbook would still get removed even with 0.01 transformation time.

 

[Tal'Rarity]

Hashtables are an easy alternative and they're not that slow, You don't know how to detect those orders then, not your fault though... Not many know how to. I didn't even know how too for a while until I decided to look into it.

Edit:

Detecting a transformation order/cast/end/effect didn't work. I just tried them all, actually. Abilities inside a permanent spellbook would still get removed even with 0.01 transformation time.

http://www.hiveworkshop.com/forums/spells-569/duff-1-0-1-a-264019/

 

[q.b]

Hashtables are an easy alternative and they're not that slow, You don't know how to detect those orders then, not your fault though... Not many know how to. I didn't even know how too for a while until I decided to look into it.

Edit:


http://www.hiveworkshop.com/forums/spells-569/duff-1-0-1-a-264019/

First, I'd like to say thank you for that because I finally found a way to pass abilities through transformations even without using 'UnitMakeAbilityPermanent.' It's a clever use of order events, but, unfortunately . . .

. . . it does not detect the reversal of a temporary transformation if the cooldown of the transformation ability is greater than its duration until an order is given to that unit. A manual order is needed to be issued for their current status to be detected.

 

[Tal'Rarity]

. . . it does not detect the reversal of a temporary transformation if the cooldown of the transformation ability is greater than its duration until an order is given to that unit. A manual order is needed to be issued for their current status to be detected.

Could you explain a bit more? I would like to fix that bug if possible, but I don't know about it.

 

[q.b]

Could you explain a bit more? I would like to fix that bug if possible, but I don't know about it.

You can actually see it for yourself by:

1. Having two units each with a transformation ability: one with cooldown set higher than its duration (+ transformation time, I'm not sure) and another one with cooldown set lower or equal to its duration.

2. Using your DUFF system to check the transformation, transform each unit one at a time, checking for the messages displayed by your system. The one with the cooldown <= duration will display the revert message while the other one will not display anything until you give an order to any unit.

I'm not sure how to explain it, but I think it's because, during the undoing of a temporary transformation, the transformation ability is actually cast (if it's on cooldown), so it is detected by events (cast, effect, finish, order). However, if it's not on cooldown, it will not be detected at all.

For your system to detect the reversal of the transformation with higher cooldown than its duration, an order (any) had to be given to any of the units present for the triggers to fire.

 

[Tal'Rarity]

You can actually see it for yourself by:

1. Having two units each with a transformation ability: one with cooldown set higher than its duration (+ transformation time, I'm not sure) and another one with cooldown set lower or equal to its duration.

2. Using your DUFF system to check the transformation, transform each unit one at a time, checking for the messages displayed by your system. The one with the cooldown <= duration will display the revert message while the other one will not display anything until you give an order to any unit.

I'm not sure how to explain it, but I think it's because, during the undoing of a temporary transformation, the transformation ability is actually cast (if it's on cooldown), so it is detected by events (cast, effect, finish, order). However, if it's not on cooldown, it will not be detected at all.

For your system to detect the reversal of the transformation with higher cooldown than its duration, an order (any) had to be given to any of the units present for the triggers to fire.

That's actually something everyone shouldn't do, its a Blizzard bug. Recently discovered it in demonic rage by reyo which inspired my bankai spell.

It does eventually fix itself though I currently don't know how to fix it myself yet.

 

[IcemanBo]

I recommend you to use a hastable and save boolean "true" to key "item type" of a registered item.
This will avoid unneeded looping in your core system to check if item is in a set or not.

Seems like there are some redundant operations.

We're used to use TriggerCondition over TriggerAction. It's slighly faster.

The system looks simple and might be useful. I like it.

 

[IcemanBo]

Read my post above + ...

... with hastbales you not only remove the loop for item check, but you also could keep track of the number of items a unit currently has from a set.
This could again avoid an internal loop.

In case you won't keep track of the number of items of a set:
if .... and CountItemsOfSameType(u, GetItemTypeId(i)) - 1 == 0)
->
if .... and (c == 1)

 

[q.b]

Updated.

Please check again if it's better now.

 

[IcemanBo]

• Take more advantage of hashtable.
  Use hashtable to save the set_level for a unit.
  onDrop you decrease it, onPickUp you increase it.
  Then you don't need loops to know what ability to add/remove etc..
  As this is big part of the code implementation I value performance here.
• itemcount - 1 == 0
  ->
  itemcount == 1
• You cancel loop when index is higher than 6. Additionaly you can canel when itemType matches 0.
• all SetPlayerAbilityAvailable(GetOwningPlayer(u), effect_id[index], false)
  ^Why?
• (LoadBoolean(udg_ItemSet_System_Hashtable, id, 0) == true)
  ->
  LoadBoolean(udg_ItemSet_System_Hashtable, id, 0)
• Nulling a static trigger is not necessarily needed, because it's never destroyed. (but I don't count this as mistake)