• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Question: Would These Regions Need to be Removed?

Status
Not open for further replies.
Level 2
Joined
Oct 28, 2010
Messages
14
If you wish for me to post my code, I'll do so at a later time (currently on a different computer than my WCIII Editor, so it might take some time).

Anyway, so here is my scenario:

1. I have this unit (let's call it X [and the unit is assigned to a variable]) that will go into a region to trigger an event.

2. After the unit enters this region, it will be ordered to stop, teleport instantly to the center of the aforementioned region, and will be removed from the game shortly afterwards.

3. Afterwards, a new unit (called Y) will spawn at the center of another region, and 4 new units will spawn around unit Y (top, bottom, left, and right of it).

4. These 4 new units will also be assigned to variables and be told to move to 4 specified regions for each one of them, individually. After that, the player user will be able to move around with unit Y, attack the newly spawned units, etc.

HOWEVER, the regions that I spoke about (concerning the region that unit X enters, unit Y spawns at, and the 4 new units that I talked about) will be used over again if the player decides that he had enough time with unit Y and decides to spawn unit X again. In that case, would it be necessary to destroy these regions through custom scripts, or can I leave them as is?

Because basically, if the player decides to move unit X back to the region that started this whole clusterfuck, it will do exactly as stated above over again (but it will remove any units that are left, if any, but everything else, from spawning unit Y again to having 4 new units spawn and move to their respective regions, would be left intact).

If this is all too confusing, I'll post a pic of my trigger later on about what I did. Don't worry, it's not too messy (I hope). :ogre_haosis:
 
Level 21
Joined
Mar 27, 2012
Messages
3,232
The regions that you make in region editor don't leak unless you somehow generate them mid-game. They are called rects.

The ones that can leak are actual regions (the JASS type). Those can leak, since the GUI regions might be turned to those depending on use.
 
Level 2
Joined
Oct 28, 2010
Messages
14
The regions that you make in region editor don't leak unless you somehow generate them mid-game. They are called rects.

The ones that can leak are actual regions (the JASS type). Those can leak, since the GUI regions might be turned to those depending on use.

Thanks for the clarification.

As for assigning my units to their respective variables, would "removing" the unit kill the variable unit and make the variable = null, or would I need to call upon custom scripts to remove the variables themselves?
 
Level 21
Joined
Mar 27, 2012
Messages
3,232
Thanks for the clarification.

As for assigning my units to their respective variables, would "removing" the unit kill the variable unit and make the variable = null, or would I need to call upon custom scripts to remove the variables themselves?

I feel I didn't say enough about regions vs rects.

The GUI native for entering a region(rect) actually does create a region, as seen here:
JASS:
function TriggerRegisterEnterRectSimple takes trigger trig, rect r returns event
    local region rectRegion = CreateRegion()
    call RegionAddRect(rectRegion, r)
    return TriggerRegisterEnterRegion(trig, rectRegion, null)
endfunction

However, avoiding this leak is not possible without JASS, because you can't access the actual event in GUI.

Every unit has some kind of an ID to distinguish it from others. The unit variable stores this and doesn't empty automatically. This is useful, because you can do something like:

JASS:
if UnitType(MyUnit) == null then
    //do stuff
endif

Null means "No unit type" in this case, so this pseudocode snippet essentially checks if a unit has been removed from the game (only then can the unit be of no type)

If variables auto-cleared, then many such used would be impossible.
So yes, the variable will stay whatever it was.
But does it need to be cleared? That depends on your use. It doesn't generate leaks, because the variable is there anyway.
However, depending on use it might cause other problems.

For instance, in my map I have an integer array where I write the lifesteal of every unit that has it. When one of the units dies, then a new one might take its slot and thus, inherit the lifesteal. In such cases it has to be nulled/defaulted to prevent bugs.
 
Level 12
Joined
Feb 22, 2010
Messages
1,115
The GUI native for entering a region(rect) actually does create a region, as seen here:
JASS:
function TriggerRegisterEnterRectSimple takes trigger trig, rect r returns event
    local region rectRegion = CreateRegion()
    call RegionAddRect(rectRegion, r)
    return TriggerRegisterEnterRegion(trig, rectRegion, null)
endfunction

However, avoiding this leak is not possible without JASS, because you can't access the actual event in GUI.

You won't going to destroy that region anyway.
 
Status
Not open for further replies.
Top