System Rectwraps

[Troll-Brain]

Aha that's evil, it's just a JassHelper future or bug, depends your opinion

When a method doesn't need to be evaluated (because the function exist before his call) then JassHelper doesn't evaluate it, and the state of debug mode doesn't matter.

struct s_data

   method A takes nothing returns nothing
    // code
   endmethod

   method B takes nothing returns nothing
      call this.A.evaluate() // ignored !!!! it compiles like "call this.A()"
   endmethod

endstruct

I guess it's because Vexorian thought TriggerEvaluate didn't open a new thread, but it's false.
And also probably to inline, when it's possible, some auto evaluated methods if you don't have turned on [forcemethodevaluate] inside jasshelper.conf

 

[Azlier]

D'oh. Vexorian.

 

[Troll-Brain]

Instead of using .execute you could still use . evaluate

    method replaceTerrain takes integer oldTerrain, integer terrain returns nothing
        set .old = oldTerrain
        set .new = terrain
        set .curX = .minX + 64
        set .curY = .minY + 64 //Magic numbers for the win.
        set .tempRW = this
        call ReplaceTerrainA.evaluate()
    endmethod
    
    private static method ReplaceTerrainA takes nothing returns nothing
        loop
            set .curX = .tempRW.minX + 64
            call ReplaceTerrainB.evaluate()
            set .curY = .curY + 128
            exitwhen .curY > .tempRW.maxY
        endloop
    endmethod
    
    private static method ReplaceTerrainB takes nothing returns nothing
        loop
            if GetTerrainType(.curX, .curY) == .old then
                call SetTerrainType(.curX, .curY, .new, -1, 1, 1)
            endif
            set .curX = .curX + 128
            exitwhen .curX > .tempRW.maxX
        endloop
    endmethod

Also i see more your attachment as a proof of concept than something that really should be used, we have GetHandleId and hashtables now.

 

[Executor]

What about optional Event requirement? You could add the Event library wrapped in a static if..

 

[Troll-Brain]

I think he hate to much the EventReg thing

 

[Azlier]

>Instead of using .execute you could still use . evaluate

I should just manually evaluate everything the way this is headed.

>What about optional Event requirement?

Two reasons.

1. EventReg is the bane of my very existence.
2. WC3C has this unwritten and often debated rule about not being able to require outside systems, perhaps even optionally. I'd rather not get tangled in that web.

 

[Troll-Brain]

I should just manually evaluate everything the way this is headed.

But it will create useless triggers and conditions, if you don't need to open a new thread though.
Not something really relevant, but still.

Oh and don't forget that you will save many bits of code if you don't optimize your map

 

[Executor]

>What about optional Event requirement?

Two reasons.

1. EventReg is the bane of my very existence.
2. WC3C has this unwritten and often debated rule about not being able to require outside systems, perhaps even optionally. I'd rather not get tangled in that web.

Hm, but who could say anything against sth. like this:

library RectWraps requires optional Event
    // ...
endlibrary
static if not LIBRARY_Event then
    library Event
        // ...
    endlibrary
endif

Just putting the optional Event library on the bottom.
User has Event => Yours is 'deleted'
User hasn't Event => Yours is used

 

[Azlier]

>Hm, but who could say anything against sth. like...

WC3C staff.

 

[Troll-Brain]

>Hm, but who could say anything against sth. like...

WC3C staff.

You forgot one big thing, you use TriggerExecute as a method to link an integer with a trigger, so there is no way it will be approved on wc3c.
And to be honest i found this method quite nice, or at least funny, but it was BEFORE GetHandleId and hashtables.

 

[Azlier]

This trigger method is faster (providing you create most of your rectwraps on map initialization). This is one of the few situations where the triggers can be recycled and thus can be attached to via TriggerExecCount in a good way.

This is faster than even H2I - 0x10000 (or whatever, I forget. Never used it.). And that method is, in turn, faster than a hashtable.

 

[Troll-Brain]

This trigger method is faster (providing you create most of your rectwraps on map initialization). This is one of the few situations where the triggers can be recycled and thus can be attached to via TriggerExecCount in a good way.

This is faster than even H2I - 0x10000 (or whatever, I forget. Never used it.). And that method is, in turn, faster than a hashtable.

I won't believe it without a benchmark.
What you say about map initialization is right, but i can't believe that's the best way to attach let's say the integer (1000) to a trigger.
But yeah with small integers it should be faster.
Ofc it will be always faster to get the data.

I were a speedfreak but not really longer know, i prefer a way which is a bit slower but always O(1), no matter situations.

 

[Azlier]

If you ever create a rectwrap with an index over 1000 (very unlikely) and not on map initialization (unlikely), any lag spike there could be is unnoticeable even on a crappy computer such as this.

>I won't believe it without a benchmark.

I do believe it's been benchmarked at some point in time. For some system. Was it KT2? Possibly.

>Ofc it will be always faster to get the data.

Aye. This is why I use the TriggerExecCount.

 

[Troll-Brain]

If you ever create a rectwrap with an index over 1000 (very unlikely) and not on map initialization (unlikely), any lag spike there could be is unnoticeable even on a crappy computer such as this.

It's quite reasonable to think that you can need 1000 rect on map initialization and few other ones more during the game.

Also, i prefer a code which is always O(1) for creating/getting the integer linked, but slower with few rects than your specific code (but the player can't see the difference between the 2 codes) against a code which is O(N) for creating an instance (even if it's hardly noticeable with 1000 rects on a crappy computer)

I do believe it's been benchmarked at some point in time. For some system. Was it KT2? Possibly.

Actually that makes sense that getting an integer natively associated to the trigger is lightning fast.
I believe you without any benchmark, i worry more about how you attach this integer.

Aye. This is why I use the TriggerExecCount.

Speed is not all.

I won't try to convince you more, i know you won't change your mind anyway.
But don't expect that it will be approved on wc3c on the current state, imho (maybe you don't really care also)

 

[Troll-Brain]

Oh and the method SetTrigData needs to be improved btw.

    private static method SetTrigData takes trigger t, integer i returns nothing
        local integer j = GetTriggerExecCount(t)
        if i < 0 then // protect dumb users from themwelves, alternatively add a static if DEBUG_MODE, if you care about one "useless" if ...
            return
        endif
        if j > i then
            call ResetTrigger(t)
            // set TriggerExec/EvalCount to 0
        else
            set i = i-j
        endif
        
        loop
            exitwhen i == 0
            call TriggerExecute(t)
            set i = i - 1
        endloop
    endmethod

And yes i definitely hate this method, because it can fuck up the user if for some reason he want to know how many times a trigger has been evaluated.
You can't attach high integers, since the limit op will be reached ...
And finally you can attach only one data for a same trigger.

EDIT : You can't even unregister the event, hence the actual version of your method SetTrigData.

 

[Azlier]

Jesus Christ. It seems like none of the creation methods other than .wrap worked properly, and in all this time nobody noticed. This has been fixed.

 

[luorax]

I did not even know about this snippet. I have to say it looks nice, I think I'm going to change my AoS movement snippet to use this.

EDIT: okay, there're things that should be fixed. For example it should require Event rather than CnP'ing it. You should also get rid of the [ljass]onDestroy[/ljass] method. Rectwrap should be an array struct, you may use Alloc.

If you fix all those things I think I'll use it.