RegisterPlayerUnitEvent

[Bribe]

To reduce the cumbersome amount of handles generated by registering a player unit event for each player, this system localizes it all and groups everything together.

This function is more than a wrapper for TriggerRegisterAnyUnitEventBJ, it is also the replacement.

The API is as simple as this:

JASS:

call RegisterPlayerUnitEvent(EVENT_PLAYER_UNIT_DEATH, function OnDeath)
...
call RegisterPlayerUnitEvent(EVENT_PLAYER_UNIT_ISSUED_ORDER, function OnOrder)

And the code is really this short:

JASS:

library RegisterPlayerUnitEvent
    globals
        private trigger array t
    endglobals
    function RegisterPlayerUnitEvent takes playerunitevent p, code c returns nothing
        local integer i = GetHandleId(p)
        if t[i] == null then
            set t[i] = CreateTrigger()
            call TriggerRegisterAnyUnitEventBJ(t[i], p)
        endif
        call TriggerAddCondition(t[i], Filter(c))
    endfunction
endlibrary

[Anitarf]

I'm not convinced that saving a few dozen handles is worth implementing an additional library. Sure, implementing a simple library like this is not a big deal, but neither is having a few dozen extra handles in your map. There doesn't seem to be any noticeable difference between using this library and not using it, so I don't think it meets our usefulness criterion for resources.

[Bribe]

For those who don't want the requirement but want the potential benefit could use static if's (you know those things that so many people forget even exist) and "requires optional" (something not seen nearly enough).

In terms of efficiency there is not a lot to be gained, but by saying "a few dozen" handles will be saved that is underestimating. Order events, spell events and death events are quite common among a multitude of resources, the number of handles saved can easily launch into the hundreds and larger maps even more.

Surely using something like your http://www.wc3c.net/showthread.php?t=105374 is quite useful for handling that corner of the market, but this is more extensible.

[Deaod]

There are other things to be gained by centralizing spell events than fewer handles. It avoids running the trigger of each spell listening on that event, even if the spell has not been cast. Saving a few handles on the way is a nice bonus, but not the primary reason for such a library.

[Bribe]

Anitarf's SpellEvent could run off of this, which shows its extensibility. But the main reason to use this is to save on handle count (mostly for the RAM benefit), and I don't see how that isn't reason enough to use it.

[Anitarf]

Originally Posted by Bribe

Anitarf's SpellEvent could run off of this,

Yes, but why should it? Once you have a system like it in your map, its spell event trigger is the only one you'll need. In that case, using this library makes literally no difference. Same goes for orders, if you are using order triggers a lot, this would help a bit, but having a dedicated order event library that allows you to filter responses based on the issued order id would help a whole lot more and once you had such a library implemented, this one would again be useless.

As far as other unit events go, they are not used often. "A few dozen handles" is by no means an underestimation. There is no utility in saving a few dozen handles' worth of RAM.

[Bribe]

I am not getting your arguments, or maybe you are not getting what the community is building with their resources.

There are many playerunitevents that are not order events that are used, and used by multiple libraries like item systems, death detection, not to mention the infamous UNIT_ATTACKED that is still useful for detecting the moment the animation finishes. Hero leveling is also commonly seen lately.

Saving a few dozen handles is the smallest benefit to be gained, however in many maps I've seen there is room for saving hundreds.

In either case saving RAM is worth it - and I mean just for the sake of saving RAM this is worth it. Fewer handles is the lower concern although it does help if you are using something like handle ID offsetting (keeping handles as low as possible), in such a way this contributes little (but it does contribute).

[Anitarf]

Originally Posted by Bribe

There are many playerunitevents that are not order events that are used, and used by multiple libraries like item systems, death detection, not to mention the infamous UNIT_ATTACKED that is still useful for detecting the moment the animation finishes. Hero leveling is also commonly seen lately.

Well, could I get a sample list of such libraries? Preferably ones that don't do the same thing; for example, there may be many hero leveling systems out there that all use the hero level event, but a map is unlikely to use more than one such system.

Saving a few dozen handles is the smallest benefit to be gained, however in many maps I've seen there is room for saving hundreds.

The smallest benefit to be gained is zero. The term "many maps I've seen" is not very helpful; could I get some examples of such maps? Preferably ones that are well coded; after all, saving a hundred handles doesn't really mean much in a map that uses leaking GUI triggers.

In either case saving RAM is worth it - and I mean just for the sake of saving RAM this is worth it.

I disagree. The utility of saving an amount of RAM this small has not been demonstrated. On the other hand, even simple libraries like this have a cost in terms of the time it takes to implement them. Any cost, no matter how small, is not worth it if in return you get zero utility.

Fewer handles is the lower concern although it does help if you are using something like handle ID offsetting (keeping handles as low as possible), in such a way this contributes little (but it does contribute).

It doesn't really contribute anything. For handle ID offsetting, we don't need to keep the handles as low as possible; we just need to keep them lower than 8190. A difference between 1000 and 1100 handles is meaningless. You would need to be saving thousands of handles to be able to claim any kind of utility in this regard.

[Bribe]

Anitarf, if you were keeping up with what the wc3 community is building (I guess you won't see much action on this specific site) you wouldn't have even asked me to cough up some maps or systems.

How much RAM saving would it take to convince you of the value? Probably none at all based on your replies.

If you want to talk about cost of implementation well it's the difference between typing this:

JASS:

local trigger t = CreateTrigger()
call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_DEATH)
call TriggerAddAction(t, function OnDeath)
set t = null

JASS:

call RegisterPlayerUnitEvent(EVENT_PLAYER_UNIT_DEATH, function OnDeath)

I'd say the cost of implementing this is in the negatives, meaning it saves time. Unless you are repairing an existing map, then you can enjoy the benefit of saving lots of bytes of text to keep the map file size down. Which is another argument all in itself.

[Captain Griffen]

I'm not convinced that saving a few dozen handles is worth implementing an additional library. Sure, implementing a simple library like this is not a big deal, but neither is having a few dozen extra handles in your map.

I agree. The efficiency argument seems silly, since it isn't going to make any real difference. Not using conditions may actually make it less efficient, potentially.

But this seems much more important:

I'd say the cost of implementing this is in the negatives, meaning it saves time.

I'm lazy though, and like less lines. Less lines of code is nice for readability too. Plus it cuts out a silly BJ, but I think that's just an irrational hatred of BJs (of the coding kind, anyway).

[Anitarf]

Originally Posted by Bribe

Anitarf, if you were keeping up with what the wc3 community is building (I guess you won't see much action on this specific site) you wouldn't have even asked me to cough up some maps or systems.

Bribe, if you were really interested in getting this approved you wouldn't be pontificating pointlessly like that. You're just making it seem like you can't come up with any convincing examples.

How much RAM saving would it take to convince you of the value? Probably none at all based on your replies.

There certainly is an amount that would make implementing an extra library worthwhile on its own, but I'm pretty certain your library doesn't come close to reaching it. Early heavily triggered maps had many leaks and that did start to affect performance after a while, so there is utility in reducing the handle count if it can be done on that scale, however we are talking about thousands if not tens of thousands of handles here.

If you want to talk about cost of implementation well it's the difference between typing this:

JASS:

local trigger t = CreateTrigger()
call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_DEATH)
call TriggerAddAction(t, function OnDeath)
set t = null

JASS:

call RegisterPlayerUnitEvent(EVENT_PLAYER_UNIT_DEATH, function OnDeath)

I'd say the cost of implementing this is in the negatives, meaning it saves time. Unless you are repairing an existing map, then you can enjoy the benefit of saving lots of bytes of text to keep the map file size down. Which is another argument all in itself.

That's not a particularly fair comparison. The fourth line in the first example is not really needed, while the second example omits the requires RegisterPlayerUnitEvent that needs to be typed in a different place, not to mention that autocomplete helps you type most of the first example anyway. Besides, according to your earlier post, users would need to type something more like this:

JASS:

static if LIBRARY_RegisterPlayerUnitEvent then
    call RegisterPlayerUnitEvent(EVENT_PLAYER_UNIT_DEATH, function OnDeath)
else
    local trigger t = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_DEATH)
    call TriggerAddAction(t, function OnDeath)
endif

[Bribe]

Anitarf, plenty of resources use the EVENT_PLAYER_UNIT_DEATH registry (this is the most common) and I could come up with a lot of examples of many unrelated systems which have completely legitimate useage of it, and smaller numbers of various systems which use other types, however I am concerned that presenting said things is going to "do it" for you as you've made your stance pretty clear that the dozens-hundreds of saved handles implementing this does not reach your thousands-tends of thousands saved handle requirement.

That and the fact you made a pretty big point on the utility factor, which this absolutely doesn't have (offers no new functionality). I could add in some relevant functions which could enhance the features and offer more to do with it, but for now I really have other things to focus on as I completely suck at multi-tasking.

You are welcome to graveyard this thing.

[BBQ]

This should be changed to use trigger conditions (just like the version on THW), as it has been show that creating boolexprs out of functions that return nothing is perfectly safe.

[Bribe]

You are right. I didn't think pJass would let that compile but I guess the "Evil Workaround" those guys were talking about is just to have a proxy take the code as an argument and then pJass is defeated.

[Anitarf]

Well, I recently stumbled upon a similar resource that got approved in the past, so precedent says this meets our criteria for usefulness. Since this is considerably better than the old implementation I'll graveyard it and approve this.