FilterUtils

[Bribe]

library GlobalUtils requires optional GroupUtils
    
/**
 * A small pack to save on re-creating 'private' globals of the same name again
 * and again.  The GROUP, LOCATION and WORLD_BOUNDS variables should not
 * be destroyed as they are meant to replace the need to constantly destroy /
 * re-create such variables.  I see many systems create a group, location and
 * get a world-bounds rect and they would save memory to all share from the
 * same library.
 */
    
    static if (LIBRARY_GroupUtils) then
        globals
            constant group GROUP = ENUM_GROUP
        endglobals
    else
        globals
            constant group GROUP = CreateGroup()
        endglobals
    endif // GROUP - For filters/enums which only last an instant (nearly all)
    
    globals
        constant location LOCATION = Location(0.0, 0.0) // For your GetLocationZ() needs.
    endglobals
    
    globals
        constant rect WORLD_BOUNDS = GetWorldBounds() // For your map-scanning needs.
    endglobals
    
    /**
     * The below variables are useful for instant filters and should not be expected
     * to remember data past a wait period.
     */
    
    globals
        unit global_casterUnit = null
        unit global_targetUnit = null
        unit global_filterUnit = null
    endglobals
    
    globals
        player global_player  = null
        player global_player2 = null
    endglobals
    
    globals
        real global_duration = 0.0
        real global_damage   = 0.0
        real global_x  = 0.0
        real global_y  = 0.0
        real global_x2 = 0.0
        real global_y2 = 0.0
    endglobals
    
    globals
        integer global_this  = 0 // ie. for structs
        integer global_index = 0 // ie. for loops
    endglobals
    
endlibrary

 

[kingking]

Is it good enough to be a utility?

 

[busterkomo]

We already have GroupUtils for both a global group and group recycling. What is the point of the xyz struct and the module? Just use a library initializer.

 

[YourNameHere]

We already have GroupUtils for both a global group and group recycling. What is the point of the xyz struct and the module? Just use a library initializer.

Afaik struct initializers are called before library initializers.

 

[busterkomo]

It wouldn't matter if they were.

 

[Bribe]

Module init > struct init > library init > scope init > GUI init

 

[busterkomo]

The order is irrelevant. You shouldn't be making both a module and a struct just to increase it's initialization priority.

Also, I would like to re-iterate that GroupUtils renders the global group obsolete.

 

[Bribe]

GroupUtils stupidly uses two hashtables, as well, when it only should be using one, but the guys there don't care about their own systems (see the stupid RemoveUnit hook in AutoIndex).

Having a module initializer makes it so most wouldn't technically have to type 'requires FilterUtils' as most people aren't working with modules, but rather libraries, structs and scopes.

And even if they required this library, if they have a module initializer of their own that depended on the GROUP variable and my initializer was not in a module, the GROUP variable would still not have been initialized due to JASSHelper's initialization quirks.

Updated library with two sets of coordinates and added compatibility with GroupUtils.

 

[Anachron]

I think this is to less to be useful.
Also I did something similar: CustomFilter.

 

[Bribe]

CustomFilter is nothing like this library. You may have mis-posted this, maybe meant to be in the Point thread, in relation to your 'Loc' library which is still scarcely related to the functionality of the Point library.

 

[Anachron]

Oh well, sorry, I really missread the purpose. And well yeah, this really is somehow useful, no matter how small it is.

 

[Nestharus]

since nobody has mentioned this yet..

group GROUP // for filters which only last an instant (almost all of them)

put the above variable into a struct and put a static if around it so that it is only generated if GroupUtils does not exist.

set GROUP = bj_lastCreatedGroup seems unstable since GUI could just as easily destroy that group at any point or actually use it to store units >.<. I'd just use CreateGroup()


I honestly don't find this library very useful. I only really see the need for a single global location and a single global group. The rest of the variables seem to be eh.

You could just as easily have a snippet like this

library_once GlobalUtils

struct GlobalUtils extends array
    static if not LIBRARY_GroupUtils then
        public static group group = CreateGroup()
    else
        public static group group = //group utils var >.>
    endif

    public static location location = Location(0, 0)
endstruct

endlibrary

That way all things that used it could just have it included since it'd only be like 2 vars o-o.

 

[Bribe]

Actually, GUI never destroys bj_lastCreatedGroup. Ever. A few months ago I did a search in blizzard.j to find all instances of it, such as GetLastCreatedGroup() which does not even return it but spawns a copy group of it, so if a GUI user does call DestroyGroup(GetLastCreatedGroup()) he is essentially creating a group just to destroy it.

Some of those suggestions are pretty cool, and I have updated the library with the static-if's within the globals initialization block as well as added a LOCATION variable and a WORLD_BOUNDS variable. The name FilterUtils is kind of silly for this because GroupUtils has far more filter-enhancing capabilities, anyway. GlobalUtils is a more fitting name.

 

[azlier]

An idea like this works great on paper, in reality not so much. First of all, only constant variables should have fully capitalized names. Second, it helps script readability tremendously if variables are at least somewhat descriptive of what they are used to hold.

This script removes that advantage without much in return. Sure, you save a bit memory and make your script the tiniest bit faster. But at what cost?

 

[Bribe]

You make quite a valid point. Updated the variable names to reflect non-constant values.

 

[Nestharus]

You need to put your fields into a struct or it'll always return false. Every time I've tried static ifs on globals or global blocks, they've always returned false I think? It was either that or true ; P. Then again, basing static if on library vars might merit better results. You should test it since I'm too lazy to do it ; P.

I also agree with azlier about the whole usefulness issue. Group and location only *maybe* in the script form I showed (like a little add on for libs or w/e), but ehhhh, that's iffy too.

 

[azlier]

Those last two viable uses, a global group and global location, have already been done. One is called EnumGroup unless I've gone truly mad, and GetLocationZ systems certainly exist.

Graveyarded.