System IDEA - Item Death Event & Autoindexer

[Jesus4Lyf]

>For the love of god, stop smearing on perfectly good things for no reason...
Sounds hypocritical, considering that issue in KT2 was removed ages ago.

 

[Azlier]

>no guarantee that the removed items will last for 5 seconds, they will just last at most five seconds

I have tested that issue, and another system called HT has been implemented into KT to handle long periods with accuracy. The items are removed after 5 seconds, in exactly the order I spam-picked them up.

 

[Azlier]

Quick fix for 1.23b. It's slower now. Hurray. Let's hope Blizzard gives us GetTriggerItem, then it becomes fast.

Also, structs attached to items via the module will now attempt to destroy themselves. Sooner or later. Best I could do without a timer scanning indices.

A MyData[MyItem] == 0 check before messing with IDEA structs can do a lot of good.

Great, now I have to wait for both Blizzard AND Vexorian.

 

[wraithseeker]

Isn't GetTriggerItem GetManipulatedItem()?

 

[Azlier]

No. We're talking about an item death event, here.

 

[Jesus4Lyf]

>Quick fix for 1.23b.
This never used the return bug. >_<

I'm quite sure I explained that. <_<

 

[Azlier]

Blizzard isn't supporting casting from widgets directly to units, destructables, or items anymore. So, in a way, it did use "unsafe" upcasting. Even though it could only be an item the entire time.

 

[Jesus4Lyf]

Lol? Are you sure? I still haven't patched up so I haven't tested this, but I know the syntax checker in NewGen was broken the whole time...

 

[Jesus4Lyf]

I think this needs resurrection.

struct MyItemData extends array
    real x
    real y
    implement IDEA
    private method IDEA_onCreate takes nothing returns nothing
        set this.x=GetItemX(this.item)
        set this.y=GetItemY(this.item)
    endmethod
    private method IDEA_onDestroy takes nothing returns nothing
        call BJDebugMsg("Item Removed")
    endmethod
endstruct

Can you make it work?

 

[Azlier]

I can't at the moment.

I'd be glad to make it work. It's teeeerrible at the moment.

And I'm still waiting for better hooks to perfect this.

 

[Azlier]

Udapetd.

 

[Jesus4Lyf]

function RemoveItemEx takes item i returns nothing //For compatibility.

That's not compatible - it doesn't remove items?

IDEA structs should have the static IDEA_filter method, because that would allow you to make structs specific to an item type (very useful with items). Of course, the filter would just prevent onCreate and onDestroy from firing.

I don't think IDEA structs support recursion - what if when one item is created, we create another item? Won't subsequent onCreate methods fail for the original item?

How about methods like onAquire, onDrop and onUse?
(And a documented paradigm about when these fire, such as an item cannot come to be on a unit without onAquire firing immediately after it is picked up).

You probably noticed my attempt at making this redundant, but the code was ridiculous... but the methods you can implement could work well here.

 

[Azlier]

And I thought I could sneak away without a filter method. I should go back to AIDS and steal more code to fix the recursion thing, if there is indeed a problem.

I suppose those other methods are certainly doable.

EDIT:
It does indeed fail recursively.

>That's not compatible - it doesn't remove items?

Oh snap. You're right.

Can't fix that either, unless I remove it. Remove it I shall.

EDIT2:

Having big problems trying to figure out how AIDS handles recursion.

 

[Jesus4Lyf]

Having big problems trying to figure out how AIDS handles recursion.

*Nods and smiles*

A function which calls itself stores its local variables somewhere, naturally, and obviously not in the same place each time. It attaches to the instance of the function. Rite?

So it makes a stack. In AIDS, I make a parallel stack in JASS. To simulate locals, which can be accessed globally... eh, you get the picture. Maybe someone else can explain it better (or myself, if you still don't get it).

 

[grim002]

Or maybe you could actually use local variables.

I can't believe that you would need to store local variables in a stack and access them globally except in cases of bad code design.

 

[Jesus4Lyf]

Or maybe you could actually use local variables.

I can't believe that you would need to store local variables in a stack and access them globally except in cases of bad code design.

Having not written a system like this for efficiency yourself, fair enough to say that...

To fire a dynamic number of functions in the most efficient way, where the number is decided on map init, one uses a single trigger - to which all said functions are attached (as conditions). If that fires itself (or potentially can), one must use the said method (a stack) to cause the same values to be passed to each called function on the trigger successfully.

It actually has nothing to do with local variables, it's just attaching the value to the instance of the function calls.

You prefer to make n triggers and run through them manually using an array (function interface solution to the problem, as seen in AI last time I checked). It's just not as efficient.

Edit: It's actually for anything recursive that uses WC3 natives. You stab your efficiency if you don't. My Damage system does it, recursive GroupEnums should use it, etc.
On the same token as it's "poor code design", so is attaching values to timers. The timer should natively contain the data.

 

[grim002]

Like I said: bad code design.

 

[Narks]

Woah, holy shit, hiding an item apparently causes IDEA to destroy it.

 

[Azlier]

Well that's a problem now isn't it. I wonder what causes that...

 

[Narks]

I think also unhiding an item reallocates it? Although that might be a problem on my side...

EDIT:
Hmmm....

function GetItemIndex takes item i returns integer
    if GetItemUserData(i) != null then
        //! runtextmacro IDEA__RegisterItem("i")
    endif
    return s_Data.tempData
endfunction

This doesn't look right. If the item already has data, register it again? And what's with the strange return?

EDIT2:

function GetItemIndex takes item i returns integer
    local integer k = GetItemUserData(i)
    if k == 0 then
        //! runtextmacro IDEA__RegisterItem("i")
        return s_Data.tempData
    endif
    return k
endfunction

this seems to solve my other problem (not the destroying problem)