[Snippet] RegisterPlayerUnitEvent

[Bribe]

How would GUI users benefit? Not unless they coded in JASS really.

 

[Magtheridon96]

Well, they could benefit if they wanted to
They could leave the events in every trigger empty, then register them in some trigger that runs on map initialization.

I still agree with you: This would mainly benefit vanilla Jassers.

 

[azlier]

Ran my own benchmark. Not much of a measurable difference, if any. Here's the script I used and I attached the benchmarking map for good measure.

//! zinc
library Benchmark {

//Test results (Azlier):
// Or: 13.8 fps
// TriggerAddCondition: 13.9 fps

constant real TICK = 0.01;
constant integer COND_COUNT = 1500;
constant boolean USE_OR = true;

trigger Trig = CreateTrigger();
boolexpr Cond = null;
code Dummy;

function DummyFunc () {}

function Execute () {
    TriggerEvaluate(Trig);
}

function AddConds () {
    integer i = COND_COUNT;
    while (i != 0) {
        i -= 1;
        if (USE_OR) {
            if (Cond == null) {
                Cond = Condition(Dummy);
            } else {
                Cond = Or(Cond, Condition(Dummy));
                TriggerClearConditions(Trig);
            }
            TriggerAddCondition(Trig, Cond);
        } else {
            TriggerAddCondition(Trig, Condition(Dummy));
        }
    }
}

function BeginTest () -> boolean {
    TimerStart(CreateTimer(), TICK, true, function Execute);
    DestroyTrigger(GetTriggeringTrigger());
    return false;
}

function onInit () {
    trigger t = CreateTrigger();
    Dummy = function DummyFunc;
    
    AddConds.evaluate();
    
    TriggerRegisterPlayerEvent(t, GetLocalPlayer(), EVENT_PLAYER_END_CINEMATIC);
    TriggerAddCondition(t, function BeginTest);
    t = null;
    
    if (USE_OR) {
        DisplayTextToPlayer(GetLocalPlayer(), 0, 0, "Test: Or.");
    } else {
        DisplayTextToPlayer(GetLocalPlayer(), 0, 0, "Test: TriggerAddCondition.");
    }
    DisplayTextToPlayer(GetLocalPlayer(), 0, 0, "Press Esc to begin the test.");
}

}
//! endzinc

 

[Magtheridon96]

If that's true, I guess that the TriggerAddCondition version is better.
The Or version is pretty much the same. (Because I suspect that the boolexpr class contains 2 other boolexpr instances which are set inside a new instance of boolexpr when the Or function is used.)

 

[Dirac]

It would be best by far: it gives you the possibility of deleting the condition from the trigger after added, instead of a nasty overhead linked-list of boolexprs inside Or()

 

[Bribe]

Another benefit to using this is that you can allow your functions to return nothing (it doesn't crash Mac computers any more). pJass won't let Filter(function thatReturnsNothing) parse but if you first pass the code argument as a variable and then pass the code argument to the Filter it compiles just fine.

Therefore we can stop with the spamming of "return false" once and for all! Hah hah hah hah hah (evil victorious laugh).

 

[Dirac]

Kewl
I've been doing it since BBQ said that it's ok to do it

 

[Troll-Brain]

Btw, in most situations you should return true instead of false in such boolexprs, for many reasons :

- It makes sense to returns true when a code is succesfuly finished.
- This way you can easily check if you don't reach the limit op (if TriggerEvaluate returns true it doesn't, if it returns false you have reached it)
- Even if you use trigger actions, the actions will not be called if the trigger conditions were evaluated with a TriggerEvaluate.
- Trigger conditions don't use short-circuit evaluation anyway

 

[Adiktuz]

Another benefit to using this is that you can allow your functions to return nothing (it doesn't crash Mac computers any more). pJass won't let Filter(function thatReturnsNothing) parse but if you first pass the code argument as a variable and then pass the code argument to the Filter it compiles just fine.

Therefore we can stop with the spamming of "return false" once and for all! Hah hah hah hah hah (evil victorious laugh).

cool

 

[Luorax]

Another benefit to using this is that you can allow your functions to return nothing (it doesn't crash Mac computers any more). pJass won't let Filter(function thatReturnsNothing) parse but if you first pass the code argument as a variable and then pass the code argument to the Filter it compiles just fine.

Therefore we can stop with the spamming of "return false" once and for all! Hah hah hah hah hah (evil victorious laugh).

That's cool!

 

[Magtheridon96]

Another benefit to using this is that you can allow your functions to return nothing (it doesn't crash Mac computers any more). pJass won't let Filter(function thatReturnsNothing) parse but if you first pass the code argument as a variable and then pass the code argument to the Filter it compiles just fine.

Therefore we can stop with the spamming of "return false" once and for all! Hah hah hah hah hah (evil victorious laugh).

That's cool!

 

[Bribe]

Ccccccombo breaker!

 

[Magtheridon96]

Updated.

Added some really cool functions:
EnablePlayerUnitEvent
DisablePlayerUnitEvent

These are really useful when you want to do some very 'sensitive' actions like adding items to a unit that get removed at the end of a function.

 

[Bribe]

Bad, other libraries might need the event to fire but you disable it for everyone when you only want it disabled for yourself.

If you want it disabled, flag a boolean.

Sorry but those two functions do not belong.

The vanilla JASS version needs to be posted in the map header. It won't always work if it's just a trigger.

 

[Magtheridon96]

That's why I'm only using it when I'm doing things that I DON'T want any other system to detect.

I'm also using it to avoid infinite loops when you call the 'disassemble' function within a function registered to a pickup event. (RecipeEngine)

 

[Bribe]

That sounds more responsible. I guess if it has a disclaimer it will be more appropriate though. Like you don't want to do that for death-events or order-events, for example, as those are very important.

 

[Magtheridon96]

Yeah, I guess a disclaimer would be good

edit
Bad idea. Removed the 2 functions.

If you disable EVENT_PLAYER_UNIT_PICKUP_ITEM, Nestharus' GetItemOwner won't function.
If you disable EVENT_PLAYER_UNIT_DEATH, all hell would break loose.
If you disable EVENT_PLAYER_UNIT_ISSUED_ORDER, any library that logs unit orders wouldn't function properly.

It was a bad idea, and above all that, an epic fail.

 

[Switch33]

How does someone use this on a Player Unit Event that requires a condition? Or is it not possible?

Edit: Well, i guess I could replace the condition by using an if then else but eh.

 

[Bribe]

Yeah you use an if/then/else. Pro users do the condition and the action in the same thread anyway.

What's the condition you're checking? You can use SpellEffectEvent if it's a spell, or OrderEvent if it's an order. Pretty much anything else you're better off using an if/then/else block anyway.

 

[Switch33]

I'm working on a major recoding of this: http://www.wc3c.net/showthread.php?t=108895


To be as updated as possible. Including using Dirac's Linked List Module. But I guess it's gonna be a lot of work mainly cause I'm not familiar with linked lists really.

I've already re-organized the Camera/Math libraries to be readable and better.

But yeah it's a selection event, so it should be if/then/else. And for the order of the right click that will be an OrderEvent.

 

[Troll-Brain]

I've realized something with this approach against X triggers with the same event.

Let's say there is a trigger that needs to register any orders (for debugging or whatever).
An other trigger for forbid the point order "move", by using the trick pause unit/ issue immediate order 851973 / unpause unit.
You have to pause this last trigger to avoid an infinite recursive fire event.

With the X triggers approach it can be done easily, Disable/Enable/Trigger(GetTriggeringTrigger()), and you're done.

With this approach, you still have to do that but that will deactivate all things, including the debugging trigger.

I mean it's something that should be kept in mind, and X triggers are sometimes the way to go.

 

[Magtheridon96]

It won't matter much though.

 

[Troll-Brain]

Depends, really. (the debug example was just the first random thing i've thought about)
But having this in mind is enough.

 

[Magtheridon96]

I'll keep that in mind for the future.

 

[Bribe]

It sounds like the solution would be to use multiple triggers to handle that sort of firing, sort of like the Advent library where you can disable certain registries. Other than that, you'd pretty much need to disable the entire system, issue the order, then enable the entire system. I think this is enough of a solution. If anyone has any problems with doing that they can post it here.

 

[Magtheridon96]

I provided EnablePlayerUnitEvent and DisablePlayerUnitEvent functions awhile ago.
Then I removed them cause they were dangerous =p
I guess the only time you need those functions is when avoiding infinite loops, but then
again, if you're trying to avoid an infinite loop, you're going to be calling it from a function
registered to a trigger with a specific playerunitevent obviously, so why not just turn off
that trigger ;P

 

[Troll-Brain]

You don't get it.
In the mentionned case you can't turn off the trigger, else the order won't be registered for the print order function.
Sometimes multiple triggers is the only way to go.

 

[Magtheridon96]

Or, you can hook IssueOrder functions :x (Only 8-9 hooks if you're not using BJs/GUI)
Who cares about natural orders? You know they're being ordered as you go along so displaying them is useless.

 

[Troll-Brain]

Or, you can hook IssueOrder functions :x (Only 8-9 hooks if you're not using BJs/GUI)

I will consider it as bad joke.

Who cares about natural orders? You know they're being ordered as you go along so displaying them is useless.

Dude, it's just an example ...

 

[Magtheridon96]

It's debug-only, so it doesn't matter what you do (even if hooks slow everything down, it's debug-only, so who cares)
Multiple triggers are the way to go in every case, but I'm giving you an example of what you could do in this case.

 

[Troll-Brain]

it was just an example

 

[Magtheridon96]

I know.

 

[Troll-Brain]

Plus, it's not because you give an order, that it will be given (unit get stunned, invalid order, and such).

So plz admit that in some cases the multiple triggers is the only way to go (i'm not saying it happens that many times though)

 

[Magtheridon96]

So plz admit that in some cases the multiple triggers is the only way to go (i'm not saying it happens that many times though)

I already did

Multiple triggers are the way to go in every case

 

[Magtheridon96]

Updated to 5.0.0.0
Don't worry, backwards compatibility is NOT broken, I just added a new function.

function RegisterPlayerUnitEventForPlayer takes playerunitevent p, code c, player pl returns nothing

This function will register a playerunitevent for one player.
This was added because of special cases I found in which using TriggerRegisterPlayerUnitEvent would be much more of a bonus than using this library.
(When there are tons of events)

 

[Luorax]

/*
*       - function RegisterPlayerUnitEvent
*/

->

/*
*       - function RegisterPlayerUnitEventForPlayer
*/

 

[Magtheridon96]

Thanks, fixed.

 

[Troll-Brain]

Don't worry, backwards compatibility is NOT broken, I just added a new function

Pff, that's not fun :/

 

[Magtheridon96]

Pff, that's not fun :/

Vexorian changing TimerUtils' API is way funner >
Over 200 spells/systems would need an update (on Hive there are 1307 spells, and 385 Jass/vJass spells, but not all of them require it)

 

[Troll-Brain]

I don't care, i use my own TimerStack
Btw it's Anitarf, not Vexorian the guilty.

Tell me if it's too much off-topic, but i think it's fine with you, plus see how it keeps your resource on the top of the list ^^

 

[Magtheridon96]

I don't care about off-topic
To give no constructive criticism is like reassuring me that nothing's wrong with the resource at the moment ^_^ (Well, only when you guys are doing it ;P)

 

[Luorax]

Well, there's not much we can say about this snippet; it's short and does its job well. It's that simple.

 

[Bribe]

I like the API. Thanks for adding it in. Though its main use will be for map makers.

 

[jim7777]

Uhuh i don't know why this problem is arising on my map

well, i tried using everything of this snippet on each and every spell unfortunately, i'm having a stuck with a hero of mine with some synergy spells (like a skill will only work if a skill is cast or skill is learned or whatever)

And if there are many conditions with GetSpellAbilityId() running like (my theory)
GetSpellAbilityId() == SPECIFIC_ABIL
some parts might not work.. So i decided to change some of it to triggers or the normal creation of triggers blah blah
is that a war3 engine problem? or just this snippet

 

[Bribe]

Try using SpellEffectEvent, because it's meant to be used to avoid things like condition spamming.

http://www.hiveworkshop.com/forums/jass-resources-412/snippet-spelleffectevent-187193/

 

[jim7777]

i have successfully made it to the locker matie

thank you

 

[Magtheridon96]

SpellEffectEvent is much faster for spells because it only runs the thread that supposed to execute.
OrderEvent is the same.
RegisterPlayerUnitEvent is for everything else.

Maybe a RegisterPlayerEvent will be available soon
I'd code it, but I'm busy at the moment, so I'll code one later (maybe after January 15)

 

[Bribe]

Meh, playerevents are not so bad. There are only a few and most are useless:

    constant playerevent EVENT_PLAYER_STATE_LIMIT               = ConvertPlayerEvent(11)
    constant playerevent EVENT_PLAYER_ALLIANCE_CHANGED          = ConvertPlayerEvent(12)

    constant playerevent EVENT_PLAYER_DEFEAT                    = ConvertPlayerEvent(13)
    constant playerevent EVENT_PLAYER_VICTORY                   = ConvertPlayerEvent(14)
    constant playerevent EVENT_PLAYER_LEAVE                     = ConvertPlayerEvent(15)
    constant playerevent EVENT_PLAYER_CHAT                      = ConvertPlayerEvent(16)
    constant playerevent EVENT_PLAYER_END_CINEMATIC             = ConvertPlayerEvent(17)

For the other playerevents, those are all taken care of by ArrowKeyEvent.

 

[Magtheridon96]

StateLimit, Chat and AllianceChange events can't be covered like Leave, Esc, Defeat and Victory :/

I guess RegisterPlayerEvent would be useless

 

[Bribe]

Edit: Never mind, I forgot that playerunitevents start at index 18.

old

    function RegisterPlayerUnitEventForPlayer takes playerunitevent p, code c, player pl returns nothing
        local integer i = @260@ /* Needs to be 277 */ + 16 * GetHandleId(p) + GetPlayerId(pl)
        if t[i] == null then
            set t[i] = CreateTrigger()
            call TriggerRegisterPlayerUnitEvent(t[i], pl, p, null)
        endif
        call TriggerAddCondition(t[i], Filter(c))
    endfunction