System Enter Rect

[Azlier]

If you looked at mine, you would see that I do store the target X/Y to teleport to.

Mine uses two rectwraps and one Doorway to work. Yours uses two rectwraps and two EnterRects to work.

 

[DrEvil]

hmm
but you have a reason to store the new start/end x/y because they offset from the rect.
mine was originally like yours without all the other members in the struct , then Jesus4Lyf told me to change it and hold the tar x/y but use 2 different EnterRect's

Hmm yours uses one less EnterRect , so Jesus4Lyf told me wrong :O ?

So I should change it back ?
To storing 2 Rectwraps within one EnterRect ?

 

[Jesus4Lyf]

No, yours is better. Azlier is just lame.

Azlier, struct instance counts don't matter. They're freaking integers.
His skips the rectwrap comparison that yours has to do. So it's a little more efficient (his older comparison was more strenuous, I'll give you that). I think you should update yours to use two structs, Az.

But, instead of a 0 second timer, can't you just enable the trigger at the end? Hmm.

 

[Azlier]

Instant disabling/enabling hasn't worked in my tests.

>His skips the rectwrap comparison that yours has to do.
Mebbe I should skip the comparison. I could do that quite easily.

>Azlier, struct instance counts don't matter. They're freaking integers.
/me likes to conserve instances.

EDIT: Here we are. No rectwrap comparisons.

struct Doorway

private static constant real DOORWAY_DISTANCE = 128

private rectwrap Enter
private rectwrap Exit

private real EnX
private real EnY
private real ExX
private real ExY

private real EnAngle
private real ExAngle

private static trigger EnTrig = CreateTrigger()
private static trigger ExTrig = CreateTrigger()

private static method EnterDoor takes nothing returns boolean
    local thistype this = GetTriggeringRectwrap().userData
    local unit u = GetTriggerUnit()
    call SetUnitPosition(u, .ExX, .ExY)
    call SetUnitFacing(u, .ExAngle)
    if GetLocalPlayer() == GetOwningPlayer(u) then
        call SetCameraPosition(.ExX, .ExY)
    endif
    set u = null
    return false
endmethod

private static method ExitDoor takes nothing returns boolean
    local thistype this = GetTriggeringRectwrap().userData
    local unit u = GetTriggerUnit()
    call SetUnitPosition(u, .EnX, .EnY)
    call SetUnitFacing(u, .EnAngle)
    if GetLocalPlayer() == GetOwningPlayer(u) then
        call SetCameraPosition(.EnX, .EnY)
    endif
    set u = null
    return false
endmethod

static method create takes rect r1, real angle1, rect r2, real angle2 returns thistype
    local thistype this = thistype.allocate()
    set .Enter = rectwrap.wrap(r1)
    set .Exit = rectwrap.wrap(r2)
    call .Enter.registerEnter(.EnTrig)
    call .Exit.registerEnter(.ExTrig)
    
    set .Enter.userData = this
    set .Exit.userData = this
    
    set .EnAngle = angle1
    set .ExAngle = angle2
    
    set angle1 = angle1 * bj_DEGTORAD
    set .EnX = .Enter.cenX + .DOORWAY_DISTANCE * Cos(angle1)
    set .EnY = .Enter.cenY + .DOORWAY_DISTANCE * Sin(angle1)
    
    set angle2 = angle2 * bj_DEGTORAD
    set .ExX = .Exit.cenX + .DOORWAY_DISTANCE * Cos(angle2)
    set .ExY = .Exit.cenY + .DOORWAY_DISTANCE * Sin(angle2)
    return this
endmethod

private static method onInit takes nothing returns nothing
    call TriggerAddCondition(.EnTrig, Condition(function thistype.EnterDoor))
    call TriggerAddCondition(.ExTrig, Condition(function thistype.ExitDoor))
endmethod

endstruct

 

[Jesus4Lyf]

/me likes to conserve instances.

Why do people always push me into making unrefutable arguments?

Maybe it's a good thing.

Here's yours: For every Doorway struct, you must have two rectwraps. Therefore, you are not saving instances, since you can only ever have 8191/2 in your method anyway. In my method, you have "twice as many" but can have the full 8191. So it's the same, except mine saves code. :thup:

At very least, clearly no reason for him to change it...

 

[DrEvil]

Woot Woot !!

Jesus!!!
Jesus!!!

>/me likes to conserve instances.
Like Jesus said , you still have to use 2 rectwraps for each instance of Doorway ... what only let's you have around 4000 instances like mine.
So in all fairness , mine is better ^_^ , I can have less members to worry about and still the amount of instances you could have

 

[Azlier]

>Like Jesus said , you still have to use 2 rectwraps for each instance of Doorway ... what only let's you have around 4000 instances like mine.
So in all fairness , mine is better ^_^ , I can have less members to worry about and still the amount of instances you could have

Ah, but if you ever actually reach 4000, you only need to increase the instance limit of one of them :nuts:.

 

[DrEvil]

so would you :nuts:

 

[Jesus4Lyf]

Oh c'mon. Let him be, he's doing it well.

What you're actually suggesting is instead of having two structs, you double the number of arrays you use. Surely that's worse.

Anyway, move on... lol

 

[Romek]

So, what does this actually do?
First post would like to know.

 

[DrEvil]

I couldn't think of a clean way to explain it but..

Like you specify 2 rects ( and an integer and string for the Ex ) then when a unit enters one of them rects ,it sends the unit to the other rect ( checking level requirement ) , if he is not high enough send a message saying he is not high enough level ( or custom message )

( Bit clustery isn't it XD ? If someone could make that 'neater' that would be nice )

 

[Jesus4Lyf]

This seems quite nice.
But.

GetTriggeringRectwrap().userData

-->

thistype(GetTriggeringRectwrap())

local thistype d = thistype.allocate()
...
set start.userData = d

-->

local thistype d = thistype(start)

private struct EnterRect

-->

private struct EnterRect extends array // Removes allocate/destroy method

And move your =CreateTrigger() and stuff in your member declaration to your .create method.

I don't believe public systems should monopolise a rectwrap's userData (as I think Azlier mentioned, if I recall correctly). (This fixes it.)

 

[Azlier]

Exactly. Monopolizing user data is a terrible thing.

That integer was thrown in there for fun. You're not supposed to actually use it.

 

[DrEvil]

Thanks to Jesus for helping me write more efficient code.
+ Azlier for writing an awesome speech ( )

Updated : Map + Code

 

[Jesus4Lyf]

This is looking pretty cool, well dnoe.

I think there must be a better name for this than Enter Rect. If I was looking for a rect teleporting snippet it wouldn't occur to me to check this perhaps.

Other than that, I must now just find time to test it. :thup:

Let me know here if you'd like a rename.

 

[Azlier]

How about 'Gateway'? Or 'Waygate'? Or 'Rectangular Teleporter Thingies'?

 

[Jesus4Lyf]

... Wait, why doesn't this just use waygates? Then the pathing would work. You could always reject units that pass through based on level and entering rects.

 

[DrEvil]

Azlier... lol
Well... If you find that it would be better than ... maybe XD

 

[Jesus4Lyf]

Actually, users can add their own invisible waygate to fix pathing issues.