Attempt to call method 'getX' (a nil value) about jumper

Ok, I figured out the first problem. I had to use node.x and node.y instead of node.getX() and node.getY(). Is the readme outdated? :O

[pancinteractive]

Remember to use the most recent stable build of Jumper and not the dev version.

[Yonaba]

@Myll, first of all, thanks for the kind words, and for your interest.

Concerning the first question, well, the README is not outdated. You are actually (I believe) using the newer syntax for the actual development version of this library, as @pancsoftware kindly pointed out. Instead, use the latest stable version (which is 1.8.1, at the moment, and the example given for this version.).
I will manage to find some time and reorganise the repository, and leave the latest stable accessible from the main branch. As-is, I admit the repository layout is quite messy. Sorry for that.

As for the second question, you normally don't need to do such expensive things. Actually, Jumper resolves the collision map dynamically. You just have to init a pathfinder once, passing it your collision map. Later on, if you need to change node from walkable to unwalkable, or vice versa, just tweak the collision map data directly. For instance:

local map = {
  {0,0,0,0,0,0,0},
  {0,0,0,0,0,0,0},
  {0,0,0,0,0,0,0},
}

local Grid = require ('jumper.grid')
local Pathfinder = require ('jumper.pathfinder')

local walkable = 0
local myGrid = Grid(map)
local myFinder = Pathfinder(grid, 'ASTAR',walkable)

-- Need to change node at (x = 4,y = 1) behaviour
print(myGrid:isWalkableAt(4,1)) --> true

map[1][4] = 1 -- Change the collision map data for node(4,1) from "0" to "1"
print(myGrid:isWalkableAt(4,1)) --> false

This is basically how it works. By changing the underlying collision map data, in case a value on this map no longer matches the initial "walkable" property given, Jumper considers the corresponding node as no longer walkable.

PS/ Side note, it is advised in general not to use "/" in paths passed to require, but instead use dots ".". Slashes can cause problems on some specific systems, while dots will not. So better use this style:

local Grid = require ("jumper.grid") -- The grid class
local Pathfinder = require ("jumper.pathfinder") -- The pathfinder lass

You might have noticed this is the style I always use in the examples I give in all my READMEs.

Hope all of this helps. Let me know how it goes anyway.

Hi Yonaba,

Yes, I was using the stable version but was referring to the newer syntax. Also, I had to change the dots to slashes because it was giving me errors like these:

[ VScript ]: [X] module jumper/core/path FAILED: scripts/vscripts/jumper/core/path.lua:18: loop or previous error loading module 'jumper/core/path' [ VScript ]: [X] module jumper/grid FAILED: scripts/vscripts/jumper/grid.lua:41: module 'jumper/grid.core.node' not found: [ VScript ]: no field package.preload['jumper/grid.core.node']Failed to find scripts/vscripts/jumper/grid/core/node.lua

The library is working nicely, but I have a question regarding tunneling. I understand the stable version doesn't support tunneling with JPS, but what about ASTAR?

When I use ASTAR and set tunneling to false (I also tried true):
local path, length = MyFinder:getPath(startx, starty, endx, endy, false)

I still get a path like this. I added purple rectangles where I believe extra nodes should be.

Thank you!

[Yonaba]

Hi @Myll,
Sorry for the delay. I see what the problem is. You just need something i'll rather call it "corner crossing". This feature is not availale as-of-now, but will be implemented later. I already filed an issue for this a while back (see #30 for more details). For now, if the original problem is solved, we can keep this issue closed, and watch what goes on with issue #30.
Thanks.

Got it, thanks.

On Oct 23, 2014, at 7:26 AM, Roland Y. [email protected] wrote:

Hi @Myll https://github.com/Myll,
Sorry for the delay. I see what the problem is. You just need something i'll rather call it "corner crossing". This feature is not availale as-of-now, but will be implemented later. I already filed an issue for this a while back (see #30 #30 for more details). For now, if the original problem is solved, we can keep this issue closed, and watch what goes on with issue #30 #30.
Thanks.

—
Reply to this email directly or view it on GitHub #35 (comment).