[Solved] Convert Point With Size To Region, question

[Solu9]

Quick and simple question.

Will the event "Convert Point With Size To Region" leak more than the point? Fx; region leak of some sort?

 

[Bannar]

Is there such event in the game? Locations do leak, so do regions.

 

[Solu9]

I would not ask the question if there were no such event. (yeah...)

So by creating a region this way do I need to set it to a variable? Can it be removed entirely again? Can I move said region without problems?

 

[sethmachine]

Edit: What is the name of this function? I searched the JASS manual and only found four functions which return a region.

native CreateRegion () returns region
constant native GetTriggeringRegion () returns region
native LoadRegionHandle (hashtable table, integer parentKey, integer childKey) returns region
function LoadRegionHandleBJ (integer key, integer missionKey, hashtable table) returns region

Or did you mean a rect and not a region?

function RectFromCenterSizeBJ (location center, real width, real height) returns rect
native RectFromLoc (location min, location max) returns rect

Locations do leak, so do regions.

Sorry what do you mean by locations and regions leaking?

AFAIK there are two natives for deallocating points and regions.

RemoveLocation and RemoveRegion. Are you saying these actually don't work?

This tutorial (http://www.hiveworkshop.com/forums/trigger-gui-editor-tutorials-279/basic-memory-leaks-5889/) suggests that locations and regions don't leak.

Now, let's say we want to create a footman at the center of playable map area. If we didn't care about memory leaks, we would do it like this:
Unit - Create 1 Footman for (Player 1 - Red) at (center of (playable map area)) facing 0.00 degrees

However, the (center of (playable map area)) creates a location object at which the footman is then created, and this location then "leaks" because we can't remove it, because there's no way to know where in memory it is. We avoid this leak like this:
Set tempPoint = (center of (playable map area))
Unit - Create 1 Footman for (Player 1 - Red) at tempPoint facing 0.00 degrees
Custom script:
call RemoveLocation( udg_tempPoint )

Or is that information outdated?

 

[Bannar]

Nope. Why do we say that handles "leak"? What does it mean? Seems that you missed the point, missunderstood me or lack knowledge about that subject.

As long as handle is required for your stuff to work, it's usefull - we dont want to destroy it. However, everything has it's end, and with it, the memory should be cleared to free space of not used handle.
Thus, spawning unit via CreateUnitAtLoc(Player(0), 'hfoo', Location(0,0), 0) creates a location handle leak - we required location for short period, yet we havent destroyed it because we lack reference to such. If we can not track it and destroy it, that handle will occupy memory untill game ends.

We don't really want that. Proper solution would involve storing Location(0,0) followed by CreateUnitAtLoc and then RemoveLocation.

Btw, those are not "events". @Solu9, what event do you mean exactly?

 

[IcemanBo]

@Solu9,
You only will leak one location for your event. So don't worry. The function takes the location as argument and then just returns the rect you need.

 

[Solu9]

Perhaps I should have been clearer:
Events -A unit enters (Region [conversion - convert point with size to region])*

*Region centered at Point with size (Width , Height)

@sethmachine: Yes the point will definitely leak. But I'm am not familiar with the issues with the region which is created based on the point. Hence my initial question.

Edit: Bannar, IcemanBo posted inbetween

 

[sethmachine]

Nope. Why do we say that handles "leak"? What does it mean? Seems that you missed the point, missunderstood me or lack knowledge about that subject.

I know what leaks are and I did not misunderstand. Locations and rects do not leak, unlike strings, which can't ever be deallocated. Of course if a function returns a handle but it is not stored in a variable that can be later be destroyed.

I believe we may be operating with different definitions of the verb leak. It is obvious that any handle won't be deallocated unless done explicitly by a corresponding remove/destroy native. If something leaks the programmer forgot to deallocate / destroy the object, or the object can't be deallocated (like strings).

Saying that they leak without any context (OP did not provide an example) suggested to me that locations / regions can't be deallocated and permanently increase the memory usage of WC3 each time they are created.

@Solu9 It looks like you are calling this function,

function RectFromCenterSizeBJ (location center, real width, real height) returns rect.

So you probably would need to cache the rect it returns to avoid it leaking. I don't think it leaks a point since it takes that as an argument. You'd just have to pass in a pre-defined point.

Btw, those are not "events". @Solu9, what event do you mean exactly?

Yes this needs clarification. You are just using the event type for entering a region, and then creating the region in question by a function that returns a region / rect. The function that takes a point/width/height and returns a rect isn't an event, it's just a function. The output is produces, however, is part of the enter / leave region event.

 

[Bannar]

@sethmachine - "Convert Point With Size To Region" is not a native event of any sort in war3. Now that Solu9 specified that it is related to "UnitEnter/Leave" stuff, we can talk.
And yes, I have said "the loc/region handles do leak" in case I was speaking of situation when you leave those free, regardless if you need them or not.

• Events
  • Unit - A unit enters (Region centered at (Point(0.00, 0.00)) with size (0.00, 0.00))

Outputs:

call TriggerRegisterEnterRectSimple( <trigger>, RectFromCenterSizeBJ(Location(0, 0), 0.00, 0.00) )

// BJ wrapper:
function RectFromCenterSizeBJ takes location center, real width, real height returns rect
    local real x = GetLocationX( center )
    local real y = GetLocationY( center )
    return Rect( x - width*0.5, y - height*0.5, x + width*0.5, y + height*0.5 )
endfunction

Thus as stated by IcemanBo, you will create one Location handle leak. It's one-time operation, thats why you don't really need to worry about that.

If you want to avoid leak tho, you can use native native TriggerRegisterEnterRegion takes trigger whichTrigger, region whichRegion, boolexpr filter returns event.

 

[Solu9]

Hmm. About the point leak.
The point used to define the region will not stay static. It will actually be set multiple times. So if it leaks a point every time I think I need to remove it.
But that I know how to do.

I'm more concerned with the region that is created based on the point. Because I don't know how the game handles that.

 

[sethmachine]

@sethmachine - "Convert Point With Size To Region" is not a native event of any sort in war3

I'm not sure where I ever claimed it was a native function, or a native event (whatever that means).

In fact I never mention "native event" once, it's only found on your post.

Edit: Further, I never event mention "event" except in reference to the OP. Nor do I ever call it an event or a native, actually. Read this.

The function that takes a point/width/height and returns a rect isn't an event, it's just a function.

Please read carefully what I post before making inaccurate comments.

I never called it an event, or a native event. Either wouldn't' make any sense--how can a function be an event, either in the semantics of WC3's use of event or the event type itself. Give me more credit than that.

In any case the confusion was in the OP where the whole expression was called an event, when the OP was actually asking about a subpart of the expression that returned a rect/region (the function in question).

 

[edo494]

you are nitpicking ONE word. You should reconsider your life ...

 

[Dr Super Good]

Regions have no relationship with the rects they are made from. As such moving the rect will not automatically update the region. To update the region you need to clear the rect area of all rects you are going to move (before they are moved) and then add all rects to it that were moved (after they are moved). I do not know how it behaves as far as regions moving over units and the appropriate events.

Rects, like most objects in WC3, are prone to leaking. There is no automatic garbage collector so if you lose the reference to a rect permanently the rect will remain in memory for the rest of the map session. Like locations, groups and forces, you can destroy the object before losing all references to it and so not leak.

native RemoveRect takes rect whichRect returns nothing

Dynamically created rects are mostly used for unit searches as they represent a rectangular grid aligned scope unlike the in range search which is circular. They are also convenient ways to modify regions but since regions are not available in GUI at all (GUI cannot touch them directly) this obviously is only the case for some JASS systems.

In StarCraft II regions are done completely differently. There is no concept of a "rect" object and instead you write square and circular areas to regions directly. A region can consist of any number of these primitive shapes. You also have exclusion primitives of the same shapes which will mask the area they represent allowing the creation of complex shapes. All regions have an origin and all positioning is done relative to this. Regions can be moved and all attached primitives will be moved respectively. It is not possible to remove primitives once attached. It is not possible to cancel out an exclusion primitive once applied. Some natives have a chance of failure with complex shapes. You can attach regions to both locations and units and they will automatically track the position of these objects on the map. Region related events will track the regions current position. Regions are automatically garbage collected when no references exist.

 

[Vinz]

Here comes DSG telling us how good the SC2 Editor is compared to WC3's.

jk

 

[Solu9]

Here comes DSG telling us how good the SC2 Editor is compared to WC3's.

jk

If you have nothing constructive to stay then don't say anything.

On topic.
I've found another way to achieve what I wanted. Thanks IcemanBo.
This thread can be closed.