#(fullwall) Additional Citizens pathfinder options

56 messages · Page 1 of 1 (latest)

tight vector
bleak urchinBOT
#

(fullwall) Additional Citizens pathfinder options

bleak urchinBOT
#

Hi I'm AutoThreadBot! Don't mind me, I'll just be adding the helper team to this thread so they can see it. A human will get to you soon.

haughty nacelle
#

I seen you closed some related issues this morning I'm guessing you are migrating the issues from GitHub over to the discord?

tight vector
#

eventually yes

haughty nacelle
#

@zinc verge

#

o/

#

Seen you made some progress this morning Fullwall, looks promising.

#

It looks like you had to change a lot

#

Is the pathfinding range something that you would be allowing the user to modify?

#

I wonder if a feature for fake stairs or something would be useful to circumvent edge cases where the jump impossible but the precision required would be too much.

tight vector
#

the pathfinding range is already adjustable

haughty nacelle
#

Jump is possible*

#

Ah right on. Neat

zinc verge
haughty nacelle
#

I am struggling to comprehend the system in its current state but I was curious if it was able to update the path in realtime if blocks states change nearby.

Like if a tnt goes off or a block gets destroyed would it be able to dynamically adjust to those circumstances?

#

Or does it do one check at the beginning to the destination

tight vector
#

probably that could be added

#

it doesn't do bidirectional A* either

haughty nacelle
#

Bidirectional means looking backwards right?

#

To go the long way, so to speak.

zinc verge
haughty nacelle
#

Ah. I see.

#

I can see why that would be useful yeah.

zinc verge
#

not too sure about the usefulness. either you're meeting in the middle when pathfinding from both sides, or you let the pathfinder run twice in both directions. but latter is more a safety check, if start -> target is not reachable, but target -> start in some weird scenarios

#
  • you're doubling the work load by having 2 pathfinder instances running instead of just one
haughty nacelle
#

I assume if you have two positions on a grid and you want them to meet up in the middle (like two AI fighting each other) you would want to do it bidirectional otherwise at the start wouldn't both of them detect the far position and head there?

#

If there is no realtime updates

#

Or it would look like something from OSRS when you follow each other

tight vector
#

bidirectional A* speeds up A* significantly

zinc verge
haughty nacelle
#

Oh Fullwall this is the guy that works on pathetic by the way

#

Sorry for just inviting him I was looking into his project lol

#

I should have introduced him

tight vector
#

you can see how bidirectional helps

#

it's less helpful for open areas though

haughty nacelle
#

In a scenario where two paths are the same cost, does it go randomly or is it determined

#

By like some arrangement on the grid

#

Checks north first, etc.

#

Because theoretically you could just check all directions randomly and then purge that option from the list

tight vector
#

insertion order

zinc verge
# tight vector

that really depends on the heuristic. pathetic for example has a really aggressive heuristic which leads to a similiar result

#

theoretically bidirectional should be faster, but it's always a matter of the overhead coming with it

#

if you want to have a more efficient algorithm you could look into JPS or HPA*

#

but it's always a pros and cons consideration since with those you lose precision + memory(in terms of HPA*) for speed

tight vector
#

I know

#

HPA* is one of the next things to implement

tight vector
#

thinking I should probably merge minecraft and citizens movement systems so there's just one consistent movement system

haughty nacelle
#

Might be worth the investment