Then you need (only 4 licensed c2)/use families.

https://www.scirra.com/manual/142/families

Or nick name the solids with one of the 2 plugins by rexrainbow.

One of them should be a 'fake' slider, only reacts to the player scrolling as a graphic element, but with no changing conditions attached to it. The other one, the real one, acts to the player scrolling and changes the things that you want to change. Now it is just a case of picking the right one and set the other one to the same Y position.

Logic:

Player changed fake_slider

set real_slider to same position

change the things you want to change based on the position of the real_slider

Player changed real_slider

change the things you want to change based on the position of the real_slider

set fake slider to same position

Depends on the moment that you acces that menu. You can't have most of the conditions in a 'on start layout' event.

Wich is totaly logic.

Geez i forgot to include the link. You solved you probs, buet here is it anyways:

https://

drive.google.com/open?id=0B1SSuCVV8v74aVhQUDBSdU9MVEE

Find a path with a solid sprite is in fact easy. Just set the origin on the right and 3 pixels outside the collision polygone. With a good cell size and a relative big border, it will avoid other solids. You can add the 'push out of solids' from the 'custum movement' to avoid them getting stuck or (better) use wat R0J0hound wrote. But you can not use the origin to rotate. Dooing this with a gost could work, keeping the face sprite aligned facing to the current waypoint in the path.

Pathmoving will avoid solids because of the cell size and cell border. NOT beacuse of the fact that the obstacles are solid. To include moving solids you will have to recalculate regions arround those objects a lot. There is an action for that. But do not expect wonders. Do not expect close encounters. Do not expect it to move trough small gates.

Give me a base capx. And i try.

Other (probaly better and more elegant) solutions go from using bullet to move an object from waypoint in the path to the next waypoint(i can show you that), to coding your own pathfinding (there are examples in the forum).

Is this what you want ?

Your local variable movement got reset when its topevent runs in its next tick. Always beeing zero, every tick. So, it kept finding paths, not ever coming to move on it.

Local variables are heaven, but you know that they reset (if you dont make them static) every time theire top event runs.

I added obstacles in event 12. I recalculated them localy for the battlefield. INCLUDING the battlefield.

I made the pathfinding logic in events 19 to 21.

I made the cellsize 30 and border 1. See manual why.

Hope you get the hang on the pathfinding thing.

Maybe you have to set the origin in the middle in the first frame, and the apply it to all frames of the animation ?

For the 9 points, just set 9(n) imagepoints , and use the expressions Sprite.ImagePointX(n) & Sprite.ImagePointY(n) as the positions to find a path to. Pick n in a choose(...,n)

https://www.scirra.com/manual/63/image-points

Set the obstacles on 'custom' in the pathfinding behaviour. And add obstacles, if you need to, in actions. And do use the 'create obstacle map' at least once somewhere, if you have obstacles.

The object will stop moving when reaching end of path, if it does not, you probaly let it find a path each tick. Or youre pathfinding has a problem.

If i may say some things that i personal dislike in your project. They are just personal taste. Just gentle tips:

Plz, name you sprites. Its difficult to look into a capX where everything is named 'sprite(n)'.

You can as well after the "direction = 1" condition move the sprite. Dont need the second 'action in between agent'.

When you enter the battle arena, all those blue solids still count as obstacles when finding a path. Needs more time to calculate, can lead to unecpected behaviour. Since now you have solids set as obstacles in the path behaviour.

All the blue obstacles are so many collission calculations. You can speed things up by 600% when you bring them in a tilemap.

Not that my opion counts in anyway or any other way on this forum.

Plz yell if you still have problems.

The first thing is see is that the pathfinding object is a solid it self, while having the pathfinder behaviour set to avoid solids. It can not not reach out itself. Either dont make the pathfinding object a solid, or dont make solids an obstacle.

Also. I am not sure that the collision polygones as set in the battlefield sprite work as expected when they have to repesend a solid to a pathfinding. Would it not be esayer to just use 4 solid solids ?

Also. I have no idea where 833,456 is supposed to be, but it do not think it is inside the battle area.

Maybe later i look deeper in it.

Wich plugin does the falling ? Physics ? Platform ? Bullet ?

How is the player controlling the object ?

Would be nice if you just post a CapX.

Make a new layer. Move sprite2 (the arrow) to that new layer. Set parrallax of that new layer to zero. Move the arrow in the layout to the top. Remove the action in the events. Now you have a HUB layer.

This is not meant to be functional, it is only meant to show multi touch.

https://

drive.google.com/open?id=0B1SSuCVV8v74ek1JWGI4b3RET3c