RegionAddRect ~ Warcraft III Fatal Error

[Berb]

I was addressing a bug that Bribe brought to my attention and in trying to establish a method of determining whether or not a unit has been removed (unitVar == null is not accurate) I was trying to add the entire world-bounds to a region so that it could be evaluated whether the unit in question is in that region (if not then it has been removed from the game).

call RegionAddRect(someGlobalRegion, GetWorldBounds())
call RegionAddRect(someGlobalRegion, bj_mapInitialPlayableArea)

The above lines of code cause fatal errors, just thought (if it is not already known) that someone would find this information valuable.

 

[Deaod]

Better way to check if a unit has been removed from the game is to check the units type ID against 0.

But thats an interesting crash. Does the line with GetWorldBounds() suffice to crash WC3?

 

[Berb]

I completely forgot about the GetUnitTypeId() == 0 check - it is because sometimes when units are removed they are still equal to null, yet all of their properties are nullified.

Does the line with GetWorldBounds() suffice to crash WC3?

Either of those two lines crashes Warcraft III.

 

[Anachron]

The reason why it crashes the game is that GetWorldBounds() and bj_mapInitialPlayableArea both refer to an always-updating variable. (bj_mapInitialPlayableArea is just a link to, it's not the real variable)

The primary reason was to be able to change the map size ingame, however, this has never been fully implemented.

While refering to a dynamic variable (Such as the units life, which is in fact a variable too) it will add that rect to the region. Then the rect gets updated and the region has invalid data.

If you really want to check whether an unit has been removed, you can check its handle id too (GetHandleId(unit)) AFAIK.

 

[Bribe]

GetHandleId() == 0 will be just as unreliable as unit == null because the variable will always point to the handle id until it is directly set to 'null'. Part of the joy of Blizzard's wild ideas.

 

[Anachron]

Oh well that's bad, I thought they fixed it with one of the latest patches.

 

[Bribe]

Has someone compiled a list of the stupidest things that can happen with JASS? I once saw Vexorian write something which had to do with the $ character escaping strings.

 

[Anachron]

You mean this?

 

[Bribe]

I wonder how current those bugs are. There are weird ones, such as the game compiling 'this' type of rawcode of only size 1 or 4 (the rest throwing syntax errors... you would think you could get away with 2 and 3 as well, but no, it's just 1 or 4.), the stupid way strings are stored into a table causing leak throughout the game, the way chat messages leak until you press F12... the list is long... far longer than that thread.

 

[Berb]

While refering to a dynamic variable (Such as the units life, which is in fact a variable too) it will add that rect to the region. Then the rect gets updated and the region has invalid data.

Except if you add a rect to a region and then remove that rect from the game the region still operates properly.

Look more closely; this:

• Untitled Trigger 001
  • Events
    • Unit - A unit enters (Entire map)
  • Conditions
  • Actions

Translates to:

//===========================================================================
function InitTrig_Untitled_Trigger_001 takes nothing returns nothing
    set gg_trg_Untitled_Trigger_001 = CreateTrigger(  )
    call TriggerRegisterEnterRectSimple( gg_trg_Untitled_Trigger_001, GetEntireMapRect() )
    call TriggerAddAction( gg_trg_Untitled_Trigger_001, function Trig_Untitled_Trigger_001_Actions )
endfunction

The GUI trigger uses TriggerRegisterEnterRectSimple. This translates to:

function TriggerRegisterEnterRectSimple takes trigger trig, rect r returns event
    local region rectRegion = CreateRegion()
    call RegionAddRect(rectRegion, r)
    return TriggerRegisterEnterRegion(trig, rectRegion, null)
endfunction

Now look again at the first block of JASS code; it contains GetEntireMapRect(). This looks like:

function GetEntireMapRect takes nothing returns rect
    return GetWorldBounds()
endfunction

Now if you break it down this performs:

local region rectRegion = CreateRegion()
call RegionAddRect(rectRegion, GetWorldBounds())
call TriggerRegisterEnterRegion(trig, rectRegion, null)

For some reason this works fine. I think there might be something else to it.

The reason why it crashes the game is that GetWorldBounds() and bj_mapInitialPlayableArea both refer to an always-updating variable. (bj_mapInitialPlayableArea is just a link to, it's not the real variable)

So I guess none of what you said here is correct either, or else the GUI would crash Warcraft III.

Okay, after further speculation it is not actually the execution of the code that makes it crash. I'll show you what I've got:

UnitExists Library

library UnitExists initializer init
 globals
    // Config 
    // ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
    private     region      gameBounds      = CreateRegion()
 
 endglobals

 function UnitExists takes unit whichUnit returns boolean
    return IsUnitInRegion(gameBounds, whichUnit)
 
 endfunction
 
 // Initialization
 // ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
 public function init takes nothing returns nothing
    call RegionAddRect(gameBounds, GetWorldBounds())
 
 endfunction
 
endlibrary

The reason it's causing the game to crash is because CreateRegion() is in the global-declaration block instead of in the initializer. When the constructor is placed in the initializer function the game ceases to crash. I could have sworn that it wasn't working the same way initially, but it seems to be now so I'll just assume I'm a little bit crazy.

Anachron what was all that about GetWorldBounds() and bj_mapInitialPlayableArea being "dynamic" entities; they are completely static the entire game, as are all rects.

 

[Anachron]

remove that rect from the game the region still operates properly.

I can't see where it is removed?

 

[Berb]

I don't actually do that in any of this code, I know that from personal experience though. I know you'll want proof, so here:

UnitExists Modified

library UnitExists initializer init
 globals
    // Config 
    // ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
    private     region      gameBounds      //= CreateRegion()
 
 endglobals

 function UnitExists takes unit whichUnit returns boolean
    return IsUnitInRegion(gameBounds, whichUnit)
 
 endfunction
 
 // Initialization
 // ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
 public function init takes nothing returns nothing
    local rect worldBounds = GetWorldBounds()
    local rect r = Rect(GetRectMinX(worldBounds), GetRectMinY(worldBounds), /*
                        */ GetRectMaxX(worldBounds), GetRectMaxY(worldBounds))
        set gameBounds = CreateRegion()
        call RegionAddRect(gameBounds, r)
        call RemoveRect(r)
        set r = null
        set worldBounds = null
        
 endfunction
 
endlibrary

This works properly, despite r being removed after it is added to gameBounds.

 

[Anachron]

You are creating your own rect which has static x/y values, so you don't need to wonder why it works.

 

[Bribe]

GetWorldBounds() returns a static rect just like any. If the world bounds somehow changed, the next time GetWorldBounds() is called would reflect that change, but no existing World Bounds rects.

RegionAddRect does something internally to the region so it no longer needs the rect, and it can then be safely removed. Even SetRect after the RegionAddRect call should not affect the size of the region because of the way it works.

Then again, that's logical thinking.

 

[Berb]

Where are you getting this information from Anachron.

 

[Anachron]

GetWorldBounds() returns a static rect just like any. If the world bounds somehow changed, the next time GetWorldBounds() is called would reflect that change, but no existing World Bounds rects.

Then why does GetWorldBounds() == GetWorldBounds() always fail?

Where are you getting this information from Anachron.

I once had a friend whos dad was working on blizzard, and I was asking him if he could do me a favor and tell me why the world bounds are so bugged.
And that's the answer I got.

 

[Bribe]

>> Then why does GetWorldBounds() == GetWorldBounds() always fail?

It returns a new rect every time, that's why I said "If the world bounds somehow changed, the next time GetWorldBounds() is called would reflect that change, but no existing World Bounds rects".

 

[Anachron]

Well that's interesting. I am keeping an eye on it. Maybe it's abuseable.

 

[Berb]

I once had a friend whos dad was working on blizzard, and I was asking him if he could do me a favor and tell me why the world bounds are so bugged.
And that's the answer I got.

The native GetWorldBounds returns a new rect each time it is referenced. This means that if you define a new rect as newRect = GetWorldBounds() you can destroy it without hindering the reference of GetWorldBounds - if it is used twice it will return two separate, unassociated rects. This is why GetWorldBounds() != GetWorldBounds().

There is nothing buggy about GetWorldBounds(), so I really don't know what you're talking about. It makes it hard to believe this friend of yours is connected to Blizzard Entertainment in any way, I mean you got a response to a non-existent problem. There is no bug with GetWorldBounds(), so I'm curious as to where exactly this answer came from.

 

[Anachron]

The native GetWorldBounds returns a new rect each time it is referenced. This means that if you define a new rect as newRect = GetWorldBounds() you can destroy it without hindering the reference of GetWorldBounds - if it is used twice it will return two separate, unassociated rects. This is why GetWorldBounds() != GetWorldBounds().

There is nothing buggy about GetWorldBounds(), so I really don't know what you're talking about. It makes it hard to believe this friend of yours is connected to Blizzard Entertainment in any way, I mean you got a response to a non-existent problem. There is no bug with GetWorldBounds(), so I'm curious as to where exactly this answer came from.

Yes, I am really confused about it as well, maybe he was just a wanna-be?

 

[Deaod]

Guys, this isnt some complicated thing.
Check the fucken type ID of a unit against 0 to determine if a unit handle is still valid.

You could also try to modify the unit's custom value; If you cant modify it (GetUnitUserData always returns 0), the unit has been removed.

You dont need rects or anything complex like that.

 

[Berb]

Check the fucken type ID of a unit against 0 to determine if a unit handle is still valid.

I am already doing that, it was updated hours ago - you can see the results in my Projectile library submission thread. Discussion kind of just lingered on as irrelevant input was conversed upon.

You dont need rects or anything complex like that.

They're not really complex, but doing GetUnitTypeId() is a lot quicker than determining if a unit is in a region; this is the reason that I use that simple method rather than this bloated one.