Your opinion about IsPointWalkableForSize

[ZiBitheWand3r3r]

Hi, what do you think about submiting at spell section this code. It is based on PurgeandFire / Quilnez work.
If it will be allowed I vote to remove this

// IsPointWalkable ver 1.00  /by zibithewand3r3r/
// based on PathingLib v1.5 by Quilnez, idea by PurgeandFire
//
// Allows to check if given point is walkable for 3 diffrent collision sizes (16,32,64)
// function IsPointWalkableForSize(real x, real y, integer size) returns boolean
// use 16 or 32 or 64 numbers as 'size' parameter
// if you pass number other than those mentioned above, function will check for 64 collision size
//
// It uses 4 custom units:
// DUMMY_CHECKER (as a builder) and three WALK_CHECKERs with diffrent collision sizes
// c&p custom units, be sure DUMMY_CHECKER can build 3 other units in ObjectEditor
// set their raw codes at Init function

library IsPointWalkable initializer Init
    globals
        private integer DUMMY_CHECKER
        private integer array WALK_CHECKER
        private unit PathChecker
    endglobals
    
    function IsPointWalkableForSize takes real x, real y, integer size returns boolean
        if WALK_CHECKER[size] != null then
            return IssueBuildOrderById(PathChecker, WALK_CHECKER[size], x, y)
        else
            return IssueBuildOrderById(PathChecker, WALK_CHECKER[64], x, y) // check anyway
            debug call BJDebugMsg("Wrong parameter passed to function IsPointWalkableForSize. Use 16 or 32 or 64.")
        endif
        return false
    endfunction

    private function Init takes nothing returns nothing
        //--- CONFIGURATION --- set raw codes of units:
        set DUMMY_CHECKER = 'h000' // dummy path checker
        set WALK_CHECKER[16] = 'o000' // path checker peon
        set WALK_CHECKER[32]  = 'o001' // path checker grunt
        set WALK_CHECKER[64]  = 'o002' // path checker tauren
        set PathChecker = CreateUnit(Player(15), DUMMY_CHECKER, 0, 0, 0)
        call UnitRemoveAbility(PathChecker, 'Amov') //remove move
        call ShowUnit(PathChecker, false)
        if GetLocalPlayer() == Player(15) then
            call FogEnable(false)
        endif
    endfunction
endlibrary

 

[BPower]

Moved to The Lab.

 

[Bribe]

Blink doesn't work like you'd think it should. Regardless of collision size, a unit can never blink into deep water even if it has the "amphibious" movement type. It "may" consider collision size, but I never went that route due to the enter-region event spam.

The "build" method is flawed because the unit you are trying to check pathing for is going to prevent that order from executing.

The method I use in Knockback 2.5D is about as bug-free as this stuff can get.

 

[Kazeon]

The "build" method is flawed because the unit you are trying to check pathing for is going to prevent that order from executing.

The approach is not flawed at all. Instead it's proven to be very powerful for massive uses in map making, in certain cases of course.

It's very possible to ignore ground unit's pathing actually. Since basically it has the same flaw (if you call it so) as the item method, they need to hide all items/units around before check. All I need is to hide all ground units around before issuing the order (path checking). It's just going to be a lil bit slower since units may have larger collision size than item, so there could be more units to hide or unhide. That's why I was not adding this feature right away. I think it's better to have second walkability checker in the map.

 

[Bribe]

It is a lot worse to hide units than items. Units will try to find a new target if their current one is hidden even for that instant. The HideUnit native searches the list of units targeting it which can cause them to find a new target. It's very disruptive when you see it in action.

Item postion checking does not require units to be hidden. Only items. Since this method also requires items to be hidden, it has no advantage over the item spread I use in K2.5D.

 

[Kazeon]

How about moving those units to other place instead of hiding them?

 

[Bribe]

Then you have to worry about enter/leave region events firing. Maybe aura effects as well. The item method works fine when you check the circular area around the destination to fill the volume if the collision size.

 

[Kazeon]

How about hiding items? Wouldn't all units which is targeting the item be ordered to stop as well?

 

[ZiBitheWand3r3r]

Why hide units at all as a first??

If there is unit in checked location that means you cannot place there another unit.
If you do with SetUnitX/Y, game will correct it after a moment. Maybe function name is a little confusing: IsPointFreeForSize or someth like that would be better?

Build method counts as a blockers units, structures, destructables, terrain(cliffs/deep water). Excactly like in-game you cannot reach those points blocked by listed above. So build-method simulates in-game behavior in my understanding.

Item-method shows point where is a unit as a "walkable" but point where is a tower "not-walkable": inconsistency, when unit/structure dies both points becomes "walkable" (assuming building has normal pathing)
Bribe, instead of 6 item-calls wouldnt it be better to use one build-method check (+ possible one item-check call).
like if buildCheck32size == false and itemCheck == true then
that means point walkable but there's other unit there, I just though about merging both methods..

If we reach an agreement here could you upgrade your PathingLib Quilnez? Would be better to have it in one library.

 

[Kazeon]

If there's legit way to upgrade the PathingLib I will obviously do it already. But every time I thought about this, it always came that using two walkability checker is better. If user don't want to involve ground units, they can use PnF's checker. Else they can use PathingLib.