Version 0.17.49

Information about releases and roadmap.
Post Reply
User avatar
FactorioBot
Factorio Staff
Factorio Staff
Posts: 228
Joined: Tue May 12, 2015 1:48 pm

Version 0.17.49

Post by FactorioBot » Thu Jun 13, 2019 5:06 pm

Bugfixes
  • Fixed sprite batching issue when drawing many inserters with circuit connectors. (61861)
  • Fixed construction robot working shadow. (71909)
  • Fixed using repeat_count in RotatedAnimation definition would cause crash. (71939)
  • Fixed rail signal consistency in case of reserved signal being invalidated by building a rail that puts both sides into same block.
  • Fixed rail crash related to marking reserved signal for deconstruction.
  • Fixed that programmatically set locale for autoplace controls didn't work. (71933)
  • Fixed that scrollpane consumed the mouse wheel events even when not activated, which blocked the other (parent) scrollpane. (69766)
  • Fixed that re-pathing in chain signal sequence didn't respect the need for green exit when the re-pathing was based on manual change of target station. (71371)
  • Fixed that changing state of rail signal by circuit network didn't properly update state of parent circuit signals. (71731)
  • Fixed that rail signal disabled by circuit network didn't prevent train passing by it if it guards a block that is already reserved/occupied by the same train. (71839)
  • Limited of usage of tab/shift-tab to move between textboxes as other objects didn't support it and it seems like it isn't worth to try to support it for everything. (69656) (71556)
  • Reduced the UPS impact of a large number of biters trying to pathfind. (71865)
  • Fixed that tabbing could move to invisible or disabled widgets.
Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

User avatar
BattleFluffy
Long Handed Inserter
Long Handed Inserter
Posts: 75
Joined: Sun Mar 31, 2019 4:58 pm
Contact:

Re: Version 0.17.49

Post by BattleFluffy » Thu Jun 13, 2019 5:32 pm

Reduced the UPS impact of a large number of bitters trying to pathfind.
Awesome, thanks for looking at this Oxyd ! :D
Pathfinder was using 1ms in my game in 0.17.48, I'm waiting for the patch to appear on Steam so I can see what my new times are. :>

I did a little bit of reading back in old FFF's about the last time pathfinding was looked at. One suggestion that came up then was to use Jump Point Search instead of A*.

I had a look at some videos of this method online and it seems like it would be a great match for Factorio bitters. Sounds like a really sneaky algorithm :> According to one video I watched about it, on short paths it's not that different from A*, but for longer paths, especially with obstacles, it can be 20x or even 200x faster.

Anyway, I was wondering if you ever gave some thought to JPS ? :>

th0
Inserter
Inserter
Posts: 21
Joined: Sat Mar 16, 2019 12:04 pm
Contact:

Re: Version 0.17.49

Post by th0 » Thu Jun 13, 2019 6:35 pm

Thanks.
I don't see it on Steam. Is it my problem or general?

SchniSchnaSchnuck
Manual Inserter
Manual Inserter
Posts: 2
Joined: Tue Apr 23, 2019 2:07 pm
Contact:

Re: Version 0.17.49

Post by SchniSchnaSchnuck » Thu Jun 13, 2019 6:45 pm

th0 wrote:
Thu Jun 13, 2019 6:35 pm
Thanks.
I don't see it on Steam. Is it my problem or general?
I have the same problem

Loewchen
Global Moderator
Global Moderator
Posts: 5206
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: Version 0.17.49

Post by Loewchen » Thu Jun 13, 2019 7:19 pm

It's on steam now.

jamezhall
Burner Inserter
Burner Inserter
Posts: 11
Joined: Fri Jul 21, 2017 11:27 am
Contact:

Re: Version 0.17.49

Post by jamezhall » Thu Jun 13, 2019 10:36 pm

Limited of usage of tab/shift-tab to move between textboxes as other objects didn't support it and it seems like it isn't worth to try to support it for everything.
The one thing I can't stand is not being able to TAB when changing train colors. Most of the time i'm typing in an rgb code and I have to type in a number -> move the mouse -> click in the next feild, repeat, repeat. Is this part of that?

programaths
Manual Inserter
Manual Inserter
Posts: 4
Joined: Fri Feb 22, 2019 6:44 pm
Contact:

Re: Version 0.17.49

Post by programaths » Sun Jun 16, 2019 9:44 am

BattleFluffy wrote:
Thu Jun 13, 2019 5:32 pm
[...]
Anyway, I was wondering if you ever gave some thought to JPS ? :>
This looks indeed a nice thing! It's also nicely explained here : https://zerowidth.com/2013/05/05/jump-p ... ained.html

But as I understood, it requires a jump table too. There is some time to pour to analyse the feasibility in Factorio.

Now, when you build a structure, Factorio probably mark the cell as busy. With JPS, there would be extra work to update the jumping table.

This extra work may be to costly! So, they would need to get metrics on how much structures people build over time and experiment.
Some people have auto expanding factories, which looks like one of the worse case scenario for JPS.

But it is still an option they could consider. Also, they can probably have an hybrid approach. But that would mean to have some heuristic and being able to correct it online :-\

It's though material here!

Dominik
Factorio Staff
Factorio Staff
Posts: 534
Joined: Sat Oct 12, 2013 9:08 am
Contact:

Re: Version 0.17.49

Post by Dominik » Mon Jun 17, 2019 9:51 am

BattleFluffy wrote:
Thu Jun 13, 2019 5:32 pm
Anyway, I was wondering if you ever gave some thought to JPS ? :>
That looks good! I am surprised that nobody thought of that earlier.

mrvn
Smart Inserter
Smart Inserter
Posts: 3386
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Version 0.17.49

Post by mrvn » Mon Jun 17, 2019 11:52 am

programaths wrote:
Sun Jun 16, 2019 9:44 am
BattleFluffy wrote:
Thu Jun 13, 2019 5:32 pm
[...]
Anyway, I was wondering if you ever gave some thought to JPS ? :>
This looks indeed a nice thing! It's also nicely explained here : https://zerowidth.com/2013/05/05/jump-p ... ained.html

But as I understood, it requires a jump table too. There is some time to pour to analyse the feasibility in Factorio.

Now, when you build a structure, Factorio probably mark the cell as busy. With JPS, there would be extra work to update the jumping table.

This extra work may be to costly! So, they would need to get metrics on how much structures people build over time and experiment.
Some people have auto expanding factories, which looks like one of the worse case scenario for JPS.

But it is still an option they could consider. Also, they can probably have an hybrid approach. But that would mean to have some heuristic and being able to correct it online :-\

It's though material here!
JPS seems to only work around inefficiencies in the priority queue. Specifically adding a tile to the queue multiple times because it can be reached over multiple paths. JPS makes some paths preferred and only that path adds the tile saving the cost to check the priority queue for the tile for all alternate paths. But why not simply add a flag to each tile marking it when the tile was added to the priority queue? Then A* can check in O(1) if the tile is already present in the priority queue. You get the same saving without needing to build any jump tables or complex tests for obstacles in adjacent tiles.

But lets consider the special case of aliens in factorio. They do live far outside the base. In the wilderness. There won't be any user placed entities near the aliens usually for several chunks. It looks to me like the game could pre-process chunks to see if there are paths from one chunk to the other. Or is there a lake or a wall that splits the chunk in 2? Then aliens could first search for a path on the chunk level and then refine it on the tile level as needed. Paths around lakes would then be just a few chunks long instead of hundreds of tiles.

Obviously the chunk-chunk paths change when the user builds stuff. The simplest solution would be to mark chunk-chunk paths as obsolete in every chunk that changes (only significant changes like landfill or entities placed / removed). Then recalculate the chunk-chunk paths as needed. Most of the interior chunks of the players domain won't be interesting to aliens and don't need the chunk-chunk paths recalculated.

programaths
Manual Inserter
Manual Inserter
Posts: 4
Joined: Fri Feb 22, 2019 6:44 pm
Contact:

Re: Version 0.17.49

Post by programaths » Sun Jul 14, 2019 7:44 am

mrvn wrote:
Mon Jun 17, 2019 11:52 am
[...]Then recalculate the chunk-chunk paths as needed. Most of the interior chunks of the players domain won't be interesting to aliens and don't need the chunk-chunk paths recalculated.
So, basically, "layered A*" if I understood properly.

slippycheeze
Fast Inserter
Fast Inserter
Posts: 196
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Version 0.17.49

Post by slippycheeze » Sun Jul 14, 2019 6:23 pm

mrvn wrote:
Mon Jun 17, 2019 11:52 am
programaths wrote:
Sun Jun 16, 2019 9:44 am
BattleFluffy wrote:
Thu Jun 13, 2019 5:32 pm
[...]
Anyway, I was wondering if you ever gave some thought to JPS ? :>
This looks indeed a nice thing! It's also nicely explained here : https://zerowidth.com/2013/05/05/jump-p ... ained.html
But as I understood, it requires a jump table too. There is some time to pour to analyse the feasibility in Factorio.
JPS seems to only work around inefficiencies in the priority queue. Specifically adding a tile to the queue multiple times because it can be reached over multiple paths. JPS makes some paths preferred and only that path adds the tile saving the cost to check the priority queue for the tile for all alternate paths. But why not simply add a flag to each tile marking it when the tile was added to the priority queue? Then A* can check in O(1) if the tile is already present in the priority queue. You get the same saving without needing to build any jump tables or complex tests for obstacles in adjacent tiles.
Executive summary: JPS is far better than you think, Factorio would benefit from it, or perhaps works built on it (if any) that I'm not familiar with yet.

If you really want to get into it, this has been my go-to for A* optimization for a while now. In short, though, no: JPS isn't just addressing "inefficiencies in the priority queue" as you describe. The optimization properties are significantly greater than your proposal, unsurprisingly.

At the time of discussion in my linked note (and, I think, the referenced blog posts) it had some properties that made JPS hard to apply in all sorts of contexts ... unless you had a game with uniform path-cost on the grid. Always a nice property in context. Anyway, it and successors have definitely moved since but I haven't bothered to review it. I assume by now they can apply something similar in variable weight grids, non-rectangular grids, and almost certainly without assumptions like "zero width agent" :)
mrvn wrote:
Mon Jun 17, 2019 11:52 am
But lets consider the special case of aliens in factorio. They do live far outside the base. In the wilderness. There won't be any user placed entities near the aliens usually for several chunks. It looks to me like the game could pre-process chunks to see if there are paths from one chunk to the other. Or is there a lake or a wall that splits the chunk in 2? Then aliens could first search for a path on the chunk level and then refine it on the tile level as needed. Paths around lakes would then be just a few chunks long instead of hundreds of tiles.

Obviously the chunk-chunk paths change when the user builds stuff. The simplest solution would be to mark chunk-chunk paths as obsolete in every chunk that changes (only significant changes like landfill or entities placed / removed). Then recalculate the chunk-chunk paths as needed. Most of the interior chunks of the players domain won't be interesting to aliens and don't need the chunk-chunk paths recalculated.
A* is a simple (ha!) dynamic programming problem. Like any dynamic programming problem you make it faster one of four ways:
  1. You trade time for space through some form of precomputation.
  2. You do less work by restructuring your problem to make it smaller.
  3. You do less work by making better guesses about what to try first.
  4. Micro-optimizations.
We can dismiss micro-optimizations because they (like your proposal for a priority queue with O(1) membership testing) are fundamentally uninteresting in general; I don't have the Factorio source or enough info on target hardware and data size to make smart comments here on if, eg, an O(1) membership test demanding random memory access has a higher constant than a more computationally expensive queue that doesn't require access outside L2 cache.)

Your second proposal is either 1 or 2: precompute pathing data and cache it by chunk, using more space but less time since you can reuse it, or restructuring your problem to make it smaller. As in, if you only A* on chunks for some part of the problem you get to deal with 32^2 less candidate chunks to test, as long as you have an efficient way to determine if the entire chunk is passable or not, and assume you don't care *how* you get through it.

JFS is a much, much smarter version of 3 - the heuristics turn out to give theoretically optimal results with vastly lower time investment. That is absolutely not what you get from either a faster priority queue, or by routing on the chunk level. It is, theoretically at least, far far better, because it does an order of magnitude less work most of the time. (Again, if and only if the heuristics work in your problem space.)

PS: whoever asked why nobody thought of this before, answer is simple: dynamic programming problems have the fun property that almost any innovation looks so completely obvious in hindsight you are stuck wondering why nobody thought of it before. Clearly, the answer is "don't know why, but nobody *did* think of it, so hey, welcome to the new and better future..."

PPS: I dabble, and that only because the game related stuff is usually more fun to read than the other graph problem applications (which I do care about) of this stuff. Don't read me as saying JFS is the best solution, or even the best JFS-like algorithm today, just that it is definitely not "only" a better priority queue. ;)

mrvn
Smart Inserter
Smart Inserter
Posts: 3386
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Version 0.17.49

Post by mrvn » Mon Jul 15, 2019 11:03 am

slippycheeze wrote:
Sun Jul 14, 2019 6:23 pm
mrvn wrote:
Mon Jun 17, 2019 11:52 am
programaths wrote:
Sun Jun 16, 2019 9:44 am
BattleFluffy wrote:
Thu Jun 13, 2019 5:32 pm
[...]
Anyway, I was wondering if you ever gave some thought to JPS ? :>
This looks indeed a nice thing! It's also nicely explained here : https://zerowidth.com/2013/05/05/jump-p ... ained.html
But as I understood, it requires a jump table too. There is some time to pour to analyse the feasibility in Factorio.
JPS seems to only work around inefficiencies in the priority queue. Specifically adding a tile to the queue multiple times because it can be reached over multiple paths. JPS makes some paths preferred and only that path adds the tile saving the cost to check the priority queue for the tile for all alternate paths. But why not simply add a flag to each tile marking it when the tile was added to the priority queue? Then A* can check in O(1) if the tile is already present in the priority queue. You get the same saving without needing to build any jump tables or complex tests for obstacles in adjacent tiles.
Executive summary: JPS is far better than you think, Factorio would benefit from it, or perhaps works built on it (if any) that I'm not familiar with yet.

If you really want to get into it, this has been my go-to for A* optimization for a while now. In short, though, no: JPS isn't just addressing "inefficiencies in the priority queue" as you describe. The optimization properties are significantly greater than your proposal, unsurprisingly.

At the time of discussion in my linked note (and, I think, the referenced blog posts) it had some properties that made JPS hard to apply in all sorts of contexts ... unless you had a game with uniform path-cost on the grid. Always a nice property in context. Anyway, it and successors have definitely moved since but I haven't bothered to review it. I assume by now they can apply something similar in variable weight grids, non-rectangular grids, and almost certainly without assumptions like "zero width agent" :)
One thing I don't see as useful in JPS for factorio. JPS looks ahead in one direction until it hits an obstacle or the end of the map. I assume it also stops when the next step no longer brings it closer to the goal. It does this horizontal and vertical and only then goes diagonal. Right? So in factorio in the desert with with no rocks or trees for miles wouldn't JPS search horizontal and vertical for miles and miles? Doesn't that give a huge search area making each step in the JPS take forever? Sure there are far fewer steps but in the end what really costs time is fetching all the tiles from memory to check them.

The other thing is the path it finds. For example in an open desert doesn't JPS go horizontal or vertical at the start and finish with a diagonal. Right? Counting tiles that is a shortest path. But going in a straight line (alternative horizontal/vertical and diagonal moves) would be much more natural and expected. So even if JPS is faster would the result even look right?

slippycheeze
Fast Inserter
Fast Inserter
Posts: 196
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Version 0.17.49

Post by slippycheeze » Mon Jul 15, 2019 9:37 pm

mrvn wrote:
Mon Jul 15, 2019 11:03 am
slippycheeze wrote:
Sun Jul 14, 2019 6:23 pm
mrvn wrote:
Mon Jun 17, 2019 11:52 am
programaths wrote:
Sun Jun 16, 2019 9:44 am
BattleFluffy wrote:
Thu Jun 13, 2019 5:32 pm
[...]
Anyway, I was wondering if you ever gave some thought to JPS ? :>
This looks indeed a nice thing! It's also nicely explained here : https://zerowidth.com/2013/05/05/jump-p ... ained.html
But as I understood, it requires a jump table too. There is some time to pour to analyse the feasibility in Factorio.
JPS seems to only work around inefficiencies in the priority queue. Specifically adding a tile to the queue multiple times because it can be reached over multiple paths. JPS makes some paths preferred and only that path adds the tile saving the cost to check the priority queue for the tile for all alternate paths. But why not simply add a flag to each tile marking it when the tile was added to the priority queue? Then A* can check in O(1) if the tile is already present in the priority queue. You get the same saving without needing to build any jump tables or complex tests for obstacles in adjacent tiles.
Executive summary: JPS is far better than you think, Factorio would benefit from it, or perhaps works built on it (if any) that I'm not familiar with yet.

If you really want to get into it, this has been my go-to for A* optimization for a while now. In short, though, no: JPS isn't just addressing "inefficiencies in the priority queue" as you describe. The optimization properties are significantly greater than your proposal, unsurprisingly.

At the time of discussion in my linked note (and, I think, the referenced blog posts) it had some properties that made JPS hard to apply in all sorts of contexts ... unless you had a game with uniform path-cost on the grid. Always a nice property in context. Anyway, it and successors have definitely moved since but I haven't bothered to review it. I assume by now they can apply something similar in variable weight grids, non-rectangular grids, and almost certainly without assumptions like "zero width agent" :)
One thing I don't see as useful in JPS for factorio. JPS looks ahead in one direction until it hits an obstacle or the end of the map. I assume it also stops when the next step no longer brings it closer to the goal. It does this horizontal and vertical and only then goes diagonal. Right? So in factorio in the desert with with no rocks or trees for miles wouldn't JPS search horizontal and vertical for miles and miles? Doesn't that give a huge search area making each step in the JPS take forever? Sure there are far fewer steps but in the end what really costs time is fetching all the tiles from memory to check them.

The other thing is the path it finds. For example in an open desert doesn't JPS go horizontal or vertical at the start and finish with a diagonal. Right? Counting tiles that is a shortest path. But going in a straight line (alternative horizontal/vertical and diagonal moves) would be much more natural and expected. So even if JPS is faster would the result even look right?
I checked - it is much easier if you adjust the per-step delay waaay up to like a second or two in the JS code of that demo, because JPS is so fast, but no: it proceeds in the optimal direction for the target initially. So, a diagonal is chosen if that is the "cone approximating the target vector best", both initially, and after an obstacle, even when you have to reverse direction before resuming pathing. (Which, of course, is the definition of optimal, which is a property of the final result of JPS.)

So ... as long as your idea is "some approximation of the shortest path" for natural movement, it'll do OK. I'd personally guess that you do best with a shortest path for guiding the things, and then introduce random perturbations using strictly local information (as in, within a 10 tile radius or whatever) to vary from it a little, and/or other environmental reactions.

Ultimately, though, they pay Wube the big bux to figure that bit out, and not me. Which is probably a very, very good choice, because I'm not actually good at the bits like "natural feeling movement", compared to things like JFS is a strictly superior pathfinding method to A* if you meet the requirements, and as far as I can tell from the outside, Factorio does meet them.

I assume that vanilla A* must be OK enough for this because, well, unless this thread misleads, that is what is used today. JFS should give literally identical path output, given the same input, just faster. Certainly, I was unable to find a counterexample of that in the toy. :)

mrvn
Smart Inserter
Smart Inserter
Posts: 3386
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Version 0.17.49

Post by mrvn » Thu Jul 18, 2019 9:48 am

slippycheeze wrote:
Mon Jul 15, 2019 9:37 pm
mrvn wrote:
Mon Jul 15, 2019 11:03 am
slippycheeze wrote:
Sun Jul 14, 2019 6:23 pm
mrvn wrote:
Mon Jun 17, 2019 11:52 am
programaths wrote:
Sun Jun 16, 2019 9:44 am


This looks indeed a nice thing! It's also nicely explained here : https://zerowidth.com/2013/05/05/jump-p ... ained.html
But as I understood, it requires a jump table too. There is some time to pour to analyse the feasibility in Factorio.
JPS seems to only work around inefficiencies in the priority queue. Specifically adding a tile to the queue multiple times because it can be reached over multiple paths. JPS makes some paths preferred and only that path adds the tile saving the cost to check the priority queue for the tile for all alternate paths. But why not simply add a flag to each tile marking it when the tile was added to the priority queue? Then A* can check in O(1) if the tile is already present in the priority queue. You get the same saving without needing to build any jump tables or complex tests for obstacles in adjacent tiles.
Executive summary: JPS is far better than you think, Factorio would benefit from it, or perhaps works built on it (if any) that I'm not familiar with yet.

If you really want to get into it, this has been my go-to for A* optimization for a while now. In short, though, no: JPS isn't just addressing "inefficiencies in the priority queue" as you describe. The optimization properties are significantly greater than your proposal, unsurprisingly.

At the time of discussion in my linked note (and, I think, the referenced blog posts) it had some properties that made JPS hard to apply in all sorts of contexts ... unless you had a game with uniform path-cost on the grid. Always a nice property in context. Anyway, it and successors have definitely moved since but I haven't bothered to review it. I assume by now they can apply something similar in variable weight grids, non-rectangular grids, and almost certainly without assumptions like "zero width agent" :)
One thing I don't see as useful in JPS for factorio. JPS looks ahead in one direction until it hits an obstacle or the end of the map. I assume it also stops when the next step no longer brings it closer to the goal. It does this horizontal and vertical and only then goes diagonal. Right? So in factorio in the desert with with no rocks or trees for miles wouldn't JPS search horizontal and vertical for miles and miles? Doesn't that give a huge search area making each step in the JPS take forever? Sure there are far fewer steps but in the end what really costs time is fetching all the tiles from memory to check them.

The other thing is the path it finds. For example in an open desert doesn't JPS go horizontal or vertical at the start and finish with a diagonal. Right? Counting tiles that is a shortest path. But going in a straight line (alternative horizontal/vertical and diagonal moves) would be much more natural and expected. So even if JPS is faster would the result even look right?
I checked - it is much easier if you adjust the per-step delay waaay up to like a second or two in the JS code of that demo, because JPS is so fast, but no: it proceeds in the optimal direction for the target initially. So, a diagonal is chosen if that is the "cone approximating the target vector best", both initially, and after an obstacle, even when you have to reverse direction before resuming pathing. (Which, of course, is the definition of optimal, which is a property of the final result of JPS.)

So ... as long as your idea is "some approximation of the shortest path" for natural movement, it'll do OK. I'd personally guess that you do best with a shortest path for guiding the things, and then introduce random perturbations using strictly local information (as in, within a 10 tile radius or whatever) to vary from it a little, and/or other environmental reactions.

Ultimately, though, they pay Wube the big bux to figure that bit out, and not me. Which is probably a very, very good choice, because I'm not actually good at the bits like "natural feeling movement", compared to things like JFS is a strictly superior pathfinding method to A* if you meet the requirements, and as far as I can tell from the outside, Factorio does meet them.

I assume that vanilla A* must be OK enough for this because, well, unless this thread misleads, that is what is used today. JFS should give literally identical path output, given the same input, just faster. Certainly, I was unable to find a counterexample of that in the toy. :)
Even if you go diagonal first if that is the better start as far as I understood the explanation you would still go diagonal as long as possible. So baring obstacles you get one diagonal and one straight section. On the other hand with A* every tile along the way is added to the priority queue. And I think the distance to the goal is taken "as the crow flies". So as you drift away from the "as the crow flies" path the distance estimation doesn't go down 1 tile as you advance a tile. The combined cost goes up and the more natural path becomes cheaper. This causes A* to approximate the "as the crow flies" path.

As for the final movement: If you take the path and follow it tile to tile (center to center) the units would make a sharp turn in the center of each tile whenever it changed from straight to diagonal. Doesn't look good. A simple way to smooth that out is to not go to the center of the next tile but head towards the center of the tile 1 (2, 3, 4, ..) steps ahead. The more you look ahead the more you clip corners though and might hit obstacles. But even 1 tile look ahead makes a huge difference how the movement looks. For more lookahead it makes sense to only do it when not rounding an obstacle.

PS: going diagonal costs sqrt(2) in factorio. I'm not sure how that affects JPS.

slippycheeze
Fast Inserter
Fast Inserter
Posts: 196
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Version 0.17.49

Post by slippycheeze » Fri Jul 19, 2019 5:00 am

mrvn wrote:
Thu Jul 18, 2019 9:48 am
Even if you go diagonal first if that is the better start as far as I understood the explanation you would still go diagonal as long as possible.
Look, JPS is an optimization for A* on an equal weight grid map. It produces the same - optimal - output. It is literally just a performance improvement that doesn't change the outcome. At this point I don't know how else to explain that, so I'm just gonna step away.

Post Reply

Return to “Releases”

Who is online

Users browsing this forum: No registered users