Possible bug but perhaps I'm missing something

Hello!

Just wanted to make sure before posting a bug that I'm just being a fool and it's not actually a bug.

The example is very simple. Two sprites with pinned "wheels", both with bound to layout and 8 direction. If I move the sprites to the edge of the window one set of wheels doesn't behave properly when the sprite reaches the edge.

https://drive.google.com/open?id=1gBzXmUDmay7q5vp3eHqrXrpc1Q6IEZh_

Thanks

Define "doesn't behave" properly.

As far as I could see, I noticed no difference between the wheels of the top sprite and bottom sprite.

Your wheels are pinned to the sprite, meaning that when you move your sprite, the wheels are then moved, with some delay (due to the nature of pin).

If you can explain clearly what you are expecting and what you are experiencing, it will be easier to investigate your issue.

Hi Kyatric. Thanks for the response.

What I experience from the capx I shared is:

• All is ok when moving without reaching the edge of the layout.
• when reaching the edge, and without lifting the key, the wheels of the bottom sprite move relative to the sprite they are pinned to (which shouldn't happen since they are position pinned to this bottom sprite).
• when releasing the key, the wheels of the bottom sprite return to the original position relative to the sprite that are pinned to.

I've also tried to replicate this behavior in C3 building it from scratch, but it didn't show. Now, when I imported the C2 example to C3 it behaves again as I described above (???).

I'm using the last build of C2, r262.

The runtime has to run behaviors in some order. There's no fundamental way around this. The order you are getting is either:

1) move 8direction

2) bound to layout

This means it bounds it to the layout after moving 8direction, which works as you want it to. Otherwise it's

1) bound to layout (before it's moved)

2) move 8direction (which could then move it outside the layout)

This means the object can temporarily be left outside the layout, because 8direction moved it after it checked the bounds.

The workaround is to change the order the behaviors run in, which you can do by rearranging the list.

The runtime has to run behaviors in some order. There's no fundamental way around this. The order you are getting is either:

1) move 8direction

2) bound to layout

This means it bounds it to the layout after moving 8direction, which works as you want it to. Otherwise it's

1) bound to layout (before it's moved)

2) move 8direction (which could then move it outside the layout)

This means the object can temporarily be left outside the layout, because 8direction moved it after it checked the bounds.

The workaround is to change the order the behaviors run in, which you can do by rearranging the list.

Ahhhh!!! Many many thanks. I was losing my mind. I knew that I was missing something. Didn´t occurred to me to check the order of behaviours.

Thanks you very much Kyatric and Ashley