Jill of the Jungle sword or boomerang, working example...

A gif of my working example:

Here's what it SHOULD look like: https://youtu.be/t7E-P4VJbdg?t=45

This is the best I've got so far: https://www.dropbox.com/s/p3hywg0ow9k7v ... .capx?dl=0

If you enable 14 and 15, a crude "drop" will kick in, to avoid the knife fighting around forever if it can't reach you ala: https://youtu.be/t7E-P4VJbdg?t=23

I also have another (broken) version: https://www.dropbox.com/s/vnl5gdjk0dqpq ... .capx?dl=0

It uses rexrainbow 's LJpotential behavior: viewtopic.php?f=153&t=112786

Basically, the knife needs to "pathfind" it's way back to the player a lot better, avoiding the obstacles properly. RIght now, it doesn't, but it makes a valiant effort to try!

Rex kindly made a version with bullet behavior: https://1drv.ms/u/s!Am5HlOzVf0kHlm8pc07sz5MESI51 but there's a bit of flutter with the angle rotation, and it clings a bit to the walls, but it serves as a useful example for some ideas. He also suggested using the boids plugin: behavior-rex-boids_t126707 but I've never used this before and am not sure how to make this work in this particular case.

If anyone has ANY advice on how I can try and get this knife-tech looking and working better, please be my guest! <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

Zebbi

You could try to tune the parameter of bullet behavior (max speed, or max rotate angle), then find out that the LJpotential behavior won't work well anymore. It needs tune the parameter A,B,m,n, too.

A possible solution is,

1. tune the behavior of the target object (bullet behavior in this case)

2. tune the parameter A,B,m,n of LJpotential behavior to match your requirement

Cool!

Are you using bullet for the boomerang/knife?

I am thinking when it hits an obstacle have it arc upward like a boomerang would and that would give it a better chance to find a path. Maybe make it move back along the X coordinate until it finds that path.

Not sure how your obstacles will be arranged but looks like if it goes up after a collision it will find a path back.

Zebbi

You could try to tune the parameter of bullet behavior (max speed, or max rotate angle), then find out that the LJpotential behavior won't work well anymore. It needs tune the parameter A,B,m,n, too.

A possible solution is,

1. tune the behavior of the target object (bullet behavior in this case)

2. tune the parameter A,B,m,n of LJpotential behavior to match your requirement

Yes, that's the hard part, I barely know what I'm adjusting with LJ! Is there some alternative to using "rotate 10 degrees"? I tried an anglediff idea, but it didn't work either.

Cool!

Are you using bullet for the boomerang/knife?

I am thinking when it hits an obstacle have it arc upward like a boomerang would and that would give it a better chance to find a path. Maybe make it move back along the X coordinate until it finds that path.

Not sure how your obstacles will be arranged but looks like if it goes up after a collision it will find a path back.

I'm using the car, as it had a good built-in bounce and turned nicely when you use a second object pinned on top to disguise the angling of the sprite. It's just hard to find a decent way of finding it's way home in a highly dynamic way (since pathfinding tends to be turn-based.) If I could work LJ out, it should be perfect as I could reject the solids, but I'm awful at setting it up properly, and the only reason my first example (and the gif) looks that good is because it didn't hit any solids!

Any boids experts want to have a go?

No takers? :/

No takers? :/

Well, I still think using the bullet behavior and On Line Of Sight and Pathway behaviors might be better to get that boomerang to return to you instead of falling off the screen but do what you are doing and maybe someone can get that boomerang to return every time.

Best!

> No takers? :/

>

Well, I still think using the bullet behavior and On Line Of Sight and Pathway behaviors might be better to get that boomerang to return to you instead of falling off the screen but do what you are doing and maybe someone can get that boomerang to return every time.

Best!

Say again? So, can pathfinding be used in realtime?

>

> > No takers? :/

> >

>

> Well, I still think using the bullet behavior and On Line Of Sight and Pathway behaviors might be better to get that boomerang to return to you instead of falling off the screen but do what you are doing and maybe someone can get that boomerang to return every time.

>

> Best!

>

Say again? So, can pathfinding be used in realtime?

Sure pathfinding and on line of sight work fine in real time.

Use the bullet behavior so it detects collisions when you release the boomerang but use on line of sight and pathfinding to bring it back to you.

If it has you locked in on line of sight just have it return to your position. If not find a path and clear obstacles until it has line of sight.

It should always return along the X axis towards you so include that to keep it moving.

Sure pathfinding and on line of sight work fine in real time.

Use the bullet behavior so it detects collisions when you release the boomerang but use on line of sight and pathfinding to bring it back to you.

If it has you locked in on line of sight just have it return to your position. If not find a path and clear obstacles until it has line of sight.

It should always return along the X axis towards you so include that to keep it moving.

I thought pathfinding had to calculated and couldn't work very efficiently on an every tick basis, which is what this would need to be? The solids might not be moving, but the player would be, so wouldn't pathfinding be really heavy on performance? I'm still having trouble working out how to incorporate this in my example

>

>

> Sure pathfinding and on line of sight work fine in real time.

>

> Use the bullet behavior so it detects collisions when you release the boomerang but use on line of sight and pathfinding to bring it back to you.

>

> If it has you locked in on line of sight just have it return to your position. If not find a path and clear obstacles until it has line of sight.

>

> It should always return along the X axis towards you so include that to keep it moving.

>

I thought pathfinding had to calculated and couldn't work very efficiently on an every tick basis, which is what this would need to be? The solids might not be moving, but the player would be, so wouldn't pathfinding be really heavy on performance? I'm still having trouble working out how to incorporate this in my example

Well what I suggested is using the bullet behavior. That is used to keep the boomerang flying back towards the player while on line of sight and pathfinding is used to change the bullets course as needed to get it back to the player so they are checking position every tick but not making adjustments every tick and should't slow down performance.

If I get some time I will try to make a capx with an example of what I mean but I am just going off what I see in your example so it may not work for your game.

>

> >

> >

> > Sure pathfinding and on line of sight work fine in real time.

> >

> > Use the bullet behavior so it detects collisions when you release the boomerang but use on line of sight and pathfinding to bring it back to you.

> >

> > If it has you locked in on line of sight just have it return to your position. If not find a path and clear obstacles until it has line of sight.

> >

> > It should always return along the X axis towards you so include that to keep it moving.

> >

> I thought pathfinding had to calculated and couldn't work very efficiently on an every tick basis, which is what this would need to be? The solids might not be moving, but the player would be, so wouldn't pathfinding be really heavy on performance? I'm still having trouble working out how to incorporate this in my example

>

Well what I suggested is using the bullet behavior. That is used to keep the boomerang flying back towards the player while on line of sight and pathfinding is used to change the bullets course as needed to get it back to the player so they are checking position every tick but not making adjustments every tick and should't slow down performance.

If I get some time I will try to make a capx with an example of what I mean but I am just going off what I see in your example so it may not work for your game.

Sounds like it could work really nicely, wish I knew where to start! I might have a cack-handed go at trying to figure it out...

I wonder if Magistross easystar could be useful here, if we used tiles instead of solid backgrounds, that might be super efficient for the knife to just pathfind itself all the way home?

Anyone got a pathfinding example I could hack in?

I can't figure this out with pathfinding, I've tried finding the path and incorporating it with my example, but it doesn't really work.

Still hoping for a solution 😒