This site requires JavaScript, please enable it in your browser!
Greenfoot back
MrBradley
MrBradley wrote ...

2021/9/30

Actor::getNeighbours(...) bug?

MrBradley MrBradley

2021/9/30

#
If the size of the cell as defined in the World is larger than the size of the image for the Actor (for example if you want a small gap between cells) then getNeighbours() may not return a number that would be reasonably expected as provided by the documentation: Return the neighbours to this object within a given distance. This method considers only logical location, ignoring extent of the image. Thus, it is most useful in scenarios where objects are contained in a single cell. All cells that can be reached in the number of steps given in 'distance' from this object are considered. Steps may be only in the four main directions, or may include diagonal steps, depending on the 'diagonal' parameter. Thus, a distance/diagonal specification of (1,false) will inspect four cells, (1,true) will inspect eight cells. For reference: World Cell size / Image Size = Result 16 / 16 = true 17 / 16 = true 18 / 16 = true 19 / 16 = false What is the logic behind identifying neighbours? If I write my own version using getObjectsAt it works fine... Thanks in advance. p.s. Many hours spent finding this one.
danpost danpost

2021/10/1

#
MrBradley wrote...
Actor::getNeighbours(...) bug?
I believe --- yes, you have found a bug. It seems as the step size diminishes, the more likely the occurrence. I did some testing with a cell size of 60. Both true and false diagonal settings worked fine until the image size dropped below 40. At a distance of 1, false gave 4, then 3 below 40; and, true gave 8, then 5 below 40. The 3 in y+1 row seem to be missed. However, at distance 2, at a smaller image size (I think it was 5), the y+1 and y+2 rows dropped, plus (x+2, y-2) and (x+2, y) cells. Very strange, indeed.
You need to login to post a reply.