Vallar's Forum Posts

  • > I am unsure if what you want is the sprite to follow a path drawn by your finger, just following your finger or mimic a behavior where the sprite is "pinned" to the touch so it moves with your finger.

    >

    > To have it where you touch a place and the sprite moves towards it. Add the Pathfinding behavior to the sprite then use an action

    > "On Touch" > "Find Path X: Touch.X - Y: Touch.Y"

    > "On Path Found" > "Move Along the Path"

    >

    > To have it where the sprite moves all the time with your touch:

    > "On Touch" > "Set Position X: Touch.X - Y: Touch.Y"

    >

    > Hope that helps.

    >

    I need something like in this game:

    https://play.google.com/store/apps/deta ... rles&hl=en

    If I do what you say it works?

    I couldn't check the game as your link is edited out (a security measure in the forums). Can you at least mention the game's name so I can check it out?

  • What are the enemies pathing towards? Can you just set it to move towards the thing without using pathfinding? i.e. Set Angle. There's a ghost shooter tutorial level where monsters spawn outside of the layout and move towards the player without the use of pathfinding. If you definitely need pathfinding then have them move towards the central point of the level until they are inside the layout then enable pathfinding?

    They are pathing towards a random point inside the layout. I tried a Move but it isn't working very efficiently, half the sprite must be inside the layout for the pathfinding to kick in (or that is what I think anyway). This eliminates the part where the player would feel the enemies are coming out of the boundaries. I tried to do it like the tutorial where I use the Bullet behavior and rotate the enemy towards a random point inside the layout, then once the enemy is inside the layout (inverting the "Inside Layout" condition) I would disable the Bullet behavior and activate the Pathfinding. Unfortunately, it doesn't work. The bullet gets disabled but the pathfinder still doesn't get a path.

    Worthy of note however that the second method (Bullet + Pathfinding), C2 considers the sprite is inside the layout when at least 2-3 pixels of the sprite are INSIDE the layout. Yet, the pathfinding doesn't get a path (which I believe is because it is still considering the sprite is outside of the layout). I then had a condition testing where X is more than 10 and less than 960 then disable Bullet behavior and activate Pathfinding. The pathfinder gets a path and the "isMoving" boolean is set to true on the enemies but they don't move. They stop. So I am unsure what to do really.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Hello,

    I have a layout that is the same exact size as the game's window 960x640. However, I am using the pathifinding behavior with my enemies and that is proving problematic with what I want to do.

    What I want to do is simulate enemies appearing into the layout as if they came from outside the screen (left and right). It is similar to the behavior you see in Feeding Frenzy (the game), the fish appear outside of the screen and move into the screen from the left or right side.

    What I have done to try and remedy this is that I spawned my enemies outside of the screen; they have the pathfinding behavior. I gave them a path INSIDE the layout (and therefore the screen) so they move into the screen. However, they never get a path. I later found out a bug report where Ashley said that is by design since the pathfinding assumes anything outside of the layout is infinite and can't be calculated.

    The second method I tried to do is that I made the layout bigger, that way when the enemies spawn outside of the screen they are in the layout still. My problem is, the window is fixed on the top left of the screen and I want it to move to the center of the layout. So the rest can be "extra space" I would use to spawn enemies. I couldn't find any actions or anything on this forum that fixes this problem.

    My other solution is that I would add an action "Scroll to Object" with a "On Start of Layout" condition. However the problem now is that I have to shift everything I have been adding to my layout (which isn't a big deal in of itself). However, with the new setup, I can't get a good visual if for example the GUI text I put is centered when the window scrolls eventually. I have to put the object, play the game and look at it. Didn't find it good enough, move it a bit, then play again and so on and so forth till I fix it. Obviously this is a hassle and a lot of needless fiddling. Is there a way to fix the issue I am having?

    Thank you very much in advance.

  • I am unsure if what you want is the sprite to follow a path drawn by your finger, just following your finger or mimic a behavior where the sprite is "pinned" to the touch so it moves with your finger.

    To have it where you touch a place and the sprite moves towards it. Add the Pathfinding behavior to the sprite then use an action

    "On Touch" > "Find Path X: Touch.X - Y: Touch.Y"

    "On Path Found" > "Move Along the Path"

    To have it where the sprite moves all the time with your touch:

    "On Touch" > "Set Position X: Touch.X - Y: Touch.Y"

    Hope that helps.

  • Might not be the best to do this but you can use the condition "Mouse Click On An Object" put your events based on each object you are selecting. I have been using this so far with objects overlapping and it never selects the bottom object if I click on the top one.

  • We don't normally investigate bugs that are not minimal projects. The attached .capx has 53 events, it probably only needs 2-3 to demonstrate the problem. There are also 3 layouts, non-trivial controls that I can't figure out within a minute or two, and no description on what to actually do in your .capx - this is why we ask for minimal projects.

    Anyway, "dead center" of the target object is such an infinitesimally small target area that in practice it will never hit "dead center". This is made worse by the fact fast-moving objects can step large distances every tick (e.g. at 600px/sec, it's stepping 10px per tick, so it may not even stop on top of a 5px object). To solve this there is a radius tolerance where it can be near to but not exactly on the destination and count as arrived. Therefore this is by design.

    Sorry for the bad .capx. It is the first time I submit a bug and I didn't know that you only needed such a small CAPX. I am going to be more careful in the future and thanks for the explanation!

  • I also have noticed this with path finding movement and decided to use other behaviors (may not be possible in all situations)

    I had a player move towards enemy on path finding movement and had an event for on collision to attack (since enemy was still moving I didn't want to wait for arrival and have them walk past each other). Sometimes it would "arrive" at the enemies origin but wouldn't be close enough to cause collision.

    Also had zombies that were supposed to take a few steps at a time so it was path finding a small distance. Randomly it wouldn't move at all when it was supposed to. I could never trouble shoot it. I guess now I know it was "close enough" so didn't move at all.

    I know this post doesn't help you but I am interested in any resolution as right now path finding movement is my last choice, unless there is an actual maze.

    Well I have been using an "On Arrived" + "Move To" to get the moving object to reach the center of the target. It doesn't feel natural if you really concentrate (doubt players will notice if they are engaged). It is good for now though as I haven't gone for polish yet.

    I guess it can't hurt filing as a bug. If it is intended behaviour then Ashley will know and just close the report. If not then he will fix it at some point

    ~Sol

    Done, I filed a bug report and hopefully it will be fixed with one of those updates

  • Problem Description

    If you add the pathfinding to an object (let's say O1) and give O1 a target as another object to reach as a destination. O1 will give uponce it reaches the general borders of the object and considers O1 as "arrived".

    Here are some screenshots:

    Changing the cell size by increasing and decreasing doesn't affect the path finding drastically (the first image is with Cell Size as the default and if changed to 0 as for the second image is for when you change the cell size to match the object's size -- note object is a square).

    Attach a Capx

    https://dl.dropboxusercontent.com/u/682 ... 20Bug.capx

    Description of Capx

    The CAPX has the same exact setup I was using and will replicate the problem above.

    Steps to Reproduce Bug

    • Create an object with the size of 15x15 pixels
    • Add the object to a family.
    • Add to the object (and not the family) the pathfinding behavior
    • Don't change anything on the pathfinding settings.
    • Use the "Find Path" and give it another object as the target.
    • Use the "Move Along Path" and you'll find the same exact problem.

    Observed Result

    The moving object will not stop moving and mark itself as arrived at the dead center of the target object. The object will be marked as arrived and will stop once it "collides" with the target object.

    Expected Result

    The moving object should only be considered and mark itself as arrived when it reaches the dead center of the target object. If the above is desired then changing the settings would be needed to give a VERY large cell size.

    Affected Browsers

    • Chrome: Yes
    • FireFox: Yes, but the moving object gets much closer to the intended behavior than Chrome
    • Internet Explorer:NA

    Operating System and Service Pack

    Windows 8.1 with latest updates_

    Construct 2 Version ID

    r229 Beta

  • Hmmm, this must be a "quirk" of the pathfinder movement - it just gives up when it's "good enough". Probably to do with speed/optimisation of the behaviour most likely.

    I guess doing something like Arima suggested, using LOS and then simply "moveto" once LOS has been achieved. You can set your LOS distance to be fairly close to the object itself and it should give the desired result.

    I think maybe I should play around with pathfinding a bit more and see if there is some other way, but that method sounds pretty good to me in theory.

    ~Sol

    Should I file a bug report or anything of the sort so Ashley could check it?

    Right now I am using a check with distance() and having the Move To take over as I feel LOS is a bit of an over kill, but I might actually end up using it as you mentioned since it may make the movement appear more "fluid".

  • What happens if you set the pathfinding cell size to be the exact same as the actual object doing the pathfinding?

    Eg. if your object is still set at 5px, make the path cells to be 5px also... just wondering what would cause it to suddenly stop when it gets "close enough". It has to be something between the actual object bounding box size, and the pathfinding cell size.

    ~Sol

    There is nothing on the layout between the two. I only have 3 objects on the layout as you can see below; the moving object is created on run time and immediately moves to one of the two objects (that have the green object). The moving object is created on the cyan/light blue square.

    The result above is when I increased the cell size to the same as the object moving. As you can see, not much difference.

  • How I do it is by checking frequently for line of sight to the destination, and when the sprite has it I stop the pathfinding behavior and start the moveto plugin.

    I didn't think of that, but I am currently using the On Arrive event to then kick in the Move To command (previously was a Set Position). It looks slightly instant, which might give the feeling of "snapping". It isn't too bad though and might actually fly by as a feature.

    Maybe another way would be to create/spawn a 1pixel transparent sprite on mouse click ..then set the 1pixel sprites position to the clicked object.X,Y origin within the same event..

    -->

    Then 'find path' to the 1pixel sprite.x,y

    and destroy the 1pixel sprite after pathfinder arrives at destination

    that might work a little better

    also If you needed to find paths to moving objects then you would just add a pin behavior to the 1pixel sprite which is pinned to object at initial mouse click

    It is a stationary object that I am moving towards. This might actually work, albeit I feel this is more of a bug in Construct 2 (r229 is what I am using) more than anything else. I doubt the intended use of "Find a path to an object's X and Y position" would just end when it reaches the general abouts of the X and Y.

  • Just curious, did you try making the actual object that is using path finding very small? Maybe reduce the size to only 1 pixel? Just to see if the theory about it stops when it touches the border of the destination?

    If it's smaller, maybe it will get closer to the destination point

    *EDIT*

    I think it's obvious that I don't really ever use path finding - so these problems are new to me also!

    ~Sol

    The moving object is 15x15 px by default. 1x1px is almost impossible for me to see. I tried with 5x5px and it doesn't get any nearer. In fact, what I discovered that the exact position of arrival is not fixed.

    So for example, if I send instance1 of moving object to another object's position it will arrive (for example, this isn't 100% true but just to give an example) at the top left of the object (inside the object not outside of its borders).

    If I choose instance2 of the moving object from another location, it will arrive at middle left instead of top left as the first instance. Clearly the targeted position if I use a sprite as the position is messed up (perhaps a bug?) or there is something I am not understanding with path finding that is going under the hood.

  • Oh my bad I didn't read your post very well it seems. Haha!

    ~Sol

    Not at all, you confirmed that the best method is what Facecrime mentioned. I didn't like the fact that Construct 2 was doing this, but apparently no other way.

    Thanks a lot!

  • A quick and dirty fix would be that pathfinding only works if the object ISN'T overlapping the destination object... then when it touches the destination to have it move to the X.Y position of the destination manually - since by the time it has touched the object the pathfinding has already done it's job.

    You could even create a small buffer around the destination (use a slightly enlarged version of the same sprite maybe) so that it "corrects" itself before it's already on-top. It might make this look a little less "oh um let me just fix myself at the last second".

    ~Sol

    Currently that is what I am doing, as mentioned by Facecrime, I do a set position at the On Arrive event for now. Once I get the basic functionality going, I'll look into making it more smooth.

  • The Destination Object X,Y position is based on its Origin image point..not its border or collision box

    it would suggest that its the size of the pathfinding cell but if you are saying you entered a size of 0 then it must be something else

    An objects position is just a destination..its no different that just stating a position....both object position and screen positions are the same thing...based on image origin

    personally I would store Mouseclick.X, Y coordinates in a Global Variable and then update and send the pathfinder to those Coordinates..

    its more accurate

    I understand that sending the Mouse X and Y positions would be easier. But the intended use won't benefit from that, unfortunately. What I want is that the moving object to arrive at the dead center of another object. If I send the Mouse X and Mouse Y, that won't always equal the dead center of the object. The user might have clicked on the borders of the object for example.