System IDEA - Item Death Event & Autoindexer

[wraithseeker]

I'm sure if you request it in wc3c to have a item death event, vex will do it.

 

[Jesus4Lyf]

I'm pretty sure this makes that unnecessary...

 

[Azlier]

The ItemFinder scans the map for items laying on the ground during gameplay, unindexed. The original detected everything but items laying on the ground during gameplay.

Besides, mine is more efficient than Vex's because mine detects item deaths and pawning directly. (He will hate me for the dynamic triggers, I tell you. He hates them with a burning passion. That and TriggerExecCount.) His lets you use RemoveItem, but that's pretty much the only pro of scanning through indexed item slots.

Off topic:

Oh, and sorry Vex, but this Init function made me lol.

private function init takes nothing returns nothing
     local timer T= CreateTimer()
     call TimerStart(T, RECYCLE_INTERVAL, true, function recycleLoop)
endfunction

-->

private function init takes nothing returns nothing
     call TimerStart(CreateTimer(), RECYCLE_INTERVAL, true, function recycleLoop)
endfunction

 

[SerraAvenger]

Awesome!
Can you make two systems out of this, the IDE and the PII part and make IDE require PII?
I don't want to import both Event and IDE just for the PII part...

 

[Azlier]

The Event struct can be privatized and put directly into the system. The indexer does actually depend upon the item death event, too.

 

[SerraAvenger]

The Event struct can be privatized and put directly into the system. The indexer does actually depend upon the item death event, too.

hum. Okay.

 

[Azlier]

With no death event, I end up scanning through the items checking for missing ones. Like ItemDex does.

>Note that if you do this, you should NOT loop through all items at once, instead please loop through one every 0.03125 of a second or something. The detection of removal for recycling the index doesn't have to be fast, just happen some time.

Wait, what is Jesus4Lyf talking about? I don't scan through indices... you still have to use RemoveItemEx.

 

[Jesus4Lyf]

>that's why I didn't complain about RemoveItemEx - I'm sure with a timer looping through each item you could accomplish Remove detection just fine
I meant as an alternative to RemoveItemEx, you could've done this, but I didn't complain and suggest it because I liked the efficiency.

So does this not allow attaching to a newly created item on the ground?

 

[Azlier]

Not instantly. There is no detection for an item entering a region.

It's either the timer, or GetItemIndex not being inlined. Perhaps it not being inlined could be better.

 

[Blackrage]

First came PUI. Then came IDEA. Next will come DDI (Destructable Death & Indexer) (Don't flame me please xD)

 

[Jesus4Lyf]

>Next will come DDI (Destructable Death & Indexer)
Sounds like a fun idea.

Err so. I'd have to say it may be worth not making this inline, but you still can't remove your item detection mechanisms because of the death event. Still, it only makes sense that sooner or later people will actually want to create an item and attach data to it?

Suppose you might as well make this foolproof. How about allowing RemoveItem and having a timer cycle through just one item in the list every 0.03125 seconds to check if it has been removed?

 

[Azlier]

I'd rather use no timer at all. Or use native hooks, which are indeed coming. I'll go ahead and do non-inlining GetItemIndex .

 

[Jesus4Lyf]

You can change this to a native hook system once they're released (I had no idea they were, but this is good news if it is done well). In the mean time, non-inlining will do just fine. Users won't need to change their code, then, to replace RemoveItemEx.

 

[Cohadar]

First of all IDEA is not PUI for items.
Last time I checked PUI automatically deletes all structs attached to unit when unit gets removed from map.

IDEA is just item indexing + item death event (which is good enough for itself)

So this is a misinformation and I request you delete it immediately:

module IDEA
//Tweaks a struct to work exactly like the "//! runtextmacro PUI()" textmacro in PUI (duh).

Note also that basic premise of PUI is that you can use RemoveUnit and get away with it.

EDIT:
You also seem to have a bug somewhere.
Compile your demo map in debug mode, when you sel items you pick from ground you get:
Attempt to destry a null struct of type: IDEA__ItemData

 

[Azlier]

>First of all IDEA is not PUI for items.
Nope. Not exactly. Didn't know PUI destroyed structs. Huh. Nevermind, then.

>Attempt to destry a null struct of type: IDEA__ItemData
Vhat? Must see check this for myself.
EDIT: Fixed. I blame Blizzard's relatively unpredictable item event responses.

 

[Cohadar]

May I suggest:

private struct ItemData

    trigger Trig
    
    static method create takes item i returns ItemData
        local ItemData this = ItemData.allocate()
        call SetItemUserData(i, this)
        set .Trig = CreateTrigger()
        call TriggerRegisterDeathEvent(.Trig, i)
        call TriggerAddCondition(.Trig, OnDeath)
        return this
    endmethod
    
    private method onDestroy takes nothing returns nothing
        call TriggerClearConditions(.Trig)
        call DestroyTrigger(.Trig)
    endmethod

endstruct

//...

function RemoveItemEx takes item i returns nothing
    local ItemData d = GetItemUserData(i)
    //call DestroyTrigger(d.Trig)
    call d.destroy()
    call RemoveItem(i)
endfunction

 

[Azlier]

Yes, that is a good plan. There, done. But I made it better than even what you have there.

Not clearing conditions, though. Sorry. I have no evidence that they leak.

EDIT: Update. Now cleans item leaks. The most common item leaks are tomes that you buy so much, that you can see tiny sparkling tomes on the ground forever after. IDEA now removes those. But, it now requires KT2.

EDIT2: Just read that PII does that as well :nuts:. Huh. Still keeping it, though.

 

[Cohadar]

These things tend to converge, which is nice because it makes spells easily convertible between systems.

 

[Azlier]

It seems that way. Once Vex gets those native hooks ready, GetItemIndex will inline like it did originally. I hate having to wait on Vex .

And, once Vex makes modules live up to the hype, it will automatically destroy structs on item destruction, too.

 

[Vexorian]

since this uses KT2, that item decay stuff is completely bugged and umpredictable, you should probably update the documentation to say that ITEM_DECAY is no guarantee that the removed items will last for 5 seconds, they will just last at most five seconds, they could get removed just away...

No H2I

For the love of god, stop smearing on perfectly good things for no reason...