PathingLib v1.6

[Moderator]

11:40, 10th Mar 2015
IcemanBo: The system works very nicely and can be very useful. Good job.

 

[Tal'Rarity]

Could you write a small description explaining your system?

 

[edo494]

description is provided in the jass resource already.

I like the overall description quite a lot actually.

Cant really rate the algorithm, but I guess it works correctly, assuming you tested it.

One last thing to mention is you could mention to copy the units from the map, but that is not really required, since most people will understand that if it says 'h000' and 'n000' than it most likely is implicit, kind of.

 

[Tal'Rarity]

That requires me to actually read the JASS though... =(

Though what I really wanted to know is what is the point of this system?

 

[Faith]

The point of the system is to enable you to check not only if the terrain is walkable, but if it's buildable, pathable for air units, etc.
There are also combinations, the 'colors' are results of things being, for example, both walkable AND buildable.

Now I'm not the best with vJASS but I'm basing this off of what I remember when I was working with pathability before, and I had looked up a few resources.

 

[Kazeon]

Updated. It's completely accurate now. Glitch on water has been fixed as well. Enjoy.

 

[Celaquil]

Opening test.

 

[Kazeon]

OMG. I'm so excited to release this update. It's not only much faster due to its new approach (big thanks to PurgeandFire), but it also allows you to check flyability and buildability as well. And it's no longer depending on IsTerrainWalkable library by Vex. It has its own function which is faster than before. Enjoy!!!

 

[IcemanBo]

UNUSED_PLAYER is not the best name in my eyes.
System works very good, I like it much.

Approved.

 

[Almia]

What did I just saw ?

 

[Kazeon]

What did I just saw ?

What did you see? :O

 

[MoCo]

Hey Quilnez, this seems to be a great system - thanks for this.

 

[Kazeon]

Hey Quilnez, this seems to be a great system - thanks for this.

Hey, thanks! And you are welcome! Well, this is nothing without PnF's idea

 

[Pinzu]

How would one go about detecting if and which building is causing unwalkable?

 

[edo494]

group enum units in the place that the tile is unwalkable, that will give you exact unit, if any(if none, its some kind of destructable)

 

[Pinzu]

group enum units in the place that the tile is unwalkable, that will give you exact unit, if any(if none, its some kind of destructable)

I thought so too, but the Building has to be in the center of the search area, it doesn't pick up corners so to speak.

 

[Kazeon]

Updated with the following changes:

• Renamed to "Pathing Library" or in short "PathingLib"
• Improved documentations
• Global vision is no longer given to dummy player
• Improved object editor data:
  • Added locust to dummy units
  • Dummy units are moved to Other-Special category for better look
  • Removed pathing map from Build Checker, improved accuracy, supposedly
• And some others

 

[BPower]

This is a nice way to detect pathing.

 

[TKF]

Excellent supplement for projectile systems and for other useful systems where you need to identify different pathings from apart.

 

[BPower]

How sensitive is IsTerrainWalkable? For better understanding the word sensitive is used
to describe a true positive result.

In other words, what is the closest point to an unwalkable point returning IsWalkable?
If I remember correctly the minimum collision size was something like 8.
Let's say (0,0) is not walkable. Will IsTerrainWalkable(1, 0) return true or false?
Or is the closest point (9, 0)?

 

[Nestharus]

I'd drop

function GetTerrainPathingColor takes real x, real y returns integer

and all of your coloring stuff. That stuff isn't necessary ; ). The same can be accomplished with an external lib at no extra cost with more specificity to the problem.


To support vexorian's JassHelper, you should be using a module initializer instead of the regular initializer. By using the regular initializer, a general public resource (at least one I write) can't use this.

I have taken the opportunity to edit the script and give some more specific comments within the script itself.

library PathingLib
    
    // Configuration
    
        globals
        
            private constant integer PATH_CHECKER  = 'h000'
            private constant integer FLY_CHECKER   = 'h001'
            private constant integer WALK_CHECKER  = 'h002'
            private constant integer BUILD_CHECKER = 'h003'
            
            private constant player  DUMMY_PLAYER  = Player(15)
            
        endglobals
    
    /*
    
                Pathing Library v1.4
                ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
                        by: Quilnez aka Dalvengyr
        
        
        Description
        ¯¯¯¯¯¯¯¯¯¯¯
            This library allows you to detect all pathability types:
            walkablility, flyability, and buildability.
            
            Warning!
            Please keep informed that this system is more sensitive than
            any other walkability checker systems out there, as it also
            detects pathing map generated by normal units as well.
            
            (You can check your pathing map by pressing 'p' at terrain editor.)
            
            
        API
        ¯¯¯

            // this is difficult to read with the description coming before the function
            // normally the functions are listed with tabbed descriptions. This is common in
            // all forms of professional documentation.
            1. Used for checking certain point's flyability
            
                | function IsTerrainFlyable takes real x, real y returns boolean
                
                
            2. Used for checking certain point's walkability.
            
                | function IsTerrainWalkable takes real x, real y returns boolean
                
                
            3. Used for checking certain point's buildability.
            
                | function IsTerrainBuildable takes real x, real y returns boolean
                    
                    
        How to import
        ¯¯¯¯¯¯¯¯¯¯¯¯¯
            - Copy Fly, Walk, Build, and Path Checker (units) at object editor.
            - Make sure Path Checker is able to build Fly, Walk, and Build Checker
              (at object editor>unit>Path Checker>"Techtree - Structures built")
            - Configure this system (available above).
                    
                    
        Credits
        ¯¯¯¯¯¯¯
            - PurgeandFire for pathability checking method.
            - TheHelper.net for complete pathing types tutorial.
                    
                    
        Link
        ¯¯¯¯
            hiveworkshop.com/forums/spells-569/pathing-type-v1-2-a-263230/
    
    */
    
    globals

        // should be pathChecker
        private unit PathChecker

    endglobals
    
    function IsTerrainFlyable takes real x, real y returns boolean
        return IssueBuildOrderById(PathChecker, FLY_CHECKER, x, y)
    endfunction
    
    function IsTerrainWalkable takes real x, real y returns boolean
        return IssueBuildOrderById(PathChecker, WALK_CHECKER, x, y)
    endfunction
    
    function IsTerrainBuildable takes real x, real y returns boolean
        return IssueBuildOrderById(PathChecker, BUILD_CHECKER, x, y)
    endfunction

    // Init library here if this is ugly -> github.com/nestharus/JASS/blob/master/jass/Systems/Init/script.j
    private module Init
        private static method onInit takes nothing returns nothing
            call init()
        endmethod
    endmodule

    private struct InitStruct extends array
        private static method init takes nothing returns nothing
    
            // should disable whatever Unit Indexing library before creating this unit

            set PathChecker = CreateUnit(DUMMY_PLAYER, PATH_CHECKER, 0, 0, 0)
            call UnitRemoveAbility(PathChecker, 'Amov')
            call ShowUnit(PathChecker, false)

            // is this line necessary? I really don't know.
            if GetLocalPlayer() == DUMMY_PLAYER then
                call FogEnable(false)
            endif
        
        endmethod

        implement Init
    endstruct
    
endlibrary

I also recommend that, if there is a unit indexing library involved, you disable the unit indexer when creating your unit : ).

You might also want to do 3 methods of installation.

Method 1: Copy objects
Method 2: Run object merger script
Method 3: Run installation script (dynamic, see my Lua stuff on github under JASS)



Also, having "cool" bonus functionality is not a good thing : P.


I'm only critiquing this harshly because I think it should be used as the standard pathing library. It's better than mine too : ).

https://github.com/nestharus/JASS/blob/master/jass/Systems/IsPathable/script.j


In order to really be used as a core standard, it needs to have very tight code (minimal features), it needs to work with as many resources as possible (things like module initializers), and it needs to have as many methods of installation as possible for compatibility (by Lua, by inline, by copy).



For now, I personally rate this a 4/5. Let's bring it to a perfect score ^)^.

 

[edo494]

while I dont take your opinion out, you are almost like Nazi. "Making it the standard"
a.) You are not really in position to call things standards, we are not coding for you, but for the comunity
b.) nowhere did he say he wants this to become clear standard smashing everything to ground from now on.

Forms of instalation, I dont think copy pasting 2 things from one map to another is really an issue, dont forget LUA doesnt work for everyone

Also on the color, while it is extra stuff, it is still strongly related, therefore I see why it could be in the core of this system instead of new independant resource, mainly because having 50 lines resources that can be inlined into the original thing are just plain annoying and retarded(look at your shitty tables you had here). Modularity is nice thing, but having 10 line resources is just, as I said, plain retarded, mainly because there is no good way to pull scripts from internet into JassHelper, yet

 

[BPower]

while I dont take your opinion out, you are almost like Nazi. "Making it the standard"

Quite inappropriate.

I agree on covering a disable call for a possible unit indexer tool.
Module initializers is (sadly) a must have in every resource, which should be accessible from other resources.

You can do the LUA thing, it's not a must have for only few objects (my opinion).

 

[Kazeon]

How sensitive is IsTerrainWalkable? For better understanding the word sensitive is used
to describe a true positive result.

In other words, what is the closest point to an unwalkable point returning IsWalkable?
If I remember correctly the minimum collision size was something like 8.
Let's say (0,0) is not walkable. Will IsTerrainWalkable(1, 0) return true or false?
Or is the closest point (9, 0)?

I think this is perfectly precise, theoritically. Since I'm using 0 collision size for every checker unit, but thanks God they are still able to check pathability.

@Nestharus:
Your post is so long to quote.

But I would like to ask you, why you love to separate every little thing? Alright the color feature is just useful in some rare cases but still, it's just some lines of codes, how terrible can it be?

I could fix the initializer thing tho, I never knew the issue behind that method before.

And sorry for the late response, I didn't really check my resources lately.

 

[BPower]

Last time I tried this together with my missile library, it was too sensitive.
For example I the terrain was not pathable when firing a missile, because it detected the
shooters collision.

Apart from that this is really useful

 

[Kazeon]

Yeah, it detects pathing map generated by normal units as well, unlike PnF's. That's why I call it "sensitive". I couldn't use this in my spell either because of that.

 

[Pinzu]

Yeah, it detects pathing map generated by normal units as well, unlike PnF's. That's why I call it "sensitive". I couldn't use this in my spell either because of that.

Suggestion: Maybe removing the collisions of all units in the search area and then setting it back would work?

 

[Kazeon]

Suggestion: Maybe removing the collisions of all units in the search area and then setting it back would work?

Sorry for late reply. No it won't work. Disabling unit collision doesn't remove the pathing map.

 

[Nestharus]

Someone else uses the Blink ability.

 

[Kazeon]

Someone else uses the Blink ability.

That approach could be better Maybe it will ignore pathing map by units, haven't tested it tho.

 

[Kazeon]

Update:
- Fixed initialization issue
- Library is now separated into PathingLib and PathingColor
- Minimized code size

 

[Nestharus]

Excellent update.

You still have an initializer thing in your first line of code.


The only things left would be to generate objects specific to this resource and account for unit indexing systems.

 

[ZiBitheWand3r3r]

Maybe add 3 walk-checker units instead of 1.
Base them on peon, grunt and tauren.
This will allow you to improve this library by adding abilities to check 3 diffrent walkability sizes: 16/32/48

 

[Kazeon]

Silly me. Forgot to update minor mistake as Nestharus pointed out.

 

[Zwiebelchen]

private module Init
         private static method onInit takes nothing returns nothing
             call init()
         endmethod
     endmodule
     
     private struct InitStruct extends array
         private static method init takes nothing returns nothing
             set PathChecker = CreateUnit(DUMMY_PLAYER, PATH_CHECKER, 0, 0, 0)
             call UnitRemoveAbility(PathChecker, 'Amov')
             call ShowUnit(PathChecker, false)
             if GetLocalPlayer() == DUMMY_PLAYER then
                 call FogEnable(false)
             endif
         endmethod
         implement Init
     endstruct

What exactly was the issue with the library initializer btw? The new solution seems super convoluted and I don't see the point in it.

Also, any ideas on how to fix the unit sensitivity problem? You lib is the only one I've seen so far that takes destructables into account, but this thing also reacting to units makes it kinda unusable for missile or knockback systems.

 

[PurgeandFire]

What exactly was the issue with the library initializer btw? The new solution seems super convoluted and I don't see the point in it.

It is an issue with Vexorian's jasshelper. Picture libraries as a tree where "requires" indicates that the library is a parent. The "root" node in a tree is the one that is all the way at the top (all the children require the root, or they require a library which requires the root).

i.e. if you have a library B that requires A, and library C that requires A, then you'll have a tree that will look something like this:

.. A .
./...\.
B....C

Vexorian's jasshelper evaluates initializers as follows:

• First execute the root module initializer, and then all its children's module initializers.
• Second, execute the root struct initializers (private static method onInit) and then all its children's struct initializers.
• Third, execute the library initializers and all its children's library initializers.
• Finally, execute the scope initializers and all its children's scope initializers, and then its regular Trig_Init methods (I don't remember the details for this step).

This leads to weird problems when you try to use a library within an initialization function. If the library you require uses a library initializer whereas your child library uses a struct initializer, then your child library's init will run first.

That's why a lot of libraries just use module initializers. They are implemented first, so you're guaranteed to have functionality when someone calls it within their initialization function. It is a minor cost of readability, but eh there isn't any way of knowing how an individual user writes his code, so it is kinda a necessary evil if you wan't your code to work in those cases. :\

The easiest way to fix this would be to update jasshelper. Cohadar did that but he switched the parser and that gave a slew of other issues--so it never really caught on.

 

[Kazeon]

Also, any ideas on how to fix the unit sensitivity problem? You lib is the only one I've seen so far that takes destructables into account, but this thing also reacting to units makes it kinda unusable for missile or knockback systems.

I kinda forgot to reply. Maybe there is. But perhaps it's not a neat solution:
Before you check a pathing just move all units around the point within.. largest unit collision size in your map, to another point. Using SetUnitX/Y will move normal unit's pathing to the new spot immediately, but not with structure unit's, it will stay. If you do so, I suppose it will work like PnF's pathing checker then. I haven't tested it tho but I'm pretty much sure bout the result ^^

@PnF:
Thanks man for the explanation!

 

[MyPad]

Now that the number of players has increased from 12 to 24, modifying the DUMMY_PLAYER to refer to the new slot of Neutral Passive would be recommended instead of just a hardcoded 15.

 

[Pinzu]

This hasn't been replaced by new natives right?

 

[emil23]

is it possibleto make it so the system doesnt detect pathning generatedby units

 

[ToldYouSo]

Could anyone tell me what is that code?

    // Object generator
    //! external ObjectMerger w3u hgry hPLF unsf "(PathingLib) FlyChecker"   unam "" umdl ".mdl" ubdg 0 uabi "Aloc" uble 0 ulum 0 upoi 0 uico "" umxp 0 umxr 0 ussc 0 ushu "" ugol 0 uaen "" udea "" umvt "fly" usnd "" ufle 0 ufoo 0 uspe 1 uhom 1 urac "unknown" usid 0 usin 0 upgr "" uhot "" utip "" utub ""
    //! external ObjectMerger w3u hfoo hPLW unsf "(PathingLib) WalkChecker"  unam "" umdl ".mdl" ubdg 0 uabi "Aloc" uble 0 ulum 0 upoi 0 uico "" umxp 0 umxr 0 ussc 0 ushu "" ugol 0 uaen "" udea "" umvt "foot" ucol 0 usnd "" ufle 0 ufoo 0 uspe 1 uhom 1 urac "unknown" usid 0 usin 0 upgr "" uhot "" utip "" utub ""
    //! external ObjectMerger w3u hhou hPLB unsf "(PathingLib) BuildChecker" unam "" umdl ".mdl" ubdg 1 uabi "Aloc" upat "" ulum 0 upoi 0 uubs "" uble 0 ushb "" uico "" ugol 0 ufma 0 umxp 0 ubsl "" umxr 0 ussc 0 ushu "" uaen "" udea "" umvt "" ucol 0 usnd "" ufle 0 ufoo 0 uspe 1 uhom 1 urac "unknown" usid 0 usin 0 upgr "" uhot "" utip "" utub ""
    //! external ObjectMerger w3u hpea hPLP unsf "(PathingLib) PathChecker"  unam "" umdl ".mdl" ubdg 0 uabi "Aloc" uble 0 ubui "hPLF,hPLW,hPLB" ulum 0 upoi 0 uico "" umxp 0 umxr 0 ussc 0 ushu "" ugol 0 uaen "" udea "" umvt "foot" ucol 0 usnd "" ufle 0 ufoo 0 uspe 1 uhom 1 urac "unknown" usid 0 usin 0 upgr "" uhot "" utip "" utub ""

Is there a way to use that system without these strings? Since Im using another version of world editor, these things give me the error while trying to save the demo map. (and I dont plan to use another since my map is already hardcoded into another WE version)

1.26 version.

 

[Pyrogasm]

There is zero good reason to be on patch 1.26 any more. Please update your game; it's literally free.

This is old code that can no longer run in the modern WE because //! external calls are now deprecated. Those lines create units in the Object Editor. You can do what they do manually by going word-by-word and matching up what that means you should change. Things always come in pairs just like when editing spell data with triggers:

• ObjectMerger w3u ---> OM is making a unit
• hgrp hPLF ---> based on unit 'hgrp' it has the new custom rawcode 'hPLF'
• unsf "(PathingLib) FlyChecker" ---> it has that as a suffix
• unam "" ---> the field unam (name) has the value "" (empty string)
• umdl ".mdl" ---> it has a model file of ".mdl"

See how you can walk through the list? You just need to recreate them all yourself as they are specified by the OM calls. Press Ctrl + D while in the Object Editor to see each field by its raw name rather than the verbose names for each field (unam vs "Unit Name").

 

[ToldYouSo]

There is zero good reason to be on patch 1.26 any more. Please update your game; it's literally free.

This is old code that can no longer run in the modern WE because //! external calls are now deprecated. Those lines create units in the Object Editor. You can do what they do manually by going word-by-word and matching up what that means you should change. Things always come in pairs just like when editing spell data with triggers:

• ObjectMerger w3u ---> OM is making a unit
• hgrp hPLF ---> based on unit 'hgrp' it has the new custom rawcode 'hPLF'
• unsf "(PathingLib) FlyChecker" ---> it has that as a suffix
• unam "" ---> the field unam (name) has the value "" (empty string)
• umdl ".mdl" ---> it has a model file of ".mdl"

See how you can walk through the list? You just need to recreate them all yourself as they are specified by the OM calls. Press Ctrl + D while in the Object Editor to see each field by its raw name rather than the verbose names for each field (unam vs "Unit Name").

Oh, I see. Thx you. But since his demo map already has modified object editor with units named FlyChecker; WalkChecker and etc. I suggest I can easily remove those lines from library, copy and paste his units from Object Editor, and that's it, I just copied them and it should work fine?

Pyrogasm is there a way that this system check inside a loop would loop endlessly?
f.e

loop
set X = GetRandomReal(GetRectMinX(bj_mapInitialPlayableArea), GetRectMaxX(bj_mapInitialPlayableArea)) 
set Y = GetRandomReal(GetRectMinY(bj_mapInitialPlayableArea), GetRectMaxY(bj_mapInitialPlayableArea))
exitwhen IsTerrainWalkable(X, Y)
endloop

?

 

[Pyrogasm]

The OM lines probably made those units in the first place, so yeah you can just copy them.